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.
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.
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.
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 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