Protecting Security Information in Distributed ... - Semantic Scholar

22 downloads 0 Views 957KB Size Report
The paper shows how Security Iqformatwn for user au- lhenticatwn, peer-entity ..... In its simplest form the PAC is a signed sequence of security Privilege ...
Protecting Security Information in Distributed Systems Leif Nilsen and ~smund Skomedal* Alcatel Telecom Norway AS P.O. Box 310 @kern, N-051 10slo 5 Norway

Claus Fritzner,

This resultsin a needforprotectionmechanismsfromboth externaland internalthreats.

Abstract The paper shows how Security Iqformatwn for user aulhenticatwn, peer-entity authentication and access control is created and w“lised in large distributed systems. The protectwn mechanisms used are hashfwctions, symmetric and asymmetric cryptography. We describeand combine data formats for Secura”tyInjormatwn based on international standardsfrom several stawi-wdisatwn bodies.

The paper is organised as follow~ D~tributed systems, seeurityinformationand securitysetiees are deseribedin seetion2. Threatsagainstthis informationare discussedin section 3 and protection mechanisms are described in seetion 4. Finally, in section 5 we show how these mechanisms can be applied to standardised security informationformats,thus providingadequateprotection.

L Introduction 2. Security systems.

During the last few years considerable researeh has been earnled out on distributed systems. Them has also been increasingactivityin the area of standardisationon topics such as Document Filing and Retrieval (DFR), Open DistributedProcessing(ODP)and TransactionProcessing (’IT). On the securityscene,however,therehas been little activity. Now conceptsfromCCITT,ECMA,and 1S0 are emerging ([CC189],[CC189b],@3CM881,@3CM891 ~d [1S088]),but thereis still along way to go beforeone has real Open Distributed Systems with good security features.

When A wants to establisha connectionto B the protocol ix 1)Requesting public keys from the Directory. 2) The Dwtory returns the key certificate for B and possibly for A. These certifkates contain the public keys Ap and Bp of A and B. The secret keys AS and BS mMt be

hastxmrsupportedbysheNorwegian Teleeornrnunieation Administration and The RoyatNorwegian CQIUX51 forScientificandIndustrial Researchunder Grant IT mseareh

0333.22222.

245

.00 @ 1991 IEEE

distributed

Applicationsmay be distributed for various reasons such as sharing costly resources, distributed functionalityor building fault tolerance. This distribution demands a communicationsystem between entities in the system. The Open Systems Interconnection(OSI) [1S0] has now becomea standardfor such communication. In the article “Experimental Seeure Distributed Information System” ~ri88], it is shownhow seeurityean be implementedin the upper layers of the 0S1 stack. Our approachis to use the CCITI’ X.500 series [CC189]to build a key certification and distributioncentre. Public keys [Dit76] are used for exchange of session keys for symmetric encryption in a hybrid crypto-system. The communication system can thenprovideservicesIikepeer-entityauthenticationduring associationestablishment confidentiality and authenticity of user data in transferbetweencommunicatingentities.

The Security Information we are eoncemed with here is used for human user authentication, peer-to-peer authentication of communicating entities and access controldecisionmaking. In open distributedsystemsall thesetypesof securityinformationmust becommunicated.

GH2986-8\91/0000/0245$01

in

2.1 The communication system.

In this paper we will deseribesome of our ideas relatedto this work. Parts of it have been implemented in an experimental nehvork ~ri88]. Further extensions, as describedin this paper, have been implementedthis year. In the design of our experimental network we have ecmcentratedon utilising Security Information in a way that makes the security features of the system mostly transparentto the humanuser.

* This

Information

2Q User authentication

safely stored within the end systems. All keys are importantpieces of Security Information. 3) A sends an authenticationmessage (AMA)to B. In

The securitymechanismsdescribedin 2.1 are tmnsparent to the human user. The mechanisms described in this sectionare partly visible to the user as he/she will have to interact directly with several security services. These services me defined in the standardECMA-138lECM891. Manyof the termsintroducedin this sectiooare &fmed in this standard and in the technical qort ECMA TR/46 @CM88].

addition to authentication information this message contains the public key Ap of A and secret session information(SSI) encryptedwith thepublickey of B. This session information is optional and is only sent if confidentiality or integrity is wanted in the following communication session, or a common secret value is wantedfor someother reason. 4) Bprovesrhatheis Bandisreadytotalk to Abysending his authenticationmessage(Ah4B).

When a user wants access to the system he/she activates the localwork-station.Theusermust fwt be authenticated to the system.This procedureshould take place only once during a ‘user-session’,even in a distributedsystem. The useris theprincipalinitiatorof activitiesin the systemand correct idcntifkation is fimdamental to the overall security. To provide flexibility and enable adoption by different users, the system should allow a user to authenticateby differentmethti - Conventionaluse of passwords. - Dynamicpasswordsusing hand-heldtoken devices. - Zero-knowledgeidentibtion using smartcards. - Biometricauthenticationmethods (e.g. handwriaensignatureverification[Mj089]).

