This Standard Guide gives the framework and implementation details for implementing secureend-to-end EDI communication focusing on HL7. It is based on the Standard Guide for HL7Communication Security and addresses system implementers.

Starting with an introduction into security services and general requirement for application andspecially for communication security, in chapter 6 the fundamental security services needed asstrong mutual authentication and securing information exchange by securing control

data andmessage data as well are described mentioning possible security attacks, security requirements andproposed implementations of solutions. In that context, different exchange protocols are reflected.Regarding accountability, different non-repudiations services are discussed in detail.

(in the sense of non-repudiation of origin and receipt) asdescribed and defined in the Standard Guide for EDI Communication Security [HL7CommSec].Communication security is related to enhancement of the whole message cryptographically, likemessage signing and message encryption, regardless of its internal structure.

Following the recommendations of the Standard Guide for EDI Communication Security thesolution for secure communication of EDI messages presented in this standard guide is based uponpublic key cryptography within a proper security infrastructure (public key infrastructure = PKI).

In the first part, the fundamentals of the solution are described independently of thecommunication protocol used. For each security service selected the specific structure and contentsof tokens exchanged between client and server is described. This includes all security servicesproposed in the Standard Guide for EDI Communication Security as strong mutual authentication,integrity, confidentiality as well as non-repudiation of origin and receipt.

Subsequently the communication protocol for token exchange is presented in detail serving as themost convenient mechanism next to the paradigm of EDI communication in client/serverarchitectures. This protocol is called the secure file transfer protocol (SFTP) that is a securityenhanced version of the unsecure RFC0959 compliant FTP.

6

Security Services and General Realisation

After giving some basic information about the public key infrastructure and the notation used

inthis standard guide, this part selects the security services needed for the control and dataconnection regarding the Standard Guide for EDI Communication Security. Then, for each servicethe general realisation is given independently of the communication protocol used. Possible attacksand countermeasures are considered and the resulting structure and contents of the tokensexchanged are presented.

6.1

Fundamentals and Notation

This approach is based upon public key cryptography using asymmetric security

techniques andsymmetric security techniques as well. The latter is only taken for bulk data encryption withinhybrid encryption employing a symmetric session key. Trust is established by a public keyinfrastructure (PKI) using trusted public keys certified by a certification authority (CA). For thispurpose, X.509 certificates are applied that are stored and managed in X.500 directories.

6

Different key pairs

MUST be used for authentication, digital signature generation/verification andencryption/decryption to avoid security compromise by (possibly adaptive) chosen-text attackswhere the intruder chooses challenges to extract information about the key. ThisMAY

be possiblesince the private key is used to compute the response and thus it may reveal partial

information.Hence, there are cryptographic needs for key separation requiring the use of one key for eachpurpose. For key separation the notation given inTable6-1

is used in the following.

The main symbol indicates the kind of asymmetric key (PrK

for private key andPK

for publickey), whereas the upper index denotes the key usage (auth

for authentication,digSig

for digitalsignature generation/verification, andcrypt

for encryption/decryption) and the lower one identifiesthe owner of the key (client

for client,server

for server andca

for the CA).

Table6-1: Key separation by key usage

Notation

Usage

authPrK

Private key for authentication (generation of digital signature)

digSigPrK

Private key for integrity service (generation of digital signature)

cryptPrK

Private key for decryption

authPK

Public key for authentication (verification of digitalsignature)

digSigPK

Public key for integrity service (verification of digital signature)

cryptPK

Public key for encryption

Strong security measures

MUST be achieved by using strong cryptographic mechanisms andpublic key certificates following X.509 that MUST be verified before usage every time. Forverification, the public key certificate of the CA for digital signature verification (digSigCAPK) isneeded. This certificate MUST be checked itself before usage. Certificate verificationMAY

involve directory or local cache access that is performed prior to the authentication exchange.

Fortoken formatting, the tag-length-value (TLV) format MUST be applied. Each token field ispreceded by a tag-byte specifying

the type of data and a length-word (first is low byte) determiningthe amount of data following as shown inTable6-2. The concatenation of tokens is expressedby

”||”.

Table6-2: Tag-Length-Value format of tokens

Token Offset

Purpose

0x0000

TAG-byte (identifies the type of data)

0x0001

LEN-byte (low-byte of amount of data)

0x0002

LEN-byte (high-byte of amount of data)

0x0003

and following

DATA-bytes (data)

6.2

Strong Mutual Authentication

HL7 realises event driven exchange of messages between healthcare applications. Depending onspecific circumstances or protocols used, the communicating principals may also include thehuman information systems user. As a basic requirement, the communicating principals MUST be

7

authenticated mutually. Because the solution implemented is intended to be open and flexible alsoallowing inter-protocol communication, different use cases must be reflected. In that context, thesolution has to befitted into the security environment, e.g., the European security infrastructure.

Following the Standard Guide for EDI Communication Security, asymmetric techniques areapplied for strong authentication. Before mutual trust between client and server can be established(the client is authenticated to the server and vice versa), the human user must authenticate oneselfto a cryptographic module of the local end system (user authentication), which then acts as aninitiator (client) and performs the digital signature generation and verification on behalf of thehuman user towards the responder (server) carrying outsystem authentication.

As recommended in the Standard Guide for EDI Communication Security, human userauthenticationSHOULD

be carried out by ISO/IEC7816 compliant chipcards (HPC) incombination with PIN code. During the a communication session, the chipcard needs to be keptinserted in the chipcard terminal for timed chipcard request. When removing the chipcard, theapplication MUST inhibit further

operations and only continues to work, if the chipcard is insertedagain and the subsequently user authentication is performed successfully.

The strong authentication of an initiator to the responder depends on the successful verification ofthe initiator‘s digital signature binding with its key pair and on a successful verification of theinitiator’s digital signature (signing means showing the possession of the secret key) on a randomnumber challenge generated by the responder. Accordingly, for mutualauthentication thesuccessful authentication of the responder to an initiator is checked. The binding of a principal’sunique identifier, i.e. the distinguished name (DN), with its key pair is essential for proving theauthenticity of its identity and must

be checked prior to any authentication exchange. This isachieved by user authentication following verification of X.509 public key certificates retrievedfrom a X.500 directory.

Protocols for strong mutual authentication using asymmetrical security techniques can be found in[ISO/IEC 9798-3],[FIPS196]

and[X509]

chapter 10. There are some differences between thesethree sources concerning the authentication data structure, particularly regarding what token fields(such as digital signature, random numbers, time stamps and DNs) are recommend or optional ineach step and what fields are covered by the digital signature. The order of authentication (first, theclient is authenticated to the server, and afterwards the server is authenticated to the client in turn)remains the same, of course. Mutual authentication is performed by a three-waychallenge-response-protocol for security and efficiency reasons limiting the amount of tokensexchanged.

