Application level end-to-end encryption?

[emiltin]

What do you want to know?

Hi,
Do you have any thoughts/plans on supporting application level end-to-end encryption in SparkPlug? You can already run with TLS, but we have road authorities that also want E2E encryption on application level, which currently would seem to exclude SparkPlug, since the payload format is fixed.

Is this related to a Sparkplug Listing request? If so, link the issue from https://github.com/eclipse-sparkplug/sparkplug.listings here.

No.

Version

None

Accept EFTL Terms

• I agree to the terms of EFTL

[bryce-nakatani]

Thank you for posting your issue. Would tunneling the TLS session through a VPN connection suffice?

[emiltin]

Thank you for your response.
I don't think so. They're already investing resources in implementing application level encryption (in RSMP 3) because they think it's necessary.

[peterhumaj]

So, if a payload was encrypted, only one (or few) endpoint(s) has decryption key, so all the others cannot read the data.
While this is ok for generic MQTT, in my opinion it totally denies the purpose of Sparkplug - to provide metrics to all who need it.
Outside of Sparkplug, you are free to encrypt the payload and send it as vanilla MQTT messages (preferably outside of Sparkplug namespace).

[emiltin]

Thank you for the input! I guess provideing metrics to all who need them is generally true, for both MQTT and SparkPlug. But often you have a setup with a few well-known applications and for security reasons you might want to be able to control who can read the data. I believe the SparkPlug spec also mentioned access control lists on the broker. But that's different from end-to-end encryption.

I don't see how this denies the purpose of SparkPlug?

[peterhumaj]

I thought the purpose of Sparkplug is to increase interoperability of MQTT clients (IIOT devices, SCADA systems, etc) by providing the rules for encoding data (Protobuf) and defining application states (DEATH/BIRTH). To make information accessible, not inaccessible. I may be wrong, though.

All the encryption was delegated to lower protocol levels (TLS). Authorization/authentication was handled by the MQTT broker.

So "to be able to control who can read the data" should be handled by the MQTT broker and its configuration.

If it is not enough (i.e., you don't trust the MQTT broker), you could still encrypt part of the payload and hide it in Sparkplug (perhaps Metadata? it even supports files transfer), and set up your clients to process such a payload, which will be happily ignored by others.

[emiltin]

Yes, however all the other SparkPlug-defined fields like name, timestamp and type of the metrics cannot be encrypted, as far as I can see.

[peterhumaj]

You are quite right. You can, however, put all fields that you need to encrypt into Protobuf format, encrypt it, send it within Metadata and after receiving, decrypt & process as Sparkplug payload. And beside metric name ("my_encrypted_data"), you just specify is_null=true, which doesn't reveal much.

Btw, your implementations will have to

• store public keys of the receiving party / parties
• have a procedure to update the public keys of the receiving party / parties (when they change)
• perhaps have a mechanism to re-generate their own private/public key pair (before they expire) ... and probably push them to the receiving party?

Do you suggest putting these things also to the Sparkplug specification? In the way that OPC UA defines key management procedures?

[peterhumaj]

Another possible though ugly way (I'm mentioning it because my colleague is about to do something similar - take a BLOB, BASE64 encoded and treat it as a text) would be to encrypt the metric, encode (e.g. BASE64), and send as a value of a text metric...