BS DD ENV 13608-3-2000 Health informatics - Security for healthcare communication - Secure data channels《医疗保健信息学 保健通信的安全性 安全数据通道》.pdf

1、| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DRAFT FOR DEVELOPMENT DD ENV 13608-3:2000

2、ICS 35.240.80 NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW Health informatics Security for Healthcare communication Part 3: Secure data channelsThis British Standard, having been prepared under the direction of the DISC Board, was published under the authority of the Standa

3、rds Committee and comes into effect on 15 August 2000 BSI 08-2000 ISBN 0 580 35485 7 DD ENV 13608-3:2000 Amendments issued since publication Amd. No. Date Comments National foreword This Draft for Development is the English language version of ENV 13608-3:2000. This publication is not to be used as

4、a British Standard. It is being issued in the Draft for Development series of publications and is of a provisional nature due to the limited duration of the European prestandard. It should be applied on this provisional basis, so that information and experience of its practical application may be ob

5、tained. Comments arising from the use of this Draft for Development are requested so that UK experience can be reported to the European organization responsible for its conversion into a European Standard. A review of this publication will be initiated 2 years after its publication by the European o

6、rganization so that a decision can be taken on its status at the end of its three-year life. The commencement of the review period will be notified by an announcement in Update Standards. According to the replies received by the end of the review period, the responsible BSI Committee will decide whe

7、ther to support the conversion into a European Standard, to extend the life of the prestandard or to withdraw it. Comments should be sent in writing to the Secretary of BSI Technical Committee IST/35, Health Informatics, at 389 Chiswick High Road, London W4 4AL, giving the document reference and cla

8、use number and proposing, where possible, an appropriate revision of the text. A list of organizations represented on this committee can be obtained on request to its secretary. Cross-references The British Standards which implement international or European publications referred to in this document

9、 may be found in the BSI Standards Catalogue under the section entitled “International Standards Correspondence Index”, or by using the “Find” facility of the BSI Standards Electronic Catalogue. Summary of pages This document comprises a front cover, an inside front cover, the ENV title page, pages

10、2 to 22, an inside back cover and a back cover. The BSI copyright notice displayed in this document indicates when the document was last issued.EUROPEANPRESTANDARD PRNORMEEUROPENNE EUROPISCHEVORNORM ENV136083 May2000 ICS Englishversion HealthinformaticsSecurityforhealthcarecommunicationPart 3:Secure

11、datachannels ThisEuropeanPrestandard(ENV)wasapprovedbyCENon29July1999asaprospectivestandardforprovisionalapplication. TheperiodofvalidityofthisENVislimitedinitiallytothreeyears.AftertwoyearsthemembersofCENwillberequestedto submittheir comments,particularlyonthequestionwhethertheENVcanbeconvertedinto

12、aEuropeanStandard. CENmembersarerequiredtoannouncetheexistenceofthisENVinthesamewayasforanENandtomaketheENVavailablepromp tly atnationallevelinanappropriateform.Itispermissibletokeepconflictingnationalstandardsinforce(inparalleltothe ENV)untilthefinal decisionaboutthepossibleconversionoftheENVintoan

13、ENisreached. CENmembersarethenationalstandardsbodiesofAustria,Belgium,CzechRepublic,Denmark,Finland,France,Germany,Greece, Iceland,Ireland,Italy,Luxembourg,Netherlands,Norway,Portugal,Spain,Sweden,SwitzerlandandUnitedKingdom. EUROPEANCOMMITTEEFORSTANDARDIZATION COMITEUROPENDENORMALISATION EUROPISCHE

14、SKOMITEEFRNORMUNG CentralSecretariat:ruedeStassart,36B1050Brussels 2000CEN Allrightsofexploitationinanyformandbyanymeansreserved worldwideforCENnationalMembers. Ref.No.ENV136083:2000EPage2 ENV136083:2000 Contents Foreword 3 Introduction . 3 1 Scope 5 2 Normativereferences . 5 3 Definitions . 6 4 Sym

15、bolsandabbreviations. . 10 5 Requirements 11 AnnexA (informative)TLSoverview 13 AnnexB (informative)Usageexamples . 16 AnnexC (informative) SecuringofexistingprotocolswithTLS. 18 AnnexD (informative) Plaintextrecovery. 21 Bibliography. 22Page3 ENV136083:2000 Foreword ThisEuropeanPrestandardhasbeenpr

16、eparedbyTechnicalCommitteeCEN/TC251“Healthinformatics“,the secretariatofwhichisheldbySIS. AccordingtotheCEN/CENELECInternalRegulations,thenationalstandardsorganizationsofthefollowing countriesareboundtoannouncethisEuropeanPrestandard:Austria,Belgium,CzechRepublic,Denmark, Finland,France,Germany,Gree

17、ce,Iceland,Ireland,Italy,Luxembourg,Netherlands,Norway,Portugal,Spain, Sweden,SwitzerlandandtheUnitedKingdom. Thismultipartstandardconsistsofthefollowingparts,underthegeneraltitle SecurityforHealthcare Communication(SECCOM): Part1:ConceptsandTerminology Part2:SecureDataObjects Part3:SecureDataChanne