The authentication procedures defined in[X509]

are intended to be used between directory useragents (DUAs), but mainly follow the other specifications. Random numbers are used incombination with time stamps.

[ISO/IEC 9798-3]

serves as a basis for the authentication protocols defined in[FIPS196]

andspecifies different protocols addressing both unilateral and mutual entity authentication, that makeusage of public

key cryptography algorithms.

In[FIPS196]

only one protocol for each unilateral and mutual authentication has been selectedfrom[ISO/IEC 9798-3]

and certain authentication token fields and protocol steps are described ingreater detail than in the ISO specification. Furthermore,[FIPS196]

is less strict allowing thearbitrary ordering of token fields. The appendices A to D of this specification contain severaloptional methodsand set of rules for formatting and encoding authentication information (ASN.1Notation and CER/DER encoding, Simple Public Key GSS-API Mechanism (SPKM), formattingbased on ANSI X9.26-1990 and Base64 encoding) helping to promote the interoperability ofvarious implementations of the authentication protocols defined. These appendices are providedfor informational purposes only, and are not part of the standard. Formatting and encoding is left to

8

the discretion of the implementers. Moreover, to avoid the use of synchronised clocks to verify thetimeliness of authentication tokens, authentication exchanges using time stamps were not chosenfor[FIPS196]. Beyond, sequence numbers have not been chosen, due to their requirement ofmaintaining sequence number log tables. Random number challenges are used for both timestamps and sequence numbers, instead. Finally, biometric authentication techniques are notincluded, but discussed in[FIPS190].

For the protocol presented in the following, all standards and recommendations mentioned aboveare combined and enhanced gaining as much robustness and security as possible.

6.2.1

Possible Attacks and Countermeasures

For carrying out strong mutual authentication using asymmetric techniques, authentication tokenshave to be exchanged by a challenge-response protocol. In general, these tokensMUST

becompletely integrity protected to detect alteration of any kind. Furthermore, data originauthentication as well as non-repudiationof origin and receipt MUST be offered by theauthentication protocol.

To cover all the security services mentioned and to detect or prevent attacks on the protocol, thetokens exchangedMUST

is known as pretending a wrong identity, i.e. assuming theidentity of one of the legitimate parties in the network. This threat is eliminated by theauthentication service itself assuring that the identity claimed is authentic. This is achieved bybinding the identity (DN) to the token sent using the integrity service providing data originauthentication. Authenticity of a public key is given by a CA-created certificate that binds identityand public key together. Proving these authenticity means verifying the certificate and possible achain of certificates to establish an hierarchy of trust. For data origin authentication and non-repudiation of origin, the distinguished name (DN) and physical location of the sender MUST beincluded. The physical location is specified by IP address and network adapter hardware address(MAC).

Token manipulation

is addressed by integrity protection of the complete token for all exchangesperformed.Continuity of authentication

MUST be assured by binding the authentication serviceand the integrity service for further token exchanges (see control data) so that no intruder can cut inor take over after the authentication has completed. Moreover, system authentication MUST beperformed at the beginning and all through each session (timed authentication). For integrityprotection, digital signatures MUST be applied. For each signed message the signatureMUST

beincluded for verification purposes.

Replay attacks

MUST be addressed by including pre-signed random numbers generated by thecounterpart that are checked for equality when the counterpart receives the reply. Moreover, achaining of random numbers MUST be carried out verifying if the number received by

thecounterpart in the last message is the same that comes with the current message (seeFigure6-1).As the same random number challengeMUST

never be issued twice or accepted twice by the samemachine (client, server), a random number log table MUST be maintained. Furthermore, asequence number MUST be applied for each token that must be recorded as well to preventduplications. To reduce logging of the unique numbers (random number, sequence number) to acertaintime window time stamps SHOULD be used as continuously transaction numbers. The

9

time stamps of token generation and expiration time are included in the token applying UTC time(Universal Time Co-ordinated). Thus, a secure time service is needed offering synchronous clocks.Without secure time server, the time difference of the stamps can be verified only using local time.Different report logs have to be maintained by the server for each client.

A token identificator MUST be included to recognise and distinguish the different kinds of tokensexchanged for authentication (request, data1, data2, data3).

To eliminaterelay attacks

were the intruder acts a wire, i.e. forced delay andintruder-in-the-middle, additionally measures MUST be applied. First, the continuity ofauthentication is assured as described above. Furthermore, the DN, IP address and the MAC(determining the physical location) of the recipient are included (dedicated challenge). Then, thetime stamps included prohibit delays that are longer than

the time window given. Short time outsare applied for the communication protocol model, i.e. the temporal distance of commands toreplies as well as of a command to the next in a chain of commands is checked using short timewindows. At last, the authentication tokens differ according to the issuer by including its role(initiator, responder). A state indicator (authentication invitation, authentication request) marks ifthe verifier invites or the initiator request authentication. This is needed if bothparties can start theauthentication procedure as this is generally the case for mutual authentication protocols. Thisadditional information may not be included if the entity that starts interaction is either always theclaimant or always the verifier.

Attacks on the implementation

asinterleaving1

orreflection2

MUST be addressed also.Uni-directional keys must be used (each principal has a unique signing key), the identifiers of thetarget party are included, and tag-length-value encoding (TLV, seeTable6-2) is applied for fieldidentification. TLV encoding permits to randomise the order of fields inside a token preventingmessage symmetries. Furthermore, TLV protects against an inconsistent view of token fieldsgiving an unique standardisation of all possible contents. The fields are distinguishable from eachother independent of their token position. Thus, the implementation is more efficient due to theunambiguousness gained.

Token IDs and sequence numbers protect against an inconsistent view of tokens giving eachmessage an unique tag of position within a stream of messages.

ConfidentialityMUST NOT

be applied, otherwisekey attacks

are possible. Since the control datais a well-known and often small set of commands resulting in short tokens, key attacks likeforward search3

or dictionary4

may be successful. Moreover, applying unnecessary securityservices may result in security flaws due to possible interaction between security mechanisms.When used in isolation, security mechanisms provide an acceptable level of security and maybecome more vulnerable when used in combination with other mechanisms (see [ISO/IEC 10181-1] page 15).

NRR SHOULD be provided by including the hash value of the previously received token

in thenew message to be sent.

After the authentication (user and system) has been successfully performed, authorisation and auditbased upon the user’s identity MAY be carried out. The identity involved is obtained from theauthentication tokens (as thefield containing the DN).

1

The selective combination of information from one or more previous or simultaneously ongoing protocol sessions,including possible origination of one or more protocol sessions by an intruder itself.

2

An interleaving attack involving sending information from an ongoing protocol session back to the originator of suchinformation

3

Applying forward search means, that the intruder takes all 2n

possible entries of a token field and encrypts them usingthe public key of the original recipient and compares each of the 2n

ciphertexts with the actually encrypted value in thetransaction (n denotes the amount of bits per token).

4

When performing dictionary attacks, the intruder encrypts all entries of a dictionary (e.g. the list of communicationprotocol commands) with the public key of the original recipient and compares the result to the transmitted value.

10

6.2.2

Proposed Implementation

In addition to the fields needed in the authentication tokens as given in the Standard Guide for EDICommunication Security and explained above, all tokens MUST be Base64-encoded andcanonicalised afterwards before transmission forsystem interoperability preventing loss of databits

in environments not capable of full binary transport. Not applying these conversions mayresult in invalidation of the digital signature.

The resulting protocol scheme is shown inFigure6-1

and the tokens exchanged (AuthenticationRequest, AuthData1, AuthData2 and AuthData3) are presented in the following within thesequence of the protocol. Each token field is TLV-formatted which is

not shown explicit.

Figure6-1: Strong Mutual Three-Way Authentication

1. At first, the client initiates system authentication by sending an authentication request token tothe server:

a.

Generate:

AuthReq’ =

SeqNo1

|| TokenID1

|| IPclient|| MACclient|| DNclient|| IPserver|| MACserver|| DNserver

|| TSgen1||TSexp1|| Role-Initiator || State-Request|| Rclient1

|| Auth-Command.

b.

Calculate the digital signature over all fields:

DS1

=authclientPrK(AuthReq’).

c.

Concatenate the digital signature and the generated token:

AuthReq’’ = AuthReq’ || DS1.

d.

Perform Base64-encoding and canonicalisation afterwards:

AuthReq = (AuthReq’’)Base64, Canon.

e.

Send the token to the server.

2. On receipt of AuthReq the server performs the following operations:

a.

Apply Base64-decoding.

b.

Check if all necessary fields are included (using the TAG-byte).

c.

Verify the certificate ofdigSigCAPK, usedigSigCAPK

to verifyauthclientPK

and takeauthclientPK

to check thedigital signature of the token received.

d.

Check if the TLV-format is correct, i.e. if the values of length are correct matching thelength of data supplied.

been performed successfully, the control connectionMUST be integrity protected as required by the Standard Guide for EDI Communication Security.Furthermore, data origin authentication, non-repudiation of origin (NRO), and non-repudiation ofreceipt (NRR) SHOULD be provided.

6.3.1

Possible Attacks and Countermeasures

Integrity protection (using digital signatures) MUST be applied during the whole session over allfields contained in a message of control data (token). This enables todetected tokenmanipulation

and assures thecontinuity of authentication

binding the authentication service andthe integrity service so that no intruder can cut in or take over after the authentication hascompleted. For each signed message the signature must be included for verification purposes.

Replay attacks

MUST be addressed by including pre-signed random numbers generated by thecounterpart that are checked for equality when the counterpart receives the reply. Moreover, achaining of random numbers MUST be carried out verifying if the number received by thecounterpart in the last message is the same that comes with the current message (seeFigure6-3).Furthermore, a sequence number MUST be applied for each token. To reduce logging of theunique numbers (random number, sequence number) to a certain time window time stampsSHOULD be used as continuously transaction numbers. The time stamps of token generation andexpiration time are included in the token applying UTC time.

A token identificator MUST be included to distinguish control data that is sent from the client tothe server (containing commands) from control data that is transmitted from the server to the client(containing reply codes).

For data origin authentication and non-repudiation of origin, the sender MUST include hisdistinguished name (DN), IP address and network adapter hardware address (MAC).

To eliminaterelay attacks

were the intruder acts a wire, i.e. forced delay andintruder-in-the-middle, additionally measuresMUST be applied. First, the continuity ofauthentication is assured as described above. Furthermore, the DN, IP address and the MAC(determining the physical location) of the recipient are included. Then, the time stamps includedprohibit delays that are longer than the time window given. At last, short time outs are applied forthe communication protocol model, i.e. the temporal distance of commands to replies as well as ofa command to the next in a chain of commands is checked using short time windows.

14

Attacks on the implementation

asinterleaving

orreflection

MUST be addressed also.Uni-directional keys are used (each principal has a unique signing key), the identifiers of the targetparty are included, and tag-length-value encoding (TLV) is applied for field identification.

Token IDs and sequence numbers protect against an inconsistent view of tokens giving eachmessage an unique tag of position within a stream of messages.

ConfidentialityMUST NOT

be applied, otherwisekey attacks

are possible. Since

the control datais a well-known and often small set of commands resulting in short tokens, key attacks likeforward search or dictionary may be successful. Moreover, applying unnecessary security servicesmay result in security flaws due to possible interaction between security mechanisms. When usedin isolation, security mechanisms provide an acceptable level of security and may become morevulnerable when used in combination with other mechanisms (see [ISO/IEC 10181-1], page 15).

NRR SHOULD be providedby including the hash value of the previously received token in thenew message to be sent.

6.3.2

Proposed Implementation

In addition to the fields needed in the authentication tokens as given in the Standard Guide andexplained above, all tokens MUST be Base64-encoded and canonicalised afterwards beforetransmission forsystem interoperability preventing loss of data bits

in environments notcapable of full binary transport. Not applying these conversions may result in invalidation of thedigital signature.

The resulting token contents for the control data connection are given in the following. First, thegeneration and verification of the tokens is described in detail. Then, a general overview of thetoken exchanged within the communication protocol is shownregarding the continuity ofauthentication by resuming the authentication protocol given above (seeFigure6-3). Each tokenfield is TLV-formatted which is not shown explicit.

In general, the token generation process (of command or reply codes) for every control data tokenlooks like the following:

a.

Generate:

Token’n

=

SeqNon

|| TokenIDm

|| IPclient|| MACclient|| DNclient|| IPserver|| MACserver|| DNserver

|| TSgen o|| TSexp

p|| [command

replyCode]|| randomNumbers || HashValueToken’(n-1)).

b.

Calculate the digital signature over all fields:

DSn

= [digSigclientPrK(Token’n)

digSigserverPrK(Token’n)].

c.

Concatenate the digital signature and the generated token:

Token’’n

= Token’n

|| DSn.

d.

Perform Base64-encoding and canonicalisation afterwards:

Tokenn

= (Token’’n)Base64, Canon.

e.

Send the token to the [server

client].

Basically, the following steps are performed on receipt of the token for verification:

a.

Apply Base64-decoding.

