Ασφάλεια Υπολογιστών και Προστασία Δεδομένων Ιόνιο Πανεπιστήμιο Τμήμα Πληροφορικής Ακαδημαϊκό Έτος 2012-2013 Εξάμηνο: Δ’ Ασφάλεια Υπολογιστών και Προστασία Δεδομένων Ενότητα Ε: Ασφάλεια Δικτύων: Αυθεντικοποιημένη Εδραίωση Κλειδιού και Εφαρμογές 1

Αυθεντικοποιημένη Εδραίωση Κλειδιού Syllabus Ασφαλής Επικοινωνία – Βασικές Έννοιες & Εργαλεία Αυθεντικοποίηση Χρήστη & Μηνύματος, Μυστικότητα Κρυπτογραφικά Πρωτόκολλα Εδραίωσης Κλειδιού Ορισμοί-Κατηγοριοποίηση-Στόχοι Ασφάλειας Εδραίωση Κλειδιού με Συμμετρικές Τεχνικές Διανομή, Μεταφορά, Συμφωνία Κλειδιού - Εφαρμογές Εδραίωση Κλειδιού με Τεχνικές Δημόσιου Κλειδιού Μεταφορά, Συμφωνία Κλειδιού - Εφαρμογές Προηγμένα Πρωτόκολλα Εδραίωσης Εφαρμογές SSL/TLS (Secure Sockets Layer / Transport Layer Security) SSH (Secure Shell) IPSec (Internet Protocol Security)

1. Ασφαλής Επικοινωνία Βασικές Έννοιες & Εργαλεία H Alice & ο Bob μπορεί να είναι χρήστες, Η/Υ, διεργασίες κλπ… 1. Ασφαλής Επικοινωνία Βασικές Έννοιες & Εργαλεία Ζητούμενο: Ασφαλής Επικοινωνία Σε κάθε είδους εξ’ αποστάσεως επικοινωνία, το ζητούμενο είναι η ασφαλής επικοινωνία έναντι είτε παθητικών εχθρών που υποκλέπτουν την επικοινωνία, ή/και ενεργητικών εχθρών που μπορεί να εξαπολύουν επιθέσεις πλαστοπροσωπίας ή ενδιάμεσης οντότητας. Από τη σκοπιά της Alice και του Bob για παράδειγμα, σκοπός είναι η εξασφάλιση ιδιοτήτων όπως: Αυθεντικοποίηση Χρήστη, δηλαδή απάντηση στο ερώτημα: «Με ποιον μιλάω, τώρα?» Αυθεντικοποίηση Μηνύματος, δηλαδή απάντηση στο ερώτημα: «Ποιος δημιούργησε το μήνυμα που έλαβα?» Μυστικότητα (Εμπιστευτικότητα), δηλαδή εξασφάλιση ότι κανείς δεν αποκ΄τά πρόσβαση στην επικοινωνία μας. Alice Bob Αυθεντικοποίηση Χρήστη: «Με ποιον μιλάω, τώρα?» Αυθεντικοποίηση Μηνύματος: «Ποιος δημιούργησε το μήνυμα που έλαβα?» Μυστικότητα (Εμπιστευτικότητα): «Κανείς δεν μπορεί να διαβάσει όσα λέμε εγώ και η Alice» Αυθεντικοποίηση Χρήστη: «Με ποιον μιλάω, τώρα?» Αυθεντικοποίηση Μηνύματος: «Ποιος δημιούργησε το μήνυμα που έλαβα?» Μυστικότητα (Εμπιστευτικότητα): «Κανείς δεν μπορεί να διαβάσει όσα λέμε εγώ και η Alice» ΕνεργητικόςΕχθρός (Mallory) ΠαθητικόςΕχθρός (Eve)

1. Ασφαλής Επικοινωνία Βασικές Έννοιες & Εργαλεία Ζητούμενο: Ασφαλής Επικοινωνία Σήμερα, η κρυπτογραφία μας προσφέρει ασφαλείς & αποδοτικούς μηχανισμούς για την εκπλήρωση των ιδιοτήτων ασφάλειας: Σήμερα, η κρυπτογραφία μας προσφέρει ασφαλείς & αποδοτικούς μηχανισμούς για την εκπλήρωση των ιδιοτήτων ασφάλειας. Παραδείγματα αποτελούν: Τεχνικές αυθεντικοποίησης χρήστη με πρόκληση-απάντηση Αυθεντικοποίηση με συναρτήσεις Message Authentication Code & αλγόριθμους Ψηφιακών Υπογραφών Αλγόριθμους Συμμετρικής Κρυπτογράφησης (π.χ 3DES, AES) ή Κρυπτογράφησης Δημόσιου Kλειδιού (π.χ. RSA) Στην πράξη σήμερα προτιμώνται οι συμμετρικές τεχνικές, για λόγους απόδοσης. Alice Bob Αυθεντικοποίηση Χρήστη: «Με ποιον μιλάω, τώρα?» Αυθεντικοποίηση Μηνύματος: «Ποιος δημιούργησε το μήνυμα που έλαβα?» Μυστικότητα (Εμπιστευτικότητα): «Κανείς δεν μπορεί να διαβάσει όσα λέμε εγώ και η Alice» Τεχνικές Πρόκλησης-Απάντησης Λόγω απόδοσης, στην πράξη προτιμώνται οι συμμετρικές τεχνικές ! Αυθεντικοποίηση με MAC (Αλγόριθμοι: MD5, SHA-1,…) & Ψηφιακές Υπογραφές (Αλγόριθμοι: DSA, RSA, ElGamal,… ) ΕνεργητικόςΕχθρός ΠαθητικόςΕχθρός Συμμετρική Κρυπτογράφηση (Αλγόριθμοι: AES,3DES), Κρυπτογράφηση με Δημόσιο Kλειδί (Αλγόριθμοι: RSA, ElGamal,…)

2. Πρωτόκολλα Εδραίωσης Κλειδιού Ορισμοί Το πρόβλημα: Στις συμμετρικές τεχνικές, η Alice και ο Bob μοιράζονται ένα κλειδί Κ. Πώς όμως αποκτούν αυτό το κλειδί; Γενικότερη διατύπωση: Πώς δύο ή περισσότερες οντότητες αποκτούν από κοινού ένα μυστικό (συμμετρικό) κλειδί για ασφαλή επικοινωνία … … δηλαδή έναντι παθητικών ή/και ενεργητικών εχθρών Οι συμμετρικές τεχνικές, στις οποίες αναφερθήκαμε νωρίτερα, προϋποθέτουν ότι η Alice και ο Bob ΗΔΗ μοιράζονται ένα κλειδί Κ. Πώς όμως έχουν αποκτήσει αυτό το κλειδί, δεδομένου ότι επικοινωνούν μέσα από ένα μη ασφαλές κανάλι? Η ΑΛΛΙΩΣ: Πώς δύο ή περισσότερες οντότητες αποκτούν από κοινού ένα μυστικό (συμμετρικό) κλειδί για ασφαλή επικοινωνία … έναντι παθητικών εχθρών που υποκλέπτουν την επικοινωνία, ή/και έναντι ενεργητικών εχθρών που αλλοιώνουν, διαγράφουν, ή εισάγουν πλαστά δεδομένα? Σημείωση: Ως παθητικός εχθρός μπορεί να θεωρηθεί και ένας εκ των Alice ή/και Bob που π.χ. επιθυμεί να μάθει περισσότερα πράγματα από ό,τι του επιτρέπει ένα πρωτόκολλο επικοινωνίας. Eve: Υποκλέπτει επικοινωνία Mallory: Επιθέσεις πλαστοπροσωπίας και ενδιάμεσης οντότητας

2. Πρωτόκολλα Εδραίωσης Κλειδιού Ορισμοί Γιατί κλειδιά συνόδου; Περιορισμός των συνεπειών αν ο «εχθρός» βρει ένα κλειδί. Περιορισμός της ποσότητας υλικού που θα χρησιμοποιηθεί για κρυπτανάλυση. Άρση ανάγκης αποθήκευσης πολλών κλειδιών για μεγάλο χρονικό διάστημα. Ανεξαρτησία μεταξύ των συνόδων επικοινωνίας και των δικτυακών εφαρμογών Σκοπός: Η εδραίωση ενός εφήμερου ή «φρέσκου» κλειδιού που αποκαλείται κλειδί συνόδου (session key) Ο στόχος ενός πρωτοκόλλου εδραίωσης κλειδιού είναι η απόκτηση ενός εφήμερου συμμετρικού κλειδιού που καλείται κλειδί συνόδου. Οι λόγοι για την εδραίωση κλειδιών συνόδου είναι: – Ο περιορισμός των συνεπειών από την αποκάλυψη ή τη μη εξουσιοδοτημένη πρόσβαση σε κρυπτογραφικά κλειδιά. - O περιορισμός της ποσότητας κρυπτογραφημένου υλικού που μπορεί να χρησιμοποιηθεί για κρυπτανάλυση. – Η άρση της ανάγκης αποθήκευσης πολλών κρυπτογραφικών κλειδιών για μεγάλο χρονικό διάστημα. – Η ανεξαρτησία μεταξύ των συνόδων επικοινωνίας και μεταξύ των δικτυακών εφαρμογών/υπηρεσιών.

2. Πρωτόκολλα Εδραίωσης «Φυσική» Εδραίωση Κλειδιού Σενάρια: H Alice επιλέγει ένα κλειδί και το μεταδίδει στον Bob με φυσικό τρόπο Μια Τρίτη Αρχή επιλέγει ένα κλειδί και το μεταδίδει στους Alice & Bob με φυσικό τρόπο Για κρυπτογράφηση από άκρη-σε-άκρη (end-to-end) στο επίπεδο δικτύου, όχι αποδοτικό N hosts: Ν(Ν-1)/2 κλειδιά Τι θα γίνει αν η κρυπτογράφηση γίνει στο επίπεδο εφαρμογής; 1 κλειδί για κάθε ζεύγος χρηστών ή διεργασιών; Case: Δίκτυο με εκατοντάδες κόμβους & χιλιάδες διεργασίες! Τα σενάρια 1 και 2, συνήθως εφαρμόζονται για: Κρυπτογράφηση ζεύξης (link encryption) στο επίπεδο σύν-δεσης δεδομένων (π.χ. Wi-fi)

2. Πρωτόκολλα Εδραίωσης «Φυσική» Εδραίωση Κλειδιού

2. (Λογική) Εδραίωση Κλειδιού Κατηγοριοποίηση Τρεις περιπτώσεις: Οι Alice & Bob μοιράζονται ήδη ένα κλειδί μακράς διαρκείας (π.χ. password) Οι Alice & Bob μοιράζονται ξεχωριστά κλειδιά μακράς διαρκείας με ένα έμπιστο κέντρο (KDC). Η Alice και ο Bob δεν μοιράζονται κάποιο κλειδί Τα πρωτόκολλα εδραίωσης κλειδιού μπορούν να διακριθούν σε: Α. Σε πρωτόκολλα που χρησιμοποιούν συμμετρικές τεχνικές, όπου δηλαδή για παράδειγμα η Alice και ο Bob μοιράζονται ένα κλειδί μακράς διαρκείας (π.χ. password). Εναλλακτικά, οι Alice & Bob μοιράζονται ξεχωριστά κλειδιά με ένα έμπιστο κέντρο (Key Distribution Center). B. Η Alice και ο Bob δεν μοιράζονται κάποιο κλειδί (είτε μεταξύ τους είναι με τρίτες οντότητες). Σε αυτήν την περίπτωση η εδραίωση επιτυγχάνονται κάνοντας χρήση τεχνικών δημόσιου κλειδιού. ΣΥΜΜΕΤΡΙΚΕΣ ΤΕΧΝΙΚΕΣ ΤΕΧΝΙΚΕΣ ΔΗΜΟΣΙΟΥ ΚΛΕΙΔΙΟΥ

2. (Λογική) Εδραίωση Κλειδιού Κατηγοριοποίηση Τρεις περιπτώσεις: Οι Alice & Bob μοιράζονται ήδη ένα κλειδί μακράς διαρκείας (π.χ. password) Οι Alice & Bob μοιράζονται ξεχωριστά κλειδιά μακράς διαρκείας με ένα έμπιστο κέντρο (KDC). Η Alice και ο Bob δεν μοιράζονται κάποιο κλειδί Σε κλειστά ή/και αυτόνομα συστήματα, τα κλειδιά μακράς διαρκείας (Master keys) χρησιμοποιούνται για την εδραίωση των (εφήμερων) κλειστών συνόδου. Τα Master keys διανέμονται με μη κρυπτογραφικό τρόπο (π.χ. φυσικά) Η προτεινόμενη μέθοδος για συστήματα μεγάλης κλίμακας (π.χ. Internet)

2. Πρωτόκολλα Εδραίωσης Κλειδιού Κατηγοριοποίηση Πρωτόκολλα Διανομής Κλειδιού (Key Distribution) Μια έμπιστη οντότητα (KDC) δημιουργεί το κλειδί και το στέλνει στην Alice και τον Bob Πρωτόκολλα Μεταφοράς Κλειδιού (Key transport) Η Alice (Bob) δημιουργεί ένα κλειδί και το στέλνει στον Bob (Alice) Ειδικότερα, τα πρωτόκολλα εδραίωσης κλειδιού μπορούν να διακριθούν σε Πρωτόκολλα Διανομής κλειδιού. Σε αυτά τα πρωτόκολλα. μία έμπιστη οντότητα (Κέντρο Διανομής Κλειδιού – KDC) συμμετέχει στο πρωτόκολλο εδραίωσης. Στην πιο απλή μορφή των πρωτοκόλλων αυτής της κατηγορίας, το ΚΔΚ επιλέγει το κλειδί συνόδου και το αποστέλλει με ασφαλή τρόπο στους χρήστες, για περαιτέρω επικοινωνία. Πρωτόκολλα Μεταφοράς κλειδιού, όπου ένας χρήστης δημιουργεί το κλειδί συνόδου και το αποστέλλει με ασφάλεια στον άλλο χρήστη. Πρωτόκολλα Συμφωνίας κλειδιού. Οι χρήστες συμμετέχουν στη δημιουργία του κλειδιού συνόδου, τυπικά συνεισφέροντας ψευδο-τυχαιότητα για την κατασκευή του Πρωτόκολλα Συμφωνίας Κλειδιού (Key Agreement) Η Alice & Bob συνεισφέρουν από κοινού στη δημιουργία του κλειδιού συνόδου

2. Πρωτόκολλα Εδραίωσης Κλειδιού Κατηγοριοποίηση 2. Πρωτόκολλα Εδραίωσης Κλειδιού Κατηγοριοποίηση Κρυπτογραφικά Πρωτόκολλα Εδραίωσης Κλειδιού 1. Συμμετρικές Τεχνικές 2. Τεχνικές Δημόσιου Κλειδιού Διανομής: Π1-Π8 Μεταφοράς: Π9-Π10 Συμφωνίας: Π11-Π12 Μεταφοράς: Π14-Π18 Συμφωνίας: Π19-Π26 Πηγή: (Magkos et al, 2011)

2. Πρωτόκολλα Εδραίωσης Κλειδιού Κατηγοριοποίηση Σημείωση: Στις συμμετρικές τεχνικές, μπορούμε να εντάξουμε μια επιπλέον κατηγορία Εδραίωση χωρίς σύνδεση με προ-μοιρασμένα κλειδιά (Offline Key Establishment with Pre-Shared Keys) Στις συμμετρικές τεχνικές, μπορούμε να εντάξουμε μια επιπλέον κατηγορία Εδραίωση χωρίς σύνδεση με προ-μοιρασμένα κλειδιά: Στην ειδική αυτή περίπτωση οι Alice και Bob, που ήδη μοιράζονται ένα κλειδί μακράς διαρκείας K, κατασκευάζουν τα κλειδιά των επόμενων συνόδων, ΧΩΡΙΣ να αλληλεπιδράσουν. Στο παράδειγμα, το κλειδί συνόδου της εποχής j είναι η έξοδος μιας συνάρτησης hash, στην οποία δίνονται ως είσοδος το κλειδί Κ και μια τιμή nonce (π.x. Η τρέχουσα τιμή ενός μετρητή στον οποίο έχουν προ-συμφωνήσει) K K Παράδειγμα (για j συνόδους) Session 1: Κ1 = Hash(K, n1) Session 2: Κ2 = Hash(K, n2) … Session j: Κj = Hash(K, nj) n: nonce (number used once)

