Commercial Product Customers Worried About Connection Security

So we are planing to use the electric imp technology as our Wifi/IoT connectivity module.

Some of our B2B customers are worried about connecting to their internet and any security risks. When I have the conversation about network security with current and future customers, how can I comfort and guarantee their network security through electric imp’s services and hardware?

We can provide a lot of information on this subject; for truly industrial-strength answers we have a nearly 50 page principles of operation document that gives full information about system architecture, keys used (where/how generated, where stored, lifetimes, etc). This is generally the document that we provide to pentesting firms or companies doing security reviews, and it’s provided under NDA - contact sales for more info on that.

We also can provide some more basic information which is not NDA protected. What are your customers concerned about, specifically?

Some common answers below, for impOS33 and later. There have been improvements since impOS32 (current release for imp001-003) but impOS34 is just around the corner which harmonizes all devices onto the same version. I’m quoting the impOS34 detail as that’s more relevant long-term.

Connection type
Imps connect outwards to the server in all cases. There is no need for customers to open any inbound ports. Imps will attempt connections on port 31314, 993 and 443 (in that order), and can be configured to use an HTTP CONNECT proxy. Static IP can also be configured.

Connection security
Connections are standard TLS1.2, using ECDHE-RSA2048-AES128-SHA256 (ie, forward secrecy is enabled). Embedded CAs verify the keys provided by each end, and a challenge-response is used to challenge the unique per-device key to prevent device impersonation even if TLS keys leaked.

Code security
All code is executed from on-die memory ONLY. All debug interfaces are disabled. VM applications are downloaded over the TLS channel. On imps that use off-die memory (eg imp005), the contents are encrypted with the per-device unique keys and AES128 - this includes OS images, VM applications, and configuration information.

OS security
OS images are encrypted and signed with an RSA4096 key that is stored within a FIPS140-2 compliant HSM. The HSM lives in a safe and requires multiple smartcards to be presented to sign an image.

There are more levels beyond this, but… you get the idea :slight_smile:

@hugo, first and foremost, thank you for the details. Your platform is very impressive!

Is there a formal document that you can supply which covers the information you supplied along with any other security details of your platform (e.g. impcentral authentication, how keys are managed, etc)? I am working for a group that has built on your platform and is undergoing an intensive government security review.

Yes, as referenced above in my post there is a formal “principles of operation” document, that we provide to customers, security analysts and pentesters.

This is available under NDA; please contact with details of the customer you’re working with and we can get the NDA sorted out provide the detail.