Context
I work in the energy domain with devices that send data in clear text over some medium, that finally ends on a computer. The data is there decoded and stored in XML files.
A current XML file storing data for a device looks like this at the moment:
<Device>
<Address>1234</Address>
<SomeOtherParam />
<Data>
<Record>
<Key name="Energy" ... />
<Value unit="kWh">42.56</Value>
</Record>
<Record>
<Key name="Volume" ... />
<Value unit="m3">2.317</Value>
</Record>
...
</Data>
</Device>
Change
Now, with the emergence of IoT, new devices must send some parts of their data encrypted (some parts can still remain unencrypted though). When the data reaches the computer, it’s possible (but not mandatory) that the data is still encrypted and could not be decrypted at this moment. However, I still need to save it in XML for a further decryption but the actual XML structure wasn’t designed to store encrypted data.
Imagined solutions
Solution 1
<Data>
<Record>
<Key name="Volume" ... />
<Value unit="m3">2.317</Value>
</Record>
...
<EncryptedRecords>4F2B8678...</EncryptedRecords>
</Data>
Solution 2
<Data>
<Decrypted>
<Record>
<Key name="Volume" ... />
<Value unit="m3">2.317</Value>
</Record>
...
</Decrypted>
<Encrypted>
???
</Encrypted>
</Data>
Solution 3
<Data>
<Record>
<Key name="Volume" ... />
<Value unit="m3">2.317</Value>
</Record>
...
</Data>
<EncryptedData>
???
</EncryptedData>
Personal thoughts
- Solution 1: could provide a minimalist working solution
- Solution 2: could possibly break backward-compatibility
- Solution 3: what should replace
????
Question
What would be the ideal evolution of the XML’s structure to store the encrypted data (keep in mind that I need to keep backward-compatibility) ?
I also found that the W3C has already published a recommendation long time ago. Should I stick to this instead ? Basically, it means ??? of solution 3 could be filled with a recommended structure.
Precision: these XML files are manipulated with JAXB. If JAXB has any facilitation with encryption, it could be an advantage if the new XML structure is directly supported.
2
One possible suggestion: Add an attribute to any XML tag.
<Record Encrypted="true">ABNSDJDFGHD</Record>
Then when reading you can still read the tag and based on the attribute call an additional function to decrypt the data. The Encrypted attribute could be added to any tag. Your current XML structure would remain the same.
2
My suggestion based on your description that your device is using Wireless Meter Bus over radio that a simple solution involving secure transport is probably going to be more trouble than it is worth. It appears that in M-Bus (being wholly unfamiliar with it mind you) that it is flexible such that you could feasibly define your own Transport layer thus implementing something like Transmission Control Protocol is TECHNICALLY feasible. I have no idea if this even exists however and it certainly wouldn’t be worth implementing all of that just to use something readily available like SSL certificates and handshakes to make sure data is sent securely from client to device.
You mention that you are using JAXB so I assume you have a Java program that can marshall, unmarshall XML via annotations. The Jasypt Framework integrates nicely with JAXB to achieve encryption and decryption of specific fields through the use of adapters.
To be honest though, I am surprised that your device is not only running Java, but has enough computing resources to handle an operating system, the overhead of large Java frameworks like JAXB, and can afford to communicate in verbose XML data. My answer fully assumes that both the device sending the data, as well as the device receiving the data are both running Java programs with sufficient computing resources available to them in an OS that is capable of this.
11