ΑΣΦΑΛΕΙΣ ΗΛΕΚΤΡΟΝΙΚΕΣ ΣΥΝΑΛΛΑΓΕΣ

ΑΣΦΑΛΕΙΣ ΗΛΕΚΤΡΟΝΙΚΕΣ ΣΥΝΑΛΛΑΓΕΣ

ΑΣΦΑΛΕΙΣ ΗΛ. ΣΥΝΑΛΛΑΓΕΣ Στο ιαδίκτυο είναι διαθέσιµο ένα πλήθος πρωτοκόλλων που χρησιµοποιούν κρυπτογραφία Το κάθε ένα από αυτά χρησιµοποιείται για διαφορετικό σκοπό. Κάποια από αυτά έχουν σχεδιαστεί για την προστασία συγκεκριµένων υπηρεσιών, όπως είναι το ηλεκτρονικό ταχυδροµείο (e-mail) ή η αποµακρυσµένη πρόσβαση (remote login).

ΑΣΦΑΛΕΙΣ ΗΛ. ΣΥΝΑΛΛΑΓΕΣ Πρωτόκολλο CyperCash DNSSEC IPSec PCT PGP S/MIME S-HTTP Secure RPC SET SSL SSH TLS Σκοπός Ηλεκτρονικές τραπεζικές συναλλαγές Domain Name System (DNS) Κρυπτογράφηση σε επίπεδο «πακέτου» Κρυπτογράφηση σε επίπεδο TCP/IP Ηλεκτρονικό Ταχυδροµείο Ηλεκτρονικό Ταχυδροµείο Πλοήγηση στον Παγκόσµιο Ιστό Αποµακρυσµένες διαδικασίες κλήσεις Ηλεκτρονικές τραπεζικές συναλλαγές Κρυπτογράφηση σε επίπεδο TCP/IP Αποµακρυσµένη πρόσβαση Κρυπτογράφηση σε επίπεδο TCP/IP

ΑΣΦΑΛΕΙΣ ΗΛ. ΣΥΝΑΛΛΑΓΕΣ Στον Παγκόσµιο Ιστό τα συνήθως χρησιµοποιούµενα πρωτόκολλα είναι το SSL και το SET Secure Sockets Layer (SSL): Κρυπτογράφηση του traffic µεταξύ web server και client. Πολύ κοινή η χρήση του για κρυπτογράφηση HTTP traffic (https- >443). Secure Electronic Transactions (SET): Εξειδικευµένο πρωτόκολλο για προστασία συναλλαγών µέσω πιστωτικών καρτών.

SECURE SOCKETS LAYER (SSL) (1/5) Το SSL εµφανίσθηκε στην αγορά το 1994 µε τηνπρώτη έκδοση του Netscape Navigator browser. Tον ίδιο χρόνο, ένα ανταγωνιστικό κρυπτογραφικό πρωτόκολλο, το S-HTTP, εµφανίσθηκε στην αγορά από µια συµµαχία εµπορικών οµάδων που ονοµαζόταν CommerceNet.

SECURE SOCKETS LAYER (SSL) (2/5) Αν και οι αρχές κρυπτογραφίας που χρησιµοποιούνταν από το S-HTTP και SSL ήταν οι ίδιες υπήρχαν δύο σηµαντικές διαφορές µεταξύ των S-HTTP και SSL. Το S-HTTP σχεδιάστηκε για να δουλεύει µόνο µε πρωτόκολλα WEB. To SSL είναι χαµηλότερου επιπέδου πρωτόκολλο που µπορεί να χρησιµοποιηθεί για κρυπτογραφήσει πολλών τύπων συνδέσεις δικτύου. Το SSL ενσωµατώθηκε σε έναν δωρεάν browser που έγινε παντού διάσηµο. To S-HTTP ήταν αρχικά διαθέσιµο σεµια ελαφρώς διαφορετική εκδοχή του NCSA Mosaic που οι χρήστες έπρεπε να αποκτήσουν.

SECURE SOCKETS LAYER (SSL) (3/5) Ενσωµατωµένο σε Netscape και Internet Explorer. Παρέχει: Κρυπτογράφηση δεδοµένων, Πιστοποίηση εξυπηρέτη µέσω πιστοποιητικού. Ακεραιότητα µηνυµάτων Προαιρετική πιστοποίηση του πελάτη µέσω πιστοποιτικού. ύο εκδόσεις SSL: Κλειδιά 40 και 128 bits. Λειτουργεί πάνω από οποιοδήποτε πρωτόκολλο µεταφοράς (π.χ TCP).

