For all hours that go into preparing for the Catalyst conference, it flashes by in an instant. This year was no exception. In the course of prepping for Catalyst, I attempt to pack my head as full of my recent research as possible, but there are practical limits to that…
In the privacy track, I described a method for protecting privacy through the use of data labels, which we call relationship context metadata (RCM). (For those of you Catalyst attendees who missed it; you can see my presentation here and for IT1 subscribers you can read my report here.) In the RCM proposal, when one enterprise transfers data to another for processing, a “bead” of RCM is created that describes consented uses of that data and obligations imposed on recipients. Each bead is a point-in-time snapshot of the appropriate uses of the data and extra precautions regarding the data. The instructions in the beads are meant for the social layer of the enterprise – its people. The RCM instructions are not meant as a technical control (though they could be used by technical controls).
I was really impressed by the specificity and nature of the questions I received on RCM. Having heard Flavio Villanustre of LexisNexis describe his company’s data labeling scheme, the audience was clearly primed to dig into relationship context metadata. A gentleman asked a question which I had to take offline – because after four days of the Catalyst lifestyle my brain was pudding. The question was fairly simple: what happens if an attacker manipulates the data while leaving the RCM, the data labels, alone?
I’ve had a chance to think about that now. A few things to keep in mind: first, what our research proposes a method of tamper detection – not tamper-resistance. Second, the concern is the malicious manipulation of a bead or of the data, not the removal of a bead (we use procedural controls to deal with removal of beads; the rules we propose place liability with the organization that removes beads). Lastly, the tamper detection methodology I’m about to describe is not the only one that could be implemented; I strongly caution enterprises who are considering a data-labeling system to think long and hard about their tamper detection mechanisms, and I welcome comments from cryptographers with suggestions for improvements.
Here is how we think tamper detection could be implemented in an RCM system. While a bead is being constructed:
- Hash the data and record the data hash in the bead.
- Generate a UUID for the bead and record it in the bead.
- Record previous bead’s UUID and the previous bead’s hash in the current bead.
- Hash the current bead and record the bead hash in the bead.
First, we hash the data – straightforward enough. Next, because we will want to reference a specific bead, a universally unique identifier is generated for the bead. Third, because beads are ordered on their strings, we record the previous bead’s UUID. We also record the previous bead’s hash in the current bead; this allows us to detect “cuts” in the string of beads. Finally, we generate a hash of the current bead itself.
I mentioned earlier that RCM and the instructions in individual beads are meant for the social layer of the enterprise. Clearly, no data handler is going to examine all of these hashes, let alone compute them. The tamper detection RCM proposes is a technical control which relies on the technical layer of the enterprise for implementation – the idea is that this mechanism will be used as an integrity verification check if someone in the social layer calls the validity of the information in a bead string into question after seeing “something fishy”.
I’ve been talking to enterprises about data labeling and protecting privacy. The opinions and implementations vary widely. If you are considering some sort of data labels effort, drop me a line – I’d love to talk about.
The post Follow-up from Catalyst 2011: Tamper detection and Relationship Context Metadata appeared first on Ian Glazer.