b.

Check if all necessary fields are included (using the TAG-byte).

c.

Verify the certificate ofdigSigCAPK, usedigSigCAPK

to verify [digSigclientPK

digSigserverPK] and use[digSigclientPK



digSigserverPK] tocheck the digital signature of the token.

d.

Check if the TLV-format is correct, i.e. if the value of length is correct matching the length ofdata supplied.

of data bits.Furthermore, for the correct handling and feature negotiation a cryptographic syntax MUST beused for encapsulation. Thus, to satisfy all these requirements MIME-object security MUST beapplied.

Security Multiparts for MIME[RFC1847], S/MIME version 2[SMIME2], S/MIME version 3[SMIME3], MOSS [RFC1848] or PGP/MIME [RFC2015] are appropriate for this purpose.Informational examples for applying Security Multiparts for

MIME and S/MIME version 2 aregiven in Annex B and Annex C, respectively. Beingindependent of the cryptographic protocolsyntax, any other desired cryptographic syntax can be added when offering the featured needed.

Each cryptographic protocolSHOULD

be used in three different operation modes(besidesplain text) according to the local security policy: signed-only, encrypted-only or signed-and-encrypted. These modes MUST be realised by applying MIME-object nesting. For bulk encryption(content encryption) a strong symmetric session key (having at least 112 significant key bits)MUST be used MUST be secured by strong asymmetric techniques (preferably by RSA with 1024bits and above) for transport (hybrid encryption). The session key algorithmMUST

be selectableand a new keySHOULD

be calculated for each message data transport. Switching between thecryptographic protocols and their operation modesSHOULD

be performed easily by the humanuser.

Fortransmission of large files, data compression or deliveryof raw cryptographic objects MAYbe applied. For Security Multiparts for MIME and S/MIME these raw objects are PKCS#7-basedas PKCS#7-objects[RFC2315]

or CMS-objects[SMIME3]. PGP/MIME is based uponPGP-objects, whereas MOSS is not bound to a specific syntax.

Compression of EDI messagesMUST

be done before encryption,afterapplying the digitalsignature if needed ([MIME-SECURE]

chapter 5.4.1). In general, EDI messages compress well,since there is a lot of repetitive data in most of the messages. Applying compressing beforeencryption strengthens cryptographic security since repetitious strings are reduced due to theirredundancy. The MIME standards[MIME]

do not define any content encodings concerningcompression, but allow the definition of additional content fields (see chapter

9 of RFC2045). Aspresented in[MIME-SECURE], an additional content field ”Content-Encoding:” (followingRFC2068 chapter 3.5 and 14.12 for HTTP1.1) may be inserted to convey compressioninformation. Ifgzip

(see RFC1952) is used, this looks like ”Content-Encoding: gzip”.

