Flexible Role-based Secure Messaging Service: Exploiting IBE Technology for Privacy in Health Care

1. A Flexible Role-based Secure Messaging Service: Exploiting IBE Technology for Privacy in Health Care Marco Casassa Mont Pete Bramhall Keith Harrison Trusted Systems Laboratory Hewlett-Packard Labs, Bristol, UK TrustBus 2003, 2-4 September 2003 Prague, Czech Republic

2. Presentation Outline • Setting the Context • Addressed Problems • Scenarios • Requirements • Related Work • Our Approach • Discussion • Conclusions ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

3. Setting the Context • Organisations are more and more complex, dynamic and flexible: people’s roles, rights and duties can frequently • change • Confidential information needs to be protected whilst it is • exchanged and accessed, especially in dynamic environments • Messaging services (such as e-mail services), are commonly used to exchange information within and across organisations ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

4. Addressed Problems • Enforcement of confidentiality and privacy of • information in dynamic contexts, where people’s roles • and permissions are subject to frequent changes • Allow the exchange of confidential information in a way • that only the entities that satisfy predefined privacy policies, • at a specific point in time, can access it ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

5. Context: UK Health Care Service • Focus on an Health Care Service: • example of dynamic organisation • Roles (GP, Doctor, Consultant, • Nurse, etc.) can be played by • different people at different time • We partnered with a UK • Health Care Organization • to understand real problems • and have a Technology Trial • of our solutions • Most of the employees use the • e-mail service but … • At moment interactions involving • confidential patient data are mainly • paper-based: need to be compliant • with Data Protection and Privacy • Laws … Waiting List Administration Teams Referral Letter Referral Letter Assistant GP Referral Letter Nurse Consultant Discharge Letter Surgeries Departments Hospitals Health Service Network ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

6. Scenarios [1] ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

7. Scenarios [2] ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

8. Our Goals • Automate the exchange of Confidential Information • by preserving the Privacy of Patients: i.e. only • the people with the right roles and permissions • will access it • Provide a Flexible, Role-based Secure e-mail • service • Learn from the Trial and investigate usages of • the adopted solution in other “dynamic contexts” ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

9. High-level Requirements Requirements for a secure e-mail service (Health Care Trial): • Strong Authentication of the involved parties • Privacy and Confidentiality: obfuscation of confidential data • Policy-based Disclosures: privacy policies strictly associated to • confidential messages. It must be possible • to tell if they have been tampered with. • Flexibility: Privacy policies must be flexible. it must be possible to • specify role-based disclosure policies. Support for late • binding of roles. Users define their own disclosure policies. • Simplicity of Usage and Management ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

10. Related Work [1] Usage of traditional public key cryptography and digital certificates for confidentiality, non-repudiation and authentication purposes. Example of S/MIME, for e-mail services: Alice’s Private Key Bob’s Private Key Public Keys (Certificates) e-mail service Alice Bob Encryption Decryption Plaintext Ciphertext Plaintext Bob’s Public Key Bob’s Private Key Does it address our problems? … ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

11. Related Work [2] • If disclosure polices depend on the Identity of the receiver, the usage of digital certificates • and public key cryptography is viable. Confidential messages are encrypted • with the public key (within the digital certificate) of the receiver. Examples: S/MIME • If these policies do not (directly) depend on the identity but on other aspects, such as Roles • or terms and conditions, the above approach does not work! • At priori (at the encryption time) , the Identity of the Receivers might not be known! Case of • Late Binding of the Identity. This is the case we are addressing. Receiver’s Identity Known at the sending time Alice Bob Bob Role X Charles Receiver’s Identity Unknown at the sending time Alice … Late Binding ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

