2

I have an object which I need to transmit to clients and I need the clients to know that I actually created the object. Obviously, this process involves in me signing the object with my private key, so the clients can then verify it using my public key. The only problem which I have is that there is some processing in yet another application which changes some properties inside this object. This means that I cannot sign the whole object since verification will fail. However, what I really need to verify is the Payload, which does not change. The process which I followed is the following. Please let me know if this is the correct way of doing it and point out any security flaws which there might be.

  1. I added 2 properties in the object (SignedPayload and PublicKey)
  2. Create a public/private key pair
  3. Signed the Payload using the private key, and set SignedPayload
  4. Added the public key to the PublicKey property

The middle application will now be hit, and some properties are going to change, but, the Payload will not. Ultimately, the next steps will be done once the message is received on the client:

  1. Deserialized the message
  2. Verify the message using the PublicKey, Payload and SignedPayload properties. If the Payload has changed, or the public key does not originate from my organization, the message is ignored. This means that I have to sign the public key.

My main questions are:

  1. Is this approach secure?
  2. How do I sign the public key so the client can make a check that I am the owner of the key?
  3. From what I have read, it is common practice to transmit the public key when signing and verifying data. Is this correct?
  4. Is there something wrong with the approach of creating a key pair for every message, since I am always transmitting the public key? The reason for this is to avoid having to store the private key on the server, which can be hijacked.

Many thanks in advance.

  • I think you're misusing the acronym "PKI". What you most likely mean is "public/private key pair" – Stephane Oct 14 '15 at 8:54
  • Correct. I updated the question. – seedg Oct 14 '15 at 9:36
2

Unless you've left out an important element, tour approach seems to have a major flaw: you're checking the validity of the payload using the public key included with the same message.

Anyone could therefore forge a valid packet simply by generating a new key pair, signing the payload and the attaching the public key to the packet. That is why your first step should always to evaluate the validity of the public key.

This is usually done by placing the public key in a signed certificate describing the claim of identity of the originator and having that certificate signed by an authority trusted by the recipient.

As for your other questions:

Without going through a CA, how can I generate a PKI which I myself, can verify that I, and nobody else, has created that PKI?

Assuming you're simply misusing the acronym "PKI" to mean "public/private key pair" then you can't: you absolutely need to have a way to validate the public key in order to validate the message sender. Otherwise, as I described, anyone could create a packet.

That validation is what a CA is for: it allows the end user to tell that a given public key is owned by a specific security principal.

Another way of validating such a key is to use a key server: a system that hold the information linking a public key with a security principal. This could be used if you want to create a semi-anonymous transport system: if you do not want the recipient to be able to know who sent a specific payload but want it to be able to make sure it has the proper authorization and, at the same time, ensure that the central server cannot see the content of each payload. It doesn't looks like you're implementing that kind of system, though.

From what I have read, it is common practice to transmit the public key when signing and verifying data. Is this correct?

You need to provide the public key to the end user, yes. But common practice depends on what you're doing exactly. In most cases, you'll not only have the public key but also some form of digital certificate allowing the end user to validate the key itself (if you don not have another mechanism in place to validate that public key). In the case of TLS, the common practice is to transmit ALL certificates in the trust chain (up to the root) to the client so they can check the full chain even if they are missing an intermediate certificate.

Is there something wrong with the approach of creating a PKI for every message, since I am always transmitting the public key?

Not as such but creating a key pair is a delicate and resource-intensive operation. Unless absolutely necessary, it isn't typically implemented that way.

  • As I said, I also want to verify that I am the owner of the public key, so I guess that I have to sign it using a CA. Regarding creating a key pair for every tranmission, this is to avoid having to store the private key on my server, since if it is hijacked, all transmissions will not be secure until the private key is changed. What would you recommend in this case, creating a pair each time? Or storing the private key on the server's hard drive? – seedg Oct 14 '15 at 9:23
  • Please correct your question: you're not using "PKI" correctly and that is making it quite confusing – Stephane Oct 14 '15 at 9:24
  • Done, I also updated the questions. – seedg Oct 14 '15 at 9:32
  • generating new key for each packet will not protect you if your server is breached: the attacker will not automatically gain the ability to create new valid packets. In fact, you're making it harder to validate each individual packet since you have to trut a new key each time and have to keep track of them. For optimal security, best is to use a hardware key storage (HSM). – Stephane Oct 14 '15 at 9:52
  • Right, so I should generate one key pair and protect the private key. I can self sign this key in order for the client applications to know that I am the actual sender correct? – seedg Oct 14 '15 at 9:55

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.