Alternatives for Message Signature from Sender
Post on 02-Jan-2016
59 Views
Preview:
DESCRIPTION
Transcript
Alternatives for Message Signature from Sender1. Approach 1
– X12 58 to digitally sign X12 transaction set• Optional: X12 815 to transmit signer’s public key and/or location of Signer’s Public
Certificate
– Include Signer’s Public Certificate as binary object in SOAP body (SOAP gateway will use MTOM to convert binary data to MIME attachment)
– Signer’s Public Certificate could be either held in an esMD specific schema (e.g. <esMD:Certificate>) or added to CORE metadata
2. Approach 2– XML SIG in SOAP body to digitally sign payload– Include Signer’s Public Certificate as binary object in XML SIG– Digital Signature location could be either esMD specific schemas (e.g.
<esMD:Signature>) or added to CORE metadata
Alternatives for Delegation of Rights
1. Signed SAML Assertion included as XML in message header (WS-Security) or message body (esMD Metadata)
– Delegator of rights signs assertion containing issuer and serial number of public certificate of receiver of rights
2. Proxy certificate included as attachment in message body– Delegator of rights signs proxy certificate of receiver of rights
3. Signed X12 815 transaction set included in functional group of X12 message– X12 815 contains public key of receiver of rights– X12 58 is used to sign X12 815 with private key of delegator of rights
Comparison of approaches to transmitting esMD Security ArtifactsApproach Considerations
esMD Metadata • Applicable to both X12 and HPD Plus based esMD transactions• Leverages existing standards (XML SIG and SAML)• Specific to the esMD implementation guides• Could not use X12 999/824 to report errors in processing of security
artifacts. Need to select alternative error handling method.
X12 58 & X12 815 • Only applicable to X12 based transactions• X12 815 would require changes to support limited delegation of rights (e.g.
expiration date, usage)• X12 815 may require changes to carry x.509 certificate as binary object• Use for delegation of rights is new, may require new standard
Mixed Approach1. Signature: X12, Delegation:
WS-Security2. Signature: X12, Delegation:
Metadata3. Signature: Metadata,
Delegation: WS-Security
• WS-Security is specific to SOAP messages, different approach required for Direct
• Verification of holder-of-key assertion requires access to signature of delegated party
• Delegation requirements may not be clear if SOAP header is processed before payload
• X12 58 specific to X12 transactions, different approach required for HPD Plus based transactions in Use Case 1
esMD Security Metadata applied to supported transport options
Phase II CAQH CORE 270: Connectivity Rule Version 2.2.0 eHealth Exchange Direct
SAML Participants
• At a minimum, SAML exchanges take place between system entities referred to as a SAML asserting party, which makes SAML assertions, and a SAML relying party, which uses assertions it has received. Most SAML assertions are in regards to a Subject about whom the assertion is being made.
• When a SAML asserting or relying party makes a direct request to another SAML entity, the party making the request is called a SAML requester, and the other party is referred to as a SAML responder.
• A relying party's willingness to rely on information from an asserting party depends on the existence of a trust relationship with the asserting party.
• SAML system entities can operate in a variety of SAML roles which define the SAML services and protocol messages they will use and the types of assertions they will generate or consume.
− Example SSO Roles: Principal – Subject of Assertion Identity Provider – SAML asserting party Service Provider – SAML relying party
SAML Assertions
An assertion contains some basic required and optional information that applies to all its statements, and usually contains a subject of the assertion, conditions used to validate the assertion, and assertion statements.
1. Authentication statements: These are created by the party that successfully authenticated a user. At a minimum, they describe the particular means used to authenticate the user and the specific time at which the authentication took place.
2. Attribute statements: These contain specific identifying attributes about the subject (for example, that user “John Doe” has “Gold” card status).
3. Authorization decision statements: These define something that the subject is entitled to do (for example, whether “John Doe” is permitted to buy a specified item).
Confirmation Method
The SubjectConfirmation element provides the means for a relying party to verify the correspondence of the subject of the assertion with the party with whom the relying party is communicating. The Method attribute indicates the specific method that the relying party should use to make this determination.
SAML 2.0 accounts for three different security scenarios by defining three values for the Method attribute of the SubjectConformation element, these are• holder-of-key – the attesting entity demonstrates knowledge of specific key information
to use the assertion (and thereby lay claim to some relationship with the subject within).• sender-vouches - the relying party has an existing trust relationship with the attesting
entity. The attesting entity vouches for the subject of the assertion.• bearer - any party that bears the Assertion may use the assertion.
SAML Specifications
SAML consists of building-block components that, when put together, allow a number of use cases to be supported. The components primarily permit transfer of identity, authentication, attribute, and authorization information between autonomous organizations that have an established trust relationship.
1. Core: Defines the structure and content of both assertions and protocol messages used to transfer this information.
2. Protocols: Generalized methods to request assertions and respond to requests for assertions.
3. Bindings: Mappings of SAML protocols onto standard messaging and communication protocols.
4. Profiles: Combinations of assertions, protocols, and bindings to support a defined use case.
5. Metadata: Defines a way to express and share configuration information between SAML parties.
SAML Protocols
Requests and responses for obtaining assertions and doing identity management.
1. Assertion Query and Request Protocol: Defines a set of queries by which SAML assertions may be obtained. The Request form of this protocol can ask an asserting party for an existing assertion by referring to its assertion ID. The Query form of this protocol defines how a relying party can ask for assertions (new or existing) on the basis of a specific subject and the desired statement type.
2. Artifact Resolution Protocol: Provides a mechanism by which SAML protocol messages may be passed by reference using a small, fixed-length value called an artifact. The artifact receiver uses the Artifact Resolution Protocol to ask the message creator to dereference the artifact and return the actual protocol message. The artifact is typically passed to a message recipient using one SAML binding (e.g. HTTP Redirect) while the resolution request and response take place over a synchronous binding, such as SOAP.
3. Authentication Request Protocol
4. Single Logout Protocol
5. Name Identifier Management Protocol
6. Name Identifier Mapping Protocol
SAML Bindings
Mappings of SAML protocols onto standard messaging and communication protocols.
1. SAML SOAP Binding: Defines how SAML protocol messages are transported within SOAP 1.1 messages, with details about using SOAP over HTTP.
2. HTTP Redirect Binding: Defines how SAML protocol messages can be transported using HTTP redirect messages (302 status code responses).
3. HTTP POST Binding: Defines how SAML protocol messages can be transported within the base64-encoded content of an HTML form control.
4. SAML URI Binding: Defines a means for retrieving an existing SAML assertion by resolving a URI (uniform resource identifier).
5. HTTP Artifact Binding: Defines how an artifact (described above in the Artifact Resolution Protocol) is transported from a message sender to a message receiver using HTTP. Two mechanisms are provided: either an HTML form control or a query string in the URL.
SAML Profiles
Combinations of assertions, protocols, and bindings to support a defined use case.
1. Assertion Query/Request Profile: Defines how SAML entities can use the SAML Query and Request Protocol to obtain SAML assertions over a synchronous binding, such as SOAP.
2. Artifact Resolution Profile: Defines how SAML entities can use the Artifact Resolution Protocol over a synchronous binding, such as SOAP, to obtain the protocol message referred to by an artifact.
3. SSO Profiles of SAML
4. Name Identifier Mapping Profile
5. SAML Attribute Profiles
Example 1: esMD Use Case 1
A Provider delegates eMDR registration to an HIH. A SAML Assertion is used to communicate this delegation to the payer.• Participants
‒ SAML Asserting Party: Provider (or trusted third party SAML Service)‒ SAML Relying Party: Payer‒ Subject of SAML Assertion: HIH
• The HIH signs the registration request using their private key.• Either the HIH or Payer requests an assertion from the Provider/SAML Service. • The Provider/SAML Service signs the HIH’s public key and places this in the
SubjectMethod of the Assertion which is then sent to the requestor.• The Payer uses the public key provided in the SubjectMethod to verify the signature of the
HIH on the registration request.• If the signature is valid, the requirements of the Holder-of-Key confirmation method are
satisfied. The Payer knows that the HIH is the Subject of the Assertion and any assertions the Provider/SAML Service has made apply to that HIH.
Use of SAML for esMD Delegation of RightsBenefits• Provides structured format to exchange assertions• Holder-of-Key Confirmation Method aligns well to esMD requirements• OASIS specifications can be combined to support variety of use cases
Considerations• Providers/SAML Service, HIHs, and Payers must support components of SAML including
SAML Core and any implementation specific profiles• Either the Provider or a trusted third party SAML Service working on their behalf would
require a SAML endpoint capable of creating and signing assertions using their private key• SAML Assertions are usually generated and consumed for a specific request and not
stored or exchanged as documents for long periods of time
Transaction TimelineAn esMD transaction begins with the creation of some type of electronic content (e.g. X12 274, 277, or 275 message or an HPD Plus DSML, CDA, or PDF document). As the content is packaged into a message and sent, security elements are added at points along the timeline dependent on the standard(s) selected and the purpose of the security element. This process is reversed on the receiving end.
Electronic Content Created
Content Stored as a document
XD* Metadata
Content packaged
into payload
Message created
Message Sent
DSG Signature
X12 58 Signature
WS-Security Encryption
(transport level)
CAQH CORE Metadata
Internal Systems Gateway
Message Received
Process Header
Process Payload
X12 58 Signature
WS-Security
CAQH CORE/ XD* Metadata
Process Content
DSG Signature
Internal Systems
GatewayInternet
Store Content
IHE DSGThe Document Digital Signature (DSG) content profile specifies the use of XML Advanced Electronic Signatures (XAdES) for documents that are shared between organizations.
Process Flow for Phase 1 Sending Medical Documentation
Transaction Structure
Extensions to MetadataThis approach would extend existing metadata to support the exchange of the required security information. For esMD, this would require extensions to CAQH CORE and XD* metadata. We would need to work with the relevant organizations to seek inclusion of these changes in future specifications.
Process Flow for UC1 Registration
Transaction Structure
X12 58This standard defines the data formats for authentication, encryption, and assurances in order to provide integrity, confidentiality, and verification and non-repudiation of origin for two levels of exchange of EDI formatted data defined by ASC X12.
Process Flow for UC1 Registration
Transaction Structure
WS-SecurityThis specification extends SOAP Messages to provide three main security capabilities: the ability to send security tokens as part of a message, message integrity, and message confidentiality.
Process Flow for UC1 Registration
Transaction Structure
Identity Requirements
Requirement Description Registration Send eMDR
Send eMD
Include Sender's public digital certificate in transaction
- Receiver traces certificate to root CA in order to verify sender's identity.- Receiver uses public key and digital signature to verify authenticity.
y y y
Include additional public digital certificates in transaction
- Transaction includes public digital certificates of all other parties that have digitally signed something in the transaction.- Receiver traces certificates to root CAs in order to verify identity of all parties that have digitally signed something in the transaction.- Receiver uses public keys and digital signatures to verify authenticity of all parties that have digitally signed something in the transaction.- Receiver uses certificates to verify all delegation of rights artifacts created by all parties that have digitally signed an assertion
y n y
Authenticity Requirements 1/2
Requirement Description Registration Send eMDR
Send eMD
Digital Signature of portion of transaction (message)
- All parties that interact with transaction can sign it - Receiver uses digital signature to verify authenticity of message across all hops
n n n
Digital Signature of entire transaction (message)
- Sender of message can sign it - Receiver uses digital signature to verify authenticity of message
y y y
Digital Signature of a contributor to a document (payload)
- Multiple content creators sign relevant portions of payload- Receiver uses digital signatures to verify authenticity of content
n n Level 1 - nLevel 3 - y
Digital Signature of an entire document (payload)
- Single content creator signs entire payload- Receiver uses digital signatures to verify authenticity of content
n n Level 1 - nLevel 2 - y
Digital Signature of an aggregation of documents (payload)
- Single content creator signs entire payload- Receiver uses digital signatures to verify authenticity of content
n n Level1 - y
Authenticity Requirements 2/2
Requirement Description Registration Send eMDR
Send eMD
Supports digital signature chains
- Receiver understands the order in which digital signatures were applied - Receiver understand what part of the transaction each digital signature applies to
y n y
Supports long term validation of digital signatures
- Receiver can validate digital signature up to twenty years after signing- Example: Content creator adds time-stamped and CA signed OCSP response or CRL to content at time of creation
n n y
Authority Requirements
Requirement Description Registration Send eMDR
Send eMD
Include single delegation of rights artifacts in transaction
- Party A delegates a right to Party B who may not delegate that right to any other party
n n n
Include multiple delegation of rights artifacts in transaction
- Party A delegates a right to Party B who may delegate that right to Party C
y n y
Encryption Requirements
Requirement Description Registration Send eMDR
Send eMD
Support encryption of components of payload at point of creation
- Content creator encrypts portions of the payload
n n Level 1 - n Level 3 - ?
Support encryption of entire payload at point of creation
- Content creator encrypts entire payload n n Level 1 - nLevel 2 - ?
Note: esMD assumes transport level encryption is in place. Payload encryption is still under consideration
General Requirements
Category Requirement Description Registration Send eMDR
Send eMD
Location Security elements are included in payload
- Security elements are tied to payload and will be processed by internal systems rather than gateway
y (Delegation of Rights)
n y
Existing Standard
Created and maintained by SDO
- Uses existing standard y y y
Applicable Standard
X12 274 - Supports the exchange of provider information
y n n
Applicable Standard
IHE HPD+ - Supports the exchange of provider information
y n n
Applicable Standard
X12 277 - Supports the exchange of requests for additional information regarding a claim
n y n
Applicable Standard
X12 275 - Supports the exchange of additional information regarding a claim
n n y
Applicable Standard
HL7 CDA - Supports the exchange of patient clinical information
n n y
Use Case 1: Requirements for RegistrationCategory Requirement DSG X12 58 WS-
SecurityMetadata Extension
s
Identity Include Sender's public digital certificate in transaction
n ? y y
Identity Include additional public digital certificates in transaction
y ? y y
Authenticity Supports digital signature chains ? 2? y y
Authenticity Digital Signature of entire transaction (message)
n n y n
Authority Include multiple delegation of rights artifacts in transaction
y n ? y
Authority Supports delegation of rights artifact chains ? n ? y
Existing Standard Created and maintained by SDO y y y n
Applicable Standard X12 274 ? y y y
Applicable Standards IHE HPD+ y n y y
Location Security requirements are included in payload
y y? n y
Use Case 2: Requirements for Sending eMDRs
Category Requirement DSG X12 58 WS-Security
Metadata Extensions
Identity Include Sender's public digital certificate in transaction
y ? y y
Authenticity Digital Signature of entire transaction (message)
n n y n
Existing Standard Created and maintained by SDO y y y n
Applicable Standard X12 277 ? y y y
Phase 1: Requirements for Sending Electronic Medical Documentation
Category Requirement DSG X12 58 WS-Security
Metadata Extensions
Identity Include Sender's public digital certificate in transaction
y ? y y
Identity Include additional public digital certificates in transaction
y ? y y
Authenticity Supports digital signature chains ? ? y yAuthenticity Supports long term validation of digital
signaturey ? y y
Authenticity Digital Signature of entire transaction (message)
n n y n
Authenticity Digital Signature of an aggregation of documents (payload)
y y/n y/n y/n
Authority Include multiple delegation of rights artifacts in transaction
y n ? y
Authority Supports delegation of rights artifact chains ? n ? yLocation Security elements are included in payload y y n nExisting Standard Created and maintained by SDO y y y nApplicable Standard X12 275 ? y y yApplicable Standard HL7 CDA y n y y
Conclusions
• No single standard/specification supports all requirements for all use cases• Support for some requirements depends on implementation details
• Example: WS-Security can sign an entire message or a portion of a message, including the payload. However, this signature would usually be processed by the SOAP gateway and unavailable to the internal information systems.
• A mix of standards may be required, each one selected to fulfill a specific requirement
IHE DSG
Strengths- Supports transmission of signatures and certificates- Based on XMLSig and XAdES which provides long-term validation of signatures- Can be used to sign any kind of document- XML transforms are not required- Signatures applied to payload and processed by internal system- Potentially meets AoR Level 2 requirements
Weaknesses- Receiver must track both signed document and signature document- Applicability limited to signing of documents- Probably does not meet AoR Level 3 requirements
Extensions to Metadata
Strengths- Potentially designed to meet exact needs of esMD- Signatures applied to payload and processed by internal system
Weaknesses- May require changes to existing standards- Relevant SDOs may choose to not adopt changes
Alternatives- MIME Attachments: Attach various security artifact files to payload using appropriate
MIME content-type
X12 58
Strengths- Standard across all X12 transactions- Applies signature at payload level
Weaknesses- Only applicable to X12 transactions- Requires separate transaction to exchange certificates- Requires maintenance of certificates apart from transaction- No support for Delegation of Rights
WS-Security
Strengths- Supports transmission of signatures and certificates- Easily supported in all SOAP based transactions- Based on XMLSig standard- Can support XAdES which provides long-term validation of signatures- Supports exchange of SAML Assertions (for Delegation of Rights)
Weaknesses- Signatures are applied to message and processed at gateway- Gateway would require additional configuration to pass signatures, certificates, and SAML
Assertions to internal system- No definitive specification binding SOAP over SMTP for Direct purposes
Alternatives- S/MIME: Default signing and encryption of Direct messages
Security Approach 1Message• Metadata extension contains XML Signature of message and certificate used to verify message• Metadata extension contains SAML Assertion of message and certificate used to verify message
Phase 1 Payload• IHE DSG to sign document bundle
• NwHIN/CORE: ZIP file containing document bundle and signature document placed in 275 BIN segment• Direct: ZIP file containing document bundle and signature document sent as attachment to payload
Strengths- Leverages existing standards- Supports transmission of signatures and certificates- All signatures based on XMLSig standard- Supports XAdES signature on document bundle, which provides for long-term validation of signature- Supports exchange of SAML Assertions for Delegation of Rights- Does not preclude use of X12 58 if required by trading partners
Weaknesses- Receiver must maintain attachments and track relationships between files- Approach is not completely transport neutral
Use Case 1: Transaction Process Flow
Registration Request
Delegation of Rights Artifact
Signature of Registration Request
Public Certificate of Registration Requestor
Assertion of Rights
Signature of Assertion
Public Certificate of Assertor
Delegation of Rights Artifact
Registration Request Message
Owner Process Standards
Registration Requestor
Request Delegation of Rights Artifact from Assertor of Rights • SAML Query
Assertor of Rights
Create Assertion • SAML
Sign Assertion and attach certificate • XMLSig
Provide Delegation of Rights Artifact to Registration Requestor • SAML Response
Registration Requestor
Create Registration Request • Payload: X12.274, HPD
Attach Delegation of Rights Artifact and attach Certificate of Subject • SAML Assertion
Sign Registration Request Message and attach certificate • XML Signature
Send Registration Request Message • NwHIN/CORE• Direct
Payer/Payer Contractor
Trace Certificate of Registration Requestor to Root CA • XML Signature
Verify Signature of Registration Request • XML Signature
Verify Delegation of Rights Artifact • SAML Assertion
Process Registration Request • Payload: X12.274, HPD
Use Case 2: Transaction Process Flow
eMDR Message
eMDR
Signature of eMDR
Public Certificate of Payer/Payer Contractor
Owner Process Standards
Payer/Payer Contractor
Create eMDR • Payload: X12.277
Sign eMDR Message and attach certificate • XML Signature
Send eMDR Message • NwHIN/CORE• Direct
eMDR Consumer
Trace Certificate of Payer/Payer Contractor to Root CA • XML Signature
Verify Signature of eMDR • XML Signature
Process eMDR • Payload: X12.277
Phase 1: Transaction Process FlowSigned Medical
Document Bundle
eMDR Response Message
eMDR Response
Document Bundle Attachment
Signature of eMDR Response
Public Certificate of eMDR Consumer
Medical Document Bundle
Signature of Document Bundle
Public Certificate of Document Bundle Owner
Owner Process Possible Locations and Standards
EHR/Provider
Assemble Medical Document Bundle • Payload: PDF, CDA, ZIP
Sign Document Bundle • Payload: DSG
Attach Public Certificate • Payload: DSG
Provide Medical Document Bundle Attachment to eMDR Consumer • Outside esMD scope
eMDR Consumer
Create eMDR Response • Payload: X12.275, XD*
Add Document Bundle Attachment • Payload: BIN Seg, Attachment
Sign eMDR Response and attach certificate • XML Signature
Send eMDR Response Message • NwHIN/CORE• Direct
Payer/Payer Contractor
Trace Certificate of eMDR Consumer to Root CA • XML Signature
Verify Signature of eMDR Response • XML Signature
Process eMDR Response • Payload: X12.275, XD*
Consume Document Bundle • Payload: DSG
Signature Artifact
The Signature Artifact (paired with the Public Digital Certificate of the Sender) will enable the message receiver to authenticate the sender, verify message integrity, and prove non-repudiation.
1. Public Digital Certificate of Sender – x.509 certificate issued by a Certificate Authority
2. Signature Artifact – Encrypted message digest*
* The exact details of the Signature Artifact are being developed in the esMD Author of Record Initiative.
Public Key of Dr. Smith
Signature Artifact Example
1. Dr. Smith attaches signature artifact to Request to Register to Receive eMDRs
Registration Request
Provider Name: Dr. SmithNPI: 987654Service: Receive eMDRs
MetadataEncrypted Message Digest: H8K9QTPPublic Digital Certificate of Dr. Smith
hash functionMessage Digest:
987654 signature algorithm
Private Key of Dr. Smith
2. Payer verifies the Request came from Dr. Smith and has not been tampered with
Registration Request
Provider Name: Dr. SmithNPI: 987654Service: Receive eMDRs
MetadataEncrypted Message Digest: H8K9QTPPublic Digital Certificate of Dr. Smith
hash function Message Digest: 987654
signature algorithm
Verify Identity
Message Digest: 987654
Verify Integrity
Delegation of Rights Artifact
The Delegation of Rights Artifact (paired with the Public Digital Certificate of Subject) enables the Subject to delegate a right to the Sender of a Request such that the Receiver can cryptographically confirm that delegation of rights has occurred.
1. Public Digital Certificate of Subject – x.509 certificate issued by a Certificate Authority
2. Delegation of Rights Artifact – Encrypted message digest of an assertion of rights*
* The exact details of the Delegation of Rights Artifact are being developed in the esMD Author of Record Initiative.
Delegation of Rights Example (1/2)
1. Dr. Smith delegates the right to register his NPI to receive eMDRs to Medical Data, Inc.
Registration Request
Provider Name: Dr. Bob SmithNPI: 987654Service: Receive eMDRs
MetadataEncrypted Message Digest: H8K9QTPPublic Digital Certificate of Medical Data, Inc.Delegation of Rights ArtifactPublic Digital Certificate of Dr. Smith
2. Medical Data, Inc. include their Signature Artifact, Dr. Smith’s Delegation of Rights Artifact, and both Public Digital Certificates in their Request to Register Dr. Smith to Receive eMDRs
Assertion of Rights
Dr. Bob Smith gives Medical Data, Inc. the right to register his NPI to receive eMDRs.Expiration Date: 1/1/2013
MetadataEncrypted Message Digest: U37G90P
hash function Message Digest: 123456 signature algorithm
Private Key of Dr. Smith
Delegation of Rights Example (2/2)
Registration Request
Provider Name: Dr. Bob SmithNPI: 987654Service: Receive eMDRs
MetadataEncrypted Message Digest: H8K9QTPPublic Digital Certificate of Medical Data, Inc.Delegation of Rights ArtifactPublic Digital Certificate of Dr. Smith
3. Payer verifies Medical Data, Inc. has the right to register Dr. Smith to receive eMDRs
Public Key of Dr. Smith
Assertion of Rights
Dr. Bob Smith gives Medical Data, Inc. the right to register his NPI to receive eMDRs.Expiration Date: 1/1/2013
MetadataEncrypted Message Digest: U37G90P
hash function Message Digest: 123456
signature algorithm Message Digest: 123456
Verify Right
top related