Sorry if the question title sounds unclear, I'll happily accept suggestions how to make it better.
We are running a rather complicated SCADA/MES system with a Web interface through which users can, beside other things, set values directly to a PLC control system. The topology is m:1:n, which is many clients to one central server to many control point clients (redundancy/availability measures omitted for simplicity).
Most of the data with which the users interact dwell on the front end server which is secured to the best of our expertise, but is still a web server at the end of the day. We want additional level of security for all actions that don't end their live at the server but are propagated to the control clients.
Current setup is synchronous and direct - on request the server connects direct to the control client and relays the request. The control client has a PIN stored by itself, which is kept nowhere else in the system and distributed to the authorized personnel through different channel. User must supply the correct PIN, or the request gets rejected by the control client
For latency and topology reasons we are planning to switch to asynchronous indirect connection - the request from a user will be stored in the server database and control clients will query the server regularly for the requests. Everything about this setup is convenient, apart from the security implications - the requests for the control points must be stored somewhere on the server, which makes the PIN option irrelevant.
The question is whether there is an option how to secure the 'channel' from the web client to the control client when the requests are asynchronously relayed through the main server.
One idea I could come up with is to simply XOR the request payload, store it on the server and then XOR it again at the control client. This is doable in browser and I suppose this would give the whole request path about the same security as the pin itself. The problem is, that when the Server DB gets compromised and there are more (than one) requests pending in the relay queue, the nature of the requests (JSON strings) will make it very easy to recover the pin. I guess that Base64ing before XOR won't make it any securer.
Details of interest The requests are in form of very short (max 1 KB) JSON strings. There are max. 1000 control clients and estimated 0 to 5 control requests per control client at any given time. Currently the system is not of much interest to 'third parties' but we don't want to wait to have this assumption refuted.