2. Πρωτόκολλα Εδραίωσης Κλειδιού Στόχοι Ασφάλειας 2. Πρωτόκολλα Εδραίωσης Κλειδιού Στόχοι Ασφάλειας Αυθεντικοποίηση Χρήστη (User Authentication) Αυθεντικοποίηση Κλειδιού (Key Authentication) Εννούμενη Αυθεντικοποίηση (Implicit Key Authentication) Ρητή Αυθεντικοποίηση (Explicit Key Authentication) Μυστικότητα Κλειδιού (Key Secrecy) Φρεσκάδα Κλειδιού (Key Freshness) … ένα πρωτόκολλο εδραίωσης θεωρείται ασφαλές αν το κλειδί που θα προκύψει είναι ανέφικτο να το γνωρίζει/μάθει ένας μη εξουσιοδοτημένος χρήστης… Η αυθεντικοποίηση μπορεί να είναι μονόδρομη ή αμοιβαία Ένα πρωτόκολλο εδραίωσης θεωρείται ασφαλές αν το κλειδί που προκύπτει είναι αδύνατον (στην πράξη, ανέφικτο) να το γνωρίζει ή μάθει ένας μη εξουσιοδοτημένος χρήστης, εσωτερικός ή εξωτερικός του συστήματος. Ας δούμε ειδικότερα τις απαιτήσεις ασφάλειας που αναφέρονται στη βιβλιογραφία.

2. Πρωτόκολλα Εδραίωσης Κλειδιού Στόχοι Ασφάλειας 2. Πρωτόκολλα Εδραίωσης Κλειδιού Στόχοι Ασφάλειας Αυθεντικοποίηση Χρήστη Κάθε χρήστης μπορεί να καθορίσει: Την ταυτότητα του χρήστη με τον οποίο εδραιώνει το κλειδί συνόδου, και ότι ο έτερος χρήστης είναι ενεργός τη στιγμή που εκτελείται το πρωτόκολλο Αυθεντικοποίηση Kλειδιού. Ο χρήστης γνωρίζει την ταυτότητα του χρήστη με τον οποίο εδραίωσε το κλειδί Εννούμενη Αυθεντικοποίηση π.χ. η Alice γνωρίζει ότι μόνον ο Βob μπορεί να έχει πρόσβαση στο κλειδί που εδραιώνεται Ρητή αυθεντικοποίηση π.χ. η Alice βεβαιώνεται ότι ο Βοb έχει πρόσβαση στο κλειδί που εδραιώθηκε 1) Αυθεντικοποίηση χρήστη. Κάθε χρήστης μπορεί να καθορίσει την ταυτότητα του χρήστη με τον οποίο εδραιώνει το κλειδί συνόδου, καθώς επίσης και ότι ο έτερος χρήστης είναι ενεργός τη στιγμή που εκτελείται το πρωτόκολλο. Διακρίνεται σε μονόδρομη και αμοιβαία. 2) Αυθεντικοποίηση κλειδιού. Η ιδιότητα σύμφωνα με την οποία ο χρήστης γνωρίζει την ταυτότητα του χρήστη που έχει/αποκτά πρόσβαση στο κλειδί που εδραιώνεται. Επίσης διακρίνεται σε μονόδρομη και αμοιβαία. Συχνά, διακρίνεται περαιτέρω σε: – Εννοούμενη αυθεντικοποίηση, όπου π.χ. η Alice γνωρίζει ότι μόνον ο Βob μπορεί να έχει πρόσβαση στο κλειδί που εδραιώνεται, και – Ρητή (explicit) αυθεντικοποίηση, όπου π.χ. η Alice βεβαιώνεται ότι ο Βοb απέκτησε το κλειδί που εδραιώθηκε. Ουσιαστικά η ιδιότητα αυτή αναφέρεται και ως επιβεβαίωση κλειδιού, όπου δηλαδή η Alice και ο Bob αποδεικνύουν ο ένας στον άλλον ότι γνωρίζουν το κλειδί που εδραιώθηκε. Γνωστή και ως «Επιβεβαίωση Κλειδιού»

2. Πρωτόκολλα Εδραίωσης Κλειδιού Στόχοι Ασφάλειας 2. Πρωτόκολλα Εδραίωσης Κλειδιού Στόχοι Ασφάλειας Μυστικότητα Κλειδιού Μόνον οι εξουσιοδοτημένοι χρήστες έχουν πρόσβαση στο κλειδί συνόδου Φρεσκάδα Κλειδιού Το εδραιωμένο κλειδί πρέπει να είναι καινούριο, δηλ. να μην έχει εδραιωθεί ξανά στο παρελθόν από άλλους χρήστες 3) Μυστικότητα κλειδιού. Μόνον οι Alice, Bob αποκτούν πρόσβαση στο κλειδί συνόδου. 4) Φρεσκάδα κλειδιού. Το κλειδί που εδραιώνεται πρέπει να είναι καινούριο, δηλαδή να μην έχει εδραιωθεί/χρησιμοποιηθεί στο παρελθόν από άλλους χρήστες του συστήματος.

2. Πρωτόκολλα Εδραίωσης Κλειδιού Στόχοι Αποδοτικότητας 2. Πρωτόκολλα Εδραίωσης Κλειδιού Στόχοι Αποδοτικότητας Ένα πρωτόκολλο εδραίωσης πρέπει να είναι αποδοτικό ως προς τις εξής πολυπλοκότητες: Επικοινωνία: Ο αριθμός των αποστολών μηνυμάτων (passes), Ο αριθμός των bit που ανταλλάσσονται (per pass), Κ Alice Bob Υπολογισμοί: ο αριθμός των απαιτούμενων υπολογιστικών πράξεων Αποθήκευση: O απαιτούμενος αποθηκευτικός χώρος που απαιτείται για την εδραίωση Carol

Συμβολισμοί Εδώ βλέπουμε τους συμβολισμούς που θα χρησιμοποιήσουμε και θα εξηγήσουμε στα πρωτόκολλα που ακολουθούν.

3. Εδραίωση με Συμμετρικές Τεχνικές 3. Α 3. Εδραίωση με Συμμετρικές Τεχνικές 3.Α. Διανομή Κλειδιού - Πρωτόκολλο Π1 Πρωτόκολλο Π1 - Απλή διανομή κλειδιού [38] [Popek and Kline, 1979]

3. Εδραίωση με Συμμετρικές Τεχνικές 3. Α 3. Εδραίωση με Συμμετρικές Τεχνικές 3.Α. Διανομή Κλειδιού - Πρωτόκολλο Π2 Πρωτόκολλο Π2 - Απλή διανομή με ρητή αυθεντικοποίηση

3. Εδραίωση με Συμμετρικές Τεχνικές 3. Α 3. Εδραίωση με Συμμετρικές Τεχνικές 3.Α. Διανομή Κλειδιού - Πρωτόκολλο Π2 Επίθεση Ε1 - Μία επίθεση πλαστοπροσωπίας στο πρωτόκολλο Π2 [30]

3. Εδραίωση με Συμμετρικές Τεχνικές 3. Α 3. Εδραίωση με Συμμετρικές Τεχνικές 3.Α. Διανομή Κλειδιού - Πρωτόκολλο Π3 Πρωτόκολλο Π3 -Αυθεντικοποίηση με εισαγωγή πληροφορίας σχετικής με την ταυτότητα των χρηστών [30]

3. Εδραίωση με Συμμετρικές Τεχνικές 3. Α 3. Εδραίωση με Συμμετρικές Τεχνικές 3.Α. Διανομή Κλειδιού - Πρωτόκολλο Π3 Επίθεση Ε2 - Μία επίθεση πλαστοπροσωπίας στο πρωτόκολλο Π3 [30]

3. Εδραίωση με Συμμετρικές Τεχνικές 3. Α 3. Εδραίωση με Συμμετρικές Τεχνικές 3.Α. Διανομή Κλειδιού - Πρωτόκολλο Π4 Πρωτόκολλο Π4 - Το πρωτόκολλο διανομής των Needham-Schroeder [35] ( Needham and Schroeder, 1978)

3. Εδραίωση με Συμμετρικές Τεχνικές 3. Α 3. Εδραίωση με Συμμετρικές Τεχνικές 3.Α. Διανομή Κλειδιού - Πρωτόκολλο Π4 Επίθεση Ε3 - Μία επίθεση πλαστοπροσωπίας στο Needham-Schroeder [14] (Denning and Sako, 1981)

3. Εδραίωση με Συμμετρικές Τεχνικές 3. Α 3. Εδραίωση με Συμμετρικές Τεχνικές 3.Α. Διανομή Κλειδιού - Πρωτόκολλο Π5 Πρωτόκολλο Π5 - Εισαγωγή χρονοσφραγίδων στο πρωτόκολλο Needham-Schroeder [14] (Denning and Sako, 1981, Denning, 1981)

Menezes, Oorschot, Vanstone, Handbook of Applied Cryptography, CRC, 2001

Το Σύστημα Kerberos To λογισμικό Kerberos στον Η/Υ της Emily στέλνει το username στην Υπηρεσία Αυθεντικοποίησης (AS) στον server KDC, που με τη σειρά της επιστρέφει στην Emily ένα Εισιτήριο Έκδοσης Εsισιτηρίων (Ticket Granting Ticket – TGT), κρυπτογραφημένο (συμμετρικά) με το password της Emily Η Emily έρχεται στη δουλειά. Εισάγει σε μια φόρμα το username και τον κωδικό της πρόσβασης, στις 8.00 A.M Η TGS δημιουργεί και στέλνει στην Emily ένα 2o εισιτήριο, για την ταυτοποίηση της στον file server. To εισιτήριο περιέχει ένα κλειδί συνόδου , κρυπτογραφημένο με τα κλειδιά που μοιράζεται το KDC με Emily & τον server Αν η Emily έχει δώσει το σωστό password, το TGT αποκρυπτογραφείται και η Alice αποκτά πρόσβαση στο σταθμό εργασίας της Όταν η Emily θελήσει να επικοινωνήσει με τον file server, το Kerberos στον Η/Υ της στέλνει μια αίτηση, μαζί με το TGT, στην Υπηρεσία Έκδοσης Εισιτηρίων (Τicket Granting Service – TGS) στον KDC. Το Kerberos εξάγει το κλειδί συνόδου, και αποστέλλει το εισιτήριο στον file server για να αρχίσει η επικοινωνία !

Εφαρμογή Νο 2 The Kerberos System (Stallings, 2010) Εφαρμογή Νο 2 The Kerberos System (Steiner et al, 1988) The problem : ”In an open distributed environment users at workstations wish to access services on servers distributed throughout the network. The servers must be able to restrict access to authorized users and to authenticate requests for service.” A workstation cannot be trusted to identify users correctly A user may gain access to a particular workstation and pretend to be another user operating from that workstation A user may alter the network address of a workstation and thus impersonate another workstation A user may eavesdrop on exchanges and use a replay attack to gain entrance to a server

Εφαρμογή Νο 2 The Kerberos System (Stallings, 2010) Εφαρμογή Νο 2 The Kerberos System In a distributed architecture consisting of clients and servers three approaches to security can be envisioned: Rely on each client workstation to assure the identity of its users and rely on each server to enforce security policy based on user identification (ID). Require that client systems authenticate themselves to servers, but trust the client systems concerning the identity of the user. Require the user to prove identity for each service invoked. Require that servers prove their identity to clients. Third approach is supported by Kerberos: Motivation If a set of users is provided with dedicated personal computers that have no network connections, then a user’s resources and files can be protected by physically securing each personal computer. When these users are served by a central time sharing system, the time sharing operation must provide the security. The operating system can enforce access control policies based on user identity and use the logon procedure to identify users. Today, neither of these scenarios is typical. More common is a distributed architecture consisting of dedicated user work stations (clients) and distributed or centralized servers. In this environment, three approaches of security can be envisioned: Rely on each individual client workstations to assure the identity of its user or users and rely on each server to enforce a security policy based on user identification (ID). Requires that client systems authenticate themselves to servers, but trust the client system concerning the identity of the user. Requires the user to prove identity fro each service invoked. Also requires that severs prove their identity to clients. In a small, closed environment, in which all systems are owned and operated by a single organization, the first or perhaps the second strategy may suffice. But in a more open environment, in which network connections to other machines are supported, the third approach is needed to protect user information and resources housed by the server. The third approach is supported b Kerberos. Kerberos assumes distributed client/server architecture and employs one or more Kerberos servers to provide an authentication service.

Εφαρμογή Νο 2 The Kerberos System (Stallings, 2010) Εφαρμογή Νο 2 The Kerberos System A trusted, centralized auth. server who facilitates authentication of users to servers and servers to users. There are two versions Version 4 is still in common use Version 5 (1994) corrects some deficiencies of version 4 Kerberos relies exclusively on conventional encryption. (Steiner et al, 1988, Miller et al,1988) (Kohl et al, 1994) (RFC 4120)

Εφαρμογή Νο 2 The Kerberos System (Stallings, 2010) Εφαρμογή Νο 2 The Kerberos System The following requirements were listed for Kerberos: Secure: a network eavesdropper should not be able to obtain the required information for impersonating a user. Reliable: Kerberos should employ a distributed server architecture with one system able to back up another. Transparent: the user should not be aware that authentication is taking place, except for the entering of the password. Scalable: the system should have a modular, distributed architecture to support large number of clients and servers.

Kerberos Version 4 (Stallings, 2010) We build up to full protocol (Steiner et al, 1988, Miller et al,1988) We build up to full protocol A Simple Authentication Protocol This protocol uses an authentication server (AS) that knows the passwords of each user and shares a secret key with each server. Some issues: Plaintext transmission of password Number of password uses (Bryant et al,1988) A Simple Authentication Dialogue. In an unprotected network environment, any client can apply to any server for service. The obvious security risk is that of impersonation. An opponent can pretend to be another client and obtain unauthorized privileges on server machines. To counter this threat, servers must be able to confirm the identities of clients who request service. Each server can be required to undertake this task for each client/ server interaction, but in an open environment, this places a substantial burden on each server. An alternative is to use an authentication server (AS) that knows the passwords of all users and stores these in a centralized database. In addition, the AS shares a unique secret key with each server. These keys have been distributed physically or in some other secure manner. In this scenario, the user logs on to a workstation and requests access to server V. The clientmodule C in the user's workstation requests the user's password and then sends a message to theAS that includes the user's ID, the server's ID, and the user's password. The AS checks itsdatabase to see if the user has supplied the proper password for this user ID and whether this user is permitted access to server V. If both tests are passed, the AS accepts the user as authentic andmust now convince the server that this user is authentic. To do so, the AS creates a ticket thatcontains the user's ID and network address and the server's ID. This ticket is encrypted using thesecret key shared by the AS and this server. This ticket is then sent back to C. Because the ticketis encrypted, it cannot be altered by C or by an opponent. With this ticket, C can now apply to Vfor service. C sends a message to V containing C's ID and the ticket. V decrypts the ticket andverifies that the user ID in the ticket is the same as the unencrypted user ID in the message. If these two match, the server considers the user authenticated and grants the requested service. The ticket is encrypted to prevent alteration or forgery. The server's ID (IDV) is included in the ticket so that the server can verify that it has decrypted the ticket properly. IDC  is included in theticket to indicate that this ticket has been issued on behalf of C. Finally, ADC  serves to counter the following threat. An opponent could capture the ticket transmitted in message (2), then usethe name IDC  and transmit a message of form (3) from another workstation. The server wouldreceive a valid ticket that matches the user ID and grant access to the user on that other workstation. To prevent this attack, the AS includes in the ticket the network address from which the original request came. Now the ticket is valid only if it is transmitted from the same workstation that initially requested the ticket. Although the foregoing scenario solves some of the problems of authentication in an open network environment, problems remain. Two in particular stand out. First, we would like to minimize the number of times that a user has to enter a password. Suppose each ticket can beused only once. If user C logs on to a workstation in the morning and wishes to check his or her mail at a mail server, C must supply a password to get a ticket for the mail server. If C wishes tocheck the mail several times during the day, each attempt requires reentering the password. We can improve matters by saying that tickets are reusable. For a single logon session, theworkstation can store the mail server ticket after it is received and use it on behalf of the user for multiple accesses to the mail server. However, under this scheme it remains the case that a user would need a new ticket for every different service. If a user wished to access a print server, amail server, a file server, and so on, the first instance of each access would require a new ticket and hence require the user to enter the password. The second problem is that the earlier scenario involved a plaintext transmission of the password [message (1)]. An eavesdropper could capturethe password and use any service accessible to the victim. To solve these additional problems,we introduce a scheme for avoiding plaintext passwords and a new server, known as the ticket-granting server (TGS). C  AS: IDC|| PC || IDV AS C: IDC || Ticket CV: Ticket Ticket = E(KV, [IDC|| ADC || IDV]) C = Client AS = authentication server V = server IDC = identifier of user on C IDV = identifier of V PC = password of user on C ADC = network address of C KV= secret encryption key shared by AS and V

