Correct way of signing and verifying a message

Question

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.

Answer 1

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.