Authentication applications Kerberos X.509 Authentication services E mail security IP security Web security

Transcription

1 UNIT 4 SECURITY PRACTICE Authentication applications Kerberos X.509 Authentication services E mail security IP security Web security Slides Courtesy of William Stallings, Cryptography & Network Security, Pearson Education, 4th Edition

2 Chapter 1 Authentication Applications Authentication applications Kerberos X.509 Authentication services

3 Authentication Applications will consider authentication functions developed to support application level authentication & digital signatures will consider Kerberos a private key authentication service then X.509 a public key directory authentication service

4 Kerberos trusted key server system from MIT provides centralised private key third party authentication in a distributed network allows users access to services distributed through network without needing to trust all workstations rather all trust a central authentication server two versions in use: 4 & 5

5 Kerberos Requirements its first report identified requirements as: secure reliable transparent scalable implemented using an authentication protocol based on Needham Schroeder

6 Kerberos v4 Overview a basic third party authentication scheme have an Authentication Server (AS) users initially negotiate with AS to identify self AS provides a non corruptible authentication credential (ticket granting ticket TGT) have a Ticket Granting server (TGS) users subsequently request access to other services from TGS on basis of users TGT

7 Kerberos v4 Dialogue 1. obtain ticket granting ticket from AS once per session 2. obtain service granting ticket from TGT for each distinct service required 3. client/server exchange to obtain service on every service request

8 Kerberos 4 Overview

9 Kerberos Realms a Kerberos environment consists of: a Kerberos server a number of clients, all registered with server application servers, sharing keys with server this is termed a realm typically a single administrative domain if have multiple realms, their Kerberos servers must share keys and trust

10 Kerberos Realms

11 Kerberos Version 5 developed in mid 1990 s specified as Internet standard RFC 1510 provides improvements over v4 addresses environmental shortcomings encryption alg, network protocol, byte order, ticket lifetime, authentication forwarding, interrealm auth and technical deficiencies double encryption, non std mode of use, session keys, password attacks

12 X.509 Authentication Service part of CCITT X.500 directory service standards distributed servers maintaining user info database defines framework for authentication services directory may store public key certificates with public key of user signed by certification authority also defines authentication protocols uses public key crypto & digital signatures algorithms not standardised, but RSA recommended X.509 certificates are widely used

13 X.509 Certificates issued by a Certification Authority (CA), containing: version (1, 2, or 3) serial number (unique within CA) identifying certificate signature algorithm identifier issuer X.500 name (CA) period of validity (from to dates) subject X.500 name (name of owner) subject public key info (algorithm, parameters, key) issuer unique identifier (v2+) subject unique identifier (v2+) extension fields (v3) signature (of hash of all fields in certificate) notation CA<<A>> denotes certificate for A signed by CA

14 X.509 Certificates

15 Summary have considered: Kerberos trusted key server system X.509 authentication and certificates

16 Chapter 2 E Mail Security PGP S/MIME

17 Security is one of the most widely used and regarded network services currently message contents are not secure may be inspected either in transit or by suitably privileged users on destination system

18 Security Enhancements confidentiality protection from disclosure authentication of sender of message message integrity protection from modification non repudiation of origin protection from denial by sender

19 Pretty Good Privacy (PGP) widely used de facto secure developed by Phil Zimmermann selected best available crypto algs to use integrated into a single program on Unix, PC, Macintosh and other systems originally free, now also have commercial versions available

20 PGP Operation Authentication 1. sender creates message 2. use SHA 1 to generate 160 bit hash of message 3. signed hash with RSA using sender's private key, and is attached to message 4. receiver uses RSA with sender's public key to decrypt and recover hash code 5. receiver verifies received message using hash of it and compares with decrypted hash code

21 PGP Operation Confidentiality 1. sender generates message and 128 bit random number as session key for it 2. encrypt message using CAST 128 / IDEA / 3DES in CBC mode with session key 3. session key encrypted using RSA with recipient's public key, & attached to msg 4. receiver uses RSA with private key to decrypt and recover session key 5. session key is used to decrypt message

22 PGP Operation Confidentiality & Authentication can use both services on same message create signature & attach to message encrypt both message & signature attach RSA/ElGamal encrypted session key

23 PGP Operation Compression by default PGP compresses message after signing but before encrypting so can store uncompressed message & signature for later verification & because compression is non deterministic uses ZIP compression algorithm

24 PGP Operation Compatibility when using PGP will have binary data to send (encrypted message etc) however was designed only for text hence PGP must encode raw binary data into printable ASCII characters uses radix 64 algorithm maps 3 bytes to 4 printable chars also appends a CRC PGP also segments messages if too big

25 PGP Operation Summary