Kerberos Version 4 (Stallings, 2010) (Steiner et al, 1988, Miller et al,1988) A More Secure Authentication Dialogue The new service, TGS, issues tickets to users who have been authenticated to AS. Thus, the user first requests a ticket-granting ticket (Tickettgs) from the AS. The client module in the user workstation saves this ticket. Each time the user requires access to a new service, the clientapplies to the TGS, using the ticket to authenticate itself. The TGS then grants a ticket for the particular service. The client saves each service-granting ticket and uses it to authenticate its user to a server each time a particular service is requested. Let us look at the details of this scheme 1. The client requests a ticket-granting ticket on behalf of the user by sending its user's ID to the AS, together with the TGS ID, indicating a request to use the TGSservice. 2. The AS responds with a ticket that is encrypted with a key that is derived from the user's password. When this response arrives at the client, the client prompts the user for his or her password, generates the key, and attempts to decrypt the incoming message. If thecorrect password is supplied, the ticket is successfully recovered Because only the correct user should know the password, only the correct user can recover theticket. Thus, we have used the password to obtain credentials from Kerberos without having totransmit the password in plaintext. The ticket itself consists of the ID and network address of the user, and the ID of the TGS. This corresponds to the first scenario. The idea is that the client canuse this ticket to request multiple service-granting tickets. So the ticket-granting ticket is to be reusable. However, we do not wish an opponent to be able to capture the ticket and use it.Consider the following scenario: An opponent captures the login ticket and waits until the user has logged off his or her workstation. Then the opponent either gains access to that workstationor configures his workstation with the same network address as that of the victim. The opponentwould be able to reuse the ticket to spoof the TGS. To counter this, the ticket includes atimestamp, indicating the date and time at which the ticket was issued, and a lifetime, indicatingthe length of time for which the ticket is valid (e.g., eight hours). Thus, the client now has areusable ticket and need not bother the user for a password for each new service request. Finally,note that the ticket-granting ticket is encrypted with a secret key known only to the AS and theTGS. This prevents alteration of the ticket. The ticket is reencrypted with a key based on theuser's password. This assures that the ticket can be recovered only by the correct user, providingthe authentication. The Version 4 Authentication Dialogue Although the foregoing scenario enhances security compared to the first attempt, two additional problems remain. The heart of the first problem is the lifetime associated with the ticket-granting ticket. If this lifetime isvery short (e.g., minutes), then the user will be repeatedly asked for a password. If the lifetime is long (e.g.,hours), then an opponent has a greater opportunity for replay. An opponent could eavesdrop on the network andcapture a copy of the ticket-granting ticket and then wait for the legitimate user to log out. Then the opponentcould forge the legitimate user's network address and send the message of step (3) to the TGS. This would give the opponent unlimited access to the resources and files available to the legitimate user.Similarly, if an opponent captures a service-granting ticket and uses it before it expires, the opponent has accessto the corresponding service Thus, we arrive at an additional requirement. A network service (the TGS or an application service) must beable to prove that the person using a ticket is the same person to whom that ticket was issued. The second problem is that there may be a requirement for servers to authenticate themselves to users. Without such authentication, an opponent could sabotage the configuration so that messages to a server were directed toanother location. The false server would then be in a position to act as a real server and capture any informationfrom the user and deny the true service to the user. Once per user logon session: (1) C  AS: IDC || IDtgs (2) AS  C: E(KC, Tickettgs) Once per type of service: (3) C TGS: IDC || IDV || Tickettgs (4) TGSC: TicketV Once per service session: (5) CV: IDC || TicketV Kc = key derived from user password Tickettgs= Ticket granting ticket Ticketv= Service- granting ticket TS = A time-stamp Issues Replays after C logs off & before lifetime is over Servers do not authenticate to Users Tickettgs = E(Ktgs, [IDC|| ADC || IDtgs || TS1 || Lifetime1] ) TicketV = E(KV, [IDC|| ADC || IDV || TS2 || Lifetime2])

Kerberos Version 4 The Version 4 Authentication Dialogue (Steiner et al, 1988, Miller et al,1988) First, consider the problem of captured ticket-granting tickets and the need to determine that the ticket presenteris the same as the client for whom the ticket was issued. The threat is that an opponent will steal the ticket anduse it before it expires. To get around this problem, let us have the AS provide both the client and the TGS witha secret piece of information in a secure manner. Then the client can prove its identity to the TGS by revealingthe secret information, again in a secure manner. An efficient way of accomplishing this is to use an encryptionkey as the secure information; this is referred to as a session key in Kerberos.Table 14.1ashows the technique for distributing the session key. As before, the client sends a message to theAS requesting access to the TGS. The AS responds with a message, encrypted with a key derived from theuser's password (Kc) that contains the ticket. The encrypted message also contains a copy of the session key,Kc,tgs, where the subscripts indicate that this is a session key for C and TGS. Because this session key is insidethe message encrypted with Kc, only the user's client can read it. The same session key is included in the ticket,which can be read only by the TGS. Thus, the session key has been securely delivered to both C and the TGS. Note that several additional pieces of information have been added to this first phase of the dialogue. Message(1) includes a timestamp, so that the AS knows that the message is timely. Message (2) includes severalelements of the ticket in a form accessible to C. This enables C to confirm that this ticket is for the TGS and tolearn its expiration time.Armed with the ticket and the session key, C is ready to approach the TGS. As before, C sends the TGS amessage that includes the ticket plus the ID of the requested service (message (3) inTable 14.1b). In addition, Ctransmits an authenticator, which includes the ID and address of C's user and a timestamp. Unlike the ticket,which is reusable, the authenticator is intended for use only once and has a very short lifetime. The TGS candecrypt the ticket with the key that it shares with the AS. This ticket indicates that user C has been providedwith the session key Kc,tgs. In effect, the ticket says, "Anyone who uses Kc,tgs must be C." The TGS uses thesession key to decrypt the authenticator. The TGS can then check the name and address from the authenticatorwith that of the ticket and with the network address of the incoming message. If all match, then the TGS isassured that the sender of the ticket is indeed the ticket's real owner. In effect, the authenticator says, "At timeTS3, I hereby use Kc,tgs." Note that the ticket does not prove anyone's identity but is a way to distribute keyssecurely. It is the authenticator that proves the client's identity. Because the authenticator can be used only onceand has a short lifetime, the threat of an opponent stealing both the ticket and the authenticator for presentationlater is countered The reply from the TGS, in message (4), follows the form of message (2). The message is encrypted with thesession key shared by the TGS and C and includes a session key to be shared between C and the server V, theID of V, and the timestamp of the ticket. The ticket itself includes the same session key. C now has a reusable service-granting ticket for V. When C presents this ticket, as shown in message (5), it alsosends an authenticator. The server can decrypt the ticket, recover the session key, and decrypt the authenticator. If mutual authentication is required, the server can reply as shown in message (6) of Table 14.1. The serverreturns the value of the timestamp from the authenticator, incremented by 1, and encrypted in the session key. Ccan decrypt this message to recover the incremented timestamp. Because the message was encrypted by thesession key, C is assured that it could have been created only by V. The contents of the message assure C that this is not a replay of an old reply. Finally, at the conclusion of this process, the client and server share a secret key. This key can be used toencrypt future messages between the two or to exchange a new random session key for that purpose (Stallings, 2010)

Kerberos Version 4 The Version 4 Authentication Dialogue (Steiner et al, 1988, Miller et al,1988) First, consider the problem of captured ticket-granting tickets and the need to determine that the ticket presenteris the same as the client for whom the ticket was issued. The threat is that an opponent will steal the ticket anduse it before it expires. To get around this problem, let us have the AS provide both the client and the TGS witha secret piece of information in a secure manner. Then the client can prove its identity to the TGS by revealingthe secret information, again in a secure manner. An efficient way of accomplishing this is to use an encryptionkey as the secure information; this is referred to as a session key in Kerberos.Table 14.1ashows the technique for distributing the session key. As before, the client sends a message to theAS requesting access to the TGS. The AS responds with a message, encrypted with a key derived from theuser's password (Kc) that contains the ticket. The encrypted message also contains a copy of the session key,Kc,tgs, where the subscripts indicate that this is a session key for C and TGS. Because this session key is insidethe message encrypted with Kc, only the user's client can read it. The same session key is included in the ticket,which can be read only by the TGS. Thus, the session key has been securely delivered to both C and the TGS. Note that several additional pieces of information have been added to this first phase of the dialogue. Message(1) includes a timestamp, so that the AS knows that the message is timely. Message (2) includes severalelements of the ticket in a form accessible to C. This enables C to confirm that this ticket is for the TGS and tolearn its expiration time.Armed with the ticket and the session key, C is ready to approach the TGS. As before, C sends the TGS amessage that includes the ticket plus the ID of the requested service (message (3) inTable 14.1b). In addition, Ctransmits an authenticator, which includes the ID and address of C's user and a timestamp. Unlike the ticket,which is reusable, the authenticator is intended for use only once and has a very short lifetime. The TGS candecrypt the ticket with the key that it shares with the AS. This ticket indicates that user C has been providedwith the session key Kc,tgs. In effect, the ticket says, "Anyone who uses Kc,tgs must be C." The TGS uses thesession key to decrypt the authenticator. The TGS can then check the name and address from the authenticatorwith that of the ticket and with the network address of the incoming message. If all match, then the TGS isassured that the sender of the ticket is indeed the ticket's real owner. In effect, the authenticator says, "At timeTS3, I hereby use Kc,tgs." Note that the ticket does not prove anyone's identity but is a way to distribute keyssecurely. It is the authenticator that proves the client's identity. Because the authenticator can be used only onceand has a short lifetime, the threat of an opponent stealing both the ticket and the authenticator for presentationlater is countered The reply from the TGS, in message (4), follows the form of message (2). The message is encrypted with thesession key shared by the TGS and C and includes a session key to be shared between C and the server V, theID of V, and the timestamp of the ticket. The ticket itself includes the same session key. C now has a reusable service-granting ticket for V. When C presents this ticket, as shown in message (5), it alsosends an authenticator. The server can decrypt the ticket, recover the session key, and decrypt the authenticator. If mutual authentication is required, the server can reply as shown in message (6) of Table 14.1. The serverreturns the value of the timestamp from the authenticator, incremented by 1, and encrypted in the session key. Ccan decrypt this message to recover the incremented timestamp. Because the message was encrypted by thesession key, C is assured that it could have been created only by V. The contents of the message assure C that this is not a replay of an old reply. Finally, at the conclusion of this process, the client and server share a secret key. This key can be used toencrypt future messages between the two or to exchange a new random session key for that purpose (Stallings, 2010)

First, consider the problem of captured ticket-granting tickets and the need to determine that the ticket presenteris the same as the client for whom the ticket was issued. The threat is that an opponent will steal the ticket anduse it before it expires. To get around this problem, let us have the AS provide both the client and the TGS witha secret piece of information in a secure manner. Then the client can prove its identity to the TGS by revealingthe secret information, again in a secure manner. An efficient way of accomplishing this is to use an encryptionkey as the secure information; this is referred to as a session key in Kerberos.Table 14.1ashows the technique for distributing the session key. As before, the client sends a message to theAS requesting access to the TGS. The AS responds with a message, encrypted with a key derived from theuser's password (Kc) that contains the ticket. The encrypted message also contains a copy of the session key,Kc,tgs, where the subscripts indicate that this is a session key for C and TGS. Because this session key is insidethe message encrypted with Kc, only the user's client can read it. The same session key is included in the ticket,which can be read only by the TGS. Thus, the session key has been securely delivered to both C and the TGS. Note that several additional pieces of information have been added to this first phase of the dialogue. Message(1) includes a timestamp, so that the AS knows that the message is timely. Message (2) includes severalelements of the ticket in a form accessible to C. This enables C to confirm that this ticket is for the TGS and tolearn its expiration time.Armed with the ticket and the session key, C is ready to approach the TGS. As before, C sends the TGS amessage that includes the ticket plus the ID of the requested service (message (3) inTable 14.1b). In addition, Ctransmits an authenticator, which includes the ID and address of C's user and a timestamp. Unlike the ticket,which is reusable, the authenticator is intended for use only once and has a very short lifetime. The TGS candecrypt the ticket with the key that it shares with the AS. This ticket indicates that user C has been providedwith the session key Kc,tgs. In effect, the ticket says, "Anyone who uses Kc,tgs must be C." The TGS uses thesession key to decrypt the authenticator. The TGS can then check the name and address from the authenticatorwith that of the ticket and with the network address of the incoming message. If all match, then the TGS isassured that the sender of the ticket is indeed the ticket's real owner. In effect, the authenticator says, "At timeTS3, I hereby use Kc,tgs." Note that the ticket does not prove anyone's identity but is a way to distribute keyssecurely. It is the authenticator that proves the client's identity. Because the authenticator can be used only onceand has a short lifetime, the threat of an opponent stealing both the ticket and the authenticator for presentationlater is countered The reply from the TGS, in message (4), follows the form of message (2). The message is encrypted with thesession key shared by the TGS and C and includes a session key to be shared between C and the server V, theID of V, and the timestamp of the ticket. The ticket itself includes the same session key. C now has a reusable service-granting ticket for V. When C presents this ticket, as shown in message (5), it alsosends an authenticator. The server can decrypt the ticket, recover the session key, and decrypt the authenticator. If mutual authentication is required, the server can reply as shown in message (6) of Table 14.1. The serverreturns the value of the timestamp from the authenticator, incremented by 1, and encrypted in the session key. Ccan decrypt this message to recover the incremented timestamp. Because the message was encrypted by thesession key, C is assured that it could have been created only by V. The contents of the message assure C that this is not a replay of an old reply. Finally, at the conclusion of this process, the client and server share a secret key. This key can be used toencrypt future messages between the two or to exchange a new random session key for that purpose (Stallings, 2010)

First, consider the problem of captured ticket-granting tickets and the need to determine that the ticket presenteris the same as the client for whom the ticket was issued. The threat is that an opponent will steal the ticket anduse it before it expires. To get around this problem, let us have the AS provide both the client and the TGS witha secret piece of information in a secure manner. Then the client can prove its identity to the TGS by revealingthe secret information, again in a secure manner. An efficient way of accomplishing this is to use an encryptionkey as the secure information; this is referred to as a session key in Kerberos.Table 14.1ashows the technique for distributing the session key. As before, the client sends a message to theAS requesting access to the TGS. The AS responds with a message, encrypted with a key derived from theuser's password (Kc) that contains the ticket. The encrypted message also contains a copy of the session key,Kc,tgs, where the subscripts indicate that this is a session key for C and TGS. Because this session key is insidethe message encrypted with Kc, only the user's client can read it. The same session key is included in the ticket,which can be read only by the TGS. Thus, the session key has been securely delivered to both C and the TGS. Note that several additional pieces of information have been added to this first phase of the dialogue. Message(1) includes a timestamp, so that the AS knows that the message is timely. Message (2) includes severalelements of the ticket in a form accessible to C. This enables C to confirm that this ticket is for the TGS and tolearn its expiration time.Armed with the ticket and the session key, C is ready to approach the TGS. As before, C sends the TGS amessage that includes the ticket plus the ID of the requested service (message (3) inTable 14.1b). In addition, Ctransmits an authenticator, which includes the ID and address of C's user and a timestamp. Unlike the ticket,which is reusable, the authenticator is intended for use only once and has a very short lifetime. The TGS candecrypt the ticket with the key that it shares with the AS. This ticket indicates that user C has been providedwith the session key Kc,tgs. In effect, the ticket says, "Anyone who uses Kc,tgs must be C." The TGS uses thesession key to decrypt the authenticator. The TGS can then check the name and address from the authenticatorwith that of the ticket and with the network address of the incoming message. If all match, then the TGS isassured that the sender of the ticket is indeed the ticket's real owner. In effect, the authenticator says, "At timeTS3, I hereby use Kc,tgs." Note that the ticket does not prove anyone's identity but is a way to distribute keyssecurely. It is the authenticator that proves the client's identity. Because the authenticator can be used only onceand has a short lifetime, the threat of an opponent stealing both the ticket and the authenticator for presentationlater is countered The reply from the TGS, in message (4), follows the form of message (2). The message is encrypted with thesession key shared by the TGS and C and includes a session key to be shared between C and the server V, theID of V, and the timestamp of the ticket. The ticket itself includes the same session key. C now has a reusable service-granting ticket for V. When C presents this ticket, as shown in message (5), it alsosends an authenticator. The server can decrypt the ticket, recover the session key, and decrypt the authenticator. If mutual authentication is required, the server can reply as shown in message (6) of Table 14.1. The serverreturns the value of the timestamp from the authenticator, incremented by 1, and encrypted in the session key. Ccan decrypt this message to recover the incremented timestamp. Because the message was encrypted by thesession key, C is assured that it could have been created only by V. The contents of the message assure C that this is not a replay of an old reply. Finally, at the conclusion of this process, the client and server share a secret key. This key can be used toencrypt future messages between the two or to exchange a new random session key for that purpose

