Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
1  
You seem to be confusing the certificate with the private key. It's the private key that needs to be protected, not the certificate. The certificate is needed for verification, not the private key. –  David Schwartz May 19 '12 at 9:46
    
@DavidSchwartz there's no confusion, the question is: where should I store the certificate for performing validations later? For instance, in the first approach 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 –  Óscar López May 19 '12 at 12:05
    
If the verification succeeding in that case is a problem, then something is very fundamentally wrong in the design. All the verification checks is that the claimed data was signed with the claimed certificate. It was in that case. So the verification should succeed. (It's bad if someone can change my contract and leave my signature on it. But if they have to replace my signature with their own to change the contract, then that's fine. It's not my contract, but it doesn't even appear to have my signature. So no problem.) –  David Schwartz May 19 '12 at 12:14
    
@DavidSchwartz I rephrased my question –  Óscar López May 19 '12 at 12:16
    
How would an attacker get his hands on a private key that corresponds to a certificate the system would consider valid? Wouldn't the system just say "that's not a certificate signed by any authority I recognize" and reject the data? –  David Schwartz May 19 '12 at 12:23

1 Answer 1

up vote 5 down vote accepted

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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