nokia-s40-self-signed-certificates

analysis of nokia's ext_info.sys file format

This is my analysis of nokia's ext_info.sys file format. This is a binary file format that is used to associate metadata with x509 certificates on (some?) nokia S40 (and maybe also some S60?) mobile phones.

Below, you can see the original ext_info.sys that gets generated by the mobile OS when I install my dustbowl.cer self-signed certificate. Below that is my modified ext_info.sys that was created by running the alter_ext_info_file script in the dustbowl project against the original ext_info.sys file. Because I only installed a single certificate into the user certificates directory on the device, the entire ext_info.sys file in these cases constitutes a single certificate record. I highlighted the different sub-segments of the file and included notes on the segments below the hexdumps.

Original ext_info.sys

00000000 80 00 01 00 01 43 02 10 00 00 14 00 02 dc 60 c3 |.....C........`.|
00000010 db 27 38 5b 72 af 1e 8f 00 a2 db 23 50 c7 ec 95 |.'8[r......#P...|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 d0 37 06 66 16 19 4b bc |.........7.f..K.|
00000050 04 94 ee 1b 3a e2 39 15 93 cc 39 78 00 00 00 00 |....:.9...9x....|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000070 0c 64 75 73 74 62 6f 77 6c 2e 63 65 72 00 00 55 |.dustbowl.cer..U|
00000080

Modified ext_info.sys

00000000 98 00 00 00 01 41 02 10 14 00 14 14 02 dc 60 c3 |.....A........`.|
00000010 db 27 38 5b 72 af 1e 8f 00 a2 db 23 50 c7 ec 95 |.'8[r......#P...|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 d0 37 06 66 16 19 4b bc |.........7.f..K.|
00000050 04 94 ee 1b 3a e2 39 15 93 cc 39 78 d0 37 06 66 |....:.9...9x.7.f|
00000060 16 19 4b bc 04 94 ee 1b 3a e2 39 15 93 cc 39 78 |..K.....:.9...9x|
00000070 0c 64 75 73 74 62 6f 77 6c 2e 63 65 72 00 18 06 |.dustbowl.cer...|
00000080 08 2b 06 01 05 05 07 03 03 06 0c 2b 06 01 04 01 |.+.........+....|
00000090 2a 02 6e 02 02 02 01 00 |*.n.....|
00000098

Notes:

  • Bold+Underline indicates a record-length prefix character.
    For the beginning of the record, this is the length of the entire record.
    For the certificate filename sub-record, this is the length of the filename.
    For the permission section, this is the length of the permission section.
  • Record Magic Number Prefix

    I am not sure what this magic number byte sequence is supposed to represent. After the record length byte, all certificates in the system ext_info.sys file (.../auth/ext_info.sys) begin with the 11-byte sequence in my modified ext_info.sys file. I believe it is necessary to modify these 11 bytes to this constant magic number byte sequence.

  • SHA1 Fingerprint of the Key

    This is always just the sha1 fingerprint of the key (this can be obtained by running sha1sum on the DER-formatted cer file). Do not change these bytes.

  • X509v3 Auth Key Identifier

    Note that I may be mixing up the Auth Key Identifier and the Subject Key Identifier segments. I cannot really tell because for a single-link cert chain, they will be equivalent. In any case, they are inter-dependent for the generation of this byte sequence. If authorityKeyIdentifier is present in the x509 v3 extension section then both sections are not-blank. If it is absent then both get set to all zeros (40 consecutive zeros). It is OK to omit Auth Key Identifier from your certificate by omitting an authorityKeyIdentifier entry in the openssl.conf file used to generate the certificate. Do not change these bytes.

  • X509v3 Subject Key Identifier

    Note I may be mixing up the Auth Key Identifier and the Subject Key Identifier segments. As stated above, if either the auth key or subject key identifier is undefined in your certificate, this will be all zeros. Having said that, I defined subject key identifier in my certificates because it was defined in the root certificates preinstalled on the phone. So do specify subjectKeyIdentifier=hash in the openssl.conf that you use to generate your certificate. Do not change these bytes.

  • sha1 hash of (part of) certificate subject?

    This appears to be another sha1 hash. I believe that this is derived from elements of the subject of the cert, but maybe only the CN of the cert subject is used? When the cert is determined to be invalid, the generated value gets set to all zeros. When the cert is recognized as valid is recognized as valid?) then this will be non-zero. I noticed that this value changes when you generate a cert with a different CN, and I played around with taking a sha1 of various parts of the subject segment of the certificate, but I could not figure out exactly what is hashed in this sha1 (if it is a sha1). It could be an HMAC auth tag using sha1 plus some secret key? More likely, it could be a sha1 of just part of the subject (maybe just the beginning or just the end N bytes where N is evenly divisible by the block size of sha1 -- 64 bits?). In any case, you do not need to change this segment.

  • sha1 hash of (part of) certificate issuer?

    I believe this is derived from elements of the issuer of the cert. For a basic single-link-in-the-chain self signed cert, issuer == subject, and you should copy the bytes from the subject section (the previous 20 bytes) to this section.

  • Name of the cert file

    This is the name of the certificate file, prefixed by a byte indicating the length of the filename. It is always followed by a 00 byte. Do not change these bytes.

  • Certificate Permissions

    If you look at the ext_info.sys file in the directory with the root certificates that are preinstalled on the phone and compare the permissions section to the permissions associated with each certificate when you browse (in the phone UI) to:

    Settings -> Security -> Authority Certificates -> [some cert] -> Select Use

    You will see that there is a magic number sequence associated with each of the 3 certificate permissions. I am including what I observe as the magic number that enables each segment:

    App Signing
    06 08 2b 06 01 05 05 07 03 03
    Cross Certification
    06 0a 2b 06 01 04 01 5e 01 31 04 01
    Server Authentication
    06 08 2b 06 01 05 05 07 03 01

    You will noticate that my modified permissions section ends in

    06 0c 2b 06 01 04 01 2a 02 6e 02 02 02 01

    I do not know what this is for exactly, but this is included in the permissions section of the preinstalled T-Mobile certificates on my phone that are used to sign the signed MIDlets that are preinstalled on my phone. I believe this sequence specifies that apps signed with this certificate should run in the operator protection domain (?)

  • Note also that the the length in bytes of the total certificate record must be zero-padded to a length that is evenly divisible by 4.
Comments