Directory

Y El+-El (1)

(2)

Althoughpasswordsdo not seemto providemuchsecmity, it is the local security policy that will determine what authenticatwn level a user is given when he correctly identifies hmself according to one or more legal authenticationmethods. Figure 2 shows what takesplace during user identitkation. The black ‘bubble’ in the middle now represents the communication model from figure 1.The servicesinside the shadedarea are part of the trustedSecuritySystem.

Figure 1. BsWM.ing a secure connection between A and B

This activityas well as laterencryption/decryptionof user data is hidden in the communication system and is invisible to applicationprocessesand human users. In the rest of the paper it is important to remember that this functionalityis a part of the securecommunicationsystem.

The user presentshimself to the User Sponsor,which is a part of the Security System, and communicates User

Workstation

Peer+uity Awhendcatien

Authenticatim and Attribute Server Celtifkdm

(2) +

PrivileSe Attributes (3)

Figure2. User Authentication

246

tlllll

= PrivilegeAttributes

@

= ControlAttributes

Figure3. User - applicationassociation Authentication Information (AIu) with the trusted AuthenticationService (AS). The AS will then verify or deny the claimed identity of the user. This is done by execntingone or mom interactiveauthenticationprotocols between the AS-Server and the human user (l). If the identity is verifkd, a CertifiedMentifyis issued flom the AS to the Security Attribute Service (2). The Security Attribute Service represents an Attribute Authority that determinesthe cornxt attributesfor a user,consistentwith securitypolicy. The User Sponsoris then given the user’s PrivilegeAttributes(PAu)(3). ThesePrivilegeAttributes are an enrichmentof the user’s identity, and propagateto other security services which recognise the Attribute Authority. Privilegeattributesare used by other seMces for furtheraccesscontroldeckion and enforcement,audit purposesand interdoinuin communication. In distributed systems these services may not be co-located, hence certifiedidentitiesand privilege attributes must be issued in a trusted manner. In an implementation the authenticationand securityattributeservicesmaybe in the same end-system. This simplifks their intemction and onlyrequiresthe othersecurityservicesto knowaboutone AttributeAuthorityper Security Domain.

one’sown attributes,recognisedby objectidentifiersother than thosein ECMA-138. It is left to other standardisation bodies and implementorsto choose securityattributesand define the semanticsof their values. Privilege Attributesare associatedwith initiators and are another example of Security Information that is created and utilisedto maintainsecurityin the system. 2.3 User to application Association When a user wants access to a local application,the User Sponsor presents the user’s privilege attributes to the Secure AssociationService (SAS). This service is also a part of the trusted Security System. Authorisationis then performedby matchingthe privilegeattributesof the user against the correspondingControl Attributes (CAJ of the application. This access control decision is made accordingto roles implementingthe local securitypolicy. Control Attributes represent Security Information associatedwith targets. They are generatedand managed insidethe SecuritySystem. In this case theytell whatkind of security attributes a user needs in order to access an applicationin a given context e.g. an ordinaryemployee may get access to the word processor any time, but is not allowedto do file transferin the evening.

A proposalfor SecurityAttributes is given in the standard [email protected]]and includes - Authenticationlevel - Group - Role - ConfidentialityClass - Entity Identity

2.4 Application to application association. During a user session with an application, it is often necessaryfor this applicationto accessother applications. The fiist application will now act as initiator in the association and have it’s own set of privilege attributes @q). The second application may reside locally or remotely. The privilege attributesof the human user and

The philosophybehindthk approachis that one shouldnot malcea standardof thii kind tied to any particularsecurity policy. If theseattributesare not adequateonecan register

247

Figure4. Application- applicationassociation

initiating applicationare combkx-1and transferredto the target authorisation service. Such a combination of privilegeattributesis an exampleof attributesrepresenting a compound object. The SAS requests the Authorisation Service (local or remote) to check all privilege attributes againstthe controlattributesof the targetapplication. The AuthorisationServicemust thereforebe able to distinguish the privilege attributes of the user and initiating application.

AP:The publickey of a communicatingentity A. Must be transferredto B. BP:Thepublickeyof B. A receivesthis fromthe directory. As: The secret key of A. Must be hidden in A’s endsystem. B~:The secretkey of B. Mustbe hiddenin B’s end-system. AMA:Authenticationinformationin message3, Figure 1. For authenticatingA to B. AMB: Authenticationinformationin message4, Figure 1. For authenticatingB to A. SSL Secretsessioninformation. AIu:AuthenticationInformationfor users. PAU:PrivilegeAttributesof users as describedin section 2.2. PAa:PrivilegeAttributesof applications. CA,: ControlAttributesof applications.