First, consider the problem of captured ticket-granting tickets and the need to determine that the ticket presenteris the same as the client for whom the ticket was issued. The threat is that an opponent will steal the ticket anduse it before it expires. To get around this problem, let us have the AS provide both the client and the TGS witha secret piece of information in a secure manner. Then the client can prove its identity to the TGS by revealingthe secret information, again in a secure manner. An efficient way of accomplishing this is to use an encryptionkey as the secure information; this is referred to as a session key in Kerberos.Table 14.1ashows the technique for distributing the session key. As before, the client sends a message to theAS requesting access to the TGS. The AS responds with a message, encrypted with a key derived from theuser's password (Kc) that contains the ticket. The encrypted message also contains a copy of the session key,Kc,tgs, where the subscripts indicate that this is a session key for C and TGS. Because this session key is insidethe message encrypted with Kc, only the user's client can read it. The same session key is included in the ticket,which can be read only by the TGS. Thus, the session key has been securely delivered to both C and the TGS. Note that several additional pieces of information have been added to this first phase of the dialogue. Message(1) includes a timestamp, so that the AS knows that the message is timely. Message (2) includes severalelements of the ticket in a form accessible to C. This enables C to confirm that this ticket is for the TGS and tolearn its expiration time.Armed with the ticket and the session key, C is ready to approach the TGS. As before, C sends the TGS amessage that includes the ticket plus the ID of the requested service (message (3) inTable 14.1b). In addition, Ctransmits an authenticator, which includes the ID and address of C's user and a timestamp. Unlike the ticket,which is reusable, the authenticator is intended for use only once and has a very short lifetime. The TGS candecrypt the ticket with the key that it shares with the AS. This ticket indicates that user C has been providedwith the session key Kc,tgs. In effect, the ticket says, "Anyone who uses Kc,tgs must be C." The TGS uses thesession key to decrypt the authenticator. The TGS can then check the name and address from the authenticatorwith that of the ticket and with the network address of the incoming message. If all match, then the TGS isassured that the sender of the ticket is indeed the ticket's real owner. In effect, the authenticator says, "At timeTS3, I hereby use Kc,tgs." Note that the ticket does not prove anyone's identity but is a way to distribute keyssecurely. It is the authenticator that proves the client's identity. Because the authenticator can be used only onceand has a short lifetime, the threat of an opponent stealing both the ticket and the authenticator for presentationlater is countered The reply from the TGS, in message (4), follows the form of message (2). The message is encrypted with thesession key shared by the TGS and C and includes a session key to be shared between C and the server V, theID of V, and the timestamp of the ticket. The ticket itself includes the same session key. C now has a reusable service-granting ticket for V. When C presents this ticket, as shown in message (5), it alsosends an authenticator. The server can decrypt the ticket, recover the session key, and decrypt the authenticator. If mutual authentication is required, the server can reply as shown in message (6) of Table 14.1. The serverreturns the value of the timestamp from the authenticator, incremented by 1, and encrypted in the session key. Ccan decrypt this message to recover the incremented timestamp. Because the message was encrypted by thesession key, C is assured that it could have been created only by V. The contents of the message assure C that this is not a replay of an old reply. Finally, at the conclusion of this process, the client and server share a secret key. This key can be used toencrypt future messages between the two or to exchange a new random session key for that purpose

Scalability of Kerberos Kerberos Realms and Multiple Kerberi A Kerberos realm, is a full-service environment consisting of a Kerberos server, a number of clients and app servers: The Kerberos server has the IDs and hashed passwords of all users. All users are registered with the Kerberos server. The Kerberos server shares a secret key with each server. All servers are registered with the Kerberos server. Kerberos supports inter-realm authentication. Extra req: The Kerberos server in each interoperation realm shares a secret key with the server in the other realm. The two kerberos servers are registered with the each other.. Kerberos Realms and Multiple Kerberi A full-service Kerberos environment consisting of a Kerberos server, a number of clients, and a number of application servers requires the following: 1. The Kerberos server must have the user ID and hashed passwords of all participating users in its database.All users are registered with the Kerberos server. 2.The Kerberos server must share a secret key with each server. All servers are registered with the Kerberosserver.Such an environment is referred to as a Kerberos realm. The concept of realm can be explained as follows. A Kerberos realm is a set of managed nodes that share the same Kerberos database. The Kerberos database resideson the Kerberos master computer system, which should be kept in a physically secure room. A read-only copyof the Kerberos database might also reside on other Kerberos computer systems. However, all changes to thedatabase must be made on the master computer system. Changing or accessing the contents of a Kerberosdatabase requires the Kerberos master password. A related concept is that of a Kerberos principal, which is aservice or user that is known to the Kerberos system. Each Kerberos principal is identified by its principalname. Principal names consist of three parts: a service or user name, an instance name, and a realm name Networks of clients and servers under different administrative organizations typically constitute differentrealms. That is, it generally is not practical, or does not conform to administrative policy, to have users andservers in one administrative domain registered with a Kerberos server elsewhere. However, users in one realmmay need access to servers in other realms, and some servers may be willing to provide service to users fromother realms, provided that those users are authenticated Kerberos provides a mechanism for supporting such interrealm authentication. For two realms to supportinterrealm authentication, a third requirement is added: 3.The Kerberos server in each interoperating realm shares a secret key with the server in the other realm.The two Kerberos servers are registered with each other. The scheme requires that the Kerberos server in one realm trust the Kerberos server in the other realm toauthenticate its users. Furthermore, the participating servers in the second realm must also be willing to trust theKerberos server in the first realm. With these ground rules in place, we can describe the mechanism as follows : A user wishingservice on a server in another realm needs a ticket for that server. The user's client follows the usual proceduresto gain access to the local TGS and then requests a ticket-granting ticket for a remote TGS (TGS in anotherrealm). The client can then apply to the remote TGS for a service-granting ticket for the desired server in therealm of the remote TGS

Kerberos & Τομείς Ασφάλειας (Security Domains) Τομέας Ασφάλειας Μία λογική (logical) Ομάδα από υποκείμενα και αντικείμενα (χρήστες, Η/Υ, συσκευές, προγράμματα & εφαρμογές, δεδομένα, … ) …που υπακούν σε ένα κοινό σύνολο κανόνων ασφάλειας (i.e., πολιτική ασφάλειας) Kerberos: Ο ελεγκτής τομέα συγκεντρώνει τους ρόλους AS και TGS

Τομείς Ασφάλειας (Security Domains) Αρχιτεκτονική Client-Server Για κάθε τομέα, υπάρχει ένας server (Domain Controller) όπου: Μια κεντρική ΒΔ (Ενεργός Κατάλογος - Active Directory) περιέχει τους λογαριασμούς & ομάδες χρηστών και Η/Υ Δημιουργούνται & επιβάλλονται οι Πολιτικές Ασφάλειας του τομέα Πολιτικές ομάδων (group policies) Κριτήρια & Δικαιώματα πρόσβασης Ρυθμίσεις ασφάλειας Οι χρήστες (clients), γίνονται μέλη στον τομέα κάνοντας log on, με διαδικασίες SSO Μέσω LAN, WAN, VPN κλπ Λογική σύνδεση

Τομείς Ασφάλειας (Security Domains) -

Τομείς Ασφάλειας (Security Domains) Μεγάλα συστήματα, συχνά οργανώνονται ιεραρχικά: Δένδρο Πολλοί Τομείς, με το ίδιο namespace Δάσος (Forrest) Πολλά δένδρα, με διαφορετικά namespaces http://technet.microsoft.com/

3. Εδραίωση με Συμμετρικές Τεχνικές 3. Α 3. Εδραίωση με Συμμετρικές Τεχνικές 3.Α. Διανομή Κλειδιού - Πρωτόκολλο Π6 Πρωτόκολλο Π6 - Το πρωτόκολλο διανομής των Otway-Rees [37] (Otway and Rees, 1987)

3. Εδραίωση με Συμμετρικές Τεχνικές 3. Α 3. Εδραίωση με Συμμετρικές Τεχνικές 3.Α. Διανομή Κλειδιού - Πρωτόκολλο Π7 Πρωτόκολλο Π7 - Το πρωτόκολλο Π6 με αμοιβαία αυθεντικοποίηση [33]

3. Εδραίωση με Συμμετρικές Τεχνικές 3. Α 3. Εδραίωση με Συμμετρικές Τεχνικές 3.Α. Διανομή Κλειδιού - Πρωτόκολλο Π8 Πρωτόκολλο Π8 - Το πρωτόκολλο των Bellare-Rogaway [5] (Bellare and Rogaway, 1995)

3. Εδραίωση με Συμμετρικές Τεχνικές 3. Α 3. Εδραίωση με Συμμετρικές Τεχνικές 3.Α. Διανομή Κλειδιού - Πλεονεκτήματα & Μειονεκτήματα Πλεονεκτήματα Αρχιτεκτονικής Εύκολη διαχείριση συστήματος Κάθε οντότητα αποθηκεύει ένα μόνον κλειδί μακράς διαρκείας Μειονεκτήματα Αρχιτεκτονικής Υψηλή εμπιστοσύνη στον Trent Υψηλός φόρτος για τον Trent

3. Εδραίωση με Συμμετρικές Τεχνικές 3. Β 3. Εδραίωση με Συμμετρικές Τεχνικές 3.Β. Μεταφορά Κλειδιού - Πρωτόκολλο Π9 Πρωτόκολλο Π9 - Απλή μεταφορά κλειδιού [22] (ISO/IEC 11770-2:1996)

3. Εδραίωση με Συμμετρικές Τεχνικές 3. Β 3. Εδραίωση με Συμμετρικές Τεχνικές 3.Β. Μεταφορά Κλειδιού - Πρωτόκολλο Π10 Πρωτόκολλο Π10 - Απλή μεταφορά κλειδιού με πρόκληση-απάντηση [33]

3. Εδραίωση με Συμμετρικές Τεχνικές 3. C Πρωτόκολλο Π11 -To πρωτόκολλο ΑΚΕP2 [4] (Bellare and Rogaway, 1993) ΚS = Hash(K’AB, NA, NB)

3. Εδραίωση με Συμμετρικές Τεχνικές 3. C Πρωτόκολλο Π12 - Συμφωνία κλειδιού με χρονοσφραγίδες ΚS = Hash(kA, kB)

3. Εδραίωση με Συμμετρικές Τεχνικές 3. C Πρωτόκολλο Π13 - Συμφωνία κλειδιού με πρόκληση-απάντηση

4. Εδραίωση με Ασύμμετρες Τεχνικές 4. Α 4. Εδραίωση με Ασύμμετρες Τεχνικές 4.Α. Μεταφορά Κλειδιού - Η ιδέα του Merkle (Merkle, 1978) Η Alice φτιάχνει μια ΒΔ με 1.000.000 κλειδιά και αντίστοιχους (μοναδικούς) σειριακούς αριθμούς Η Alice κρυπτογραφεί κάθε ζεύγος της ΒΔ με διαφορετικά κλειδιά μικρού μήκους (π.χ 20 bit) Τυχαία σειρά

4. Εδραίωση με Ασύμμετρες Τεχνικές 4. Α 4. Εδραίωση με Ασύμμετρες Τεχνικές 4.Α. Μεταφορά Κλειδιού - Η ιδέα του Merkle (Merkle, 1978) Η Alice στέλνει στον Bob 1.000.000 κρυπτογραφημένα μηνύματα Ο Bob επιλέγει στην τύχη ένα μήνυμα και εξαπολύει μια επίθεση brute force π.χ. 1 ώρας διάρκεια O Bob ανακτά π.χ. το ζεύγος (1yt8a42x35 | 500,121) O Bob επικοινωνεί με την Alice: της λέει να χρησιμοποιήσει το κλειδί που αντιστοιχεί στο 500.121 Ασυμμετρία Η Eve δεν ξέρει πιο από τα κρυπτογραφημένα μηνύματα περιέχει το κλειδί που επέλεξε ο Bob !! Η Eve θα πρέπει να «σπάσει» κατά μέσο όρο 219 ~ 500.000 μηνύματα !!! π.χ. 500.000 ώρες εργασίας ! !

4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού 4. Α 4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού 4.Α. Μεταφορά Κλειδιού - Πρωτόκολλο Π15 Πρωτόκολλο Π15 -Ένα απλό πρωτόκολλο μεταφοράς κλειδιού [39,33] (Merkle, 1979, Kohnfelder 1978, p.5)

4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού 4. Α 4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού 4.Α. Μεταφορά Κλειδιού - Πρωτόκολλο Π15 Στην απλή του μορφή το Π15 είναι ευπαθές σε επιθέσεις MITM (Rivest & Shamir, 1984)

Εφαρμογή Νο 3 SSL 3.0 (Secure Sockets Layer) Το ΔΚ της CA είναι πιθανώς προ-εγκατεστημένο, κατά την εγκατάσταση του λογισμικού πλοήγησης … NA … NB , SigCA(PKB) EPKB[ΚΑ] ΚS = Hash(KA, NA, NB) ΚS = Hash(KA, NA, NB) Master Secret Pre-master Secret Master Secret

O “διάδοχος” του SSL TLS (Transport Layer Security) To πρωτόκολλο TLS αποτελεί επέκταση του SSL, παρέχοντας αμοιβαία αυθεντικοποίηση χρήστη (βλέπε υπογραφή από Alice στο βήμα 3 του πρωτοκόλλου) … NA … NB , SigCA(PKB) SigA(EPKB[ΚΑ],…), SigCA(PKA) ΚS = Hash(KA, NA, NB) ΚS = Hash(KA, NA, NB)

Εφαρμογή Νο 4 Κινητή Τηλεφωνία: WAP & WTLS SSL Μια παραλλαγή του πρωτοκόλλου TLS τη συναντάμε σήμερα, ως WTLS (Wireless TLS) στο πρότυπο WAP (Wireless Application Protocol) για τη διασύνδεση χρηστών «κινητών» συσκευών σε υπηρεσίες του Web. Στα κινητά 2ης γενιάς, ο ρόλος της πύλης (Gateway) είναι κυρίως η λήψη του περιεχομένου προς/από τον Web server, και η προσαρμογή του στις ανάγκες της κινητής συσκευής (δηλ. μιας συσκευής με περιορισμένη ισχύ, bandwidth, οθόνη). Οι προδιαγραφές του WTLS περιγράφουν επίσης ορισμένες διαφοροποιήσεις για την πιο αποδοτική λειτουργία του συστήματος (π.χ. συμπίεση Πιστοποιητικών, υιοθέτηση κρυπτο-αλγορίθμων βασισμένων σε ελλειπτικές καμπύλες κλπ) Στο WAP 2.0 (σήμερα) επικοινωνία μεταξύ συσκευής και web server μπορεί να είναι προστατευμένη από άκρη σε άκρη (end-to-end) με το WTLS. Web Server Internet Gateway

