Security in a Provenance System: Ensuring Integrity and Access Control

1. Overview of Today’s Talks • Provenance Data Structures • Recording and Querying Provenance • Break (30 minutes) • Distribution and Scalability • Security • Methodology

2. Security in a Provenance System Victor Tan vhkt@ecs.soton.ac.uk

3. Security: Where does it fit in ? • All data processing related activities in industrial environments will incorporate security concerns • Recording and querying are two main activities in the provenance system for which a security architecture needs to be developed • Scalability and distribution requires further extensions to a basic security architecture

4. Primary security issues • Integrity and non-repudiation of p-assertions • Access control to provenance store • Delegation of identity / access control • Federated security

5. Integrity and non-repudiation of p-assertions • P-assertion is a subjective view of actor • Need to establish accountability for the creation of an assertion (non-repudiation) • Ensure that p-assertions are not altered after being created (integrity) • Directly implemented by signing p-assertions

6. Signed actor state p-assertion

7. Signed relationship p-assertion

8. Signed interaction p-assertion

9. Access control to provenance store • Mutual authentication between actors and provenance store • Secured communication link (encryption, signatures) • Appropriate authorisation scheme expressed in suitable authorisation policy language

11. PS

12. Actor Credential server Provenance store interfaces Identity validator Access control policy Trust mediator Remote Interactor Derivation engine Authorisation engine Authorisation policy Database backend Internal representation list Remote security domain Security architecture of hosting system

13. Delegation of identity / access control • Various components interact with each other in the logical architecture during a workflow run • Need to be authenticated or authorised to perform an action or access a resource on behalf of another component • Requires delegation of identity / access control

15. Provenance store Hospital Actors User Interface Brain Death Manager Donor Data Collector

16. User Proxy cert User cert Proxy cert Delegation of identity / access control Presentation UI Provenance store

17. Federated security • Provenance stores can be distributed for scalability reasons • Stores may be located in different security domains • Federation of identity may be required for actors in a given domain to interact securely with stores in separate domains.

18. Actor Credential server Provenance store interfaces Identity validator Access control policy Trust mediator Remote Interactor Derivation engine Authorisation engine Authorisation policy Database backend Internal representation list Remote security domain Security architecture of hosting system

19. Provenance Store Distribution - Bandwidth - Access Control - Storage PS PS PS

20. Security token service Security token Security token Actor Federated security / Single sign on – Approach 1 Provenance store – Security domain 1 Provenance store – Security domain 2

21. Security token service Security token Security token Security token Actor Federated security / Single sign on – approach 2 Provenance store – Security domain 1 Provenance store – Security domain 2

22. Secondary security issues • Checking asserter identity • Documentation style: signing, anonymous, encryption and reference digest • Integrity of referenced data • Setting authorization assertions for p-assertions

23. Checking asserter identity • Asserter identity is given in view of a p-structure • This should match with identity on verified signature on associated p-assertions

24. P-structure view

25. Signed actor state p-assertion

26. Documentation style • In the simplest case, creation of a p-assertion from original message exchanged involves copying the message content verbatim • Creation of a p-assertion from original message can also involve transformation of contents of original message for various reasons

27. Documentation style: Security relevant transformations • Encryption • Uses a secret key to encrypt parts of message that becomes the content of the created p-assertion • Querying actors with access to the secret key can retrieve the p-assertion and decrypt the encrypted portion • Anonymous • Some parts of the message are replaced by anonymous identifiers • Particularly relevant in environments where privacy is critical (e.g. patientID in hospital records)

28. Documentation style: Security relevant transformations • Signing • An asserting actor may receive proxy certificates from other actors • The keys in these proxy certificates can be used to sign parts of p-assertion by the asserting actor • Referenced-digest • P-assertions may contain references to data rather than the actual data • To ensure that the data that the reference is eventually resolved to was the original data, a digest of the original data is included along with the reference in p-assertion

29. Interaction in the Organ Transplant Process Request healthcare record for patient PID1 Donor Data Collector Electronic Healthcare Management System

30. Request Message Contents <soap:envelope> <soap:header>…</soap:header> <soap:body> <echrs:request> <echrs:patient> PID1 </echrs:patient> </echrs:request> </soap:body> </soap:envelope>

31. Documentation style: Anonymous <ps:interactionPAssertion> <ps:localPAssertionId>1</ps:localPAssertionId> <ps:documentationStyle> http://www.pasoa.org/.../styles#AnonymisedPatient </ps:documentationStyle> <ps:content> <soap:envelope> <soap:header>…</soap:header> <soap:body> <echrs:request> <echrs:anoymisedPatient>x78df2 </ echrs:anoymisedPatient> </echrs:request> </soap:body> </soap:envelope> </ps:content> </ps:interactionPAssertion>

32. Setting authorisation statements • Newly created p-assertions must have authorisation statements associated with them • These can be: • set statically by provenance store system administrator; • provided by the recording actor submitting the p-assertion; • The appropriate use depends on application dependent requirements

33. Summary • Primary security issues • Integrity and non-repudiation of p-assertions • Access control to provenance store • Delegation of identity / access control • Federated security • Secondary security issues • Checking asserter identity • Documentation style • Integrity of referenced data • Setting authorisation assertions for p-assertions

34. Questions ? Victor Tan vhkt@ecs.soton.ac.uk