2

I am building a system comprising of 3 parts. System A, system B, system C.

System A cannot directly talk to system C and needs to go through system B. System B may contain many System Cs. One more concern here is that it's possible for system B to create a copy/clone of itself and have it be included under itself (as a system C).

I would like to broadcast messages to all system Cs from system A. System B contains a list of all system Cs that it encapsulates. I would like to add logic in System C wherein only messages originating from system A are considered as valid (and hence marked as safe for further processing).

As a first cut I was thinking of having a private key negotiated via the diffie-hellman algorithm. But realized that system B can create a copy of itself, have it be included as an instance of system C and obtain the private key. Is there a better/standard way to do this such that the veracity of the source can be verified on the system C's side?

shreyasva
  • 13,126
  • 25
  • 78
  • 101
  • The scenario you speak of where system C filters in only messages from A cannot exist, if A cannot talk to C, only through B. Unless I'm missing something? – St.G Dec 28 '15 at 23:58

2 Answers2

1

Sounds to me like a simple private/public key for every system A is all you need.

DH is not involved in this at all.

System A creates the keypair. System A uses its secret key to sign the hash of the message and sends it out through as many system Bs as needed. System B cannot change the message nor derive the private key, so all they could do is not pass on the message or replay them (you'll need precautions for those if that's a problem). System C needs to verify the signature of A on the message it either knows the public key of system A somehow, and verifies the signature.

To have more than one system A, it quickly becomes impractical to have (all) system Cs know all System A public keys, to solve that you create trust in a certificate authority (CA) that signs certificates for system As, and system C then trusts signed certificates by that CA. (it doesn't need to be online nor need to be able to talk to the CA to do that, the trust can easily be offline).

If you do go for an offline thing, take care that the keys (and/or certificates) might need to get updated, so foresee a mechanism for that.

As you see B is merely a transport in it all.

  • Seems like the right directions. What is the need to have multiple system A public keys? Assuming that there is only 1 system A, I can see a need for only 1 public key. – shreyasva Jan 03 '16 at 06:59
  • If you have only one system A, you only need one certificate or keypair indeed. But certificates do expire and keys might need be replaced after time, so you still need to anticipate that –  Jan 03 '16 at 20:06
0

If there is nothing shared ahead of time, there is no way for a C to distinguish between messages that come from A and ones that come from a B who wants to impersonate an A. In your case, a shared secret key won't work, since that would allow B to forge messages. So you'll need something like a public key for A that B and C can use to verify messages, but which only A can use to create/sign messages.

bmm6o
  • 6,187
  • 3
  • 28
  • 55