Εφαρμογή Νο 5 ΙΕΕΕ 802.11i (Ασύρματα Τοπικά Δίκτυα) Οι δυνατότητες του πρωτοκόλλου TLS για εδραίωση κλειδιού με αμοιβαία αυθεντικοποίηση, προβλέπονται στα πλαίσια του τρέχοντος προτύπου 802.11i για ασφαλή ασύρματα τοπικά δίκτυα Wi-Fi. Τυπικά, ο πελάτης και ένας server αυθεντικοποίησης ανταλλάσσουν τα πιστοποιητικά τους και εδραιώνουν ένα κλειδί συνόδου, σύμφωνα με το πρωτόκολλο TLS. Κατόπιν, ο server προωθεί το κλειδί συνόδου στον σταθμό βάσης, ενώ εν συνεχεία η επικοινωνία του client και του σταθμού θα προστατεύεται από το συμμετρικό κλειδί που εδραιώθηκε. Mobile client Radius Authentication Server Enterprise network Εδραίωση Κλειδιού σε WLANS (EAP-TLS)

4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού 4. Α 4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού 4.Α. Μεταφορά Κλειδιού - Πρωτόκολλο Π16 Πρωτόκολλο Π16 -Μεταφορά κλειδιού με αυθεντικοποίηση οντότητας [23]

4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού 4. Α 4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού 4.Α. Μεταφορά Κλειδιού - Πρωτόκολλο Π17 Πρωτόκολλο Π17 -Μεταφορά κλειδιού με αυθεντικοποίηση οντότητας [23] (ISO/IEC 11770-3, 1999)

4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού 4. Α 4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού 4.Α. Μεταφορά Κλειδιού - Πρωτόκολλο Π18 Πρωτόκολλο Π18 -Μεταφορά κλειδιού με αμοιβαία αυθεντικοποίηση [33]

4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού 4. B Πρωτόκολλο Π19-Συμφωνία κλειδιού με αμοιβαία αυθεντικοποίηση [35] (Needham & Schroeder, 1978) ΚS = Hash(kA, kB)

4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού 4. B Πρωτόκολλο Π20 - Τροποποίηση του πρωτοκόλλου Π19 [33]

4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού 4. B Πρωτόκολλο Π21 - Παραλλαγή του πρωτοκόλλου Needham-Schroeder [35] (Needham & Schroeder, 1978)

4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού 4. B Πρωτόκολλο Π22 - Μια απλοποίηση του Π21 [35] (Needham & Schroeder, 1978)

4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού 4. B Στο δεύτερο βήμα, αν ο Bob εισήγαγε στην κρυπτογράφηση το μήνυμα: ¨Β,Α¨ - δηλαδή: είμαι ο Bob και θέλω να μιλήσω με την Alice, η επίθεση δεν θα ήταν δυνατή. Επίθεση E4 - H επίθεση του Lowe στο πρωτόκολλο Π22 [30]

4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού 4. B 4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού 4.B. Συμφωνία Κλειδιού - Πρωτόκολλο Diffie-Hellman (Diffie &Hellman, 1976) Πρωτόκολλο Π23 - Το πρωτόκολλο Diffie-Hellman [15] Εφαρμογές: Ο αλγόριθμος και οι παραλλαγές του χρησιμοποιούνται σήμερα ευρέως σε δημοφιλείς εφαρμογές: π.χ. IPSec, SSH, SSL/TLS, …

John Hershey. Cryptography Demystified. McGraw-Hill Professional, 2003 Κρυπτογραφία Δημόσιου Κλειδιού To Πρωτόκολλο Diffie-Hellman – Ένα παράδειγμα Παράμετροι συστήματος p= 101, g=3 a=5 b=6 Όλες οι πράξεις γίνονται mod p g και p: Παράμετροι συστήματος ΓΝΩΣΤΕΣ ΣΕ ΟΛΟΥΣ

4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού 4. B Επίθεση E5 - Μία επίθεση ενδιάμεσης οντότητας (MITM) στο DH [30]

4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού 4. B 4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού 4.B. Συμφωνία Κλειδιού - To Πρωτόκολλο STS [16] Πρωτόκολλο Π24 - Το πρωτόκολλο Station to Station (STS) [16] (Diffie et al, 1981)

Εφαρμογή Νο 6: Virtual Private Networks (VPNs) IPSec - Το πρωτόκολλο IKE (Internet Key Exchange) m1 m2 A, (ga mod p) B, (gb mod p) Στα πλαίσια του προτύπου IPSEC (Internet Protocol SECurity) για την Ασφάλεια στο επίπεδο Δικτύου του μοντέλου TCP/IP, δύο δρομολογητές μπορούν να δημιουργήσουν ένα Ασφαλές Εικονικό Δίκτυο (VPN), εκτελώντας το πρωτόκολλο εδραίωσης IKE που αποτελεί μια παραλλαγή του πρωτοκόλλου εδραίωσης STS , SigB(m1,m2), CertB SigA(m1,m2), CertA A B

Εφαρμογή Νο 7: Secure Shell (SSH) Εδραίωση Κλειδιού στο πρωτόκολλο SSH SigB(m1,m2) A, (ga mod p) B, (gb mod p), A B m1 m2 Αυθεντικοποίηση χρήστη (π.χ. αποστολή password, κρυπτογραφημένου με το Ks) Ομοίως το Πρότυπο Secure Shell ή SSH, που επιτρέπει την ίδρυση ενός ασφαλούς καναλιού μεταξύ ενός τοπικού υπολογιστή και ενός απομακρυσμένου υπολογιστή (π.χ. Secure Telnet, Secure FTP), χρησιμοποιεί μια παραλλαγή του πρωτοκόλλου Diffie-Hellman για την εδραίωση ενός κλειδιού συνόδου Ks. Στο παράδειγμα μας, ο server αυθεντικοποιείται με τη χρήση ψηφιακής υπογραφής (υποτίθεται ότι ο client ήδη κατέχει το έγκυρο δημόσιο κλειδί του server). Αφού το κλειδί εδραιωθεί, ο client ταυτοποιείται αποστέλλοντας το password που του έχει εκχωρηθεί.

Εφαρμογή Νο 7: Bluetooth v. 2.1 Εδραίωση Κλειδιού στο Bluetooth Elliptic Curve Diffie-Hellman (ECDH) Key Exchange Let’s pair PKb Device A Device B PKa DHkeyA = aPKb DHkeyB = bPKa DHkeyA = aPKb = abG = baG = bPKa = DHkeyB http://www.aladdin.com/blog/pdf/AndrewLindell-BlackHat08.ppt

4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού 4. B Πρωτόκολλο Π25 - Το πρωτόκολλο εδραίωσης κλειδιού X.509 [34]

4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού 4. B Πρωτόκολλο Π26 - Το πρωτόκολλο Π25 με πρόκληση-απάντηση [34]

5. Προηγμένα Πρωτόκολλα Εδραίωσης H Οικογένεια Πρωτοκόλλων MTI [31] Πρωτόκολλο Π27 - To πρωτόκολλο συμφωνίας MTI/A0 [31] (Matsumoto et al, 1986)

5. Προηγμένα Πρωτόκολλα Εδραίωσης Το πρωτόκολλο ΕΚΕ (Encrypted Key Exchange) [7] Πρωτόκολλο Π29: Το πρωτόκολλο ΕΚΕ [7] (Bellovin and Merritt, 1992)

5. Προηγμένα Πρωτόκολλα Εδραίωσης Το πρωτόκολλο ΕΚΕ2 [3] 5. Προηγμένα Πρωτόκολλα Εδραίωσης Το πρωτόκολλο ΕΚΕ2 [3] Πρωτόκολλο Π30: Το πρωτόκολλο ΕΚΕ2 [3] (Bellare et al, 2000)

5. Προηγμένα Πρωτόκολλα Εδραίωσης Εδραίωση Κλειδιού Ομάδας στο DH (Ingemarsson et al, 1982) Πώς μπορούν 3 ή περισσότεροι χρήστες να συμφωνήσουν σε ένα κοινό κλειδί K … … Χρησιμοποιώντας το πρωτόκολλο DH; Κ Group Key Agreement Alice Bob Carol Carol

5. Προηγμένα Πρωτόκολλα Εδραίωσης Εδραίωση Κλειδιού Ομάδας στο DH (Ingemarsson et al, 1982) Πώς μπορούν 3 ή περισσότεροι χρήστες να συμφωνήσουν σε ένα κοινό κλειδί K … … Χρησιμοποιώντας το πρωτόκολλο DH; Κ Group Key Agreement Alice Bob Carol

5. Συνοψίζοντας Συμμετρικά Πρωτόκολλα vs Πρωτόκολλα ΔΚ Εδραίωση με Συμμετρικά Συστήματα ΥΠΕΡ Απόδοση (κόστος υπολογισμών, χωρητικότητας, αποθήκευσης) ΚΑΤΑ Απαιτούν προ-συμφωνημένα μυστι-κά (με άλλους κόμβους ή με το KDC) Διαχείριση κλειδιού σε συστήματα μεγάλης κλίμακας: Δύσκολη Εφαρμογή σε κατανεμημένα και δυναμικά περιβάλλοντα: Δύσκολη Στα συστήματα διανομής, το KDC αποτελεί μοναδικό σημείο αποτυχίας Εδραίωση με Συστήματα ΔΚ ΥΠΕΡ Δεν απαιτούν την ύπαρξη προ-εγκατεστημένων μυστικών, ούτε ενός πλήρως έμπιστου, online KDC Ιδανικά για συστήματα μεγάλης κλίμακας και δυναμικής τοπολογίας Μη αποποίηση ευθύνης (ψηφιακές υπογραφές) ΚΑΤΑ Απόδοση (κόστος υπολογισμών, χωρητικότητας, αποθήκευσης) Διαχείριση κλειδιού (Υποδομές δημόσιου κλειδιού- PKI) Εδραίωση με Συμμετρικά Συστήματα ΥΠΕΡ Απόδοση (μικρό μήκος κλειδιού, κόστος υπολογισμών, χωρητικότητας αποθήκευσης (σε bit)) ΚΑΤΑ Απαιτούν προ-εγκατεστημένα μυστικά (με άλλους κόμβους ή με το KDC) Διαχείριση κλειδιού (Πλήθος κλειδιών – O(n^2) keys need to be managed, πώς προ-εγκαθίστανται, που αποθηκεύονται, πώς ανανεώνονται κλπ) σε συστήματα μεγάλης κλίμακας: Δύσκολη / πολύπλοκη Στα συστήματα διανομής, το KDC αποτελεί μοναδικό σημείο αποτυχίας (σ.σ. Ένα κακόβουλο KDC μπορεί να παραβιάσει τη μυστικότητα των επικοινωνιών, αλλά και να πλαστοπροσωπήσει τους χρήστες του συστήματος) Δύσκολη εφαρμογή σε κατανεμημένα περιβάλλοντα (σ.σ. αποκεντρωμένα: π.χ. δεν υπάρχουν έμπιστες οντότητες, & όλοι οι κόμβοι του συστήματος έχουν το ίδιο επίπεδο εμπιστοσύνης) & δυναμικά περιβάλλοντα (π.χ. όπου η τοπολογία του δικτύου αλλάζει, ή/και εισέρχονται (εξέρχονται) κόμβοι στο (από το) σύστημα) Εδραίωση με Συστήματα ΔΚ Δεν απαιτούν την ύπαρξη προ-εγκατεστημένων μυστικών, ούτε ενός πλήρως έμπιστου, online KDC Ιδανικά για συστήματα μεγάλης κλίμακας και δυναμικής τοπολογίας (Λόγω χαμηλού κόστους διαχείρισης π.χ. Ο(n) keys need to be managed, επίσης η διάρκεια ζωής των δημόσιων κλειδιών είναι μεγαλύτερη) Απόδοση (μεγάλο μήκος κλειδιών - κόστος υπολογισμών, χωρητικότητας, αποθήκευσης) Διαχείριση κλειδιού (Υποδομές δημόσιου κλειδιού- PKI)

Εφαρμογές 86

A Classification of Threats on the Web * (Stallings, 2010)

Relative Location of Security Facilities in the TCP/IP Protocol Stack (Stallings, 2010), * * (Katz, 2010) Figure 14: illustrates this difference. One way to provide Web security is to use IP Security (Figure 14.1a). The advantage of using IPSec is that it is transparent to end users and applications and provides a general-purpose solution. Further, IPSec includes a filtering capability so that only selected traffic need incur the overhead of IPSec processing. Another relatively general-purpose solution is to implement security just above TCP (Figure 14.1b). The foremost example of this approach is the Secure Sockets Layer (SSL) and the follow-on Internet standard of SSL known as Transport Layer Security (TLS). At this level, there are two implementation choices. For full generality, SSL (or TLS) could be provided as part of the underlying protocol suite and therefore be transparent to applications. Alternatively, SSL can be embedded in specific packages. For example, Netscape and Microsoft Explorer browsers come equipped with SSL, and most Web servers have implemented the protocol. Ασφάλεια στο Επίπεδο Εφαρμογής (S/MIME, PGP, Kerberos,…) Σχεδιασμός εξειδικευμένων υπηρεσιών ασφάλειας (user-to-app) Ασφάλεια στο Επίπεδο «above TCP» (SSH, SSL/TLS) Ασφάλεια “end-to-end” (app-to-app) Ασφάλεια στο Επίπεδο IP (IPSec) Διαφάνεια, προστασία όλων των εφαρμογών, (host-to-host) Ασφάλεια στο Επίπεδο MAC (Data Link) (WPA, IEEE 802.11i,…) “hop-by-hop” security; WLAN & Cellular security (NIC-to-NIC) …

What Layer? For most implementations of IP stacks SSL/TLS (or SSH) (Basin, 2005) * (Kaufman, 2002) * For most implementations of IP stacks Transport layer and below implemented in operating system. Above transport layer implemented in user process. SSL/TLS (or SSH) OS doesn’t change, applications do. IPsec: OS changes. Applications unchanged.

Secure Socket Layer and Transport Layer Security (Stallings, 2010), * (Katz, 2010) * Goal: Reliable, end-to-end security Best for: Connection-oriented sessions User: Users not necessarily involved OS: Not necessarily modified App: Easy to modify apps to use SSL Current version: SSL v3, also known as TLS (Transport Layer Security): Internet Standard (RFC 5246) *

SSL Record Protocol * (Stallings, 2010) SSL Record provides two services for SSL connections: Confidentiality: Handshake defines a shared key for encrypting SSL payloads Message Integrity: Handshake defines a shared key for MAC

SSL Handshake Protocol * (Stallings, 2010)

SSL Handshake Protocol * (Stallings, 2010) Phase 1. Establish Security Capabilities Key exchange method (cipher suite) RSA key transfer: session key encryp-ted with receiver’s PK (cert is available) Fixed Diffie-Hellman: Cert contains DH public-key (fixed key) signed by CA Ephemeral Diffie-Hellman: sign (RSA or DSS) & send ephemeral DH keys Anonymous Diffie-Hellman: Use the base DH key agreement algorithm

SSL Handshake Protocol * (Stallings, 2010) Phase 2. Server Auth and Key Exchange Cert not required for anonymous DH Server_key_exchange not required if: Fixed DH (cert already contains key) RSA key transfer is to be used Server_key_exchange may be needed in: Anonymous DH: Send global values (p, g) and the server’s public DH key Ephemeral DH: the values above, signed with server’s private key RSA key transfer in which the server has a signature-only RSA key: Server creates a temporary key pair, then signs & sends pk (exponent & modulus) Signature also contains nonces so far:

SSL Handshake Protocol * (Stallings, 2010) Phase 3. Client Auth and Key Exchange Server may also ask a client cert (TLS) Content of client_key_exchange: RSA key transfer: Client generates a 48-byte pre_master_secret & encrypts with server’s public key Ephemeral or Anonymous DH: The client’s public DH parameters Fixed DH: content null (DH parameters were sent in the certificate message) Certificate_verify is sent only if client’s cert has a signing capability: Goal: prove possession of private key

SSL Handshake Protocol * (Stallings, 2010) Phase 4. Finish Completion of setting up a connection Finished message verifies that auth and key exchange were successful Concatenation of two hashes:

