Can I use a certificate w/ a S/N not starting w/ 3CC3 as Verification cert for an LPC secure boot?

[nicolaponzevero]

Hi All,

According to what I read in UM11126 rev 1.8 section 7.3.2.1.2

The x509 serial number field in the image signing certificate is used the following way: byte 0 shall be 0x3c, byte 1 shall be 0xc3, byte 2 and byte 3 form an unsigned 16-bit integer
whose value is compared with the IMAGE_KEY_REVOKE value in the PFR. On
mismatch, the image authentication process will fail. 

So it seems that there is a mandatory prescription to use a seral number for the Image verification certificate tat matches a pattern 3C C3 NN NN XX XX XX...

Unfortunately the Certificate authority server I need to use to issue this certificate do not allow me to freely set the certificate serial number, but generate a serial number according to its internal logic. This serial number won't match the pattern reported above.

We are not planning to use the revocation mechanism for the image certificate.

We definitely hope that the reason why you introduced the 3cc3 prefix is to address our use case i.e. that any certificate whose serial number does not begin w/ 3cc3 eventually cannot be revoked, but can be still safely used for the software authentication. Can you confirm or deny this is the case?     

Thanks in advance and regards
Nicola

[Alice_Yang]

Hello @nicolaponzevero 

What  IMAGE_KEY_REVOKE   value did you set in Certificate and FPR?

BTW, what is your application?

BR

Alice

[nicolaponzevero]

Hi Alice, thanks for your answer,

I edited the original question and this follow-up hoping to make them clearer.

Our problem is that we are almost forced to use a specific corporate server as our Certificate authority to issue the LPC Image verification certificate, and this server does not have the option to let the operator set the Serial number but sets automatically a value for the S/N that as you can understand won't have the requested format "3cc3...".

We are trying to understand if we can issue an usable Image verification certificate for the LPC55sXX by relying on our existing process and CA server (that will result in issuing a cert w/ an arbitrary s/n) or we are forced to invest in setting up an entirely new process able to generate a compliant LPC image verification certificate (w/ S/N of the form 3cc3...).   

As far as I can imagine the information we requested should be more easily found by reading the documentation of the LPC55sXX boot ROM more than than from examining our application or our tests, anyway - while I ask you to focus on the above request if possible -  I'm adding below the information you requested.

Thanks and regards

Nicola

--------------------------------------------------------------------------------------------------------------------------

1) our application is a set of embedded devices with some security feature (using cryptography) based either on LPC55s69 or LPC55s66. All must have the secure boot enabled (boot only signed software).

2) the IMAGE_KEY_REVOKE field in the CFPA section of the PFR during our test was 0 (zero).  

3) the S/N used for the image verification certificate in our test was (in ascii/hex) 010203040506070809
This means 0102 in place of the 3CC3 "Magic number" and 0304 (1027 dec) as the "counter" field, followed  by 5 bytes 05:06:07:08:09 in place of the multiple AB values proposed by the secure provisioning tool. Just in case I append below the certificate dump. All the certificate fields but the serial number came from an equivalent certificate generated by the provisioning tool that generated also the roots and their hash. The signature have been recalculated and confirmed to be correct by verifying it on a pc.

C:\workspace>openssl.exe x509 -text -inform der -in IMG1_2_sha256_2048_65537_v3_usr_crt.der
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
01:02:03:04:05:06:07:08:09
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = ROT1_sha256_2048_65537_v3_ca
Validity
Not Before: Aug 24 13:31:49 2023 GMT
Not After : Aug 21 13:31:49 2033 GMT
Subject: CN = IMG1_2_sha256_2048_65537_v3_usr
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:e8:94:a4:42:06:60:35:ce:75:35:31:91:77:20:
87:28:74:47:89:75:0a:74:df:09:5d:09:40:db:bb:
51:b3:60:e7:53:86:61:a8:f7:65:bc:de:5f:ee:af:
70:aa:fb:00:ab:40:3e:bf:b7:6f:6b:b6:0f:99:f6:
f8:84:6a:74:82:0f:0a:78:4f:62:20:1e:a1:1b:fe:
7c:b7:fa:fb:50:6d:62:e1:14:a7:24:b4:9e:38:ab:
f5:22:a4:fd:03:4a:02:fd:d4:72:eb:ac:8d:26:31:
27:65:db:0a:1a:03:ae:5e:7b:c4:7c:e4:76:89:df:
82:08:c2:2d:65:90:c1:bd:05:7a:ea:93:71:a6:25:
9b:73:d7:d4:78:75:3a:93:92:d2:64:54:4d:92:08:
df:41:e2:85:f5:91:fa:7c:1b:d1:77:1e:e7:ef:2b:
4d:76:be:ad:50:2e:11:8d:f4:54:c4:7b:16:25:03:
0c:b6:39:3b:e5:b4:7c:52:2f:df:6c:a9:f0:01:7a:
60:64:1c:7b:c1:42:a4:6a:cb:ee:4c:e1:07:8a:5c:
fd:89:91:38:f3:58:c2:bf:52:a5:81:dc:f8:55:9e:
b8:8f:db:74:47:d9:34:4b:0b:e5:c2:58:35:7a:41:
c5:45:6f:c6:1c:ea:73:0c:55:af:07:d6:85:1e:25:
c6:ed
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
DirName:/CN=ROT1_sha256_2048_65537_v3_ca
serial:3C:C3:00:00:AB:AB:AB:AB

