1 / 36

Secure Message Delivery IHE Connectathon - 19 April 2010

The Future is E-Health. Secure Message Delivery IHE Connectathon - 19 April 2010. Building a Sealed Message. Public Key Infrastructure (PKI). Public Key Infrastructure: Key Concepts. Asymmetric Cryptography — public and private keys.

corin
Télécharger la présentation

Secure Message Delivery IHE Connectathon - 19 April 2010

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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)

More Related