SSL Handshake Protocol * (Stallings, 2010) Master Secret Creation It is built upon a pre_master_secret, which, has already been built in 2 ways: RSA key transfer: pre_master is sent by client, encrypted with server’s pk Diffie-Hellman: pre_master_secret is the established DH key Both sides now compute master_secret: In TLS, master_secret is computed as:

SSL Handshake Protocol * (Stallings, 2010) Generation of Cryptographic Parameters CipherSpecs requires: A client write MAC secret A server write MAC secret A client write key and IV A server write key and IV How? Hash master_secret until enough output is generated:

Transport Layer Security (RFC 5246) (Brown, 2011) * * * (Stallings, 2010) Similar to SSLv3 with minor differences record format version number uses HMAC for MAC a different pseudo-random function has additional alert codes some changes in supported ciphers changes in certificate types & negotiations changes in crypto computations & padding

Transport Layer Security (RFC 5246) * * (Stallings, 2010)

HTTP Secure (HTTPS) HTTP over SSL/TLS (Stallings, 2010) * (Brown, 2011) * Motivation HTTP: subject to man-in-the-middle and eavesdropping attacks Goal Encrypted communication & iden-tification of (at least) Web server over an insecure network Solution Use ordinary HTTP over an SSL/TLS connection Documented in RFC 2818 HTTPS: a URI scheme URLs begin with https:// Use port 443 Used in: Payment transactions User access with passwords Secure mail, Corporate Intranet,… * * https://www.owasp.org/index.php/Man-in-the-middle_attack

HTTP Secure (HTTPS) HTTP over SSL/TLS (Stallings, 2010) * (Brown, 2011) * Information that HTTPS encrypts: URL, document contents, form data, cookies, HTTP headers The attacker can only know the fact that a connection takes place between two hosts with known domain names and IP addresses

HTTP Secure (HTTPS) HTTP over SSL/TLS (Stallings, 2010) * Client Authentication HTTPS can also be used for controlling access to a web server Admin builds a cert for each user Each user loads cert to browser Typically, the certificate contains name and e-mail address of user Other Issues Certificate revocability Browser should check whether a cert is still valid Implement Online Certificate Status Protocol (OCSP) Software security issues (Browser and Server) * (RFC 2560) *, *

Εφαρμογές Κινητή Τηλεφωνία: WAP & WTLS SSL Μια παραλλαγή του πρωτοκόλλου TLS τη συναντάμε σήμερα, ως WTLS (Wireless TLS) στο πρότυπο WAP (Wireless Application Protocol) για τη διασύνδεση χρηστών «κινητών» συσκευών σε υπηρεσίες του Web. Στα κινητά 2ης γενιάς, ο ρόλος της πύλης (Gateway) είναι κυρίως η λήψη του περιεχομένου προς/από τον Web server, και η προσαρμογή του στις ανάγκες της κινητής συσκευής (δηλ. μιας συσκευής με περιορισμένη ισχύ, bandwidth, οθόνη). Οι προδιαγραφές του WTLS περιγράφουν επίσης ορισμένες διαφοροποιήσεις για την πιο αποδοτική λειτουργία του συστήματος (π.χ. συμπίεση Πιστοποιητικών, υιοθέτηση κρυπτο-αλγορίθμων βασισμένων σε ελλειπτικές καμπύλες κλπ) Στο WAP 2.0 (σήμερα) επικοινωνία μεταξύ συσκευής και web server μπορεί να είναι προστατευμένη από άκρη σε άκρη (end-to-end) με το WTLS. Web Server Internet Gateway

Εφαρμογές ΙΕΕΕ 802.11i (Ασύρματα Τοπικά Δίκτυα) Οι δυνατότητες του πρωτοκόλλου TLS για εδραίωση κλειδιού με αμοιβαία αυθεντικοποίηση, προβλέπονται στα πλαίσια του τρέχοντος προτύπου 802.11i για ασφαλή ασύρματα τοπικά δίκτυα Wi-Fi. Τυπικά, ο πελάτης και ένας server αυθεντικοποίησης ανταλλάσσουν τα πιστοποιητικά τους και εδραιώνουν ένα κλειδί συνόδου, σύμφωνα με το πρωτόκολλο TLS. Κατόπιν, ο server προωθεί το κλειδί συνόδου στον σταθμό βάσης, ενώ εν συνεχεία η επικοινωνία του client και του σταθμού θα προστατεύεται από το συμμετρικό κλειδί που εδραιώθηκε. Mobile client Radius Authentication Server Enterprise network Εδραίωση Κλειδιού σε WLANS (EAP-TLS)

Secure Shell (SSH) * (Stallings, 2010) Initial version (SSH1) to replace TELNET & other insecure schemes Today, SSH provides a general client-server capability Remote login, file transfer, mail,… * Current version: SSH2 (RFCs 4250-4256) * Motivation: (old) Telnet sessions are unencrypted ! http://www.ibm.com/developerworks/aix/library/au-sshsecurity/

Secure Shell (SSH) Transport Layer Protocol * * A. Host Keys Server auth occurs here Server possesses public/private key pair Client must have a priori knowledge of the server’s public host key Two alternative trust models: Client has a local database that associates a host name with a pk Host name-to-key certified by a CA (client knows CA’s root key) * *

Secure Shell (SSH) Transport Layer Protocol * (Stallings, 2010) * B. Packet Exchange *

Secure Shell (SSH) Transport Layer Protocol (Stallings, 2010) * * B. Packet Exchange Steps of SSH Transport Layer Identification string exchange These strings are used in the DH key exchange later Algorithm negotiation Key exchange, encryption, MAC, compression Key exchange Diffie-Hellman key exchange *

Secure Shell (SSH) Transport Layer Protocol * (Stallings, 2010) * *

Secure Shell (SSH) Transport Layer Protocol – DH Key Exchange (Stallings, 2010) * * *

Secure Shell (SSH) Transport Layer Protocol (Stallings, 2010) * * Subsequent to DH key exchange, all data is exchanged as the pay-load of an SSH packet, protected by encryption and MAC C. Key Generation All needed keying material is gene-rated from established DH key: *

Secure Shell (SSH) User Authentication Protocol (Stallings, 2010) * * Three authentication methods: Public-key: Client sends a public key and a signature on a message Typically , user supplies a pass-phrase to decrypt signature key Password: Client sends password, encrypted by TLP Host-based: Host locally authenti-cates (multiple) user(s), then signs a message with host’s private key

Secure Shell (SSH) Connection Protocol (Stallings, 2010) * * Assumes a secure authenti-cation connection (tunnel) Uses the tunnel to multiplex a number of logical channels All types of SSH communica-tion use separate channels Either side may open a channel with unique id number Channels are flow controlled using a window mechanism http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch03_05.htm

Secure Shell (SSH) Connection Protocol (Stallings, 2010) * * Life of a channel has 3 stages: Opening a channel, Data transfer, Closing a channel

Secure Shell (SSH) Connection Protocol (Stallings, 2010) * * Channel types: Session Remote execution of a program (shell, file transfer, mail, …) Local port forwarding SSH client “listens” and intercepts selected app-level traffic and redirects it to SSH tunnel Examples: POP3, SMTP, HTTP,… Remote port forwarding Tunnel initiated on server side, goes back through client machine Port forwarding services are also known as SSH tunneling *

Secure Shell (SSH) Local Port Forwarding Case: Use a local mail client to get mail from mailserver via POP3 Secure Shell (SSH) Local Port Forwarding (Stallings, 2010) * *, *, * * Unprotected session

Secure Shell (SSH) Remote Port Forwarding Case: You wish to access a server at work from home (server is behind a firewall) (Stallings, 2010) * *, *, *

Internet Protocol Security (IPsec) (Stallings, 2010) * Motivation An enterprise can run a secure, private network over Internet Encrypt packets that leave/enter the premises Authenticate packets that leave/enter the premises Security at the IP level Protect all apps (with or without security mechanisms!) Transparent to end users

IPsec Applications of IPsec Branch connectivity Secure remote access (Stallings, 2010) * Applications of IPsec Branch connectivity Company builds a secure VPN over Internet or public WAN Secure remote access User calls local ISP & gains secure access to company network Extranet & Intranet connectivity Secure communication with other organizations and/or other depart-ments within enterprise http://www.digi-cube.com/images/client2network_vpn.gif

Figure 8. 1is a typical scenario of IPsec usage Figure 8.1is a typical scenario of IPsec usage.An organization maintainsLANs at dispersed locations.Nonsecure IP traffic is conducted on each LAN.Fortraffic offsite,through some sort of private or public WAN,IPsec protocols are used.These protocols operate in networking devices,such as a router or firewall,that con-nect each LAN to the outside world.The IPsec networking device will typicallyencrypt and compress all traffic going into the WAN and decrypt and decompresstraffic coming from the WAN;these operations are transparent to workstations andservers on the LAN.Secure transmission is also possible with individual users whodial into the WAN.Such user workstations must implement the IPsec protocols toprovide security

IPsec Rooting Applications IPsec can assure that: (Stallings, 2010) * Rooting Applications IPsec can assure that: A router advertisement comes from an authorized router A neighbor advertisement comes from an authorized router A redirect message comes from a router to which packet was sent A routing update is not forged * (Stallings, 1996) * http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094e9e.shtml

To πρότυπο IPsec IPsec Services AH and ESP support two modes: (Stallings, 2010) * IPsec Services Access Control Connectionless integrity Data origin authentication Rejection of replay packets Confidentiality Traffic flow confidentiality Two (2) protocols are used: AH (Authentication Header) Authentication & Integrity ESP (Encapsulation Sec. Payload) Confidentiality (& optional authentication / integrity) * (RFC 4301) Το πρότυπο IPSEC. Το IP Security είναι ένα σύνολο πρωτοκόλλων επιπέδου Δικτύου (επίπεδο 3 στο μοντέλο TCP/IP). Αυτό σημαίνει πως μπορεί να προστατεύσει οποιαδήποτε ροή δεδομένων (πρωτόκολλα και εφαρμογές) ανώτερων επιπέδων. Σήμερα αποτελεί πρότυπο (standard) για την υλοποίηση κρυπτογραφικών μηχανισμών σε δρομολογητές και firewalls για τη διασύνδεση τοπικών δικτύων (LAN), δικτύων ευρείας περιοχής (WAN), καθώς και σε απομακρυσμένους hosts που διασυνδέονται μέσω δικτύων TCP/IP. Μπορεί να εφαρμοστεί (προαιρετικά) στο πρωτόκολλο Ipv4, ενώ υποχρεωτικά συμπεριλαμβάνεται στις προδιαγραφές του επερχόμενου Ipv6 (Internet Protocol version 6) Συγκεκριμένα, το Ipsec προσφέρει υπηρεσίες Ακεραιότητας (integrity) – «είναι το πακέτο IP που έλαβα αυτό που μου έστειλαν?», Αυθεντικότητας (authentication) – «Ποιος μου έστειλε το πακέτο IP?» και Εμπιστευτικότητας (confidentiality) - «Μόνον εγώ μπορώ να δω τα περιεχόμενα του πακέτου IP που μου έστειλαν?», στο επίπεδο Δικτύου. Το IPSEC μπορεί να εκτελεστεί σε δύο διακριτές λειτουργίες: Σε λειτουργία μεταφοράς (transport mode), το IPSEC διασφαλίζει αποκλειστικά τα δεδομένα (payload) του πακέτου IP, και όχι την επικεφαλίδα του πακέτου (η οποία χρησιμοποιείται απλά για τη δρομολόγηση του πακέτου στον παραλήπτη). Οι υπηρεσίες ασφάλειας που προσφέρονται εξαρτώνται από το πρωτόκολλο που υλοποιεί το IPSEC (ΑΗ ή/και ESP). To IPSEC σε λειτουργία μεταφοράς χρησιμοποιείται συνήθως για την (end to end) σύνδεση μεταξύ client-server, ή μεταξύ client-client. Σε λειτουργία tunnel (tunnel mode), το IPSEC διασφαλίζει ολόκληρο το πακέτο IP, δηλαδή επικεφαλίδα και δεδομένα. Στη συνέχεια προστίθεται μια επιπλέον επικεφαλίδα IP, για τη δομολόγηση του πακέτου. Οι υπηρεσίες ασφάλειας που προσφέρονται σε λειτουργία tunnel, εξαρτώνται από το πρωτόκολλο που υλοποιεί το IPSEC (ΑΗ ή/και ESP). To IPSEC σε λειτουργία tunnel χρησιμοποιείται συνήθως για την (end to end) σύνδεση μεταξύ δύο δρομολογητών-firewalls, στα πλαίσια ενός Εικονικού Ιδιωτικού δικτύου VPN. Το IPSec δεν είναι ένα απλό πρωτόκολλο. Αποτελείται από δύο βασικά κρυπτογραφικά πρωτόκολλα ασφαλείας για το IP, τα οποία μπορούν να υλοποιηθούν μαζί ή ξεχωριστά: Επικεφαλίδα Αυθεντικότητας IP (ΑΗ - Αuthentication Header). Όπως προδίδει και το όνομα του, το πρωτόκολλο αυτό εξασφαλίζει την αυθεντικότητα του αποστολέα και την ακεραιότητα του περιεχομένου ενός πακέτου IP. Ανάλογα με τo mode λειτουργίας (transport ή tunnel), το ΑΗ προσθέτει μια επικεφαλίδα στο πακέτο IP (ΑΗ header) η οποία π.χ. περιέχει έναν κώδικα MAC των δεδομένων του αρχικού πακέτου (transport), ή ένα MAC ολόκληρου του αρχικού πακέτου IP (tunnel: δεδομένα και επικεφαλίδα). Το ΑΗ δεν προσφέρει εμπιστευτικότητα της επικοινωνίας. Ενθυλάκωση Δεδομένων IP (ESP- Encapsulating Security Payload). Το πρωτόκολλο εξασφαλίζει την εμπιστευτικότητα των περιεχομένων ενός πακέτου IP. Σε λειτουργία transport, κρυπτογραφούνται μόνον τα δεδομένα που ακολουθούν την επικεφαλίδα του πακέτου (το “payload” του πακέτου), ενώ σε λειτουργία tunnel κρυπτογραφείται ολόκληρο το πακέτο IP. Προαιρετικά, το ESP προσφέρει τη δυνατότητα ψηφιακής υπογραφής των δεδομένων (payload) του πακέτου, διασφαλίζοντας έτσι και την ακεραιότητα και αυθεντικότητα του πακέτου, σε λειτουργία transport (transport mode), ή tunnel (tunnel mode). Περίπτωση: VPN σε λειτουργία Tunnel. Το IPSEC διασφαλίζει την επικοινωνία IP μεταξύ δύο ενδιάμεσων κόμβων. Οι κόμβοι αυτοί είναι συνήθως δύο (απομακρυσμένοι) δρομολογητές που επιχειρούν να συνδεθούν με ασφαλή σύνδεση (από άκρη σε άκρη – end-to-end) με σκοπό τη δημιουργία ενός Εικονικού Ιδιωτικού Δικτύου (VPN). Σε tunnel mode, το IPSEC που εκτελείται σε έναν δρομολογητή δέχεται ως είσοδο ένα πακέτο IP που προέρχεται από κάποιον host του δικτύου, και στη συνέχεια δημιουργεί ένα καινούριο πακέτο: Στο πεδίο των δεδομένων ενθυλακώνει ολόκληρο το πακέτο IP που έλαβε, αφού πρώτα το διασφαλίσει (εφαρμόζοντας το μηχανισμό AH ή ESP). Στη συνέχεια προσθέτει μια IP επικεφαλίδα (header) στην οποία φαίνεται ως αποστολέας ο δρομολογητής του δικτύου, και ως παραλήπτης ο έτερος δρομολογητής), ώστε το πακέτο να δρομολογηθεί κανονικά μέσω του δικτύου. Σε αντίθεση με τη λειτουργία transport, η λειτουργία tunnel είναι εντελώς διαφανής (transparent) στους τελικούς χρήστες. Εικονικά Ιδιωτικά Δίκτυα (Virtual Private Networks – VPNs). Εκτός από τη διασύνδεση δικτύων Το IPSec υποστηρίζει την ασφαλή επικοινωνία μεταξύ δύο hosts (host-to-host), μεταξύ LAN (lan-to-lan), καθώς και συνδέσεις (user-to-LAN) όπου ο απομακρυσμένος χρήστης μπορεί να συνδεθεί ασφαλώς στο περιβάλλον του τοπικού δικτύου. Ένα δίκτυο VPN περιλαμβάνει ένα σύνολο από τεχνολογίες που επιτρέπουν την ασφαλή επικοινωνία διαμέσου μη ασφαλών δικτύων όπως είναι το Internet και τα δημόσιο τηλεφωνικά δίκτυα. Η ασφάλεια ενός δίκτυου VPN δεν επιτυγχάνεται με μισθωμένες γραμμές (leased lines) όπως συμβαίνει σε ένα Ιδιωτικό Δίκτυο Private Network, αλλά με κρυπτογραφικούς μηχανισμούς ασφάλειας που επιτρέπουν μόνον σε εξουσιοτημένες οντότητες την πρόσβαση σε εμπιστευτικά δεδομένα. Έτσι, για παράδειγμα, ένας απομακρυσμένος client με εγκατεστημένο λογισμικό VPN μπορεί να συνδεθεί σε έναν server (VPN-enabled), και να εκτελέσει οποιαδήποτε λειτουργία (π.χ. telnet, mail, κοινή χρήση αρχείων, κ.λ.π), καθώς η επικοινωνία θα προστατεύεται από το IPSEC. Αυτό έρχεται σε αντίθεση με άλλες τεχνολογίες (π.χ. OpenSSH, SSL, οι οποίες επειδή ανήκουν σε υψηλότερα επίπεδα, μπορούν να προστατέψουν συγκεκριμένες εφαρμογές και πρωτόκολλα). Σημείωση: Τo IPSEC εξ’ ορισμού (default) χρησιμοποιεί συμμετρικές κρυπτογραφικές τεχνικές: Αλγόριθμους Hash για ακεραιότητα, Κώδικες Αυθεντικότητας (MAC) για αυθεντικότητα, και συμμετρικούς αλγόριθμους κρυπτογράφησης για εμπιστευτικότητα. * (Heidari, 2004) AH and ESP support two modes: Transport mode Only protect IP packet payload (protect upper layer protocol) Case: E2E between 2 hosts Tunnel mode Protects the entire IP packet Case: A number of endnodes (without IPsec installation) on networks between firewalls Case2: endnode to firewall * * 123

