Secure Boot wording

[daveythacher]

I was attempting to read the process used by the RP2350 bootrom and I came to the conclusion it does nothing. I noticed the documentation makes a different conclusion.

Section 10.1.1 or RP2350 datasheet page 802. (Version: August 8, 2024)

1. Calculate a SHA-256 hash using image code and data when loading the binary.
2. Decrypt the image’s signature using the user’s public key, which is also stored in the image.
3. Check the included, decrypted signature against the calculated SHA-256 hash value for the binary.
4. Check the image’s public key against a SHA-256 key fingerprint stored in OTP.

If both checks succeed, the bootrom assumes someone in possession of the private key registered by an OTP public key fingerprint calculated the same SHA-256 hash. Based on the properties of hash functions, the bootrom assumes that the binary contents has not been altered since the signature was generated. This proves that this is an authentic binary signed by the owner of the private key, so the bootrom will entertain the idea of running the binary.

[nathan-contino]

Why did you come to the conclusion that it does nothing?

[daveythacher]

1. Calculate the hash (Everything sounds good.)
2. Decrypt a hash using a public key within the image (Anyone can do that.)
3. Check the signature against the calculated hash. (We know the binary is correct as someone intended.)
4. Check the identity from the image with the OTP. (Anyone can do that.)

So we do not know who generated the hash. How it likely should read:

1. Calculate the hash.
2. Decrypt the hash using the OTP private key
3. Verify the hash

At this point we know the hash is correct and who made. Note this simple process may not be complete or safe.

[nathan-contino]

Gotcha, thanks for explaining. I'll look into clarifying this.

[kilograham]

I don't understand the criticism or at least your wording of it; what is the "it" that you say does nothing?

"4" does do something; without it we know that the hash verifies using the public key included with the binary. it very much matters that the public key matches one of the public key (hashes) stored in OTP, otherwise you could use any old key.

[daveythacher]

Conceptually this a simplified root of trust system. I was expecting something like using a public key to generate an encrypted hash then using the private to decrypt it. The identity is verified by asymmetric keys. Except you use symmetric keys so this obviously wrong.

Does your scheme not disclose the key by accident?

• Why is the users key in the image?
• What is the users key?
• What is the images key?
• What is the fingerprint?

So as I read it. I could brute force the signature to discover the OTP. Then I can sign any binary. At which point the secure loader is compromised and trustzone is worthless. Which renders most of the intellectual property worthless. This also likely blocks the encryption process as this is technically a secondary process?

[daveythacher]

Here is what I see when I read it. Image contains this:

• Blob of data
• Encrypted hash of data
• Key to decrypt hash
• OTP key unhashed

Steps:

1. Use blob of data to compute hash.
2. Use key to decrypt, encrypted hash.
3. Verify the hashes match.
4. Hash the OTP key and look for a match in OTP.

So ECC and SHA-256 are there for "entertaining" the bootrom.

[kilograham]

https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm

[kilograham]

Public key is in the binary Signature of hash of binary is in the binary Sha256 Hash of the public key is in otp

Bootrom simply checks that the binary hash is signed by a public key it accepts. Certainly the private key is neither in the binary (would be idiotic) or the otp (would require secrets to be handled by the bootrom)

[kilograham]

Actually re-opening because i do think the use of "encryption/decryption" in the description is confusing

[daveythacher]

I guess there is no point asking about random data being passed into the signature of the hash. Is any private key actually used?

[kilograham]

I guess there is no point asking about random data being passed into the signature of the hash

what do you mean?

Is any private key actually used?

The user uses their private key when signing the binary. There is no private information involved in the signature check.

[daveythacher]

Do you increase the complexity of the verification of the decryption? Do you use asymmetric keys or symmetric keys?

[daveythacher]

Are you going to issue an errata or wait for someone to compromise the loader? How much money did they put up?

[kilograham]

what on earth are you even talking about?

The "check of the signature of the hash" is a verification (using the public key included) that someone who had the private key signed the binary. We also check that the public key is allowed to be used. Still, no one who didn't have the private key could have signed the binary using the public key. If they sign it using a different key, then that key won't match the key hash in OTP.

[daveythacher]

The problem is asymmetric keys do not work like that. So you must have a symmetric key which you allow to be called public and private. (Unless you are using the private key as the public key, which degrades asymmetric keys to symmetric keys.) Therefor I can use a replay attack and the trusted boot loader is compromised. The kernel can be modified in the trusted world but the untrusted world. All the kernel priviledges and isolation counts for nothing.

