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


  1. 1. WEB Security
  2. 2. Information securityInformation security Pre computer ageRugged filing cabinets with combination lock Computer ageAutomated tools for security Computer securityCollection of tools to protect data Network security Internet security3
  3. 3. 3 aspects of information security3 aspects of information security Security Attack: Any action that compromisesthe security of information. Security Mechanism: A mechanism that isdesigned to detect, prevent, or recover from asecurity attack. Security Service: A service that enhances thesecurity of data processing systems andinformation transfers. A security service makesuse of one or more security mechanisms.4
  4. 4. Web Security Considerations WWW is Client server application over Internetand TCP/IP intranets Web is vulnerable to attacks on web servers overthe Internet The WEB is visible outlet for corporates Web servers are easy to configure and manage. Complex software hide many security flaws. Subverted servers will provide access to intranetsystems Users are not aware of the risks.
  5. 5. Internet security issuesInternet security issues Requirements Confidentiality Authentication Nonrepudiation Integrity Selection of algorithms Services Security mechanisms Creation, distribution and protection of secret keys Dependence of protocol Placement of security mechanisms6
  6. 6. OSI security architecture ITU-T recommendations X.800Defines a systematic approach International standardFor managers to provide securityFor security products Focuses on services, mechanisms andattacks7
  7. 7. Security services Definition in RFC 2828A processing or communication service thatis provided by a system to give a specifickind of protection to system resources X.800 servicesFive categories and 14 specific services8
  8. 8. Categories Authentication Access control Data Confidentiality Data Integrity Nonrepudiation9
  9. 9. Specific services Authentication(1) Peer entity authentication(2) Data-origin authentication Data confidentiality(3) Connection confidentiality(4) Connectionless confidentiality(5) Selective-field confidentiality(6) Traffic flow confidentiality10
  10. 10. Specific services Data integrity(7) Connection integrity with recovery(8) Connection integrity without recovery(9) Selective-field Connection Integrity(10) Connectionless Integrity(11) Selective-field Connectionless Integrity11
  11. 11. Specific services Nonrepudiation(12) Nonrepudiation, origin(13) Nonrepudiation, destination(14) Availability serviceProtect to ensure availabilityDepends on- Proper management & control of system resources12
  12. 12. Security mechanisms(Specific) Encipherment Digital signature Access control Data integrity Authentication exchange Traffic padding Routing control Notarization13
  13. 13. Security mechanisms(Pervasive) Trusted functionality Security label Event detection Security audit trail Security recovery14
  14. 14. Security AttacksSecurity Attacks15
  15. 15. Security AttacksSecurity Attacks Interruption: This is an attack onavailability Interception: This is an attack onconfidentiality Modification: This is an attack onintegrity Fabrication: This is an attack onauthenticity16
  16. 16. 17
  17. 17. Methods of DefenceMethods of Defence Encryption Software Controls (access limitations ina data base, in operating system protecteach user from other users) Hardware Controls (smartcard) Policies (frequent changes ofpasswords) Physical Controls20
  18. 18. Placement of securitymechanisms Link to linkHardware deviceApplication unawareDistribution of keys a problem End to endApplication/software awareLarge no of keys involved
  19. 19. Link layer mechanisms Radius (Remote authentication dial in userservice)NSA, RADIUS serversAuthentication, authorisation, accounting WEP (Wireless encryption Protocol)Static keys WPA (WiFi protected Access)Dynamic keys
  20. 20. Security mechanisms in theTCP/IP protocol stack
  21. 21. Need for IPSec Application level security services Electronic mail○ S/MIME, PGP Client Server○ Kerberos, X.509 Web access○ SSL, TLS, SET Enterprises need security at IP layer To protect security ignorant applications Additional security to applications with securitymechanisms Establish private secure network
  22. 22. IPv4 Header
  23. 23. IPv6 Header
  24. 24. IP Security Overview IPSec is not a single protocol. IPSec provides a set of securityalgorithms IPSec provides a general securityframework for a pair of communicatingentities Across LAN, Private & Public WANs Across Internet
  25. 25. IP Security Overview Applications of IPSecSecure branch office connectivity over theInternetSecure remote access over the InternetEstablsihing extranet and intranetconnectivity with partnersEnhancing electronic commerce security
  26. 26. IP Security Overview Benefits of IPSecBetter firewall protectionTransparent to applications (below transportlayer (TCP, UDP)Provide security for individual users IPSec can assure that:A router or neighbor advertisement comes froman authorized routerA redirect message comes from the router towhich the initial packet was sentA routing update is not forged
  27. 27. IP Security Scenario
  28. 28. IP Security Architectures Integrated architectureSupported in IPv6Difficult to implement in IPv4 Bump in The stack (BITS) for IPv4Between Data link and IP layers Bump in The Wire (BITW)Hardware implementation
  29. 29. IPSec RFCs IPSec documents:RFC 2401: An overview of security architectureRFC 2402: Description of a packetauthentication extension to IPv4 and IPv6RFC 2406: Description of a packet encryptionextension to IPv4 and IPv6RFC 2408: Specification of key managamentcapabilities
  30. 30. IPSec Services Access Control Connectionless integrity Data origin authentication Rejection of replayed packets Confidentiality (encryption) Limited traffic flow confidentiallity
  31. 31. IPSec protocols Authentication header (AH) Encapsulating security payload (ESP) ESP with Authentication
  32. 32. IPSec modes of operations TransportIPSec protects IP payloadIPSec headers added before IP payloadNo change in IP header TunnelIPSec protects total IP packetIPSec headers encapsulates IP packetNew IP header is created
  33. 33. DiscussiononTunnel and Transport mode Tunnel mode header orderNew IP hdr->IPsec hdr->old IP hdr->IP payloadBITS or BITW architectureChoice for VPN Transport mode header orderIP hdr->IPSec hdr->IP payloadIPSec integrated architectureEnd to End security
  34. 34. Protocols Transport ModeSATunnel ModeSAAH Authenticates IP payloadand selected portions ofIP header and IPv6extension headersAuthenticates entireinner IP packet plusselected portions ofouter IP headerESP Encrypts IP payload andany IPv6 extesion headerEncrypts inner IPpacketESP withauthenticationEncrypts IP payload andany IPv6 extesionheader. Authenticates IPpayload but no IP headerEncrypts inner IPpacket. Authenticatesinner IP packet.Security services
  35. 35. Before applying AH
  36. 36. Transport Mode (AHAuthentication)
  37. 37. Tunnel Mode (AHAuthentication)
  38. 38. ESP Encryption and Authentication
  39. 39. ESP Encryption andAuthentication
  40. 40. Combinations of SecurityAssociations
  41. 41. Combinations of SecurityAssociations
  42. 42. Combinations of SecurityAssociations
  43. 43. Combinations of SecurityAssociations
  44. 44. SSL and TLS SSL was originated by Netscape TLS working group was formed withinIETF First version of TLS can be viewed asan SSLv3.1
  45. 45. SSL Make use of TCP Provide reliable end to end secure communication Two layers of protocolsHigher layer○ Handshake○ change cipher spec○ AlertLower layer○ Record
  46. 46. SSL Architecture
  47. 47. SSL connection A logical client/server link A peer-to-peer connection with twonetwork nodes. Transient. Every connection associated with onesession.
  48. 48. SSL session An association between a client and a server Defines a set of parameters such as algorithms used,session number etc. An SSL session is created by the Handshake Protocol that allows parameters to be shared among theconnections made between the server and the client Sessions are used to avoid negotiation of new parametersfor each connection. A single session is shared among multiple SSL connectionsbetween the client and the server. In theory, it may also be possible that multiple sessions areshared by a single connection, but this feature is not used inpractice.
  49. 49. SSL session state A session state is defined by the following parameters: session identifier: this is an identifier generated by the server toidentify a session with a chosen client, Peer certificate: X.509 certificate of the peer, compression method: a method used to compress data prior toencryption, CipherSpec: specifies the bulk data encryption algorithm (forexample DES) and the hash algorithm (for example MD5) usedduring the session, Master secret: 48-byte data being a secret shared between theclient and server “is resumable”: this is a flag indicating whether the session canbe used to initiate new connections.
  50. 50. SSL connection state The SSL connection state is defined by the followingparameters: Server and client random: random data generated by both theclient and server for each connection, Server write MAC secret: the secret key used for data written bythe server, Client write MAC secret: the secret used for data written by theclient, Server write key: the bulk cipher key for data encrypted by theserver and decrypted by the client, Client write key: the bulk cipher key for data encrypted by theclient and decrypted by the server, Initialisation vectors: for CBC mode of block cipher Sequence number: sequence numbers maintained separately bythe server for messages transmitted and received during thedata session.
  51. 51. Record protocol Services providedConfidentiality○ Encryption of payloads using sharedsecret key obtained from handshakeprotocolMessage Integrity○ MAC using shared secret key obtainedfrom handshake protocol
  52. 52. SSL Record Protocol Operation
  53. 53. SSL Record Format
  54. 54. Change cipher spec protocol Payload of record protocol Consist of single messageSingle byte value = 1 Purpose of messageCause copy of pending state to current stateUpdates cipher suite to be used on thecurrent connection
  55. 55. Alert protocol Conveys SSL alerts to peer Payload of record Consists of two bytes1stbyte : warning or fatal2ndbyte: code for specific alerts
  56. 56. SSL Record Protocol Payload
  57. 57. Handshake Protocol The most complex part of SSL. Allows the server and client toauthenticate each other. Negotiate encryption, MAC algorithmand cryptographic keys. Used before any application data aretransmitted.
  58. 58. handshake protocol phases 1stphaseEstablish security capabilities 2ndphaseServer authentication and key exchange 3rdphaseClient authentication and key exchange 4thphasefinish
  59. 59. Handshake Protocol Action
  60. 60. Full handshake
  61. 61. Re-establish old session
  62. 62. Cryptographic computations Shared master secret : 48 byte Creation in 2 stages Pre-master secret exchanged○ RSA○ Diffie Hellman Master secret calculated at both ends Use of master secret at client end Client write MAC secret Client write key Client write IV Use of master secret at client end Server write MAC secret Server write key Client write IV
  63. 63. Transport Layer Security The same record format as the SSL record format. Defined in RFC 2246. Similar to SSLv3. Differences in the: version number (3.1) message authentication code (HMAC, TLScomressed.version) pseudorandom function ( different from SSL) alert codes ( more in TSL) cipher suites ( fortezza dropped) client certificate types ( fortezza schemes not included) certificate_verify and finished message ( calculation different) cryptographic computations ( different from SSL) Padding ( any amount for total length = Xblock length upto max 255 bytes )
  64. 64. Master secret in SSLMaster secret =MD5(pre_master_secret||SHA(“A”||pre_master_secret||ClientHello.random||serverHello.random))||MD5(pre_master_secret||SHA(“BB”||pre_master_secret||ClientHello.random||serverHello.random))||MD5(pre_master_secret||SHA(“CCC”||pre_master_secret||ClientHello.random||serverHello.random))||
  65. 65. Key block in SSLKey block =MD5(master_secret||SHA(“A”||master_secret||serverHello.random||ClientHello.random))||MD5(master_secret||SHA(“BB”||pre_master_secret|| serverHello.random||ClientHello.random))||MD5(master_secret||SHA(“CCC”||pre_master_secret|| serverHello.random||ClientHello.random))||…..
  66. 66. Master secret and Key block inTLSMaster secret =PRF(pre_master_secret, “master secret”,ClientHello.random||serverHello.random)Key block =PRF(master_secret, “key expansion”, SecurityParameters.server_random||SecurityParameters.client_random)PRF(secret,label,seed) = P_MD5(S1,label||seed)XOR P_SHA-1(S2,label||seed)
  67. 67. Secure Electronic Transactions An open encryption and securityspecification. Protect credit card transaction on theInternet. Companies involved:MasterCard, Visa, IBM, Microsoft,Netscape, RSA, Terisa and Verisign Not a payment system. Set of security protocols and formats.
  68. 68. SET Services Provides a secure communicationchannel in a transaction. Provides tust by the use of X.509v3digital certificates. Ensures privacy.
  69. 69. SET Overview Key Features of SET:Confidentiality of informationIntegrity of dataCardholder account authenticationMerchant authentication
  70. 70. SET Participants
  71. 71. SET participants Cardholder: authorised holder of credit card issuedby issuer. Interacts with merchants over internet Merchant : Seller of goods over internet Issuer : Bank which issues credit card to cardholder. Acquirer : Fin institution which has an account witha merchant, processes card authorisation andpayments. Payment gateway: Interfaces between SET andPayment network CA: Issues X.509 certificates to All players
  72. 72. Sequence of events fortransactions1. The customer opens an account.2. The customer receives a certificate.3. Merchants have their own certificates.4. The customer places an order.5. The merchant is verified.6. The order and payment are sent.7. The merchant request payment authorization.8. The merchant confirm the order.9. The merchant provides the goods or service.10. The merchant requests payments.
  73. 73. Dual SignatureH(OI))]||)(([ PIHHEDS cKR=
  74. 74. Payment processingCardholder sends Purchase Request
  75. 75. Payment processingMerchant Verifies Customer Purchase Request
  76. 76. Payment processing Payment Request:Initiate requestInitiate responsePurchase requestPurchase response Payment Authorization:Authorization RequestAuthorization Response Payment Capture:Capture RequestCapture Response
  77. 77. Payment Request Initiate request from card holder Request certificates to merchant Incl: Brand of cc, ID req/resp, nonce Initiate response by merchant Response signed by Kr of merchant Incl: Cust nonce, new nonce, trans ID, merchant’ssignature certificate, payment gateways key exchangecertificateCardholder verifies merchant and gateway’s certificates Generates○ OI- ref to order○ PI – card number, value etc
  78. 78. Payment Request Purchase request by card holderForwarded to payment gateway○ Incl: EKs[PI+Dual sig+OIMD], EKUch[Ks]To merchant○ OI+dual sig+PIMD, CH certificate Purchase response by merchantIncl: Trans ID, response block with order acksigned by merchant using Kr, merchant’ssignature certificateCard holderVerifies merchant’s signature on response block
  79. 79. Payment Authorization Authorization Request to payment gateway from merchant forwarded○ PI+dual sig+OIMD+EKUch[Ks] Generated○ Auth block: EKms[SignKrm[Trans ID]]○ EKUpg[EKms] Certificates○ Card holder signature key, merchant signature key and merchant key exchange certificatesPayment gateway Verifies all certificates, obtains EKms, decrypts auth block, verifies merchant’s sign, verifies dualsign, verifies trans ID, requests and receives an auth from issuer Authorisation response by payment gateway to merchant Auth block:○ EKpgs[SignKrpg[authorisation]]○ EKUm[EKpgs] Capture token info:○ EKpgs[SignKrpg[capture token]] Certificate○ Gateway’s signature key certifixcate
  80. 80. Payment capture Capture Request by merchant to paymentgatewayCapture req block○ Amount+Trand ID+token signed andencrypted by merchantThis is verified by payment gateway. Reqissuer to release payment Capture Response by payment gatewayto merchant confirmation of payment