Data Durability Security Over Time

Session Topic: Data Durability: Security Over Time

Wednesday 2K

Convener: T. Rob

Notes-taker(s): T. Rob

Tags for the session - technology discussed/ideas considered: security, data, pclouds, vrm, identity, encryption, key management, iot

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps: There are two use cases which appear to be common for Personal Cloud and VRM and which both require a data centered approach rather than the ubiquitous connection-oriented approach:

1. A need to prove data integrity and authenticity over time. If the personal cloud collects transactional and experiential data over time, then for that data to be useful for more than trivial requirements there must be a way to prove it is authentic and intact when it is used at a later date.

2. A need of 2nd and 3rd party recipients to trust data for non-trivial uses. The example given is of a power utility receiving load abatement data concerning LED bulbs. The utility does not receive the data directly from the bulbs but rather the bulbs report to the homeowner who republishes the data to the utility.

Many existing architectures rely on a secure connection to a trusted party. Data received over that secure connection is assumed to be authentic and intact due to the context of the connection. The authoritative source (usually a vendor or merchant) is assumed to have sufficient physical and procedural controls to prevent changes to the underlying data.

The base assumptions change for personal clouds. These may be self-hosted in which case there is no longer an assumption regarding physical security of the data. Regardless of who hosts them, one premise of personal clouds is that you own your own data and so there is no longer an assumption of procedural controls to assure integrity of stored data. On what basis can someone connecting to a personal cloud then trust the data received, other than that to which it is not a 1st party participant?

The answer proposed is that the parties involved counter-sign the transactional data, or that devices sign the data that they emit. At daily intervals the transactional and event data are signed as a batch. Then at weekly and perhaps monthly intervals hashes of the smaller batched are aggregated and signed. In this way, large databases can be verified after migration or against a redundant copy and any discrepancies can be identified at the data element level by drilling down through the hierarchical hash tree.

The similarity to BitCoin and Ripple history auditing was discussed and the idea of an implementation based on Ripple was tossed around.

We also discussed implications on key management. Currently either a key is valid or it isn’t. In Enterprise archival storage key usage is time-bound by category such that, for example, a given key can be invalid for encryption after a given date but valid for authentication and decryption for a much longer period.

Data sharing over time was also of interest to the group. Access to the personal cloud is perhaps not granular enough when the cloud represents shared history. When you get married, both parties legitimately have access to their shared history but not necessarily to prior history. In the event of divorce, there needs to be a way to either duplicate the shared portion or else maintain access to *just* that portion by both parties while subsequent history is private.

Similar requirements apply to organizations that outlive membership of any one individual such as Scout troops. Here there is tremendous benefit in maintaining the history and traditions of the troop despite the participation of any one leader or member lasting on average just a few years. Although much of the data would be public, access to current and past membership details would need to be limited and audited.

Although there were no next steps from the meeting, the consensus of the group was that the session’s premises were valid and that connection-oriented security alone is not sufficient to address the unique security needs of Personal Clouds or VRM as currently understood.