18、ls ThisstandardisdesignedtomeetthedemandsoftheTechnicalReportCEN/TC251/N98110Health Informatics Frameworkforsecurityprotectionofhealthcarecommunication . ThisstandardwasdraftedusingtheconventionsoftheISO/IECdirectivePart3. Allannexesareinformative. Introduction Theuseofdataprocessingandtelecommunica

19、tionsinhealthcaremustbeaccompaniedbyappropriatesecurity measurestoensuredataconfidentialityandintegrityincompliancewiththelegalframework,protectingpatients aswellasprofessionalaccountabilityandorganizationalassets.Inaddition,availabilityaspectsareimportantto considerinmanysystems. Inthatsense,theSEC

20、COMseriesofstandardshastheintentionofexplaininganddetailingtothehealthcare enduserthedifferentalternativestheyhavetocopewithintermsofsecuritymeasuresthatmightbe implementedtofulfiltheirsecurityneedsandobligations.Incorporatedwithinthisisthestandardizationofsome elementsrelatedtotheinformationcommuni

21、cationprocesswheretheyfallwithinthesecuritydomain. Inthecontinuityofthe Frameworkforsecurityprotectionofhealthcarecommunication (CEN/TC251/N98 110),hereafterdenoted the Framework,whoseCENReportaimedatpromotingabetterunderstandingofthe securityissuesinrelationstothehealthcareITcommunication,thisEurop

22、eanPrestandardshallaidinproducing systemstoenablehealthprofessionalsandapplicationstocommunicateandinteractsecurelyandtherefore safely,legitimately,lawfullyandprecisely. TheSECCOMseriesofstandardsarekeycommunicationsecuritystandardsthatcanbegenericallyappliedtoa widerangeofcommunicationprotocolsandi

23、nformationsystemapplicationsrelevanttohealthcare,thoughthey areneithercompletenorexhaustiveinthatrespect.Thesestandardsmustbedefinedwithinthecontextand scenariosdefinedbytheTC251workprogramme,inwhichthemessagingparadigmforinformationsystem interactionis oneoftheessentials,asitwasreflectedbythe Frame

24、work( Frameworkforsecurityprotectionof healthcarecommunication.)Page4 ENV136083:2000 SecureDataChannel Thispart3oftheEuropeanPrestandardonSecurityforHealthcareCommunicationdescribeshowtosecurely communicatearbitraryoctetstreamsbymeansofasecuredatachannelcommunicationprotocol. NOTE NOTEThisstandarddo

25、esnotspecifymethodsrelatedtoavailability,storageortransportationofkey certificatesorotherinfrastructuralissues,nordoesitcoverapplicationsecurityaspectssuchasuser authentication. Asecuredatachannelisdefinedforthepurposesofthisstandardasareliablecommunicationprotocolthat implementsthefollowingsecurity

26、services: 1. authenticationofcommunicatingentitiespriortothecommunicationofanyotherdatapreservationofdata integrity 2. preservationofconfidentialityofthecommunicateddata. Asecuredatachannelprotocoloperatesintwodistinctphaseswhich,however,mayberepeated: 1. negotiationphase:authenticationofcommunicati

27、ngentities(e.g.exchangeofcertificates),negotiationof theciphersuitetobeused,derivationofasharedsecretusingakeyexchangealgorithm 2. communicationphase:transmissionofuserdataencryptedaccordingtothenegotiatedciphersuite. Inadditionthesecuredatachannelcanbeclosedbyeitherpartywhenitisnolongerrequired. Th

28、econceptofasecuredatachannelcanbebestunderstoodbylookingatitsproperties,especiallyin comparisonwiththepropertiesofasecuredataobject(prENV136082,part2ofthisEuropeanPrestandard): 1. Interactivity:thenegotiationphaseallowsthecommunicatingentitiestointeractivelyagreeuponacipher suitethatmeetsbothparties

29、securitypoliciesforthecommunicationscenarioinquestion(e.g.nationalvs. internationalcommunication).Iftheciphersuitenegotiationisunsuccessful,nocommunicationsessionis established. 2. Transience:thesecuredatachannel,beingpartofalayeredcommunicationprotocol,receivesanddelivers unsecureduserdatafromandba

30、cktothecallinglayer.Theencryptedrepresentationofthedataistransient (e.g.availableonlyduringtransmission)andunavailabletothecallinglayer(e.g.application). 3. Performance:aftertheestablishmentoftheciphersuiteandsharedsecretduringthenegotiationphase,there isnoneedtousethecomputationallyresourceintensiv

31、easymmetriccryptographicalgorithmsduringthe communicationphase.Ontheotherhand,becauseofthetransienceoftheencryptedrepresentationofthe data,encryptionmustbeperformedduringthecommunicationprocessandcannotbeprecomputedoffline. 4. Forwardsecrecy:canbeeasilyimplementedaspartofthekeyexchangeprotocol. 5. C

