Getting a pre-cooked authentication IC may be the best way forward here. Although it's intended for heavier duty, using a TLS library may be a good way forward here.
I was thinking a security chip + small MCU may be cheaper/easier than an MCU capable of doing TLS or other security in software. The node will be doing nothing else but replying to auth requests and setting an output on receipt of a command.
I had some thoughts about anti-removal detection:
- you could send a heartbeat message through the secure channel
The host will continuously poll the node
- this implies that the host & nodes will be powered on continuously - are they battery powered? If not, what about power cuts?
Yes they will be continuously powered, with system-wide backup. Power at the node is limited due to being on the end of a long wire which may be part of existing cabling which we can't re-specify
- make sure the client really wants this feature. It's going to be a pain, with false tamper detections and trips to fetch the disconnected node and bring it back to the shack for re-pairing. Given some of your very cool installation work is installed 10 meters above the ground, such trips could be a giant pain in the backside.
Yes, they want something - the product will be to retrofit existing/new installs solely to add this specific feature.
Regarding cryptography:
- If you're prepared to 100% trust that there aren't any eavesdroppers on the wire, you can do quite basic pairing.
- If you want to authenticate that the Node is an authentic MikesSecureStuff Node, it will need some kind of certificate inside. This will need secure loading at the factory (see below) but should allow secure pairing over an untrusted wire (yay!)
Building a Node @ factory
- Generates an asymmetric key pair e.g. Elliptic Curve Cryptography (ECC) public and private key
- Sends the public key to a Hardware Security Module (HSM) computer in the factory (this may be air-gapped and placed in a secure cage), which makes a certificate to say 'the above private key is indeed a genuine MikesElectricStuff widget'
- Stores the public key, private key and certificate in secure EEPROM
- Runs a TLS server, ready for the Host to connect
Building a Host @ factory
- Gets loaded with the a number of trusted HSM certificates in the factory
- Optionally, generate an asymmetric key pair and get a certificate (same procedure as for node)
- Stores the (optional) public and (optional) private key and list of HSM certificates in secure EEPROM or something
- Runs a TLS client for each Node connection. When connecting to the Node, the TLS library will verify the Node certificate against the list of HSM certificates.
Pretty much none of that is needed - Security starts at the on-site installation stage, nodes are potentially freely available, pairing is initiated on the host in a controlled environment, and the host-node connection is not regarded as vulnerable during pairing. How this may work for extra-paranoid customers is the node is connected locally to the host for pairing, then moved to the final location at the end of the wire.
Part of my problem is wading through all the features of the crypto chips to distill out what we actually need without spending too much time learning unnecessary things.
The on-site pairing is what I see as the main difference between this and the more traditional factory provisioning/certificate process, none of which is needed here.
At installation we just need the host to generate a random key, communicate it to the node and store it securely in the node.
Like I said the need for "crypto" is mostly about using a cheap off-the-shelf chip, and ticking boxes for customers who have no clue about the technicalities.
We could do it just fine with some mildly obfuscated CRC type stuff on a PIC8, but for the intended market, it is probably worth spending half a buck to be able to tick those boxes, and be confident we won't end up the subject of a Defcon presentation!