# Samsung .Cert File - Digging deeper

I don't know if I should ask this question in Android Stackexchange or here, but I am sure I am in a right place to ask.

My question is about following Samsung Certificate file:

File name: I9301I-357537065876500.cert

[cert]
Model=GT-I9301I
IMEI=357537065876500
SerNo=S200013955



A discussion that I found here says, this cert file is

Imei Cert Is RSA 512

Another users says:

Absolutely wrong! Imei cert is rsa 2048.

My question is how do I know if it is 512 or 2048 as well what are the steps to generate our own cert file according to these parameters given: Model IMEI SerNo

I found a description of the format of the public key here posted by Victor from Blagoevgrad at GSMHosting.com. As mentioned in the comments, both signature sizes are also 2048 bits, so that's pretty conclusive.

Here's the contents of the post of the information in the link:

#define RSANUMBYTES 256           /* 2048 bit key length */
#define RSANUMWORDS (RSANUMBYTES / sizeof(uint32_t))

typedef struct RSAPublicKey {
int len;                  /* Length of n[] in number of uint32_t */
uint32_t n0inv;           /* -1 / n[0] mod 2^32 */
uint32_t n[RSANUMWORDS];  /* modulus as little endian array */
uint32_t rr[RSANUMWORDS]; /* R^2 as little endian array */
int exponent;             /* 3 or 65537 */
} RSAPublicKey;


I found out that there is a modexp3 in the rest of the source code which is made more efficient using the n0inv and rr values, so the public exponent has value 3 (it seems missing from the structure, so I guess that part has been deprecated).

Possibly the confusion comes from the 40 00 00 00 hexadecimal value at the front; this encodes 64 when seen as little endian value. However, it doesn't mean 64 bytes: 64 * 8 = 512, but 64 words, where each word is 32 bits, i.e. 4 times as much giving 2048 bits.

This means that the modulus has the following value - in big endian:

93f0d9ad49d1dc8fb2445709b6210ba5a377c52f710e1e61458e84b2c53d69a4cb2aa2c914a7669230a6a81b69fbd558f11855a7adb29753a34a95e29b37a16d
509cab68883e54c88f50583d52a9bf4522d19344af4fe67d7a6163a4e7fc9b680602a691c487c55bc0c66125eb829125a78b47111da1f4a459a5d95bf1d879af
da7e3decb6a89207229cbd2839c5ccd0e26c6eb76598504de4478d883f1d68852275e2ee0296ed6f2eb6ff590005c5bcaa9f48b18437950a11d69e4373fc3f53


If I use the key (just using the modulus and public exponent 3) I find that the ImeiSign signature is a PKCS#1 v1.5 signature using SHA-1 as hash. Fortunately for Samsung, the IMEI itself will probably not be susceptible against SHA-1 weaknesses w.r.t. collision resistance.

I cannot seem to verify the IMEI with it though, probably due to some strange (BCD-like?) encoding of the IMEI number. Anyway, the SHA-1 hash within the signature is 824ae6730ee34d365375e791aa2331d5e57c320d in case you want to try a few things.

• I cannot reverse the PubKeySign signature, I expect that it has been signed with a Samsung specific private key, so it would require a different public key to verify. That's the whole idea behind a hierarchical PKI after all. Aug 2, 2021 at 21:05

This isn't any of the commonly used public key formats, but the PubKey section is 1040 bytes of hexidecimal. RSA public keys are formed of a "public exponent" and a "modulus", and the length in bits of the "modulus" is what defines the RSA key size (512, 2048, 3072, 4096, etc). The "public exponent" is usually rather small, 65537 (0x010001) is common.

So with 1040 hex characters (nibbles) being $$1040\ nibbles\times 4\frac{bits}{nibble}=4160\ bits$$ I'd guess that this is in fact a 4096-bit public key.

You cannot create your own certificate without a private key that the device will accept. Since you don't have access to that private key, you cannot create a valid certificate.

• I'm doubtfull, the pubkey could have more than n hiding there. The signatures are shorter. Aug 2, 2021 at 14:57