SECURE SOCKETS LAYER (SSL) (4/5) Το SSL λειτουργεί στο επίπεδο TCP κάτω από συγκεκριµένα πρωτόκολλα εφαρµογών όπως HTTP και SMTP(e-mail). Το χαρακτηριστικό αυτό του SSL του προσδίδει ευχρηστία και ανεξαρτησία. Οποιοδήποτε πρόγραµµαχρησιµοποιεί το TCP µπορεί να τροποποιηθεί ώστε να χρησιµοποιεί ασφαλείς SSL συνδέσεις κάνοντας απλώς µερικές αλλαγές στον πηγαίο κώδικα.

SECURE SOCKETS LAYER (SSL) (5/5) Όταν υπάρχει µια SSL σύνδεση, όλες οι browser-προςserver επικοινωνίες και το αντίθετο κρυπτογραφούνται, συµπεριλαµβανοµένου και του URL του ζητούµενου εγγράφου, των περιεχοµένων του ζητούµενου εγγράφου, των περιεχοµένων όλων των φορµών που υποβάλλονται, των cookies που αποστέλλονται από τον browser στο server, των cookies που αποστέλλονται από τον server στο browser, των περιεχοµένων του HTTP header. Το µόνο πράγµαπουδενµπορεί να συγκαλυφθεί από ένα SSL είναι το ότι ένας συγκεκριµένος browser «µιλάει» σε έναν συγκεκριµένο server.

ΑΛΓΟΡΙΘΜΟΙ ΚΡΥΠΤΟΓΡΑΦΗΣΗΣ ΤΟΥ SSL Αλγόριθµοι οµάδας (block ciphers). (40-168 bits κλειδιά) Αλγόριθµοι στοιχειοσειράς (stream ciphers). (40 και 128 bits κλειδιά) Αλγόριθµοι παραγωγής hash. MD-5 (128-bits κλειδί). SHA (160-bit κλειδί).

ΑΛΓΟΡΙΘΜΟΙ ΚΡΥΠΤΟΓΡΑΦΗΣΗΣ ΤΟΥ SSL Αλγόριθµος IDEA RC2-40 DES-40 Block Ciphers Μέγεθος κλειδιού 128 40 40 Stream Ciphers Αλγόριθµος Μέγεθος κλειδιού RC4-40 40 RC4-128 128 DES 56 3DES 168 Fortezza 80

ΑΛΓΟΡΙΘΜΟΙ ΚΡΥΠΤΟΓΡΑΦΗΣΗΣ ΤΟΥ SSL ιαχείριση των κλειδιών γίνεται µεασύµµετρη κρυπτογραφία (RSA) και µε το πρωτόκολλο ανταλλαγής κλειδιών Diffie-Hellman. Ο RSA µπορεί να χρησιµοποιηθεί για την ψηφιακή υπογραφή των κλειδιών κρυπτογράφησης

ΤΜΗΜΑΤΑ SSL SSL Handshake Protocol (SSLHP): ιαπραγµατεύεται τους αλγορίθµους κρυπτογράφησης που θα χρησιµοποιηθούν και πραγµατοποιεί την πιστοποίηση αυθεντικότητας του εξυπηρέτη και του πελάτη (αν ζητηθεί) SSL Record Protocol (SSLRP): Τοποθετεί τα δεδοµένα σε πακέτα, τα κρυπτογραφεί και τα δίνει στο επίπεδο µεταφοράς. Επίσης, εκτελεί την αντίστροφη διαδικασία, για τα παραλαµβανόµενα πακέτα.

SSL Record Protocol Ένα πακέτο SSLRP αποτελείται από δύο µέρη: την επικεφαλίδα (header) τα δεδοµένα (data). Ηεπικεφαλίδαµπορεί να έχει µήκος 2 ή 3 bytes. Είναι απαραίτητο να είναι 3 bytes όταν τα δεδοµένα χρειάζονται συµπλήρωµα (padding). Για την επικεφαλίδα των 2 bytes το µέγεθος του πακέτου είναι 32767 bytes, ενώ για την επικεφαλίδα των 3 bytes το µέγεθος είναι 16383 bytes.

