Do You Know Where Your Data Are? Secure Data Capsules for Deployable Data Protection

Do you know where your data are? Who can see them? Who can modify them without a trace? Who can aggregate, summarize, and embed them for purposes other than yours? We don’t, and we suspect neither do you. The problem is that we do not have a widely-available mechanism to answer these questions, and yet, paradoxically, all evidence shows that it should have been solved long ago. The problem is critical; incidents involving sensitive data leakage, unauthorized access, and integrity violations (accidental or not) are a daily occurrence [1]. It is well known, as evidenced by the volume of relevant government regulation and pontification from privacy advocates. It is interesting, since it has inspired much research into data confidentiality, integrity, and authorization. Yet publicizing it, regulating it, and talking about it have not led to solving the problem effectively for the vast majority of users. Why? We believe the root of this paradox lies in the disconnect between research, policy, and industry objectives, and the needs of the real world. Research has largely focused on elegance and intellectual exploration, while industry has built expedient solutions for media content protection and enterprise rights management, guided by projected revenue. In either case, the problem is solved for some users, under narrow scenarios, but neither research results nor rights management systems have resulted in broad applicability and deployment. In this paper, we examine the problem of protecting data for all users, and not just for some. We use broad applicability as the driving goal, and explore the challenges and promises of reaching towards that goal with efficiency and high assurance. To be broadly applicable, a data protection mechanism must support, first and foremost, backward compatibility. Any mechanism must seamlessly integrate with unmodified applications and data formats. Even in the face of vulnerabilities, pragmatic concerns make it tough to argue for the wholesale migration of systems from existing infrastructure and legacy programs to something completely new. Research proposals that require completely new operating systems [11, 32], languages [21], or both [25], do not apply to legacy systems and therefore contribute only indirectly to solving our problem. Beyond the ability to support existing applications, a data protection mechanism should be flexible. Solutions based on a centrally vetted, closed set of applications are incompatible with today’s diverse, dynamic systems. A prime example are commercially available enterprise rights management (ERM) solutions. Although technical details and scrutiny are scarce, ERM products appear to be based on a common proprietary application framework [3,20] or on application-specific modifications [12]. Consumerization, which fosters individual choice, leads many users to find the “walled gardens” of ERM systems unacceptable. On the other hand, the limited set of supported applications inhibits interoperability among enterprises—a cost organizations often refuse to bear. When an organization does decide to move to a different application platform, it may risk losing continuity within its own documents, at a potentially astronomical cost. As a motivating example, consider protecting the privacy and integrity of a patient’s—we will call him Owen—personal health records. In the USA, the privacy of these records is a requirement laid down by statute, with significant penalties for violations [2]. Their integrity is also critical: unauthorized modifications could be fatal—consider the inadvertent removal of Owen’s alergies from his record. Current usage exhibits significant complexity. Owen’s record may be handled by all the physicians who treat or advise him, all of his insurers over time and employment changes, and all the hospitals and clinics where he is seen. This usually large set of people and organizations view and modify Owen’s record on varied platforms (clinic PCs, mobile tablets, web forms), managed by IT staff of varying skill. It is unreasonable to expect such a diverse conglomeration of users and systems to change en masse into a new, common OS and a small set of blessed applications. At the same time, restrictive solutions like ERMs are too specific, and do not work seamlessly across hospitals with distinct infrastructures (e.g., when Owen is treated while on vacation abroad). Although representative in criticality and complexity, this example is by no means unique. From social networking to advertising systems, from financial transactions to email records, examples abound, each with varying privacy and integrity requirements.