Where to Store The Private Key on a Digital Signing Server

Where to store the private key on a digital signing server?

Option option is to use a setuid binary which runs as a different user to do the certificate signing.

This other user would have read-access to the key, but the "Normal" app-server user would not have read-access. Therefore if someone compromised the app server's account, they would only be able to sign arbitrary certificates, not steal the CA private key.

Another possibility would be to have some RPC mechanism to pass the signing request to another process running as another user, possibly on another host. Or another VM on the same host (but not inside the app server machine).

Any of these approaches just reduce the impact of a compromise, but it's still bad.

Is it okay to store a digital signature and the public key of the signatory inside a json file?

Yes. As long as your private key remains undisclosed, storing your public key along with a document signed by the private key is safe.

In the SAML2.0 system for federated user authentication and authorization, the Assertion tokens they use are signed with a private key. Those Assertions are XML documents, containing both the crypto signature and the public key. The public key is the base64 encoded version of the X.509 public key in that system.

Of course, a recipient should validate the signature with its own previously stored copy of the public key. If a recipient validates the signature with the public key in the document, it's vulnerable to spoofing. A bad actor could sign a malicious document with their own private key, and send along their own public key. The signature would match, but prove nothing about the origin of the document.

How the public key can be ensured being from sender in the digital signature security model?

Yes, the authenticity of public keys is a key component of applied cryptography. I can issue a public key that says "I am the website of your bank, trust me", but you shouldn't really trust it. Different schemes have been developed to establish authentication of public keys. One approach is the web of trust model in PGP and GnuPG, others are PKI and Kerberos. One of the main difference between these approaches is where you place your trust. I provide a simplified description only, you have to read about them to learn about the exact details (you wouldn't base your security on an extremely short summary, would you?).

In the web of trust there are some people who you trust, and you (ideally) verified their public keys personally. You can trust other public keys if they have been signed by several people bearing your initial trust. Using these trusted individuals you can check more and more keys.

In PKI (Personal Key Infrastructure) you trust several Certificate Authorities (CAs) and accept their public keys. You trust them that they thoroughly check the identity of key holders before signing their public keys. The combination of public key + signature from a CA (and some other data) forms a certificate. The PKI is used in SSL/TLS, it is the underlying infrastructure of the secure web. You use it when you read your mail on a web interface, when you do online banking, etc. If a CA is compromised, then every certificate signed by the CA will be come insecure.

In Kerberos is designed for computer networks and the key server is the single point of trust. It provides mutual authentication and a unique symmetric encryption key for clients and servers. The key server checks the identity of clients by a secret shared only between the key server and the client. Kereberos is used, for example, in Windows, AFS, Grid computing.



Related Topics



Leave a reply



Submit