26 PGP Session Keys need a session key for each message of varying sizes: 56 bit DES, 128 bit CAST or IDEA, 168 bit Triple DES generated using ANSI X12.17 mode uses random inputs taken from previous uses and from keystroke timing of user

27 PGP Public & Private Keys since many public/private keys may be in use, need to identify which is actually used to encrypt session key in a message could send full public key with every message but this is inefficient rather use a key identifier based on key is least significant 64 bits of the key will very likely be unique also use key ID in signatures

28 PGP Message Format

29 PGP Key Rings each PGP user has a pair of keyrings: public key ring contains all the public keys of other PGP users known to this user, indexed by key ID private key ring contains the public/private key pair(s) for this user, indexed by key ID & encrypted keyed from a hashed passphrase security of private keys thus depends on the pass phrase security

30 PGP Message Generation

31 PGP Message Reception

32 PGP Key Management rather than relying on certificate authorities in PGP every user is own CA can sign keys for users they know directly forms a web of trust trust keys have signed can trust keys others have signed if have a chain of signatures to them key ring includes trust indicators users can also revoke their keys

33 S/MIME (Secure/Multipurpose Internet Mail Extensions) security enhancement to MIME original Internet RFC822 was text only MIME provided support for varying content types and multi part messages with encoding of binary data to textual form S/MIME added security enhancements have S/MIME support in many mail agents eg MS Outlook, Mozilla, Mac Mail etc

34 S/MIME Functions enveloped data encrypted content and associated keys signed data encoded message + signed digest clear signed data cleartext message + encoded signed digest signed & enveloped data nesting of signed & encrypted entities

35 S/MIME Cryptographic Algorithms digital signatures: DSS & RSA hash functions: SHA 1 & MD5 session key encryption: ElGamal & RSA message encryption: AES, Triple DES, RC2/40 and others MAC: HMAC with SHA 1 have process to decide which algs to use

36 S/MIME Messages S/MIME secures a MIME entity with a signature, encryption, or both forming a MIME wrapped PKCS object have a range of content types: enveloped data signed data clear signed data registration request certificate only message

37 S/MIME Certificate Processing S/MIME uses X.509 v3 certificates managed using a hybrid of a strict X.509 CA hierarchy & PGP s web of trust each client has a list of trusted CA s certs and own public/private key pairs & certs certificates must be signed by trusted CA s

38 Certificate Authorities have several well known CA s Verisign one of most widely used Verisign issues several types of Digital IDs increasing levels of checks & hence trust Class Identity Checks Usage 1 name/ check web browsing/ 2 + enroll/addr check , subs, s/w validate 3 + ID documents e banking/service access

39 Summary have considered: secure PGP S/MIME

40 Chapter 3 IP Security IP Security

41 IP Security have a range of application specific security mechanisms eg. S/MIME, PGP, Kerberos, SSL/HTTPS however there are security concerns that cut across protocol layers would like security implemented by the network for all applications

42 IPSec general IP Security mechanisms provides authentication confidentiality key management applicable to use over LANs, across public & private WANs, & for the Internet

43 IPSec Uses

44 Benefits of IPSec in a firewall/router provides strong security to all traffic crossing the perimeter in a firewall/router is resistant to bypass is below transport layer, hence transparent to applications can be transparent to end users can provide security for individual users secures routing architecture

45 IP Security Architecture specification is quite complex defined in numerous RFC s incl. RFC 2401/2402/2406/2408 many others, grouped by category mandatory in IPv6, optional in IPv4 have two security header extensions: Authentication Header (AH) Encapsulating Security Payload (ESP)

46 IPSec Services Access control Connectionless integrity Data origin authentication Rejection of replayed packets a form of partial sequence integrity Confidentiality (encryption) Limited traffic flow confidentiality

47 Security Associations a one way relationship between sender & receiver that affords security for traffic flow defined by 3 parameters: Security Parameters Index (SPI) IP Destination Address Security Protocol Identifier has a number of other parameters seq no, AH & EH info, lifetime etc have a database of Security Associations

48 Authentication Header (AH) provides support for data integrity & authentication of IP packets end system/router can authenticate user/app prevents address spoofing attacks by tracking sequence numbers based on use of a MAC HMAC MD5 96 or HMAC SHA 1 96 parties must share a secret key

49 Authentication Header

50 Transport & Tunnel Modes

51 Encapsulating Security Payload (ESP) provides message content confidentiality & limited traffic flow confidentiality can optionally provide the same authentication services as AH supports range of ciphers, modes, padding incl. DES, Triple DES, RC5, IDEA, CAST etc CBC & other modes padding needed to fill blocksize, fields, for traffic flow

52 Encapsulating Security Payload