12. Alice Encrypted data + policies Bob Trusted Mediator x Charles RBAC Mediator’s Public Key Bob has Role x x … Related Work [3] • Introducing a further level of indirection via a “third party”: • It must be trusted • Encryption/decryption of messages (along with the associated disclosure polices) • by using its keys • Usage of enveloping techniques (PKCS#7, etc.) • It can be coupled with Role-based Access Control mechanisms (RBAC)  It can be implemented by using public key/PKI technologies Cons: - It is not the most natural way of using public key/PKI for e-mail services (e.g. S/MIME) - Complexity of PKI-based solutions for end-users ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

13. Our Approach • Based on: • Identifier-based Encryption (IBE) technology • Reasons: • Explore alternative/complementary solutions • Investigate the suitability of IBE technology ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

14. What is Identifier-based Encryption (IBE)? • It is an Emerging Cryptography Technology • Based on a Three-Player Model: Sender, Receiver, Trust Authority (Trusted Third Party) • Same Strength of RSA • Different Approaches: Quadratic Residuosity, Weil Pairing, Tate Pairing … • SW Library and Technology available at HP Laboratories ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

15. IBE Core Properties • 1st Property: any kind of “String” (or sequence of bytes) can be used as an IBE encryption key: for example a Role, an e-Mail Address, a Picture, a Disclosure Time, Terms and Conditions, a Privacy Policy … • 2nd Property: the generation of IBE decryption keys can be postponed in time, even long time after the generation of the correspondent IBE encryption key • 3rd Property: reliance on at least a trust authority (trusted third party) for the generation of IBE decryption key ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

16. Alice Bob 4 3 2 5. Bob requests the Decryption Key associated to the Encryption Key to the relevant Trust Authority. 2. Alice knows the Trust Authority's published value of Public Detail N It is well known or available from reliable source 5 6 3. Alice chooses an appropriate Encryption Key. She encrypts the message: Encrypted message = {E(msg, N, encryption key)} 6. The Trust Authority issues an IBE Decryption Key corresponding to the supplied Encryption Key only if it is happy with Bob’s entitlement to the Decryption Key. It needs the Secret to perform the computation. Trust Authority 1 1. Trust Authority - Generates and protects a Secret - Publishes a Public Detail N 4. Alice Sends the encrypted Message to Bob, along with the Encryption Key IBE Three-Player Model ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

17. Our Solution [1] • Based on the IBE Model: reliance on Trust Authority(ies) • Privacy policies are represented as IBE encryption keys: • Generated by the sender of confidential messages • Contain list of roles to be played by the intended receivers Example: “Member of The Waiting List Team” • If tampered with, the associated e-mail cannot be decrypted • Trust Authority (TA): • Checks for policy compliance • Generates, on-the-fly, IBE decryption keys • Policy compliance check: • Authentication of the requestor to the TA • The requestor must have the roles defined by the IBE encryption key at the request time • List of people’s current roles managed by the TA ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

18. Our Solution [2] 1 Encrypted confidential data + IBE Encryption Key (Required Roles) e-mail service Sender Receiver 2 Request for IBE Decryption Key 3 Generation and issuance of IBE Decryption Key, If the receiver has the required roles Trust Authority Tables Roles <Identity, Roles> Mappings ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

19. GP Trust Domain Hospital Trust Domain Health Care Organisation - Intranet Additional Technical Constraints Technical constraints dictated by the trial environment: • Authentication of Health Care’s employees via Microsoft Authentication (NT Logon). • Unique login account for each employee. Policies dictate its correct usage • MS Windows Trust Domains associated to Health Care Entities (Surgeries, Hospitals, etc) • for “authentication management” purposes • Usage of Microsoft Outlook 2000 at the client site (GPs, Nurses, Consultants, etc.) as • e-mail browser • Exchange of confidential information within the Health Care Organisation’s Intranet ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

20. High-level System Architecture • E-mail Browser Add-in: • - Standard MS Outlook 2000add-in, • containing IBE encryption/decryption • libraries • - Secure connection (https) and • authentication to the TA • - XML-based encryption envelopes • Trust Authority (TA): • secure web service, with IBE key • generation libraries. Protection • of TA secret in secure vault. Run in a • stand-alone TA trust domain by • trusted administrators, in a secure site • Database: • simple MS SQL Server database at • the TA site containing list of • current roles and up-to-date mappings of • users’ identities (NT logon) to their roles ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

21. System Architecture: Information Flow MS Outlook 2000 MS Outlook 2000 e-mail service IBE Add-in IBE Add-in 1 Encrypted e-mail Request for IBE Decryption Key by sending (part of) the XML Wrapper (via https channel) + XML Wrapper (containing encrypted IBE Encryption Key) Sender Receiver 2 3 Generation and Issuance of IBE Decryption Key, If privacy policies are satisfied (via https channel) IIS IIS .ASP ASP Trust Authority Trust Authority Engine Trust Authority TA Secret Secure Vault Tables Roles <Identity, Roles> Mappings ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

22. Encrypted e-Mail: XML Wrapper Details <?xml version="1.0" ?> - <IBEMailCiphertext> <EphemeralKey>1628655488</EphemeralKey> <IBEPublicKeyCiphertextLength>280</IBEPublicKeyCiphertextLength> <IBEPublicKeyCiphertext> 3affcffdc1ea36455fcf6 ....5rt4rg5uyhg6u </IBEPublicKeyCiphertext> <IBEMailBodyCiphertextLength> 1384 </IBEMailBodyCiphertextLength> <IBEMailBodyCiphertext> d53f07f88946e6411db83f4daeb72bdb8...625c2b900 </IBEMailBodyCiphertext> <OriginalSender>marco_casassa-mont@hp.com</OriginalSender> <UID>293364736</UID> <TimeSent>03:14:31 PM, Monday, Mar 17 2003</TimeSent> </IBEMailCiphertext> (Random) Ephemeral Key To encrypt Disclosure Policy Encrypted Disclosure Policy Exposed to TA (no e-mail content is ever exposed to TA) Encrypted e-Mail Body (e-mail attachments are encrypted and attached) Information for Receipting ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

23. E-mail Browser Add-in: Snapshots ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

24. Addressing the Requirements ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

25. Discussion • Our solution is a practical application of IBE cryptography deployed in a real • context (related work: IBE-based e-mail service by Stanford University) • We leveraged IBE for encryption purposes. It was straightforward • to do it, in a close and trusted environment. Need to explore the • implications in an open, untrusted environment … • Heavy reliance on a “third party” authentication mechanism … • We are exploring IBE-based authentication mechanisms. We do not have • practical evidence that they are better or more usable than traditional (PKI) • solution. • In general we believe IBE is a complementary technology to • public key cryptography/PKI … ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

26. Current and Future Work • We have an optimised version of IBE cryptography libraries • (performance of cryptographic operations comparable to RSA). • We are exploring how to extend our solution to include: • multiple IBE Trust Authorities (for key-escrow and trust reasons) • more complex disclosure policies ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

27. Conclusions • Privacy management is a major problem for modern, dynamic • organisations • Important issue: preserve data confidentiality when exchanged • via e-mail • Current limitations and complexity of PKI-based solutions • We partnered with a Health Care Organisation. • Goal: provision of a flexible, role-based secure e-mail service • Our approach: leveraging IBE technology to enforce • privacy, in a flexible, simple and secure way • We have built a solution that is used in a Trial. • IBE is a viable technology for encryption purposes • The Trial is ongoing and our research is in progress … ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

28. Backup Slides RSA and IBE Cryptography Models ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

29. Msg encrypt e and N published Encrypted Msg Compute N = p*q Compute d&e Keep d secret decrypt N and d Secrets p&q Msg RSA Model ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

30. Encrypt Encrypted Msg Decrypt Msg Msg Public details E D Compute public details Compute Key pairs Secrets s IBE Model [1] ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK

31. Get decrypt Key,e Choose e Encrypt Encrypted Msg Decrypt Msg Msg Public details Compute public details Generate Decryption Key Secrets s IBE Model [2] ﴀTrusted Systems Laboratory – Hewlett-Packard Labs, Bristol - UK