IS Unit 7_Network Security


Published on

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

IS Unit 7_Network Security

  1. 1. Chapter 7:Chapter 7:Chapter 7:Chapter 7:----Network SecurityNetwork SecurityNetwork SecurityNetwork SecurityBy:- Sarthak Patel (
  2. 2. OutlineDigital SignaturesAuthentication ProtocolsDigital Signature StandardsApplication AuthenticationTechniques Like KerberosSarthak Patel ( AuthenticationTechniques Like KerberosX.509 DirectoryAuthentication ServicesActive Directory Service OfWindows NT/Windows 2000
  3. 3. Digital SignaturesDigital signatures provide the ability to:verify author, date & time of signatureauthenticate message contentsbe verified by third parties to resolve disputesSarthak Patel (
  4. 4. Digital Signature Propertiesmust depend on the message signedmust use information unique to senderto prevent both forgery and denialmust be relatively easy to produceSarthak Patel ( be relatively easy to producemust be relatively easy to recognize & verifybe computationally infeasible to forgebe practical save digital signature in storage
  5. 5. Digital SignatureCategories of Digital Signature:DirectArbitrated.Sarthak Patel (
  6. 6. Direct Digital Signaturesinvolve only sender & receiverassumed receiver has sender’s public-keydigital signature made by sender signing entire message orhash with private-keycan encrypt using receivers public-keySarthak Patel ( encrypt using receivers public-keyimportant that sign first then encrypt message & signaturesecurity depends on sender’s private-key
  7. 7. Direct Digital SignatureSarthak Patel (, Authentication & Digital Signature
  8. 8. Weakness of Direct D.SThe validity of the scheme depends on the security of the sendersprivate key.If a sender later wishes to deny sending a particular message, thesender can claim that the private key was lost or stolen and thatsomeone else forged his or her signature.Sarthak Patel ( example is to require every signed message to include atimestamp (date and time) and to require prompt reporting ofcompromised keys to a central authority.
  9. 9. Arbitrated Digital Signaturesinvolves use of arbiterAvalidates any signed messagethen dated and sent to recipientrequires suitable level of trust in arbitercan be implemented with either private or public-keySarthak Patel ( be implemented with either private or public-keyalgorithmsarbiter may or may not be able to see message
  10. 10. Authentication Protocolsused to convince parties of each others identity and toexchange session keysmay be One-way or Mutualkey issues areconfidentiality – to protect session keysSarthak Patel ( – to protect session keystimeliness – to prevent replay attackspublished protocols are often found to have flaws and need tobe modified
  11. 11. (Mutual Authentication) ReplayAttackswhere a valid signed message is copied and later resentSimple replay: The opponent simply copies a message and replays it later.Repetition that can be logged: An opponent can replay atimestamped message within the valid time windowRepetition that cannot be detected: This situation could ariseSarthak Patel ( that cannot be detected: This situation could arisebecause the original message could have been suppressed and thus did not arriveat its destination; only the replay message arrivesBackward replay without modification: This is a replay back tothe message sender.
  12. 12. Countermeasures to avoid ReplayAttackTimestamps (needs synchronized clocks)Party A accepts a message as fresh only if the message contains atimestamp that, in As judgment, is close enough to Asknowledge of current time. This approach requires that clocksamong the various participants be synchronized.Sarthak Patel ( (using unique nonce)Party A, expecting a fresh message from B, first sends B a nonce(challenge) and requires that the subsequent message (response)received from B contain the correct nonce value.
  13. 13. Using Symmetric Encryptionas discussed previously, we can use a two-level hierarchy ofkeysusually with a trusted Key Distribution Center (KDC)each party shares own master key with KDCKDC generates session keys used for connections betweenSarthak Patel ( generates session keys used for connections betweenpartiesmaster keys used to distribute these to them
  14. 14. Needham-Schroeder Protocoloriginal third-party key distribution protocolfor session betweenA B mediated by KDCprotocol overview is:1. A->KDC: IDA || IDB || N1Sarthak Patel ( A->KDC: IDA || IDB || N12. KDC ->A: EKa[Ks || IDB || N1 || EKb[Ks||IDA] ]3. A -> B: EKb[Ks||IDA]4. B ->A: EKs[N2]5. A -> B: EKs[f(N2)]
  15. 15. Needham-Schroeder Protocolused to securely distribute a new session key forcommunications betweenA & Bbut is vulnerable to a replay attack if an old session key hasbeen compromisedSarthak Patel (
  16. 16. Using Public-Key Encryptionhave a range of approaches based on the use of public-keyencryptionneed to ensure have correct public keys for other partiesusing a central Authentication Server (AS)various protocols exist using timestamps or noncesSarthak Patel ( protocols exist using timestamps or nonces
  17. 17. Denning AS ProtocolDenning 81 presented the following:Sarthak Patel ( session key is chosen byA, henceAS need not betrusted to protect ittimestamps prevent replay but require synchronizedclocks
  18. 18. One-Way Authenticationrequired when sender & receiver are not in communicationsat same time (e.g., email)have header in clear so can be delivered by email systemSarthak Patel (
  19. 19. Using Symmetric Encryptioncan refine use of KDC but can’t have final exchange ofnonces:1. A->KDC: IDA || IDB || N12. KDC ->A: EKa[Ks || IDB || N1 || EKb[Ks||IDA] ]3. A -> B: EKb[Ks||IDA] || EKs[M]Sarthak Patel ( A -> B: EKb[Ks||IDA] || EKs[M]does not protect against replayscould rely on timestamp in message, though email delays makethis problematic
  20. 20. Public-Key Approacheshave seen some public-key approachesif confidentiality is major concern, can use:A->B: EPUb[Ks] || EKs[M]has encrypted session key, encrypted messageif authentication needed, use a digital signature with a digitalSarthak Patel ( authentication needed, use a digital signature with a digitalcertificate:A->B: M || EPRa[H(M)] || EPRas[T||IDA||PUa]with message, signature, certificate
  21. 21. Digital Signature Standard (DSS)US Govt approved signature schemedesigned by NIST & NSA in early 90spublished as FIPS-186 in 1991revised in 1993, 1996 & then 2000uses the SHA hash algorithmSarthak Patel ( the SHA hash algorithmDSS is the standard, DSA is the algorithmFIPS 186-2 (2000) includes alternative RSA & ellipticcurve signature variants
  22. 22. Digital Signature Algorithm (DSA)creates a 320 bit signaturewith 512-1024 bit securitysmaller and faster than RSAa digital signature scheme onlysecurity depends on difficulty of computing discreteSarthak Patel ( depends on difficulty of computing discretelogarithms
  23. 23. Digital Signature Algorithm (DSA)Sarthak Patel (
  24. 24. DSA Signature Creationto sign a message M the sender:generates a random signature key k, k<qk must be random, be destroyed after use, and never be reusedthen compute signature pair:r = (gk(mod p))(mod q)Sarthak Patel ( = (gk(mod p))(mod q)s = (k-1.H(M)+ x.r)(mod q)sends signature (r,s) with message M
  25. 25. Authentication Applicationsdeveloped to support application-level authentication &digital signatureswill discuss Kerberos – a private-key authentication servicediscuss X.509 - a public-key directory authentication serviceSarthak Patel (
  26. 26. KerberosAuthentication service developed as a part of MIT’sAthenaprojectprovides centralized private-key third-party authentication ina distributed networkallows users access to services distributed through networkwithout needing to trust all workstationsSarthak Patel ( needing to trust all workstationsrather all trust a central authentication servertwo versions in use: 4 & 5
  27. 27. Why Kerberos is needed ?Problem: Not trusted workstation to identifytheir users correctly in an open distributed environment3Threats:Pretending to be another user from the workstationSending request from the impersonated workstationSarthak Patel ( request from the impersonated workstationReplay attack to gain service or disrupt operations
  28. 28. Why Kerberos is needed ? Cont.Solution:Building elaborate authentication protocols at eachserverA centralized authentication server (Kerberos)Sarthak Patel (
  29. 29. Requirements for KERBEROSSecure:An opponent does not find it to be the weak linkReliable:The system should be able to back up anotherTransparent:Sarthak Patel ( user should not be aware of authenticationScalable:The system supports large number of clients and severs
  30. 30. Versions of KERBEROSTwo versions are in common useVersion 4 is most widely used versionVersion 4 uses of DESVersion 5 corrects some of the security deficiencies ofVersion 4Sarthak Patel ( 4Version 5 has been issued as a draft Internet Standard(RFC 1510)
  31. 31. Kerberos v4 Overviewa basic third-party authentication schemehave an Authentication Server (AS)users initially negotiate with AS to identify selfAS provides a non-corruptible authentication credential (ticketgranting ticketTGT)Sarthak Patel ( ticketTGT)have aTicket Granting server (TGS)users subsequently request access to other services fromTGS onbasis of usersTGT
  32. 32. Kerberos v4 Dialogue1. obtain ticket granting ticket from AS• once per session2. obtain service granting ticket fromTGT• for each distinct service required3. client/server exchange to obtain serviceSarthak Patel ( client/server exchange to obtain service• on every service request
  33. 33. Kerberos Version 4: Dialog 1- SimplePc=password of clientSarthak Patel ([IDc,ADc,IDv]kv=Secret Key betweenAS and V (Server)
  34. 34. whereC= clientAS= authentication serverV=serverID = identifier of user on CSarthak Patel ( identifier of user on CIDV= identifier ofVPC= password of user on CADC= network address of CKv= secret encryption key shared byAS andV
  35. 35. Kerberos Version 4 : Dialog 2-More SecureOnce per userlogon sessionticketTGS=EKtgs[IDc,ADc,IDtgs,TS1,LifeTime1 ]Sarthak Patel ( per type ofservice
  36. 36. Kerberos Version 4 : Dialog 2- More Secure Cont.Once per service sessionSarthak Patel ( TicketV+ IDcTicketV=EKv[IDc,ADc,IDv,Ts2,Lifetime2]
  37. 37. Kerberos: The Version 4 AuthenticationDialogKERBEROSOnce per user logon sessionticketTGS=EKtgs [Kc.tgs,IDc,ADc,IDtgs,TS2,Sarthak Patel ( IDc + IDtgs +TS12- EKc [Kc.tgs,IDtgs,Ts2,Lifetime2,TicketTGS]IDc,ADc,IDtgs,TS2,LifeTime2 ]
  38. 38. Kerberos: The Version 4 AuthenticationDialog Cont.KERBEROSOnce per type of serviceticketTGS=EKtgs [Kc.tgs,IDc,ADc,IDtgs,TS2, LifeTime2 ]Sarthak Patel ( TicketTGS + AuthenticatorC +IDv4-EKc.tgs[ Kc.v,IDv,Ts4,Ticketv]AuthenticatorC=EKc.tgs[IDc,ADc,TS3]ticketV=EKV[Kc.v,IDc,ADc,IDv, TS4,LifeTime4 ]
  39. 39. Kerberos: The Version 4 AuthenticationDialog Cont.Once per service sessionSarthak Patel ( TicketV+ AuthenticatorCTicketV=EKv [Kv.c, IDc, ADc, IDv, TS4, Lifetime4]AuthenticatorC=EKc.v [IDc,ADc,TS5]6- EKc.v[TS5+1]
  40. 40. Overview of Kerberos: 1Sarthak Patel (
  41. 41. Overview of Kerberos: 2Sarthak Patel (
  42. 42. Overview of Kerberos: 3Sarthak Patel (
  43. 43. Overview of Kerberos: 4Sarthak Patel (
  44. 44. Kerberos 4 OverviewSarthak Patel (
  45. 45. Tickets:Contains information which must be considered private tothe userAllows user to use a service or to accessTGSReusable for a period of particular timeSarthak Patel ( for a period of particular timeUsed for distribution of keys securely
  46. 46. AuthenticatorsProves the client’s identityProves that user knows the session keyPrevents replay attackUsed only once and has a very short life timeOne authenticator is typically built per session of use of aSarthak Patel ( authenticator is typically built per session of use of aservice
  47. 47. Kerberos RealmsA single administrative domain includes:a Kerberos servera number of clients, all registered with serverapplication servers, sharing keys with serverWhat will happen when users in one realm need access toSarthak Patel ( will happen when users in one realm need access toservice from other realms?:Kerberos provide inter-realm authentication
  48. 48. Inter-realm Authentication:Kerberos server in each realm shares a secret key with otherrealms.It requiresKerberos server in one realm should trust the one in otherrealm to authenticate its usersSarthak Patel ( to authenticate its usersThe second also trusts the Kerberos server in the first realmProblem: N*(N-1)/2 secure key exchange
  49. 49. Request for Service in another realm:Sarthak Patel (
  50. 50. KERBEROS Version 5 versus Version4Environmental shortcomings ofVersion 4:Encryption system dependence: DESInternet protocol dependenceTicket lifetimeAuthentication forwardingSarthak Patel ( forwardingInter-realm authentication
  51. 51. KERBEROS Version 5 versus Version4Technical deficiencies ofVersion 4:Double encryptionSession KeysSarthak Patel ( KeysPassword attack
  52. 52. RealmIndicates realm of the userOptionsTimesFrom: the desired start time for the ticketTill: the requested expiration timeNew Elements in Kerberos Version 5Sarthak Patel ( the requested expiration timeRtime: requested renew-till timeNonceA random value to assure the response is fresh
  53. 53. Kerberos Version 5 Message Exchange:1To obtain ticket-granting ticket:(1)C AS : Options || IDc || Realmc || IDtgs ||Times ||Nonce1(2) AS C : Realmc || IDc ||Ticket tgs ||EKc [ Kc,tgs || IDtgs ||Times || Nonce1 ||| Realm tgs ]Sarthak Patel ( [ Kc,tgs || IDtgs ||Times || Nonce1 ||| Realm tgs ]Ticket tgs= EKtgs [ Flags || Kc,tgs || Realm c ||IDc ||ADc ||Times]
  54. 54. Kerberos Version 5 Message Exchange:2To obtain service-granting ticket :(3)C TGS : Options || IDv ||Times || Nonce2 ||Ticket tgs ║Authenticator c(4)TGS C : Realmc || IDc ||Ticket v || EK c,tgs [ Kc,v ║Times||Nonce2 || IDv ║ Realm v]Sarthak Patel ( || IDv Realm v]Ticket tgs= EKtgs [ Flags || Kc,tgs || Realm c || IDc ||ADc ||Times]Ticket v : EK v [Kc,,v ║ Realmc || IDc ║ADc ║Times ]Authenticator c : EK c,tgs [IDc ║ Realmc ║TS1]
  55. 55. Kerberos Version 5 Message Exchange:3To obtain service(5) C S : Options ||Ticket v||Authenticator c(6) S C : EK c,v [TS2|| Subkey || Seq# ]Ticket v : EK v [Flags || Kc,v || Realmc ||Sarthak Patel ( v : EK v [Flags || Kc,v || Realmc ||IDc ||ADc ||Times ]Authenticator c : EK c,v [IDc || Realmc ||TS2 || Subkey|| Seq# ]
  56. 56. Kerberos : StrengthsUsers passwords are never sent across the network, encrypted orin plain textSecret keys are only passed across the network in encrypted formClient and server systems mutually authenticateIt limits the duration of their users authentication.Authentications are reusable and durableSarthak Patel ( are reusable and durableKerberos has been scrutinized by many of the top programmers,cryptologists and security experts in the industry
  57. 57. Certificate:Electronic counterparts to driver licenses, passportsVerifies authenticity of the public keyPrevents impersonationEnables individuals and organizations to secure business andpersonal transactionsSarthak Patel ( transactions
  58. 58. What a certificate includes:Name of Entity being CertifiedPublic KeyName of CertificateAuthoritySerial NumberExpiration DateSarthak Patel ( DateDigital signature of the issuerOther information (optional)
  59. 59. Certificate Authorities:Trusted entity which issue and manage certificates for a populationof public-private key-pair holders.A digital certificate is issued by a CA and is signed with CA’sprivate key.Sarthak Patel (
  60. 60. Who are the Certificate Authorities?VeriSignGTE CyberTrustEntrustIBMCertCoSarthak Patel ( / Cylink
  61. 61. Certificate Issuance Process:Generate public/private key pairSends public key to CAProves identity to CA - verifyCA signs and issues certificateCA e-mails certificate or Requestor retrieves certificate fromSarthak Patel ( e-mails certificate or Requestor retrieves certificate fromsecure websitesRequestor uses certificate to demonstrate legitimacy of theirpublic key
  62. 62. Types of Digital CertificatesE-Mail CertificatesBrowser CertificatesServer (SSL) CertificatesSoftware Signing CertificatesSarthak Patel ( Signing Certificates
  63. 63. Potential security holes:Was the user really identified?Security of the private keyCan the Certificate Authority be trusted?Names are not uniqueSarthak Patel ( are not unique
  64. 64. X.509 Directory Authentication ServiceDefines a framework for the authentication servicesThe X.509 directory serving as a repository of public-keycertificatesDefines alternative authentication protocolsSarthak Patel (
  65. 65. X.509 Certificate formatVersionSerial numberAlgorithmAlgorithmNotation to define a certificate:CA<<A>>=CA{V,SN,AI,CA,Ta,A,Ap}AlgorithmParametersIssuerNot beforeNot afterSubjectAlgorithmParameterKeySignatureSarthak Patel( ofvaliditySubject’spublic keyCA<<A>>=CA{V,SN,AI,CA,Ta,A,Ap}whereY<<X>>= the certificate of user Xissued by certification authority YY{I}=the signing of I by Y. It consists ofI with an enciphered hash codeappended.
  66. 66. Securely Obtain a Public KeyScenario:A has obtain a certificate from the CA X1B has obtain a certificate from the CA X2A can read the B’s certificate but cannot verify it.Solution: X1<<X2> X2<<B>>Sarthak Patel ( obtain the certificate of X2 signed by X1 from directory. obtain X2’spublic keyA goes back to directory and obtain the certificate of B signed by X2.obtain B’s public key securely
  67. 67. X.509 CA HierarchySarthakPatel( acquires B certificateusing chain:X<<W>>W<<V>>V<<Y>>Y<<Z>> Z<<B>>B acquires A certificateusing chain:Z<<Y>>Y<<V>>V<<W>>W<<X>> X<<A>>67
  68. 68. Authentication Procedures:Three alternative authentication procedures:One-WayAuthenticationTwo-WayAuthenticationThree-WayAuthenticationSarthak Patel ( use public-key signatures
  69. 69. One-Way Authentication:1 message ( A->B) used to establishthe identity ofA and that message is fromAmessage was intended for Bintegrity & originality of messageSarthak Patel ( B1-A {ta,ra,B,sgnData,PUb[Kab]}Ta-timestamp A=nonce B =identitysgnData=signed with A’s private key
  70. 70. Two-Way Authentication2 messages (A->B, B->A) which also establishes in addition:the identity of B and that reply is from Bthat reply is intended forAintegrity & originality of replySarthak Patel ( B1-A {ta,ra,B,sgnData,KUb[Kab]}2-B {tb,rb,A,sgnData,KUa[Kab]}
  71. 71. Three-Way Authentication3 messages (A->B, B->A,A->B) which enables aboveauthentication without synchronized clocksSarthak Patel ( B1- A {ta,ra,B,sgnData,KUb[Kab]}2 -B {tb,rb,A,sgnData,KUa[Kab]}3- A{rb}
  72. 72. THE ENDTHE ENDSarthak Patel (