In Figure 4 both a local and a remote association are shown. The main difference is that in the local case

authorisation is provided by a system that knows the attributes of the initiating application. When the target application is remote, this information, as well as user information, must be transferred to another end-system. Theprincipleis that accesscontroldecisionsare madeand enforcedby the SecuritySystem in the target end-system. During transferthe informationmay pass throughentities we do not trust at all. Hence the information must be protected.

This information may be vulnerable to the following threats Undetected modijfcation. This means that information has

Privilege attributes associated with applications can also be utilised in application - data relations, thus requiring control attributes to be associated with target data. Such an extension enables a uniform implementation of local and distributed security aspects.

been modit%d or originates from a false source. Modifkation can be done by externals for the sole purpose of destruction or by intemata trying to aeeess resources for which he/she is not authorised. Therefore we define the fouowing Categories U]: Issued by false authority U2: Modifkation by externals during communication. U3: Modifk.ation by internals.

3. Threats against Security Information To protect the security information described in chapter 2, we must discuss what kind of threats exists in the model. So far we have identified the following information that is

Conjl&ntiality violation. C: This means that secret informationis read by someone

used whenbuildinga securedistributedsystem:

it is not intendedfor.

248

AP: . :; B~ : AMA: Ah&: S!m AIu: PAU: PA: CA:

U1 x x

U2 x x .

.

x x ix)l) x x (x)

x x x x x x

U3

C

Ml .

M2 .

(x)2) (x)2)

xxx

.

.

x x .

M4

.

x x

x x

.

.

x x

(x)

x x .

.

M3 .

x x x x x x .

. X3) X3) . (x) x x

1)In zero-knowledgeprotocols,AIucan be issuedby a false authority. 2) If not hardwareprotected,X~can be corruptedby software. 3) Use of expiredsecretkey for signature. Table1. Misuse. Security information can be picked up by an eavesdropperfor later masqueradeor a user could try to use an out-dated key. We will distinguish between the following: Ml: Use by comet initiatoragainstwrongtarget. IW2Use by incorrectinitiatoragainstany target. M3: IReplayattacksby externals. M4: Use of invalid informationby internals. The identifkd security information is then vulnerable to different threats. This is shown in Table 1. A “x” means that we have a serious threat against the corresponding semuityinformation. The main lesson from this matrix is that most security information needs protection from undetected modification and misuse, i.e. integrity protection. Only informationfor user authenticationand secret keys need protexx.ionfmm disclosure. Using dynamic password or zero-knowledge techniques, even this authentication informationis non-confidential.The rest of the paper is concernedwith how cryptographictechniquesand careful choice of logical qualifier fields provide the necessary protection. 4. Protection

mechanisms

The securityinformationdescribedin chapter2 needsto be protected. The E(XVIATechnkal Report TR/46 @CM88]

and standard ECMA-138 l?3CM89] describe and standardisesome data structures for this kind of security information. The type of protection mechanisms is indicated, but any recommendation or description of specific cryptographic techniques are left out of these standards. This servestwo purposes. Firstly, the standard is not bound to a specific cryptographictechniquewhich might decrease the lifetime and validity of the standard. Secondly,it gives the KX@XIdesign freedom for future standardwritersand implementors. 4.1 Confidentiality Confidentiality means that information is not made availableor disclosedto unauthorisedindividuals,entities or processes.The only practical way to achieve this is to apply cryptographictechniques.The choice of the actual algorithm and its mode of operation will depend on application,security level and availablehardware. Oneof the mostcommonlyusedconfidentialityalgorithms in commercial security is the DES algorithm @3ES77]. DES is very fast when implemented in hardware and althoughit was designedto be used for a pxiod of ten to fifteenyears, it is still widely used and much studied.The general consensusamongst cryptologicresearcherstoday is that DES is an extremely good cipher with an unfortunately small key [Mas88]. DES is a symmetric encryptionalgorithm,which means that secretkeys must be exchangedbetween communicatingentities prior to a