SSL Record Protocol Τµήµαδεδοµένων αποτελείται από Ένα Message Authentication Code - MAC, τα πραγµατικά δεδοµένα και δεδοµένα συµπλήρωσης (εάν αυτά χρειάζονται). Το τµήµα αυτό είναι που κρυπτογραφείται κατά την µετάδοση. Συµπληρωµατικά δεδοµένα: απαιτούνται όταν οι αλγόριθµοι κρυπτογράφησης είναι τύπου οµάδας και ο ρόλος τους είναι να συµπληρώνουν τα πραγµατικά δεδοµένα, ώστε το µέγεθος τους να είναι πολλαπλάσιο του µεγέθους που δέχεται σαν είσοδο το κρυπτογράφηµα οµάδας. Εάν χρησιµοποιούνται αλγόριθµοι στοιχειοσειράς τότε δεν απαιτείται συµπλήρωµα και µπορεί να χρησιµοποιηθεί η επικεφαλίδα των 2 bytes.

SSL Record Protocol Το MAC είναι η τιµήκατακερµατισµού στη συγχώνευση του ιδιωτικού κλειδιού του αποστολέα του πακέτου, των πραγµατικών δεδοµένων, των συµπληρωµατικών δεδοµένων και ενός αριθµού ακολουθίας. Προβλέπεται και η συµπίεση των δεδοµένων (data compression) µε κατάλληλους µηχανισµούς που επιλέγονται κατά τη «χειραψία», δεν αποκλείεται να χρειαστεί και τεµαχισµός της πληροφορίας σε πολλά πακέτα (fragmentation).

SSL Handshake Protocol Το πρωτόκολλο SSL Handshake διαχωρίζεται σε δύο επιµέρους φάσεις: Η πρώτη φάση αφορά την επιλογή των αλγόριθµων, την ανταλλαγή ενός κύριου κλειδιού και την πιστοποίηση της ταυτότητας του εξυπηρέτη. Η δεύτερη φάση υλοποιεί την πιστοποίηση της ταυτότητας του πελάτη (εάν ζητηθεί) και ολοκληρώνει την διαδικασία της «χειραψίας» (handshaking). Όταν ολοκληρωθούν και οι δύο φάσεις, το στάδιο της «χειραψίας» ολοκληρώνεται και αρχίζει η µεταφορά των δεδοµένων σύµφωνα µετοssl Record Protocol

Η SSL ΣΥΝΑΛΛΑΓΗ (1/6) Ο σκοπός του πρωτοκόλλου είναι να πιστοποιήσει τον server και προαιρετικά τον πελάτη, και να καταλήξει µε ένα µυστικό συµµετρικό κλειδί που και ο πελάτης και ο server µπορούν να χρησιµοποιήσουν για να αποστέλλουν κρυπτογραφηµένα µηνύµατα. 1. Ο πελάτης πραγµατοποιεί µια σύνδεση µε τηνθύρατου server και στέλνει ένα ClientHello µήνυµα. Το µήνυµα περιλαµβάνει σε λίστα τις ικανότητες του πελάτη, καθώς και την έκδοση SSL που χρησιµοποιεί, τις κρυπτογραφικές µεθόδους που υποστηρίζει, και τις µεθόδους συµπίεσης δεδοµένων που υποστηρίζει.

Η SSL ΣΥΝΑΛΛΑΓΗ (2/6) 2. Ο server ανταποκρίνεται µεένα ServerHello µήνυµα. Επιστρέφει ένα µήνυµα που περιέχει ένα αναγνωριστικό της σύνδεσης (connection id) την µέθοδο κρυπτογράφησης και την µέθοδο συµπίεσης δεδοµένων που επέλεξε, καθώς και το πιστοποιητικό του server (το οποίο χρησιµοποιεί ο client για να µάθει το δηµόσιο κλειδί του server). Αν δεν ταιριάζουν οι µέθοδοι κρυπτογράφησης που υποστηρίζονται από τον πελάτη και τον server, τότε ο server στέλνει ένα «αποχαιρετιστήριο» µήνυµα και «κρεµάει».

