0

Assume that I want to sign digitally updates for an offline appliance (lets say a limited linux VM). To begin with, such mechanism is not in place and the very limited OS doesn't have any CA certificates. Secondly, any update can be uploaded only with removable media, so no Internet connection.

This scenario creates an already unsafe state, that I want to upgrade to a safer state. In this case I want to verify and authenticate my code to the appliance. We can assume that a certificate is not necessary (or maybe not?), since to begin with there is no a CA established (and not accessible in any method), and we proceed with just a classic RSA pair key signing process.

The first problem I see is the first update that will provide the public key to the appliance. Since we start from an unsafe state, I suppose we cannot resolve this. We have to accept that the first update might be malicious. But from that point on, each update could be verified by the public key.

The main problem is how to maintain such an approach. If for some reason the appliance looses its public key, is there a way to provide the public key with some confidence that the process is safe even if there is a cost in user experiece? For example if I provide the public key in an https site with its hash, and perhaps with a login process, could this resolve this edge case, as long as I trust the https connection? In this case I still used removable media, I just download the update (or the public key) from an other system and require some manual work from the user.

Is there a better approach that I might want dig into, to provide a better scheme with these conditions

  • Is it possible to make manual initial appliance provisioning? You could configure public key to trust. – Crypt32 Jul 11 at 10:29
  • This scenario cannot work if you have to send the update, in case the appliance is already deployed. But ofc we can do it in case of the new images. – ystv Jul 11 at 12:04
  • Is there any particular reason you can't nuke and rebuild into a more secure configuration? And yes, you're correct about not being able to verify the first update; there's a reason most computers today come preinstalled with a trust store. You can't turn an untrusted channel into a trusted one from absolutely nothing. – Nic Hartley Jul 11 at 14:06
  • Basically, the issue is that if you already have deployed appliances you cannot go back. In a sense, this is an accepted risk (or perhaps an unavoidable one) that I have to live with. But even if I have accept this risk, I still have the issue of maintenance. – ystv Jul 11 at 15:08
  • Please describe how your update process works currently: where the update is stored, how users acquire the update, how do they install it. Also clarify what do you mean by “If for some reason the appliance looses its public key”. If code signature validation is going to be a part of the update process then “lost” public key is equivalent to damaged update mechanism. What if I loose /bin/*? I salvage data and reinstall the OS. – Andrew Morozko Jul 12 at 7:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.