4

Let's say you wanted to implement a "secure sideloading" mechanism for your embedded device so that the device could establish trust with authorized 3rd party developers. Developers would have local access to the device, the firmware is not updatable which contains the OS (Linux), the sideloading feature would provide them a way to load applications that run on top

These were my initial thoughts:

1.) Enable/Disable sideloading on the device via a remote signal (TLS), the client would initiate the request based on some user initiated action (the TLS client code being baked into the firmware)

2.) Use a system such as X.509 or GPG, pre-generate and embed a certificate in the firmware of the device prior to shipping it. Developers could then be issued keys from the device provider which could in turn be verified by the embedded public key/cert on the device. There are added advantages such as expiration dates and revocation methods that would work offline/OOB

3.) Use both 1 + 2

I'm not a security expert so I'm not familiar with the possible ways to exploit #1, however I think #2 would be inherently more secure than #1 as the establishment of trust is out of band (doesn't use the network). On that note, I'd just assume #3 would be better yet.

Any comments? Thank you

  • One major issue is certificate revocation. If a certificate is compromised you should have a way to invalidate and reissue signatures. – AstroDan Jul 18 '16 at 15:58
2

You really need both as the two achieve different things.

  1. You achieve secure communications, which protect from interception/injection of data during comms.

  2. You achieve confidence the 3rd party is both a trusted 3rd party and the 3rd party you think it is. (or in this case, a 3rd party which is trusted/authorised by the vendor).

The 1st one is pretty straight-forqward. The 2nd is a little more tricky and where many vendors have made mistakes. For example, the many IoT devices where they have used a GPG approach, but have made the mistake of using the same private gpg key on all devices.

Which type of solution you use for #2 will depend on your exact needs and risks. You need to balance the amount of protection required with the inherent level of complexity it introduces - there is no point having a really complex and highly secure solution if managing that solution becomes so complex that operational failure becomes more likely.

Consider what your requirements are and what the associated risks are to determine the minimum necessary protection and then look at how you will manage the solution and ensure this can be done without excessive burden.

There is no one right solution. It will depend on the risk profile you are addressing and how you structure things. For example, if you want the 3rd party developers to manage things i.e. the software is made available on developer managed web sites, then you probably want a signed certificate approach where you give an approved 3rd party a signed certificate and your device will only allow loading of apps from 3rd parties which have an appropriately signed certificate. This gives you the ability to revoke approval by revoking the certificate.

Alternatively, you could use an approach where you allow 3rd parties to submit applications to a site which you control. You would assess and approve the 3rd party apps and only make ones which you approve to be available on the site. In this case, you can probably just use a GPG based approach, which might be easier to manage.

The first approach would put greater trust in the 3rd parties, but would likely reduce administration overhead for you. The second would require less trust, but would create higher admin overheads for you because you have taken on a vetting role. It is also likely that there would be increased turn-around time i.e. from release of new/patched versions. However, it would also have the advantage of more control and increased quality, which may be important as the overall quality of your device may easily be judged by the quality of the apps it runs.

The two are not mutually exclusive either - you could do both, which may be warranted in some circumstances - again, depends on your risk profile and what levels of risk your comfortable with.

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.