6
$\begingroup$

The titles says most of what we're confused with. Here's some details:

On an embedded device, we have a microcontroller and external flash memory. This memory can be easily read and written to in place. On that memory we store SSL certificates and a private key.

The microcontrollers internal flash memory is secure and can be used to hold fixed encryption keys, even uniquely generated so are only ever known inside the microcontroller. I cannot store certificates on the internal flash memory.

It seems obvious that the private key should be stored as encrypted but I am not so clear about the certificates.

What is not so obvious is if the certificates used to verify a TLS connection should be stored as encrypted to. It is likely that the root level certificates will be self signed and have no chain back to a verified root CA.

Thoughts?

Improve this question
$\endgroup$
7
  • $\begingroup$ This is an archtypal question new people would ask. I'll edit it a bit so that others can find it relevant. $\endgroup$
    – DannyNiu
    May 11, 2021 at 5:59
  • $\begingroup$ The cryptographic answer to this question is no. The IT security answer is more nuanced, and there are arguments towards storing the certificates obfuscated. Fortunately, that's off-topic. $\endgroup$
    – fgrieu ♦
    May 11, 2021 at 7:08
  • $\begingroup$ @fgrieu Had it been asked on Information Security yet? If so, a cross-reference would be awesome. $\endgroup$
    – DannyNiu
    May 11, 2021 at 10:54
  • $\begingroup$ @DannyNiu: the closest I find is this question which considers obfuscating certificates embedded in mobile apps. I know this is common practice: there are so many attacks trying (often successfully) to undo TSL encryption between app and server, using a proxy in the phone. I'm told there's a business in the evaluation of the "security" of mobile apps again such attacks, including some grading of the difficulty to identify and alter such embedded certificates, among other similar heresy from an academic crypto standpoint. $\endgroup$
    – fgrieu ♦
    May 11, 2021 at 11:21
  • $\begingroup$ @DannyNiu I could offer this question, which explains the difference between a certificate, a public key and a private key. $\endgroup$
    – MechMK1
    May 11, 2021 at 14:57

2 Answers 2

Reset to default
17
$\begingroup$

What is not so obvious is if the certificates used to verify a TLS connection should be stored as encrypted to. It is likely that the root level certificates will be self signed and have no chain back to a verified root CA.

As DannyNiu stated, there is no issue if someone were able to read the certificates; those are public information, and allowing an adversary to read them is not an issue.

However, there is a potential concern - what if an adversary can overwrite them? After all, an adversary who can do that could insert his own root certificate, and then establish a TLS connection (based on the root certificate he picked). This may or may not be a concern for you (can the adversary modify the flash, and then perform a negotiation?); if it is, one approach to prevent this would be to integrity check the certificate. That is, you would pick a random key, and put that into the internal flash memory; you would use that key to compute a MAC of your certificate; that generates a moderate sized (perhaps 32 byte) string, and write that string alongside the certificate in your external flash. Then, when it comes time to use the certificate, you would again compute the MAC of that on-flash certificate using the key, and check to see if the 32 byte string you computed was the same as the string that's stored in memory.

An attacker who tries to replace the certificate with his own is unable to compute the 32 byte string (because that depends on the key you have in secure storage); hence any attempt at modification will be detected.

Improve this answer
$\endgroup$
8
  • $\begingroup$ This answer addresses my concern of people being able to write their own certificates to the external flash memory. I thought about it so much I started doubting what I already knew! $\endgroup$
    – Ashley Duncan
    May 11, 2021 at 20:44
  • $\begingroup$ Addition: the next threat level is adversaries that overwrite certificates and workaround the protection afforded by the answer's MAC, either by removing the MAC check, or reverse-engineering the MAC key. Against that, an alternate line of thought in mobile app security (a black art which amount for a large part to sophisticated obfuscation) it to encipher the certificate, or disguises it with steganography in an effort to make detection more difficult. $\endgroup$
    – fgrieu ♦
    May 12, 2021 at 12:38
  • $\begingroup$ @fgrieu: I'm assuming that the MAC implementation (and the rest of the system) is secure. If it's not, then he could just replace the entire software system... $\endgroup$
    – poncho
    May 12, 2021 at 12:49
  • $\begingroup$ Don't most libraries match the certificate with the associated private key using information which is already both in the key and certificate? $\endgroup$
    – jcaron
    May 12, 2021 at 14:55
  • $\begingroup$ @jcaron: I was discussing the 'trusted root certificates', for example, what the Verisign certificate looks like. Obviously we don't have the private key in that case $\endgroup$
    – poncho
    May 12, 2021 at 15:51
11
$\begingroup$

Certificates that contains public-keys don't need to be encrypted, as the public-key algorithm ensures that nobody can "decrypt" public-key into private keys.

However, there's a special type of certificate: PKCS#12. This is actually less of a certificate format, and more of a cryptographic "keychain" - it's a complex format and can contain public-key certificates, private keys (encrypted and un-encrypted), and if I remember correctly, auxiliary information such as attributes, etc.

Improve this answer
$\endgroup$
3
  • 2
    $\begingroup$ Funny enough the certificates in PKCS#12 can be encrypted, e.g. the keytool / Java since version 9 creates a key / certificate store where the certificates are encrypted. If you can call 40 bit RC2 "encrypted" of course. However, you could also use AES (as long as the tools allow it - keytool doesn't). $\endgroup$
    – Maarten Bodewes ♦
    May 11, 2021 at 15:54
  • 1
    $\begingroup$ @MaartenBodewes: Java supports PKCS12 using RC2-40 on certbag back to j5 at least; it just became default in j9 up. So do OpenSSL and NSS by default (the latter not if FIPS mode, and I'm not sure about the former), Windows (always AFAICT), and the (recent) SMIME part of GPG. I don't know about Apple. $\endgroup$
    – dave_thompson_085
    May 12, 2021 at 2:24
  • $\begingroup$ Yeah, true, though they are expanding their ability to handle PKCS#12 gradually (glacier like, although I'm not sure if that's still a good analogy). It's a horrid standard, e.g. Java performed 3 entire password based key derivations at a 50K rounds minimum (the attacker obviously only cares about the minimum anyway). I think the general public has no idea that they are still using 3DES to protect their private keys either (fortunately the data is protected using HMAC). $\endgroup$
    – Maarten Bodewes ♦
    May 12, 2021 at 9:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.