Can you talk in more detail about the cryptography you're using?
We do not write any of our own crypto. We use common open source libraries like libsodium, WolfSSL, OpenSSL, etc. under the hood. We provide binary versions of our library linked against the appropriate libraries for the customer, or customers can build their own combination of our library+crypto dependencies from source.
Sometimes we help customers get the compile options right to take advantage of, say, NEON instructions to optimize for an ARM target, but that's about the extent in terms of touching the actual crypto library.
I'm guessing there are almost certainly side-channel attacks (discovered or not) in most crypto libraries. How easily they're exploited is another topic.
We don't believe we need to build more cryptography engines. We just think we need to make the existing crypto libraries easier to use in conjunction with PKI, vulnerability monitoring, ease of patching, and especially in the context of documentation and testing in the eyes of the FDA.
Underneath, calls would be made to the open source crypto lib yielding, for example, data encrypted via ChaCha20 stream cipher with Poly1305 MAC authentication.
Also, our platform generates a provisioning configuration that tells the device to generate a dedicated set of keys for the purpose of encrypting data at rest. Those keys would not be used for any other signing or socket security operations. In general, if the target hardware can support it, we create dedicated keys for each type of data security operation (read multiple RPCs sending different types of data like log data, command-control data, images). We think this is especially important for encrypting data with LTKs since there have been cases where encrypting with a secret key has resulted in secret key leakage.