1、Designation: E 1985 98 (Reapproved 2005)An American National StandardStandard Guide forUser Authentication and Authorization1This standard is issued under the fixed designation E 1985; 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 (e) 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 administrativ
3、e 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
4、 and 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 u
5、ser authentication and authorization. Theactual definition of who can access what is based on organi-zational policy.2. Referenced Documents2.1 ASTM Standards:2E 1762 Guide for Electronic Authentication of HealthcareInformationPS 100 Provisional Specification for Authentication ofHealthcare Informat
6、ion 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 Privilege Attribute Secu-rity Applications with Related Key Distribution Func-tions4FIPS PUB 112 Password Usage53. Te
7、rminology3.1 Definitions:3.1.1 access control lista piece of access control informa-tion, associated with a target, that specifies the initiators whomay access the target.3.1.2 capabilitya piece of access control information,associated with an initiator, which authorizes the holder toaccess some tar
8、get.3.1.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 a
9、nd target labels are com-pared to determine if access is allowed.3.1.7 targetan entity (for example, a file or document)that may 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.
10、3 ADFAccess 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 m
11、akes use of authentication andauthorization processes,4.1.2 To serve as a guide to healthcare providers who areimplementing authentication and authorization mechanisms,and4.1.3 To be a consensus standard on the design, implemen-tation, and use of authentication and authorization mecha-nisms.1This gu
12、ide is under the jurisdiction of ASTM Committee E31 on HealthcareInformatics and is the direct responsibility of Subcommittee E31.25 on HealthcareManagement, Security, Confidentiality, and Privacy.Current edition approved Nov. 1, 2005. Published January 2006. Originallyapproved in 1998. Last previou
13、s edition approved in 1998 as E 1985 98.2For referenced ASTM standards, visit the ASTM website, 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 Ameri
14、can National Standards Institute, 11 W. 42nd St., 13thFloor, New York, NY 10036.4Available from 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.1Copyright A
15、STM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959, United States.4.2 Additional standards will define interoperable protocolsand message formats that can be used to implement thesemechanisms in a distributed environment, using specific com-mercial technologies s
16、uch as digital signatures.5. User Authentication5.1 Authentication ensures the identity of a user. Thelegitimate owner 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 par
17、ty (verifier) to verify that the claim islegitimate.5.2 Requirements:5.2.1 Users shall be authenticated for access to 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 met
18、hods based on organizational policy:5.2.3.1 Claimant demonstrates knowledge of a password, orthe like,5.2.3.2 Claimant 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 a
19、ccess to health information shall be mutuallyauthenticated.5.2.5 Determination of which method or methods to use forauthentication 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 u
20、pon a role.5.3 Knowledge:5.3.1 Password or Personal Identification Number:5.3.1.1 In any environment, a user can be authenticatedusing a password or a personal identification number (PIN).The claimant shall enter a password or PIN for authenticationpurposes. The verifier shall then verify the passwo
21、rd or PIN ofthe claimant.5.3.1.2 The password or PIN shall be protected againstdisclosure. For guidelines on password 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-basedsch
22、emes may be augmented by the challenge-response mecha-nism. In challenge-response, as part of the authenticationprotocol, 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
23、claimant shows possession by presentinga physical object or token that is unique to the principal orclaimant. The token 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.
24、 The verifier shall then verify the token ofthe claimant.5.4.2 The information shall be protected against duplicationor 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 th
25、efollowing: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 genera-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
26、 individual. These features are calledbiometrics. Biometric authentication is the measurement of aunique biological features 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 b
27、e used to access the biometric. The verifier shallthen verify the biometric of the claimant.5.5.2 The biometric shall 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 includ
28、e 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 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 th
29、e principle of convincing a verifier that because aclaimant possesses some secret key, the claimant is theprincipal claimed. 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 infor
30、mation using that key. If the verifier can successfullydecrypt or verify that the seal is correct, then the claimant is 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 claima
31、nt digitally signs a challenge using hisprivate key. The verifier checks the digital signature, using thepublic key of 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. Se
32、e also 5.3.2.5.6.4 A trusted on-line server may be used for authentica-tion. One of the following methods may be used:E 1985 98 (2005)25.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 verificat
33、ion. The verifierand the authentication server shall use a shared key.5.6.4.2 The claimant shall first conduct an exchange 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 sha
34、red key. The ticketshall be constructed in such a way that will be acceptable onlyto an entity knowing the shared key between 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 authentica
35、tion. Verifiers shall need toobtain the certified public keys of principals and certificaterevocation lists.6. Authorization6.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
36、 documents;6.1.1.2 Users shall be authorized to perform application-specific actions on a document (for example, physician 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 allo
37、wed to doso, according to any rules and limits agreed to by the partiesinvolved. For example, it may be a requirement that 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 si
38、gnature, as defined inGuide E 1762. Particular actions are indicated using signaturepurposes. Thus, signatures are applied 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 p
39、erform the specific actions of6.1.1.2.6.2 Access Control:6.2.1 In a distributed environment, the following entitiescan be identified: the initiator wishes to access some object: thetarget. Access is mediated by an access control enforcementfunction (AEF), that uses an access control decision functio
40、n(ADF) to determine whether access is to be granted. Thisdecision is based on access control decision information (ADI)associated 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 ope
41、ratingsystem, using standard process separation mechanisms. In adistributed environment, each of the four entities above 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 informati
42、on (forexample, user identities or roles) may be required. Althoughthis guide does not dictate where each entity resides, 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 me
43、chanisms have beendefined, each of which is appropriate for particular environ-ments. These include:6.2.2.1 Access control 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
44、roles. Using groups and roles can minimize thesize of the ACL. Many operating systems support ACLs. In adistributed environment, 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 appr
45、opriate when the number of targets is verylarge compared to the number of initiators.6.2.2.2 Capabilities are associated 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 pat
46、ient record),targets are hierarchically structured so that a capability mightgrant access to the “root” object and all subordinates. In othercases, independent targets (for example, all patients on a ward)can be combined into a group, as discussed below. Fewoperating systems implement capabilities.
47、However, in a dis-tributed environment, there is a great deal of work usingcertificates to bind access control and other 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 ini
48、tiatorand the target and are compared by the ADF to determine ifaccess is allowed. Labels were developed for the militaryenvironment and typically contain a security classification. Aninitiator may, then, read a target if the initiators classificationdominates (is greater than) that of the target. L
49、abels 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 whichcase the policy is specified and enforced by the authorityresponsible for a security domain, or identity-based, in whichcase individual users control access to their own information.Rule-based p