53 Transport vs Tunnel Mode ESP transport mode is used to encrypt & optionally authenticate IP data data protected but header left in clear can do traffic analysis but is efficient good for ESP host to host traffic tunnel mode encrypts entire IP packet add new header for next hop good for VPNs, gateway to gateway security

54 Combining Security Associations SA s can implement either AH or ESP to implement both need to combine SA s form a security association bundle may terminate at different or same endpoints combined by transport adjacency iterated tunneling issue of authentication & encryption order

55 Combining Security Associations

56 Summary have considered: IPSec security framework AH ESP

57 Chapter 4 Web Security SSL TLS SET

58 Web Security Web now widely used by business, government, individuals but Internet & Web are vulnerable have a variety of threats integrity confidentiality denial of service authentication need added security mechanisms

59 SSL (Secure Socket Layer) transport layer security service originally developed by Netscape version 3 designed with public input subsequently became Internet standard known as TLS (Transport Layer Security) uses TCP to provide a reliable end to end service SSL has two layers of protocols

60 SSL Architecture

61 SSL Architecture SSL connection a transient, peer to peer, communications link associated with 1 SSL session SSL session an association between client & server created by the Handshake Protocol define a set of cryptographic parameters may be shared by multiple SSL connections

62 SSL Record Protocol Services message integrity using a MAC with shared secret key similar to HMAC but with different padding confidentiality using symmetric encryption with a shared secret key defined by Handshake Protocol AES, IDEA, RC2 40, DES 40, DES, 3DES, Fortezza, RC4 40, RC4 128 message is compressed before encryption

63 SSL Record Protocol Operation

64 SSL Change Cipher Spec Protocol one of 3 SSL specific protocols which use the SSL Record protocol a single message causes pending state to become current hence updating the cipher suite in use

65 SSL Alert Protocol conveys SSL related alerts to peer entity severity warning or fatal specific alert fatal: unexpected message, bad record mac, decompression failure, handshake failure, illegal parameter warning: close notify, no certificate, bad certificate, unsupported certificate, certificate revoked, certificate expired, certificate unknown compressed & encrypted like all SSL data

66 SSL Handshake Protocol allows server & client to: authenticate each other to negotiate encryption & MAC algorithms to negotiate cryptographic keys to be used comprises a series of messages in phases 1. Establish Security Capabilities 2. Server Authentication and Key Exchange 3. Client Authentication and Key Exchange 4. Finish

67 SSL Handshake Protocol

68 TLS (Transport Layer Security) IETF standard RFC 2246 similar to SSLv3 with minor differences in record format version number uses HMAC for MAC a pseudo random function expands secrets has additional alert codes some changes in supported ciphers changes in certificate types & negotiations changes in crypto computations & padding

69 Secure Electronic Transactions (SET) open encryption & security specification to protect Internet credit card transactions developed in 1996 by Mastercard, Visa etc not a payment system rather a set of security protocols & formats secure communications amongst parties trust from use of X.509v3 certificates privacy by restricted info to those who need it

70 SET Components

71 SET Transaction 1. customer opens account 2. customer receives a certificate 3. merchants have their own certificates 4. customer places an order 5. merchant is verified 6. order and payment are sent 7. merchant requests payment authorization 8. merchant confirms order 9. merchant provides goods or service 10. merchant requests payment

72 Dual Signature customer creates dual messages order information (OI) for merchant payment information (PI) for bank neither party needs details of other but must know they are linked use a dual signature for this signed concatenated hashes of OI & PI DS=E(PR c, [H(H(PI) H(OI))])

73 SET Purchase Request SET purchase request exchange consists of four messages 1. Initiate Request - get certificates 2. Initiate Response - signed response 3. Purchase Request - of OI & PI 4. Purchase Response - ack order

74 Purchase Request Customer

75 Purchase Request Merchant 1. verifies cardholder certificates using CA sigs 2. verifies dual signature using customer's public signature key to ensure order has not been tampered with in transit & that it was signed using cardholder's private signature key 3. processes order and forwards the payment information to the payment gateway for authorization (described later) 4. sends a purchase response to cardholder

76 Purchase Request Merchant

77 Payment Gateway Authorization 1. verifies all certificates 2. decrypts digital envelope of authorization block to obtain symmetric key & then decrypts authorization block 3. verifies merchant's signature on authorization block 4. decrypts digital envelope of payment block to obtain symmetric key & then decrypts payment block 5. verifies dual signature on payment block 6. verifies that transaction ID received from merchant matches that in PI received (indirectly) from customer 7. requests & receives an authorization from issuer 8. sends authorization response back to merchant

78 Payment Capture merchant sends payment gateway a payment capture request gateway checks request then causes funds to be transferred to merchants account notifies merchant using capture response

79 Summary have considered: need for web security SSL/TLS transport layer security protocols SET secure credit card payment protocols