To πρότυπο IPsec (Stallings, 2010) *

IPsec Architecture (Stallings, 2010) * Security Associations A key concept that appears in both the authentication and confidentiality mecha-nisms for IP is the security association (SA).An association is a one-way logical con-nection between a sender and a receiver that affords security services to the traffic carried on it. If a peer relationship is needed for two-way secure exchange, then two security associations are required. Security services are afforded to an SA for the use of AH or ESP, but not both. A security association is uniquely identified by three parameters. Security Parameters Index (SPI): A bit string assigned to this SA and havinglocal significance only.The SPI is carried in AH and ESP headers to enable thereceiving system to select the SA under which a received packet will beprocessed.• IP Destination Address: This is the address of the destination endpoint of theSA,which may be an end-user system or a network system such as a firewall orrouter. Security Protocol Identifier: This field from the outer IP header indicateswhether the association is an AH or ESP security association.Hence,in any IP packet,the security association is uniquely identified by theDestination Address in the IPv4 or IPv6 header and the SPI in the enclosed exten-sion header (AH or ESP). ----------------- Security Association Database In each IPsec implementation,there is a nominal Security Association Databasethat defines the parameters associated with each SA.A security association is nor-mally defined by the following parameters in an SAD entry. Security Parameter Index: A 32-bit value selected by the receiving end of anSA to uniquely identify the SA.In an SAD entry for an outbound SA,the SPIis used to construct the packet’s AH or ESP header.In an SAD entry for aninbound SA,the SPI is used to map traffic to the appropriate SA.• Sequence Number Counter: A 32-bit value used to generate the SequenceNumber field in AH or ESP headers,described in Section 8.3(required for allimplementations).• Sequence Counter Overflow: A flag indicating whether overflow of theSequence Number Counter should generate an auditable event and preventfurther transmission of packets on this SA (required for all implementations).• Anti-Replay Window: Used to determine whether an inbound AH or ESPpacket is a replay,described in Section 8.3(required for all implementations).• AH Information: Authentication algorithm, keys, key lifetimes,and relatedparameters being used with AH (required for AH implementations).• ESP Information: Encryption and authentication algorithm,keys,initializa-tion values,key lifetimes,and related parameters being used with ESP(required for ESP implementations).• Lifetime of this Security Association: A time interval or byte count afterwhich an SA must be replaced with a new SA (and new SPI) or terminated,plus an indication of which of these actions should occur (required for allimplementations). IPsec Protocol Mode: Tunnel,transport,or wildcard. Path MTU: Any observed path maximum transmission unit (maximum sizeof a packet that can be transmitted without fragmentation) and agingvariables (required for all implementations). --------------------------- Security Policy Database The means by which IP traffic is related to specific SAs (or no SA in the case of trafficallowed to bypass IPsec) is the nominal Security Policy Database (SPD).In its sim-plest form,an SPD contains entries,each of which defines a subset of IP traffic andpoints to an SA for that traffic.In more complex environments,there may be multipleentries that potentially relate to a single SA or multiple SAs associated with a singleSPD entry.The reader is referred to the relevant IPsec documents for a full discussion.Each SPD entry is defined by a set of IP and upper-layer protocol field values, called selectors.In effect,these selectors are used to filter outgoing traffic in order tomap it into a particular SA.Outbound processing obeys the following general sequence for each IP packet. 1. Compare the values of the appropriate fields in the packet (the selector fields)against the SPD to find a matching SPD entry,which will point to zero ormoreSAs. 2.Determine the SA if any for this packet and its associated SPI. 3.Do the required IPsec processing (i.e.,AH or ESP processing). The following selectors determine an SPD entry: Remote IP Address:This may be a single IP address,an enumerated list or rangeof addresses,or a wildcard (mask) address.The latter two are required to supportmore than one destination system sharing the same SA (e.g.,behind a firewall).• Local IP Address:This may be a single IP address,an enumerated list or rangeof addresses,or a wildcard (mask) address.The latter two are required to sup-port more than one source system sharing the same SA (e.g.,behind a firewall).• Next Layer Protocol:The IP protocol header (IPv4,IPv6,or IPv6 Extension)includes a field (Protocol for IPv4,Next Header for IPv6 or IPv6 Extension)that designates the protocol operating over IP.This is an individual protocolnumber,ANY,or for IPv6 only,OPAQUE.If AH or ESP is used,then this IPprotocol header immediately precedes the AH or ESP header in the packet. Name:A user identifier from the operating system.This is not a field in the IPor upper-layer headers but is available if IPsec is running on the same operat-ing system as the user.• Local and Remote Ports:These may be individual TCP or UDP port values,an enumerated list of ports,or a wildcard port.

IPsec Architecture (Stallings, 2010) * Just as firewalls are configured with tables telling them what type of traffic to allow based on information such as IP header src and dest addresses and TCP ports, IPsec is assumed to have access to a similar database specifying which types of packets should be dropped completely, which should be forwarded or accepted without IPsec protection, and which should be protected by IPsec, and if protected, whether they should be encrypted and/or integrity proteted Table 8.2 provides an example of an SPD on a host system (as opposed to anetwork system such as a firewall or router).This table reflects the following config-uration:A local network configuration consists of two networks. The basic corporate network configuration has the IP network number 1.2.3.0/24.The local configuration also includes a secure LAN,often known as a DMZ,that is identified as1.2.4.0/24.The DMZ is protected from both the outside world and the rest of thecorporate LAN by firewalls.The host in this example has the IP address 1.2.3.10,and it is authorized to connect to the server 1.2.4.10 in the DMZ.The entries in the SPD should be self-explanatory.For example,UDP port 500is the designated port for IKE.Any traffic from the local host to a remote host forpurposes of an IKE exchange bypasses the IPsec processing.

IPsec Architecture (Stallings, 2010) * IP Traffic Processing IPsec is executed on a packet-by-packet basis. When IPsec is implemented,each outbound IP packet is processed by the IPsec logic before transmission,and each inbound packet is processed by the IPsec logic after reception and before passing the packet contents on to the next higher layer (e.g.,TCP or UDP).We look at the logic of these two situations in turn. OUTBOUND P ACKETS  Figure 8.3highlights the main elements of IPsec processing foroutbound traffic.A block of data from a higher layer,such as TCP,is passed down tothe IP layer and an IP packet is formed,consisting of an IP header and an IP body.Then the following steps occur: 1. IPsec searches the SPD for a match to this packet. 2. If no match is found,then the packet is discarded and an error message isgenerated. 3. If a match is found,further processing is determined by the first matchingentry in the SPD.If the policy for this packet is DISCARD,then the packet isdiscarded.If the policy is BYPASS,then there is no further IPsec processing;the packet is forwarded to the network for transmission. 4. If the policy is PROTECT,then a search is made of the SAD for a matchingentry.If no entry is found,then IKE is invoked to create an SA with the appro-priate keys and an entry is made in the SA. 5. The matching entry in the SAD determines the processing for this packet.Either encryption,authentication,or both can be performed,and eithertransport or tunnel mode can be used.The packet is then forwarded to thenetwork for transmission.

IPsec Architecture (Stallings, 2010) * INBOUND P ACKETS   INBOUND P ACKETS  Figure 8.4 highlights the main elements of IPsec processing forinbound traffic.An incoming IP packet triggers the IPsec processing.The following steps occur: 1. IPsec determines whether this is an unsecured IP packet or one that has ESP or AH headers/trailers,by examining the IP Protocol field (IPv4) orNext Header field (IPv6). 2. If the packet is unsecured, IPsec searches the SPD for a match to this packet. If the first matching entry has a policy of BYPASS,the IP header is processed and stripped off and the packet body is delivered to the next higher layer,suchas TCP.If the first matching entry has a policy of PROTECT or DISCARD,or if there is no matching entry, the packet is discarded. 3. For a secured packet, IPsec searches the SAD. If no match is found,the packet is discarded.Otherwise,IPsec applies the appropriate ESP or AH processing.Then,the IP header is processed and stripped off and the packet body is delivered to the next higher layer, such as TCP.

Encapsulating Security Payload (ESP) (Stallings, 2010) * ESP Format Figure 8.5ashows the top-level format of an ESP packet.It contains the following fields.• Security Parameters Index (32 bits): Identifies a security association, enables the receiving system to select the SA under which a received packet will be processed (e.g., look up the cryptographic keys, algorithms, ect) from her SA database. The SPI value is chosen by the destination. Sequence Number (32 bits): A monotonically increasing counter value;thisprovides an anti-replay function,as discussed for AH.• Payload Data (variable): This is a transport-level segment (transport mode)or IP packet (tunnel mode) that is protected by encryption.• Padding (0–255 bytes): The purpose of this field is discussed later.• Pad Length (8 bits): Indicates the number of pad bytes immediately precedingthis field.• Next Header (8 bits): Identifies the type of data contained in the payload datafield by identifying the first header in that payload (for example,an extensionheader in IPv6,or an upper-layer protocol such as TCP). Integrity Check Value (variable): A variable-length field (must be an integralnumber of 32-bit words) that contains the Integrity Check Value computedover the ESP packet minus the Authentication Data field. Encryption and Authentication Algorithms The Payload Data,Padding,Pad Length,and Next Header fields are encrypted bythe ESP service.If the algorithm used to encrypt the payload requires crypto-graphic synchronization data,such as an initialization vector (IV),then these datamay be carried explicitly at the beginning of the Payload Data field.If included,anIV is usually not encrypted,although it is often referred to as being part of theciphertext.The ICV field is optional.It is present only if the integrity service is selectedand is provided by either a separate integrity algorithm or a combined mode algo-rithm that uses an ICV.The ICV is computed after the encryption is performed.Thisorder of processing facilitates rapid detection and rejection of replayed or boguspackets by the receiver prior to decrypting the packet,hence potentially reducing the impact of denial of service (DoS) attacks.It also allows for the possibility of par-allel processing of packets at the receiver,i.e.,decryption can take place in parallelwith integrity checking.Note that because the ICV is not protected by encryption,akeyed integrity algorithm must be employed to compute the ICV.

Encapsulating Security Payload (ESP) Transport and Tunnel mode (Stallings, 2010) * Transport and Tunnel Modes Figure 8.7shows two ways in which the IPsec ESP service can be used.In the upperpart of the figure,encryption (and optionally authentication) is provided directlybetween two hosts.Figure 8.7bshows how tunnel mode operation can be used to setup a virtual private network .In this example,an organization has four privatenetworks interconnected across the Internet.Hosts on the internal networks use theInternet for transport of data but do not interact with other Internet-based hosts.Byterminating the tunnels at the security gateway to each internal network,the configu-ration allows the hosts to avoid implementing the security capability.The formertechnique is supported by a transport mode SA,while the latter technique uses atunnel mode SA

ESP Transport and Tunnel modes (Stallings, 2010) * Transport mode Confidentiality & integrity for any app (no need to implement confidentiality in an app separately) Traffic analysis on transmitted packets ! Tunnel mode Counter traffic analysis Simplifies key distribution T RANSPORT M ODE ESP  Transport mode ESP is used to encrypt and optionallyauthenticate the data carried by IP (e.g.,a TCP segment),as shown in Figure 8.8b For this mode using IPv4,the ESP header is inserted into the IP packet immediately prior to the transport-layer header (e.g.,TCP,UDP,ICMP), and an ESP trailer (Padding,Pad Length,and Next Header fields) is placed after the IP packet.If authentication is selected,the ESP Authentication Data field is added after the ESP trailer.The entire transport-level segment plus the ESP trailer are encrypted. Authentication covers all of the ciphertext plus the ESP header. Transport mode operation may be summarized as follows. 1. At the source,the block of data consisting of the ESP trailer plus the entiretransport-layer segment is encrypted and the plaintext of this block is replacedwith its ciphertext to form the IP packet for transmission.Authentication isadded if this option is selected. 2. The packet is then routed to the destination.Each intermediate router needs toexamine and process the IP header plus any plaintext IP extension headers butdoes not need to examine the ciphertext. 3. The destination node examines and processes the IP header plus any plaintextIP extension headers.Then,on the basis of the SPI in the ESP header,thedestination node decrypts the remainder of the packet to recover the plaintexttransport-layer segment. Transport mode operation provides confidentiality for any application thatuses it,thus avoiding the need to implement confidentiality in every individualapplication.One drawback to this mode is that it is possible to do traffic analysis onthe transmitted packets. -------------------------------- T UNNEL M ODE ESP  Tunnel mode ESP is used to encrypt an entire IP packet(Figure8.8c).For this mode,the ESP header is prefixed to the packet and thenthepacket plus the ESP trailer is encrypted.This method can be used to countertraffic analysis. Because the IP header contains the destination address and possibly sourcerouting directives and hop-by-hop option information,it is not possible simply totransmit the encrypted IP packet prefixed by the ESP header.Intermediate routerswould be unable to process such a packet.Therefore,it is necessary to encapsulatethe entire block (ESP header plus ciphertext plus Authentication Data,if present)with a new IP header that will contain sufficient information for routing but not fortraffic analysis. Whereas the transport mode is suitable for protecting connections betweenhosts that support the ESP feature,the tunnel mode is useful in a configuration thatincludes a firewall or other sort of security gateway that protects a trusted networkfrom external networks.In this latter case,encryption occurs only between an exter-nal host and the security gateway or between two security gateways.This relieves hosts on the internal network of the processing burden of encryption and simplifiesthe key distribution task by reducing the number of needed keys.Further,it thwarts traffic analysis based on ultimate destination. Consider a case in which an external host wishes to communicate with a host on an internal network protected by a firewall,and in which ESP is implemented in the external host and the firewalls.The following steps occur for transfer of a trans-port-layer segment from the external host to the internal host. 1. The source prepares an inner IP packet with a destination address of thetarget internal host.This packet is prefixed by an ESP header;then thepacket and ESP trailer are encrypted and Authentication Data maybeadded.The resulting block is encapsulated with a new IP header (baseheader plus optional extensions such as routing and hop-by-hop options forIPv6) whose destination address is the firewall;this forms the outer IPpacket. 2. The outer packet is routed to the destination firewall.Each intermediaterouter needs to examine and process the outer IP header plus any outer IPextension headers but does not need to examine the ciphertext. 3. The destination firewall examines and processes the outer IP header plusany outer IP extension headers.Then,on the basis of the SPI in the ESPheader,the destination node decrypts the remainder of the packet torecover the plaintext inner IP packet.This packet is then transmitted in theinternal network. 4. The inner packet is routed through zero or more routers in the internalnetwork to the destination host. Figure 8.9shows the protocol architecture for the two modes.

