4

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.

Improve this question
2
  • 2
    What specifically is your requirement however? If it merely needs to be encrypted on transport, then you could potentially solve this problem with few application changes. Otherwise if the data must be encrypted on the device and/or stored in a backend system in an encrypted manner then it certainly becomes more complicated. Furthermore, how is this data being transported? What protocol and medium is being used? Commented Mar 18, 2016 at 13:27
  • Encryption without authentication is useless. XML encryption is tricky. Please have a look at IT Security SE for leads. Commented Mar 20, 2016 at 17:30

2 Answers 2

Reset to default
1

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.

Improve this answer
2
  • 1
    For more general use, I would suggest instead an encryptedWith attribute that could identify the encryption type. You could use values like "AES" or "Blowfish", or internal identifiers if you don't want to identify the algorithm used. Commented Mar 18, 2016 at 13:55
  • The problem is that records aren't encrypted one by one but as a whole. Therefore I could only store one encrypted block containing many records, which is semantically speaking different from a single record. Commented Mar 18, 2016 at 14:00
1

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.

Improve this answer
11
  • The device isn't running Java (the firmware is basically written in C), but it isn't the point of interest of my question. The problem I have is on the "server" side, which is a Java program that should handle (decode, decrypt, store, etc.) incoming data from many of these devices. Commented Mar 18, 2016 at 14:03
  • My answer doesn't fundamentally change then. You can still use JAXB with Jasypt to decrypt any fields that are encrypted. I am still confused though as to HOW the data fields are being encrypted? The device firmware would have to be updated to use encryption keys to encrypt the data. Those keys would need to be available on the Java program to decrypt the data. Commented Mar 18, 2016 at 14:12
  • Indeed, the firmware knows the key to encrypt the data. But the key is not always known by the Java program. In this case the best I could do is to store the data encrypted. My problem is more: What's the best way to store the encrypted data in xml ? rather than How to decrypt the encrypted data from an xml ? Commented Mar 18, 2016 at 14:19
  • By the way, thank you for having mentionned Jasypt Framework. This could be helpful for me in the future. Commented Mar 18, 2016 at 14:30
  • @Spotted Just store it as is :) You probably want to make sure you have some way to identify the record to a specific device, or else you may not know how to retrieve the decryption key at a later date. There is no problem to store an XML document in a database that has encrypted fields as long as you have some uniquely identifiable fields in that record that can link it directly or indirectly to a specific device or encryption key Commented Mar 18, 2016 at 14:38

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.