X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
Signature Algorithm: sha256WithRSAEncryption
6c:44:02:ff:34:4d:6a:e5:76:61:22:3e:14:5d:a6:9b:3a:80:
24:37:9c:72:2d:73:71:0a:64:db:3e:75:31:a5:72:2d:ea:46:
d3:c2:51:69:ba:1b:4a:45:99:c7:de:21:c2:49:2b:26:ef:b6:
d3:5c:e1:a0:60:39:f8:49:e5:ea:36:db:74:d4:f5:4e:35:d0:
59:34:dd:15:62:b2:21:fd:ae:c0:52:1d:90:96:2a:15:89:85:
70:34:92:92:94:8b:57:86:92:4f:80:dd:2b:5d:a2:02:11:bb:
eb:23:33:fd:3c:2e:78:87:91:83:95:72:e8:ed:7b:aa:1f:09:
48:2c:fe:45:3c:23:6b:51:51:ca:5d:fe:f5:fe:03:01:23:9d:
ff:fb:f8:25:1f:9f:31:c7:64:11:29:3c:e4:44:30:96:cb:b9:
d4:ce:aa:12:26:a3:50:6d:06:ef:8e:b8:fe:46:a3:03:0f:32:
d0:4b:62:4f:01:3e:cb:81:be:70:68:64:47:ee:d3:2f:c7:32:
26:6b:0c:20:25:a7:5f:fa:eb:62:19:08:15:6a:0a:18:3e:45:
ec:ae:a0:23:82:4c:e3:2f:14:78:c8:7b:0d:07:72:14:60:57:
a3:90:4b:91:58:aa:85:f9:74:52:fa:0c:2c:65:05:3c:68:e0:
8c:2e:da:b8
-----BEGIN CERTIFICATE-----
MIIDMDCCAhigAwIBAgIJAQIDBAUGBwgJMA0GCSqGSIb3DQEBCwUAMCcxJTAjBgNV
BAMUHFJPVDFfc2hhMjU2XzIwNDhfNjU1MzdfdjNfY2EwHhcNMjMwODI0MTMzMTQ5
WhcNMzMwODIxMTMzMTQ5WjAqMSgwJgYDVQQDFB9JTUcxXzJfc2hhMjU2XzIwNDhf
NjU1MzdfdjNfdXNyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6JSk
QgZgNc51NTGRdyCHKHRHiXUKdN8JXQlA27tRs2DnU4ZhqPdlvN5f7q9wqvsAq0A+
v7dva7YPmfb4hGp0gg8KeE9iIB6hG/58t/r7UG1i4RSnJLSeOKv1IqT9A0oC/dRy
66yNJjEnZdsKGgOuXnvEfOR2id+CCMItZZDBvQV66pNxpiWbc9fUeHU6k5LSZFRN
kgjfQeKF9ZH6fBvRdx7n7ytNdr6tUC4RjfRUxHsWJQMMtjk75bR8Ui/fbKnwAXpg
ZBx7wUKkasvuTOEHilz9iZE481jCv1Klgdz4VZ64j9t0R9k0Swvlwlg1ekHFRW/G
HOpzDFWvB9aFHiXG7QIDAQABo1wwWjBABgNVHSMEOTA3oSukKTAnMSUwIwYDVQQD
FBxST1QxX3NoYTI1Nl8yMDQ4XzY1NTM3X3YzX2Nhggg8wwAAq6urqzAJBgNVHRME
AjAAMAsGA1UdDwQEAwIE8DANBgkqhkiG9w0BAQsFAAOCAQEAbEQC/zRNauV2YSI+
FF2mmzqAJDecci1zcQpk2z51MaVyLepG08JRabobSkWZx94hwkkrJu+201zhoGA5
+Enl6jbbdNT1TjXQWTTdFWKyIf2uwFIdkJYqFYmFcDSSkpSLV4aST4DdK12iAhG7
6yMz/TwueIeRg5Vy6O17qh8JSCz+RTwja1FRyl3+9f4DASOd//v4JR+fMcdkESk8
5EQwlsu51M6qEiajUG0G7464/kajAw8y0EtiTwE+y4G+cGhkR+7TL8cyJmsMICWn
X/rrYhkIFWoKGD5F7K6gI4JM4y8UeMh7DQdyFGBXo5BLkViqhfl0UvoMLGUFPGjg
jC7auA==
-----END CERTIFICATE-----

[Alice_Yang · Accepted solution]

Hello @nicolaponzevero 

I confirmed with our SE, yes, the seral number for the Image verification certificate must matches a pattern 3C C3 NN NN XX XX XX...

BR

Alice

[nicolaponzevero]

Hi Alice,

thanks for your help. 

Your answer was unambiguous, and I already accepted it as a solution.

Anyway, if possible, I would like to take advantage of your kindness and ask you to spend a few more minutes with your SE to ask him why using the certificate listed above (having a non compliant S/N 010203040506070809) our EVB booted even if its processor's PFR was correctly configured for performing the the secure boot (also confirmed by several tests).

Thanks again and regards

Nicola