Encapsulating Security Payload (ESP) Transport and Tunnel mode (Stallings, 2010) *

ESP & AH Transport Packet layout IP Header ESP Header Payload (TCP, UDP, etc) Filtering unencrypted IP traffic in Firewalls/Routers --------------------------------------------------------- Note2: If everything beyond the IP header is encrypted (as it would be, with ESP), then firewalls and routers are not able to look at fields such as layer 4 ports in order to do packet filtering, content screening, ect (only IPsec source and destination nodes would know). This is considered another feature where AH is better than ESP. Tunnel Packet layout IP Header ESP Header IP Header Payload (TCP. UDP,etc) Απροστάτευτο Προστατευμένο Note: In transport mode, AH is better than ESP with authentication, since AH also provides integrity protection for some fields inside the IP header (although this can also be offered by ESP tunnel mode)

Ipsec - Combining Security Associations (Stallings, 2010) * An individual SA can implement either the AH or ESP protocol but not both.Sometimes a particular traffic flow will call for the services provided by both AHand ESP.Further,a particular traffic flow may require IPsec services between hostsand,for that same flow,separate services between security gateways,such as fire-walls.In all of these cases,multiple SAs must be employed for the same traffic flowto achieve the desired IPsec services.The term  security association bundle refers to a sequence of SAs through which traffic must be processed to provide a desired set of IPsec services.The SAs in a bundle may terminate at different endpoints or at thesame endpoints. Security associations may be combined into bundles in two ways: Transport adjacency: Refers to applying more than one security protocol tothe same IP packet without invoking tunneling.This approach to combiningAH and ESP allows for only one level of combination;further nesting yieldsno added benefit since the processing is performed at one IPsec instance:the(ultimate) destination. Iterated tunneling: Refers to the application of multiple layers of securityprotocols effected through IP tunneling.This approach allows for multiplelevels of nesting,since each tunnel can originate or terminate at a differentIPsec site along the path The two approaches can be combined,for example,by having a transport SAbetween hosts travel part of the way through a tunnel SA between security gateways. One interesting issue that arises when considering SA bundles is the order inwhich authentication and encryption may be applied between a given pair of endpointsand the ways of doing so.We examine that issue next.Then we look at combinations of SAs that involve at least one tunnel. Authentication Plus Confidentiality Encryption and authentication can be combined in order to transmit an IP packetthat has both confidentiality and authentication between hosts.We look at severalapproaches. ESP WITH AUTHENTICATION OPTION  This approach is illustrated in Figure 8.8.Inthis approach,the user first applies ESP to the data to be protected and thenappends the authentication data field.There are actually two subcases: Transport mode ESP: Authentication and encryption apply to the IP payloaddelivered to the host,but the IP header is not protected. Tunnel mode ESP: Authentication applies to the entire IP packet deliveredtothe outer IP destination address (e.g.,a firewall),and authentication isperformed at that destination.The entire inner IP packet is protected by theprivacy mechanism for delivery to the inner IP destination.For both cases,authentication applies to the ciphertext rather than the plaintext. T RANSPORT ADJACENCY  Another way to apply authentication after encryption is touse two bundled transport SAs,with the inner being an ESP SA and the outer beingan AH SA.In this case,ESP is used without its authentication option.Because theinner SA is a transport SA,encryption is applied to the IP payload.The resultingpacket consists of an IP header (and possibly IPv6 header extensions) followed by anESP.AH is then applied in transport mode,so that authentication covers the ESP plusthe original IP header (and extensions) except for mutable fields.The advantage of this approach over simply using a single ESP SA with the ESP authentication optionis that the authentication covers more fields,including the source and destination IPaddresses.The disadvantage is the overhead of two SAs versus one SA. T RANSPORT -T UNNEL BUNDLE  The use of authentication prior to encryption mightbe preferable for several reasons.First,because the authentication data areprotected by encryption,it is impossible for anyone to intercept the message andalter the authentication data without detection.Second,it may be desirable to storethe authentication information with the message at the destination for laterreference.It is more convenient to do this if the authentication information appliesto the unencrypted message;otherwise the message would have to be reencryptedto verify the authentication information. One approach to applying authentication before encryption between twohosts is to use a bundle consisting of an inner AH transport SA and an outer ESPtunnel SA.In this case,authentication is applied to the IP payload plus the IPheader (and extensions) except for mutable fields.The resulting IP packet is thenprocessed in tunnel mode by ESP;the result is that the entire,authenticated innerpacket is encrypted and a new outer IP header (and extensions) is added. Basic Combinations of Security Associations The IPsec Architecture document lists four examples of combinations of SAs thatmust be supported by compliant IPsec hosts (e.g.,workstation,server) or securitygateways (e.g.firewall,router).These are illustrated in Figure 8.10.The lower part of each case in the figure represents the physical connectivity of the elements;theupper part represents logical connectivity via one or more nested SAs.Each SA canbe either AH or ESP.For host-to-host SAs,the mode may be either transport ortunnel;otherwise it must be tunnel mode. Case 1. All security is provided between end systems that implement IPsec.For any two end systems to communicate via an SA,they must share the appropri-ate secret keys.Among the possible combinations are a. AH in transport mode b. ESP in transport mode c. ESP followed by AH in transport mode (an ESP SA inside an AH SA) d. Any one of a,b,or c inside an AH or ESP in tunnel modeWe have already discussed how these various combinations can be used tosupport authentication,encryption,authentication before encryption,and authenti-cation after encryption. Case 2. Security is provided only between gateways (routers,firewalls,etc.)and no hosts implement IPsec.This case illustrates simple virtual private networksupport.The security architecture document specifies that only a single tunnel SA isneeded for this case.The tunnel could support AH,ESP,or ESP with the authenti-cation option.Nested tunnels are not required,because the IPsec services apply tothe entire inner packet. Case 3. This builds on case 2 by adding end-to-end security.The same combi-nations discussed for cases 1 and 2 are allowed here.The gateway-to-gateway tunnelprovides either authentication,confidentiality,or both for all traffic between endsystems.When the gateway-to-gateway tunnel is ESP,it also provides a limited formof traffic confidentiality.Individual hosts can implement any additional IPsec ser-vices required for given applications or given users by means of end-to-end SAs. Case 4. This provides support for a remote host that uses the Internet to reach anorganization’s firewall and then to gain access to some server or workstation behindthe firewall.Only tunnel mode is required between the remote host and the firewall.Asin case 1,one or two SAs may be used between the remote host and the local host.

IP Security IKE (Internet Key Exchange) (Stallings, 2010) * (RFC 4306) * Goal Mutually authenticated session key(s) establishment Protocol A variarion of DH key exchange with extra features Cookies, to thwart clogging Nonces to prevent replay Mutual authentication, to thwart MITM attacks Optional anonymity Oakley Key Determination Protocol: Oakley is a key exchange protocol basedon the Diffie-Hellman algorithm but providing added security.Oakley isgeneric in that it does not dictate specific formats. F EATURES OF IKE KEY DETERMINATION  The IKE key determination algorithm ischaracterized by five important features: 1. It employs a mechanism known as cookies to thwart clogging attacks. 2. It enables the two parties to negotiate a group;this,in essence,specifies the globalparameters of the Diffie-Hellman key exchange. 3. It uses nonces to ensure against replay attacks. 4. It enables the exchange of Diffie-Hellman public key values. 5. It authenticates the Diffie-Hellman exchange to thwart man-in-the-middleattacks We have already discussed Diffie-Hellman.Let us look at the remainder of these elements in turn.First,consider the problem of clogging attacks.In this attack,an opponent forges the source address of a legitimate user and sends a public Diffie-Hellman key to the victim.The victim then performs a modular exponentiation tocompute the secret key.Repeated messages of this type can clog the victim’s systemwith useless work.The cookie exchange requires that each side send a pseudoran-dom number,the cookie,in the initial message,which the other side acknowledges.This acknowledgment must be repeated in the first message of the Diffie-Hellmankey exchange.If the source address was forged,the opponent gets no answer.Thus,an opponent can only force a user to generate acknowledgments and not to performthe Diffie-Hellman calculation. IKE mandates that cookie generation satisfy three basic requirements: 1. The cookie must depend on the specific parties.This prevents an attacker fromobtaining a cookie using a real IP address and UDP port and then using it toswamp the victim with requests from randomly chosen IP addresses or ports. 2. It must not be possible for anyone other than the issuing entity to generate cook-ies that will be accepted by that entity.This implies that the issuing entity will uselocal secret information in the generation and subsequent verification of a cookie.It must not be possible to deduce this secret information from any partic-ular cookie.The point of this requirement is that the issuing entity need not savecopies of its cookies,which are then more vulnerable to discovery,but can verifyan incoming cookie acknowledgment when it needs to. 3. The cookie generation and verification methods must be fast to thwart attacksintended to sabotage processor resources. The recommended method for creating the cookie is to perform a fast hash(e.g.,MD5) over the IP Source and Destination addresses,the UDP Source andDestination ports,and a locally generated secret value. Cookie: a hash over IP (src, dest) addresses, UDP (src, dest) ports, & a locally generated secret value Three authentication methods: Public signatures keys. Sign hashes of previous messages Public encryption keys. Encrypt challenges with responder’s PK Symmetric key encrypt. Use an out-of-band established key * *

Internet Key Exchange Clogging attacks & Cookies (Stallings, 2010) * (Sun, 2011) * Clogging attacks Opponent forges legitimate IP & sends a public DH key to victim; Victim performs modular exponentiation to compute the DH key; Repeated messages of this type can clog the victim’s system with useless work. Suggestion: Cookies When receiving request from S, send cookie to S; start processing after cookie comes back from the initiator Stateless Cookies Responder does not have to remember cookies he sent out; Cookie is a function of e.g., IP address and a secret known to responder

Internet Key Exchange Clogging attacks & Cookies (Stallings, 2010) * (Sun, 2011) *

IPSec Case: the Photuris Protocol (candidate for IKE) * (Kaufman, 2002) { } –encryption with the established DH key Anonymous DH with identity hiding and stateless cookies

IKE Phase 1 Aggressive Mode * (Kaufman, 2002) IKE defines two phases. Phase 1 does mutual authentication and establishes session keys. It is based on identities such as names, and secrets such as public key pairs, or pre-shared secrets between the two parties. Then using the key established in phase 1, multiple phase-2 SAs between the same pair of entities can be established. The phase 1 exchange is known as the ISAKMP SA, or IKE SA. An ESP or AH SA would be established through phase 2. Basically, Phase 1 negotiates IKE SA while phase 2 negotiates IPsec SAs. There are two types of phase-1 exchanges, called modes. Aggressive mode accomplishes mutual authentication and session key establishment in 3 message. Main mode uses 6 messages, and has additional functionality, such as the ability to hide endpoint identifiers from eavesdropping, and additional flexibility in negotiating cryptographic algorithms. Proof I’m Bob/Alice: (a) I prove I know the key associated to my identity (e.g., private signature key, private decryption key, pre-shared key) (b) Integrity-protect the previous messages

IKE Phase 1 Main Mode (Kaufman, 2002) + cookies * IKE defines two phases. Phase 1 does mutual authentication and establishes session keys. It is based on identities such as names, and secrets such as public key pairs, or pre-shared secrets between the two parties. Then using the key established in phase 1, multiple phase-2 SAs between the same pair of entities can be established. The phase 1 exchange is known as the ISAKMP SA, or IKE SA. An ESP or AH SA would be established through phase 2. Basically, Phase 1 negotiates IKE SA while phase 2 negotiates IPsec SAs. There are two types of phase-1 exchanges, called modes. Aggressive mode accomplishes mutual authentication and session key establishment in 3 message. Main mode uses 6 messages, and has additional functionality, such as the ability to hide endpoint identifiers from eavesdropping, and additional flexibility in negotiating cryptographic algorithms. + cookies

IKE Phase 1 Public Signature Keys, Main Mode (Kaufman, 2002) * Figure 18-4 CP: Crypto proposal CPA: Crypto proposal accepted The reason for including nonces in message 3 and 4 is because they will be used to calculate K next. If they do not include a nonce, they will have to use different DH value for each exchange and that is computationally expensive. Or they will have to use the save value for many exchanges, that is not secure for the reason of Perfect Forward Secrecy. So it is good idea to change K periodically. Message 5 and 6: the identity of the endpoints are hided. In this case, because both sides have public keys capable of doing signatures. The proof of identity consists of a signature of the hash of all the information, such as the DH value, the nonces, the crypto parameter Alice offered, and the cookies. 141

IKE Phase 1 Public Signature Keys, Aggressive Mode * (Kaufman, 2002) In the aggressive mode. Message 2 and 3 are not encrypted. So the identity is exposed. Relative advantage of using public signature keys: Don’t require knowing the other side’s public key in advance. (?) 142

IKE Phase 1 Public Encryption Keys, Main Mode, Original (Kaufman, 2002) * The original protocol were inefficient, but after they resigned them, they kept the original design in the spec for backward compatibility. We present here, one reason is to give you a complete picture of the protocols. Also I think it is not bad to know the pitfall made by experts. So you won’t go into the same inefficiency or problem again. In this design, the first two message exchanges the crypto proposals and cookies. Then in message 3, Alice sends her nonce and identity to Bob. Since they have a encryption key and are capable of doing encryption, the nonce and Alice’s identity was encrypted with Bob’s public key. Similarly, when Bob send Alice his nonce and identity, they were encrypted with Alice’s public key too. The reason that this protocol is not efficient is that nonce and Alice’s identity is encrypted separated, which requires separate private key operations to decrypt it. Another problem is that what if the nonce or the identity were larger than the public key with which it is being encrypted. Remember for public key algorithm, the message to be encrypted should be shorter than the key. The spec did not define it. The authentication is based on the proof that each side has the private key he/she supposed to have. So if they are able to decrypt the nonce and consequently computer the correct K, their identity is proved. The proof of identity here is the hash of the information such as the nonce, the cookie, the DH value, the crypto proposals, and so on. It does not directly involve the private key. However, since the hash is a function of the nonces, being able to compute the right K and right hash already prove the knowledge of the private decryption key. 143

IKE Phase 1 Public Encryption Keys, Aggressive Mode, Original * (Kaufman, 2002) This protocol is almost the same as the main mode version except that message 1 and 2 are removed, the crypto suites other than the DH group are negotiated in parallel with the other information in message 1 and 2. Again, the proof of identity consists of a hash of the nonce presented by the other side. They prove the knowledge of the private decryption key by getting the nonce decrypted. 144

IKE Phase 1 Public Encryption Keys, Main Mode, Revised (Kaufman, 2002) * The public encryption protocol was then revised to require only a single private key operation on each side (rather than two in the original). This is done by encrypting with a secret key which is a function of the nonce, and the nonce is encrypted with the other side’s public key. Thus the other side uses its private key to retrieve the nonce, but then decrypts the other fields with a secret key. 145

IKE Phase 1 Public Encryption Keys, Aggressive Mode, Revised * (Kaufman, 2002) Relative advantage: Both main mode and aggressive mode can hide both identities from passive as well as active attackers. While for public signature keys, main mode can hide both entities’ identities from passive attackers, but only hide Bob’s from active attackers since Alice has to divulge and prove her identity first; the aggressive mode cannot hide either side’s identity from passive or active attackers. 146

IKE Phase 1 Pre-Shared Secret Keys, Main Mode (Kaufman, 2002) * 147

IKE Phase 1 Pre-Shared Secret Keys, Aggressive Mode (Kaufman, 2002) * Relative Advantage: Better performance, easier to type in if configuration is done by typing the value into the two end nodes, but harder to configure than public keys because each pair of communicating entities results in a key to be configured. 148

IP Security Cryptographic Suites (Stallings, 2010) *