1、Designation: E1985 98 (Reapproved 2013) An American National StandardStandard Guide forUser Authentication and Authorization1This standard is issued under the fixed designation E1985; the number immediately following the designation indicates the year oforiginal adoption or, in the case of revision,
2、 the year of last revision. A number in parentheses indicates the year of last reapproval. Asuperscript epsilon () indicates an editorial change since the last revision or reapproval.1. Scope1.1 This guide covers mechanisms that may be used toauthenticate healthcare information (both administrative
3、andclinical) users to computer systems, as well as mechanisms toauthorize particular actions by users. These actions mayinclude access to healthcare information documents, as well asspecific operations on those documents (for example, reviewby a physician).1.2 This guide addresses both centralized a
4、nd distributedenvironments, by defining the requirements that a singlesystem shall meet and the kinds of information which shall betransmitted between systems to provide distributed authentica-tion and authorization services.1.3 This guide addresses the technical specifications forhow to perform use
5、r authentication and authorization. Theactual definition of who can access what is based on organi-zational policy.2. Referenced Documents2.1 ASTM Standards:2E1762 Guide for Electronic Authentication of Health CareInformationPS100 Provisional Specification for Authentication ofHealthcare Information
6、 Using Digital Signatures2.2 ANSI Standard:X9.45 Enhanced Management Controls Using Digital Sig-natures and Attribute Certificates32.3 Other Standards:ECMA1-219 Authentication and PrivilegeAttribute SecurityApplications with Related Key Distribution Functions4FIPS PUB 112 Password Usage53. Terminolo
7、gy3.1 Definitions:3.1.1 access control lista piece of access controlinformation, associated with a target, that specifies the initia-tors who may access the target.3.1.2 capabilitya piece of access control information,associated with an initiator, which authorizes the holder toaccess some target.3.1
8、.3 claimantparty requesting authentication; may be aperson or a device.3.1.4 initiatoran entity (for example, a user) who requestsaccess to some object.3.1.5 principallegitimate owner of an identity.3.1.6 security labelaccess control information bound toinitiators and targets. The initiator and targ
9、et labels are com-pared to determine if access is allowed.3.1.7 targetan entity (for example, a file or document) thatmay be accessed by an initiator.3.1.8 verifieranother party seeking to authenticate princi-pal.3.2 Acronyms:3.2.1 ACIAccess Control Information3.2.2 ACLAccess Control List3.2.3 ADFAc
10、cess Control Decision Function3.2.4 ADIAccess Control Decision Information3.2.5 AEFAccess Control Enforcement Function3.2.6 PINPersonal Identification Number4. Significance and Use4.1 This guide has three purposes:4.1.1 To serve as a guide for developers of computersoftware that provides or makes us
11、e of authentication andauthorization processes,4.1.2 To serve as a guide to healthcare providers who areimplementing authentication and authorization mechanisms,and1This guide is under the jurisdiction of ASTM Committee E31 on HealthcareInformatics and is the direct responsibility of Subcommittee E3
12、1.25 on HealthcareData Management, Security, Confidentiality, and Privacy.Current edition approved March 1, 2013. Published March 2013. Originallyapproved in 1998. Last previous edition approved in 2005 as E1985 98(2005).DOI: 10.1520/E1985-98R13.2For referenced ASTM standards, visit the ASTM website
13、, www.astm.org, orcontact ASTM Customer Service at serviceastm.org. For Annual Book of ASTMStandards volume information, refer to the standards Document Summary page onthe ASTM website.3Available from American National Standards Institute, 11 W. 42nd St., 13thFloor, New York, NY 10036.4Available fro
14、m ECMA International, Rue du Rhone 114, CH, 1204, Geneva.5Available from National Technical Information Service, U.S. Department ofCommerce, Springfield, VA. http:/csrc.nist.gov or www.ntis.gov.Copyright ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959. United
15、 StatesNOTICE: This standard has either been superseded and replaced by a new version or withdrawn.Contact ASTM International (www.astm.org) for the latest information14.1.3 To be a consensus standard on the design,implementation, and use of authentication and authorizationmechanisms.4.2 Additional
16、standards will define interoperable protocolsand message formats that can be used to implement thesemechanisms in a distributed environment, using specific com-mercial technologies such as digital signatures.5. User Authentication5.1 Authentication ensures the identity of a user. Thelegitimate owner
17、 of an identity is known as a principal.Authentication occurs when a claimant has presented a prin-cipals identity and claims to be that principal. Authenticationallows the other party (verifier) to verify that the claim islegitimate.5.2 Requirements:5.2.1 Users shall be authenticated for access to
18、healthinformation.5.2.2 Users may be authenticated at the system, subsystem,application, or medical record level.5.2.3 Users shall be authenticated by one or more of thefollowing methods based on organizational policy:5.2.3.1 Claimant demonstrates knowledge of a password, orthe like,5.2.3.2 Claimant
19、 demonstrates possession of a token, orsomething similar,5.2.3.3 Claimant exhibits some physical characteristic, likea fingerprint, and5.2.3.4 Cryptographic techniques.5.2.4 Remote access to health information shall be mutuallyauthenticated.5.2.5 Determination of which method or methods to use forau
20、thentication shall be based on a risk assessment and organi-zational policy.5.2.6 For accountability purposes, authentication shall bebased upon an individual principal rather than upon a role.5.3 Knowledge:5.3.1 Password or Personal Identification Number:5.3.1.1 In any environment, a user can be au
21、thenticatedusing a password or a personal identification number (PIN).The claimant shall enter a password or PIN for authenticationpurposes. The verifier shall then verify the password or PIN ofthe claimant.5.3.1.2 The password or PIN shall be protected againstdisclosure. For guidelines on password
22、generation and usagesee FIPS PUB 112.5.3.1.3 In a multiple system environment, a single passwordor PIN may be used for authentication.5.3.2 Challenge-ResponsePassword or PIN-basedschemes may be augmented by the challenge-response mecha-nism. In challenge-response, as part of the authenticationprotoc
23、ol, the verifier sends the claimant a non-repeating value(challenge) in advance. The claimant sends a response to theverifier based on the challenge.5.4 Possession:5.4.1 The user or claimant shows possession by presentinga physical object or token that is unique to the principal orclaimant. The toke
24、n shall contain information unique to theprincipal or claimant. The claimant shall present the token asproof of identity. A password or PIN may be used to accessinformation on token. The verifier shall then verify the token ofthe claimant.5.4.2 The information shall be protected against duplicationo
25、r theft.5.4.3 Determination of which type of form factor may beused is based on risk assessment and organizational policy.5.4.4 The form factors may include but are not limited to thefollowing:5.4.4.1 Smart Card,5.4.4.2 PCMCIA,5.4.4.3 Diskettes, and5.4.4.4 Hand held password or challenge response ge
26、nera-tors.5.4.5 The form factors may also be used for cryptographictechniques.5.5 Physical Characteristic:5.5.1 Certain physical features of the human body arerelatively unique to an individual. These features are calledbiometrics. Biometric authentication is the measurement of aunique biological fe
27、atures used to verify the claimed identity ofa principal. The claimant shall present the biometric as proof ofidentity. The biometric may be stored on a token. A passwordor PIN may be used to access the biometric. The verifier shallthen verify the biometric of the claimant.5.5.2 The biometric shall
28、be protected against duplication ortheft.5.5.3 Determination of which type of biometric may be usedis based on risk assessment and organizational policy.5.5.4 These biometrics include but are not limited to thefollowing:5.5.4.1 Fingerprints,5.5.4.2 Voice recognition,5.5.4.3 Retinal scan,5.5.4.4 Hand
29、 geometry,5.5.4.5 Signature dynamics or recognition, and5.5.4.6 Facial characteristics.5.6 Cryptographic Techniques:5.6.1 Authentication using cryptographic techniques arebased on the principle of convincing a verifier that because aclaimant possesses some secret key, the claimant is theprincipal cl
30、aimed. Symmetric or public key techniques may beused.5.6.2 Symmetric Key The principal and the verifier shallshare a symmetric key. The claimant shall either encrypt or sealthe information using that key. If the verifier can successfullydecrypt or verify that the seal is correct, then the claimant i
31、s theprincipal claimed to be. A non-repeating value may also beused as part of the information encrypted.5.6.3 Public KeyThe principal shall have a public/privatekey pair. The claimant digitally signs a challenge using hisprivate key. The verifier checks the digital signature, using thepublic key of
32、 the principal. If the signature checks correctly,then the claimant is the principal that he claimed to be. Anon-repeating value may also be used as part of the informationsigned. See also 5.3.2.E1985 98 (2013)25.6.4 A trusted on-line server may be used for authentica-tion. One of the following meth
33、ods may be used:5.6.4.1 The claimant shall encrypt or seal the health infor-mation with his or her key. A separate exchange with theauthentication server shall be used for verification. The verifierand the authentication server shall use a shared key.5.6.4.2 The claimant shall first conduct an excha
34、nge withthe authentication server to obtain a ticket which is then passedto the verifier. The exchange between the claimant and authen-tication server shall be protected using a shared key. The ticketshall be constructed in such a way that will be acceptable onlyto an entity knowing the shared key b
35、etween the verifier andthe authentication server. An example of this is the Kerberossystem.5.6.5 When using the public key cryptography, an off-lineserver may be used for authentication. Verifiers shall need toobtain the certified public keys of principals and certificaterevocation lists.6. Authoriz
36、ation6.1 Requirements:6.1.1 Three types of authorization are required based onorganizational policy:6.1.1.1 Users shall be authorized to access (read or write)healthcare information documents;6.1.1.2 Users shall be authorized to perform application-specific actions on a document (for example, physic
37、ian re-view); and6.1.1.3 Users shall be able to determine whether all neces-sary actions have been performed on the document, andwhether the users performing these actions were allowed to doso, according to any rules and limits agreed to by the partiesinvolved. For example, it may be a requirement t
38、hat documentsshall be reviewed by a physician prior to inclusion in themedical record.6.1.2 A users application-specific action on a documentwill be indicated using an electronic signature, as defined inGuide E1762. Particular actions are indicated using signaturepurposes. Thus, signatures are appli
39、ed in 6.1.1.2, and verifiedin 6.1.1.3. Generic access as described in 6.1.1.1 may beindicated using signatures, but this is not a requirement. Thistype of access may be needed to perform the specific actions of6.1.1.2.6.2 Access Control:6.2.1 In a distributed environment, the following entitiescan b
40、e identified: the initiator wishes to access some object: thetarget. Access is mediated by an access control enforcementfunction (AEF), that uses an access control decision function(ADF) to determine whether access is to be granted. Thisdecision is based on access control decision information (ADI)a
41、ssociated with the initiator, the target, the access request, andthe context within which access is taking place. In a singlesystem, access control is typically provided by the operatingsystem, using standard process separation mechanisms. In adistributed environment, each of the four entities above
42、 mayactually reside on a different system. Furthermore, each entitymay be under the control of a different security domain orpolicy, so that translation of access control information (forexample, user identities or roles) may be required. Althoughthis guide does not dictate where each entity resides
43、, it may bepossible to make use of existing operating system accesscontrol mechanisms if the AEF and ADF reside on the samesystem as the target.6.2.2 A variety of access control mechanisms have beendefined, each of which is appropriate for particular environ-ments. These include:6.2.2.1 Access contr
44、ol lists (ACLs) are associated with atarget and list the initiators which may access the target. ACLsmight list individual user identities, as well as names of groupsof users, and roles. Using groups and roles can minimize thesize of the ACL. Many operating systems support ACLs. In adistributed envi
45、ronment, some method for verifying the iden-tity of a remote initiator (for example, a public key certificate)is needed in order to provide remote access. ACLs areparticularly appropriate when the number of targets is verylarge compared to the number of initiators.6.2.2.2 Capabilities are associated
46、 with an initiator andspecify the targets that may be accessed. Targets might becombined into groups in order to minimize the size ofcapabilities. In some cases (for example, a patient record),targets are hierarchically structured so that a capability mightgrant access to the “root” object and all s
47、ubordinates. In othercases, independent targets (for example, all patients on a ward)can be combined into a group, as discussed below. Fewoperating systems implement capabilities. However, in a dis-tributed environment, there is a great deal of work usingcertificates to bind access control and other
48、 information to ausers identity (see, for example, ANSI X9.45). Such certifi-cates can be used to specify such capabilities.6.2.2.3 Security labels are associated with both the initiatorand the target and are compared by the ADF to determine ifaccess is allowed. Labels were developed for the militar
49、yenvironment and typically contain a security classification. Aninitiator may, then, read a target if the initiators classificationdominates (is greater than) that of the target. Labels are usefulif there are many initiators and targets, but only a coarsegranularity of access (that is, a classification) is needed.6.2.2.4 The mechanisms in 6.2.2.1-6.2.2.3 may, of course,be combined, so that, for example, a user shall have anappropriate classification, and be on anACL, in order to accessa file.6.2.3 Access control policies may be rule-based, in whichcas