confidentialsession. Our approachis to use DES for user data encryption, in combination with the asymmetric RSA-system Biv77] for exchangeof secret session keys duringcommunicationsetup. 4.2 Integrity This mechanismis used to ensure that informationis not modified, inserted or removed by unauthorised individuals,entities or processes.In a closed system with trustedentitiesthis couldbe implementedusinga Message AuthenticationCode (MAC), but this techniquedoes not easilyfit intoa systemwhereentitiesdo not sharecommon secrets. The integrity mechanism we use in our experimental network is built from cryptographic hash functionsand digital signaturesbased on RSA. The very idea of a digital signatureis that the receiverof a digital message should be able to verify the origin and integrity of the message using only public information. The receivershould also be able to prove to a third party that the message was sent by the genuine sender. Digital signatureswereone of the fundamentalproblemsin secure communication that was solved by public key cryptography.See the paper by Goldwasser, Micali and Rivest [GOL88] for a detailed but theoretical survey on digital signatures. If the messageitself is hiddenwithinthe signatureand fmt becomesknownduringthe verificationprocess,we havea digital signature scheme giving message recovery. This

approachhas been takenin the ISO/IECDIS 9796and can be used to sign messagesof a length less than half of the lengthof the RSA-modulus chosen.The otherprincipleis to append the signature to the message itself so that the received message consists of two parts, message and signature.This is knownas a digital signature scheme with appendix.

Independent of digital signature schemes, it is recommendedthat a one-wayhash functionbe applied to the messageprior to the signingprocess.The result of the hash functionis then input to the signaturealgorithm.This is done both for efficiencyand securitypurposes. Such a hash functionshouldgive a freedlengthoutput,say 128or 256 bits, irrespectiveof input message length. The hash functionmust alsobe collisionresistant.‘llii meansthat it is computationalinfeasibleto find two messagesthat hash to the same hash result, The X.509 [CC189]authenticationframeworkdescribesa hashfunctionto be usedwithX.509certificates.It has later been found to be insecure and modifkations to this

function are proposed [Cop89][Jun90].In spite of these weaknesses,this is the hash functionwe have used in our experigwntalsystem. Other approachesare to build hash functionsfrom a known symmetricblock cipher [Mey89] or to design special propose hash functions like MD4 ~iv90]. At the present time there is no definitecandidate for a hash function that has been studied for a sufficient length of time without any weaknesses being found. Designand analysisof hash functionsare thereforecurrent researchtopicsand the securitycommunityis still waiting fora good solutionto this problem.Forthcomingstandards and application requirements will determine what hash functionwe will use in the future. Given the hash function h, we describe our digital signatureschemewith appendixin the followingway A(M) = M IIAs [h(M)] User A signs the message M by “encrypting”the hash valueh(hl) usinghis secretRSA-keyAs. The result of the RSA computationis then appended to the message. This notationis used in section5. 43 Using control field values Integrity and confidentialityprotect security information from being modifkxi and known. In addition one adds control information in order to prevent security information from being replayed, used against wrong targetsor from wronginitiators. The controlfieldsmustbe protected with integrity mechanisms, but confidentiality servicesare not required. Below follows a descriptionof three different kinds of control information; random numbers,qualifierattributesand timestamps. In all security systems there is a need for true random numbers. Randomnumbersare used for makingkeys and initial values and are also used in protocols to achieve uniqueidentifiers. The identit%ris used to preventreplay of the securityinformation. When the security information is intended for use by a specific initiator against a specific target or a group of targets, qualifier attributes are needed. The qualifier attributes describe the initiator and/or the target(s). The attributes prevent the security information from being usedagainstunintendedtargetsand/orby wronginitiators. The attribute used in this design is the entity identity attributein the form of a distinguishedname. The security informationoften has some liiited validity time, or can only be used at particular time periods.

250

Security informationis thereforeoften issued with timeconstraints[Den81][Hab90]. 50 Protection

5.2 X311 Token The X.511 token is used as an authenticationtoken. A tokenwhichis createdby A and sentto B has the following form

of Security Information

In the distributedsystemdescribedin section2, the CCITT X.509Certif@e [CC189]togetherwith the CCI’ITX.511 Token [CC189b] are used to obtain peer-to-peer authenticationand secret sessionkey exchange. ECMA’S Privilege Attribute Certificates (PACS) and Control AttributesPackage (CAPS)are used to communicateand keep accesscontrol information.

A(tA,#, B, BP[encDatal) whera ~A = timestamp, consists of one or two *, the generationdate (whichis optional)and theexpirydate ~ #= non-repeatingnumbergenemtedby A c B = targetentity identity,distinguishedname c B ~[encData]= secret data encryptedwith B’s public key (tlis field is optional) ●

5.1 X.S09 Certificate The X.509 certificate is used to bind a public key to a DistinguishedName,DN. Thecertifkate of an objectwith distinguished name A, produced by the certification authorityCA, has the followingform

The token containscontrolfield valuesand, optionally,an encryptedfield which can containa secretkey. The token is signed by the issuing part using the private key of the issuer, thus protecting against U1 and U2. Integrity mechanismsonly assurethe correctnessof the information in a token. If a tokenalsocontainssomesecretinformation (SSI), this must be protected by a confidentialityservice (threatc).

CA