In IoT “S” stands for security
(c) one smart guy in Twitter
Weak security is a major problem of almost all modern IoT and IIoT/Industry 4.0 solutions. There’s usually nothing wrong when equipment state or shadow state is available for nodes in your configuration, as one of Industry 4.0 design principles is “Information transparency”.
However things change when we start talking about control. Allowing nodes to control each other and send action API calls is dangerous: if attacker get an access to information exchange point, he can destroy your business or even your life.
The door of your house is locked, everyone can check this fact. But will you give a keys from this door to a stranger and ask him to open it for you? I don’t think so.
We all know about popular SARA attack on a cars: when you send wireless signal to your car lock, it can be intercepted by attacker and used later to open it without your permission. Why? Because wireless protocols in the air are vulnerable and sooner or later but all car lock vendors started using encryption.
EVA ICS controllers installed on separated nodes around the world can connect each other via HTTPS, and this is the most safe and reliable way: the protocol is protected with a strong TLS/SSL encryption and nobody can steal passwords or API keys sent inside its frames.
But this is “old-school” way, in modern times we all prefer to avoid fighting with port-forwarding, gateways and NAT, we like real cloud computing and information should be exchanged via cloud exchange points, such as MQTT servers or IoT cloud providers (which all have actually MQTT inside).
MQTT server is the most important part of any IoT infrastructure. Enterprise customers and even home users prefer to use it as SaaS, in order not to worry about scalability, downtimes and etc. But yes – it’s insecure.
If attacker get an access to MQTT server, he can intercept API keys and unlock your door. Actually majority solutions don’t even use any authentication mechanisms, considering MQTT server should do the job ruling permissions to specified message topics.
MQTT servers in clouds are managed by 3rd party technical staff, cloud providers avoid to sign any liability contracts, with any 3rd party MQTT/IoT provider the whole infrastructure becomes vulnerable. In EVA ICS we consider any MQTT server is evil and insecure.
Even your own – if you host own cloud, IoT nodes are located inside protected local networks, but if more than one network is used, MQTT is usually installed on a “public” host.
Solution? Obviously! All API calls except state announcements should be encrypted.
How? You can use old good asymmetrical cryptography, but this is a redundant way: any IoT infrastructure is private, both clients and servers have a set of API keys, so why not to use them for encryption?
How it’s made in EVA ICS: encrypted JSON RPC over MQTT.
- Client controller sends API request which contain plain-text API key ID and AES-signed/encrypted request UUID + JSON-RPC API request body. (if auto-discovery/announces are on, controllers use API key with ID “default” to discover and pair each other automatically).
- API request is being sent with topic <SERVER_CONTROLLER_ID>/api/request
- Client waits for the single message with topic <SERVER_CONTROLLER_ID>/api/response/request_UUID for the specified period of time (server timeout).
- When server controller receives message with the above topic, it looks for API key by its plain-text ID and tries to verify and decrypt API request. (ID of the API key should be equal on both sides).
- If API request signature matches and data is successfully decrypted, server process API request and sends API response.
- If decryption is failed, request is ignored, as server can’t guess who exacly sent it.
- API response contains plain-text common response code (200 for OK or 500 for Internal Error, e.g. server crashed) + JSON RPC API response, signed/encrypted with client API key and is sent with MQTT topic <SERVER_CONTROLLER_ID>/api/response/request_UUID
- Client gets API response, verifies its signature and decrypts it with API key used.
MQTT server gets just a pile of garbage. No any useful information can be intercepted and forged. The only visible data is request UUID which becomes public only after the reply is already sent and obsolete as soon as client got it. No one can even know for which client this data is.
In EVA ICS “S” stands for security
(c) EVA ICS Team