Best Practices for Storing Digital Certificate

Question

I'm building an application where certain sensitive files need to be digitally signed before being stored in the file system using ASN.1 encoding, so they can be verified against a digital certificate (the one corresponding to the private key used for signing) at a later point in time when they're accessed. I'm using the Bouncy Castle library for Java.

There's a disagreement between members of my team regarding the best place for storing the digital certificate, and I'd like to know what's the best practice:

• Storing the file contents, the signature and the certificate packaged together in a CMSSignedData object. In this way, the verification procedure only needs to receive the CMSSignedData object, as all data needed for performing the verification is present in a single object.
• Storing only the signature and the file contents in a CMSSignedData, and storing the certificate elsewhere. Using this approach, some extra work is needed for managing the certificate and relating each signed file to the certificate needed for performing the verification.

I'm worried about the first approach, I believe someone could package and save the file contents, a certificate different from my own and a signature generated with the private key corresponding to that certificate - and the verification would succeed, because the verification procedure didn't receive the "original" certificate but a fake one.

What do you recommend? Do you see any shortcomings or potential problems in either one of the alternatives mentioned above? what's the best practice, or should I use an entirely different approach?

Answer 1

The first approach is better. Your concerns are misplaced. In the example you give, the verification should succeed. The data was indeed signed by the certificate it claims to have been signed by.

If I sign some document, then it's very important that it only appear to have my signature if it hasn't been tampered with. But if you can tamper with it but then have to put your signature on it, that's fine. You did sign its contents. I didn't, but it doesn't appear to have my signature. So that's fine.

You still must decide what that signature means of course after you decide it's basically valid. But that should be considered a separate step.

The design should be based on the fundamental security principle that an untrusted attacker cannot obtain the private key corresponding to the public key authorized by any certificate the system would accept as valid. Generally, it will be based on the common name in the certificate and the identity of the authority who signed it.

You can safely store the data, certificate, and signature together. This will allow you to validate the data and signature. The important thing is that you properly decide what that validation means by looking at the certificate.