This question might very well be more a confirmation than anything else, but I'm breaking my head over a problem I try to solve. I hope someone can either confirm my thoughts or tell me something I'm missing.

We are trying to setup a secure environment on an existing system (I'm aware this is not the way to go, but companies..) and the problem I have is the following:

Tool A is used to update system B, system B does currently not contain any keys for a secure exchange. The update system B is receiving will contain keys to make secure exchange of information and future updates possible. This will be in plain text as system B isn't aware of any secure protocols.

The interface used to transfer the update to system B should be considered not secure, and could have a potential listener.

Would there be any way of securing system B without the key leaking? So far the only solution I can think of is securing the environment of system B while transferring the software. This limits the possibilities heavily on updating system B, is there another solution?

Summary: We move from a not secure way of updating to a secure way of updating, the problem we face is the first update will contain secure data send on a non-secure way. Is there a way around this?

  • Do you have physical access to system B?
    – Ella Rose
    Commented Nov 4, 2019 at 15:07
  • The person updating does, sharing this update to others is the main issue. As this compromises future updates if someone picks the initial key from the update.
    – Light44
    Commented Nov 4, 2019 at 15:13
  • What about using TLS to download the keys? Almost every system will have TLS API (curl on Linux/iOS, PowerShell on Windows).
    – ThoriumBR
    Commented Nov 4, 2019 at 18:33
  • We are talking embedded systems & CAN bus interface.
    – Light44
    Commented Nov 5, 2019 at 7:07

1 Answer 1


If you start off with an insecure system you can only secure it first. It seems however that you start off with a secure system for which the communication is not trusted.

Any initial operation you perform can be repeated by an attacker. You can only escape this if you have either a shared secret, a private key for which the public key is trusted, or a trusted public key of the other party already installed.

As this doesn't seem to be the case, the only thing you can do is to mitigate things. You can send an update to the system that implements DH key agreement. Then you let both systems generate a DH key pair and perform the key agreement. The resulting keys derived from the shared secret can then be used to keep messages confidential and authenticated.

The problem with the above approach is that an adversary can perform the same update or provide their own key agreement. Now the fact that anybody can do the update cannot be mitigated. However, you can include the public key used for the key agreement in the update itself. That way there is a (semi-?) trusted public key available for the system, and the resulting secret is known to be correct.

Of course, that will still leave the server guessing if the shared secret is from the previously insecure system or an adversary. You can mitigate this fact by including using a random update ID in the key derivation, and make sure that this ID can only be used once. That way all the security is just dependent on the update, so as long as that's secure - and the key agreement is performed immediately - then you're in the clear. If there is a system ID of the insecure system, use that in the key derivation as well - the more dependencies the harder it becomes for an adversary to mess with the system.

In any next system you design / roll out, always include a public / private key pair into the system and trust the public key in the server. Also include a trusted public key of the server. That way you've got a good way of bootstrapping security once it is required.

Any way you can introduce trust can of course be utilized. For instance, you can send out engineers with their own trusted private keys and use that to initially set up trust for the system. Humans may be better at estimating the initial security of the system after all (if the computer is in the basement of a hacker then it is probably not secure).

  • These solutions are mainly obscuring whats going on, correct? As the update is done over the same channel as the other communication there is nothing that can't be mirrored by another party.
    – Light44
    Commented Nov 5, 2019 at 7:19

You must log in to answer this question.

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