Η SSL ΣΥΝΑΛΛΑΓΗ (3/6) 3. Ο server στέλνει µια αίτηση πιστοποίησης στον πελάτη (προαιρετικό). 4. Ο πελάτης στέλνει το πιστοποιητικό του (προαιρετικό). Αν το πελάτης δεν έχει πιστοποιητικό τότε ειδοποιεί τον server. Ο server µπορεί να επιλέξει να διακόψει την συναλλαγή ή να συνεχίσει.

Η SSL ΣΥΝΑΛΛΑΓΗ (4/6) 5. Ο server στέλνει ένα «ClientKeyExchange µήνυµα. Αυτό είναι το σηµείο που επιλέγεται το συµµετρικό κλειδί. Οι λεπτοµέρειες ποικίλουν ανάλογα µε την επιλεγόµενη ακολουθία κρυπτογράφησης, αλλά τις περισσότερες φορές, ο πελάτης παράγει ένα µυστικό αρχικό κλειδί µε τυχαίοτρόπο. Ο browser κρυπτογραφεί το µυστικό κλειδί µε τοδηµόσιο κλειδί του server για δηµιουργήσει ένα ψηφιακό µήνυµα τοοποίο προωθείται τώρα στον server.

Η SSL ΣΥΝΑΛΛΑΓΗ (5/6) 6. Ο πελάτης στέλνει ένα «CertificateVerify» µήνυµα (προαιρετικό). Αν χρησιµοποιείται η πιστοποίηση του πελάτη, τότε ο πελάτης πρέπει να πιστοποιήσει τον εαυτό του στον server µε τοναδείξει πως ξέρει το σωστό ιδιωτικό κλειδί. Το CertificateVerify µήνυµα αποτελείται από το αρχικό µυστικό κλειδί που παράχθηκε στο βήµα 5. Το µυστικό κλειδί υπογράφεται µε το ιδιωτικό κλειδί του πελάτη και προωθείται στον server οοποίοςτοελέγχει ωςπροςτην εγκυρότητα.

Η SSL ΣΥΝΑΛΛΑΓΗ (6/6) 7. Και ο πελάτης και ο server στέλνουν ένα «ChangeCipherSpec» µήνυµα. Αυτό είναι ένα απλό µήνυµα που επιβεβαιώνει ότι και ο πελάτης και ο server είναι έτοιµοι να ξεκινήσουν να επικοινωνούν χρησιµοποιώντας το συµφωνηµένο συµµετρικό κλειδί. 8. Και ο πελάτης και ο server στέλνουν «Finished» µήνυµα. Αυτό επιτρέπει και στις δύο πλευρές να επιβεβαιώσουν ότι τα µηνύµατά τους ελήφθησαν απείραχτα. Σε αυτό το σηµείο, οπελάτηςκαιοserver περνούν σε encrypted mode χρησιµοποιώντας το κλειδί ακολουθίας για να κρυπτογραφήσουν συµµετρικά µεταδώσεις και από τις δύο πλευρές.

ΑΝΤΟΧΗ SSL ΣΕ ΓΝΩΣΤΕΣ ΕΠΙΘΕΣΕΙΣ (1/3) Επίθεση λεξικού: Αν µη κρυπτογραφηµένο τµήµα µηνύµατος βρεθεί σε κακόβουλο χρήστη, κωδικοποίηση του ώστε να προκύψει τµήµα του κωδικοποιηµένου µηνύµατος. Σε περίπτωση που η έρευνα είναι «επιτυχής», τότε το κλειδί που χρησιµοποιήθηκε για την κρυπτογράφηση ολόκληρου του µηνύµατος έχει βρεθεί. Αντοχή SSL λόγω ανάγκης υπολογισµού 2^128 διαφορετικών ακολουθιών. Ακόµα και οι αλγόριθµοι σε προϊόντα για χρήση εκτός Η.Π.Α, υποστηρίζουν κλειδιά των 128 bits και παρ' όλο που τα 88 bits αυτών µεταδίδονται χωρίς κρυπτογράφηση, ο υπολογισµός 2^40 διαφορετικών ακολουθιών καθιστά την επίθεση εξαιρετικά δύσκολη.

