2

Automated signing of files, such as software packages or file backups, is inherently risky if a certain level of trust is given to it. Having signing be an automated process means that there's no user sitting by and verifying the files themselves.

That being a given, what are steps that can be taken to increase confidence in automated signatures?

Other than mandatory access control and basic securing of a Linux machine, what else can be done?

  • 1
    The use case is somewhat unclear. Who (or what) trusts your auto-signed files? Why do you want to take a human out of the loop? Do you use HSM to store the private key? – Deer Hunter Mar 10 '16 at 5:54
1

Typically, you have two vectors here.

  1. Loss of the Private Key
  2. Unauthorized use of the Private Key

Generally, some hardware backing is recommended to address #1, such as an HSM, SmartCard, or other physical crypto device.

These devices also typically have some from of access control, ranging from IP ACLS with passwords, all the way down to a pin with small retry counts.

As a general rule, you need to be restrictive on what can access the PK for signing, for example, if jenkins builds your software, then signs it, only allow jenkins processes to access the PK, additionally all signing could be performed on a seperate jenkins slave, which is as isolated as possible from everything else.

However, as we all well know, damage control is almost as important as the attempts made to prevent damage. One should ensure he/she has a way to revoke the signing key should it become compromised, and plans to replace and transition cleanly.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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