Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mbedtls_x509_crt_info produces non-printable output for binary HardwareModuleName SAN extensions #6262

Closed
Kabbah opened this issue Sep 6, 2022 · 1 comment · Fixed by #6265

Comments

@Kabbah
Copy link
Contributor

Kabbah commented Sep 6, 2022

Summary

mbedtls_x509_crt_info produces non-printable characters if the certificate contains an RFC 4108 HardwareModuleName (as a Subject Alternative Name extension) whose hwSerialNum has non-printable bytes.

This happens because the code assumes the hwSerialNum is made of printable characters and simply does a memcpy directly to the output. In fact, RFC 4108 specifies that the ASN.1 type of hwSerialNum is OCTET STRING, which basically permits any arbitrary sequence of octets. The RFC does not impose any other structure or encoding on the serial number.

System information

Mbed TLS version (number or commit id): 52f83dc
Operating system and version: Manjaro Linux 21.3.7
Configuration (if not default, please attach mbedtls_config.h): default
Compiler and options (if you used a pre-built binary, please indicate how you obtained it): gcc (GCC) 12.1.1 20220730, default options
Additional environment information: None

Expected behavior

In order to print binary hwSerialNums, we'd have to encode them into a printable format (hex for instance).

I generated this test certificate with a binary hwSerialNum (3132338081008180333231 in hex):

-----BEGIN CERTIFICATE-----
MIIBwTCCAWagAwIBAgIBTTAKBggqhkjOPQQDAjBPMQswCQYDVQQGEwJVSzERMA8G
A1UECgwITWJlZCBUTFMxLTArBgNVBAMMJE1iZWQgVExTIG5vbi1wcmludGFibGUg
b3RoZXJuYW1lIFNBTjAeFw0yMjA5MDYxNTU2NDdaFw0zMjA5MDMxNTU2NDdaME8x
CzAJBgNVBAYTAlVLMREwDwYDVQQKDAhNYmVkIFRMUzEtMCsGA1UEAwwkTWJlZCBU
TFMgbm9uLXByaW50YWJsZSBvdGhlcm5hbWUgU0FOMFkwEwYHKoZIzj0CAQYIKoZI
zj0DAQcDQgAEN8xW2XYJHlpyPsdZLf8gbu58+QaRdNCtFLX3aCJZYpJO5QDYIxH/
6i/SNF1dFr2KiMJrdw1VzYoqDvoByLTt/6MzMDEwLwYDVR0RBCgwJqAkBggrBgEF
BQcIBKAYMBYGBysGAQQBEQMECzEyM4CBAIGAMzIxMAoGCCqGSM49BAMCA0kAMEYC
IQDATir07PTj5gtf+HAyI+nd27AH9+bdaWdOI2t2bAwUWgIhAO7kvdcsa++yfJdT
3vnWdvcHRIAdXA0kh+mcBMaXk9B0
-----END CERTIFICATE-----

The expected output of mbedtls_x509_crt_info should then be:

cert. version     : 3
serial number     : 4D
issuer name       : C=UK, O=Mbed TLS, CN=Mbed TLS non-printable othername SAN
subject name      : C=UK, O=Mbed TLS, CN=Mbed TLS non-printable othername SAN
issued  on        : 2022-09-06 15:56:47
expires on        : 2032-09-03 15:56:47
signed using      : ECDSA with SHA256
EC key size       : 256 bits
subject alt name  :
    otherName :
        hardware module name :
            hardware type          : 1.3.6.1.4.1.17.3
            hardware serial number : 3132338081008180333231

Actual behavior

The actual output of mbedtls_x509_crt_info is

cert. version     : 3
serial number     : 4D
issuer name       : C=UK, O=Mbed TLS, CN=Mbed TLS non-printable othername SAN
subject name      : C=UK, O=Mbed TLS, CN=Mbed TLS non-printable othername SAN
issued  on        : 2022-09-06 15:56:47
expires on        : 2032-09-03 15:56:47
signed using      : ECDSA with SHA256
EC key size       : 256 bits
subject alt name  :
    otherName :
        hardware module name :
            hardware type          : 1.3.6.1.4.1.17.3
            hardware serial number : 123��

Also note that the 0x00 in the middle of the hwSerialNum ends up NULL-terminating the whole thing, causing any following characters not to be printed.

Steps to reproduce

Save the certificate above as a file and run the sample program: programs/x509/cert_app mode=file filename=path/to/cert.crt

Additional information

I already implemented the hex conversion locally. If we agree on changing the format of the hardware serial number in x509_info_subject_alt_name to hex, I can submit a pull request.

@paul-elliott-arm
Copy link
Member

Hi!
I agree with you that the spec says this is an octet stream, and therefore invite you to push your PR
Many thinks,
Paul.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants