Ensuring patients privacy in a cryptographic-based-electronic health records using bio-cryptography

Several recent works have proposed and implemented cryptography as a means to preserve privacy and security of patients health data. Nevertheless, the weakest point of electronic health record (EHR) systems that relied on these cryptographic schemes is key management. Thus, this paper presents the development of privacy and security system for cryptography-based-EHR by taking advantage of the uniqueness of fingerprint and iris characteristic features to secure cryptographic keys in a bio-cryptography framework. The results of the system evaluation showed significant improvements in terms of time efficiency of this approach to cryptographic-based-EHR. Both the fuzzy vault and fuzzy commitment demonstrated false acceptance rate (FAR) of 0%, which reduces the likelihood of imposters gaining successful access to the keys protecting patients protected health information. This result also justifies the feasibility of implementing fuzzy key binding scheme in real applications, especially fuzzy vault which demonstrated a better performance during key reconstruction

SoK: Cryptographically Protected Database Search

Protected database search systems cryptographically isolate the roles of reading from, writing to, and administering the database. This separation limits unnecessary administrator access and protects data in the case of system breaches. Since protected search was introduced in 2000, the area has grown rapidly; systems are offered by academia, start-ups, and established companies. However, there is no best protected search system or set of techniques. Design of such systems is a balancing act between security, functionality, performance, and usability. This challenge is made more difficult by ongoing database specialization, as some users will want the functionality of SQL, NoSQL, or NewSQL databases. This database evolution will continue, and the protected search community should be able to quickly provide functionality consistent with newly invented databases. At the same time, the community must accurately and clearly characterize the tradeoffs between different approaches. To address these challenges, we provide the following contributions: 1) An identification of the important primitive operations across database paradigms. We find there are a small number of base operations that can be used and combined to support a large number of database paradigms. 2) An evaluation of the current state of protected search systems in implementing these base operations. This evaluation describes the main approaches and tradeoffs for each base operation. Furthermore, it puts protected search in the context of unprotected search, identifying key gaps in functionality. 3) An analysis of attacks against protected search for different base queries. 4) A roadmap and tools for transforming a protected search system into a protected database, including an open-source performance evaluation platform and initial user opinions of protected search.Comment: 20 pages, to appear to IEEE Security and Privac

Enabling Secure Database as a Service using Fully Homomorphic Encryption: Challenges and Opportunities

The database community, at least for the last decade, has been grappling with querying encrypted data, which would enable secure database as a service solutions. A recent breakthrough in the cryptographic community (in 2009) related to fully homomorphic encryption (FHE) showed that arbitrary computation on encrypted data is possible. Successful adoption of FHE for query processing is, however, still a distant dream, and numerous challenges have to be addressed. One challenge is how to perform algebraic query processing of encrypted data, where we produce encrypted intermediate results and operations on encrypted data can be composed. In this paper, we describe our solution for algebraic query processing of encrypted data, and also outline several other challenges that need to be addressed, while also describing the lessons that can be learnt from a decade of work by the database community in querying encrypted data

Why Do Developers Get Password Storage Wrong? A Qualitative Usability Study

Passwords are still a mainstay of various security systems, as well as the cause of many usability issues. For end-users, many of these issues have been studied extensively, highlighting problems and informing design decisions for better policies and motivating research into alternatives. However, end-users are not the only ones who have usability problems with passwords! Developers who are tasked with writing the code by which passwords are stored must do so securely. Yet history has shown that this complex task often fails due to human error with catastrophic results. While an end-user who selects a bad password can have dire consequences, the consequences of a developer who forgets to hash and salt a password database can lead to far larger problems. In this paper we present a first qualitative usability study with 20 computer science students to discover how developers deal with password storage and to inform research into aiding developers in the creation of secure password systems

Some Potential Issues with the Security of HTML5 IndexedDB

The new HTML5 standard provides much more access to client resources, such as user location and local data storage. Unfortunately, this greater access may create new security risks that potentially can yield new threats to user privacy and web attacks. One of these security risks lies with the HTML5 client-side database. It appears that data stored on the client file system is unencrypted. Therefore, any stored data might be at risk of exposure. This paper explains and performs a security investigation into how the data is stored on client local file systems. The investigation was undertaken using Firefox and Chrome web browsers, and Encase (a computer forensic tool), was used to examine the stored data. This paper describes how the data can be retrieved after an application deletes the client side database. Finally, based on our findings, we propose a solution to correct any potential issues and security risks, and recommend ways to store data securely on local file systems