Secure Message Delivery IHE Connectathon - 19 April 2010

1. The Future is E-Health Secure Message DeliveryIHE Connectathon - 19 April 2010

2. Building a Sealed Message Public Key Infrastructure (PKI)

3. Public Key Infrastructure:Key Concepts • Asymmetric Cryptography —public and private keys. • Key Encryption — a message encrypted with a recipient's public key cannot be decrypted by anyone except a possessor of the matching private key. This is used for confidentiality. • Digital Signing — a message signed with a sender's private key can be verified by anyone who has access to the sender's public key. This is used for identification and authenticity.

4. Public Key Infrastructure:Structure of an X.509 Certificate • Subject (CN=Common Name) • Subject Alternate Name (URI,DNS,email) • Issuer • Validity (Not Before, Not After) • Certificate Policy • Key Usage

5. Public Key Infrastructure: How to check validity and t rust • Check date validity (not before, not after) • Check issuer is a CA that you trust and that the issuer signed the certificate • Optionally, check certificate has not been revoked • Certificate Revocation List (CRL), • Online Certificate Status Protocol (OCSP)

6. Public Key Infrastructure: Issues with Certificates • CRL and OCSP Checking • Old Medicare test certs have invalid CRL (http://www.hesageek.com.au...) • Medicare Location Certs have split key usage • Digital Signing (can use in TLS client) • Key Encipherment (can’t use in TLS client!)

7. Building a Sealed Message Transport Layer Security (TLS) (Successor to SSL)

8. Transport Layer security:What is TLS? • Provides endpoint authentication and communication encryption over the Internet. • Unilateral: Only the server is authenticated (the client can identify the server). Most common form of TLS. • Bilateral: Both endpoints are authenticated (both endpoints know the identity of the other endpoint). Also known as mutual authentication as required by SMD.

9. Transport Layer security: TLS Client Keystore • The TLS client keystore must contain the private credentials of the client organisation: • NASH HPI-O Process Certificate; OR • Medicare Facility Certificate (with KeyUsage of DigitalSignature). (IE/.NET: Private credentials in Personal certificate store)

10. Transport Layer security: TLS Server Keystore • The TLS server keystore must contain the private credentials that identify the server: • NASH SSL Server Certificate; OR • NASH HPI-O Process Certificate (with SubjAltName/DNS); OR • Trusted CA issued server certificate (e.g. Verisign). (you can’t use Medicare certificate for server identification)

11. Transport Layer security: TLS Client Truststore • The TLS client truststore must contain the set of certificate authorities that you trust to issue server certificates: • NASH OrgCA and RootCA public certificates; AND • Commonly trusted CAs (e.g. Verisign). (IE/.NET: OrgCA in IntermediateCertification Authorities, RootCA in Trusted Root Certification Authorities)

12. Transport Layer security: TLS Server Truststore • The TLS server truststore must contain the set certificate authorities that you trust to issue TLS client certificates: • NASH OCA and RCA public certificates; OR • Medicare OCA and RCA public certificates. (as a server, you need to be able to identify the client: only support NASH and Medicare client certificates)

13. Building a Sealed Message Building a Sealed Message

14. Building a Sealed Message: Part 1 – XML Wrapping • Wrap raw payload in XML <msg:message> <data>{base64 of raw payload}</data> </msg:message> • Nothing to do if already XML

15. Building a Sealed Message: Part 2 – XML Signature • Sign the XML Payload • Sign with private key of sender organisation: <sp:signedPayload … /> • Existing code: • NEHTA has released XSP sample code in Java and C# • XSP library supporting Standards Aust version in SMDA source release

16. Building a Sealed Message: Part 3 – XML Encryption • Encrypt the Signed XML Payload • Encrypt with public certificate of receiver organisation (from ELS interaction): <ep:encryptedPayload … /> • Existing code • NEHTA has released XSP sample code in Java and C# • XSP library supporting Standards Aust version in SMDA source release

17. Building a Sealed Message: Part 4 – Putting it all together • Build the Sealed Message:<smsg:message> <metadata> <creationTime … /> <expiryTime … /> <invocationId … /> <receiverOrganisation … /> <senderOrganisation … /> <serviceCategory … /> <serviceInterface … /> <routeRecord> <sendIntermediateResponses … /> <interaction … /> </routeRecord> </metadata> <ep:encryptedPayload … /></smsg:message>

18. Building a Sealed Message:creationTime • creationTime – The date and time (in UTC timezone) the message was created. • <creationTime>2010-04-12T13:25:20.665Z</creationTime> • (Hopefully the UTC requirement will be dropped in a future revision of the standard – standard tools (e.g. JAXB) use local time with a UTC offset – e.g. “+10:00” – which is a perfectly valid encoding for a xsd:dateTime).

19. Building a Sealed Message:expiryTime • expiryTime – The date and time (in UTC timezone) by which a final transport response for the message is expected to arrive. • <expiryTime>2010-04-13T13:25:20.665Z</expiryTime> • (This is optional in XSD, but mandatory for deferred mode in the SMD standard – it does not make sense for immediate mode).

20. Building a Sealed Message:invocationId • invocationId – A unique identifier of the message: • A UUID encoded as a URN; • A URL based on the sender’s domain name, followed by an identifier that is unique for the sender. • <invocationId> urn:uuid:42ab3c5-35fd-4e98-9156-3c63f41ffa44 • </invocationId> • (Note the “urn:uuid:” prefix)

21. Building a Sealed Message:receiverOrganisation • receiverOrganisation – qualified identifier for the receiver. • <receiverOrganisation> • http://ns.electronichealth.net.au/id/hi/hpio/1.0/8003625678914916 • </receiverOrganisation> • The defined qualifiers are: • HPI-O: http://ns.electronichealth.net.au/id/hi/hpio/1.0/ • Medicare RA:http://ns.electronichealth.net.au/smd/id/ra/

22. Building a Sealed Message:senderOrganisation • senderOrganisation – qualified identifier for the sender. • <senderOrganisation> • http://ns.electronichealth.net.au/id/hi/hpio/1.0/8003625678983955 • </senderOrganisation> • The defined qualifiers are: • HPI-O: http://ns.electronichealth.net.au/id/hi/hpio/1.0/ • Medicare RA:http://ns.electronichealth.net.au/smd/id/ra/

23. Building a Sealed Message:serviceCategory • serviceCategory – the service category associated with the invocation. Provides information on the contents of the message payload. • <serviceCategory> • http://ns.ahml.com.au/smd/sc/2.16.840.1.113883.2.3.3.14.1.1.3 • </serviceCategory> • Reference: http://www.ahml.com.au/smd/servicecategories

24. Building a Sealed Message:serviceInterface • serviceInterface – the service interface associated with the invocation. Both the invoker (client) and service provider (server) must support this interface to achieve communication. • <serviceInterface> • http://ns.electronichealth.net.au/smd/intf/SealedMessageDelivery/TLS/2010 • </serviceInterface> • Reference: ATS 5822-2010

25. Building a Sealed Message:routeRecord • routeRecord(s) – Interactions for the delivery of transport responses. If the message travels via intermediaries, there may be multiple routeRecords in the message received by the Receiver. • <routeRecord> • <sendIntermediateResponses>true<sendIntermediateResponses> • <interaction> • <target>http://ns.electronichealth.net.au/id/hi/hpio/1.0/8003629000000003<target> • <serviceCategory> • http://ns.electronichealth.net.au/smd/sc/TransportResponseDelivery/2010 • <serviceCategory> • <serviceInterface> • http://ns.electronichealth.net.au/smd/intf/TransportResponseDelivery/TLS/2010 • </serviceInterface> • <serviceEndpoint> • https://smda-test-server:8081/smdaDeliveryServer/responseDelivery • </serviceEndpoint> • <serviceProvider>http://ns.electronichealth.net.au/id/hi/hpio/1.0/8003629000000003</serviceProvider> • </interaction> • </routeRecord>

26. Building a Transport Response

27. Building a transport response • Build the Transport Response<response> <metadata> <transportResponseTime … /> <responseId … /> <sourceOrganisation … /> <serviceCategory … /> <invocationId … /> <receiverOrganisation … /> <senderOrganisation … /> </metadata> <deliveryResponse> <responseClass … /> <responseCode … /> <message … /> <digestValue … /> </deliveryResponse> <final … /></response>

28. Building a Transport Response:transportResponseTime • transportResponseTime – The date and time (in UTC timezone) the transport response was created. • <transportResponseTime> • 2010-04-12T13:25:20.665Z • </transportResponseTime>

29. Building a Transport Response:responseId • responseId – A unique identifier of the transport response: • A UUID encoded as a URN; • A URL based on the sender’s domain name, followed by an identifier that is unique for the sender. • <responseId> • urn:uuid:42ab3c5-35fd-4e98-9156-3c63f41ffa44 • </responseId> • (Note the urn:uuid: prefix)

30. Building a Transport Response:sourceOrganisation • sourceOrganisation – qualified identifier of the originator of the transport response. • <sourceOrganisation> • http://ns.electronichealth.net.au/id/hi/hpio/1.0/8003625678914916 • </sourceOrganisation> • The defined qualifiers are: • HPI-O: http://ns.electronichealth.net.au/id/hi/hpio/1.0/ • Medicare RA:http://ns.electronichealth.net.au/smd/id/ra/

31. Building a Transport Response:serviceCategory, invocationId, receiverOrganisation, senderOrganisation • serviceCategory, invocationId, receiverOrganisation and senderOrganisation are copied directly from the metadata of the received message. • <serviceCategory> • http://ns.ahml.com.au/smd/sc/2.16.840.1.113883.2.3.3.14.1.1.3 • </serviceCategory> • <invocationId> urn:uuid:42ab3c5-35fd-4e98-9156-3c63f41ffa44 • </invocationId> • <receiverOrganisation> • http://ns.electronichealth.net.au/id/hi/hpio/1.0/8003625678914916 • </receiverOrganisation> • <senderOrganisation> • http://ns.electronichealth.net.au/id/hi/hpio/1.0/8003625678983955 • </senderOrganisation>

32. Building a Transport Response:deliveryResponse - responseClass • responseClass – Success, Error, Information or Warning. • <deliveryResponse> • <responseClass>Success</responseClass> • … • </deliveryResponse> • Reference: ATS 5822-2010 • (Note: A ‘final’ response must be either Success or Error and an ‘intermediate’ response must be either Information or Warning).

33. Building a Transport Response:deliveryResponse - responseCode • responseCode – A URI that may sub-classify the class of response. • <deliveryResponse> • <responseCode> • http://ns.electronichealth.net.au/smd/codes/Success • </responseCode> • </deliveryResponse> • Reference: ATS 5822-2010 – Appendix E2

34. Building a Transport Response:deliveryResponse - message • message – A user-friendly description of the reason for response. • <deliveryResponse> • <message>Ok</message> • </deliveryResponse>

35. Building a Transport Response:deliveryResponse - digestValue • digestValue – The digest from the signature block of the signed container in the received message. • <deliveryResponse> • <digestValue>1bhkCR5XxZqUIgDXeE+LSB524eo=</digestValue> • </deliveryResponse> • (Should be no need to recalculate – it is available in the XML signed payload)

36. Building a Transport Response:final • final – true if the message was successfully delivered to the receiver or an unrecoverable error. • <final>true</final> • (Transport responses with final=true are normally sent by the Receiver, but may be sent by an Intermediary if it is known that the message can never be delivered to the Receiver)