ΑΝΤΟΧΗ SSL ΣΕ ΓΝΩΣΤΕΣ ΕΠΙΘΕΣΕΙΣ (2/3) Βίαιη επίθεση (brute-force): Χρήση όλων των πιθανών κλειδιών για αποκρυπτογράφηση. Τέτοια επίθεση σε αλγορίθµους που χρησιµοποιούν κλειδιά των 128 bits είναι ατελέσφορη. Μόνο ο DES των 56 bits είναι ευαίσθητος σε αυτήν την επίθεση

ΑΝΤΟΧΗ SSL ΣΕ ΓΝΩΣΤΕΣ ΕΠΙΘΕΣΕΙΣ (3/3) Επίθεση επανάληψης: Όταν ένας «τρίτος» καταγράφει την ανταλλαγή µηνυµάτων µεταξύ πελάτη - εξυπηρέτη και προσπαθεί να χρησιµοποιήσει ξανά τα µηνύµατα του πελάτη για να αποκτήσει πρόσβαση στον εξυπηρέτη. Όµως το SSL κάνει χρήση του αναγνωριστικού σύνδεσης (connection-id), το οποίο παράγεται από τον εξυπηρέτη µε τυχαίο τρόπο και διαφέρει για κάθε σύνδεση. Το αναγνωριστικό σύνδεσης έχει µέγεθος 128 bits=> πρόσθετη ασφάλεια.

Α ΥΝΑΜΙΕΣ SSL Βίαιη επίθεση και µέγεθος κλειδιού Η µεγαλύτερη αδυναµία του πρωτοκόλλου SSL είναι η ευαισθησία των αλγόριθµων που χρησιµοποιούν µικρά κλειδιά. Συγκεκριµένα, οι RC4-40, RC2-40 και DES-56 εισάγουν σοβαρά προβλήµατα ασφάλειας και θα πρέπει να αποφεύγονται.

Α ΥΝΑΜΙΕΣ SSL Επαναδιαπραγµάτευση κλειδιών συνόδου (µόνο στην 2 έκδοση) Από την στιγµήπουµία σύνδεση δηµιουργηθεί, το ίδιο κλειδί (master key) χρησιµοποιείται καθ' όλητηδιάρκεια της. Όταν το SSL χρησιµοποιείται πάνω από µια µακρόχρονη σύνδεση (π.χ. µιας εφαρµογής TELNET), η αδυναµία αλλαγής του κλειδιού γίνεται επικίνδυνη. Ηκαλύτερηµέθοδος επίλυσης αυτού του προβλήµατος είναι η επαναδιαπραγµάτευση του κλειδιού σε τακτά χρονικά διαστήµατα, µειώνοντας έτσι την πιθανότητα µιας επιτυχoύς Βίαιης Επίθεσης (Brute Force Attack).

Χρήσεις του SSL Η πιο κοινή εφαρµογή του SSL είναι για την κρυπτογράφηση επικοινωνιών HTTP µεταξύ του προγράµµατος πλοήγησης (browser) και του εξυπηρέτη web (web server). Η ασφαλής έκδοση του HTTP χρησιµοποιεί URLs που ξεκινούν µε "https" αντί του κανονικού "http" και διαφορετική θύρα (port) που είναι η προκαθορισµένη θύρα 443. Ο browser αποθηκεύει τα ιδιωτικά κλειδιά του χρήστη και µε κατάλληλο τρόπο υποδεικνύει την διενέργεια ασφαλών συνδέσεων.

Secure Electronic Transactions (SET)

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

ΓΙΑΤΙ SET ΚΑΙ ΟΧΙ SSL; (1/3) Χρήση SSL συνηθίζεται να πραγµατοποιείται κυρίως µέσω του ιαδικτύου. Το SSL µειονεκτεί για αυτό το σκοπό. Παρόλο που το SSL λύνει το πρόβληµα τηςασφαλούςµετάδοσης του κωδικού από τον πελάτη στον έµπορο, δε βοηθάει στην υπόλοιπη διαδικασία µιας και είναι απαραίτητος ο έλεγχος του κωδικού για εγκυρότητα, ο έλεγχος για το εάν ο πελάτης δικαιούται να χρησιµοποιήσει αυτό το νούµερο, κ.α. Σε ένα απλό σύστηµα, ένα CGI µπορεί να ελέγξει τον κωδικό της πιστωτικής κάρτας για τυπογραφικά λάθη και να καταγράψει τον αριθµό σε ένα φάκελο ή σε µια βάση δεδοµένων για χειρονακτική επιβεβαίωση αργότερα. Ωστόσο για πολλές εφαρµογές η online κατοχύρωση της πιστωτικής κάρτας είναι απαραίτητη.

ΓΙΑΤΙ SET ΚΑΙ ΟΧΙ SSL; (2/3) Ένα άλλο πρόβληµα µετηχρήσητουπρωτοκόλλουssl αφορά στην ασφάλεια από τη µεριά του εξυπηρέτη. Επειδή ο κωδικός µεταφέρεται µέσω στον server του εµπόρου, είναιεύλογοοέµπορος να µπορεί να επιλέξει αν θα το αποθηκεύσει σε φάκελο ή σε βάση δεδοµένων. Εάν κάποιος πετύχει να εισβάλλει στον server του εµπόρου, µπορεί να καταχραστεί η λίστα µετουςκωδικούςτωνπιστωτικών καρτών. Ένα άλλο πρόβληµα µετηχρήσητουssl είναι συστήµατα που µαντεύουν κωδικούς. Σε περίπτωση επιτυχηµένης προσπάθειας, µπορεί να γίνει η αγορά και να φανερωθεί ένας πραγµατικός αριθµός πιστωτικής κάρτας.

ΓΙΑΤΙ SET ΚΑΙ ΟΧΙ SSL; (3/3) Το πρωτόκολλο SET αποφεύγειαυτάταπροβλήµατα, παρέχοντας ένα σύστηµα το οποίο χειρίζεται ολόκληρη την µετάδοση, συµπεριλαµβανοµένου της κατοχής της κάρτας και της πραγµατοποίησης της πώλησης. Προκειµένου να αποφευχθεί η κλοπή, το πρωτόκολλο δεν επιτρέπει ποτέ την άµεσηπρόσβασητουεµπόρου στον αριθµό πιστωτικής του πελάτη. Αντί αυτού, απλά ειδοποιείται για το εάν η αγορά έγινε αποδεκτή.

ΛΕΙΤΟΥΡΓΙΑ SET Στο πρωτόκολλο SET εµπλέκονται τέσσερις φορείς: Oκάτοχος της κάρτας, οέµπορος, Πύλη Πληρωµών, Υπηρεσία Πιστοποιητικών. Όπως συµβαίνει και µε άλλα πρωτόκολλα, το SET χρησιµοποιεί δηµόσια / ιδιωτικά ζεύγη κλειδιών και υπογεγραµµένες πιστοποιήσεις, προκειµένου να εκδώσει την ταυτότητα του εκάστοτε πληρωτή και να επιτρέψει να στέλνουν µηνύµατα ο ένας στον άλλον. Κατά τη διάρκεια µιαςσυναλλαγήςαγοραπωλησίας, το πρωτόκολλο δουλεύει ως εξής:

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

Dual Signature customer creates dual messages order information (OI) for merchant payment information (PI) for bank The merchant does not need to know the customer s credit card number, and the bank does not need to know the details of the customer s order however the two items must be linked in a way that can be used to resolve disputes if necessary.

Dual Signature SET uses a dual signature for this The customer takes the hash (using SHA-1) of the PI and the hash of the OI, concatenates them, and hashes the result. Finally,the customer encrypts the final hash with his or her private signature key, creating the dual signature. This can be summarized as: DS=E(PRc, [H(H(PI) H(OI))])

SET Purchase Request SET purchase request exchange consists of four messages 1. Initiate Request - get certificates In order to send SET messages to the merchant, the cardholder must have a copy of the certificates of the merchant and the payment gateway. The customer requests the certificates in the Initiate Request message, sent to the merchant. 2. Initiate Response - signed response The merchant generates a response and signs it with its private signature key. 3. Purchase Request - of OI & PI The cardholder verifies the merchant and gateway certificates by means of their respective CA signatures and then creates the OI and PI. Next, the cardholder prepares the Purchase Request message with Purchaserelated information & Order-related information. 4. Purchase Response - ack order acknowledges the order and references the corresponding transaction number

Purchase Request Customer Cardholder certificate. This contains the cardholder s public signature key

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

Purchase Request Merchant

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

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