3

We have a commercial library that uses a public key to sign an XML request that goes up to our license server. The response that comes back is XML that has been signed with our private key, and the library then uses the public key to verify the response.

How do we handle the situation where the private key was compromised (intentionally or through a mistake)? We now need a new public/private key. However, people will not be willing to update their library for this case.

Should we have a property for the library that, if set, is the new public key to use? And then send that out asking people to update that setting?

Library is runnign on Java or .NET and the server end is .NET on Azure if that matters (likely doesn't).

Improve this question
1
  • Can you clarify your question? "uses a public key to sign an XML request" doesn't make any sense; public keys can't sign anything or everybody would be able to generate the "signature" and it would be meaningless. As for key rotation, without knowing what library you're using I can't tell you how to do it, but any half-decent crypto library will let you rotate keys. If your question is "how do I force users to upgrade", well, that depends on your upgrade story. You might be able to make it so old versions fail the licensing check, but that will burn goodwill.
    – CBHacking
    Commented Mar 3, 2018 at 0:01

2 Answers 2

Reset to default
1

When the private key is compromised, there are several things you need to do:

  • Stop using the private key (obviously): since other parties can now impersonate you using the leaked key, you should forfeit the key altogether.

  • Inform other parties (i.e. all your customers and users of your library) that the key was compromised: they should stop using the corresponding public key. How you do so depends on how you propagated the public key in the first place. If you used a KDC (Key Distribution Center) of any form, you should notify it of the leak and possibly revoke it if it lets you.

  • Generate a new pair and distribute the replacement public key to your correspondents and/or the KDC.

From your question, you seem to have a key distribution problem: you give the impression that your public key is distributed as an embed inside your library, so you can't easily prevent the usage of a compromised key's public part by your customers (apart from telling them to stop using your library, which is most probably a no-no).

If your question is pre-empting any leak (hopefully), you should redesign your library to acquire the relevant public key separately from being hardcoded. A simple scheme goes along these lines:

  • You may distribute the public key as a file (e.g. signed X.509 certificate) inside your library's installer. The installer should be responsible for installing the file as well as the library inside the guest OS and configure the library to use it.

  • You may distribute standalone installers for a public key file and similarly have it install (replace) the file inside the guest OS and configure the library to use it.

That way, in the event of a leak, your customers can receive a single, non-functional patch, which is usually much easier (much less risk to production) to get through approval than a full reinstall.

If you have the luxury to use a KDC, have your library periodically verify it uses the currently valid public key at disposal. KDCs usually are able to tell clients that the key they are using is valid or revoked, and also expose the currently valid one.

Remember that by having your private key leaked, you will suffer a hit on your customers' trust. Being able to swiftly and efficiently correct the situation will be paramount in keeping you on their good side.

Improve this answer
4
  • Is there any downside to having the public key as key=ABC... in the properties file (Java app) as opposed to a file. This loses the signed part of the public key, but is that critical? BTW - we have customers with no internet connection (highly secure government labs, nuclear power plants, etc)
    – David Thielen
    Commented Mar 3, 2018 at 21:02
  • Yes there is a significant downside, and you mentioned yourself: the key would just be a key, without any means of verifying its integrity and authenticity. Your library is responsible for verifying that the parameters of the communication channels it operates correspond to the specification -- in your case, if you need a trusted, secure and confidential channel, your library needs a way to authenticate the public key it is using before sending out encrypted information using that same key.
    – korrigan
    Commented Mar 4, 2018 at 17:13
  • @DavidThielen I note that you didn't mention that the server's response is encrypted. Although from your description, a lot of what you seem to need would probably be answered by TLS (e.g. via HTTPS). Do consider whether your licensing server would benefit from exposing a service via HTTPS (possibily requiring a client certificate for clients' authentication).
    – korrigan
    Commented Mar 4, 2018 at 17:17
  • @DavidThielen Finally, I don't know about your customers, but if they are secure labs and sensitive operations, they probably have requirements and policies w.r.t. cryptographic material, which would further influence your choice of implementation.
    – korrigan
    Commented Mar 4, 2018 at 17:18
1

Simple option: Use two public keys embedded in the library. One of them is used day-to-day, and the second is in offline cold storage. If key compromise necessitates a rotation, you can bring the offline key back online. Then you update the library before the next compromise.

More complex option: embed a certificate authority key. Keep it offline. In addition to the signed responses, include the public key (just like an HTTPS request). Verify the CA chain. (This need not be a commercial CA, you can run your own easily.)

Most complex and most flexible: combine both. Two CAs, offline cold storage in HSMs/Smart Cards for CA keys.

Improve this answer
1
  • We can't do anything that requires an internet connection, some of our customers are in very secure facilities with no internet. And 2 public keys allows 1 mistake, but then not a second.
    – David Thielen
    Commented Mar 3, 2018 at 21:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .