3

I plan to put an SSH server on micro-controller devices. There shall be many devices distributed in a wide range.

The identity of the server is checked with the server key. The server needs to store the private key to allow the authentication. When I copy the private key to all micro-controllers I have to generate the private key elsewhere (e.g. at my PC). This copy of the private key can be thieved.

It would be more secure when the server generates a key pair and the private key will never be copied from the micro-controller.

  • How can I check that I am connected to a server and not to a man in the middle?
  • How should I distribute this information to all clients?

The server should work standalone without a hierarchical trust infrastructure.

Edit: The microcontroller has a one-time programmable storage for one public key and built-in routines to verify a signature. There could be added a trusted platform module for private keys. But if the devices share a common private key it would be necessary to replace the key pair in all devices when the private key gets compromized. Since there is no obviously visible way to update the private key using a connection "secured" with a compromized private key it should be avoided to share the private key.

  • The answer may depend on the SSH server used on your devices. OpenSSH for instance allow keys to be signed by a trusted authority, as are certificates, which removes the possibility of a man in the middle. – WhiteWinterWolf Feb 9 '15 at 10:43
  • What does hinder the MITM to have it's own signed key? – harper Feb 9 '15 at 11:14
  • 1
    Do you maintain control over the micro-controller devices? Can a third-party acquire a copy of the private key from a micro-controller or is the vulnerability only the generated version you have on your own PC? Do all the micro-controller share the same private key? – M'vy Feb 9 '15 at 13:08
1

It's impossible to create a PKI when the server cannot be trusted somehow. You can generate the asymmetric key pair on the server, but you would still have to trust the public key of the key pair. Otherwise the private key may be secure, but you wouldn't know what private key to trust.

So what you should do is to create separate key pairs for each trusted device. Then you should trust the public key of the key pair. This should be performed in a secure environment. You should not distribute the private key to multiple devices as you suggest in your question.

  • 1
    When I have some hundred of servers how should I manage the public keys in the clients? It would be necessary to update the public key list at all clients when I add a new microcontroller device. – harper Feb 12 '15 at 9:38
  • PKI usually uses a tree structure, you only have to trust the public keys. The keys may be send when they are needed. Usually the keys are put in a certificate of sorts and signed by a key higher up in the hierarchy. That leaves you with certificate revocation, which can be handled by an online protocol as well (OCSP). – Maarten Bodewes Feb 12 '15 at 9:42
0

Depending on the chipset and board design and motivation of an attacker to go to the effort you should assume that everything on the micro is public knowledge.

If there is potential significant financial gain to be made from breaking this system then additional hardware steps should be taken last thing you want is someone to simply connect a jtag programmer onto your board in situ or go to the effort of desoldering a 256 pin micro to be able to insert their own key into it. And then potentially break open the whole network

Is your planned design supposed to "phone home" or only receive commands ?

I have seen absolutely insane ( successful ) attempts at hardware mods which have in effect destroyed thousands of dollars worth of hardware in failed attempts or simply research in attempts to crack video game consoles

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.