1 / 44

Arab Academy for Science & Technology and Maritime Transport

Arab Academy for Science & Technology and Maritime Transport. e. Represented By : Ahmed Eldemallawy Ahmed Madani. Agenda. e -Mail. e -Commerce. Email Email Security Enhancements PGP ( Pretty Good Privacy ) S/MIME (Secure/Multipurpose Internet Mail Extensions). Email.

tave
Download Presentation

Arab Academy for Science & Technology and Maritime Transport

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Arab Academy for Science & Technology and Maritime Transport e Represented By : Ahmed Eldemallawy Ahmed Madani

  2. Agenda • e-Mail • e-Commerce • Email • Email Security Enhancements • PGP (Pretty Good Privacy) • S/MIME (Secure/Multipurpose Internet Mail Extensions)

  3. Email • email is one of the most widely used and regarded network services • currently message contents are not secure

  4. Email Security Enhancements • confidentiality • authentication • message integrity • non-repudiation of origin

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

  6. PGP Operation – Authentication Source A Destination B KUa EKRa[H(M)] KRa DP H || Z Z-1 M M EP Compare H

  7. PGP Operation – Confidentiality Source A Destination B KUb EKUb[Ks] KRb EP Ks DP M M Z EC || DC Z-1

  8. PGP Operation – Confidentiality & Authentication Source A Destination B EKRa[H(M)] EKUb[Ks] KUa KUb KRb DP EP Ks DP KRa M Compare DC Z-1 H || Z EC || M EP H

  9. PGP Operation – Compression • by default PGP compresses message after signing but before encrypting • uses ZIP compression algorithm

  10. PGP Operation – Email Compatibility • when using PGP will have binary data to send (encrypted message etc) • however email 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

  11. PGP Operation – Summary X  file Signature required? Yes Generate Signature X  signature || X No Compress X  Z(X) Confidentiality required? Yes Encrypt key,X X  EKUB[Ks]||EKs[X] No Convert to radix 64 X  R64[X] Generic Transmission Diagram (from A)

  12. PGP Operation – Summary Convert using radix 64 X  R64-1[X] Confidentiality required? Yes decrypt key,X X  DKRb[Ks]; XDKs[X] No Decompress X  Z-1(X) Signature required? Yes Strip signature from X Verify signature No Generic Reception Diagram (to B)

  13. 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

  14. 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

  15. 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

  16. KUb Output EP || Ks KRa EC H || M EP PGP Message Generation Passphrase H Public key Ring Private key Ring Select IDB Select Encrypted Private key IDA Key ID DC RNG Key ID

  17. PGP Message Reception Passphrase H Public key Ring Private key Ring Select Encrypted Private key Select DC Receiver’s Key ID Sender’s Key ID Encrypted Session key Encrypted digest KUa Encrypted Message + Signature KRb Message DP DP Compare DC H

  18. S/MIME (Secure/Multipurpose Internet Mail Extensions) • security enhancement to MIME email • original Internet RFC822 email 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 various modern mail agents: MS Outlook, Netscape etc

  19. 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

  20. S/MIME Cryptographic Algorithms • hash functions: SHA-1 & MD5 • digital signatures: DSS & RSA • session key encryption: ElGamal & RSA • message encryption: Triple-DES, RC2/40 and others • have a procedure to decide which algorithms to use

  21. 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

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

  23. Agenda • e-Mail • e-Commerce • Web security • SSL (Secure Socket Layer) • TLS (Transport Layer Security) • SET (Secure Electronic Transactions)

  24. Web Security • Web now widely used by business, government, individuals • but Internet & Web are not protected against attacks • have a variety of threats • integrity • confidentiality • denial of service • authentication • need added security mechanisms

  25. SSL (Secure Socket Layer) • transport layer security service • originally developed by Netscape • uses TCP to provide a reliable end-to-end service • SSL has two layers of protocols

  26. SSL Architecture SSL Change Cipher Spec Protocol SSL Change Cipher Spec Protocol SSL Alert Protocol HTTP SSL Record Protocol TCP IP

  27. SSL Architecture • 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 • SSL connection • a transient, peer-to-peer, communications link • associated with 1 SSL session

  28. SSL Record Protocol • confidentiality • using symmetric encryption with a shared secret key defined by Handshake Protocol • IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4-128 • message is compressed before encryption • message integrity • using a MAC with shared secret key

  29. SSL Change Cipher Spec Protocol • one of 3 SSL specific protocols which use the SSL Record protocol • single message 1 byte with value 1 • causes pending state to become current • updating the cipher suite in use

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

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

  32. SSL Handshake Protocol Client Server Phase 1 Establish security capabilities, including protocol version, session ID, cipher suite, compression method, and initial random numbers. Client_hello Server_hello Phase 2 Server may send certificate, key exchange, and request certificate. Server signals end of hello message phase. Certificate Server_key_exchange Certificate_request Server_hello_done

  33. SSL Handshake Protocol Certificate Phase 3 Client sends certificate if requested. Client sends key exchange. Client may send certificate verification. Client_key_exchange Certificate_verify Change_cipher_spec Finished Phase 4 Change cipher suite and finish handshake protocol. Change_cipher_spec Finished

  34. 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

  35. Secure Electronic Transactions (SET)

  36. 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

  37. SET Components

  38. SET Transaction • customer opens account • customer receives a certificate • merchants have their own certificates • customer places an order • merchant is verified • order and payment are sent • merchant requests payment authorization • merchant confirms order • merchant provides goods or service • merchant requests payment

  39. Dual Signature PI PIMD H KRc Dual Signature POMD || H E OI OIMD H

  40. Purchase Request Customer Passed on by Merchant to Payment gateway + PI Digital Envelop E + PIMD + Ks + Received By merchant Dual Signature OI + E OIMD + Dual Signature KUb + Cardholder Certificate

  41. + Digital Envelop + PIMD + OI + Dual Signature + Cardholder Certificate Purchase Request Merchant Passed on by Merchant to Payment gateway POMD || Compare H OIMD D POMD KUc

  42. + Digital Envelop Payment Gateway Authorization PI D H + Ks OIMD || D + Compare Dual Signature KRb D KUc

  43. 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

  44. ? Questions

More Related