Now I am guessing this is a joke put on for kids. This would not pass any real security review. It looks like there is no meaningful intellectual property or security measures on the RP2350 over the RP2040. Therefore my interest in the RP2350 is basically using the Cortex-M3 ISA, double the RAM and 25MHz of additional headroom.

[daveythacher]

The public key can be read by the private key only. (The public key has no read priviledges.) The private key can read itself and the public key. The private key is a trusted secret and usually is stored in TPM key store as root of trust. (I am simplifying the process.) The public key is different from the private key. Anyone with a public key can publish against the private key.

If you want to communicate with someone you hand out your public key. They will give you theirs which will allow you to send messages to them. This is just one piece of the puzzle. Skipping over all the issues and possible solutions to the central certificate authority system. They sign the public keys with the private so that only they can answer the question. In this case the OTP is the CCA.

So how does the OTP know the public key is real? You are telling me it is the hashed public key. Not the signed public key. Therefore I can grab a real binary by dumping the flash. Discover the key. Then hash it. Thus I know the OTP value. Now I can create new binary with the key. Thus the trusted world cannot be trusted.

[Quorth]

So how does the OTP know the public key is real?

Because the OTP contains the hash of the public key, and by collision resistance you can assume the key is to be trusted if its hash matches the one stored in OTP.

You are telling me it is the hashed public key. Not the signed public key.

Yes.

Therefore I can grab a real binary by dumping the flash.

Yes you can.

Discover the key.

Which is public.

Then hash it.

I guess you could.

Thus I know the OTP value.

Sure.

Now I can create new binary with the key.

Nope. To create a new binary you need the private part of the key, as it is the key used to sign (i.e. encrypt) the hash of the code and data images to provide authentication.

Thus the trusted world cannot be trusted.

Elephants cannot be trusted.

[kilograham]

Now I am guessing this is a joke put on for kids. This would not pass any real security review. It looks like there is no meaningful intellectual property or security measures on the RP2350 over the RP2040

you should be able to make an easy $10k then:

https://github.com/raspberrypi/rp2350_hacking_challenge

[daveythacher]

I guess we are left with this:

• Can you legally market this under ARM TrustZone?
• Is the OTP even secure?
• Is the bootrom running under TrustZone?
• I can expect an official disclosure after September 7?
• I am still capable of implementing my own secure boot loader? Or did you block me from this?
• Who assumes liability here?
• What threat level is available?

I get the following cause issues:

• XIP
• Limited Crypto functions
• Silicon hardening

[lurch]

Now I am guessing this is a joke put on for kids. This would not pass any real security review. It looks like there is no meaningful intellectual property or security measures on the RP2350 over the RP2040

you should be able to make an easy $10k then:

https://github.com/raspberrypi/rp2350_hacking_challenge

$20,000 now: https://www.raspberrypi.com/news/30000-badges-and-still-no-hack/

[daveythacher]

Alright I looked into it. (Thank you to who ever wrote picotool.)

• You do use the private key! (x, y and d) You create a hash and sign it with the private key.
• The signature contains two things: the public key (x and y, but not d) and signed hash.
• The hash is not encrypted and anyone can read it.
• You ensure the public key can never change. (Thus the private key can never change.)
• Assuming no one figures out how to piece together d, it may hold up.
• Who is doing this for 20K?
• This is asymmetrical.

So the bootrom will:

1. Calculate the hash.
2. Load the signature which contains the public key and hash signed by the private key.
3. Use the public key to extract the hash.
4. Compare the hash. (We proved the code did not change.)
5. Prove the public key matches the OTP's notion of the public key. (Thus the private key is still required and who made the code.)

Most of my other questions still apply.

[daveythacher]

I am guessing this was done for manufacturing security.

[lurch]

You create a hash and sign it with the private key.

Yes, exactly as Graham already wrote: "The user uses their private key when signing the binary."

[daveythacher]

Signatures are actually somewhat bad practice, if I am not mistaken. All three variables become observable. In this case you have no choice. The existence and role of the third variable was not explicitly stated. More people know the encryption process compared to the signature process.

Perhaps we can fix this? (Documentation and the limitation of the OTP.)

[daveythacher]

Want a joke: this->these

[daveythacher]

It would be fair to say the SDK will never change the preamble of an encrypted boot without an end of life notification? Out of fear of losing control over the private key used to sign the preamble, for which an unknown number of devices rely upon. Such actions would be explicit malpractice for which no liability is certified? It would also be fair to say that using encrypted boot with ARM TrustZone is highly encouraged?

Note I do not wish to drag this into another issue. The issue here is the private key of secure boot so it is close enough. Truth be told I am just throwing it out there in case it matters. I again redirect to this.