Transport of raw cryptographic objects (as PKCS#7, CMS or PGP) can be applied to avoid thecryptographic syntax overhead of MIME security as Base64-encoding, MIME headers and trailers.Raw objects of this kindMUST NOT

be used for transport of EDI messages, because neithercanonicalisation nor Base64-encoding is performed. Without MIME headers, no content handlingand feature negotiation can be performed. Furthermore, NRR can be only provided forCMS-objects in combination with the Enhanced Security Services (ESS,[SMIME3]). Otherwise,there is no NRR support available for these raw objects. For NRR related issues see section6.4.3.

5

As ADT, BDT, GDT, LDT and more. Used for standardised message transfer in health care in Germany.

17

6.4.1

Encapsulating EDI-messages in MIME

Before delivery of EDI messages using MIME security, the messageMUST

be Base64-encoded toprevent loss or manipulationof certain EDI characters (as the HL7 segment terminator) leading toinvalidation of the digital signature. Furthermore, the message MUST be inserted into a MIMEbody for delivery that must itself be canonicalised. On receipt, the MIME bodyMUST

becanonicalised for signature validation and the message has to be Base64-decoded afterwards.Informational examples for applying Security Multiparts for MIME and S/MIME version 2 aregiven in Annex B and Annex C, respectively.

As mentioned above, the implementation can be used inany desired environment

for delivery ofany type of data. Data type independency means that the receiving application must be able torecognise the type of data received. For that reason, if inserting an HL7 message into a MIMEbody, a content-type identifying HL7 messagesMUST

be used. Thus, the content-typeapplication/x-EDI-HL7

SHOULD

be applied. Additional parameters (for example syntaxand version)MAY

be stated in the content-type to specify encodings rules, for instance. Whenoperating in anHL7-environment, data type independencyMUST NOT

be attended, since theHL7 interface definitely knows that only HL7 message data is sent between application. For thatreason when inserting HL7 messages, the specialised content-type

application/x-EDI-HL7

need not be used, but the content-type chosenMUST

be able to carry the additional parameters aswell. Another possible solution is to map the HL7 message (including the additional protocolparameters mentioned above) into a X12 message using thestandardised mapping rules and toinsert the result into the content-typeapplication/EDI-X12

defined in[RFC1767]. Othercontent-types could not be used as they are not featuring the additional protocol parametersmentioned above. MIME encapsulation of X12 and EDIFACT objects is specified in[RFC1767]

using the content-typesapplication/EDI-X12

andapplication/EDIFACT.

For delivery of EDI messages, general requirement for inter-operable EDI and securityrelatedissues can be found in[EDI-REQ].

6.4.2

Encapsulating signed MIME messages for Transport

When transporting signed data usingmultipart/signed

by Internet (http, mail) or end-to-endin non-MIME environments, gateways are generally not aware of MIME security and treat thiscontent-type asmultipart/mixed

or also apply conversions to the MIME structure and itscontents according to the local format. Thus, either the original message could not be reconstructedand the signature could not be verified, or the signature verification fails.

To encounter this problem,[SMIME2]

and[SMIME3]

propose two solutions. Either thecontent-typeapplication/pkcs7-mime

or the content-typeapplication/mime

SHOULD be used to pass signed data through the gateway, completely intact for a S/MIMEfacility. The major difference between these two alternatives is that the first uses a PKCS#7 objectand the latter encapsulates the wholemultipart/signed

entity.

The encapsulation usingapplication/mime

has been also specified by[APP-MIME], but thisInternet-Draft is expired and has been deleted without publication as a RFC.

A description for secure exchange of EDI documents using http transport is given in[MIME-HTTP]

6.4.3

Non-Repudiation

18

According to the Standard Guide for EDI Communication Security, non-repudiation of origin(NRO) and receipt (NRR)SHOULD

be provided for the transmission of message data (EDImessages and other data files).

Generally,NRO

MUST be provided by inserting information about the sender (in the role of thesigner) as its distinguished name or public key (certificate).

For PKCS#7 and CMS thesignedData

object MUST be used to assure NRO. This can beachieved by including certificates or authenticated attributes. For PKCS#7-objects, certificates areincluded using the fieldExtendedCertificatesAndCertificates

for a set of PKCS#6extended certificates and X.509 certificates (chains of certificates) or using the fieldExtendedCertificateOrCertificate

for either a PKCS#6 extended certificate or anX.509 certificate. For CMS-objects, certificates are included using the fieldcertificates

containing a collection of PKCS#6-certificates (obsolete for CMS) or X.509 (attribute) certificates.

Authenticated attributes are inserted in the attributeauthenticatedAttributes

of the fieldsignerInfo

for PKCS#7-objects, whereas the attributesignedAttrs

is used forCMS-objects. For MOSS, the fieldOriginator-ID:

can hold the DN (including email ifdesired) or the public key of the sender (originator).

For providingNRR, signed receipts MUST be used. In general, NRR can be realised by theMIME-syntax itself or the cryptographic objects embedded. The way of

providing NRR by MIME-syntax is given by[RFC1892],[RFC2298]

as well as[MIME-SECURE]

and described in section6.4.3.1. Following this way, NRR can beprovided independently of the objects embedded. Whenusing S/MIME version 3, NRR MUST be provided by the CMS-objects embedded in combinationwith the Enhanced Security Services (ESS) as defined by[SMIME3]. This way is described insection6.4.3.2. There is no other way to offer NRR, yet. No NRR support is available on thePKCS#7-level.

Since the return of message contentMAY

be wasteful of network bandwidth and time anappropriate strategySHOULD

be chosen. Thus, only the hash value of the last message receivedSHOULD be included and not the full message itself.

6.4.3.1

NRR for MIME-Object Security Protocols

When using MIME-object security protocol as Security Multiparts for MIME, S/MIME version 2,MOSS or PGP/MIME the following specifications and formats for receipts and signed receiptsMUST

be applied for provision of NRR. For S/MIME version 3, NRRMUST

be implemented asgiven in section6.4.3.2

The format ofrequesting

and the format of receipts

itself are defined in[RFC2298], the formatofsigned receipts and their requests

are specified in[MIME-SECURE]

chapter

5. Forrequesting a signed receipt, the sender places the following headers before the first content-type ofthe message. The headerDisposition-notification-to:

and a”reference” to the original message (third body). For human eye diagnosing, the textual status

19

description (first body part ofmultipart/report) can be used to include a more detailedexplanation of the error conditions reported by the disposition headers. Following[RFC2298]

and[RFC1892]

for receipts, the original message (if encrypted, in its encrypted form) or part of it (forinstance received headers) should be included as a third body part (optional body part) or omittedif message headers are not available. Full message inclusion is only recommended if the requestlevel is absence, otherwise partial inclusion is recommended. In any case, the reference is achievedby the fieldOriginal-Message-ID:

besides other fields

likeReporting-UA:,Original-Recipient:,Final-Recipient:

andDisposition:

of the second bodypart without any security protection (for example: possible forgery of MDNs).

Signed receipts

are built following[MIME-SECURE]

using the content-typemultipart/report

as described above, but now the Base64-encoded MIC (message integritycheck or message digest) of the original plain text message is inserted into the new fieldReceived-content-MIC:

in the second body to establish the reference. For any signedmessages (means that signed/encrypted must be decrypted first), the MIC to be returned iscalculated on the canonicalised (multipart) MIME header and content, for encrypted-onlymessages, the MIC to be returned is calculated on the decrypted and afterwards canonicalised(multipart) MIME header and content, and for plain text messages the MIC must be calculatedover the message contents before their transfer encoding and without any MIME or other headers.Returning the original or parts

of the received message in the third body ofmultipart/report

is not required (optional body part), but it is recommended to place the received headers into thatbody. At least, the complete content-typemultipart/report

is signedafter

itscanonicalisation usingapplication/pkcs7-mime

withsmime-type=signed-data

ormultipart/signed

for S/MIME version 2, ormultipart/signed

for secure MIME.

Forvalidation, the MIC contained inmultipart/report

received from the server must becompared with the MIC calculated by the client.

Forbundling purposes, the server’s response comprising of the reply message and the signedreceipt (the whole content-typemultipart/report

as described above but un-signed andun-encrypted) are bound together by the content-typemultipart/related

[RFC2112]: Theserver computes a reply message and inserts this message in to MIME entity (for HL7 thecontent-typeapplication/x-EDI-HL7). This entity is inserted as the first part of themultipart/related

MIME entity. Themultipart/report

entity is inserted un-signedand un-encrypted as the second body part. A prototype of themultipart/report

entity isshown inFigure6-4.

Then, themultipart/related

entity (parameter typeapplication/x-EDI-RESPONSE

and consisting of two bodies) is canonicalised and signed afterwards. If confidentiality is needed,the result itself can be enveloped.

To summarise, there are only two transactions between client and server (if the client abandons tosend a MDN receipt for the server’s response in turn): The client sends an request messageincluding a request for a signed receipt and the server responds transmitting the reply message andthe receipt signed and encrypted as explained above.

Content-Type: multipart/related;<CR><LF>

type="application/x-edi-response";<CR><LF>

boundary="<boundary1>"<CR><LF>

<CR><LF>

--<boundary1><CR><LF>

Content-Type: application/x-EDI-HL7<CR><LF>

Content-Transfer-Encoding: base64<CR><LF>

<CR><LF>

20

<base64-encoded EDIreply message>

<CR><LF>

--<boundary1><CR><LF>

Content-Type: multipart/report;<CR><LF>

report-type="disposition-notification";<CR><LF>

boundary="<boundary2>"<CR><LF>

<CR><LF>

--<boundary2><CR><LF>

Content-Type: text/plain<CR><LF>

Content-Transfer-Encoding:7bit<CR><LF>

<CR><LF>

<some text describing the status>

<CR><LF>

--<boundary2><CR><LF>

Content-Type: message/disposition-notification<CR><LF>

Content-Transfer-Encoding: 7bit<CR><LF>

<CR><LF>

Reporting-UA:<ua-name>;<ua-identifying-string><CR><LF>

Final-Recipient:<address-type>;<generic-address ><CR><LF>

Original-Message-ID:<message-id><CR><LF>

Disposition:<action-mode>/<sending-mode>;<CR><LF>

<disposition-type>/<disposition-modifier

><CR><LF>

Received-Content-MIC:<mic>,<micalg><CR><LF>

<CR><LF>

--<boundary2>--<CR><LF>

<CR><LF>

--<boundary1>--<CR><LF>

Figure6-4: Prototype of themultipart/related

content-type

6.4.3.2

NRR for S/MIME Version 3

When using theS/MIME version 3

as defined by[SMIME3], the Enhanced Security Services forS/MIME (ESS,[SMIME3]) MUST be used for providing NRR by signed receipts. The ESS areusing the CMS (Cryptographic Message Syntax) as defined by[SMIME3]. The CMSis derivedfrom PKCS#7 version 1.5. Signed receipts may be requested only if a message is signed and canoptionally be encrypted by the sender of the receipt.

As described in chapter

2 of the ESS specification, therequest

is indicated by adding the attributereceiptRequest

to theauthenticatedAttributes

field of theSignerInfo

objectfor which the receipt is requested. The attributereceiptRequest

consists of the fieldssignedContentIdentifier,receiptsFrom

andreceiptTo. The fieldsignedContentIdentifier

is used to associate the signed receipt with the messagerequesting the signed receipt by an unique message identifier. Entities requested to return a signedreceipt are noted in the fieldreceiptsFrom. For each entity to whom the recipient should sendthe signed receipt, the message originator must provide theGeneralNames

is signed and the digest is included inmessageDigest, the digest valuecalculated to verify the signature of the originalsignedData

object is included inmsgSigDigest

and the receipt object identifier is inserted intocontentType. At last, allauthenticated attributes are signed and the signature is included insignature

ofsignerInfo.

ThesignedData

object is then put into anapplication/pkcs7-mime

body with theparameter typesigned-receipt. If this object should be encrypted within anenvelopedData

object, then an outersignedData

object must be created

encapsulating theenvelopedData

object containing acontentHints

attribute with the receipt objectidentifier ascontentType. This is needed for the receiving agent to indicate that a signedreceipt is contained within anenvelopedData

object.

Tovalidate a signed receipt, the requestor must retain either the originalsignedData

object, orthe signature digest value of the originalsignedData

object (contained insignature

ofsignerInfo) and the digest value of the attributereceipt.

First,contentType,signedContentIdentifier

andoriginatorSignatureValue

are extracted from thereceipt

attribute to identify the originalsignedData

object thatrequested the receipt.

Now, the digest of the originalsignedData

object is compared with the value ofmsgSigDigest. If the originator has not retained the digest, it must be recalculated. If thesevalues are identical, it is proven that the digest calculated by the recipient is based upon thereceived originalsignedData

object including the sameauthenticatedAttributes

containing thereceiptRequest.

Then, the digest calculated by the originator for thereceipt

attribute is compared with the valueofmessageDigest. If the originator has not retained the digest, it must be recalculated. If thesevalues are identical, it is proven that the recipient received the originalsignedData

objectsigned by the originator to build thereceipt

attribute.

At last, the originator verifies the signature of the receivedsignedData

object (signature

field ofsignerInfo) using the calculated digest ofauthenticatedAttributes. If thesignature verification is successful, the integrity of the receivedsignedData

object containingthereceipt

attribute is proven and the identity of the recipient included insignerInfo

isauthenticated.

7

The

Secure File Transfer Protocol (SFTP)

In this part the communication protocol over TCP/IP-based networks is described that offers userand system authentication as well as a secure control and data connection according to theStandard Guide for EDI Communication Security exchanging the tokens given in this guide (seesection6). This protocol is an security enhanced version of the fundamental file transfer protocolgiven in [RFC0959] and is based solely on standards (e.g. ISO, NIST

File transfer of HL7 messages (batch processing) is carried out by transmitting one or moremessages grouped in a file and encoded according to the encoding rules of HL7. Responses aregrouped and transported similarly. According to communication security, SFTP wraps HL7messages applying various selectable cryptographic message syntax as PKCS#7, securitymultiparts for MIME, S/MIME (version 2 or 3), MOSS or

PGP/MIME. Security based on MIMEtakes advantage of the object-based features of MIME and allows secure messages. In general,SFTP is independent of the cryptographic syntax used, thus any other syntax can be implementedwithout much effort. Moreover, SFTP is able to process any desired type of file data as EDImessages (EDIFACT, HL7, X12, xDT and other) or arbitrary binary data. Different operationmodes, i.e. plain text, signed-only, encrypted-only or signed-and-encrypted can be selected formessage transmission according to the security policy given. Character encoding using the Base64-encoding scheme is and canonicalisation is applied for system interoperability preventing loss ofdata bits that may lead to invalidation of the digital signature.

For establishing a public key infrastructure (PKI) using trusted public keys, all public keys areembedded into a certificate whose structure is following X.509, and the distinguished names (DN)used therein conform with X.501. The certificates are stored and managed in X.500 or LDAPdirectories.

7.1

The Protocol Model

The secure File Transfer Protocol (SFTP) is based upon the TCP/IP protocol suite using the FTPclient/server model as defined in[RFC0959]

An overview of the SFTP process model is shown inFigure7-2. It is derived from the fundamentalFTP model given in[RFC0959]. The protocol interpreter (PI) and the data transfer process (DTP)involved realise FTP processing by analysing and evaluating commands and replies (the part of thePI) as well as performing data transfer if needed (the partof the DTP). Thus, the PI is managingthe control connection and the DTP is responsible for the data connection.

Basically, the SFTP process looks like the following. The server is listening on the well-knownFTP service port (TCP port 21) waiting for a client connecting to that port. If the client performs aconnection (from a dynamic port X), a so-calledcontrol connection

is initiated that remains forthe whole session. On this connection the client sends commands to the server and the serverresponds by sending reply codes using this connection in full-duplex operation mode. Normally,the control connection is closed by the client sending an appropriate command (QUIT), but theserver could do so in case of serious errors.

The data transfer is performedby establishing a second temporary connection in simplex operationmode. There are two modes for the establishment of suchdata connection:

1.

Inactive mode, the client listens on a dynamic TCP port Y and sends a PORT commandcontaining his IP address and port Y to the server that itself attempts to connect to that IPaddress and TCP port.

2.

When usingpassive mode, the client sends a PASV command to the server that hereon listenson port 20 (or alternatively on a dynamic port) and informs the client where to

All transfers (control and data connection) performed by the original RFC0959-FTP protocol areunsecure having nosecurity services like strong authentication, confidentiality, integrity oraccountability. Only simple authentication is carried out transmitting the password in plain textusing the USER and PASS command.

24

Looking at the process model described above, the enhancement of security for the FTP protocolMUST

be located at the PIsecuring the control connection

and at the DTPsecuring the dataconnection. Furthermore, before the client could perform any command (except the command torequest authentication) and data transfer on the server, astrong mutual authentication

MUST

beperformed between them. Exactly this approach is realised by SFTP. For the enhancement ofsecurity, many standard document available are considered such as ISO Standards, IETF/IESGInternet Standards (RFCs), IETF Internet Drafts (IDs) and NIST publications (NIST FIPS PUB).

In addition, both client and serverMUST

apply timers to check if a connection is timed-out, thatis, if the response or chained commands are out of time. ThisMUST

beperformed for the controland data connection as well as if the server is running on idle.

7.2

Strong mutual Authentication

Foruser authentication

the human personSHOULD

provide his HPC using name and PIN incombination with biometrics. After the SC has been opened successfully, all objects (e.g. keys)MUST

be checked against completeness and validity (for instance certificates). During the SFTPsession, the chipcard needs to be kept inserted in the chipcard terminal (timed chipcard request).When removingthe chipcard, the application inhibits further operations and only continues towork, if the chipcard is inserted again and the following user authentication performed issuccessful.

Before the SFTP client could perform any command (except the command torequestauthentication) and data transfer on the server,strong mutual authentication

MUST

beperformed between them as described in section6.2.2.

As given in section6.2.2, an unique identifier is included for each token exchanged to indicate itstype and position in the exchange as shown inFigure6-2. The following values SHOULD be used(in the style of[FIPS196]

appendix A) in WORD representation:

TokenIDAuthReq.

= 0x0010

TokenIDAuthData1

= 0x0011

TokenIDAuthData2

= 0x0012

TokenIDAuthData3

= 0x0013

Two time stamps SHOULD be included: one time stamp for token generation time and one fortoken expiration time. For time stamp generation,UTC time MUST be used and converted toseconds for comparing purposes (using DWORD representation). The time windowMUST

be ofan appropriate length according to the physical properties of the underlying network (e.g. notgreater than 2 minutes.

Both DNs of the initiator and the responder, the IP Address as well as the MAC MUST beconverted to OCTETSTRING representation for delivery. The random numbersSHOULD

begenerated using strong mechanisms andMUST

be represented in OCTETSTRING. The digitalsignature

itself MUST be presented in BITSTRING.

For token formatting, the tag-length-value (TLV) formatMUST

be applied. The values used forthe tag-byte of the TLV format (seeTable6-2) are presented inTable7-1

and MUST be used.

Table7-1: Valid values for the TAG-byte

TAG-byte

Purpose

0x00

Token identificator

25

0x01

Sequence number

0x02

Time stamp for token generation time

0x03

Time

stamp for token expiration time

0x04

DN of initiator (client)

0x05

DN of responder (server)

0x06

IP address of initiator (client)

0x07

IP address of responder (server)

0x08

MAC of initiator (client)

0x09

MAC of responder (server)

0x0a

Role indicator (initiator/responder)

0x0b

State indicator (request/invitation)

0x0c

Random number 1

0x0d

Random number 2

0x0e

Random number 3

0x0f

Authentication request command

0x10

Hash value for NRR

0x11

Digital signature

According to the Standard Guide for

EDI Communication Security and section6, all token bytes(all fields including TLV encoding) MUST be Base64-encoded and canonicalised before deliveryfor interoperability reasons and decoded on the server before evaluation. Base64-encoding protectsagainst loss of data bits in environments not capable of full binary transport. Canonicalisation isperformed after the encoding process to prevent system dependency. Applying neither encodingnor canonicalisation may leading to invalidation of the digital signature.

The commands and reply codes for FTP authentication MUST be implemented in the style of[RFC2228]. AUTH is used for authentication request and security mechanism transmission.ADAT is applied for transmission of authentication data. The AUTH command is used by theclient to request authentication by giving an authentication mechanism as argument. Validmechanisms must be registered with the IANA (Internet Assigned Numbers Authority) and can befoundat[RFC2222]

or[IANA]. For local use, the values are beginning with ”X-”, so for thisprotocol ”X-SFTP” is applied.

The command ”AUTH X-SFTP” is embedded in the token field Auth-Command of the tokenAuthReq’ that is built according to section6.2.2

step 1. All tokens containing authentication dataas AuthReq, AuthData1, AuthData2 and AuthData3 are send to the server as an argument of theADAT command.Figure7-3

shows the flow of authentication tokens for SFTP.

SFTPc

SFTPd

AUTH<SPACE>AuthReq

334<SPACE>ADAT=AuthData1

ADAT<SPACE>AuthData2

235<SPACE>ADAT=AuthData3

Figure7-3: Flow of Authentication Tokens Exchanged for SFTP

26

After the authentication has been successfully performed, authorisation based upon the user’sidentity MAY be carried out by the server. The identity involved is obtained from the DNcontained in the authentication tokens. Thus, no additional USER command must be used asexplained in[RFC2228].

The checking of time stamps as mentioned above only applies, when either synchronised clocksare available in a local environment, or if clocks

are logically synchronised by bilateralagreements. In any case Co-ordinated Universal Time (UTC) and secure time servers must be used.

7.3

Securing the Control Connection

When authenticated successfully, the control connection MUST be secured as describedin section6.3. The client commands and server reply codes MUST be in the style of[RFC2228]. Commandtokens MUST be generated according to section6.3.2

and are sent as an argument of the securitycommands of[RFC2228]

(for example: ENC<SPACE>Token5

for signed-and-encryptedtransmission). The reply of the server MUST be generated analogously and the codes are following[RFC2228]

(for example: 632<SPACE>Token6).

7.4

Securing the Data Connection

The data connectionMUST

be secured as described in section6.4

providing integrity,confidentiality and non-repudiation of origin and receipt. Switching between the cryptographicprotocols (e.g. S/MIME version 2, S/MIME version 3, MOSS) and their operation modes (e.g.signed-only, signed-and-encrypted) as well as selection of the session keyMUST

be possible. The‘PROT’ command as defined in[RFC2228]

is restricted and not well specified not allowing morethan one different protocol. So, this protocol uses the ‘PROT’ command with an word encodedargument (2 Bytes in little endian order).

The first byte (low byte) MUST state the cryptographic protocol and its operation modes as brokendown inTable7-2. All unused entries of this byte between hexadecimal 0x00 and 0x3F areuser-definable, other values MUST not be allocated or re-allocated.

MIME Security Auto-detection (value 0x3F)MUST

be used only for MIME-object securityprotocols as Security Multiparts For MIME, S/MIME version 2 and 3, MOSS and PGP/MIME fornow. When setting auto-detection, the receiving application knows that something is transmittedusing MIME-object security, but it neither knows the specific MIME-object security protocol northe operation mode (signed-only, encrypted-only or signed-and-encrypted). The auto-detectionmechanism identifies the MIME-object security protocol and the operation modes. Furthermore,this mechanism must be able to process files containing multiple messages that may also vary intheir MIME-object security protocol and operation mode. Automatic detection is based upon theMIME type indicated by the content-type and the evaluation of accompanying parameters.

The operation modesMUSTonly be given if non-MIME protocols are used as PKCS#7-only andCMS-only. In this case, the value stating the protocol and the value of the desired operation modesare combined by bitwise-OR-operations. For example, PKCS#7-only in signed-and-encryptedoperation mode will result in the value ((0x10 OR 0x40) OR 0x80) = 0xD0.

Table7-2: Encoding for the Cryptographic Protocol and its Operation Mode

Value

Usage

Cryptographic Protocol:

0x00

Plain Text (ASCII)

27

0x10

PKCS#7-only

0x11

CMS-only

0x20

Security Multiparts For MIME

0x21

S/MIME Version 2

0x22

S/MIME Version 3

0x30

MOSS

0x31

PGP/MIME

0x3F

MIME Security Autodetection

Operation Mode:

0x40

Sign

0x80

Encrypt

The second byte (high byte) of the ‘PROT’-command argument MUST define the session keyalgorithm as shown inTable7-3. Here, all unused entries are user-definable.

Table7-3: Encoding for the Session Key Algorithm

Value

Usage

0x00

IDEA

0x10

DES-EDE2-CBC

0x11

DES-EDE3-CBC

7.5

Security Considerations regarding the Protocol Stack

According to the Standard Guide for EDI Communication Security, the specification of theprotocols used (as FTP, TCP, IP) contain a number of mechanisms that can be used to compromisenetwork security. There are many Internet attacks known based on infrastructure weakness, forinstance DNS spoofing, source routing (IP spoofing), FTP bouncing, racing authentication anddenial of service. Attacks arising from the weakness of the FTP protocol and underlying protocolsSHOULD be addressed by this protocol regarding[FTPSEC]

or[CERT].

Racing authentication (based on faster authentication of the attacker than the victim) SHOULD beprevented by the strong mutual three-way authentication (based on challenge/response and digitalsignature) and the restriction to one simultaneously login of the same user. Moreover, the totalnumber of control connection possibleSHOULD

be limited, also.

To protect against FTP bouncing (namely the misuse of the PORT command), the server SHOULD

NOTestablish connections to arbitrary machines (for instance a second FTP server called proxyFTP) and ports on these machines. Following[CERT]

and[FTPSEC], the server SHOULD ensurethat the IP address specified in the PORT command must match the client’s source IP address forthe control connection. Furthermore, the server MUST disallow data connections if the TCP-portspecified in the PORT command is a well-known port (port 0 to 1023) or registered port (1024 to49151). Only dynamic private ports (port 49152 to 65535) are allowed. Hence, a port scan againstanother site hiding the true source and bypassing access controls like firewalls (for instance

28

bouncing to a well-known port) cannot be performed. The PORT command is used in the activemode only, it is notused in the passive mode which is initiated by the PASV command. Since thePASV command is not affected by the bounce attack (the server gives the IP address and port toconnect to) and an attacker cannot act as a server, itSHOULD

be preferred to the PORT

commandproviding firewall-friendly FTP (see[RFC1579]), too. Using passive initiation of the dataconnection means that the TCP connection establishment is performed from the client networktowards the server network.

Furthermore, random local port numbers SHOULD be used for the data connection as stated in[FTPSEC]

to address port number guessing. Guessing the next port number is much easier whenusing simple increasing algorithms (for example: next port = old port + constant number) enablingattacks like the denial of a data connection or hijacking a data connection to steal files or insertforged files.

In addition to the authentication procedure, access restrictions based on network addressesMAY

be

provided. The server accepts only connection requests from pre-defined IP addresses (withinauthorised organisations) and confirms that this address on both the control connection and thedata connection match. When relying on IP address authentication only, an attack like sourcerouting of IP packets (IP spoofing) is possible.

For the detection of compromisations (like denial of service attacks and other attacks), the serverSHOULD keep reports logging all activities (connection attempts, disconnection, commandexecutions and other). Since the local machines are

considered as trusted, integrity and/orconfidentiality protection is not required.

29

Annex A:

Example For PKCS#7-based Security (informative)

For application of PKCS#7-only security, the plain data file is available on the file system. Next,this file is signed

applying thesignedData

object of PKCS#7 (with thecontentInfo

fieldcarrying the message data). At last, this object is encrypted using theenvelopedData

object ofPKCS#7. After transportation, this file is processed conversely (decryption following verification).

30

Annex B:

Example For Security Multiparts for MIME (informative)

In this subsection an example is presented, at which an HL7 message is secured by hybridencryption using Security Multiparts for MIME as specified in[RFC1847]

and PKCS#7 forsigning and encryption. For hybrid data encryption, a nesting of content-types is performed asexplained in[MIME-SECURE]

This message is Base64-encoded and inserted into a MIME entity using the content-type”application/x-EDI-HL7” as proposed in[HL7SEC]

(regarding[RFC1767]

and[MIME-SECURE]). For readability of the HL7 messages, the quoted-printable encoding could beimplemented. Next, this entity is canonicalised (that means 7-bit ASCII representation with linesterminated by carriage return <CR> and line feed <LF> as specified in[RFC1848]

is signed using PKCS#7. Following[RFC1847], theMIME entity is inserted into amultipart/signed

MIME message as the first body part

31

depicted inFigure7-6. The digital signature (PKCS#7-signedData

object with an emptycontentInfo

field as explained in[SMIME2]) is Base64-encoded and inserted into the secondbody part. According to[RFC1847], the signature covers the MIME header of the first body andthe first body itself as marked bold inFigure7-6.

the first body parts contains control information(control value and protocol parameter) to decrypt the data in the second body part. Analogously,after transportation the HL7 message is decrypted and verified. For validation of the digitalsignature, the part covered by the signature must be canonicalised first.

This document and translations of it may be copied and furnished to others, and derivative worksthat comment on or otherwise explain it or assist in its implementation may be prepared, copied,published and distributed, in whole or in part, without restriction of any kind, provided that theabove copyright notice and this paragraph are included on all such copies and derivative works.However, this document itself may not be modified in any way, such as by removing the copyrightnotice or references to Health Level-7, Inc. or Internet organisations, except as needed for thepurpose of developing Internet standards in which case the procedures for copyrights defined in theInternet Standards process must be followed, or as required to translate it into languages other thanEnglish.

The limited permissions grantedabove are perpetual and will not be revoked by Health Level-7,Inc. or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis andHEALTH LEVEL-7, THE INTERNET SOCIETY AND THE INTERNET ENGINEERINGTASKFORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUTNOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREINWILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WAR-RANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.