Privacy Enhanced Storage

1. Privacy Enhanced Storage

2. Periodontitis Pilot Study WP6.3 Periodontitis Pilot Study (ACTA) • Development of web-based tool for export and import from/to periodontitis data warehouse • Goal is sharing of periodontitis research data • Exported data should be anonymous • Export as such can trivially be achieved • Another less trivial issue persists: local use of data for research purposes (direct access to database, use of a local analysis tool)e.g. students should not see nominative data • Case study in collaboration with ACTA:How to create a fully protected data warehouse within the periodontitis pilot • Fully protected; solutions should not be restricted to simple access control

3. “Cryptographically Enforced” Access Control Encrypted Storage • Reduces overall vulnerability of the systemi.e. database leaks do not infringe privacy • Facilitates export to research database WP6.3 is an ideal test bed for proof-of-concept • Privacy wise non critical (dental records)Complete implementation thus not crucial • Relatively small scaleContained environment, relaxed performance constraints, … • Technological Barriers: • Deployment of related Custodix solutions has mainly been targeted against common web application frameworks (WP6.3 includes a thick-client application) • Delphi technology is not targeted by Custodix solutions (.net / J2EE)

4. Case admin. information Example of Web Based System Record Nr. No Risk Record Nr. Identities of: • Doctor • Patient Case admin. information Encryption Case data Non-identifying case data No Risk • No identities of patient or doctor required for further processing • Can be completely cleared of identifying information(also “indirect identifying information”) Encrypted • Can only be viewed (decrypted) by a limited number of authorised peopleThe Database does not contain any identifying information(only illegible encrypted data)

5. Case admin. information System Overview • Custodix Software • Software provides on-the-fly encryption and decryption of sensitive data • No unencrypted sensitive data leaves the data collection environment Database Custodix Software case-ID • Local Data Managers... • Each have a personal Keypair (Private/Public Key on Smart Cards) • form an information sharing pool • are the only ones who can view and edit all information in the database Non-identifying case data • Key Management Service • Supports key management • Does NOT contain unencrypted secrets (i.e. no security risk)

6. Smart Card Login Functionality Integration in the Periodontitis Project Key Management Server Database Privacy Enabling Daemon Existing DELPHIApplication ADO ? Callbacks interwoven calls

7. Integration Approach Main goal: Transparency for the application developer: • Limit impact on application model • Key management is handled outside the application by an independent key management service Identified solutions are based on proxy design pattern: • Proxy Database Driver (SQL Wrapper) (Data Access Layer) • Enhanced User Interface Controls (Presentation Layer)

8. proprietary EncryptionDecryption jdbc interface proprietary proprietary SQL Wrapper SQL Wrapper (Data Access Layer) • What? • Direct processing on SQL queries and responses • Gives a high level of transparency for the application developers(Note that issues with searches on encrypted fields still persist) • Problem • The SQL standard does not describe a communication protocol. Each database has proprietary solution for communication. • Handling complex queries (e.g. joins) is not straightforward Proprietary Solution • Not feasible for this project Wrapper Driver (Stub - Bridge) • “generic” approach • Still technology bound(e.g. jdbc driver) Application

9. Enhanced UI Control Enhanced User Interface Control (Presentation Layer) • What? • Actual UI control is wrapped inside a wrapping UI control. • Event-driven, i.e. wrapping UI control performs encryption/decryption on the fly when data update events are received. • Problems • Weak data typing • All data validation checks must be performed in presentation layer • Must not break common data access abstraction strategies • Data binding user controls (e.g. ADO) • Object-relational mapping tools (e.g. Hibenate)

10. Searches on Encrypted Data • i.e. the ability to look up patient records based on partial identifying information • Encrypted data is opaque (unstructured and unordered) and is thus not trivially indexable • Monitoring and analysing queries can lead to partial or complete re-identification • Possible approaches: • (encrypted) indexing service hosted by TTP • Local caching of search indexes on the client (data collection) • Client retrieves encrypted indexing structure from server • Builds local indexing table • Drawbacks: • querying the database becomes more complex as it involves more client-side processing • Synchronisation issues in data sharing environments

11. Searches on Encrypted Data Periodontitis Database is of limited size (~700 patients) • TTP solution involves too much operational overhead for the problem at hand • Searching on partial data is not main concern for this project

12. Data Sharing • Multiple users need to be able to share encrypted data • Must be able to accommodate dynamically changing user groups (roles) • Must be efficient both in time and space • Trivial solution: encrypt data for each group member • Very storage inefficient • Very computation intensive • Does not enforce group membership in a cryptographic way (relies on access control measures) • Approach based on three level encryption key infrastructure (see next slide), involving: • Users • Roles • Confidentiality Units

13. User X  { Role, Role } RBAC – Enforced through Encryption Content encrypted with the same secret Confidentiality Unit (CU) • Smallest unit of sharable data Roles • Determine “Access Control” • {Roles} have access to a CU Users • Can act in a number of {Roles} CU CU CU CU CU Note: • Suggested: Use one CU (coupled CUID) for each patient record • But not required ()

14. Notes on Security This solution is secure because: • No identifiable information leaves the Client computer in unencrypted form • All identifying information is encrypted • Only a strict group of users can decrypt that information • Personal keys can be stored in (tamperproof) Smart Cards(increasing security even further) • Database Access Control failure does NOT compromise privacy of patients (identifiers are encrypted) • The Key Management Service is NOT a risk factor in the protection scheme (It only stores Public Keys and key management metadata in encrypted form)

15. Thank you for your attention! Custodix NV Verlorenbroodstr. 120 B-9820 Merelbeke Belgium http://www.custodix.com/ or info@custodix.com