32、ompleteness:sincetheauthenticationofthecommunicatingentities(e.g.certificateexchange)ispartof theprotocol,noadditionaloutofbandcommunication(e.g.lookupofcertificatesinatrusteddirectory)is requiredtousethesecuredatachannel,exceptifcertificaterevocationlistsareused. 6. Transparency:asecuredatachannelc

33、anbeimplementedsuchthatitsupperserviceaccesspointresembles itslowerserviceaccesspoint(e.g.TCP/IPsocketinterface).Thisallowstheeasyadditionofsecurity servicestoexistingnonsecurityawaresystemsandprotocolsbyintegratingthesecuredatachannelasan additionallayerinthecommunicationprotocolstack.Awellknownexa

34、mpleforthisapproachis”Secure HTTP”(HTTPoverSSL3). TheIETFTransportLayerSecurity(TLS)specificationisadescriptionofhowtoprovideasecuredatachannel. AlthoughTLSisanIETFspecification,itisnotlimitedtoTCP/IP.TLSonlyrequiresthepresenceofareliable transmissionprotocol.Thismeansthat”TLSoverOSI”wouldbepossible

35、ifdesired.ThisEuropean PrestandarddefinesasetofprofilesusedwithinTLSforusewithinhealthcarecommunicationoversecuredata channels.Page5 ENV136083:2000 HealthinformaticsSecurityforhealthcarecommunication Part3:Securedatachannels 1 Scope ThisEuropeanPrestandardspecifiesservicesandmethodsforsecuringintera

36、ctivecommunicationsusedwithin healthcare. Interactivecommunicationsaredefinedforthepurposesofthisstandardasscenarioswherebothsystemsare onlineandinbidirectionalcommunicationsimultaneously.SecuringinthisEuropeanPrestandardincludesthe preservationofdataintegrity,thepreservationofconfidentialitywithres

37、pecttothedatabeingcommunicated, andaccountabilityintermsofauthenticationofoneorbothcommunicatingparties. NOTE NOTEExamplesofinteractivecommunicationarethedownloadofHTMLcontentovertheInternet,a DICOMcommunication,orremotelogintoacomputer. ThisEuropeanPrestandarddoesnotspecifymethodsrelatedtoavailabil

38、ityoftheinteractivecommunication, certificationandcertificatemanagementandkeymanagement.NeitherdoesthisEuropeanPrestandardspecifya mechanismforconcealingthatacommunicationsessionisinprogress.ThisEuropeanPrestandarddoesnot specifythemethodsorservicesrequiredtosecurethecommunicatingsystemsthemselves.

39、2 Normativereferences ThisEuropeanPrestandardincorporatesbydatedorundatedreference,provisionsfromotherpublications. Thesenormativereferencesarecitedattheappropriateplacesinthetextandthepublicationsarelistedhereafter. Fordatedreferences,subsequentamendmentsto,orrevisionsofanyofthesepublicationsapplyt

40、othisEuropean Prestandardonlywhenincorporatedinitbyamendmentorrevision.Forundatedreferences,thelatesteditionof thepublicationreferredtoapplies. ISO74982 InformationprocessingsystemsOpenSystemsInterconnectionBasicReference ModelPart2:SecurityArchitecture ISO8824 InformationtechnologyOpenSystemsInterc

41、onnectionSpecificationofAbstract SyntaxNotationOne(ASN.1)(Version219910424). ISO 95948 InformationtechnologyOpenSystemsInterconnectionTheDirectory: Authenticationframework ISO101811 InformationtechnologyOpenSystemsInterconnectionSecurityframeworksfor opensystems:Overview. RFC2246 InternetEngineering

42、TaskForce:TheTLS(TransportLayerSecurity)Protocol, RFC2246Page6 ENV136083:2000 3 Definitions 3.1 accountability ThepropertythatensuresthattheactionsofanentitymaybetraceduniquelytotheentityISO74982 3.2 asymmetriccryptographicalgorithm Analgorithmforperformingenciphermentorthecorrespondingdeciphermenti

43、nwhichthekeysusedfor enciphermentanddeciphermentdifferISO101811 3.3 authentication Processofreliablyidentifyingsecuritysubjectsbysecurelyassociatinganidentifieranditsauthenticator. SeealsodataoriginauthenticationandpeerentityauthenticationISO74982 3.4 availability Propertyofbeingaccessibleanduseable

44、upondemandbyanauthorisedentityISO74982 3.5 certificaterevocation Actofremovinganyreliablelinkbetweenacertificateanditsrelatedowner(orsecuritysubjectowner),because thecertificateisnottrustedanymorewhereasitisunexpired 3.6 certificateholder Anentitythatisnamedasthesubjectofavalidcertificate 3.7 certificateuser Anentitythatneedstoknow,withcertainty,thepublickeyofanotherentityISO95948 3.8 certificateverification Verifyingthatacertificateisaut