Κεντρική Σελίδα | Κεφάλαιο 1 | Κεφάλαιο 2 | Κεφάλαιο 3 | Κεφάλαιο 4 | Κεφάλαιο 5 | Κεφάλαιο 6

5.1 IPSec (IP Security)

5.1.1 Εισαγωγή

Το Internet αποτελεί αντικείμενο πολλών και διαφορετικών τύπων επιθέσεων συμπεριλαμβανομένων αυτών της απώλειας του απόρρητου, της ακεραιότητας των δεδομένων, της πλαστοπροσωπίας και της άρνησης παροχής υπηρεσιών. Ο στόχος της IPSec είναι η αντιμετώπιση όλων αυτών των προβλημάτων μέσα στην ίδια την υποδομή του δικτύου χωρίς να είναι αναγκαία η εγκατάσταση και η ρύθμιση ακριβών μηχανών και λογισμικού.

Η IPSec παρέχει κρυπτογράφηση στο επίπεδο του IP και για αυτό το λόγο αποτελεί ένα αξιοσημείωτο κομμάτι της συνολικής ασφάλειας. Οι προδιαγραφές της IPSec ορίζουν δύο νέους τύπους δεδομένων στα πακέτα: την επικεφαλίδα πιστοποίησης (AH-Authentication Header), για την παροχή υπηρεσίας ακεραιότητας δεδομένων και το φορτίο ενθυλάκωσης ασφάλειας (ESP-Encapsulating Security Payload) το οποίο παρέχει πιστοποίηση ταυτότητας και ακεραιότητα δεδομένων. Ορίζονται επίσης οι παράμετροι επικοινωνίας μεταξύ δύο συσκευών που είναι η διαχείριση των κλειδιών και η συσχετισμοί ασφάλειας (security associations).

5.1.2 Γιατί χρειαζόμαστε την IPSec

Απώλεια του Απορρήτου (Loss of Privacy)

Κάποιος που έχει καταφέρει να εισχωρήσει σε κάποιο δίκτυο έχει τη δυνατότητα να παρακολουθεί εμπιστευτικά δεδομένα κατά τη διακίνηση των τελευταίων στο Internet. Αυτή η δυνατότητα είναι ίσως ο μεγαλύτερος ανασταλτικός παράγοντας στις επικοινωνίες μεταξύ των επιχειρήσεων σήμερα. Χωρίς τη χρήση κρυπτογραφικών μεθόδων κάθε μήνυμα είναι ανοικτό προς ανάγνωση από όποιον έχει τη δυνατότητα να το αιχμαλωτίσει, όπως φαίνεται στο σχήμα 1. Το CERT (Computer Emergency Response Team Coordination Center) αναφέρεται στα προγράμματα "packet sniffers" ως την πιο συνηθισμένη περίπτωση επίθεσης από αυτές που συναντώνται, λέγοντας :

"Οι εισβολείς συνηθίζουν να εγκαθιστούν packet sniffers σε συστήματα που έχουν εκτεθεί σε κάθε είδους κίνδυνο μετά την απώλεια της μυστικότητας του root password. Αυτά τα προγράμματα, που συλλέγουν ονόματα και κωδικούς, εγκαθίστανται σαν μέρος ενός kit το οποίο αντικαθιστά επιπλέον κοινά αρχεία του συστήματος με προγράμματα που δείχνουν ότι κάνουν αυτό που θα έπρεπε αλλά στην πραγματικότητα εκτελούν άλλες λειτουργίες (Trojan horse programs). Aυτά τα kit παρέχουν οδηγίες οι οποίες καθιστούν και τον αρχάριο χρήστη τους επικίνδυνο για την ασφάλεια ενός απροστάτευτου δικτύου".

Απώλεια της Ακεραιότητας των Δεδομένων (Loss of Data Integrity)

Ακόμα και για δεδομένα που δεν είναι εμπιστευτικά πρέπει να λαμβάνονται μέτρα διασφάλισης της ακεραιότητάς τους. Μπορεί να μην μας ενδιαφέρει εάν κάποιος "δει" τη κίνηση ρουτίνας της δουλείας μας, αλλά σίγουρα θα μας προβλημάτιζε εάν αυτός αλλοίωνε κατά οποιοδήποτε τρόπο τα δεδομένα αυτά. Για παράδειγμα το να μπορεί κάποιος να πιστοποιεί με ασφάλεια τον εαυτό του στη τράπεζα κάνοντας χρήση ψηφιακών πιστοποιητικών δεν είναι αρκετό εάν η κύρια εργασία του στη τράπεζα θα μπορούσε να αλλοιωθεί με κάποιο τρόπο όπως φαίνεται στο σχήμα 2.

Πλαστοπροσωπία (Identity Spoofing)

Εκτός της προστασίας των ίδιων των δεδομένων, θα πρέπει να παίρνουμε μέτρα ώστε να προστατεύεται και η ταυτότητά μας στο Internet. Όπως φαίνεται στο σχήμα 3, ένας εισβολέας μπορεί να αποδειχθεί ικανός να κλέψει τη ταυτότητα κάποιου και έτσι να αποκτήσει πρόσβαση σε εμπιστευτικές πληροφορίες . Πολλά συστήματα ασφάλειας, σήμερα, βασίζονται στην IP διεύθυνση για να αναγνωρίσουν μοναδικά τους χρήστες. Τα συστήματα αυτά είναι πολύ εύκολο να ξεγελαστούν και αυτό το γεγονός έχει οδηγήσει σε αναρίθμητα τρυπήματα διαφόρων συστημάτων. Το CERT έχει αναφερθεί σε αυτού του είδους την επίθεση : "Συνεχίζουμε να λαμβάνουμε αρκετές αναφορές που μιλάνε για επιθέσεις τύπου IP Spoofing. Οι εισβολείς επιτίθενται χρησιμοποιώντας αυτοματοποιημένα εργαλεία που κυκλοφορούν ελευθέρα στο Internet. Κάποια sites πίστευαν, λανθασμένα, ότι σταματούσαν τέτοιου είδους επιθέσεις ενώ άλλα σχεδίαζαν να το κάνουν αλλά δεν είχαν προλάβει να το εφαρμόσουν".

Άρνηση Παροχής Υπηρεσιών (Denial-of-Service)

Εφόσον κάποιος οργανισμός εκμεταλλεύεται το Internet, πρέπει να λάβει κάποια μέτρα ώστε να διασφαλίσει τη διαθεσιμότητα του συστήματός του σε αυτό. Τα τελευταία χρόνια διάφοροι hackers έχουν βρει αδυναμίες στο πρωτόκολλο TCP/IP που τους δίνει τη δυνατότητα να "ρίχνουν" τις μηχανές (crash-σχήμα 4). Το CERT έχει μιλήσει για το θέμα : "Ο αριθμός των επιθέσεων εναντίον συστημάτων έχει αυξηθεί σημαντικά αφού υπάρχουν πλέον πακέτα που κυκλοφορούν ελευθέρα και που κάνουν εύκολη την πραγματοποίηση τέτοιου είδους επιθέσεων".

5.1.3 Ορισμός

Η IPSec είναι ένα πρωτόκολλο ανοικτών προδιαγραφών για τη διασφάλιση του απορρήτου των επικοινωνιών. Είναι βασισμένο στις προδιαγραφές που ανέπτυξε η ομάδα εργασίας του Internet (ΙETF). Η IPSec διασφαλίζει την εμπιστευτικότητα, την ακεραιότητα και την αυθεντικότητα των επικοινωνιών δεδομένων σε ένα IP δίκτυο. Η IPSec παρέχει τον απαραίτητο μηχανισμό για την ανάπτυξη ευκίνητων λύσεων ασφάλειας σε ένα δίκτυο.

Έλεγχοι κρυπτογράφησης και πιστοποίησης ταυτότητας μπορούν να εφαρμοσθούν σε διάφορα επίπεδα στην δικτυακή υποδομή όπως φαίνεται και στο σχήμα 5.

Πριν την άφιξη της IPSec στο προσκήνιο, εφαρμόζονταν αποσπασματικές λύσεις που αντιμετώπιζαν μέρος μόνο του προβλήματος. Για παράδειγμα, το SSL(Secure Sockets Layer) παρέχει κρυπτογράφηση σε επίπεδο εφαρμογής για Web browsers και άλλες εφαρμογές. Το SSL προστατεύει την πιστότητα των δεδομένων που στέλνονται από κάθε εφαρμογή που το χρησιμοποιεί, αλλά δεν προστατεύει τα δεδομένα που αποστέλλονται από άλλες εφαρμογές. Κάθε σύστημα και εφαρμογή πρέπει να είναι προστατεμένη από το SSL για να του παρέχει το τελευταίο την προστασία.

Οργανισμοί όπως ο στρατός χρησιμοποιούσαν για χρόνια κρυπτογράφηση επιπέδου συνδέσμου. Σε αυτό το σχήμα κάθε σύνδεσμος επικοινωνιών προστατεύεται από ένα ζεύγος συσκευών κρυπτογράφησης - μια στο τέλος κάθε πλευράς του συνδέσμου. Αν και αυτό το σύστημα παρέχει εξαιρετική ασφάλεια δεδομένων είναι πολύ δύσκολο να παρακολουθηθεί και να διαχειριστεί. Επιπλέον απαιτεί η κάθε πλευρά του συνδέσμου στο δίκτυο να είναι ασφαλής διότι τα δεδομένα είναι σε καθαρή μορφή σε αυτά τα σημεία. Φυσικά αυτό το σχήμα δεν μπορεί να δουλέψει καθόλου στο Internet όπου πιθανότατα κανένας από τους ενδιάμεσους συνδέσμους δεν είναι προσβάσιμος σε κανέναν και δεν εμπιστεύεται κανέναν.

Η IPSec υλοποιεί κρυπτογράφηση και πιστοποίηση επιπέδου δικτύου όπως φαίνεται στο σχήμα 6, παρέχοντας μια λύση ασφαλείας μέσα στην ίδια την αρχιτεκτονική του δικτύου. Έτσι τα συστήματα και οι εφαρμογές που βρίσκονται στις άκρες δεν χρειάζονται αλλαγές ή ρυθμίσεις για να έχουν το πλεονέκτημα της ισχυρής ασφάλειας. Επειδή τα κρυπτογραφημένα πακέτα μοιάζουν με κανονικά IP πακέτα μπορούν εύκολα να δρομολογηθούν μέσα από οποιοδήποτε IP δίκτυο, όπως το Internet, χωρίς καμία αλλαγή στον ενδιάμεσο δικτυακό εξοπλισμό. Οι μόνες συσκευές οι οποίες γνωρίζουν για την κρυπτογράφηση είναι αυτές στα ακραία σημεία. Αυτό το χαρακτηριστικό μειώνει δραστικά τόσο το κόστος της υλοποίησης όσο και το κόστος της διαχείρισης.

5.1.4 Λεπτομέρειες της IPSec

Η IPSec συνδυάζει τις παραπάνω τεχνολογίες ασφάλειας σε ένα ολοκληρωμένο σύστημα το οποίο παρέχει εμπιστευτικότητα, ακεραιότητα και πιστοποίηση της ταυτότητας των IP πακέτων. Η IPSec αναφέρεται και σε μια σειρά άλλων πρωτοκόλλων όπως ορίζεται στα RFC 1825-1829 και σε άλλες δημοσιεύσεις στο Internet. Αυτές οι προδιαγραφές περιλαμβάνουν:

• Κατάλληλο IP πρωτόκολλο ασφαλείας, το οποίο καθορίζει την πληροφορία που πρέπει να προστεθεί σε ένα IP πακέτο για να ενεργοποιηθούν οι έλεγχοι πιστότητας, ακεραιότητας και πιστοποίησης ταυτότητας, όπως επίσης καθορίζει και το πως πρέπει να γίνει η κρυπτογράφηση των δεδομένων του πακέτου.
• Ανταλλαγή κλειδιών Internet, το οποίο διαπραγματεύεται το συσχετισμό ασφάλειας μεταξύ δυο οντοτήτων και ανταλλάσσει το υλικό των κλειδιών. Δεν είναι απαραίτητο να χρησιμοποιηθεί το IKE, αλλά το να ρυθμιστούν χειροκίνητα οι συσχετισμοί ασφάλειας είναι μια δύσκολη και επίπονη διαδικασία. Το ΙΚΕ πρέπει να χρησιμοποιείται στις περισσότερες εφαρμογές για να ενεργοποιεί ασφαλείς επικοινωνίες μεγάλης κλίμακας.

Πακέτα ΙPSec

H ΙPSec ορίζει ένα νέο σετ επικεφαλίδων το οποίο προστίθεται στα IP διαγράμματα. Αυτές οι νέες επικεφαλίδες τοποθετούνται μετά την επικεφαλίδα IP και πριν το πρωτόκολλο επιπέδου 4 (τυπικά το TCP ή το UDP). Αυτές οι νέες επικεφαλίδες παρέχουν πληροφορίες για την ασφάλεια του φορτίου των IP πακέτων όπως αναλύεται παρακάτω:

• Επικεφαλίδα πιστοποίησης ταυτότητας (AH—Authentication Header)—αυτή η επικεφαλίδα όταν προστίθεται σε ένα IP διάγραμμα διασφαλίζει την ακεραιότητα και την ταυτότητα των δεδομένων. Δεν παρέχει ασφάλεια πιστότητας. Η επικεφαλίδα αυτή χρησιμοποιεί μια keyed-hash συνάρτηση αντί ψηφιακών υπογραφών διότι η τεχνολογία ψηφιακών υπογραφών είναι πολύ αργή και θα μείωνε την απόδοση του δικτύου.
• Φορτίο ασφαλείας ενθυλάκωσης (ESP—Encapsulating Security Payload)—αυτή η επικεφαλίδα όταν προστίθεται σε ένα ΙΡ διάγραμμα προστατεύει την ακεραιότητα και την ταυτότητα των δεδομένων. Αν η ESP χρησιμοποιείται για την επικύρωση της ακεραιότητας των δεδομένων δεν περιλαμβάνει τα αμετάβλητα πεδία της ΙΡ επικεφαλίδας.

Οι ΑΗ και οι ESP μπορούν να χρησιμοποιηθούν ανεξάρτητα ή μαζί, αν και για τις περισσότερες εφαρμογές μια από τις δυο είναι αρκετή. Και για τα δυο αυτά πρωτόκολλα οι ΙΡSec δεν καθορίζει συγκεκριμένους αλγόριθμους που πρέπει να χρησιμοποιηθούν αλλά παρέχει ένα ανοικτό πλαίσιο για βιομηχανική υλοποίηση με παραγωγή ανεξάρτητων αλγορίθμων. Αρχικά οι περισσότερες υλοποιήσεις της IPSec θα περιλαμβάνουν υποστήριξη για το MD5 από την RSA Data Security ή για την SHA (Secure Hash Algorithm) όπως ορίζεται από την κυβέρνηση των Η. Π. Α. για την ακεραιότητα και την πιστοποίηση της ταυτότητας. Το DES (Data Encryption Standard) είναι προς το παρόν ο πιο κοινά προσφερόμενος αλγόριθμος κρυπτογράφησης αν και υπάρχουν και άλλοι όπως οι IDEA, Blowfish και RC4.

Η IPSec παρέχει δυο καταστάσεις λειτουργίας: την transport και την tunnel, όπως φαίνεται στο σχήμα 7.

Στην κατάσταση transport μόνο το IP φορτίο κρυπτογραφείται ενώ οι αρχικές επικεφαλίδες μένουν ανέπαφες. Αυτή η κατάσταση λειτουργίας έχει το πλεονέκτημα της πρόσθεσης μόνο μερικών Bytes σε κάθε πακέτο. Επιπλέον επιτρέπουν σε συσκευές στο δημόσιο δίκτυο να βλέπουν την τελική πηγή και προορισμό του πακέτου. Αυτή η δυνατότητα επιτρέπει ειδική επεξεργασία (για παράδειγμα QoS) στο ενδιάμεσο δίκτυο βασισμένη στην πληροφορία που βρίσκεται στην ΙΡ επικεφαλίδα. Ωστόσο η επικεφαλίδα του επιπέδου 4 θα κρυπτογραφηθεί περιορίζοντας τη δυνατότητα έρευνας των πακέτων. Βεβαίως αφήνοντας την ΙΡ επικεφαλίδα χωρίς κρυπτογράφηση η κατάσταση λειτουργίας transport επιτρέπει στον επιτιθέμενο να κάνει ανάλυση κίνησης (traffic analysis). Για παράδειγμα ο επιτιθέμενος θα μπορούσε να δει πότε ένα CEO της Cisco έστειλε πολλά πακέτα σε ένα άλλο CEO. Ωστόσο ο επιτιθέμενος θα γνώριζε μόνο την αποστολή των ΙΡ πακέτων και δεν θα ήταν στη θέση να καθορίσει αν αυτά ήταν πακέτα e-mail ή κάποιας άλλης εφαρμογής.

Στην κατάσταση λειτουργίας tunnel όλο το ΙΡ διάγραμμα κρυπτογραφείται και γίνεται το φορτίο ενός καινούριου ΙΡ πακέτου. Αυτή η κατάσταση λειτουργίας επιτρέπει σε μια δικτυακή συσκευή, όπως ένας δρομολογητής, να ενεργήσει σαν ένας ΙΡSec proxy. Αυτό σημαίνει ότι ο δρομολογητής πραγματοποιεί κρυπτογράφηση για λογαριασμό των υπολογιστών του δικτύου. Η πηγή του δρομολογητή κρυπτογραφεί τα πακέτα και τα προωθεί στο IPSec tunnel. Ο προορισμός του δρομολογητή αποκρυπτογραφεί το αρχικό ΙΡ διάγραμμα και το προωθεί στο σύστημα προορισμού του. Το βασικό πλεονέκτημα αυτής της κατάστασης λειτουργίας είναι ότι τα ακραία συστήματα δεν χρειάζεται να ρυθμιστούν για να επικαρπωθούν τα πλεονεκτήματα της IPSec. Η κατάσταση λειτουργίας tunnel προστατεύει επιπλέον το σύστημα από την διαδικασία της ανάλυσης κίνησης. Σε αυτή την κατάσταση λειτουργίας ο επιτιθέμενος μπορεί να καθορίσει μόνο τα ακραία σημεία του tunnel και όχι την πραγματική πηγή και τον προορισμό των πακέτων που κυκλοφορούν μέσα σε αυτό ακόμη και αν είναι τα ίδια με τα ακραία σημεία του tunnel.

Όπως καθορίζεται από την IETF η κατάσταση λειτουργίας transport μπορεί να χρησιμοποιηθεί μόνο όταν τόσο η πηγή όσο και τα συστήματα προορισμού καταλαβαίνουν από IPSec όπως φαίνεται στο σχήμα 8. Στις περισσότερες περιπτώσεις έχουμε εφαρμογή της IPSec σε κατάσταση λειτουργίας tunnel. Έχουμε έτσι τη δυνατότητα να υλοποιήσουμε την IPSec στη δικτυακή υποδομή χωρίς να τροποποιήσουμε το λειτουργικό σύστημα ή οποιαδήποτε εφαρμογή στους servers και τους υπολογιστές του δικτύου.

Συσχετισμοί Ασφάλειας – Security Association

Η IPSec παρέχει πολλές επιλογές για την υλοποίηση κρυπτογράφησης και πιστοποίησης ταυτότητας στο δίκτυο. Κάθε ΙΡSec σύνδεση μπορεί να παρέχει είτε κρυπτογράφηση είτε ακεραιότητα και πιστοποίηση ταυτότητας δεδομένων ή και τα δυο. Όταν η υπηρεσία ασφάλειας καθοριστεί οι δυο επικοινωνούντες κόμβοι πρέπει να καθορίσουν ακριβώς ποίους αλγόριθμους θα χρησιμοποιήσουν (για παράδειγμα DES ή IDEA για κρυπτογράφηση και MD5 ή SHA για ακεραιότητα δεδομένων). Αφού αποφασίσουν για τους αλγόριθμους οι δυο συσκευές πρέπει να μοιράσουν κλειδιά σύνδεσης. Όπως μπορούμε να δούμε υπάρχει αρκετή πληροφορία προς παρακολούθηση. Η συσχέτιση ασφάλειας είναι μια μέθοδος που χρησιμοποιείται από την IPSec για την παρακολούθηση όλων των λεπτομερειών που αφορούν μια δεδομένη IPSec επικοινωνία. Μια συσχέτιση ασφάλειας είναι η σχέση μεταξύ δυο ή περισσοτέρων οντοτήτων που περιγράφει πως οι οντότητες θα χρησιμοποιήσουν τις υπηρεσίες ασφάλειας για να επικοινωνήσουν με ασφάλεια. Η νονμεκλατούρα μπερδεύει μερικές φορές διότι οι συσχετισμοί ασφάλειας χρησιμοποιούνται για πολλά περισσότερα από ότι μόνο για την IPSec. Για παράδειγμα οι συσχετισμοί ασφάλειας ΙΚΕ περιγράφουν τις παραμέτρους ασφάλειας μεταξύ δυο ΙΚΕ συσκευών.

Οι συσχετισμοί ασφάλειας είναι μη κατευθυντικοί που σημαίνει ότι για κάθε ζεύγος επικοινωνούντων συστημάτων υπάρχουν τουλάχιστον δυο συνδέσεις ασφάλειας—μια από το Α στο Β και μια από το Β στο Α. Ο συσχετισμός ασφάλειας αναγνωρίζεται μοναδικά από έναν τυχαίως επιλεγμένο μοναδικό αριθμό ο οποίος λέγεται SPI (Security Parameter Index) και από την ΙΡ διεύθυνση του προορισμού. Όταν ένα σύστημα στέλνει ένα πακέτο το οποίο απαιτεί ΙΡSec προστασία κοιτάει τον συσχετισμό ασφάλειας στη βάση δεδομένων του, εφαρμόζει τη συγκεκριμένη επεξεργασία και μετά εισάγει τον SPI από το συσχετισμό ασφάλειας στην IPSec επικεφαλίδα. Όταν το αντίστοιχο μηχάνημα IPSec λαμβάνει το πακέτο κοιτάει με τη σειρά του το συσχετισμό ασφάλειας βάσει της διεύθυνσης προορισμού και του SPI και μετά επεξεργάζεται το πακέτο όπως ορίζεται. Με λίγα λόγια ο συσχετισμός ασφάλειας είναι απλώς μια δήλωση της διαπραγματεύσιμης πολιτικής ασφάλειας μεταξύ δυο συσκευών όπως φαίνεται στο σχήμα 9.

Πρωτόκολλο Διαχείρισης Κλειδιών Internet

Η IPSec μπορεί να θεωρήσει ότι ένας συσχετισμός ασφάλειας υπάρχει αλλά δεν έχει το μηχανισμό να τον δημιουργήσει. Η IETF επέλεξε να σπάσει τη διαδικασία αυτή σε δύο μέρη : η IPSec παρέχει την επεξεργασία των πακέτων επιπέδου IP και το πρωτόκολλο διαχείρισης κλειδιών Internet (ΙΚMP—Internet Key Management Protocol), ασχολείται με ότι έχει να κάνει με τους συσχετισμούς ασφάλειας. Μετά από εξέταση πολλών εναλλακτικών λύσεων συμπεριλαμβανομένων και των SKIP (Simple Key Management Protocol) και Photouris, η IETF επέλεξε το IKE σαν το τρόπο ρύθμισης των συσχετισμών ασφάλειας για την IPSec.

Το ΙΚΕ δημιουργεί ένα πιστοποιημένο και ασφαλές κανάλι – τούνελ μεταξύ δύο οντοτήτων και κατόπιν διαπραγματεύεται τους συσχετισμούς ασφάλειας για την IPSec. Αυτή η διαδικασία απαιτεί από τις δύο οντότητες να πιστοποιήσουν η μία την άλλη και να μοιράσουν κλειδιά.

Πιστοποίηση Ταυτότητας

Τα δύο μέρη πρέπει να πιστοποιήσουν το ένα το άλλο. Το ΙΚΕ είναι πολύ ευέλικτο και υποστηρίζει πολλές διαφορετικές μεθόδους πιστοποίησης της ταυτότητας. Οι δύο οντότητες πρέπει να συμφωνήσουν σε ένα κοινό πρωτόκολλο πιστοποίησης μέσω μιας κατάλληλης διαδικασίας. Σε αυτή τη φάση υλοποιούνται συνήθως οι παρακάτω μηχανισμοί :

• Προ-Μοιρασμένα Κλειδιά—το ίδιο κλειδί προ-εγκαθίσταται και στις δύο μηχανές. Κατά την πιστοποίηση αποστέλλεται από τη μία μηχανή στην άλλη μία επεξεργασμένη μορφή (με τη βοήθεια μιας hash συνάρτησης) του ίδιου κλειδιού. Εάν αυτή η μορφή συμπίπτει με αυτήν που υπολογίζεται τοπικά σε κάθε μηχανή, τότε η διαδικασία πιστοποίησης έχει θετικό αποτέλεσμα.
• Κρυπτογράφηση Δημοσίων Κλειδιών—κάθε μηχανή "γεννάει" έναν ψευδο-τυχαίο αριθμό τον οποίο και κρυπτογραφεί με το public key (δημόσιο κλειδί) της άλλης μηχανής. Η πιστοποίηση επιτυγχάνεται μέσω της ικανότητας των μηχανών να υπολογίσουν μια hash συνάρτηση του τυχαίου αριθμού αποκρυπτογραφώντας με τα private keys (ιδιωτικά κλειδιά) ότι λαμβάνουν από το συνομιλητή τους. Το σύστημα παρέχει ακόμα και δυνατότητα άρνησης συμμετοχής σε οποιαδήποτε διαδικασία πιστοποίησης. Προς το παρόν μόνο ο αλγόριθμος δημοσίων κλειδιών της RSA υποστηρίζεται.
• Ψηφιακές Υπογραφές—κάθε συσκευή υπογράφει ψηφιακά ένα σύνολο δεδομένων και τα στέλνει στην άλλη. Αυτή η μέθοδος είναι παρόμοια με την προηγούμενη μόνο που δεν παρέχει μηχανισμό άρνησης της εμπλοκής της σε κάποια προσπάθεια πιστοποίησης. Προς το παρόν υποστηρίζονται τόσο ο αλγόριθμος δημοσίων κλειδιών της RSA όσο και οι προδιαγραφές ψηφιακών υπογραφών (DSS).

Τόσο η διαδικασία κρυπτογράφησης όσο και αυτή των ψηφιακών υπογραφών απαιτεί τη χρήση ψηφιακών πιστοποιητικών για την επικύρωση της δημόσιας σε ιδιωτική αντιστοίχησης. Το ΙΚΕ επιτρέπει την ανεξάρτητη ανταλλαγή των ψηφιακών πιστοποιητικών με τη χρήση για παράδειγμα του DNSSEC ή την ανταλλαγή τους σαν μέρος του ΙΚΕ.

Ανταλλαγή Κλειδιών

Τα δύο μέρη πρέπει να έχουν ένα κοινό, έστω προσωρινό, κλειδί έτσι ώστε να κρυπτογραφήσουν το ΙΚΕ τούνελ. Το πρωτόκολλο Diffie-Helman χρησιμοποιείται για τη συμφωνία σε ένα κοινό κλειδί. Η ανταλλαγή πιστοποιείται όπως περιγράφηκε παραπάνω για τη αποφυγή επιθέσεων παρεμβολών.

Χρησιμοποίηση του ΙΚΕ στην IPSec

Αυτά τα δύο βήματα, πιστοποίηση και ανταλλαγή κλειδιών, δημιουργούν το ΙΚΕ SA—ένα ασφαλές κανάλι μεταξύ των δύο συσκευών. Το ένα μέρος του τούνελ προσφέρει ένα σύνολο αλγορίθμων ενώ το άλλο πρέπει να κάνει αποδεκτή μία από τις προσφορές ή να απορρίψει ολόκληρη τη σύνδεση. Όταν πλέον τα δύο μέρη συμφωνήσουν στη χρήση συγκεκριμένων αλγορίθμων αντλούν το υλικό των κλειδιών για χρήση από την IPSec μαζί με μία ή και τις δύο επικεφαλίδες (AH και ESP). Η IPSec χρησιμοποιεί διαφορετικό κλειδί από αυτό του IKE. Το κλειδί της IPSec μπορεί να προέλθει από την επαναχρησιμοποίηση της ανταλλαγής Diffie-Helman για την επίτευξη υψηλού βαθμού ασφάλειας, ή με την χρησιμοποίηση της αρχικής ανταλλαγής Diffie-Helman η οποία και παρήγαγε το ΙΚΕ SA, αφού αυτή πρώτα συσχετισθεί μέσω μιας hash συνάρτησης με κάποιους τυχαίους αριθμούς. Η πρώτη μέθοδος παρέχει μεγαλύτερη ασφάλεια αλλά είναι πολύ πιο αργή. Αφού όλα τα παραπάνω τελειώσουν το IPSec SA έχει εγκαθιδρυθεί.

Το σχήμα 9 δείχνει πως η IPSec χρησιμοποιεί το ΙΚΕ για την εγκαθίδρυση μιας ασφαλούς συσχέτισης ασφάλειας. Στο παράδειγμα, το πρώτο πακέτο της Alice προς τον Bob, το οποίο πρέπει να είναι κρυπτογραφημένο, ενεργοποιεί την διαδικασία ΙΚΕ. Αυτή, με τη σειρά της, φτιάχνει ένα ασφαλές κανάλι μεταξύ του Bob και της Alice. Η IPSec SA διαπραγματεύονται μέσα σε αυτό το κανάλι-τούνελ. Κατόπιν η Alice μπορεί να χρησιμοποιήσει αυτό το συσχετισμό ασφάλειας για να στείλει δεδομένα στο Bob με ασφάλεια.

Επειδή η όλη διαδικασία δείχνει κάπως σύνθετη στη θεωρία, ας δούμε το παρακάτω παράδειγμα (σχήμα 11):

Σε αυτό το παράδειγμα ο Bob προσπαθεί να επικοινωνήσει με ασφάλεια, με την Alice. Οι κινήσεις που γίνονται είναι οι παρακάτω:

1. Ο Bob στέλνει τα δεδομένα του προς την Alice
2. Όταν ο δρομολογητής του Bob δει τα πακέτα ελέγχει τη πολιτική ασφάλειάς τους και αντιλαμβάνεται ότι αυτά πρέπει να είναι κρυπτογραφημένα.
3. Η προ-ρυθμισμένη πολιτική ασφάλειας λέει επιπλέον ότι ο δρομολογητής της Alice πρέπει να είναι το τελικό σημείο του IPSec τούνελ.
4. Ο δρομολογητής του Bob κοιτάει να δει εάν έχει εγκαθιδρυμένη μια IPSec SA με το δρομολογητή της Alice.
5. Σε περίπτωση που μια τέτοια δεν υπάρχει, τότε ζητάει μία από το ΙΚΕ.

5.1.5 Περαιτέρω Πληροφορίες

Links για επιπλέον πληροφορίες: http://www.cisco.com

5.2 NAT (Network Address Translation)

5.2.1 Τι είναι το NAT

Ο Μεταφραστής Διευθύνσεων Δικτύου σχεδιάστηκε για απλοποίηση και διατήρηση των IP διευθύνσεων αφού αυτό που κάνει είναι να επιτρέπει σε ιδιωτικά δίκτυα που χρησιμοποιούν μη εγγεγραμμένες IP διευθύνσεις να έχουν σύνδεση με το Internet. Το σύστημα ΝΑΤ λειτουργεί σε κάποιον δρομολογητή, ο οποίος συνδέει συνήθως δύο δίκτυα και μεταφράζει τις ιδιωτικές (μη μοναδικές στον παγκόσμιο ιστό) διευθύνσεις του εσωτερικού δικτύου σε νόμιμες διευθύνσεις προτού τα πακέτα προωθηθούν σε άλλο δίκτυο. Σαν μέρος αυτής της λειτουργίας το ΝΑΤ μπορεί να ρυθμιστεί να κάνει γνωστή μόνο μία διεύθυνση στον έξω κόσμο για ολόκληρο το δίκτυο που συνδέει με αυτόν. Αυτό το χαρακτηριστικό παρέχει επιπλέον ασφάλεια αφού κρύβει ολόκληρο το εσωτερικό δίκτυο από το κόσμο πίσω από μία διεύθυνση.

Επιπλέον, μία επιχείρηση μπορεί να θέλει να έχει σύνδεση με το Internet χρησιμοποιώντας όμως παραπάνω από έναν παροχέα υπηρεσιών internet (ISP) για διάφορους λόγους. Το να διατηρεί κανείς σύνδεση στο internet μέσω παραπάνω του ενός ISP μπορεί να θεωρηθεί σαν ένας τρόπος αύξησης της αξιοπιστίας της σύνδεσης στο internet. Τέτοιου είδους sites με πολλαπλές συνδέσεις ονομάζονται "multi-homed". Όταν η σύνδεση από τον ένα παροχέα πέφτει τότε η εταιρία περνάει σε κάποιον άλλο διατηρώντας τη σύνδεσή της έτσι πάντα. Ακόμα ένα πλεονέκτημα αυτού του σχήματος είναι το ότι η επιχείρηση μπορεί να διανείμει το φορτίο της σε διαφορετικές συνδέσεις. Για επιχειρήσεις μάλιστα που εκτείνονται σε μεγάλη γεωγραφική περιοχή ένα τέτοιο σχήμα θα σήμαινε και καλύτερη διαδικασία δρομολόγησης.

Όλες οι παραπάνω σκέψεις συνδυαζόμενες και με τις συνεχώς μειούμενες τιμές των internet συνδέσεων δίνουν κίνητρο σε όλο και περισσότερες εταιρίες να γίνουν "multi-homed". Την ίδια στιγμή, ο φόρτος που τέτοιες εταιρίες επιβάλλουν στους δρομολογητές στο internet αυξάνεται και γίνεται ολοένα και πιο σημαντικός. Πρέπει λοιπόν να βρεθεί ένας τρόπος κλιμακοποίησης του internet και υποστήριξης αυτών των επιχειρήσεων. Μία λύση θα ήταν οι δρομολογητές της ελεύθερης ζώνης του internet να διατηρούσαν μία διαδρομή για κάθε "multi-homed" επιχείρηση που συνδέεται με παραπάνω του ενός ISPs στο internet. Αυτή η λύση όμως δεν παρέχει επαρκή κλιμακοποίηση. Επιπλέον μία λύση για τη διαχείριση της δρομολόγηση τέτοιων εταιριών θα πρέπει να ενσωματώνει το σκεπτικό ότι ο απαιτούμενος βαθμός συνεργασίας των ISPs θα πρέπει να είναι όσο το δυνατόν μικρότερος και ιδιαίτερα αυτών που δεν συνδέονται άμεσα με τις επιχειρήσεις αυτές.

Το RFC2260 περιγράφει ένα μηχανισμό κατανομής διευθύνσεων και δρομολόγησης για "multi-homed" επιχειρήσεις ο οποίος έχει αρκετά καλή κλιμάκωση. Ωστόσο, δεν του λείπουν και τα μειονεκτήματα. Απαιτεί επαναδιευθυνσιοδότηση μέρους της επιχείρησης όταν αυτή αλλάξει έναν από τους ISPs της ή όταν πρωτογίνει "multi-homed". Επιπλέον, η ικανότητα μιας επιχείρησης να διανέμει τη κίνηση στις διαφορετικές ISP συνδέσεις της, καθορίζεται σε μεγάλο βαθμό από την ανάθεση διευθύνσεων μέσα στην επιχείρηση. Αυτό θα μπορούσε να θεωρηθεί ότι κάνει το καταμερισμό του φορτίου μια άκαμπτη και δυσκίνητη υπόθεση. Ο έλεγχος της κίνησης μέσω της ανάθεσης διευθύνσεων επιφέρει και επιπλέον πολυπλοκότητα στα σχήματα διευθυνσιοδότησης στο εσωτερικό της επιχείρησης.

Η προτεινόμενη, εδώ, λύση είναι το NAΤ. Θα δούμε πως αυτό το σύστημα μπορεί να απαντήσει στα θέματα που τέθηκαν και πώς επιπλέον μπορεί να δραστηριοποιηθεί στην κατεύθυνση της κλιμακοποίησης της δρομολόγησης στις "multi-homed" περιπτώσεις. Το σχήμα που προτείνει το NAT δεν απαιτεί από την επιχείρηση να επαναδιευθυνσιοδοτήσει κατά την αλλαγή ISP και επιτρέπει το καταμερισμό του φορτίου της ανεξάρτητα από το σκηνικό της διευθυνσιοδότησης που υπάρχει μέσα στην επιχείρηση. Η παροχή υπηρεσίας αλλαγής ISP σε περίπτωση που πέσει η σύνδεση με αυτόν που εξυπηρετεί την εταιρία είναι εφαρμόσιμη τόσο στο IPv4 όσο και στο IPv6.

5.2.2 Ανάθεση Διευθύνσεων και Δρομολόγηση

Μία "multi-homed" επιχείρηση συνδεδεμένη ένα σύνολο ISPs έχει πάρει κάποια πεδία διευθύνσεων από καθέναν από τους ISPs (για παράδειγμα μία εταιρία συνδεδεμένη με Ν ISPs θα έχει Ν διαφορετικά πεδία διευθύνσεων). Αυτές τις διευθύνσεις τις ονομάζουμε "εσωτερικές παγκόσμιες διευθύνσεις". Η ανάθεση τέτοιων διευθύνσεων από τους ISPs στην επιχείρηση μπορεί να βασίζεται στη πολιτική του "δανεισμού διευθύνσεων" [RFC2008]. Τέτοιες διευθύνσεις προέρχονται από πεδία διευθύνσεων που οι ISPs χρησιμοποιούν για να δανείζουν κομμάτια αυτών στους πελάτες τους. Ένα σύστημα ΝΑΤ που συνδέει μια επιχείρηση με έναν ISP χρησιμοποιεί το BGP για να διακηρύξει στον ISP την απευθείας σύνδεσή του με τις εσωτερικές παγκόσμιες διευθύνσεις που έχουν παραχωρηθεί από τον ISP τον ίδιο. Ο ISP με τη σειρά του ομαδοποιεί την πληροφορία αυτή και την διασύνδεει με ένα δρομολόγιο απαλείφοντας την ανάγκη να κρατάει στην ελεύθερη ζώνη του internet δρομολόγια για κάθε "multi-homed" επιχείρηση. Το ΝΑΤ δρα σαν ακραίος δρομολογητής-έχει μία εξωτερική BGP (EBGP) σύνδεση με έναν ή παραπάνω από τους δρομολογητές του παροχέα υπηρεσιών (ISP) και μια εσωτερική BGP (IBGP) σύνδεση με άλλα συστήματα NΑΤ στο εσωτερικό της επιχείρησης.

Το σχήμα, που περιγράφεται εδώ, δεν θέτει περιορισμούς στην ανάθεση διευθύνσεων στο εσωτερικό της επιχείρησης. Μπορούν να χρησιμοποιηθούν είτε παγκοσμίως μοναδικές διευθύνσεις είτε διευθύνσεις από το "ιδιωτικό" πεδίο διευθύνσεων είτε διευθύνσεις που χρησιμοποιούνται από άλλους στο internet. Αναφερόμαστε στις διευθύνσεις που χρησιμοποιούνται για ανάθεση στο εσωτερικό της επιχείρησης ως "εσωτερικές τοπικές διευθύνσεις".

Επιπρόσθετα των εσωτερικών και εξωτερικών παγκόσμιων διευθύνσεων, μια επιχείρηση πρέπει να αναθέσει σε κάθε ένα απο τα συστήματα NAT που διαθέτει, ένα πεδίο διευθύνσεων το οποίο να μην συμπίπτει τόσο με τις εσωτερικές τοπικές διευθύνσεις όσο και με οποιαδήποτε από τις (παγκοσμίως μοναδικές) internet διευθύνσεις. Αναφερόμαστε σε αυτές τις διευθύνσεις ως "εξωτερικές τοπικές διευθύνσεις". Οι διευθύνσεις αυτές μπορεί να προέρχονται από το ιδιωτικό πεδίο διευθύνσεων (εάν η επιχείρηση χρησιμοποιεί ιδιωτικό πεδίο διευθύνσεων για τις εσωτερικές τοπικές διευθύνσεις, τότε πρέπει να κρατήσει ένα μέρος αυτών για χρήση από τις εξωτερικές τοπικές διευθύνσεις). Το ΝΑΤ μιας επιχείρησης διακηρύττει στη δρομολόγηση της επιχείρησης απευθείας δυνατότητα σύνδεσης με εξωτερικές τοπικές διευθύνσεις που έχουν ανατεθεί στο ΝΑΤ. Αυτή η πληροφορία είναι και η μόνη πληροφορία δρομολόγησης που το ΝΑΤ διακηρύττει στην επιχείρηση. Έτσι η δρομολόγηση στην εταιρία διεκπεραιώνει δρομολογήσεις προς όλους τους εσωτερικούς της προορισμούς και προς τις εξωτερικές τοπικές διευθύνσεις που έχουν ανατεθεί στα ΝΑΤ της επιχείρησης και μόνο προς αυτές.

Σχήμα 1:Multi—homed Enterprise

Σαν επίδειξη ας εξετάσουμε το παράδειγμα που φαίνεται στο σχήμα 1, όπου η επιχείρηση foo. com είναι συνδεδεμένη με δύο παροχείς υπηρεσιών (ISPs), τον ISP1 και τον ISP2. Ο ISP1 δίνει από το 140. 16/16 πεδίο διευθύνσεών του το υπο-πεδίο 140. 16. 10/24 στην επιχείρηση. Το ΝΑΤ1 που συνδέει την επιχείρηση με τον ISP1 διακηρύσσει στον ISP1 απευθείας σύνδεση με το 193. 17. 15/24

Για τις εξωτερικές τοπικές διευθύνσεις της η επιχείρηση χρησιμοποιεί διευθύνσεις από το ιδιωτικό πεδίο διευθύνσεων. Για το ΝΑΤ1 η επιχείρηση διαθέτει το 192. 168. 1/24 πεδίο και για το ΝΑΤ2 το 192. 168. 2/24. Το ΝΑΤ1 διακηρύττει στην επιχείρηση απευθείας σύνδεση με το 192. 168. 1/24 και το ΝΑΤ2 αντίστοιχα με το 192. 168. 2/24. Όλα αυτά θεωρώντας ότι η επιχείρηση χρησιμοποιεί το πεδίο 10/8 για τις εσωτερικές τοπικές της διευθύνσεις.

5.2.3 Επισκόπηση Λειτουργιών

Το ΝΑΤ μπορεί να κάνει μετάφραση τόσο των διευθύνσεων των πηγών των πακέτων όσο και αυτών των προορισμών τους. Η μετάφραση γίνεται με τη βοήθεια του πίνακα μετάφρασης διευθύνσεων ο οποίος διατηρείται από το ΝΑΤ. Επιπλέον θεωρούμε ότι η λειτουργία της μετάφρασης των διευθύνσεων επαυξάνεται με μερικά από τα Application Layer Gateways (ALGs) που είναι λειτουργίες για εφαρμογές που περιέχουν IP διευθύνσεις σαν μέρος της ροής δεδομένων της εφαρμογής. Ειδικότερα, θεωρούμε ότι ένα σύστημα ΝΑΤ υλοποιεί την ALG λειτουργία για το πρωτόκολλο DNS.

Πίνακας Μετάφρασης Διευθύνσεων

Ο Πίνακας Μετάφρασης Διευθύνσεων που διατηρεί το ΝΑΤ αποτελείται από καταχωρήσεις δύο τύπων:μετάφραση εσωτερικών διευθύνσεων και μετάφραση εξωτερικών διευθύνσεων. Κάθε καταχώρηση αποτελείται από δύο μέρη: την τοπική διεύθυνση και τη παγκόσμια διεύθυνση.

Το στοιχείο της τοπικής διεύθυνσης ενός τύπου καταχώρησης εσωτερικής μετάφρασης είναι μία διεύθυνση παρμένη από το πεδίο των εσωτερικών τοπικών διευθύνσεων. Αναφερόμαστε σε μια τέτοια διεύθυνση ως γνωστόν με το χαρακτηρισμό "εσωτερική τοπική διεύθυνση" (IL). Το στοιχείο της παγκόσμιας διεύθυνσης μιας τέτοιας καταχώρησης είναι μια διεύθυνση που έχει εξαχθεί από το πεδίο των εσωτερικών παγκοσμίων διευθύνσεων που έχει δοθεί στο ΝΑΤ και αναφερόμαστε σε μια τέτοια διεύθυνση με το όνομα "εσωτερική παγκόσμια διεύθυνση" (IG).

Το στοιχείο της τοπικής διεύθυνσης ενός εξωτερικού τύπου μετάφρασης διεύθυνσης είναι μία διεύθυνση που έχει εξαχθεί από το εξωτερικό τοπικό πεδίο διευθύνσεων που υπάρχει στο ΝΑΤ. Αναφερόμαστε σε μια τέτοια διεύθυνση με το χαρακτηρισμό "εξωτερική τοπική διεύθυνση" (OL). Τέλος το στοιχείο της παγκόσμιας διεύθυνσης μιας τέτοιας καταχώρησης είναι μια διεύθυνση ενός υπολογιστή έξω από την επιχείρηση. . Αναφερόμαστε σε μια τέτοια διεύθυνση με το χαρακτηρισμό "εξωτερική παγκόσμια διεύθυνση" (OG).

Περιληπτικά:

• Εσωτερική Τοπική (IL)—Η IP διεύθυνση που δίνεται σε υπολογιστή εντός της επιχείρησης. Αυτή η διεύθυνση μπορεί να είναι παγκοσμίως μοναδική, να έχει παρθεί από το ιδιωτικό πεδίο διευθύνσεων ή να έχει ανατεθεί επίσημα σε κάποια άλλη επιχείρηση.
• Εσωτερική Παγκόσμια (IG)—Η IP διεύθυνση ενός υπολογιστή εντός της επιχείρησης όπως εμφανίζεται στο internet. Αυτές οι διευθύνσεις έχουν εξαχθεί από ένα παγκοσμίως μοναδικό πεδίο διευθύνσεων που τυπικά παρέχεται από τον ISP.
• Εξωτερική Τοπική (EL)—Η IP διεύθυνση ενός υπολογιστή εκτός της επιχείρησης όπως φαίνεται μέσα στην επιχείρηση. Αυτές οι διευθύνσεις παίρνονται εάν είναι επιθυμητό από το πεδίο διευθύνσεων που ορίζεται στo RFC 1918 και αναφέρεται σε ιδιωτικά πεδία διευθύνσεων.
• Εξωτερική Παγκόσμια (ΕG)—Η IP διεύθυνση ενός υπολογιστή εκτός της επιχείρησης όπως φαίνεται στο internet. Αυτές οι διευθύνσεις παίρνονται από ένα παγκοσμίως μοναδικό πεδίο διευθύνσεων.

Γέμισμα του Πίνακα Μετάφρασης Διευθύνσεων

Ουσιαστικές για τη λειτουργία των ΝΑΤ είναι οι διαδικασίες γεμίσματος του πίνακα μετάφρασης διευθύνσεων.

1. Καταχώρηση εξωτερικού τύπου μετάφρασης

Δημιουργείται ως αποτέλεσμα επεξεργασίας DNS απαντήσεων πακέτων δεδομένων που προέρχονται από το εξωτερικό της επιχείρησης

• Εάν η καταχώρηση έχει δημιουργηθεί ως αποτέλεσμα επεξεργασίας DNS απαντήσεων, τότε η εξωτερική παγκόσμια διεύθυνση στη καταχώρηση ισοδυναμεί με τη διεύθυνση που υπήρχε στο Α RR (Resource Record) της DNS απάντησης
• Εάν η καταχώρηση έχει δημιουργηθεί ως αποτέλεσμα επεξεργασίας πακέτου δεδομένων, τότε η εξωτερική παγκόσμια διεύθυνση στη καταχώρηση ισοδυναμεί με την IP διεύθυνση της πηγής του πακέτου
• Η εσωτερική τοπική διεύθυνση στη καταχώρηση είναι παρμένη από το πεδίο εξωτερικών τοπικών διευθύνσεων.

1. Καταχώρηση εσωτερικού τύπου μετάφρασης

• Εάν η καταχώρηση δημιουργείται ως αποτέλεσμα της επεξεργασίας κάποιας DNS απάντησης, η εσωτερική τοπική διεύθυνση στην καταχώρηση ισοδυναμεί με τη διεύθυνση που υπήρχε στο Α RR (Resource Record) της DNS απάντησης
• Εάν η καταχώρηση έχει δημιουργηθεί ως αποτέλεσμα επεξεργασίας πακέτου δεδομένων, τότε η εσωτερική τοπική διεύθυνση στη καταχώρηση ισοδυναμεί με την IP διεύθυνση της πηγής του πακέτου
• Η εσωτερική παγκόσμια διεύθυνση στη καταχώρηση είναι παρμένη από το πεδίο εσωτερικών παγκόσμιων διευθύνσεων

5.2.4 Παροχή Αδιάλειπτης Εφεδρικής Σύνδεσης

Πρώτη Μέθοδος:"Auto Route Injection"

Ας θεωρήσουμε το παράδειγμα που φαίνεται στο σχήμα 2. Θεωρούμε ότι ο δρομολογητής που συνδέει την επιχείρηση στον ISP-A ονομάζεται ENT-BR-A και ο αντίστοιχος για τον ISP-B ENT-BR-B. θεωρούμε επίσης ότι ο δρομολογητής του ISP-A που συνδέει αυτόν με την επιχείρηση λέγεται ISP-BR-A και ο αντίστοιχος του ISP-B λέγεται ISP-BR-Β. Θεωρούμε επιπλέον ότι το πεδίο εσωτερικών παγκοσμίων διευθύνσεων που ο ISP-A έδωσε στην επιχείρηση ότι λέγεται Prefix A και το αντίστοιχο του ISP-B ότι λέγεται Prefix B.

                                                      Σχήμα 2: "Auto Route Injection"—Steady State

Όταν το σύνολο των δρομολογίων που λαμβάνει ο ENT-BR-A από τον ISP-BR-A (μέσω EBGP) έχει ένα γεμάτο τμήμα με το σύνολο των δρομολογίων που ο ENT-BR-A λαμβάνει από τον ISP-BR-Β (μέσω EBGP), τότε ο ENT-BR-A διακηρύττει στον ISP-BR-A ότι έχει σύνδεση μόνο με το Prefix A. Όταν το κοινό μέρος είναι άδειο τότε ο ENT-BR-A διακηρύττει στον ISP-BR-A ότι έχει σύνδεση και με το Prefix A και με το Prefix B. (Στο σχήμα 3 η σύνδεση μεταξύ των ENT-BR-B και ISP-BR-Β έχει χαθεί ). Αυτή η προσέγγιση είναι γνωστή ως "auto route injection" και θα συνεχίζεται για όσο διάστημα η σύνδεση παραμένει κάτω. Με το που το κοινό μέρος γεμίσει, ο ENT-BR-A θα σταματήσει να διακηρύττει σύνδεση με το Prefix B στον ISP-BR-A (αλλά θα συνεχίσει να διακηρύττει σύνδεση με το Prefix A στον ISP-BR-A).

Σχήμα 3: "Auto Route Injection"—Broken Connection

• Να καταλάβει εάν η σύνδεση με το internet μέσω κάποιου άλλου δρομολογητή είναι ζωντανή ή έχει πέσει και
• Να καθορίσει τo Prefix των διευθύνσεων που δόθηκαν από τον ISP που είναι συνδεδεμένος με τον άλλο δρομολογητή της επιχείρησης. Ένας πιθανός τέτοιος μηχανισμός θα μπορούσε να παρέχεται από το BGP. Σε αυτή τη περίπτωση οι δρομολογητές μέσα στην επιχείρηση θα διατηρούσαν, μεταξύ τους, μία IBGP σχέση. Οποτεδήποτε ένας δρομολογητής αντιλαμβάνεται ότι το κοινό μέρος μεταξύ του συνόλου των συνδεδεμένων προορισμών, που λαμβάνει μέσω EBGP απευθείας από τον ISP του, και του συνόλου των συνδεδεμένων προορισμών που λαμβάνει από έναν άλλο δρομολογητή της επιχείρησης, μέσω IBGP, είναι άδειο τότε ξεκινά να διακηρύττει προς το εξωτερικό (τον δρομολογητή του ISP με τον οποίο είναι άμεσα συνδεδεμένος) ότι γνωρίζει και το Prefix που έχει αποδοθεί από τον άλλο ISP στον άλλο δρομολογητή της επιχείρησης. Αυτός, τέλος, διακηρύττει μέσω IBGP το Prefix των διευθύνσεων που είχαν αποδοθεί στην επιχείρηση από τον ISP που είναι άμεσα συνδεδεμένος μαζί του.

Κάθε σύστημα ΝΑΤ εκτός της διακήρυξης στον δρομολογητή της επιχείρησης της σύνδεσης με τις εξωτερικές τοπικές διευθύνσεις που αποδόθηκαν στο ΝΑΤ είναι επιπλέον επιφορτισμένο με την ευθύνη να διακηρύττει στον δρομολογητή της επιχείρησης της σύνδεσης με τις εξωτερικές παγκόσμιες διευθύνσεις που αποδόθηκαν στο ΝΑΤ. Αυτό με τη σειρά του συνεπάγεται ότι καμία από τις εξωτερικές παγκόσμιες διευθύνσεις που αποδόθηκαν στο ΝΑΤ θα μπορούσαν να χρησιμοποιηθούν από εσωτερικές τοπικές διευθύνσεις. Αυτό είναι αναγκαίο για την αποφυγή διάσπασης των μεταφορικών συνδέσεων σε περίπτωση που πέσει η σύνδεση μεταξύ της επιχείρησης και των παροχέων υπηρεσιών (ISP) της. Επιπλέον το ΝΑΤ πρέπει να εμφυσά στην επιχείρηση ένα δεδομένο δρομολόγιο (default route) όσο καταλαβαίνει ότι διατηρείται η σύνδεση με το Internet.

Με αυτή τη μέθοδο και σε σταθερή κατάσταση τα δρομολόγια που εμφυσούνται από την επιχείρηση στους ISPs της ομαδοποιούνται από αυτούς και δεν αναπαράγονται στην "ελεύθερη ζώνη" του internet. Μπορεί να ειπωθεί ότι όταν χαθεί η σύνδεση, όπως φαίνεται στο σχήμα 3, αυτή η μέθοδος θα είχε ως αποτέλεσμα την εμφύτεψη επιπλέον πληροφορίας δρομολόγησης στην "ελεύθερη ζώνη" του internet. Ωστόσο, κάποιος θα μπορούσε να παρατηρήσει ότι η πιθανότητα να χάσουν όλες οι "multi-homed" επιχειρήσεις τη σύνδεσή τους με το internet ταυτόχρονα είναι πολύ μικρή. Έτσι κατά μέσο όρο ο αριθμός των επιπλέον δρομολογίων στην "ελεύθερη ζώνη" του internet εξαιτίας των "multi-homed" επιχειρήσεων αναμένεται να είναι μόνο ένα μικρό κλάσμα του συνολικού αριθμού αυτών των επιχειρήσεων.

Δεύτερη Μέθοδος:"Non-Direct"BGP Peering

Η πρώτη μέθοδος επιτρέπει τη δραστική μείωση του φόρτου δρομολόγησης στην εξ ορισμού ελεύθερη (default-free) ζώνη του internet εξαιτίας των "multi-homed" επιχειρήσεων. Η παρακάτω προσέγγιση επιτρέπει την πλήρη απάλειψη αυτού του φαινομένου.

Ο δρομολογητής της επιχείρησης διατηρεί EBGP σύνδεση όχι μόνο με τον απευθείας σε αυτούς συνδεδεμένους δρομολογητές των ISPs αλλά και με τους δρομολογητές άλλων ISPs που είναι άμεσα συνδεδεμένοι με άλλους δρομολογητές της επιχείρησης. Αυτή η αντιστοίχηση λέγεται "όχι άμεση EBGP αντιστοιχήσει" και φαίνεται στο σχήμα 4.

Σχήμα 4:"Non—Direct" EBGP Peering—Steady State

Ένας ISP που διατηρεί τόσο άμεση όσο και έμμεση EBGP σύνδεση με μια συγκεκριμένη επιχείρηση διακηρύττει το ίδιο σύνολο δρομολογίων και στις δύο συνδέσεις. Ένας δρομολογητής επιχείρησης που διατηρεί άμεση ή έμμεση σύνδεση με τον ISP διακηρύττει σε αυτόν το Prefix διευθύνσεων που διατέθηκε στην επιχείρηση από αυτόν τον ISP. Στον ISP προτιμούνται τα δρομολόγια που ελήφθησαν από άμεση σύνδεση—αντιστοίχηση από τα αντίστοιχα των μη άμεσων συνδέσεων. Η προώθηση μέσω δρομολογίου που ελήφθη από έμμεση σύνδεση γίνεται με ενθυλάκωση[GRE].

Σαν παράδειγμα ας πάρουμε τη διάταξη του σχήματος 5. Η τοπολογία είναι ίδια με αυτή του σχήματος 2 μόνο που εδώ έχουμε και μια επιπλέον έμμεση EBGP σύνδεση του ENT-BR-A με τον ISP-BR-B. Ο ENT-BR-Β διατηρεί άμεση EBGP σύνδεση με τον ISP-BR-B και διακηρύττει σε αυτόν σύνδεση με το Prefix B. Τέλος, ο ENT-BR-Β διατηρεί έμμεση EBGP σύνδεση με τον ISP-BR-Α και διακηρύττει σε αυτόν σύνδεση με το Prefix Α.

Όταν η σύνδεση της εταιρίας με τους δύο ISPs είναι ζωντανή, η κίνηση που προορίζεται για υπολογιστές των οποίων οι διευθύνσεις υπήρχαν στο Prefix A θα περάσουν μέσα από τον ISP-A στον ISP-BR-A και τέλος στον ENT-BR-A και την επιχείρηση. Αντίστοιχα, η κίνηση που προορίζεται για υπολογιστές των οποίων οι διευθύνσεις υπήρχαν στο Prefix Β θα περάσει μέσα από τον ISP-Β στον ISP-BR-Β και τέλος στον ENT-BR-Β και την επιχείρηση. Τώρα ας δούμε τι θα γινόταν εάν χανόταν η σύνδεση μεταξύ των ISP-BR-Β και ENT-BR-Β. Σε αυτή τη περίπτωση η κίνηση προς τους υπολογιστές με Prefix A θα γίνεται όπως και πριν. Όμως η κίνηση προς αυτούς με Prefix B θα πηγαίνει από τον ISP-Β στον ISP-BR-Β και αυτός θα την ενθυλακώνει και θα τη στέλνει στον ENT-BR-Α όπου θα απο-ενθυλακώνετε και θα στέλνεται στην επιχείρηση όπως φαίνεται και στο σχήμα 5.

Σχήμα 5:"Non--Direct" EBGP Peering—Broken Connection

Κάθε σύστημα ΝΑΤ εκτός της διακήρυξης στον δρομολογητή της επιχείρησης της σύνδεσης με τις εξωτερικές τοπικές διευθύνσεις που αποδόθηκαν στο ΝΑΤ είναι επιπλέον επιφορτισμένο με την ευθύνη να διακηρύττει στον δρομολογητή της επιχείρησης της σύνδεσης με τις εξωτερικές παγκόσμιες διευθύνσεις που αποδόθηκαν στο ΝΑΤ. Αυτό με τη σειρά του συνεπάγεται ότι καμία από τις εξωτερικές παγκόσμιες διευθύνσεις που αποδόθηκαν στο ΝΑΤ θα μπορούσαν να χρησιμοποιηθούν από εσωτερικές τοπικές διευθύνσεις. Αυτό είναι αναγκαίο για την αποφυγή διάσπασης των μεταφορικών συνδέσεων σε περίπτωση που πέσει η σύνδεση μεταξύ της επιχείρησης και των παροχέων υπηρεσιών (ISP) της. Επιπλέον το ΝΑΤ πρέπει να εμφυσά στην επιχείρηση ένα δεδομένο δρομολόγιο (default route) όσο καταλαβαίνει ότι διατηρείται η σύνδεση με το Internet.

Μπορούμε να παρατηρήσουμε ότι με αυτό το σχήμα δεν υπάρχει επιπλέον πληροφορία δρομολόγησης εξαιτίας των "multi-homed" επιχειρήσεων στην "default-free" ζώνη του internet. Επιπλέον βλέπουμε ότι το σύνολο των δρομολογητών μέσα σε έναν ISP που διατηρούν έμμεσες συνδέσεις με δρομολογητές επιχειρήσεων δεν είναι αναγκαστικό να συμπίπτει με τους δρομολογητές που διατηρούν άμεσες συνδέσεις. Για την έμμεση αντιστοίχηση μπορεί να χρησιμοποιηθεί οποιοσδήποτε άλλος δρομολογητής βελτιώνοντας έτσι την αξιοπιστία του συστήματος σε περιπτώσεις αποτυχιών μέσα στον ISP.

5.2.5 Υπολογιστές Επιχειρήσεων Εκτός του Δικτύου Αυτών

Μία DNS ζώνη σχετιζόμενη με μια επιχείρηση μπορεί να περιλαμβάνει έναν ή παραπάνω υπολογιστές που βρίσκονται εκτός του δικτύου της επιχείρησης. Για παράδειγμα αυτοί που δεν βρίσκονται πίσω από το ΝΑΤ της επιχείρησης. Για την υποστήριξη της επικοινωνίας με αυτούς ο πίνακας μετάφρασης διευθύνσεων του κάθε ΝΑΤ που συνδέει την επιχείρηση με το internet ρυθμίζεται με έναν εσωτερικό και έναν εξωτερικό τύπο μετάφρασης για κάθε υπολογιστή. Στη καταχώρηση εσωτερικού τύπου μετάφρασης η εσωτερική τοπική διεύθυνση ισοδυναμεί με μια διεύθυνση από τις εξωτερικές τοπικές διευθύνσεις του ΝΑΤ και η εσωτερική παγκόσμια διεύθυνση ισοδυναμεί με την IP διεύθυνση του υπολογιστή. Στην εξωτερικού τύπου καταχώρηση μετάφρασης η εξωτερική τοπική διεύθυνση ισοδυναμεί με την εσωτερική παγκόσμια διεύθυνση της καταχώρησης εσωτερικών διευθύνσεων και η εξωτερική παγκόσμια διεύθυνση ισοδυναμεί με την εσωτερική διεύθυνση της μετάφρασης εσωτερικού τύπου καταχώρησης.

Η DNS καταχώρηση για έναν τέτοιο υπολογιστή (Α και PTR RR) χρησιμοποιούν την IP διεύθυνση του υπολογιστή.

5.2.6 Περαιτέρω Πληροφορίες

Ο αναγνώστης μπορεί να βρει επιπλέον πληροφορίες στο site της Cisco διεύθυνση: http://www.cisco.com

5.3 Secure Socket Layer (SSL)

5.3.1 Γενικά

Το πρωτόκολλο SSL αναπτύχθηκε από την Netscape Communications Corporation για την ασφαλή επικοινωνία ευαίσθητων πληροφοριών όπως προσωπικά στοιχεία και αριθμούς πιστωτικών καρτών. Η πρώτη σχεδίαση του πρωτοκόλλου έγινε τον Ιούλιο του 1994 και αποτελούσε την πρώτη έκδοση (version 1.0) και τον Οκτώβριο του ίδιου χρόνου δημοσιοποιήθηκε υπό την μορφή RFC (Request For Comments). Τον Δεκέμβριο του 1994 εκδίδεται μια επαναθεώρηση του πρωτοκόλλου, η δεύτερη έκδοση του (version 2.0). Η παρούσα έκδοση του SSL, version 3.0, παρουσιάσθηκε στο κοινό στα τέλη του 1995, ενώ από τα μέσα του 1995 είχε αρχίσει να εφαρμόζεται σε προϊόντα της εταιρίας, όπως τον Netscape Navigator.

Επειδή η Netscape επιθυμούσε την παγκόσμια υιοθέτηση του πρωτοκόλλου γεγονός που ερχόταν σε σύγκρουση με τους νόμους των Ηνωμένων Πολιτειών περί εξαγωγή κρυπτογραφικών αλγορίθμων, αναγκάστηκε να επιτρέψει την χρήση ασθενών αλγορίθμων στις εξαγόμενες εφαρμογές. Πιο συγκεκριμένα, δημιούργησε παραλλαγές των αλγόριθμων RC4-128 και RC2-128 που στην πραγματικότητα χρησιμοποιούν κλειδιά των 40 bits.

5.3.2 Εισαγωγή στο SSL

Το πρωτόκολλο SSL έχει σχεδιαστεί για να παρέχει απόρρητη επικοινωνία μεταξύ δύο συστημάτων, από τα οποία το ένα λειτουργεί σαν client και το άλλο σαν server. Η εξασφάλιση του απορρήτου γίνεται με την κρυπτογράφηση όλων των μηνυμάτων στο επίπεδο SSL Record Protocol. Παρέχει, επιπλέον, υποχρεωτική πιστοποίηση της ταυτότητας του server και προαιρετικά της ταυτότητας του client, μέσω έγκυρων πιστοποιητικών από έμπιστες Αρχές Έκδοσης Πιστοποιητικών (Certificates Authorities). Υποστηρίζει πληθώρα μηχανισμών κρυπτογράφησης και ψηφιακών υπογραφών για αντιμετώπιση όλων των διαφορετικών αναγκών. Τέλος, εξασφαλίζει την ακεραιότητα των δεδομένων, εφαρμόζοντας την τεχνική των Message Authentication Codes (MACs), ώστε κανείς να μην μπορεί να αλλοιώσει την πληροφορία χωρίς να γίνει αντιληπτός. Όλα τα παραπάνω γίνονται με τρόπο διαφανές και απλό.

Η έκδοση 3 του πρωτοκόλλου κάλυψε πολλές αδυναμίες της δεύτερης. Οι σημαντικότερες αλλαγές έχουν να με την μείωση των απαραίτητων μηνυμάτων κατά το handshake για την εγκαθίδρυση της σύνδεσης, την επιλογή των αλγόριθμων συμπίεσης και κρυπτογράφησης από τον server και την εκ νέου διαπραγμάτευση του master-key και session-id. Ακόμα αυξάνονται οι διαθέσιμοι αλγόριθμοι και προστίθενται νέες τεχνικές για την διαχείριση των κλειδιών.

Το SSL μπορεί να τοποθετηθεί στην κορυφή οποιουδήποτε πρωτοκόλλου μεταφοράς, δεν εξαρτάται από την ύπαρξη του TCP/IP και τρέχει κάτω από πρωτόκολλα εφαρμογών όπως το HTTP, FTP και TELNET. Μια αναπαράσταση του πρωτοκόλλου SSL βλέπουμε παρακάτω.

5.3.3 Υποστηριζόμενοι Αλγόριθμοι

Οι αλγόριθμοι κρυπτογράφησης χωρίζονται στους stream ciphers και στους block ciphers. Στους stream ciphers ανήκουν οι RC4 με κλειδιά 40 bits και 128 bits. Στους block ciphers ανήκουν οι RC2 με κλειδιά 40 και 128 bits, οι DES, DES40, Triple DES και οι IDEA και Fortezza.

Οι αλγόριθμοι για την παραγωγή των hash και digest values για τα MACs είναι ο MD5 (128-bit hash) και ο SHA (160-bit hash).

Οι τεχνικές διαχείρισης των κλειδιών (key management) διακρίνονται στους: την ασύμμετρη κρυπτογραφία με RSA, την τεχνική Diffie-Hellman. Τα πιστοποιητικά είναι της μορφής Χ.509. Ο RSA μαζί με τον DSS και τον Fortezza μπορούν να χρησιμοποιηθούν για την ψηφιακή υπογραφή των κλειδιών κρυπτογράφησης.

Προσφέρεται και η δυνατότητα επιλογής ανασφάλιστης επικοινωνίας, αλλά δεν συνιστάται.

5.3.4 Το SSL και το OSI μοντέλο

Είναι σημαντικό κάθε νέο πρωτόκολλο επικοινωνίας να συμμορφώνεται με το OSI μοντέλο, έτσι ώστε να μπορεί εύκολα να αντικαταστήσει κάποιο υπάρχον πρωτόκολλο ή να ενσωματωθεί στην υπάρχουσα δομή πρωτοκόλλων.

Το SSL χωρίζεται σε δύο μέρη, το SSL Handshake Protocol (SSLHP) και το SSL Record Protocol (SSLRP). Το SSLHP διαπραγματεύεται τους αλγόριθμους κρυπτογράφησης που θα χρησιμοποιηθούν και πραγματοποιεί την πιστοποίηση της ταυτότητας του server και εάν ζητηθεί και του client. Το SSLRP συλλέγει τα δεδομένα σε πακέτα και αφού τα κρυπτογραφήσει τα μεταδίδει και αποκρυπτογραφεί τα παραλαμβανόμενα πακέτα.

Βλέπουμε πως το SSL λειτουργεί επιπρόσθετα της υπάρχουσας δομής του OSI και όχι σαν πρωτόκολλο αντικατάστασης. Επίσης είναι πασιφανές ότι η χρήση του SSL δεν αποκλείει την χρήσης άλλου μηχανισμού ασφαλείας που λειτουργεί σε υψηλότερο επίπεδο, για παράδειγμα το S/HTTP που εφαρμόζεται στο επίπεδο Εφαρμογών, πάνω από το SSL.

SSL Record Protocol

Ένα πακέτο SSL αποτελείται από δύο μέρη, την επικεφαλίδα και τα δεδομένα. Η επικεφαλίδα μπορεί να είναι είτε 3 bytes είτε 2 bytes, από τις οποίες περιπτώσεις η δεύτερη χρησιμοποιείται όταν τα δεδομένα χρειάζονται συμπλήρωμα (padding). Το πεδίο escape-bit στην περίπτωση των 3 bytes υπάρχει μόνο σε εκδόσεις μετά την δεύτερη του πρωτοκόλλου και προβλέπεται για ρύθμιση πληροφοριών out-of-band. Για την επικεφαλίδα των 2 bytes το μέγεθος του πακέτου είναι 32767 bytes, ενώ για την επικεφαλίδα των 3 bytes το μέγεθος είναι 16383 bytes.

Το κομμάτι των δεδομένων αποτελείται από ένα Message Authentication Code (MAC), τα πραγματικά δεδομένα και δεδομένα συμπλήρωσης, εάν χρειάζονται. Αυτό το κομμάτι είναι που κρυπτογραφείται κατά την μετάδοση. Τα συμπληρωματική δεδομένα απαιτούνται όταν οι αλγόριθμοι κρυπτογράφησης εν χρήση είναι τύπου block ciphers και ο ρόλος τους είναι να συμπληρώνουν τα πραγματικά δεδομένα ώστε το μέγεθος τους είναι πολλαπλάσιου του μεγέθους που δέχεται σαν είσοδο ο block cipher. Εάν χρησιμοποιούνται stream ciphers τότε δεν απαιτείται συμπλήρωμα και μπορεί αν χρησιμοποιηθεί η επικεφαλίδα των 2 bytes.

Το MAC είναι η digest ή hash value των secret-write key (βλέπε παρακάτω) του αποστολέα του πακέτου, των πραγματικών δεδομένων, των συμπληρωματικών δεδομένων και ενός αριθμού ακολουθίας, στην σειρά που δίνονται.

Προβλέπεται και η συμπίεση των δεδομένων (data compression) με κατάλληλους μηχανισμούς που επιλέγονται κατά το handshake, ενώ δεν αποκλείεται να χρειαστεί και τεμαχισμός της πληροφορίας σε πολλά πακέτα (fragmentation).

SSL Handshake Protocol

Το πρωτόκολλο SSL Handshake διαχωρίζεται σε δύο επιμέρους φάσεις: η πρώτη φάση αφορά την επιλογή των αλγόριθμων, την ανταλλαγή ενός master key και την πιστοποίηση της ταυτότητας του server. Η δεύτερη φάση διαχειρίζεται την πιστοποίηση της ταυτότητας του client (εάν ζητηθεί) και ολοκληρώνει την διαδικασία του handshaking. Όταν το ολοκληρωθούν και οι δύο φάσεις, το στάδιο του handshake τελειώνει και η μεταφορά μεταξύ των δύο άκρων αρχίζει. Όλα τα μηνύματα κατά την διάρκεια του handshaking και μετά στέλνονται σύμφωνα με το SSL Record Protocol.

Το πακέτο των αλγορίθμων κρυπτογράφησης (Cipher Suite) περιλαμβάνει την μέθοδο για την ανταλλαγή των κλειδιών, τον αλγόριθμο κρυπτογράφησης και τον μηχανισμό για την παραγωγή του MAC.

Παρακάτω θα δούμε τρεις διαφορετικές περιπτώσεις επικοινωνίας.

1. Πρώτα θα εξετάσουμε την περίπτωση της αρχικής σύνδεσης, χωρίς πιστοποίηση ταυτότητας του client. Χρησιμοποιείται η σύμβαση "{data}key" για να υποδηλώσουμε κρυπτογραφημένα δεδομένα με το κλειδί "key".

Ας δούμε βήμα προς βήμα την ακολουθία μηνυμάτων.

Με το μήνυμα client-hello στέλνει ο client στον server μια λίστα με τους αλγόριθμους που υποστηρίζει και τα challenge-data που θα χρησιμοποιηθούν αργότερα για την πιστοποίηση της ταυτότητας του.

Το μήνυμα server-hello επιστρέφει στον client ένα αναγνωριστικό της σύνδεσης (connection-id), την επιλογή του server όσον αναφορά πακέτο των αλγόριθμων κρυπτογράφησης και συμπίεσης (που και οι δύο υποστηρίζουν) και το πιστοποιητικό του server που θα χρησιμοποιηθεί από τον client για την απόκτηση της δημόσιας κλείδας του server. Στην τελευταία έκδοση του

Το client-master-key και το master-key, που ανάλογα με το που βρίσκεται κάθε υπολογιστής, μπορεί να έχει δυο διαφορετικές μορφές. Για SSL εφαρμογές έξω από τις Ηνωμένες Πολιτείες, τα 88 bits του master-key μεταδίδονται μη κρυπτογραφημένα και κρυπτογραφούνται τα υπόλοιπα 40 bits με την δημόσια κλείδα του server. Αντίθετα για SSL εφαρμογές εντός των Ηνωμένων Πολιτειών, κρυπτογραφείται όλο το master-key και το clear-master-key είναι άδειο.

Από αυτό το σημείο και μετά όλα τα μηνύματα κρυπτογραφούνται στο επίπεδο του SSL Record Protocol. Το master-key δεν χρησιμοποιείται άμεσα για κρυπτογράφηση, αλλά για την παραγωγή δύο ζευγάρια κλειδιών. Το ένα ζευγάρι ανήκει στον client και αποτελείται από το client-write-key που χρησιμοποιεί ο client για να κρυπτογραφήσει τα μηνύματα προς τον server και το client-read-key για να αποκρυπτογραφήσει ότι λαμβάνει από αυτόν. Το δεύτερο ζευγάρι ανήκει στον server και αποτελείται από το server-write-key για κρυπτογράφηση μηνυμάτων προς τον client και το server-read-key για αποκρυπτογράφηση των παραληφθέντων. Για την ακρίβεια, το client-write-key είναι το ίδιο με το server-read-key και το client-read-key είναι το ίδιο με το server-write-key.

Το client-finish περιέχει το αναγνωριστικό της σύνδεσης που αρχικά είχε σταλεί από τον server κρυπτογραφημένο με το client-write-key.

Το server-verify περιέχει τα challenge-data που είχε στείλει ο client στον server κατά την αρχή της σύνδεσης, κρυπτογραφημένα με το server-write-key. Η παραλαβή και αποκρυπτογράφηση αυτού του μηνύματος είναι το τελικό στάδιο για την επιβεβαίωση της ταυτότητας του server καθ' ότι μόνο ο αληθινός server θα μπορούσε να αποκρυπτογραφήσει με την ιδιωτική του κλείδα το master-key.

Τέλος, το μήνυμα server-finish τερματίζει το handshake. Περιέχει το session-id που χρησιμοποιείται σε επόμενες διαδικασίες handshake για την αποφυγή επανάληψης της φάσης επιλογής αλγορίθμων και ανταλλαγής του master-key. Το session-id αποθηκεύεται και από τους δύο και η προτεινόμενη διάρκεια ζωής είναι 100 δευτερόλεπτα. Έπειτα, αχρηστεύεται.

2. Όταν ένα προηγούμενο session-id από τον client χρησιμοποιείται για να επαναεγκαταστήσει την σύνδεση, το handshake γίνεται ως εξής:

Αλλάζει το client-hello που περιέχει επιπλέον το session-id και χρησιμοποιείται από τον server για να καθορίσει τους αλγόριθμους και το master-key. Η λίστα με τους αλγόριθμους στέλνεται ξανά για την περίπτωση όπου έχει λήξει το session-id.

Το server-hello στέλνεται μόνο όταν το session-id ισχύει ακόμα.

3. Όταν ζητείται πιστοποίηση της ταυτότητας του client και έχει προηγουμένως εκδοθεί session-id, η ακολουθία των μηνυμάτων του handshaking γίνεται:

Το request-certificate στέλνεται από τον server και περιέχει μια δήλωση για την συνάρτηση που θα χρησιμοποιήσει ο client για την παραγωγή της digest value και τον τύπο της συμμετρική κρυπτογράφησης (auth-type). Επίσης, αποστέλλονται και δεδομένα που θα υπογράψει ο client για να αποδείξει την ταυτότητα του (cert-chal-data).

Το client-certificate επιστρέφει στον server το πιστοποιητικό του client, μαζί με μια δήλωση του τύπου αυτού (cert-type )και την υπογραφή των δεδομένων cert-chal-data. Ο server θα χρησιμοποιήσει την δημόσια κλείδα που περιέχεται στο πιστοποιητικό του client για να αποκρυπτογραφήσει την υπογραφή. Έπειτα, θα υπολογίσει το message digest των cert-chal-data και θα το συγκρίνει με το message digest που προήλθε από την αποκρυπτογράφηση της υπογραφής.

Κατά την διάρκεια όλων των παραπάνω ανταλλαγών μηνυμάτων, μηνύματα λάθους μπορούν να σταλούν σαν απάντηση σε μηνύματα που δεν βγάζουν νόημα. Η διαδικασία αναγνώρισης λάθους και αποστολή του κατάλληλου μηνύματος αναλαμβάνεται από το πρωτόκολλο SSL Alert Protocol και είναι μέρος του SSL Handshake Protocol. Έτσι, το μήνυμα no-cipher-error στέλνεται όταν ο server δεν υποστηρίζει κανένα από τους αλγόριθμους που προτείνει ο client, το μήνυμα no-certificate-error όταν δεν είναι διαθέσιμο το ζητηθέν πιστοποιητικό, το μήνυμα bad-certificate αν το πιστοποιητικό είναι άκυρο και τέλος το unsupported-certificate-type-error, όταν ο τύπος ενός πιστοποιητικού δεν υποστηρίζεται από κανέναν.

5.3.6 Αντοχή του SSL σε Γνωστές Επιθέσεις

Dictionary Attack

Το SSL δεν απειλείται από αυτήν την επίθεση αφού τα κλειδιά των αλγορίθμων του είναι πολύ μεγάλα των 128 bit. Ακόμα και οι αλγόριθμοι σε εξαγόμενα προϊόντα, υποστηρίζουν 128 bit κλειδιά και παρ' όλο που τα 88 bit αυτών μεταδίδονται ανασφάλιστα, ο υπολογισμός 2⁴⁰ διαφορετικών ακολουθιών κάνει την επίθεση αδύνατο να επιτύχει.

Brute Force Attack

Η επίθεση αυτή πραγματοποιείται με την χρήση όλων των πιθανών κλειδιών για την αποκρυπτογράφηση των μηνυμάτων. Όσο πιο μεγάλα σε μήκος είναι τα χρησιμοποιούμενα κλειδιά, τόσο πιο πολλά είναι τα πιθανά κλειδιά. Τέτοια επίθεση σε αλγορίθμους που χρησιμοποιούν κλειδιά των 128 bits είναι τελείως ανούσια. Μόνο ο DES56 bit cipher είναι ευαίσθητος σε αυτήν την επίθεση, αλλά η χρήση του δεν συνιστάται.

Replay Attack

Όταν ένας τρίτος καταγράφει την ανταλλαγή μηνυμάτων μεταξύ client και server και προσπαθεί να ξανά χρησιμοποιήσει τα μηνύματα του client για να αποκτήσει πρόσβαση στον server, έχουμε την επίθεση replay attack. Όμως το SSL κάνει χρήση του connection-id, το οποίο παράγεται από τον server με τυχαίο τρόπο και διαφέρει για κάθε σύνδεση. Έτσι δεν είναι δυνατόν πότε να υπάρχουν δυο ίδια connection-id και το σύνολο των είδη χρησιμοποιημένων μηνυμάτων δεν γίνονται δεκτά από τον server. Το connection-id έχει μέγεθος 128 bit για πρόσθετη ασφάλεια.

Man-In-The-Middle-Attack

Το SSL υποχρεώνει τον server να αποδεικνύει την ταυτότητα του με την χρήση έγκυρου πιστοποιητικού του οποίου η τροποποίηση είναι αδύνατον. Μην ξεχνάμε την δυνατότητα επικοινωνίας των κλειδιών υπογεγραμμένα.

Brute Force Attack Εναντίον Αδύναμων Αλγορίθμων

Η μεγαλύτερη αδυναμία του πρωτοκόλλου είναι η ευαισθησία των αλγόριθμων που χρησιμοποιούν μικρά κλειδιά. Συγκεκριμένα, οι RC4-40, RC2-40 και DES-56 εισάγουν σοβαρά προβλήματα ασφαλείας και θα πρέπει να αποφεύγονται.

Renegotiation of Session Keys (μόνο στην 2 έκδοση)

Από την στιγμή που μία σύνδεση δημιουργηθεί, το ίδιο master key χρησιμοποιείται καθ' όλη την διάρκεια της. Όταν το SSL χρησιμοποιείται πάνω από μια μακρόχρονη σύνδεση (π.χ. μιας TELNET εφαρμογής), η αδυναμία αλλαγής του master key γίνεται επικίνδυνη. Η καλύτερη μέθοδος επίλυσης αυτού του προβλήματος είναι η επαναδιαπραγμάτευση του κλειδιού σε τακτά χρονικά διαστήματα, μειώνοντας έτσι την πιθανότητα μιας επιτυχής Brute Force Attack.

5.3.8 Χρήσεις του SSL

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

Παρ' όλο που μπορεί κανείς να γράψει μια εφαρμογή του SSL ακολουθώντας τα Internet drafts και RFCs, είναι προτιμότερο να χρησιμοποιήσει μία από τις υπάρχοντες βιβλιοθήκες εργαλείων του SSL (SSL toolkit Libraries). Τέτοιες βιβλιοθήκες περιέχούν ρουτίνες για κρυπτογράφηση, digestion, και διαχείριση πιστοποιητικών και διακρίνονται στις ακόλουθες:

• SSLRef
• SSLPlus
• SSLava
• SSLeay

5.3.9 Περαιτέρω Πληροφορίες

Στις ηλεκτρονικές σελίδες που ακολουθούν, αποτελούν την πηγή της παρούσας παρουσίασης. Η τελευταία από αυτές περιέχει το draft του SSL και περιλαμβάνει όλες τις λεπτομέρειες του πρωτοκόλλου.

Introducing SSL and Certificates -- http://www.ultranet.com/~fhirsch/Papers/cook/ssl_intro.html#intrο

SSLP Project - The Secure Sockets Layer http://www.cs.bris.ac.uk/~bradley/publish/SSLP/chapter4.html

SSLP Project - Contents Page -- http://www.cs.bris.ac.uk/~bradley/publish/SSLP/contents.html

SSL Protocol V. 3.0 -- http://home.netscape.com/eng/ssl3/ssl-toc.html

5.4 S/MIME (Secure ΜΙΜΕ)

Το S/ΜΙΜΕ είναι μια εξειδίκευση του πρωτοκόλλου MIME και αναπτύχθηκε για την ασφαλή ανταλλαγή ηλεκτρονικών μηνυμάτων. Σκοπός του είναι η καταπολέμηση της πλαστογραφίας και της υποκλοπής ηλεκτρονικών μηνυμάτων καθώς και η ευκολία στην χρήση. Σχεδιάστηκε ώστε να μπορεί εύκολα να ενοποιηθεί σε προϊόντα ηλεκτρονικού ταχυδρομείου, επεκτείνοντας το πρωτόκολλο MIME σύμφωνα με ένα σύνολο κρυπτογραφικών τυποποιήσεων, το Public Key Cryptography Standards (PKCS).

Η παγκόσμια υιοθέτηση του S/ΜΙΜΕ θα επωφελήσει τους χρήστες, αφού έννοιες όπως η ακεραιότητα των δεδομένων, η αυθεντικότητα και η διαφύλαξη του απόρρητου των συναλλαγών (privacy), θα είναι διαθέσιμες σε όλους.

Πριν προχωρήσουμε σε λεπτομέρειες για το S/ΜΙΜΕ, και για να γίνουν κατανοητά αυτά που θα ακολουθήσουνε, θα πρέπει να περιγράψουμε σε γενικές γραμμές το πρωτόκολλο MIME.

5.4.1 ΜΙΜΕ (Multipurpose Internet Mail Extensions)

Το ηλεκτρονικό ταχυδρομείο του Internet επιτρέπει σε χρήστες από όλο τον κόσμο να ανταλλάσσουν μηνύματα, παρέχοντας έναν τυποποιημένο μηχανισμό που λειτουργεί ανεξάρτητα από την εκάστοτε από υποκείμενη πλατφόρμα.

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

• Μπορούσε να περιέχει μόνο ASCII χαρακτήρες.
• Οι γραμμές δεν ξεπερνούσαν τους 1000 χαρακτήρες.
• Το μήνυμα δεν ξεπερνούσε συγκεκριμένο μήκος.

Τα περιεχόμενα έπρεπε να είναι απλό κείμενο στην αγγλική γλώσσα, όπως ορίζεται από το RFC822.

Δεδομένα όπως τα Electronic Data Interchange (EDI) δεν μπορούσαν να μεταδοθούν αξιόπιστα, καθ’ ότι παραβίαζαν όλους τους παραπάνω κανόνες. Πιθανόν, να ήταν εφικτή η δημιουργία μηνυμάτων με μουσικά κομμάτια ή κάποιο έγγραφο postscript, αλλά η κωδικοποιημένη του μορφή δεν αναγνωριζόταν από μηχανές διαφορετικής προέλευσης και ακόμα η μεταφορά του μέσα από κάποιον mail gateway ήταν αδύνατη.

Τον Ιούνιο του 1992, ένα νέο πρωτόκολλο του Internet καθιερώθηκε, το ΜΙΜΕ. ΜΙΜΕ είναι το ακρωνύμιο της αγγλικής φράσης Multipurpose Internet Mail Extensions και χτίζεται πάνω στο RFC822, προσφέροντας έναν τρόπο για την ανταλλαγή κειμένου σε γλώσσες εκτός της αγγλικής και μηνυμάτων πολυμέσων μεταξύ διαφορετικών υπολογιστικών συστημάτων. Συγκεκριμένα, ένα μήνυμα συμβατό του ΜΙΜΕ μπορεί να περιέχει:

• Πολλαπλά αντικείμενα.
• Κείμενο με απεριόριστο μήκος και απεριόριστο μήκος γραμμών.
• Σύνολα χαρακτήρων πέρα από το US – ASCII, επιτρέποντας την σύνταξη μηνυμάτων σε διάφορες γλώσσες.
• Εμπλουτισμένο κείμενο, χρήση δηλαδή διάφορων τυπογραφικών στοιχείων (fonts).
• Εικόνα, κινούμενη εικόνα, ήχο.
• Δυαδικά αρχεία ή αρχεία εφαρμογών (tar files, postscript files).
• Δείκτες σε αρχεία αποθηκευμένα σε άλλους υπολογιστές.

Το ΜΙΜΕ υποστηρίζει αρκετούς προκαθορισμένους τύπους περιεχομένων, όπως 8 bit μ-LAW audio με δειγματοληψία 8 kHz, αρχεία εικόνων GIF, προγράμματα postscript και επιπλέον επιτρέπει στους χρήστες να καθορίζουν τους δικούς τους τύπους δεδομένων. Λογισμικό που ενσωματώνει το ΜΙΜΕ, παράγει μηνύματα ηλεκτρονικού ταχυδρομείου με περιεχόμενα που μπορούν αναμφίβολα να αναγνωριστούν, ενώ όταν το ίδιο λογισμικό επεξεργάζεται ένα εισερχόμενο μήνυμα, είναι σε θέση να διαχειριστεί όλη την πληροφορία που δεν προορίζεται για τον χρήστη και να τον προστατέψει από την μη ερμηνεύσιμη απόδοση της.

Ένα μήνυμα ΜΙΜΕ αποτελείται από πολλά κομμάτια που καλούνται body parts και κάθε κομμάτι αντιπροσωπεύει ένα ξεχωριστό αντικείμενο (ηχητικό μήνυμα, κείμενο, αρχείο κτλ.). Κάθε body part με την σειρά του αποτελείται από τον κορμό (body) και από τις επικεφαλίδες (headers). Στον κορμό υπάρχουν τα δεδομένα που προορίζονται για τον χρήστη, ενώ στις επικεφαλίδες περιλαμβάνονται πληροφορίες που χρησιμοποιεί το πρόγραμμα του χρήστη.

Περιληπτικός Πίνακας Επικεφαλίδων του ΜΙΜΕ:

Content-type

Μια από τις βασικότερες επικεφαλίδες του ΜΙΜΕ, γύρω από την οποία έχει χτιστεί όλη η φιλοσοφία προσέγγισης του πρωτοκόλλου, είναι η επικεφαλίδα Content-Type. Εάν περιέχεται στις επικεφαλίδες ενός μηνύματος, τότε η τιμή της υποδεικνύει το είδος των περιεχομένων που υπάρχει στον κορμό (body) του μηνύματος. Διαχωρίζεται στις παρακάτω παραμέτρους:

• type, λειτουργεί σαν γενικός οδηγός για τις πηγές που απαιτούνται για την επεξεργασία των δεδομένων που βρίσκονται στον κορμό,
• subtype, προσδιορίζει περισσότερο το είδος των περιεχομένων,
• μηδέν ή περισσότεροι υποπαράμετροι που ρυθμίζουν τα περιεχόμενα.

Η σύνταξη της επικεφαλίδας content-type είναι:

Content-type: = type "/" subtype [";" parameter]

Υπάρχουν δύο μηχανισμοί για την επέκταση των υπαρχόντων τύπων: (α) εάν κάποιο τοπικό περιβάλλον επιθυμεί να καθορίσει τους δικούς του τύπους, μπορεί να το κάνει παραθέτοντας μπροστά από τις παραμέτρους type ή subtype το γράμμα "-X" και (β) τα Internet standards επιτρέπεται να καθορίσουν νέόυς τύπους αρκεί να μην συγκρούονται με τους τυποποιημένους και να μην ξεκινούν με "-Χ".

Παρακάτω ακολουθεί μια γρήγορη αναφορά στους τυποποιημένους τύπους περιεχομένων:

1. Multipart type

Subtypes: mixed, parallel, digest, alternative.

2. Message type

Subtypes: rfc822, partial, external-body.

3. Text type

Subtypes: plain, richtext.

4. Image type

Subtypes: gif, jpeg.

5. Audio type

Subtypes: basic.

6. Video type

Subtypes: mpeg.

7. Application type

Subtypes: octet-stream, oda, postscript.

Αναλυτικά, για τον καθένα τύπο έχουμε:

1. Multipart: Αυτός ο τύπος υποδεικνύει ότι τα δεδομένα αποτελούνται από πολλαπλά body parts και συνεπώς από πολλαπλά αντικείμενα, το καθένα από τα οποία ίσως είναι διαφορετικού τύπου. Το κάθε body part έχει παρόμοια δομή με ένα ολοκληρωμένο ηλεκτρονικό μήνυμα, δηλαδή περιέχει τις δικές του επικεφαλίδες που αλλάζουν από body part σε body part. Εάν δεν υπάρχει Content-Type επικεφαλίδα, τότε χρησιμοποιείται η τιμή text/plain που σημαίνει ότι ο κορμός περιέχει μη δομημένο κείμενο ASCII χαρακτήρων.

Ο διαχωρισμός των αντικείμένων γίνεται με την παρουσία ειδικών ακολουθιών χαρακτήρων μεταξύ τους, που καλούνται boundary. Αποτελείται από μια γραμμή που ξεκινά με δύο παύλες και ακολουθούν έως και 70 χαρακτήρες. Οι χαρακτήρες διαλέγονται ώστε να μην ταυτίζονται με τους πρώτους χαρακτήρες οποιαδήποτε γραμμής του κορμού. Η επιλογή αυτών των γίνεται είτε με εξέταση κάθε κείμενου, είτε με την παραγωγή τυχαίων ακολουθιών των οποίων η πιθανότητα να συναντηθούν σε οποιοδήποτε από τα body parts είναι μηδαμινή. Το τελευταίο διαχωριστικό (closing boundary) έχει ακόμα δύο παύλες στο τέλος της γραμμής. Η χρησιμοποιούμενη ακολουθία χαρακτήρων προσδιορίζεται από την παράμετρο boundary στην επικεφαλίδα Content-Type/multipart.

Υπάρχουν τέσσερα subtypes:

• mixed: υποδηλώνει την εν σειρά επεξεργασία των body parts.
• parallel: υποδηλώνει παράλληλη επεξεργασία των body parts. Σε περίπτωση, όμως, που δυο διαφορετικά αντικείμενα απαιτούν την αποκλειστική πρόσβαση σε μια κοινή πηγή (π.χ. πληκτρολόγιο) ή εάν το σύστημα δεν είναι σε θέση να εξομοιώσει παράλληλη επεξεργασία, τότε η παρουσίαση γίνεται εν σειρά.
• digest: υποδεικνύει ότι κάθε body part είναι ένα ενθυλακωμένο ηλεκτρονικό ταχυδρομικό μήνυμα της μορφής RFC822.
• alternative: συντακτικά είναι παρόμοιος με τον Multipart/mixed. Κάθε body part είναι μια εναλλακτική έκδοση της ίδιας πληροφορίας και το πρόγραμμα ανάγνωσης μηνυμάτων πρέπει είτε να επιλέξει τον καταλληλότερο κρίνοντας από το περιβάλλον εργασίας του χρήστη, είτε να προσφέρει στον χρήστη τις διαθέσιμες εναλλακτικές παρουσιάσεις.

Content-Type: multipart/mixed; boundary=gc0y0pkb9ex

Παράδειγμα ενός multipart/mixed μηνύματος είναι:

Σε αυτό το παράδειγμα, μόνο οι χρήστες με συστήματα που κατανοούν τον τύπο text/x-whatever, θα μπορέσουν να δουν την τελευταία μορφή, ενώ οι υπόλοιποι θα αρκεστούν στις μορφές richtext και text.

Τέλος, πρέπει να σημειώσουμε ότι επιτρέπεται η χρήση του τύπου multipart στις επικεφαλίδες ενός body part που περιέχεται σε multipart μήνυμα (η δημιουργία, δηλαδή, φωλιασμένων multipart τύπων), αλλά πρέπει να τηρηθεί προσοχή στην επιλογή του διαχωριστικού του καθενός εκ των φωλιασμένων τύπων.

2. Message: Συνοδεύει περιεχόμενα που αποτελούν ένα ακόμα ηλεκτρονικό μήνυμα, αποτελώντας έναν τρόπο ενθυλάκωσης μηνυμάτων.

Υπάρχουν τρία subtypes:

• rfc822: το ενθυλακωμένο μήνυμα είναι συντεταγμένο σύμφωνα με το RFC822.
• partial: χρησιμοποιείται όταν ένα μήνυμα είναι πολύ μεγάλο για να διαχειριστεί επιτυχώς. Το μήνυμα τεμαχίζεται και μεταδίδεται σε μικρότερα κομμάτια και η αναδόμηση του τεμαχισμένου μηνύματος γίνεται αυτόματα από το λογισμικό του παραλήπτη. Παράμετροί αυτού του subtype είναι:

• external-body: υποδηλώνει ότι τα περιεχόμενα είναι δείκτης σε δεδομένα αποθηκευμένα σε άλλον υπολογιστή. Ο τρόπος με τον οποίο τα πραγματικά περιεχόμενα θα γίνουν διαθέσιμα καθορίζεται από την παράμετρο access-type και μπορεί να έχει τις εξής τιμές:

Παράδειγμα αυτού του τύπου είναι:

3. Text: Χρησιμεύει για την αποστολή υλικού μορφής κειμένου και είναι ο προκαθορισμένος τύπος σε περίπτωση απουσίας της επικεφαλίδας Content-Type. Έχει μία pαράμετρο που καθορίζει το σύνολο χαρακτήρων (character set), η charset.

Ο συγκεκριμένος τύπος έχει δύο subtypes:

• plain: υποδηλώνει την ύπαρξη απλού, μη μορφοποιημένου, χωρίς δομή κειμένου που δεν απαιτεί ειδικό λογισμικό για την σωστή και πλήρη εμφάνιση του στην οθόνη του χρήστη, εκτός από την υποστήριξη της γλώσσας στην οποία είναι γραμμένο.
• richtext: υποδηλώνει ότι το κείμενο είναι εμπλουτισμένο, δηλαδή ότι τροποποιήθηκε με κατάλληλη γλώσσα μορφοποίησης.

Content-Type: text/plain; Charset=US-ASCII.

4. Image: Συνοδεύει αντικείμενα που ανταποκρίνονται σε ακίνητη εικόνα.

Τα δύο subtypes είναι:

• gif: αρχεία εικόνων κωδικοποιημένα με τον αλγόριθμο της Compuserve, Graphic Interchange Format (GIF).
• jpeg: αρχεία εικόνων κωδικοποιημένα σύμφωνα με το ISO/IEC 10918.

5. Audio: Συνοδεύει αρχεία που περιέχουν ψηφιακό ήχο.

Έχει ένα subtype:

• basic: δεδομένα ήχου με κωδικοποίηση 8bit ISDN μ-LAW, με δειγματοληψία στα 8 kHz και ένα κανάλι.

6. Video: Υποδηλώνει δεδομένα κινούμενης εικόνας, πιθανώς συνοδευόμενα από ήχο (soundtrack).

Το μοναδικό subtype είναι:

• mpeg: κωδικοποίηση βάση του ISO/IEC 11172.

7. Application: Τα περιεχόμενα δεν ανήκουν σε καμία από τις παραπάνω κατηγορίες και μπορεί να είναι δυαδικής μορφής δεδομένα ή πληροφορία που απευθύνεται σε προγράμματα με δυνατότητες ταχυδρόμησης ηλεκτρονικών μηνυμάτων (mail-enabled applications).

Υπάρχουν τρία subtypes:

• octet-stream: τα δεδομένα των είναι δυαδικής μορφής. Έχει τέσσερις παραμέτρους:

• oda: τα δεδομένα είναι κωδικοποιημένα με το Open Document Interchange Format (ODIF), όπως ορίζεται στην τυποποίηση ISO/IEC 8613. Υπάρχει μια παράμετρος:

• postscript = τα περιεχόμενα είναι αρχείο postscript.

Ο τύπος application/octet-stream συνδυασμένος με τεμαχισμό του μηνύματος, μπορεί να χρησιμοποιηθεί για την μεταφορά αρχείων μέσω του ηλεκτρονικού ταχυδρομείου, αντικαθιστώντας τον μηχανισμό FTP.

Content-Transfer-Encoding

Πολλούς από τους παραπάνω τύπους περιεχομένων στην φυσική τους μορφή παρουσιάζονται σαν χαρακτήρες 8 bit ή δυαδικά δεδομένα. Τέτοιου είδους δεδομένα δεν μπορούν να μεταφερθούν με πρωτόκολλα όπως το SMTP (Simple Mail Transfer Protocol) λόγω των περιορισμών που ασκούνται στο μήκος των γραμμών (όχι μεγαλύτερο από 1000 χαρακτήρες) και στο χρησιμοποιούμενο σύνολο χαρακτήρων (επιτρέπεται μόνο 7 bit ASCII). Γι' αυτό το λόγο, κρίνεται απαραίτητη η κωδικοποίηση των μηνυμάτων σε μορφή τέτοια που να επιτυγχάνεται η αλάνθαστή μεταφορά τους.

Υπάρχουν μερικά θέματα που αξίζει να αναφερθούμε, τα οποία έχουν να κάνουν με τον τρόπο που γίνεται η κωδικοποίηση πριν την μετάδοση (transfer-encoding). Κατ' αρχήν, οι τύποι multipart και message δεν επιτρέπουν άλλο σχήμα κωδικοποίησης εκτός του 7 bit ASCII, ενώ για τους υπόλοιπους τύπους δεν ισχύει κάτι τέτοιο. Επιπλέον, οι διαδικασίες της κωδικοποίησης και της αποκωδικοποίησης θα πρέπει να αντιμετωπίζονται σαν τελείως διαφορετικές ενέργειες από αυτή της επεξεργασίας των δεδομένων. Κατ' αυτόν τον τρόπο τα δεδομένα αποκωδικοποιούνται στην πρωτογενή μορφής τους πριν την επεξεργασίας τους. Τέλος, παρ' όλο του ότι το ΜΙΜΕ επιτρέπει την επεκτασιμότητα των μηχανισμών κωδικοποίησης, η χρήση νέων, μη καθιερωμένων δεν συνιστάται λόγω σημαντική μείωση της δια - λειτουργικότητας.

Οι τιμές της επικεφαλίδας Content-Transfer-Encoding μπορεί να είναι:

• Quoted-Printable
• Base64
• 8bit
• 7bit
• binary
• X-EncondingName.

Quoted-Printable: Αυτό το σχήμα κωδικοποίησης είναι πιο κατάλληλο για δεδομένα που αποτελούνται κατά κύριο λόγο από εκτυπώσιμους ASCII χαρακτήρες (δηλαδή 7 bit) και ένα, μόνο, μικρό ποσοστό 8 bit χαρακτήρων. Χρησιμοποιείται επίσης όταν υπάρχει πιθανότητα κάποιος ενδιάμεσος mail transfer agent (MTA) να αλλάξει τους μη αλφαριθμητικούς χαρακτήρες. Με αυτήν την μέθοδο οι εκτυπώσιμοι χαρακτήρες παρουσιάζονται αμετάβλητοι και το σήμα της ισότητας (=) υπηρετεί σαν χαρακτήρας διαφυγής.

Ο κανόνας σύμφωνα με τον οποίο γίνεται η διαμόρφωση των δεδομένων είναι απλός: οι 8 bit χαρακτήρες, το σήμα ισότητας (=) και οι χαρακτήρες διαστήματος και tabs, κωδικοποιούνται σαν μια ακολουθία 3 χαρακτήρων, που ξεκινά με το σήμα ισότητας (=) και ακολουθείται με δεκαεξαδική παρουσίαση της τιμής του χαρακτήρα. Γραμμές μεγαλύτερες των 76 χαρακτήρων κόβονται μετά τον 75^ο χαρακτήρα και η γραμμή τερματίζεται με το σήμα ισότητας (=).

Τα πλεονεκτήματα της μεθόδου είναι ότι: (α) λίγοι επιπλέον χαρακτήρες απαιτούνται και (β) το μήνυμα μπορεί να διαβαστεί και από άτομα που δεν διαθέτουν προγράμματα με ΜΙΜΕ δυνατότητες.

Παράδειγμα κειμένου που έχει υποστεί τέτοια κωδικοποίηση είναι:

Παρατηρούμε ότι οι 7 bit χαρακτήρες είναι εύκολα κατανοητοί.

Base64: Είναι κατάλληλη μέθοδος για την αναπαράσταση δυαδικών αρχείων. Κάθε 3 bytes του επεξεργαζόμενου αρχείου, λαμβάνονται σαν ποσότητες των 24 bit και διαχωρίζονται σε 4 εξάδες bit. Έπειτα κάθε εξάδα αντιστοιχίζεται, βάσει ενός πίνακα 64 χαρακτήρων, με χαρακτήρα από συγκεκριμένο υποσύνολο του ASCII. Εάν δεν συμπληρώνονται 24 bit, τότε χρησιμοποιείται ο χαρακτήρα (=) σαν συμπλήρωμα.

Το ίδιο κείμενο που του προηγούμενου παραδείγματος με κωδικοποίηση base64:

Οι τιμές 8 bit, 7 bit και binary υποδηλώνουν ότι δεν έχει εφαρμοστεί καμιά κωδικοποίηση. Η χρήση τους περιορίζεται στην υπόδειξη του είδους της κωδικοποίησης που πρέπει να γίνει για την μετάδοση των δεδομένων σε συγκεκριμένο σύστημα.

7bit: τα δεδομένα παρουσιάζονται σε μικρές γραμμές, ASCII χαρακτήρων.

8bit: οι γραμμές είναι μικρές, αλλά μπορεί να περιλαμβάνονται και μη ASCII χαρακτήρες.

binary: οι χαρακτήρες δεν είναι ASCII και οι γραμμές δεν είναι μεγάλου μήκους, ακατάλληλες για μεταφορά με SMTP.

Όπως προαναφέραμε, πολλές εφαρμοσμένες εκδόσεις του ΜΙΜΕ υποστηρίζουν επιπλέον τιμές της επικεφαλίδας Content-Transfer-Encoding, με τυποποιημένες. Αυτές δηλώνονται με ένα "-Χ", δηλαδή "Content-Transfer-Encoding: X-my-new-encoding".

Επίσης πρέπει να διευκρινίσουμε ότι εάν μια επικεφαλίδα Content-Transfer-Encoding εμφανίζεται στις επικεφαλίδες του μηνύματος τότε αναφέρεται σε όλα το επί μέρους body parts αυτού, ενώ όταν εμφανίζεται στις επικεφαλίδες ενός body part, τότε ισχύει μόνο για τα περιεχόμενα του συγκεκριμένου body part. Η προκαθορισμένη τομή που επικρατεί σε απουσία της επικεφαλίδος είναι 7 bit.

ΜΙΜΕ-Version

Καθ' ότι το ΜΙΜΕ είναι συμβατό με το RFC822, δίνεται η δυνατότητα σε ένα πρόγραμμα ανάγνωσης ηλεκτρονικών μηνυμάτων να επεξεργάζεται και μηνύματα που δεν ακολουθούν τις προδιαγραφές του ΜΙΜΕ. Για να μπορεί κάθε πρόγραμμα ανάγνωσης να αναγνωρίζει τα ΜΙΜΕ μηνύματα, υπάρχει η επικεφαλίδα ΜΙΜΕ-Version. Αυτή καθορίζει τον αριθμό έκδοσης του χρησιμοποιούμενου ΜΙΜΕ πρωτοκόλλου.

ΜΙΜΕ-Version: 1.0

Content-ID και Content-Description

Μπορεί να είναι επιθυμητό τα περιεχόμενα ενός body να αναφέρονται σε κάποιο άλλο. Γι' αυτό το σκοπό, δίνεται σε κάθε body μία αναγνωριστική ετικέτα μέσω της επικεφαλίδας Content-ID, η οποία είναι όσο το περισσότερο μοναδική γίνεται.

Τέλος, η επικεφαλίδα Content-Description επιτρέπει την σύνδεση σχολίου με το αντικείμενο που μεταφέρεται στο μήνυμα. Και οι δύο προηγούμενες επικεφαλίδες είναι προαιρετικές.

Παρακάτω βλέπουμε ένα πολύπλοκο ΜΙΜΕ μήνυμα.

5.4.2 Προβλήματα ασφαλείας με το ΜΙΜΕ

Λογισμικό που εφαρμόζει το ΜΙΜΕ πρωτόκολλο μπορεί να προκαλέσει, όπως έχει αποδειχτεί, πολλά προβλήματα. Τα πιο σημαντικά από αυτά έχουν να κάνουν με τα postscript προγράμματα. Γνωστά παραδείγματα είναι η χρήσης τους για την αλλαγή των κωδικών σε εκτυπωτές postscript με αποτέλεσμα την άρνηση εξυπηρέτησης και αυθαίρετη διαχείριση αρχείων.

Πρέπει να πούμε επίσης, ότι τα ηλεκτρονικά μηνύματα του Internet και τα μηνύματα UUCP δεν είναι ασφαλή, αφού υπηρεσίες όπως η πιστοποίηση ταυτότητας και ακεραιότητα δεδομένων δεν παρέχονται από τα πρωτόκολλα SMTP, RFC822 και ΜΙΜΕ.

5.4.3 Περαιτέρω Πληροφορίες για το ΜΙΜΕ

Για μια πιο λεπτομερή μελέτη, ο αναγνώστης μπορεί να απευθυνθεί στις εξής ηλεκτρονικές σελίδες:

MIME (Multipurpose Internet Mail Extensions) -- http://www.oac.uci.edu/indiv/ehood/MIME/MIME.html

(MIME) Table of Contents -- http://www.oac.uci.edu/indiv/ehood/MIME/toc.html

Το S/MIME είναι ένα πρωτόκολλο που χρησιμοποιείται από προγράμματα ηλεκτρονικού ταχυδρομείου για την εφαρμογή κρυπτογραφικών υπηρεσιών σε αποστέλλοντα μηνύματα και για την επεξεργασία προστατευμένων παραληφθέντων. Η δεύτερη έκδοση του S/MIME είναι επί του παρόντος ενσωματωμένη σε πολλά δημοφιλή προϊόντα, όπως τα Lotus Domino, Netscape Communicator, Novell GroupWise και Microsoft Exchange. Το S/MIME δίνει την δυνατότητα σε εταιρίες που σχεδιάζουν λογισμικό να αναπτύσσουν προγράμματα τέτοια ώστε ένα μήνυμα που κρυπτογραφήθηκε με ένα συγκεκριμένο πρόγραμμα να μπορεί να αποκρυπτογραφηθεί από ένα άλλο.

Η ομάδα Internet Engineering Task Force (IETF) αναπτύσσει την 3^η έκδοση του S/MIME που περιλαμβάνει την εξειδίκευση Cryptographic Message Syntax (CMS) που ορίζει μια τυποποιημένη σύνταξη για την επικοινωνία των κρυπτογραφικών πληροφοριών που είναι ανεξάρτητες από την μορφή των ενθυλακωμένων περιεχομένων ή από τον μηχανισμό μεταφοράς. Κάθε τύπος δεδομένων μπορεί να προστατευθεί από το CMS. Εκτός από τις εφαρμογές S/MIME, το CMS μπορεί να χρησιμοποιηθεί με τα πρωτόκολλα HTTP, X.400, FTP, SSL και SET. Η στρατηγική ανάπτυξης της τρίτης έκδοσης είναι τέτοια ώστε να διατηρείται η συμβατότητα με την προηγούμενη έκδοση (version 2). Αυτό επιτυγχάνεται με την πρόσθεση νέων, προαιρετικών στοιχείων στην νέα έκδοση, των οποίων η απουσία στις επικεφαλίδες επιτρέπει την συνεργασία των δύο εκδόσεων.

Επίσης, η έκδοση 3 του S/MIME απαιτεί την ύπαρξη ενός ελάχιστου συνόλου κρυπτογραφικών αλγορίθμων που διασφαλίζουν την συνεργασίας μεταξύ διαφορετικών εφαρμογών.

Η περιγραφή του S/MIME v3, που αναπτύχθηκε από την ομάδα IETF περιλαμβάνει τα εξής έγγραφα:

• Cryptographic Message Syntax (CMS): Όπως προείπαμε, το CMS ορίζει ένα τυποποιημένο τρόπο σύνταξης για την ανταλλαγή κρυπτογραφικών πληροφοριών που σχετίζονται με τα προστατευμένα περιεχόμενα. Το CMS βασίζεται στο PKCS #7 Version 1.5 που χρησιμοποιείται στα τρέχοντα προϊόντα S/MIME. στο τελευταίο έχουν ενσωματωθεί προαιρετικά χαρακτηριστικά ασφάλειας όπως η ακεραιότητα δεδομένων (integrity), η πιστοποίηση ταυτότητας (authentication), η εξασφάλιση της μη αποκήρυξης της προέλευσης (non-repudiation of origin) και της διασφάλισης του απόρρητου (privacy).

• S/MIME Version 3 Message Specification: Ορίζει την ΜΙΜΕ κωδικοποίηση που χρησιμοποιείται για την μεταφορά περιεχομένων προστατευμένων από το CMS. Συγκεκριμένα, καθορίζει τις διάφορες επιλογές για την ενθυλάκωση αυτών των περιεχομένων στα ΜΙΜΕ μηνύματα και προστίθενται οι νέοι τύποι περιεχομένων multipart/signed και application/pkcs7-siganture. Όλα τα προγράμματα με εφαρμοσμένο το S/MIME πρέπει να συμμορφώνονται με αυτό το έγγραφο.
• S/MIME Version 3 Certificate Handling System: Υποχρεώνει την υποστήριξη των πιστοποιητικών Χ.509, που μαζί με τις Λίστες Ανάκλησης Πιστοποιητικών (Certificate Revocation Lists) χρησιμοποιούνται για την πιστοποίηση ταυτότητας και την διαχείριση κλείδων.
• Enhanced Security Services: Το έγγραφο αυτό περιγράφει προαιρετικές υπηρεσίες ασφάλειας που μπορούν να παρέχονται σε συνδυασμό με την CMS προστασία. Οι προβλεπόμενες προαιρετικές υπηρεσίας είναι:

1. Υπογεγραμμένες αποδείξεις (Signed Receipts): παρέχει αυθεντικές αποδείξεις παραλαβής μηνυμάτων.
2. Ετικέτες Ασφαλείας (Security Labels): παρέχει την δυνατότητα ιεράρχησης των επιπέδων ασφάλειας, συνδέοντας τα δεδομένα με ετικέτες ευαισθησίας.
3. Ταχυδρομικές Λίστες (Mail Lists): επιτρέπει στις ταχυδρομικές λίστες να διαχειρίζονται ασφαλισμένα μηνύματα.
4. Υπογεγραμμένα Πιστοποιητικά (Signing Certificates): εξασφαλίζει την αυθεντικότητα των πιστοποιητικών.

5.4.5 Δημιουργία S/MIME μηνυμάτων

Τα μηνύματα S/MIME είναι συνδυασμός ΜΙΜΕ μηνυμάτων και CMS αντικειμένων. Τα CMS αντικείμενα περιγράφουν το είδος της ασφάλειας που θέλουμε να εφαρμόσουμε και μπορεί να είναι Ψηφιακός Φάκελος (Enveloped-Data), Υπογεγραμμένα δεδομένα (Signed-Data) και άλλα. Μπορούν να χρησιμοποιηθούν όλοι οι τύποι δεδομένων του ΜΙΜΕ, χωρίς κανένα περιορισμό. Το ΜΙΜΕ μήνυμα, μαζί με άλλες πληροφορίες (πιστοποιητικά, αναγνωριστικά αλγόριθμων κ.α.), επεξεργάζονται από τις διαδικασίες του CMS και παράγεται το CMS αντικείμενο. Τέλος, το CMS αντικείμενο τυλίγεται σε εξωτερικό ΜΙΜΕ μήνυμα με κατάλληλες επικεφαλίδες.

Προετοιμασία

Η ΜΙΜΕ οντότητα που θα ασφαλιστεί από το S/MIME μπορεί να είναι είτε μέρος ενός μηνύματος, είτε ολόκληρο μήνυμα. Σε περίπτωση που η ΜΙΜΕ οντότητα ισοδυναμεί με ολόκληρό το μήνυμα, περιλαμβάνονται σ' αυτήν όλες τις ΜΙΜΕ επικεφαλίδες (δεν περιλαμβάνονται οι επικεφαλίδες του RFC822) και φυσικά τα περιεχόμενα.

Η διαδικασία που προετοιμάζει το μήνυμα/οντότητα για επεξεργασία από το CMS αποτελείται από 3 βασικά βήματα:

1. : Η ΜΙΜΕ οντότητα κατασκευάζεται σύμφωνα με τις υποδείξεις του τοπικού περιβάλλοντος. Το σύνολο χαρακτήρων και οι χαρακτήρες οριοθέτησης γραμμών (line delimiters) καθορίζονται από το τοπικό σύστημα.
2. : Η ΜΙΜΕ οντότητα μετατρέπεται σε κανονική μορφή (canonical form). Η μορφή αυτή είναι διεθνώς αναγνωρίσιμη και παρουσιάσιμη είναι ανεξάρτητη από την πλατφόρμα του εκάστοτε χρήστη. Ανάλογα με τον τύπο δεδομένων, οι ενέργειες που πρέπει να γίνουν ώστε να προκύψει αυτή η μορφή, διαφέρουν. Για παράδειγμα, για περιεχόμενα τύπου κειμένου ο χαρακτήρας οριοθέτησης γραμμών πρέπει να είναι το ζευγάρι <CR>CLF>, και το σύνολο χαρακτήρων πρέπει να είναι ένα από τα τυποποιημένα.

3. 

4. : Εφαρμόζεται κατάλληλη κωδικοποίηση μεταφοράς (transfer encoding). Απαιτείται όλες οι ΜΙΜΕ οντότητες που πρόκειται να ασφαλιστούν με το S/MIME, να είναι σε κωδικοποίηση 7bit, για σίγουρη και σωστή μεταφορά. Αυτό συμβαίνει γιατί δεν είναι βέβαιο κατά πόσο υποστηρίζεται η μεταφορά μηνυμάτων με κωδικοποίηση 8bit ή binary σε όλο το μονοπάτι από τον αποστολέα στον παραλήπτη. Εάν ένα τέτοιο μήνυμα συναντήσει ενδιάμεσο σύστημα που δεν μπορεί να μεταδώσει 8bit ή binary δεδομένα, τότε υπάρχουν τρεις επιλογές: (α) το σύστημα θα μπορούσε να αλλάξει το κωδικοποίηση μεταφοράς, ακυρώνοντας την υπογραφή, (β) το σύστημα θα μπορούσε να προωθήσει το μήνυμα όπως και να' χει, με καταστροφή του 8^ου bit και συνεπώς ακύρωσης της υπογραφής και (γ) το σύστημα θα μπορούσε να επιστρέψει το μήνυμα. Και τρεις επιλογές είναι απαράδεκτες. Οι μηχανισμοί, λοιπόν, Quoted-Printable και Base64 είναι απαραίτητοι.

CMS Αντικείμενα και CMS Επεξεργασία

Σ' αυτό το κεφάλαιο θα περιγράψουμε τα αντικείμενα ασφαλείας του CMS και πως αυτά κατασκευάζονται. Τα υποστηριζόμενα αντικείμενα είναι EnvelopedData, SignedData, DigestedData, EncryptedData και AuthenticatedData. Για κάθε αντικείμενο ο τύπος των περιεχομένων αλλάζει. Έτσι, το αντικείμενο EnvelopedData περιέχει δεδομένα σε ψηφιακό φάκελο (θα δούμε παρακάτω τι σημαίνει αυτό), το SignedData περιέχει υπογεγραμμένα δεδομένα, το EncryptedData περιέχει κρυπτογραφημένα δεδομένα, το DigestedData περιλαμβάνει την digest τιμή των δεδομένων και τέλος, το AuthenticatedData περιέχει πιστοποιημένα δεδομένα. Τα σημαντικότερα και περισσότερο χρησιμοποιούμενα αντικείμενα είναι τα SignedData και τα EnvelopedData, τα οποία και θα αναλύσουμε πιο πολύ. Εξάλλου, η υποστήριξη των υπόλοιπων αντικείμενων είναι προαιρετική.

Τα ασφαλισμένα περιεχόμενα δεν είναι η μόνη πληροφορία που περικλείεται σε ένα αντικείμενο. Υπάρχουν και άλλες πληροφορίες που προορίζονται για επεξεργασία από τα προγράμματα S/MIME και εισάγονται σε πεδία που καλούνται ιδιότητες (attributes). Πολλές φόρες, ίσως, αυτές οι ιδιότητες να απαιτούν προστασία είτε μέσω υπογραφής, είτε μέσω κρυπτογράφησης.

Επίσης, πρέπει να διευκρινιστεί, ότι όπου στο παρών κεφάλαιο αναφερόμαστε σε "περιεχόμενα οποιουδήποτε τύπου", εννοούμε δεδομένα απλά, κρυπτογραφημένα, υπογεγραμμένα, πιστοποιημένα ή συνοψισμένα (digested). Τα απλά δεδομένα ισοδυναμούν με την ΜΙΜΕ οντότητα, που είναι η είσοδος στην CMS επεξεργασία, ενώ οι υπόλοιποι τύποι αναφέρονται σε αντικείμενα του CMS, δηλαδή είδη προστατευμένα ΜΙΜΕ στοιχεία.

SignedData: Αποτελείται από περιεχόμενα οποιουδήποτε τύπου και μηδέν ή περισσότερες υπογραφές αυτών. Τα περιεχόμενα μπορούν να υπογραφούν παράλληλα από πολλούς χρήστες και τυπική εφαρμογή αυτού του τύπου είναι για την υπογραφή απλών δεδομένων ή για την μεταφορά πιστοποιητικών.

1. Για κάθε υπογράφοντα, παράγεται η συνοπτική τιμή (digest value) των περιεχομένων βάση αλγόριθμου που εξαρτάται από τον υπογράφοντα. Εάν μαζί με τα περιεχόμενα υπογράφονται και συγκεκριμένες ιδιότητες τότε παράγεται η digest value των περιεχομένων, εισάγεται σε ειδικό πεδίο των προς υπογραφή ιδιοτήτων και το τελικό message digest είναι η digest value των ιδιοτήτων.
2. Το message digest που προκύπτει από το προηγούμενο βήμα για κάθε υπογράφοντα, κρυπτογραφείται με την ιδιωτική κλείδα κάθε υπογράφοντα ξεχωριστά.
3. Για κάθε υπογράφοντα, το αποτέλεσμα της υπογραφής και άλλες πληροφορίες σχετικές με αυτόν συλλέγονται στο πεδίο SignerInfo. Το πεδίο αυτό υπάρχει μια φορά για κάθε χρήστη και αποτελείται από καταχωρήσεις που περιλαμβάνουν τα πιστοποιητικά της ταυτότητας του χρήστη (μαζί και την δημόσια κλείδα αυτού), τους αλγόριθμούς που χρησιμοποιήθηκαν και την υπογραφή αυτού.
4. Όλα τα πεδία SignerInfo, τα περιεχόμενα και επιπλέον πληροφορίες συλλέγονται και φτιάχνουν το αντικείμενο SignedData.

Ο παραλήπτης του μηνύματος/αντικειμένου υπολογίζει το message digest των περιεχομένων και με την δημόσια κλείδα του αποστολέα ανακτεί το κρυπτογραφημένο message digest που παρέλαβε με το μήνυμα. Συγκρίνει αυτά δύο, και εάν είναι ταυτόσημα, τότε έχει επαληθεύσει επιτυχώς την υπογραφή.

EnvelopedData: Αποτελείται από κρυπτογραφημένα περιεχόμενα οποιουδήποτε τύπου και κρυπτογραφημένα κλειδιά-κρυπτογράφησης για έναν ή περισσότερους αποδέκτες. Ο συνδυασμός των κρυπτογραφημένων περιεχομένων και του κρυπτογραφημένου κλειδιού, είναι ένας "ψηφιακός φάκελος". Για την επικοινωνία του κλειδιού-κρυπτογράφησης (του κλειδιού δηλαδή που χρησιμοποιήθηκε κατά την κρυπτογράφηση των περιεχομένων) υπάρχουν τρεις (3) τεχνικές και για κάθε παραλήπτη μπορεί να χρησιμοποιηθεί οποιαδήποτε από αυτές:

• key transport: το κλειδί κρυπτογραφείται με την δημόσια κλείδα του παραλήπτη.
• key agreement: η δημόσια κλείδα τού παραλήπτη και η ιδιωτική κλείδα τού αποστολέα χρησιμοποιούνται για να παράγουν (μέσω κατάλληλου αλγόριθμου) ένα συμμετρικό κλειδί το οποίο κρυπτογραφεί το κλειδί κρυπτογράφησης. Λόγω της μαθηματικής σχέσης που συνδέει την δημόσια κλείδα με την ιδιωτική κλείδα και της φύσης του αλγόριθμου, το ίδιο συμμετρικό κλειδί μπορεί να παράγει ο παραλήπτης, χρησιμοποιώντας την ιδιωτική του κλείδα και την δημόσια του αποστολέας.
• symmetric key-agreement: το κλειδί-κρυπτογράφησης, κρυπτογραφείται με συμμετρικό κλειδί που έχει πρωτύτερα διανεμηθεί.

1. Παράγεται το τυχαίο κλειδί κρυπτογράφησης.
2. Για κάθε παραλήπτη, κρυπτογραφείται το κλειδί-κρυπτογράφησης. Οι λεπτομέρειες αυτής της κρυπτογράφησης, εξαρτούνται από το ποία από τις παραπάνω τεχνικές χρησιμοποιείται.
3. Το κρυπτογραφημένο κλειδί και άλλες πληροφορίες που αφορούν κάθε παραλήπτη συλλέγονται στο πεδίο RecipientInfo. Το τελευταίο, όπως και το SignerInfo, περιέχει τα πιστοποιητικά κάθε χρήστη, την τεχνική που χρησιμοποιήθηκε, τους αλγόριθμους και το κρυπτογραφημένο κλειδί. Υπάρχει αριθμό ίσο με τον αριθμό των παραληπτών.
4. Τα περιεχόμενα κρυπτογραφούνται με το κλειδί-κρυπτογράφησης. Τα περιεχόμενα, ίσως, να χρειαστούν συμπλήρωμα (padding).
5. Τα πεδία RecipientInfo για όλους τους παραλήπτες, μαζί με τα κρυπτογραφημένα περιεχόμενα αποτελούν το αντικείμενο EnvelopedData.

Ο εκάστοτε παραλήπτης, αφού ανακτήσει το κρυπτογραφημένο κλειδί ακολουθώντας την τεχνική που υποδεικνύεται στο RecipientInfo πεδίο, αποκρυπτογραφεί τα περιεχόμενα του μηνύματος.

Θα αναφερθούμε σύντομα και στα υπόλοιπα, προαιρετικά αντικείμενα. Το DigestData συνίσταται από περιεχόμενα οποιουδήποτε τύπου και την digest value αυτών. Το EncryptedData διαφέρει από το EnvelopedData στο ότι το πρώτο δεν περιέχονται τα κλειδιά –κρυπτογράφησης κρυπτογραφημένα και δεν έχει παραλήπτες. Προορίζεται για τοπική κρυπτογράφηση αρχείων. Τέλος, το AuthenticatedData μοιάζει με το SignedData, με την διαφορά, ότι αντί για την υπογραφή του μηνύματος περιέχεται το Message Authentication Code (MAC).

Μέχρι τώρα έχουμε περιγράψει, πως προετοιμάζεται η ΜΙΜΕ οντότητα και πως δημιουργούνται τα CMS αντικείμενα από αυτήν. Το τελικό στάδιο παραγωγής ενός S/MIME μηνύματος είναι η περιτύλιξη του CMS αντικειμένου με ένα εξωτερικό ΜΙΜΕ επίπεδο και ασχοληθούμε με αυτό σε αυτό το κεφάλαιο.

Όπως αναφέραμε στην εισαγωγή, προστίθενται δύο νέες επικεφαλίδες, στις είδη υπάρχουσες επικεφαλίδες του ΜΙΜΕ: η multipart/signed και η application/pkcs7-mime. Αυτές οι νέες επικεφαλίδες χρησιμοποιούνται κατά την περιτύλιξη και εσωκλείουν τα CMS αντικείμενα.

Η multipart/signed υποδηλώνει μήνυμα με δυο body parts. Το πρώτο μέρος περιέχει αυτούσια την ΜΙΜΕ οντότητα που ασφαλίζεται, αφού υποστεί την προεργασία που περιγράφηκε προηγουμένως. Το δεύτερο μέρος περιέχει την υπογραφή της ΜΙΜΕ οντότητας και η επικεφαλίδα του body part είναι application/pkcs7-signature (βλέπε παρακάτω παράγραφο).

Η application/pkcs7-mime χρησιμοποιείται για να μεταφέρει CMS αντικείμενα διάφορων τύπων (Ψηφιακός Φάκελος, Υπογεγραμμένα Δεδομένα, κ.α.), τα οποία εμπεριέχουν μία ΜΙΜΕ οντότητα. Καθ' ότι τα CMS αντικείμενα είναι δυαδικά δεδομένα, ο κατάλληλος μηχανισμός κωδικοποίησης που πρέπει να χρησιμοποιηθεί είναι ο Base64, ειδικά όταν το πρωτόκολλο μεταφοράς είναι το SMTP. Εδώ πρέπει να πούμε ότι η κωδικοποίηση αυτή αναφέρεται στο CMS αντικείμενο και όχι στην ΜΙΜΕ οντότητα. Συνεπώς δεν υπάρχει σχέση με το 3^ο βήμα της προετοιμασίας του ΜΙΜΕ μηνύματος.

Όταν η τιμή της επικεφαλίδας είναι application/pkcs7-mime και η επέκταση του αρχείου το οποίο αποτελείται από το CMS αντικείμενο είναι .p7m τότε το αντικείμενο είναι είτε Ψηφιακός Φάκελος, είτε Υπογεγραμμένα Δεδομένα. Εάν η επέκταση είναι .p7c και η τιμή η ίδια με προηγουμένως, το αντικείμενο είναι μόνο πιστοποιητικά. Τέλος, εάν η τιμή είναι application/pkcs7-signature και η επέκταση .p7s, το αντικείμενο είναι σκέτη υπογραφή.

Φακελωμένo Μήνυμα (Enveloped Message)

1. Η ΜΙΜΕ οντότητα προετοιμάζεται κατάλληλα.
2. Η ΜΙΜΕ οντότητα και άλλες απαραίτητες πληροφορίες επεξεργάζονται για την κατασκευή του αντικειμένου EnvelopedData.
3. Στο CMS αντικείμενο EnvelopedData, προστίθεται η επικεφαλίδα application/pkcs7-mime και πραγματοποιείται η περιτύλιξη του τελικού σταδίου.

Παράδειγμα ενός S/MIME μηνύματος ασφαλισμένο κατά αυτόν τον τρόπο είναι:

Η παράμετρος smime-type καθορίζει το είδος του αντικείμενου και η επέκταση του μεταφερόμενου αρχείου είναι ".p7m". Ένα τέτοιο μήνυμα ,όμως, δεν προσφέρει ακεραιότητα δεδομένων.

Υπογεγραμμένο Μήνυμα (Signed Message)

Υπάρχουν δύο δυνατότητες για την παρασκευή υπογεγραμμένων μηνυμάτων. Η πρώτη περίπτωση περιλαμβάνει την χρήση της επικεφαλίδας application/pkcs7-mime και η δεύτερη την χρήση της multipart/signed.

application/pkcs7-mime: Τα βήματα είναι παρόμοια με αυτά του φακελωμένου μηνύματος.

1. Η ΜΙΜΕ οντότητα προετοιμάζεται κατάλληλα.
2. Η ΜΙΜΕ οντότητα και άλλες απαραίτητες πληροφορίες επεξεργάζονται για την κατασκευή του αντικειμένου SignedData.
3. Στο SignedData, προστίθεται η επικεφαλίδα application/pkcs7-mime και πραγματοποιείται η περιτύλιξη του τελικού σταδίου.

Παράδειγμα ενός τέτοιου S/MIME μηνύματος:

Και εδώ, η παράμετρος smime-type καθορίζει το είδος του αντικείμενου και η επέκταση του μεταφερόμενου αρχείου είναι ".p7m".

multipart/signed: Σε αυτήν την ΜΙΜΕ επικεφαλίδα, το περιεχόμενο SignedData αντικείμενο αποτελείται μόνο από την υπογραφή της ΜΙΜΕ οντότητας. Αυτό συμβαίνει γιατί όπως θα δούμε, το πρώτο body part περικλείει το αυθεντικό ΜΙΜΕ στοιχείο.

1. Η ΜΙΜΕ οντότητα προετοιμάζεται κατάλληλα.
2. Έπειτα, η ΜΙΜΕ οντότητα οδηγείται στην CMS επεξεργασία και προκύπτει ένα αντικείμενο SignedData, από το οποίο όμως αφαιρείται το υπογεγραμμένο περιεχόμενο (η ΜΙΜΕ οντότητα δηλαδή).
3. Το αποτέλεσμα του πρώτου βήματος, εισάγεται στο πρώτο μέρος του multipart μηνύματος.
4. Αφού κωδικοποιηθεί κατάλληλα για μεταφορά η υπογραφή (που αποκτήθηκε στο δεύτερο βήμα), εισάγεται στο δεύτερο μέρος του multipart μηνύματος με επικεφαλίδα body part, application/pkcs7-signature.

Στο παρακάτω σχήμα παρατηρούμε στο δεύτερο body part, την επέκταση του αρχείου, ".p7s" και την κωδικοποίηση μεταφοράς Base64.

Τις περισσότερες φορές, χρησιμοποιείται η περιτύλιξη με multipart/signed. Το εσωτερικό ενός τέτοιου μηνύματος μπορεί να αναγνωστεί και από χρήστες των οποίων τα προγράμματα δεν ενσωματώνουν τις S/MIME λειτουργίες. Βέβαια, αναγνώριση και επαλήθευση της υπογραφής στο δεύτερο body part δεν είναι δυνατόν να γίνει και άρα δεν μπορεί να επιβεβαιωθεί η ακεραιότητα των δεδομένων ούτε η ταυτότητα του αποστολέα.

Μήνυμα με Πιστοποιητικά (Certificate-only Message)

1. Τα πιστοποιητικά δίνονται για CMS επεξεργασία και προκύπτει αντικείμενο SignedData χωρίς υπογεγραμμένο περιεχόμενο και υπογραφή.
2. Προστίθεται η επικεφαλίδα application/pkcs7-mime και ολοκληρώνεται η ΜΙΜΕ περιτύλιξη.

Η παράμετρος smime-type, που είδαμε στα προηγούμενα παραδείγματα, είναι certs-only και η επέκταση του αρχείου είναι ".p7c".

Υπογράφοντας και Κρυπτογραφώντας

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

5.4.6 Triple Wrapping

Ένα μήνυμα τριπλά περιτυλιγμένο (triple wrapped) έχει υπογραφεί, έπειτα κρυπτογραφηθεί και τέλος ξανά υπογραφεί. Οι υπογράφοντες των εσωτερικών και εξωτερικών υπογραφών μπορεί να είναι διαφορετικές οντότητες ή η ίδια. Πρέπει να πούμε πως το S/MIME δεν περιορίζει τον αριθμό των φωλιασμένων ενθυλακώσεων και μπορούμε να έχουνε παραπάνω από τρεις.

Σκοπός του Triple Wrapping

Η εσωτερική υπογραφή χρησιμοποιείται για την ακεραιότητα την δεδομένων, την μη αποκήρυξη της ταυτότητας της πηγής (non-repudiation of origin) και για την σύνδεση συγκεκριμένων ιδιοτήτων, όπως η ετικέτα ασφαλείας (βλέπε παρακάτω) στα αρχικά περιεχόμενα. Αυτές οι ιδιότητες δεν αλλοιώνονται από τα ενδιάμεσα συστήματα μεταξύ αποστολέα και παραλήπτη, παρά απευθύνονται και επεξεργάζονται μονάχα από τον τελευταίο.

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

Η εξωτερική υπογραφή παρέχει πιστοποίηση ταυτότητας και ακεραιότητα των πληροφοριών που προσπελάσουν τα ενδιάμεσα υπολογιστικά συστήματα, για παράδειγμα ένας mail list agent. Επίσης, η εξωτερική υπογραφή, δένει κατάλληλες ιδιότητες στο κρυπτογραφημένο σώμα, οι οποίες προορίζονται για αποφάσεις δρομολόγησης (routing)και έλεγχο πρόσβασης.

Βήματα για Τριπλό Περιτύλιγμα.

1. Αρχικά έχουμε το "πρωτότυπο περιεχόμενο" (original content).
2. Προσθέτουμε στο πρωτότυπο περιεχόμενο κατάλληλες ΜΙΜΕ επικεφαλίδες (π.χ. Content-Type: text/plain).
3. Υπογράφουμε το αποτέλεσμα του βήματος 2.
4. Προσθέτουμε επικεφαλίδες, παραμέτρους και ιδιότητες, κατασκευάζοντας την τελική δομή του υπογεγραμμένου μέρους. Έχουμε δύο περιπτώσεις ανάλογα με τον τρόπο που υπογράφουμε:

(α) Εάν χρησιμοποιούμε την επικεφαλίδα "Content-Type: multipart/signed" η δομή είναι: η επικεφαλίδα "Content-Type: multipart/signed" μαζί με παραμέτρους, μια διαχωριστική γραμμή (boundary), το αποτέλεσμα του βήματος 2, η διαχωριστική γραμμή πάλι, έπειτα η επικεφαλίδα "Content-Type: application/pkcs7-signature", κάποιες ΜΙΜΕ επικεφαλίδες (π.χ. Content-Transfer-Encoding) και τέλος το αποτέλεσμα του βήματος 3.

(β) Εάν χρησιμοποιούμε την επικεφαλίδα "Content-Type: application/pkcs7-mime", η δομή είναι: η επικεφαλίδα "Content-Type: application/pkcs7-mime", ακολουθούμενη από ΜΙΜΕ επικεφαλίδες (π.χ. Content-Transfer-Encoding) και τέλος το αποτέλεσμα του βήματος 3.

Το αποτέλεσμα του καλείται "εσωτερική υπογραφή" (inside signature).

5. Κρυπτογραφούμε το αποτέλεσμα του βήματος 4 σαν ενιαίο block. Προκύπτει το "κρυπτογραφημένο σώμα" (encrypted body).
6. Προσθέτουμε την επικεφαλίδα "Content-Type: application/pkcs7-mime" με κατάλληλες παραμέτρους και επικεφαλίδες όπως η Content-Transfer-Encoding.
7. Επαναλαμβάνουμε τα βήματα 3 στο αποτέλεσμα του βήματος 6. Υπογράφουμε το κρυπτογραφημένο σώμα μαζί με τις ΜΙΜΕ επικεφαλίδες.
8. Ακολουθώντας την ίδια λογική όπως στο βήμα 4, δημιουργούμε την δομή του τελικού μηνύματος, δηλαδή την "εξωτερική υπογραφή".

Παρακάτω βλέπουμε παραδείγματα τριπλά περιτυλιγμένων μηνυμάτων, για τις δύο διαφορετικές περιπτώσεις.

Η περίπτωση application/pkcs7-mime

Παρατηρούμε ότι το τελικό προϊόν έχει πολλά επίπεδα ενθυλάκωσης, αλλά λόγω του τρόπου που πραγματοποιείται αυτή, η έννοια των επιπέδων γίνεται θολή. Μερικοί ασφαλής mail gateways υπογράφουν τα μηνύματα που περνούν από αυτούς. Εάν το μήνυμα δεν είναι ήδη υπογεγραμμένο, τότε ο gateway το τυλίγει μέσα σε εξωτερική υπογραφή, δημιουργώντας έτσι ένα ακόμα επίπεδο ενθυλάκωσης. Διαφορετικά, όταν δηλαδή το μήνυμα είναι ήδη υπογεγραμμένο, ο gateway απλά εισάγει τα στοιχεία του στο πεδίο SignerInfo της εξωτερική υπογραφής.

Η περίπτωση multipart/signed

5.4.7 Επιπρόσθετες Υπηρεσίες Ασφαλείας

Σε αυτό το κεφάλαιο θα αναφερθούμε πιο αναλυτικά στις προαιρετικές υπηρεσίες ασφάλειας του S/MIME.

Signed Receipts

Η επιστροφή μιας υπογεγραμμένη απόδειξη παραλαβής, παρέχει στον αποστολέα εξασφάλιση της διανομής του μηνύματος και του επιτρέπει να επιδείξει σε τρίτο ότι ο παραλήπτης ήταν σε θέση να επαληθεύσει την υπογραφή του αρχικού μηνύματος. Η αίτηση επιστροφής απόδειξης καθορίζεται με την τοποθέτηση της ιδιότητας receiptRequest στο πεδίο SignerInfo. Η ιδιότητα receiptRequest ανήκει στις υπογεγραμμένες ιδιότητες του πεδίου, και συνεπώς η υπηρεσία αυτή μπορεί να ζητηθεί μονάχα εάν το μήνυμα είναι υπογεγραμμένο.

1. Δημιουργία Αιτήσεως: Ο αποστολέας δημιουργεί ένα υπογεγραμμένο μήνυμα που περιλαμβάνει την ιδιότητα για την αίτηση απόδειξης (receiptRequest). Η ιδιότητα μπορεί να συμπεριληφθεί μόνο στις υπογεγραμμένες ιδιότητες της εξωτερικής υπογραφής και μπορεί να υπάρχει μόνο μία ανά πεδίο SignerInfo. Καθ' ότι μπορούν να υπάρχουν περισσότεροι υπογράφοντες του ενός, γίνεται για ένα υπογεγραμμένο αντικείμενο να ζητηθούν πολλαπλές αποδείξεις. Σε αυτήν την περίπτωση, στο πεδίο SignerInfo που αναφέρεται σε κάθε υπογράφοντα υπάρχει μια receiptRequest. Πρέπει, όμως, όλες οι αιτήσεις να είναι ταυτόσημες.
2. Μετάδοση: Ο αποστολέας μεταδίδει το μήνυμα στον ή στους παραλήπτες.
3. Επεξεργασία Αιτήσεως: Ο παραλήπτης αφού αποκτήσει, καθορίζει εάν η υπογραφή και η αίτηση της απόδειξης είναι έγκυρες. Το λογισμικό του παραλήπτη πρέπει να επαλήθευση την υπογραφή των υπογεγραμμένων ιδιοτήτων σε κάθε SignerInfo, διαφορετικά καμία υπογεγραμμένη ιδιότητα (συμπεριλαμβανομένης και της receiptRequest) δεν πρέπει να εξεταστεί. Έπειτα, πρέπει όλες οι αιτήσεις να είναι ταυτόσημες και αν έστω και μία δεν ταιριάζει με τις υπόλοιπές τότε δεν πρέπει να επιστραφεί απόδειξη.

Υπάρχουν και άλλοι παράγοντες που καθορίζουν την δημιουργία απόδειξης και εξαρτώνται από την πολιτική ασφαλείας που εφαρμόζεται στα μέλη της ταχυδρομικής λίστας (όταν υπάρχει). Έτσι, εάν ρητά απαγορεύεται η επιστροφή αποδείξεων, τότε ακόμα και αν ζητηθούν, δεν θα δημιουργηθούν ούτε θα σταλούν. Ακόμα, η θέση του παραλήπτη στην αλυσίδα της ταχυδρομικής λίστας παίζει ρόλο όταν ο αποστολέας ορίζει ότι μόνο ο πρώτος από τους παραλήπτες θα επιστρέψει απόδειξη, ενώ δεν έχει καμία σημασία όταν ορίζεται ότι όλοι θα στείλουν.

4. Δημιουργία Αποδείξεως: Ο παραλήπτης δημιουργεί μια υπογεγραμμένη απόδειξη.

Στην απόδειξη περιέχονται κωδικοποιημένα η υπογραφή των υπογεγραμμένων ιδιοτήτων του SignerInfo και η digest value του αρχικού μηνύματος. Περικλείονται και ιδιότητες από το αρχικό μήνυμα που είναι απαραίτητες για την σύνδεση της απόδειξης με αυτό.

5. Μετάδοση Αποδείξεως: Ο παραλήπτης μεταδίδει την απόδειξη.
6. Επικύρωση Αποδείξεως: Ο αποστολέας, παραλαμβάνει την απόδειξη και ερευνά κατά πόσο είναι έγκυρη και ανταποκρίνεται στο σωστό πρωτότυπο μήνυμα, βασιζόμενος στο πρωτότυπο και σε πληροφορίες που εξάγονται από αυτό.

Υπάρχει η δυνατότητα να ζητηθεί η απόδειξη να επιστραφεί και σε άλλα μέρη, εκτός από τον αποστολέα. Μάλιστα γίνεται η αίτηση να μην περιέχει το όνομα του αποστολέας καθόλου. Για να μπορέσει, όμως, ο αποδέκτης της απόδειξης να επιβεβαιώσει την εγκυρότητα της πρέπει να έχει αντίγραφο του αρχικού μηνύματος και γι' αυτό αποδέκτης της μπορεί να είναι και παραλήπτες του πρωτότυπου μηνύματος.

Security Labels

Ετικέτα ασφαλείας είναι ένα σύνολο πληροφοριών ασφαλείας που αφορούν την ευαισθησία των περιεχομένων. Αυτές οι πληροφορίες καθορίζουν εάν ο χρήστης εξουσιοδοτείται την πρόσβαση στα προστατευμένα περιεχόμενα. Μπορούν να περιγράφουν βαθμωτά επίπεδα ("μυστικό", "απόρρητο", περιορισμένη πρόσβαση" κτλ.) ή να περιγράφουν ομάδες ανθρώπων που μπορούν να δουν την πληροφορία (π.χ. "γιατροί", "ασφαλιστικές εταιρίες", "ασθενείς", "όλοι").

Επεξεργασία

Μία ετικέτα ασφαλείας τοποθετείται υπό την μορφή ιδιότητας (ESSSecurityLabel), στις υπογεγραμμένες ιδιότητες του πεδίου SignerInfo. Όταν χρησιμοποιείται, λοιπόν, πρέπει να υπογράφεται το μήνυμα. Η ετικέτα ασφαλείας μπορεί να περιέχεται στην εσωτερική υπογεγραμμένη ενθυλάκωση ή στην εξωτερική ή και στις δύο. Όταν βρίσκεται στην εσωτερική υπογραφή, αναφέρει την ευαισθησία του προστατευμένου περιεχομένου και χρησιμοποιείται για έλεγχο πρόσβασης σε αυτό. Όταν υπάρχει στην εξωτερική υπογραφή, χρησιμοποιείται για ελεγχόμενη πρόσβαση στο κρυπτογραφημένο σώμα και για αποφάσεις δρομολόγησης.

Επειδή μπορούν να υπάρχουν πολλαπλά SignerInfo πεδία και μέσα σε κάθε πεδίο μόνο μια ιδιότητα ESSSecurityLabel, επιτρέπεται η παρουσία πολλών ετικετών που καθεμία θα προέρχεται από διαφορετικό υπογράφοντα. Όλες οι ετικέτες όμως πρέπει να ίδιες. Το λογισμικό του παραλήπτη, πριν την επεξεργασία των ESSSecurityLabel πρέπει να επιβεβαίωση την υπογραφή των υπογεγραμμένων ιδιοτήτων και έπειτα να εξετάσει εάν ταυτίζονται. Ο χρήστης πρέπει να προειδοποιείται όταν δεν είναι ταυτόσημες.

Ιεράρχηση Επιπέδων Ασφάλειας

Σύμφωνα με την εξειδίκευση, όμως, Χ.411 οι ακέραιοι 0 έως 5 είναι κρατημένοι για τις βασικές έννοιες unmarked, unclassified, restricted, confidential, secret, top-secret. Η Χ.411 εξειδίκευση δεν θέτει κανόνες για το πως χρησιμοποιούνται οι παραπάνω έννοιες για να διαχωρίσουν την αξία των πληροφοριών και πως γίνεται ο έλεγχος πρόσβασης. Κάθε οργανισμός θα αποφασίσει τι σημαίνει για τον ίδιο κάθε μια από βασικές έννοιες. Για παράδειγμα, το επίπεδο που αντιστοιχεί στην έννοια "secret" ενός οργανισμού, θα έχει διαφορετική ερμηνεία από το αντίστοιχο την κυβέρνησης των Η.Π.Α.

Συνοπτικά, θα πρέπει μια πολιτική ασφαλείας να μην χρησιμοποιεί τους ακέραιους 0 – 5 για άλλες από τις έννοιες που ορίζει το Χ.411 και επιπλέον αριθμοί θα πρέπει αν υποδηλώνουν νέες έννοιες. Το σύνολο των έγκυρων τιμών πρέπει να είναι ιεραρχικές, χωρίς αυτό να σημαίνει ότι πρέπει να είναι με αυξανόμενη σειρά. Επιπλέον οι τιμές δεν είναι ανάγκη να είναι συνεχόμενες. Για παράδειγμα η φανταστική εταιρεία Morgan Corp. δεν χρησιμοποιεί καμία από τις έννοιες του Χ.411.

25 -- Morgan Corporation board of directors

Επίσης, παράδειγμα εταιρίας που ακολουθεί ότι ορίζει το Χ.411 είναι:

6 -- can only be read to Timberwolf Productions executives

Mail List Management

Τα προγράμματα ηλεκτρονικού ταχυδρομείου πρέπει να δημιουργούν κρυπτογραφημένα μηνύματα με διαφορετική δομή για κάθε προοριζόμενο παραλήπτη και συνεπώς ο φόρτος εργασίας αυξάνεται σημαντικά για μεγάλο αριθμό παραληπτών που ανήκουν στην ίδια ταχυδρομική λίστα. Γι' αυτό, συστήματα που καλούνται Mail List Agents (MLAs), αναλαμβάνουν την ανά χρήστη διαχείριση του μηνύματος. Κατά αυτόν τον τρόπο, η διευκολύνεται η αποστολή μηνυμάτων σε μεγάλες ταχυδρομικές λίστες.

Ένας MLA παρουσιάζεται στον αποστολέα σαν ένας τυπικός αποδέκτης, ενώ στην πραγματικότητα λειτουργεί σαν ένα σημείο περαιτέρω επεξεργασίας του μηνύματος που διανείμει το μήνυμα σε όλα τα μέλη της ταχυδρομική λίστας. Επίσης, ένας MLA πρέπει να αντιμετωπίζει τα mail loops. Mail Loops είναι μια κατάσταση που εμφανίζεται όταν μια ταχυδρομική λίστα είναι μέλος μιας δεύτερης που και αυτή με την σειρά της είναι μέλος της πρώτης.

Η ιδιότητα mlExpansionHistory που βρίσκεται στις υπογεγραμμένες ιδιότητες του πεδίου SignerInfo, περιέχει μια λίστα από κάθε MLA που έχει επεξεργαστεί το μήνυμα και ενημερώνεται από τον εκάστοτε MLA. Η λίστα αποτελείται από καταχωρήσεις με τα στοιχεία των MLA, την ημερομηνία που το μήνυμα επεξεργάστηκε από κάθε MLA και προαιρετικές ιδιότητες που δηλώνουν την πολιτική με την οποία αντιμετωπίζονται οι αιτήσεις για αποδείξεις. Είναι δυνατόν να υπάρχουν πολλές ιδιότητες mlExpansionHistory, μια σε κάθε SignerInfo που όμως πρέπει να είναι ολόιδιες. Πριν από την προσπέλαση της υπογεγραμμένης ιδιότητας mlExpansionHistory πρέπει να επαληθευθεί η υπογραφή του συνόλου των υπογεγραμμένων ιδιοτήτων και να συγκριθούν όλες οι mlExpansionHistory εάν ταιριάζουν.

Για την ανίχνευση και αποφυγή των mail loops, ο MLA εξετάζει τις υπάρχοντες καταχωρήσεις στο ιστορικό της mlExpansionHistory. Όταν ο MLA βρει τα αναγνωριστικά στοιχεία που ανήκουν στον ίδιο, τότε διακόπτει την επεξεργασία και προειδοποιεί τον υπεύθυνο της λίστας που αναλαμβάνει να διορθώσει το λάθος.

Επεξεργασία

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

1. Αναλύει όλα τα επίπεδα ένα προς ένα, ψάχνοντας για "εξωτερικό" υπογεγραμμένο επίπεδο, που ορίζεται σαν το πρώτο που περιέχει την ιδιότητα mlExpansionHistory ή που ενθυλακώνει κρυπτογραφημένα περιεχόμενα. Επίσης, ψάχνει και για την ιδιότητα ESSSecurityLabel και εφαρμόζει τους περιορισμούς που υποδεικνύει.
2. Εάν το ζητούμενο "εξωτερικό" υπογεγραμμένο επίπεδο βρεθεί, τότε αφαιρούνται όλα τα επίπεδα που το ενθυλακώνουν. Έπειτα, αφού συγκρατήσει τις υπογραμμένες ιδιότητες που ανήκουν σε κάθε SignerInfo αυτού, αφαιρεί και το ίδιο.
3. Από τα κρυπτογραφημένα περιεχόμενα που ενθυλακώνονταν στο "εξωτερικό" υπογεγραμμένο επίπεδο συλλέγονται πληροφορίες για τους παραλήπτες. Το πεδίο στο οποίο καθορίζεται ο παραλήπτης του μηνύματος, RecipientInfo, αρχικά περιέχει την ταυτότητα του MLA. Ο τελευταίος αντικαθιστά το πεδίο RecipientInfo που αναφέρεται στον εαυτό του, με πολλαπλά πεδία RecipientInfo που αναφέρονται στα μέλη της ταχυδρομικής λίστας. Η ενέργεια αυτή καταστρέφει την υπογραφή του αποστολέα.
4. Το μήνυμα υπογράφεται από τον MLA και αποστέλλεται στα μέλη της ταχυδρομική λίστας με ένα νέο "εξωτερικό" υπογεγραμμένο επίπεδο που περιέχει τις ιδιότητες του αρχικού.

(1). Στην πρώτη περίπτωση έχουμε την αντικατάσταση του έγκυρου, αυθεντικού πιστοποιητικού με ένα άλλο. Το πιστοποιητικό αυτό μπορεί να είναι (α) άκυρο, όποτε το μήνυμα δεν μπορεί να επαληθευθεί (άρνηση εξυπηρέτησης) αφού δεν ταιριάζουν η ιδιωτική κλείδα του αποστολέα με την δημόσια κλείδα αυτού ή (β) έγκυρο, όταν εσωκλείει τη ίδια δημόσια κλείδα με το αυθεντικό και έτσι επιτρέπεται η επικύρωση της υπογραφής κάτω από διαφορετικού περιορισμού από αυτούς που προέβλεψε ο αποστολέας.

(2). Η δεύτερη επίθεση βασίζεται στην επανέκδοση των root certificates από τις Αρχές Έκδοσης Πιστοποιητικών (Certificate Authorities). Root Certificate είναι ένα πιστοποιητικό που επιβεβαιώνει την ταυτότητα της ίδιας της Αρχής Έκδοσης Πιστοποιητικών. Κάποιος απατεώνας μπορεί να προσποιηθεί ότι είναι κάποιος άλλος με την χρήση πιστοποιητικού που υπογράφεται από το νέο root certificate.

(3) Μια ανέντιμη οντότητα μπορεί να αντιγράψει μια υπάρχουσα CA και να εκδίδει πιστοποιητικά με ίδιες δημόσιες κλείδες με αυτές που χρησιμοποιούνται. Και πάλι κάποιος επιτήδειος μπορεί να χρησιμοποιήσει ένα τέτοιο πιστοποιητικό για να παρουσιαστεί ως κάποιος άλλος.

Η νέα ιδιότητα SigningCertificate έχει σαν σκοπό να αποτρέψει τις παραπάνω επιθέσεις και να επιτρέψει σε ένα περιορισμένο σύνολο πιστοποιητικών να χρησιμοποιείται για την επαλήθευση της υπογραφής. Προστίθεται στις υπογεγραμμένες ιδιότητες και περιλαμβάνει στοιχεία που συνδέουν ταυτοποιούν το σωστό πιστοποιητικό. Η hash value του πιστοποιητικού περιλαμβάνεται στις υπογεγραμμένες ιδιότητες παρέχοντας επιπλέον ασφάλεια. Εάν η hash value στις υπογεγραμμένες ιδιότητες δεν ταιριάζει με την hash value του παραληφθέντος πιστοποιητικού τότε η υπογραφή θεωρείται άκυρη.

5.4.8 Υποστηριζόμενοι Αλγόριθμοι

Αλγόριθμοι Digest

Ο αλγόριθμος SHA-1 είναι υποχρεωτικός και ο MD5 είναι προαιρετικός.

Αλγόριθμοι Υπογραφής

Οι εφαρμογές του S/MIME πρέπει να υποστηρίζουν τις υπογραφές DSA, ενώ επιτρέπεται να υποστηρίζουν και υπογραφές RSA.

Αλγόριθμοι Διαχείρισης Κλειδιών

• Key agreement: Υποχρεωτική είναι η υποστήριξη των X9.42 Ephemeral-static-Diffie-Hellman, 3DES, RC2 και είναι δυνατή η συνδυασμένη χρήση τους για την κρυπτογράφηση των κλειδιών.
• Key transport: Για την μεταφορά των κλειδιών χρησιμοποιείται υποχρεωτικά ο αλγόριθμος RSA, ενώ για την κρυπτογράφηση των μεταφερόμενων κλειδιών εφαρμόζεται ο 3DES ή ο RC2.
• Symmetric key-encryption (προαιρετικός): Χρησιμοποιείται ο 3DES για την μεταφορά 3DES κρυπτογραφημένων κλειδιών ή ο RC2 για την μεταφορά RC2 κρυπτογραφημένων κλειδιών. Επιτρέπεται και η συνδυασμένη χρήση των αλγορίθμων.

Αλγόριθμοι Κρυπτογράφησης

Υποχρεωτικός είναι ο 3DES CBC και προαιρετικός ο RC2 CBC.

Αλγόριθμοι MAC

Υποστηρίζεται μόνο ένας, ο SHA-1.

5.4.9 Περαιτέρω Πληροφορίες για το S/MIME

Για μια πιο λεπτομερή μελέτη, ο αναγνώστης μπορεί να απευθυνθεί στην ακόλουθη ηλεκτρονική σελίδα. Σε αυτή την σελίδα είναι διαθέσιμα τα σχετικά RFCs, ταχυδρομικές λίστες και newsgroups.

S/MIME Mail Security (smime) Charter --

http://www.ietf.org/html.charters/smime-charter.html

5.5 PEM - Privacy Enhanced Mail

5.5.1 Εισαγωγή

Το πρωτόκολλο Privacy-Enhanced Mail (PEM) προβλέπει για αυτή την αδυναμία του ηλεκτρονικού ταχυδρομείου του Internet, προσθέτοντας την εφαρμογή των υπηρεσιών της απόρρητης συναλλαγής, της πιστοποίησης ταυτότητας, της ακεραιότητας των μηνυμάτων και την εξασφάλιση της μη αποκήρυξης της πηγής. Οι υπηρεσίες αυτές προσφέρονται μέσω της χρήσης απ' άκρη σ' άκρη κρυπτογράφησης μεταξύ του αποστολέα και του παραλήπτη. Δεν απαιτούνται ειδικές ικανότητες επεξεργασίας στα συστήματα MTS (Message Transfer System) και υποστηρίζεται η συνεργασία με άλλα ταχυδρομικά συστήματα μεταφοράς.

Προς το παρών το PEM χρησιμοποιείται με μηνύματα RFC822, ενώ επέκταση του πρωτοκόλλου ώστε να εφαρμόζεται και σε περιβάλλοντα ΜΙΜΕ αναμένεται.

Αρχές του PEM

1. Όλες προσθήκες ασφάλειας εφαρμόζονται στο Application Layer του OSI και είναι ανεξάρτητες από οποιαδήποτε χαρακτηριστικά ασφαλείας χαμηλότερων επιπέδων.
2. Οι προσθήκες ασφαλείας εφαρμόζονται μόνο από τους αποστολείς και τους Τελικούς αποδέκτες των μηνυμάτων. Η λειτουργία των ενδιάμεσων συστημάτων που δεν υποστηρίζουν τις δυνατότητες του PEM δεν επηρεάζεται από αυτή την συνθήκη. Παρ' όλα αυτά είναι απαραίτητο ο αποστολέας να γνωρίζει κατά πόσο ο προοριζόμενος παραλήπτης του μηνύματος εφαρμόζει τις υπηρεσίες ασφάλειας του PEM, ώστε να αποφευχθεί η άσκοπη κρυπτογράφηση και κωδικοποίηση του μηνύματος.
3. Οι καθορισμένοι μηχανισμοί είναι συμβατοί με μία μεγάλη ποικιλία ταχυδρομικών συστημάτων μεταφοράς (MTAs) και πρέπει να μπορούν να λειτουργούν πρωτόκολλα μεταφορά εκτός του SMTP (USENET, CSNET, BITNET).
4. Οι καθορισμένοι μηχανισμοί είναι συμβατοί με μεγάλη ποικιλία προγραμμάτων ηλεκτρονικού ταχυδρομείου (Mail User Agents – UAs). Επιπλέον οι μηχανισμοί του PEM διαλέγονται έτσι ώστε να μπορούν να χρησιμοποιηθούν με στα περισσότερα προγράμματα χρηστών.
5. Υποστηρίζεται μεγάλη ποικιλία τεχνικών διαχείρισης κλειδιών και διαφορετικές τεχνικές χρησιμοποιούνται με διαφορετικούς παραλήπτες. Διαφορετικές τεχνικές μπορούν να οριστούν ακόμα και με τους διαφορετικούς παραλήπτες ενός multicast μηνύματος. Για δυο PEM εφαρμογές να συνεργαστούν, πρέπει να μοιράζονται ένα τουλάχιστον κοινό μηχανισμό διαχείριση κλειδιών.

5.5.2 Παραγωγή PEM Μηνυμάτων

Είδη Κλειδιών και Διαχείριση Τους

Η περιγραφή του πρωτοκόλλου στο RFC1421 καθορίζει δύο τύπους κλειδιών:

1. Data Encrypting Keys (DEKs): Είναι κλειδιά που χρησιμοποιούνται για την κρυπτογράφηση των κειμένων των μηνυμάτων. Στην ασύμμετρη διαχείριση κλειδιών (asymmetric key management), στα PEM μηνύματα που εφαρμόζεται η υπηρεσία της διαφύλαξης του απόρρητου (ENCRYPTED μηνύματα – βλέπε παρακάτω) τα DEKs χρησιμοποιούνται στην επιπλέον κρυπτογράφηση των Message Integrity Checks (MICs). Λέμε επιπλέον γιατί τα MICs, για την παραγωγή της υπογραφής του μηνύματος, κρυπτογραφούνται από το ΙΚ. Λέγοντας MICs εννοούμε το αποτέλεσμα που δίνει στην έξοδο του ένας digest ή hash algorithm όταν στην είσοδο εισάγουμε το μήνυμα. Τα κλειδιά DEKs παράγονται εκ νέου για κάθε μήνυμα προς μετάδοση.
2. Interchange Keys (IKs): Χρησιμοποιούνται για την κρυπτογράφηση των DEKs και MICs τα οποία μεταφέρονται μέσα στο μήνυμα. Κανονικά, το ίδιο IK θα χρησιμοποιηθεί για όλα τα μηνύματα από έναν συγκεκριμένο αποστολέα σε έναν συγκεκριμένο παραλήπτη, για περιορισμένο χρονικό διάστημα. Η κρυπτογράφηση των DEKs και MICs μπορεί να γίνει είτε με συμμετρική κρυπτογραφία (συμμετρική διαχείριση κλειδιών), οπότε το IK είναι το ίδιο για αποστολέα και παραλήπτη, είτε με ασύμμετρη κρυπτογραφία (ασύμμετρη διαχείριση κλειδιών), οπότε η κρυπτογράφηση γίνεται με την δημόσια κλείδα του παραλήπτη. Στην ασύμμετρη κρυπτογράφηση των MICs χρησιμοποιείται η ιδιωτική κλείδα του αποστολέα.

Όταν ένα μήνυμα πρόκειται να επεξεργαστεί από το PEM, παράγεται ένα DEK για την κρυπτογράφηση του μηνύματος καθώς και απαραίτητοι παράμετροι (π.χ. Initialization Vectors) που εξαρτώνται από τους επιλεγμένους αλγόριθμους. Στην περίπτωση συμμετρικών IKs, χρησιμοποιούνται διαφορετικά κλειδιά για κάθε παραλήπτη του μηνύματος, για την προετοιμασία των κρυπτογραφημένων DEKs και MICs. Αντίθετα, στην περίπτωση των ασύμμετρων IKs, επειδή ο αποστολέας κατέχει ένα ζευγάρι δημόσιας – ιδιωτικής κλείδας, η κρυπτογράφηση των DEKs και MICs γίνεται για όλους τους παραλήπτες με την ίδια κλείδα.

Είναι δυνατόν ένα αφιερωμένο σύστημα (Key Distribution System) να δημιουργεί τα τυχαία DEKs. Τέτοια συστήματα μπορούν να εφαρμόζουν πιο ισχυρούς αλγόριθμους στην παραγωγή των τυχαίων DEKs, παρ' αυτά όμως η αποκέντρωση της παραγωγής επιτρέπει στα συστήματα των χρηστών να είναι αυτοσυντηρούμενα και απαλείφει την εμπιστοσύνη σε τρίτες οντότητες.

Η ασύμμετρη διαχείριση κλειδιών μπορεί να συνδυαστεί με την χρήση πιστοποιητικών για την επαλήθευσης της ταυτότητας του αποστολέα. Το πιστοποιητικό περιέχει, εκτός των πληροφοριών που σχετίζονται με τον εκδότη του (Certificate Authority – CA) και την δημόσια κλείδα του αποστολέα.

Περιληπτική Παρουσίαση της Επεξεργασίας

Με σκοπό τα κρυπτογραφημένα μηνύματα να είναι παγκοσμίως αναγνωρίσιμα και να μπορούν να μεταφερθούν σε όλα τα περιβάλλοντα, απαιτείται ένας μετασχηματισμός τεσσάρων φάσεων. Αρχικά τα μηνύματα συντάσσονται σύμφωνα με τους τοπικούς κανόνες, χρησιμοποιώντας το σύνολο χαρακτήρων (character set) και τους χαρακτήρες ελέγχου του τοπικού συστήματος. Η αρχική αυτή μορφή μετατρέπεται σε κανονική μορφή (canonical form), η οποία αποτελεί είσοδο στις διαδικασίες της κρυπτογράφησης και της παραγωγής MIC. Τέλος, το αποτέλεσμα της κρυπτογράφησης και / ή της παραγωγής του MIC κωδικοποιείται βάσει κατάλληλου μηχανισμού. Το σύνολο χαρακτήρων που χρησιμοποιεί ο μηχανισμός αυτός είναι παγκόσμια παρουσιάσιμο. Παρακάτω θα αναλύσουμε περισσότερο τα βήματα επεξεργασίας.

Ο παραλήπτης του μηνύματος, αφού αφαιρέσει την κωδικοποίηση, εξετάζει τις πεδία ελέγχου της κρυπτογράφησης που του παρέχουν τις απαραίτητες πληροφορίες για να επαλήθευση την εγκυρότητα του MIC και για να αποκρυπτογραφήσει το κείμενο. Τέλος, το μήνυμα μετατρέπεται από την κανονική μορφή στην μορφή που αντιστοιχεί στα χαρακτηριστικά του τοπικού συστήματος του παραλήπτη.

Συντακτικά άκυρα PEM μηνύματα θα πρέπει να αναφερθούν μαζί με συλλογή διαγνωστικών πληροφοριών για να αντιμετωπιστούν προβλήματα ασυμβατότητας ή άλλων αιτιών. Τα PEM μηνύματα, όμως, που είναι συντακτικά έγκυρα αλλά παρουσιάζουν αποτυχημένη επαλήθευση του MIC πρέπει να αντιμετωπίζονται με προσοχή. Οι χρήστες θα πρέπει να ειδοποιούνται ότι το δεν μπορεί να εγγυηθεί η αυθεντικότητα και η ακεραιότητα των περιεχομένων του εν λόγω μηνύματος.

Τύποι Μηνυμάτων

5.5.3 Βήματα Επεξεργασίας

Η φιλοσοφία παραγωγής μηνυμάτων συμβατών με τις υποκείμενες τεχνολογίες και πρωτόκολλα περιλαμβάνει ένα βήμα κανονικοποίησης που αφαιρεί όλες τις τοπικές συμβάσεις, ακολουθούμενο από βήμα κωδικοποίησης για την προσαρμογή με μέσω μεταφοράς ηλεκτρονικού ταχυδρομείου (SMTP).

Το πρωτόκολλο SMTP έχει συγκεκριμένους περιορισμούς όσο αναφορά την μορφή του προς μετάδοση μηνύματος. Έτσι η προετοιμασία του μηνύματος έχει τις ακόλουθες απαιτήσεις:

1. Όλοι οι χαρακτήρες πρέπει να ανήκουν στο σύνολο χαρακτήρων 7-bit ASCII.
2. Οι γραμμές κειμένου πρέπει να διαχωρίζονται από το ζευγάρι <CR><LF> και το μήκος τους δεν πρέπει να ξεπερνά τους 1000 χαρακτήρες.
3. Λόγω του ότι η ακολουθία <CR><LF>.<CR><LF> σηματοδοτεί το τέλος του μηνύματος δεν πρέπει να συναντάται πουθενά πριν από το τέλος.

Τα τέσσερα βήματα του μετασχηματισμού παρουσιάζονται αναλυτικά παρακάτω:

Το βήμα αυτό είναι εφαρμόσιμο στα PEM μηνύματα τύπου ENCRYPTED, MIC-ONLY, MIC-CLEAR. Το κείμενου του μηνύματος δημιουργείται βάσει των τοπικών συνόλων χαρακτήρων και των τοπικών χαρακτήρων ελέγχου.

Το βήμα αυτό, όπως και το προηγούμενο, είναι εφαρμόσιμο στους τύπους ENCRYPTED, MIC-ONLY, MIC-CLEAR. Το κείμενο μετατρέπεται σε παγκόσμια αναγνωρίσιμη μορφή, την κανονικά μορφή. Όλες οι συμβάσεις του τοπικού συστήματος αφαιρούνται και το κείμενο υπόκειται στους περιορισμούς του SMTP. Το μήκος των γραμμών μειώνεται, οι χαρακτήρες αλλαγής γραμμής γίνονται οι <CR><LF>, και το σύνολο χαρακτήρων ανάγεται στο 7-bit ASCII.

Το τρίτο βήμα περιλαμβάνει δύο ξεχωριστές ενέργειες: την παραγωγή MIC και την κρυπτογράφηση της κανονικής μορφής του προηγούμενου βήματος. Η κρυπτογράφηση εφαρμόζεται μόνο στα ENCRYPTED, ενώ η εφαρμόζεται και στους τρεις τύπους (ENCRYPTED, MIC-ONLY, MIC-CLEAR).

Βήμα 4: Printable Encoding (base64)

Η κωδικοποίηση του τέταρτου βήματος εφαρμόζεται στους τύπους ENCRYPTED και MIC-ONLY. Η ακολουθία bit του 3^ου βήματος κωδικοποιείται σε χαρακτήρες που είναι παρουσιάσιμοι σε όλα τα sites.

Κάθε 3 bytes του επεξεργαζόμενου αρχείου, λαμβάνονται σαν ποσότητες των 24 bit και διαχωρίζονται σε 4 εξάδες bit. Έπειτα κάθε εξάδα αντιστοιχίζεται, βάσει ενός πίνακα 64 χαρακτήρων, με χαρακτήρα από συγκεκριμένο υποσύνολο του ASCII. Εάν δεν συμπληρώνονται 24 bit, τότε χρησιμοποιείται ο χαρακτήρα (=) σαν συμπλήρωμα.

Παρακάτω φαίνεται ο πίνακας που χρησιμοποιείται για τις αντιστοιχίες.

16 Q 33 h 50 y

Τα παραπάνω βήματα μπορούν να περιγραφούν εν συντομία με την εξίσωση:

Transmit_Form = Encode(Encrypt(Canonicalize(Local_Form))),

ενώ η αντίστροφη διαδικασία παριστάνεται:

Local_Form = DeCanonicalize(Decipher(Decode(Transmit_Form)))

Το τελικό αποτέλεσμα του τέταρτου βήματος της προηγούμενης διαδικασίας συνδυάζεται με πληροφορίες που σχετίζονται με την προστασία του εγγράφου και ενθυλακώνονται στο σώμα (text portion – body) ενός κανονικού μηνύματος και μεταδίδεται. Τα πεδία που αναφέρονται στην κρυπτογράφηση και στα MIC (πληροφορίες προστασίας) τοποθετούνται σε τμήμα επικεφαλίδων πριν τα προστατευμένα δεδομένα, ενώ όλο το PEM μήνυμα περικλείεται από κατάλληλες διαχωριστικές γραμμές.

Μορφή Ενθυλακωμένου PEM μηνύματος

Η τεχνική ενθυλάκωσης μπορεί να χρησιμοποιηθεί για την ενθυλάκωση πολλαπλών PEM μηνυμάτων ή ακόμα για την συνοδεία του PEM μηνύματος από απλό κείμενο. Οι διαχωριστικές γραμμές (encapsulation boundaries) χρησιμεύουν στον διαχωρισμό των PEM μηνυμάτων και για την διάκριση των μη κρυπτογραφημένων δεδομένων από τα PEM μηνύματα. Η αρχή ενός PEM μηνύματος υποδηλώνεται με την γραμμή

-----BEGIN PRIVACY-ENHANCED MESSAGE-----

ενώ το τέλος υποδηλώνεται είτε με την ίδια γραμμή είτε με την

-----END PRIVACY-ENHANCED MESSAGE-----

υποδηλώνοντας ότι ακολουθεί άλλο PEM μήνυμα.

5.5.5 Ταχυδρομικές Λίστες

Όταν ένα μήνυμα απευθύνεται σε ταχυδρομικές λίστες, δύο διαφορετικές μέθοδοι μπορούν να εφαρμοστούν όσον αναφορά τα κλειδιά IK: (α) ΙΚ ανά λίστα (IK-per-list) και (β) ΙΚ ανά παραλήπτη (IK-per-recipient), ενώ δεν αποκλείονται οι υβριδικές προσεγγίσεις.

(α) Στην περίπτωση των ΙΚ ανά παραλήπτη, το κλειδί κρυπτογράφησης των δεδομένων του μηνύματος, DEK, κρυπτογραφείται με κάθε κλειδί ΙΚ για κάθε παραλήπτη και όλες αυτές οι κρυπτογραφημένες παρουσιάσεις των DEK μεταφέρονται με το μήνυμα. Αξίζει να επισημάνουμε ότι η ανά χρήστη κρυπτογράφηση δεν γίνεται στο προστατευμένο κείμενο παρά μόνο στα DEK και στα MIC. Το μειονέκτημα είναι η χρήση πολλών ΙΚ που περιπλέκουν την επεξεργασία του μηνύματος και την διαχείριση των κλειδιών. Παρ' όλα αυτά, όμως, η υποκλοπή ενός κλειδιού που δεν μοιράζεται μεταξύ πολλών χρηστών είναι πιο δύσκολη και η ανάκληση ενός ζεύγους ΙΚ δεν προκαλεί προβλήματα σε όλα τα μέλη της ταχυδρομική λίστας.

Καταλαβαίνουμε ότι είναι προτιμότερη μία υβριδική προσέγγιση, όπου στο μονοπάτι από τον αποστολέα προς τον Mail List Agent (MLA) εφαρμόζεται η ΙΚ ανά λίστα προστασία, ενώ στο μονοπάτι από τον MLA προς τους τελικούς αποδέκτες εφαρμόζεται ΙΚ ανά παραλήπτη προστασία.

Περίληψη Ενθυλακωμένων Επικεφαλίδων

Παρακάτω θα αναφερθούμε περιληπτικά στις σημαντικότερες επικεφαλίδες που ενθυλακώνονται στο PEM μήνυμα και περιέχουν απαραίτητες πληροφορίες για το είδος της παρεχόμενης προστασίας τους αλγόριθμους κρυπτογράφησης και παραγωγής MIC και επιπλέον στοιχεία για την πιστοποίηση της ταυτότητας της πηγής. Οι επικεφαλίδες παρουσιάζονται με την σειρά που δίνονται εδώ.

Παράδειγμα Encapsulated ENCRYPTED Message (Asymmetric Key Management)

Υποστηριζόμενοι Αλγόριθμοι

Αλγόριθμοι Κρυπτογράφησης

Ο μοναδικός αλγόριθμος που χρησιμοποιείται για την κρυπτογράφηση των περιεχομένων είναι ο DES σε CBC (Cipher Bloch Chaining) mode. Η είσοδος στον αλγόριθμο πολύ πιθανών να απαιτεί κατάλληλο συμπλήρωμα, ώστε το μήκος να είναι πολλαπλάσιο των 8 bytes. Επίσης απαιτεί έναν 64-bit Initialization Vector, ο οποίος είναι διαφορετικός για κάθε ENCRYPTED PEM μήνυμα.

Ο DES CBC απαιτεί ένα κλειδί κρυπτογράφησης των 64 bits. Από τα 64 bits, τα 56 χρησιμοποιούνται απευθείας για από τον DES CBC, ενώ τα υπόλοιπα 8 bits είναι bits περιττής ισοτιμίας. Για κάθε ENCRYPTED PEM μήνυμα παράγεται νέο τυχαίο κλειδί.

Αλγόριθμοι Παραγωγής MICs

Υπάρχουν δύο αλγόριθμοι σε αυτήν την κατηγορία, ο MD2 και ο MD5. Και οι δύο αλγόριθμοι δέχονται σαν είσοδο μήνυμα οποιουδήποτε μήκους και παράγουν στην έξοδο μια ακολουθία 16 bytes. Όταν χρησιμοποιείται συμμετρική διαχείριση κλειδιών, το αποτέλεσμα των αλγορίθμων διασπάται στα δύο μισά των 8 bytes, τα οποία κρυπτογραφούνται ξεχωριστά και έπειτα συνενώνονται.

Αλγόριθμοι Συμμετρικής Διαχείρισης Κλειδιών

Οι αλγόριθμοι που χρησιμοποιούνται για την κρυπτογράφηση των DEKs και MICs είναι δύο παραλλαγές του DES: ο DES σε ECB (Electronic-Codebook) mode και ο DES σε EDE (Encrypt-Decrypt-Encrypt) mode. Και οι δύο απαιτούν IK κλειδιά μήκους 64 bits.

Αλγόριθμοι Ασύμμετρης Διαχείρισης Κλειδιών

Το ασύμμετρο ζευγάρι IK κλειδιών (δημόσια κλείδα – ιδιωτική κλείδα) είναι της μορφής που καθορίζεται από το RSA μηχανισμό. Ομοίως, για την κρυπτογράφηση των DEKs και MICs ο μηχανισμός RSA εφαρμόζεται, κατά τον οποίο η ιδιωτική κλείδα κρυπτογραφεί τo MICs παράγοντας έτσι ψηφιακές υπογραφές των μηνυμάτων και η δημόσια κλείδα κρυπτογραφεί το DEK.

Χρησιμοποιείται, επίσης, και ο MD2 σε συνδυασμό με τον RSA για την υπογραφή των πιστοποιητικών και των λιστών ανάκλησης πιστοποιητικών (CRL).

Περαιτέρω Πληροφορίες

Στις παρακάτω ηλεκτρονικές σελίδες μπορούν να βρεθούν τα τεχνικά έγγραφα στα οποία βασίζεται η παρούσα μελέτη:

Privacy Enhanced Mail – PEM -- http://www.uninett.no/pca/html/pem-e.html

Secure EMAIL (SAECRC) -- http://ec.saecrc.org/techno/inethelp/secure2.htm

RFCs: PEM - Privacy Enhanced Mail and Cryptography  –  http://www.wu-wien.ac.at/manuals/rfc-pem.html

Το λογισμικό Pretty Good Privacy (PGP), το οποίο σχεδιάστηκε από τον Phill Zimmerman, είναι ένα λογισμικό κρυπτογράφησης υψηλής ασφάλειας για λειτουργικά συστήματα όπως τα MS DOS, Unix, VAX/VMS και για άλλες πλατφόρμες. Το PGP επιτρέπει την ανταλλαγή αρχείων και μηνυμάτων διασφαλίζοντας το απόρρητο και την ταυτότητα σε συνδυασμό με την ευκολία λειτουργίας.

Διασφάλιση του απορρήτου σημαίνει ότι μόνο αυτός για τον οποίο προορίζεται ένα μήνυμα είναι ικανός και να το διαβάσει.

Πιστοποίηση της ταυτότητας σημαίνει ότι μηνύματα που φαίνεται πως έχουν προέλθει από κάποιο άτομο μπορούν να έχουν προέλθει μόνο από αυτό το άτομο.

Ευκολία σημαίνει ότι η διασφάλιση του απόρρητου και η πιστοποίησης της ταυτότητας παρέχονται χωρίς την πολυπλοκότητα της διαχείρισης κλειδιών η οποία σχετίζεται με τη συμβατική κρυπτογραφία. Δεν είναι αναγκαία ασφαλή κανάλια για την ανταλλαγή κλειδιών μεταξύ χρηστών κάτι που κάνει το PGP πολύ ευκολότερο στη χρήση από κάθε άλλο αντίστοιχο πακέτο. Αυτό συμβαίνει διότι το PGP είναι βασισμένο σε μια δυναμική νέα τεχνολογία που καλείται κρυπτογράφηση "δημοσίων κλειδιών" (public key).

Το PGP συνδυάζει την ευκολία του RSA κρυπτοσυστήματος δημοσίων κλειδιών με την ταχύτητα της συμβατικής κρυπτογράφησης, περιλήψεις μηνυμάτων για ψηφιακές υπογραφές, συμπίεση δεδομένων πριν την κρυπτογράφηση, καλός εργονομικός σχεδιασμός και υψηλού επιπέδου διαχείριση κλειδιών. Επιπλέον το PGP εκτελεί τις λειτουργίες των δημοσίων κλειδιών γρηγορότερα από τα περισσότερα αντίστοιχα προγράμματα. Το PGP είναι κρυπτογράφηση δημοσίων κλειδιών για τις μάζες.

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

Όλο και μεγαλύτερο ποσοστό από τις ιδιωτικές μας επικοινωνίες δρομολογείται μέσω ηλεκτρονικών καναλιών. Το ηλεκτρονικό ταχυδρομείο σταδιακά αντικαθιστά το συμβατικό ταχυδρομείο. Τα μηνύματα e-mail είναι πολύ εύκολο να υποκλέπτουν και να περάσουν από διαδικασία ανίχνευσης βάσει καθορισμένων λέξεων-κλειδιών (keywords). Αυτό μπορεί να γίνει εύκολα, αυτόματα και χωρίς να πέσει στην αντίληψη κανενός σε μεγάλο επίπεδο. Οι διεθνείς συνδέσεις βρίσκονται ήδη κάτω από μια τέτοια διαδικασία παρακολούθησης από την NSA.

Κινούμαστε προς ένα μέλλον όπου οι υπολογιστές διεθνώς θα ενώνονται με δίκτυα οπτικών ινών υψηλής χωρητικότητας. Το e-mail θα είναι κάτι το αυτονόητο για όλους και όχι η καινοτομία που θεωρείται σήμερα. Οι κυβερνήσεις θα προστατεύουν το e-mail των πολιτών με πρωτόκολλα σχεδιασμένα από τις ίδιες. Πιθανότατα οι περισσότεροι άνθρωποι θα συμβιβαστούν με αυτή τη λύση αλλά ίσως μερικοί προτιμήσουν να πάρουν τα δικά τους μέτρα ασφάλειας.

Για να κατανοήσουμε τη λειτουργία του PGP θα πρέπει να αναφέρουμε λίγα λόγια πάνω στην ορολογία που χρησιμοποιείται. Ας θεωρήσουμε ότι θέλει κάποιος να στείλει ένα μήνυμα αλλά δεν θέλει να το διαβάσει κανένας άλλος εκτός από τον παραλήπτη. Μπορεί να το κρυπτογραφήσει με τη χρήση ενός κλειδιού το οποίο θα πρέπει να χρησιμοποιηθεί στην αποκρυπτογράφηση του μηνύματος από τον παραλήπτη του—τουλάχιστον έτσι δουλεύει η συμβατική κρυπτογραφία ενός κλειδιού.

Στα συμβατικά κρυπτοσυστήματα, όπως το DES, ένα και μόνο κλειδί χρησιμοποιείται τόσο για την κρυπτογράφηση όσο και για την αποκρυπτογράφηση. Αυτό σημαίνει ότι το κλειδί θα πρέπει να μεταδοθεί αρχικά μέσα από ένα ασφαλές κανάλι έτσι ώστε και τα δυο μέρη να το γνωρίζουν προτού αρχίσει η αποστολή κρυπτογραφημένων μηνυμάτων μέσω ασφαλών καναλιών. Αυτό δεν είναι και τόσο βολικό διότι αν έχεις ένα ασφαλές κανάλι για να ανταλλάζεις κλειδιά τότε τι χρειάζεσαι την κρυπτογραφία;

Στα κρυπτοσυστήματα δημοσίων κλειδιών ο καθένας έχει δυο συμπληρωματικά κλειδιά. Ένα που δίδεται δημόσια (public key) και ένα μυστικό (secret key ή private key). Το κάθε κλειδί ξεκλειδώνει τον κώδικα που το άλλο φτιάχνει. Η γνώση του δημοσίου κλειδιού δεν βοηθάει στην εξαγωγή του αντίστοιχου μυστικού κλειδιού. Το δημόσιο κλειδί μπορεί να διατεθεί σε ένα δίκτυο επικοινωνιών. Αυτό το πρωτόκολλο παρέχει διασφάλιση του απόρρητου χωρίς την ανάγκη ύπαρξης ασφαλών καναλιών, όπως απαιτεί η συμβατική κρυπτογραφία.

Ο καθένας μπορεί να χρησιμοποιήσει το δημόσιο κλειδί του παραλήπτη ενός μηνύματος για να κρυπτογραφήσει ένα μήνυμα προς αυτό το άτομο ενώ ο παραλήπτης μπορεί να χρησιμοποιήσει με τη σειρά του το αντίστοιχο μυστικό κλειδί για να αποκρυπτογραφήσει το μήνυμα. Κανένας άλλος εκτός από τον παραλήπτη δεν μπορεί να το αποκρυπτογραφήσει διότι κανένας άλλος δεν έχει πρόσβαση στο μυστικό κλειδί - ακόμη και το άτομο που κρυπτογράφησε το μήνυμα.

Επίσης παρέχεται υπηρεσία πιστοποίησης του μηνύματος. Το μυστικό κλειδί του αποστολέα μπορεί να χρησιμοποιηθεί για την κρυπτογράφηση του μηνύματος άρα και για την υπογραφή του. Έτσι δημιουργείται μια ψηφιακή υπογραφή του μηνύματος την οποία ο παραλήπτης ή οποιοσδήποτε άλλος μπορεί να ελέγξει χρησιμοποιώντας το δημόσιο κλειδί του αποστολέα για να την αποκρυπτογραφήσει. Αυτό αποδεικνύει ότι ο αποστολέας ήταν ο πραγματικός δημιουργός του μηνύματος και ότι το μήνυμα δεν αλλοιώθηκε από κάποιον άλλον διότι μόνο ο αποστολέας έχει στην κατοχή του το μυστικό κλειδί που έφτιαξε την υπογραφή. Η πλαστογράφηση ενός υπογεγραμμένου μηνύματος δεν είναι εφικτή και ο αποστολέας δεν μπορεί μετά να απαρνηθεί την υπογραφή του.

Αυτές οι δυο διαδικασίες μπορούν να συνδυαστούν για την παροχή τόσο διασφάλισης του απόρρητου όσο και πιστοποίησης της ταυτότητας αφού μπορεί κάποιος πρώτα να υπογράψει ένα μήνυμα με το μυστικό κλειδί του και μετά να το κρυπτογραφήσει με το δημόσιο κλειδί του παραλήπτη. Ο παραλήπτης αντιστρέφει αυτά τα βήματα αποκρυπτογραφώντας πρώτα το μήνυμα με το μυστικό κλειδί του και κατόπιν ελέγχοντας την ψηφιακή υπογραφή που περιέχεται σε αυτό με το δημόσιο κλειδί του αποστολέα. Αυτές οι διαδικασίες γίνονται αυτόματα από το λογισμικό του παραλήπτη.

Επειδή ο αλγόριθμος της κρυπτογράφησης δημοσίων κλειδιών είναι πολύ πιο αργός από τη συμβατική κρυπτογράφηση ενός κλειδιού η κρυπτογράφηση επιτυγχάνεται καλύτερα με τη χρήση ενός υψηλής ποιότητας γρήγορου αλγόριθμου συμβατικής κρυπτογράφησης ενός κλειδιού για την κρυπτογράφηση του μηνύματος. Το αρχικό μη κρυπτογραφημένο μήνυμα καλείται "απλό κείμενο". Σε μια διαδικασία αόρατη στο χρήστη ένα προσωρινό τυχαίο κλειδί, το οποίο έχει δημιουργηθεί μόνο για τη συγκεκριμένη φορά, χρησιμοποιείται για να κρυπτογραφηθεί συμβατικά το αρχείο "απλό κείμενο". Μετά το δημόσιο κλειδί του παραλήπτη χρησιμοποιείται για να κρυπτογραφηθεί αυτό το προσωρινό κλειδί. Αυτό το συμβατικά δημιουργημένο κλειδί μιας φοράς (session key) το οποίο έχει κρυπτογραφηθεί και με τη διαδικασία του δημόσιου κλειδιού αποστέλλεται μαζί με το κρυπτογραφημένο κείμενο (κρυπτοκείμενο) στον παραλήπτη. Ο παραλήπτης χρησιμοποιεί το δικό του μυστικό κλειδί για να ανακτήσει το session key και μετά χρησιμοποιεί αυτό κλειδί για να τρέξει τον γρήγορο συμβατικό αλγόριθμο ενός κλειδιού έτσι ώστε να αποκρυπτογραφήσει το κρυπτοκείμενο. Η όλη διαδικασία φαίνεται στο παρακάτω σχήμα:

Τα δημόσια κλειδιά φυλάσσονται σε ξεχωριστά πιστοποιητικά κλειδιών (key certificates) τα οποία περιλαμβάνουν την ταυτότητα του ιδιοκτήτη τους (το όνομα του ιδιοκτήτη), μια σφραγίδα χρόνου που δείχνει πότε το ζεύγος των κλειδιών δημιουργήθηκε και τέλος το ίδιο το υλικό του κλειδιού. Τα πιστοποιητικά δημοσίων κλειδιών περιλαμβάνουν το υλικό των δημοσίων κλειδιών ενώ τα πιστοποιητικά των μυστικών κλειδιών περιλαμβάνουν το υλικό των μυστικών κλειδιών. Κάθε μυστικό κλειδί κρυπτογραφείται επιπλέον με τον κωδικό του σε περίπτωση που κλαπεί. Ένα αρχείο κλειδιών ή ένα μπρελόκ κλειδιών (key ring) περιέχει ένα ή περισσότερα από αυτά τα πιστοποιητικά κλειδιών. Τα δημόσια μπρελόκ περιέχουν τα δημόσια πιστοποιητικά κλειδιών ενώ τα ιδιωτικά μπρελόκ περιέχουν τα ιδιωτικά πιστοποιητικά κλειδιά.

Τα κλειδιά χαρακτηρίζονται από ένα "key id" (ταυτότητα κλειδιού) η οποία είναι μια συντομογραφία του δημόσιου κλειδιού (τα 64 λιγότερο σημαντικά bits του δημοσίου κλειδιού). Όταν αυτή η ταυτότητα παρουσιάζεται μόνο τα 32 λιγότερο σημαντικά bits δίνονται για επιπλέον ελαχιστοποίηση του όγκου της ταυτότητας. Καθώς πολλά κλειδιά μπορεί να μοιράζονται το ίδιο user id (ταυτότητα χρήστη), για πρακτικούς λόγους κανένα κλειδί δεν μοιράζεται το ίδιο key id με κανένα άλλο.

Το PGP χρησιμοποιεί τις περιλήψεις μηνυμάτων (message digests) για να δημιουργήσει υπογραφές. Μια περίληψη μηνύματος είναι μια κρυπτογραφικά πολλή δυνατή μονόδρομη (hash) συνάρτηση 128 bit του μηνύματος. Είναι κάτι ανάλογο με το "check sum" ή CRC κώδικα ελέγχου στο ότι αντιπροσωπεύουν συμπαγώς το μήνυμα και χρησιμοποιούνται για την ανίχνευση αλλαγών σε αυτό. Αντίθετα βέβαια με το CRC είναι υπολογιστικά αδύνατο για κάποιον επιτιθέμενο να φτιάξει ένα υποκατάστατο μήνυμα το οποίο θα μπορούσε να παράγει την ίδια περίληψη μηνύματος. Η περίληψη μηνύματος κρυπτογραφείται με το μυστικό κλειδί και έτσι σχηματίζει την ψηφιακή υπογραφή.

Τα κείμενα υπογράφονται με την εισαγωγή στην αρχή τους ψηφιακών πιστοποιητικών υπογραφών οι οποίες περιέχουν το key id του κλειδιού που χρησιμοποιήθηκε για την υπογραφή τους, μια υπογεγραμμένη με το μυστικό κλειδί περίληψη του κειμένου και μια χρονική σφραγίδα της δημιουργίας της υπογραφής. Το key id χρησιμοποιείται από τον παραλήπτη για την ανεύρεση του δημόσιου κλειδιού του αποστολέα έτσι ώστε να ελέγξει την ψηφιακή υπογραφή. Το λογισμικό του παραλήπτη αναζητεί αυτόματα το δημόσιο κλειδί του αποστολέα και το user id του στο μπρελόκ δημοσίων κλειδιών που έχει στην κατοχή του ο παραλήπτης.

Τα κρυπτογραφημένα αρχεία περιέχουν στην αρχή τους το key id του δημοσίου κλειδιού που χρησιμοποιήθηκε στην κρυπτογράφησή τους. Ο παραλήπτης χρησιμοποιεί αυτό το key id για την ανεύρεση του μυστικού κλειδιού που απαιτείται για την αποκρυπτογράφηση του μηνύματος. Το λογισμικό του παραλήπτη αναζητεί αυτόματα το απαραίτητο μυστικό κλειδί αποκρυπτογράφησης στο μπρελόκ μυστικών κλειδιών του παραλήπτη.

Αυτοί οι δυο τύποι μπρελόκ κλειδιών είναι η κύρια μέθοδος της αποθήκευσης και διαχείρισης των δημόσιων και ιδιωτικών κλειδιών. Αντί να κρατάμε ξεχωριστά κλειδιά σε ξεχωριστά αρχεία κλειδιών τα μαζεύουμε σε μπρελόκ κλειδιών έτσι ώστε να διευκολύνουμε την αυτόματη ανεύρεσή τους είτε με τη χρήση του key id είτε με τη χρήση του user id. Κάθε χρήστης διατηρεί το δικό του ζεύγος μπρελόκ. Ένα ξεχωριστό δημόσιο κλειδί αποθηκεύεται προσωρινά σε ένα ξεχωριστό αρχείο μόνο για το χρόνο που χρειάζεται για την αποστολή του σε κάποιο φίλο ο οποίος κατόπιν θα το προσθέσει στο δικό του μπρελόκ κλειδιών.

5.6.3 Προστασία Δημοσίων Κλειδιών

Σε ένα κρυπτοσύστημα δημοσίων κλειδιών δεν υπάρχει ανάγκη προστασίας των δημοσίων κλειδιών, διότι το επιδιωκόμενο είναι η όσο το δυνατόν ευρύτερη διάδοσή τους. Το σημαντικό και αυτό που θα πρέπει να διασφαλίζεται είναι το να είμαστε σίγουροι ότι κάποιο δημόσιο κλειδί που φαίνεται ότι ανήκει σε κάποιον, όντως να ανήκει σε αυτόν. Αυτό μπορεί να είναι και το πιο σημαντικό μειονέκτημα του κρυπτοσυστήματος δημόσιων κλειδιών. Ας εξετάσουμε το λόγο:

Ας υποθέσουμε ότι ο Bob θέλει να στείλει ένα προσωπικό μήνυμα στην Alice. Για να το κάνει αυτό κατεβάζει το πιστοποιητικό δημοσίων κλειδιών από κάποιο σύστημα ηλεκτρονικού πίνακα ανακοινώσεων (BBS). Κατόπιν, κρυπτογραφεί το γράμμα προς την Alice με αυτό δημόσιο κλειδί και το στέλνει σε αυτήν μέσω της λειτουργίας e-mail του BBS.

Aτυχώς, τόσο για τον αποστολέα (Bob) όσο και για την Alice κάποιος τρίτος χρήστης – ας υποθέσουμε ο Charlie - έχει δημιουργήσει ένα δημόσιο κλειδί με το user id της Alice και το έχει βάλει στη θέση του πραγματικού κλειδιού της Alice. Ο Βob χρησιμοποίησε αυτό το πλαστογραφημένο κλειδί για να κρυπτογραφήσει το μήνυμα προς την Alice αντί του αληθινού κλειδιού της Alice. Όπως φαίνεται όλα δείχνουν φυσιολογικά διότι το πλαστογραφημένο κλειδί έχει το user id της Alice. Έτσι ο Charlie μπορεί να αποκρυπτογραφήσει το μήνυμα που προοριζόταν για την Alice μια και έχει το κλειδί που αντιστοιχεί στο πλαστογραφημένο δημόσιο κλειδί της Alice. Όμως το πρόβλημα δεν τελειώνει εδώ. Ο Charlie μπορεί επιπλέον να επανακρυπτογραφήσει το μήνυμα και να το προωθήσει στην Alice οπότε κανείς δεν πρόκειται να υποπτευθεί τίποτα. Εάν θέλει, μπορεί να προχωρήσει στη δημιουργία ψηφιακών υπογραφών της Alice με το πλαστογραφημένο κλειδί μια και όλοι θα το χρησιμοποιούν για να ελέγχουν τις υπογραφές της.

Όπως τελικά φαίνεται ο κίνδυνος είναι πολύ μεγάλος. Ο μόνος τρόπος να αποτραπούν τέτοιες καταστάσεις είναι η αποφυγή της υποκλοπής και του μπερδέματος των δημοσίων κλειδιών. Εάν κάποιος έχει πάρει το δημόσιο κλειδί της Alice κατευθείαν από την ίδια τότε δεν υπάρχει πρόβλημα. Αυτό βέβαια μπορεί να είναι πολύ δύσκολο εάν η Alice είναι χιλιάδες χιλιόμετρα μακριά ή απλά προσωρινά απρόσιτη.

Μία διέξοδος σε αυτό το πρόβλημα είναι η χρήση κάποιου τρίτου κοινά αποδεκτού "φίλου" ο οποίος έχει στη κατοχή του ένα καλό αντίγραφο του δημόσιου κλειδιού της Alice. Για παράδειγμα ας θεωρήσουμε ότι αυτός είναι ο David ο οποίος μπορεί να υπογράψει το δημόσιο κλειδί της Alice με τη δικό του μυστικό κλειδί και να εγγυηθεί με αυτό το τρόπο την αυθεντικότητα του κλειδιού της Alice.

Αυτή η διαδικασία θα παρήγαγε ένα υπογεγραμμένο πιστοποιητικό δημόσιου κλειδιού που θα αποδείκνυε την ακεραιότητα του κλειδιού της Alice. Αυτή η διαδικασία,βέβαια, προϋποθέτει την δυνατότητα ελέγχου του κλειδιού του David άρα την κατοχή ενός γνήσιου αντίγραφου του δημόσιου κλειδιού του. Ο David θα μπορούσε επιπλέον να στείλει στην Alice ένα υπογεγραμμένο αντίγραφο του δημόσιου κλειδιού του Bob. Με αυτό το τρόπο λειτουργεί σαν μεσάζοντας (introducer) μεταξύ του Bob και της Alice.

Το υπογεγραμμένο κλειδί για την Alice μπορεί να σταλεί από τον David ή την Alice στο BBS και από εκεί να το πάρει αργότερα όποιος το χρειαστεί. Αυτός το μόνο που θα χρειαστεί να κάνει, για να σιγουρευτεί για την ακεραιότητα του δημόσιου κλειδιού της Alice, είναι να την ελέγξει μέσω του δημόσιου κλειδιού του David. Κανένας δεν μπορεί να ξεγελάσει πλέον όποιον έχει το υπογεγραμμένο από τον David δημόσιο κλειδί της Alice διότι κανείς δεν μπορεί να πλαστογραφήσει την υπογραφή του David.

Κάποιο άτομο που τυγχάνει ευρείας εμπιστοσύνης θα μπορούσε να εξειδικευτεί στην παροχή αυτής της υπηρεσίας, δηλαδή της παροχής υπογραφών σε πιστοποιητικά δημοσίων κλειδιών άλλων χρηστών. Αυτό το κοινά αποδεκτό άτομο θα μπορούσε να είναι κάποιος "key server" ή κάποια υπηρεσία πιστοποίησης. Κάθε πιστοποιητικό δημόσιου κλειδιού που φέρει την υπογραφή αυτού του key server θα μπορεί να θεωρείται γνήσιο και έτσι άξιο της εμπιστοσύνης κάποιου. Το μόνο που χρειάζεται να κάνουν όσοι χρήστες θα ήθελαν να συμμετέχουν σε αυτή τη διαδικασία είναι να αποκτήσουν ένα καλό αντίγραφο του δημοσίου κλειδιού του key server έτσι ώστε να είναι σε θέση να επιβεβαιώσουν την υπογραφή αυτού.

Κάποιος κεντρικός key server ή μια υπηρεσία πιστοποίησης, θα ήταν κατάλληλη για κάποια μεγάλη και απρόσωπη επιχείρηση ή κυβερνητική υπηρεσία.

Η αποκεντρωμένη έκδοση του σχήματος αυτού είναι εκείνη που επιτρέπει σε όλους τους χρήστες να δρουν σαν μεσάζοντες, ο ένας για τον άλλο,κάτι που έχει καλύτερα αποτελέσματα από έναν και μοναδικό key server. Το PGP τείνει προς αυτή τη κατεύθυνση διότι αντανακλά καλύτερα το φυσικό τρόπο με τον οποίο αλληλεπιδρούν μεταξύ τους οι άνθρωποι στις σχέσεις τους και ταυτόχρονα επιτρέπει σε αυτούς να διαλέξουν ποιόν εμπιστεύονται για τη διαχείριση των κλειδιών τους.

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

Η χρήση ενός δημόσιου κλειδιού δεν θα πρέπει να ξεκινάει εάν δεν είμαστε σίγουροι ότι πρόκειται για ένα καλό δημόσιο κλειδί το οποίο ανήκει σε αυτόν που ισχυρίζεται ότι ανήκει. Μπορούμε να είμαστε σίγουροι για την προέλευση του κλειδιού εάν έχουμε κάποιο πιστοποιητικό από τον ιδιοκτήτη του ή κάποιον άλλο που εμπιστευόμαστε,από τον οποίο όμως έχουμε ήδη ένα εγγυημένο δημόσιο κλειδί. Επιπλέον το user id θα πρέπει να έχει ολόκληρο το όνομα του ιδιοκτήτη και όχι απλά το μικρό του ή κάποιο άλλο ψευδώνυμο.

Δεν έχει σημασία πόσο σίγουροι μπορεί να αισθανόμαστε για κάποιο δημόσιο κλειδί που κατεβάσαμε από κάποιον ηλεκτρονικό πίνακα ανακοινωθέντων—ΠΟΤΕ δεν θα πρέπει να εμπιστευόμαστε οτιδήποτε δεν έχει την υπογραφή κάποιου που εμπιστευόμαστε. Ένα δημόσιο κλειδί που απλά κατεβάσαμε δίχως να το ελέγξουμε είναι πιθανόν να έχει αλλοιωθεί από κάποιον τρίτο, ακόμα και από το διαχειριστή του ηλεκτρονικού πίνακα. Εάν ποτέ μας ζητηθεί να υπογράψουμε το δημόσιο κλειδί κάποιου άλλου θα πρέπει να σιγουρευτούμε ότι αυτό πραγματικά του ανήκει. Αυτό πρέπει να γίνει διότι η υπογραφή μας στο δημόσιο κλειδί εγγυάται την αυθεντικότητά του. Εάν έχουμε κάνει λάθος,τότε όσοι μας εμπιστεύονται θα εμπιστευτούν και το κλειδί με αβέβαια αποτελέσματα. Ο κανόνας λέει ότι υπογράφουμε δημόσια κλειδιά για τα οποία έχουμε ιδία γνώση της αυθεντικότητάς τους. Για να αποκτήσουμε αυτή τη γνώση μπορούμε για παράδειγμα να μιλήσουμε στον ιδιοκτήτη του κλειδιού στο τηλέφωνο και να επιβεβαιώσουμε τα στοιχεία που έχουμε στα χέρια μας. Με το να βάλουμε την υπογραφή μας σε ένα δημόσιο κλειδί για το οποίο ήμαστε σίγουροι δεν χάνουμε την αξιοπιστία μας ακόμα και αν αυτό ανήκει σε κάποιον ψυχοπαθή. Αυτό συμβαίνει διότι με την υπογραφή μας δεν λέμε τίποτα παραπάνω από το ότι αυτό το κλειδί ανήκει σε αυτόν που ισχυρίζεται ότι ανήκει—το ότι κάποιος μπορεί να εμπιστευθεί το κλειδί δεν έχει καμία σχέση με το αν μπορεί να εμπιστευθεί ή όχι τον ιδιοκτήτη του.

Η εμπιστοσύνη δεν είναι αναγκαστικά κάτι μεταβιβάσιμο. Για παράδειγμα μπορεί έχουμε κάποιον φίλο που εμπιστευόμαστε και ξέρουμε ότι δεν λέει ψέματα. Αυτός μπορεί να εμπιστεύεται τον πρόεδρο της κυβέρνησης. Όπως είναι αυτονόητο αυτό δεν σημαίνει ότι και εμείς εμπιστευόμαστε τον πρόεδρο της κυβέρνησης – κοινή λογική. Ανάλογα εάν εμπιστευόμαστε την υπογραφή της Alice σε ένα δημόσιο κλειδί και η Alice με τη σειρά της εμπιστεύεται την υπογραφή του Charlie σε κάποιο άλλο κλειδί, αυτό δεν σημαίνει ότι και εμείς εμπιστευόμαστε την υπογραφή του Charlie σε εκείνο το κλειδί.

Θα ήταν καλή ιδέα, οι χρήστες να κρατούσαν το δημόσιο κλειδί τους μαζί με ένα σύνολο από πιστοποιητικά για αυτό από διαφόρους μεσάζοντες με την ελπίδα ότι οι περισσότεροι χρήστες εμπιστεύονται κάποιον από αυτούς. Μπορεί λοιπόν, κάποιος χρήστης να ανακοινώσει το δημόσιο κλειδί του μαζί με τη συλλογή των πιστοποιητικών που διαθέτει για αυτό. Όταν υπογράφουμε το δημόσιο κλειδί κάποιου πρέπει να του το επιστρέφουμε μαζί με την υπογραφή μας ώστε να την προσθέσουνε στη συλλογή πιστοποιητικών για το δημόσιο κλειδί τους.

Το PGP κρατάει στοιχεία για το ποια από τα δημόσια κλειδιά που έχουμε στην κατοχή μας είναι πιστοποιημένα με υπογραφές που εμπιστευόμαστε. Το μόνο που εμείς πρέπει να κάνουμε είναι να πούμε στο PGP ποιους εμπιστευόμαστε σαν μεσάζοντες και να πιστοποιήσουμε τα κλειδιά τους με το δικό μας. Το PGP αναλαμβάνει από εκεί και πέρα να κρίνει αυτόματα κάποιο δημόσιο κλειδί ως έγκυρο ή όχι.

Πρέπει να διασφαλίσουμε ότι κανένας δεν πρόκειται να αλλοιώσει το μπρελόκ με τα κλειδιά μας. Ο έλεγχος ενός νέου υπογεγραμμένου δημοσίου κλειδιού πρέπει να εξαρτάται ολοκληρωτικά από την ακεραιότητα των κλειδιών τα οποία ήδη έχουμε στο μπρελόκ μας και τα οποία φυσικά εμπιστευόμαστε. Πρέπει να διατηρούμε συνεχή φυσικό έλεγχο των μπρελόκ δημοσίων κλειδιών μας σε κάποιο PC εκτός δικτύου όπως ακριβώς θα κάναμε και με το μυστικό κλειδί μας. Επιπλέον πρέπει να κρατάμε ένα αντίγραφο του δημόσιου και μυστικού κλειδιού μας σε κάποιο προστατευμένο μέσο όπου αποκλείεται ποτέ να τα σβήσουμε κατά λάθος. Από τη στιγμή κατά την οποία το δημόσιο κλειδί μας χρησιμοποιείται ως ο τελικός κριτής για τη πιστοποίηση ή μη όλων των άλλων κλειδιών του μπρελόκ είναι σημαντική για την ασφάλεια όλου του συστήματος η διασφάλισή του. Το PGP μπορεί αυτόματα να συγκρίνει το δημόσιο κλειδί μας με ένα αντίγραφό του σε κάποιο προστατευμένο φυσικό μέσο.

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

Ένας ακόμα τρόπος να προστατεύσουμε ολόκληρο το μπρελόκ με τα κλειδιά μας είναι να το υπογράψουμε ολόκληρο με το μυστικό μας κλειδί. Βέβαια θα έπρεπε πάλι να έχουμε κάπου αλλού προστατευμένο ένα αντίγραφο του δημοσίου κλειδιού μας για να είμαστε σε θέση να ελέγξουμε την υπογραφή μας. Όπως είναι φυσικό δεν μπορούμε να βασιστούμε στο δημόσιο κλειδί μας, που βρίσκεται στο μπρελόκ, για τον έλεγχο της υπογραφής μας διότι αυτό είναι μέρος αυτού που πάμε να προστατέψουμε.

5.6.4 Διαδικασία Αναγνώρισης Έγκυρων Κλειδιών

Το PGP παρακολουθεί ποια από τα κλειδιά που υπάρχουν στο μπρελόκ δημοσίων κλειδιών είναι πιστοποιημένα και ποια όχι με υπογραφές χρηστών που εμπιστευόμαστε. Το μόνο που πρέπει να κάνουμε είναι να "πούμε" στο PGP ποιους χρήστες εμπιστευόμαστε σαν μεσάζοντες και να πιστοποιήσουμε τα κλειδιά τους με το δικό μας κλειδί. Το PGP αναλαμβάνει από εκεί να κινήσει αυτόματα διαδικασίες ελέγχου της εγκυρότητας κλειδιών που είναι υπογεγραμμένα από τους μεσάζοντες που εμείς ορίσαμε. Υπάρχει βέβαια πάντα η δυνατότητα να υπογράψουμε κλειδιά και εμείς οι ίδιοι.

Υπάρχουν δύο διαφορετικά κριτήρια βάση των οποίων το PGP κρίνει τη χρησιμότητα των κλειδιών και τα οποία δεν πρέπει να συγχέουμε:

1. Το κλειδί ανήκει σε αυτόν που ισχυρίζεται ότι ανήκει; (έχει πιστοποιηθεί από κάποιον του οποίου την υπογραφή εμπιστευόμαστε;)
2. Ανήκει σε κάποιον που μπορούμε να εμπιστευθούμε για την πιστοποίηση άλλων κλειδιών;

Το PGP μπορεί να υπολογίσει την απάντηση στην πρώτη ερώτηση. Η απάντηση στη δεύτερη πρέπει να δοθεί αποκλειστικά από το χρήστη. Όταν ο χρήστης δώσει την απάντηση στην δεύτερη ερώτηση τότε το PGP μπορεί να υπολογίσει την απάντηση στην πρώτη ερώτηση για άλλα κλειδιά τα οποία υπογράφονται από αυτόν που έχουμε ορίσει σαν έμπιστο. Κλειδιά τα οποία έχουν πιστοποιηθεί από κάποιον που έχουμε ορίσει ως έμπιστο θεωρούνται έγκυρα από το PGP. Τα κλειδιά που ανήκουν σε έμπιστους μεσάζοντες πρέπει να πιστοποιηθούν από είτε από εμάς τους ίδιους είτε από κάποιον άλλο που έχουμε ορίσει ως έμπιστο.

Το PGP δίνει επιπλέον τη δυνατότητα ορισμού διαφορετικών επιπέδων εμπιστοσύνης για διαφορετικούς μεσάζοντες. Το ότι εμπιστευόμαστε κάποιον να δράσει ως μεσάζοντας δεν σημαίνει μόνο ότι τον εμπιστευόμαστε αλλά επιπλέον ότι τον θεωρούμε αρκετά ικανό να διαχειριστεί κλειδιά επιλέγοντας ποια από αυτά πρέπει και ποια όχι να υπογράψει. Μπορεί να ορίσουμε έναν χρήστη - μεσάζοντα στο PGP σαν άγνωστο, μη έμπιστο, μερικώς έμπιστο και εντελώς έμπιστο για να πιστοποιεί δημόσια κλειδιά. Αυτή η πληροφορία, που αφορά το βαθμό εμπιστοσύνης κάποιου μεσάζοντα, περιέχεται στο μπρελόκ των κλειδιών μαζί με το αντίστοιχο κλειδί (του μεσάζοντα) και δεν αντιγράφεται σε καμία περίπτωση κατά την αντιγραφή κάποιου κλειδιού του μπρελόκ διότι θεωρείται εμπιστευτική πληροφορία μια και αντικατοπτρίζει την άποψη του κατόχου του για τους μεσάζοντες - απόλυτα προσωπικό στοιχείο.

Όταν το PGP ελέγχει την εγκυρότητα ενός κλειδιού αυτό που κάνει είναι να ελέγχει τον βαθμό εμπιστοσύνης όλων των συνημμένων υπογραφών πιστοποίησής του. Κατόπιν υπολογίζει ένα μέσο επίπεδο εμπιστοσύνης - για παράδειγμα δύο μερικώς έμπιστες υπογραφές ισοδυναμούν με μία πλήρως έμπιστη. Το σκεπτικό λειτουργίας του PGP προσαρμόζεται στις απαιτήσεις του χρήστη και ρυθμίζεται αναλόγως (για παράδειγμα μπορούμε να ρυθμίσουμε το PGP να θεωρεί ένα κλειδί έγκυρο μόνο εάν αυτό φέρει δύο πλήρως έμπιστες υπογραφές ή τρεις μερικώς έμπιστες).

Το δικό μας κλειδί θεωρείται έγκυρο από το PGP αξιωματικά και για αυτό το λόγο δεν χρειάζεται την πιστοποίηση από κανέναν. Το PGP γνωρίζει ποια δημόσια κλειδιά είναι δικά μας κοιτάζοντας να βρει τα αντίστοιχα μυστικά κλειδιά στο μπρελόκ τους. Το PGP θεωρεί επιπλέον ότι εμπιστευόμαστε τους εαυτούς μας για να πιστοποιούν άλλα κλειδιά.

Όσο θα περνάει ο καιρός θα λαμβάνουμε όλο και περισσότερα κλειδιά από χρήστες που ίσως να θέλουμε να ορίσουμε ως μεσάζοντες. Κάθε ένας από αυτούς θα έχει τους δικούς του μεσάζοντες των οποίων τα πιστοποιητικά - υπογραφές θα μοιράζει μαζί με το κλειδί του με την ελπίδα ότι όποιος τα λάβει να εμπιστεύεται κάποιο από όλα. Έτσι δημιουργείται ένα αποκεντρωμένο δίκτυο εμπιστοσύνης για όλα τα δημόσια κλειδιά.

Αυτή η μοναδική προσέγγιση έρχεται σε αντίθεση με τα κατεστημένα κυβερνητικά σχήματα διαχείρισης κλειδιών, όπως το PEM (Ιnternet Privacy Enhanced Mail), τα οποία βασίζονται σε συστήματα κεντρικού ελέγχου και υποχρεωτικής εμπιστοσύνης σε αυτά. Τα σχήματα αυτά απαρτίζονται από ιεραρχικές οντότητες που υπαγορεύουν ποιόν πρέπει να εμπιστευόμαστε. Αυτό είναι φανερό ότι έρχεται σε πλήρη αντίθεση με τη σχεδιαστική αρχή του PGP η οποία επιτρέπει στον καθένα και ανεξάρτητα από οποιονδήποτε και οτιδήποτε άλλο να καθορίσει ο ίδιος την πολιτική που θέλει να ακολουθήσει στη διαχείριση των κλαδιών του. Έτσι το PGP βάζει το χρήστη και όχι το σύστημα στην κορυφή της προσωπική του πυραμίδα πιστοποίησης.

5.6.5 Προστασία του Μυστικού Κλειδιού

Η προστασία του μυστικού κλειδιού και της φράσης-κλειδί του, είναι κάτι το αυτονόητο στο οποίο πρέπει να δοθεί μεγάλη προσοχή. Εάν ποτέ το μυστικό κλειδί πέσει σε λάθος χέρια – τα οποία είναι οποιαδήποτε άλλα εκτός των δικών μας—τότε θα πρέπει άμεσα, τόσο για τη δική μας ασφάλεια όσο και των άλλων, να ειδοποιήσουμε τους πάντες για το γεγονός προτού κάποιος αρχίσει να υπογράφει με το "όνομά" μας. Θα μπορούσε, για παράδειγμα, να υπογράψει ένα σύνολο από δημόσια κλειδιά δημιουργώντας έτσι πρόβλημα σε πολλούς χρήστες ειδικά εάν η υπογραφή μας τυγχάνει ευρείας εμπιστοσύνης και αποδοχής. Φυσικά, κίνδυνο διατρέχουμε και από το γεγονός της έκθεσης όλων των μηνυμάτων μας στα μάτια αυτού που έχει το προσωπικό μας κλειδί.

Η προστασία του μυστικού κλειδιού πρέπει να αρχίζει με τη φυσική του διασφάλιση. Μπορούμε να το κρατάμε σε κάποιο PC στο σπίτι ή κάποιο υπολογιστή notebook μια και αυτά τα έχουμε υπό την επίβλεψή μας συνεχώς. Εάν ποτέ υπάρξει ανάγκη χρησιμοποίησης υπολογιστή στο γραφείο ή οπουδήποτε αλλού τότε θα πρέπει να μεταφέρουμε το μυστικό κλειδί μας σε αυτόν μέσο κάποιας δισκέτας ενδεχομένως και για όσο χρειάζεται ενώ όταν τελειώσουμε τη δουλεία μας δεν πρέπει να αφήσουμε πίσω οτιδήποτε μπορεί να οδηγήσει στην αποκάλυψη του. Δεν είναι επίσης σωστό να αφήνουμε το μυστικό κλειδί μας σε κάποιο απομακρυσμένο μηχάνημα (ένας Unix dial-in server) διότι μπορεί κάποιος που παρακολουθεί τις επικοινωνίες μέσω modem να υποκλέψει τη μυστική φράση (pass phrase) και να αποκτήσει το μυστικό από το απομακρυσμένο σύστημα. Συμπερασματικά λέμε ότι θα πρέπει να γίνεται χρήση του μυστικού κλειδιού μόνο σε συστήματα στα οποία έχουμε φυσικό έλεγχο.

Επιπρόσθετα, πρέπει να προσέξουμε πού αποθηκεύουμε τη μυστική φράση-κλειδί. Δεν πρέπει ποτέ αυτή να βρίσκεται στον ίδιο υπολογιστή με αυτόν που έχει το αρχείο του μυστικού κλειδιού μας. Η αποθήκευση τόσο του μυστικού κλειδιού όσο και της μυστικής φράσης στον ίδιο υπολογιστή είναι το ίδιο επικίνδυνη με την φύλαξη του PIN ενός τραπεζικού ATM λογαριασμού στο ίδιο πορτοφόλι με την κάρτα ΑΤΜ. Ένα πράγμα είναι σίγουρο - δεν θέλουμε σε καμία περίπτωση αυτός που θα έχει στα χέρια του τον σκληρό δίσκο με το μυστικό μας κλειδί να έχει στη διάθεσή του και τη μυστική φράση. Το ιδανικό θα ήταν να απομνημονεύαμε τη μυστική φράση και να μην την φυλάγαμε σε κανένα άλλο μηχάνημα εκτός του εγκεφάλου μας. Εάν, ωστόσο, νιώθουμε ότι πρέπει να τη γράψουμε κάπου θα πρέπει να την ασφαλίσουμε καλλίτερα ίσως και από το ίδιο το μυστικό μας κλειδί.

Κάτι άλλο επίσης σημαντικό, που πρέπει να κάνουμε, είναι να παίρνουμε backup του μυστικού μπρελόκ μας διότι μόνο εμείς έχουμε το μοναδικό αντίγραφο αυτού και πιθανή απώλειά του θα ισοδυναμούσε με αχρήστευση όλων των δημοσίων κλειδιών που διανείμαμε στον κόσμο.

Το αποκεντρωτικό σχήμα φιλοσοφίας αλλά και λειτουργίας που έχει επιλέξει να χρησιμοποιήσει το PGP εκτός από τα πλεονεκτήματα στη διαχείριση των κλειδιών έχει και τα μειονεκτήματα του. Δεν υπάρχει μία κεντρική λίστα που να περιέχει τα μη έγκυρα κλειδιά κάνοντας πιο δύσκολη την γνώση τους. Έτσι αν κάτι πάει στραβά η διαδικασία γνωστοποίησής του είναι επίπονη. Εάν τελικά το μυστικό κλειδί και η μυστική φράση πέσουν στα χέρια άλλων θα πρέπει να φτιάξουμε και να διανείμουμε ένα "πιστοποιητικό απολεσθέντος κλειδιού" (key compromise certificate). Αυτός ο τύπος πιστοποιητικού χρησιμοποιείται για να προειδοποιεί άλλους χρήστες να σταματήσουν να χρησιμοποιούν το αντίστοιχο δημόσιο κλειδί μας. Μπορούμε να χρησιμοποιήσουμε το PGP στη δημιουργία αυτού του πιστοποιητικού και κατόπιν να το στείλουμε σε όλους τους φίλους και συνεργάτες μας σε όλο τον κόσμο. Η έκδοση του PGP που τρέχει σε αυτούς θα αναλάβει να εγκαταστήσει το πιστοποιητικό του απολεσθέντος κλειδιού στα δημόσια μπρελόκ τους και από εκείνη τη στιγμή θα αποτρέπεται αυτόματα η επαναχρησιμοποίησή τους. Μπορούμε κατόπιν να δημιουργήσουμε ένα νέο ζεύγος μυστικού/δημοσίου κλειδιού και να αρχίσουμε πλέον να δουλεύουμε με αυτά.

5.6.6 Περαιτέρω Πληροφορίες

Για περισσότερες πληροφορίες, τα site http://www.pgpi.com και http://www.nai.com μπορούν να βοηθήσουν πολύ.

5.7.1 Εισαγωγή

Τα εργαλεία απομακρυσμένης επικοινωνίας (rsh, rcp, rlogin) είναι γνωστά για την ευκολία χρήσης τους και την παροχή γρήγορης πρόσβασης σε άλλες μηχανές. Το πρόβλημα, όμως, είναι ότι βασίζονται σε IP διευθύνσεις ή host names για την πιστοποίηση της ταυτότητας των μηχανών, γεγονός που τα καθιστά ανασφαλή καθ' ότι οι υπηρεσίες του DNS δεν είναι άξιες εμπιστοσύνης. Επίσης, η μετάδοση των κωδικών χωρίς κανένα είδος προστασίας οξύνει τις τρύπες ασφαλείας. Για να μπορούν, λοιπόν, να χρησιμοποιούνται σε ασφαλή περιβάλλοντα πρέπει να διαθέτουν πιο καλύτερους μηχανισμούς πιστοποίησης ταυτότητας. Η εισαγωγή της έννοιας της κρυπτογράφησης και των ψηφιακών υπογραφών στα εργαλεία rsh, rcp και rlogin, δημιούργησε το Secure Shell (SSH).

Το SSH σχεδιάστηκε για να αντικαταστήσει τα εργαλεία rsh, rcp και rlogin με τα αντίστοιχα ssh, scp και slogin, με επιπλέον χαρακτηριστικά αυτά της ισχυρής από άκρη σε άκρη κρυπτογράφηση, της βελτιωμένης πιστοποίησης ταυτότητας χρήστη και μηχανής και την προώθηση TCP πορτών και Χ11 συνδέσεων.

Σε αυτό το σημείο είναι απαραίτητο να εξηγήσουμε τον όρο "προώθηση TCP πορτών". Ας θεωρήσουμε τις τρεις μηχανές του παρακάτω παραδείγματος. Η μηχανή Χ είναι ο client και εγκαθιστά σύνδεση με τον server Υ μέσω SSH. Μια πόρτα ρου Χ, ας πούμε η 1999, ρυθμίζεται για προώθηση σε μια άλλη πόρτα στο απομακρυσμένο σύστημα Ζ, ας πούμε την 23. Η πόρτα προωθείται μέσω του κρυπτογραφημένου καναλιού στον Υ και από εκεί προωθείται στην πόρτα 23 του Ζ. Έτσι, η εντολή telnet localhost 1999 θα έχει σαν αποτέλεσμα μια telnet σύνδεση με τον Ζ.

Η τρέχοντα έκδοση του πρωτοκόλλου είναι η 2 (version 2.0).

5.7.2 Περιγραφή του SSH πρωτοκόλλου

• Το Transport layer protocol παρέχει πιστοποίηση της ταυτότητας του server, ακεραιότητα των δεδομένων και εξασφάλιση του απόρρητου της συναλλαγής. Προαιρετικά μπορεί να εφαρμόσει και συμπίεση δεδομένων. Τυπικά τρέχει πάνω από μία TCP/IP σύνδεση.
• Το User Authentication protocol πιστοποιεί την ταυτότητα του πελάτη- χρήστη στον server. Τρέχει πάνω από το Transport layer protocol.
• Το Connection protocol πολυπλέκει το κρυπτογραφημένο φυσικό κανάλι σε αρκετά λογικά κανάλια και τρέχει πάνω από το User Authentication protocol.

Σχηματική αναπαράσταση των επιμέρους πρωτοκόλλων του SSH.

Ιδιωτικά Και Δημόσια Κλειδιά

Κάθε server και client πρέπει να έχει ένα ζευγάρι ιδιωτικής – δημόσιας κλείδας για να μπορεί να επαλήθευση την ταυτότητα του στο άλλο άκρο. Επιτρέπεται η κατοχή περισσότερων του ενός ζευγάρια κλειδιών, όταν χρησιμοποιούνται με διαφορετικούς αλγόριθμους, ενώ η από κοινού χρήση ενός ζεύγους από πολλούς server δεν απαγορεύεται.

Για να μπορεί ο client με ευκολία να επαληθεύει την ταυτότητα του server είναι απαραίτητο να γνωρίζει την δημόσια κλείδα που αντιστοιχεί στον server που θέλει να συνδεθεί. Υπάρχουν δυο διαφορετικά μοντέλα που εξασφαλίζουν την προηγούμενη προϋπόθεση:

• Πρώτον, ο client έχει αποθηκευμένα σε μια τοπική βάση δεδομένων τα ονόματα των server και τις σχετιζόμενες με αυτά δημόσιες κλείδες. Αυτή η μέθοδος δεν απαιτεί μια κεντρική διαχείριση των κλειδιών από τρίτους. Το μειονέκτημα είναι ότι το μέγεθος μιας τέτοιας βάσης δεδομένων μπορεί να εξελιχθεί σημαντικά και συνεπώς η συντήρηση της να γίνει δύσκολη.
• Στην δεύτερη περίπτωση, σχέση μεταξύ του ονόματος του server και του κλειδιού του πιστοποιείται από μια άξια εμπιστοσύνης Certification Authority. Το πρόγραμμα του πελάτη γνωρίζει μόνο την δημόσια κλείδα της Certification Authority και μπορεί να επιβεβαιώσει την εγκυρότητα των κλείδων που έχουν πιστοποιηθεί από την CA. Εδώ δεν υπάρχει το πρόβλημα της διατήρησης μεγάλων βάσεων δεδομένων από τα τοπικά συστήματα, αφού μόνο ένα κλειδί χρειάζεται να αποθηκεύει ο client. Από την άλλη μεριά, όμως, δεν είναι δυνατή η απόλυτη εμπιστοσύνη στις διαδικασίες της Certification Authority. Επίσης, πιστοποίηση κάθε κλειδιού μπορεί να είναι μια χρονοβόρα και περίπλοκή διαδικασία.

Οι εφαρμογές του SSH μπορούν να παρέχουν επιπρόσθετες μεθόδους επικύρωσης των δημόσιων κλειδιών, όπως για παράδειγμα την παραγωγή ενός δεκαεξαδικού "αποτυπώματος" της κλείδας και από τα δύο άκρα και την σύγκριση τους μέσω εξωτερικών καναλιών επικοινωνίας (π.χ. τηλέφωνο). Κλείδες που δεν επαληθεύονται, κανονικά δεν πρέπει να γίνονται δεκτές.

Επεκτασιμότητα

Βασικός στόχος της σχεδίασης είναι η διατήρηση του πρωτοκόλλου όσο το δυνατόν απλό γίνεται, με όσο το δυνατόν λιγότερους αλγόριθμους. Όλες οι εφαρμογές πρέπει να υποστηρίζουν ένα ελάχιστο σύνολο αλγόριθμων για να εξασφαλιστεί η δια – λειτουργικότητα. Στο μέλλον αναμένεται η πρόσθεση και άλλων αλγορίθμων.

Θέματα Πολιτικής

• Οι αλγόριθμοι και οι μηχανισμοί που πρόκειται να χρησιμοποιηθούν για κάθε κατεύθυνση (client a server ή client ? server). Πρέπει να ορίζεται ποιος προτιμάται.
• Η μέθοδοι πιστοποίησης της ταυτότητας, ξεχωριστοί για κάθε χρήστη που θα εφαρμόζει ο server. Η πολιτική του server μπορεί να ζητά πολλαπλές διαδικασίες πιστοποίησης για μερικού ή όλους τους χρήστες, ενώ οι απαιτούμενοι αλγόριθμοι μπορούν να εξαρτώνται από την τοποθεσία από όπου προσπαθεί να συνδεθεί ο χρήστης.
• Οι ενέργειες που επιτρέπονται σε κάθε χρήστη και στον server. Η πολιτική ασφαλείας δεν θα πρέπει να επιτρέπει στον server να εκτελεί εντολές στην μηχανή του χρήστη ούτε στον χρήστη να συνδέεται στον authentication server.

Ιδιότητες Ασφάλειας

Για την ταχεία ανάπτυξη και υιοθέτηση του πρωτοκόλλου, κάποιες έχουν γίνει παραχωρήσεις. Σημαντικότερη από αυτές είναι η καθιέρωση της επαλήθευσης των κλείδων με υποχρεωτική, γεγονός όμως που δεν συνιστάται.

5.7.4 Transport Layer Protocol

Το Transport Layer Protocol είναι ένα ασφαλές χαμηλού επιπέδου πρωτόκολλο μεταφοράς, που παρέχει ισχυρή κρυπτογράφηση, πιστοποίηση του server και ακεραιότητα των δεδομένων. Σε αυτό το επίπεδο γίνεται η διαπραγμάτευση των αλγόρίθμων ανταλλαγής κλειδιών, συμμετρικής κρυπτογράφησης, ασύμμετρης κρυπτογράφησης, hash και MAC. Συνήθως τρέχει πάνω από TCP/IP. Η πιστοποίηση ταυτότητας σε αυτό το επίπεδο αναφέρεται μόνο σε πιστοποίηση υπολογιστικών μηχανών και όχι χρηστών. Το User Authentication Protocol αναλαμβάνει την επιβεβαίωση της ταυτότητας των χρηστών.

Έχει σχεδιαστεί για να είναι απλό, ευέλικτο, να επιτρέπει την διαπραγμάτευση παραμέτρων και να χρησιμοποιεί ένα ελάχιστο αριθμό απαραίτητων μηνυμάτων για την εγκαθίδρυση της σύνδεσης. Για τα περισσότερα περιβάλλοντα, έχει υπολογιστεί ότι ένας αριθμός 2 ανταλλαγών (round-trips) είναι αρκετός για πλήρη επικοινωνία όλων των απαραίτητων πληροφοριών. Η χειρότερη περίπτωση είναι 3 round-trips.

Εγκατάσταση της Σύνδεσης

Την διαδικασία ξεκινά ο client, ενώ ο server χρησιμοποιεί την πόρτα (port) 22 για ανταποκρίνεται τις επερχόμενες κλήσεις για σύνδεση. Όταν επιτευχθεί η ζεύξη των επικοινωνούντων σημείων, τα δύο άκρα πρέπει να στείλουν μια ακολουθία χαρακτήρων της μορφής "SSH-protoversion-softwareversion-comments" ακολουθούμενη από χαρακτήρες αλλαγής γραμμής και επιστροφής του κέρσορα (carriage return and newline characters). Το μέγιστο μήκος αυτής της ακολουθίας είναι 255 χαρακτήρες περιλαμβανομένων και των χαρακτήρων ελέγχου. Οι αριθμοί έκδοσης πρέπει να αποτελούνται από εκτυπώσιμους ASCII χαρακτήρες εκτός του κενού διαστήματος και του σήματος της αφαίρεσης (-). Χρησιμοποιείται για συμβατότητα μεταξύ παλιών εκδόσεων και για να υποδηλώσει τις δυνατότητες του συστήματος. Το πεδίο comments περιέχει επιπρόσθετες πληροφορίες που μπορεί να είναι χρήσιμες στην επίλυση διάφορων προβλημάτων.

Η διαπραγμάτευση για των αλγορίθμων ξεκινά μόλις σταλεί και από τις δύο μεριές αυτό το αναγνωριστικό. Όλα τα πακέτα που ακολουθούν χρησιμοποιούν το Binary Packet Protocol που θα περιγράψουμε αργότερα.

1. Ζεύξη των δύο σημείων.
2. Ανταλλαγή της ακολουθίας "SSH-protoversion-softwareversion-comments".
3. Διαπραγμάτευση αλγορίθμων κρυπτογράφησης και MAC και πιστοποίηση ταυτότητας του server.
4. Αίτηση εξυπηρέτησης από τον client στον sever.
5. Ανταλλαγή περαιτέρω δεδομένων.

Τα δύο πρώτα βήματα συζητήθηκαν στο παρών κεφάλαιο. Παρακάτω θα αναφερθούμε στα υπόλοιπα βήματα.

Διαπραγμάτευση Αλγορίθμων

Η πιστοποίηση της ταυτότητας μπορεί να είναι υπονοούμενη και μετά από αυτήν ακολουθεί η αίτηση εξυπηρέτησης του client.

Το αρχικό πακέτο, που σηματοδοτεί την αρχή αυτού του βήματος, έχει την παρακάτω δομή:

uint32 0 (reserved for future extension)

Στην πρώτη στήλη αναφέρεται η μορφή των δεδομένων κάθε πεδίου (δυαδικά, boolean κτλ.), ενώ η δεύτερη στήλη περιγράφει την χρησιμότητα αυτών. Με τον όρο byte περιγράφουμε ποσότητα 8 bits (octet) και ομοίως ο γενικός όρος byte[n] περιγράφει μονοδιάστατο πίνακα bytes, όπου n ο αριθμός των bytes του πίνακα. Ο όρος boolean υποδηλώνει μοναδικό byte που παίρνει τις τιμές 0 ή 1. Η τιμή 0 φανερώνει "ΛΑΘΟΣ" και η τιμή 1 φανερώνει "ΑΛΗΘΕΙΑ". Ο όρος uint32 αναφέρεται σε ακέραιο 32 bit αποθηκευμένος σαν 4 bytes με το Most Significant Bit (MSB) πρώτο. Τέλος, ο όρος string παρουσιάζει δυαδικά δεδομένα αυθαίρετου μήκους.

Με το πέρας αυτού του βήματος, παράγονται δύο τιμές που έχουν στην κατοχή τους και τα δύο συστήματα: ένα μυστικό κλειδί Κ και μια hash value. Από αυτά τα δύο και με κατάλληλο αλγόριθμο προκύπτουν κλειδιά κρυπτογράφησης και πιστοποίησης. Η hash value χρησιμοποιείται και σαν session identifier, τιμή που ταυτίζει με μοναδικό τρόπο την σύνδεση.

Μετά την καθιέρωση των χρησιμοποιούμενων αλγόριθμων, υποχρεούται ο server να αποδείξει την ταυτότητα του. Αυτό επιτυγχάνεται με την υπογραφή του session identifier με την ιδιωτική τού κλείδα και αποστολή του αποτελέσματος στον client. Μαζί αποστέλλονται και κατάλληλος αριθμός πιστοποιητικών που εμπεριέχούν την δημόσια κλείδα του server.

Αίτηση Εξυπηρέτησης

Αφού ληφθούν όλες οι απαραίτητες αποφάσεις σχετικά με τους χρησιμοποιούμενους μηχανισμούς, ο client στέλνει πακέτο που περιέχει αίτηση για συγκεκριμένη υπηρεσία. Το πακέτο έχει την εξής μορφή:

string service name

όπου η πρώτη γραμμή ταυτίζει το πακέτο σαν πακέτο αίτησης εξυπηρέτησης και η δεύτερη γραμμή δηλώνει το όνομα της υπηρεσίας που ζητείται. Τα ονόματα ssh-useraut και ssh-connection είναι κρατημένα για της υπηρεσίες του πρωτοκόλλου User Authentication και Connection αντίστοιχα.

Εάν ο server απορρίψει την αίτηση, στέλνει κατάλληλο μήνυμα αποσύνδεσης και η σύνδεση τερματίζεται. Διαφορετικά, εάν η υπηρεσία υποστηρίζεται και επιτρέπεται στον client, απαντά με

string service name

Ο client περιμένει για την απάντηση του server πριν προχωρήσει σε αποστολή άλλων δεδομένων.

Binary Packet Protocol

Κάθε πακέτο είναι της μορφής:

byte[m] mac (message authentication code); m = mac_length

Το ελάχιστο μήκος του πακέτου είναι 16 bytes και το μέγιστο 35000 bytes. Όλες οι εφαρμογές πρέπει να μπορούν να επεξεργάζονται πακέτα με ασυμπίεστο payload 23768 bytes ή λιγότερο. Πακέτα με μεγαλύτερο μήκος, θα στέλνονται μόνο όταν η έκδοση του πρωτοκόλλου στο "SSH-protoversion-softwareversion-comments" υποδηλώνει ότι υποστηρίζονται.

Κατηγορίες Αλγόριθμων

Αλγόριθμοι Συμπίεσης

Εάν έχει διαπραγματευθεί ο αλγόριθμος συμπίεσης, τότε συμπιέζονται μόνο τα περιεχόμενα του πεδίου payload σε κάθε πακέτο. Το μήκος του πακέτου και το MAC υπολογίζονται από το συμπιεσμένο payload. Ορίζεται ο αλγόριθμος GNU ZLIB (LZ77), η υποστήριξή του οποίου είναι προαιρετική, ενώ υπάρχει πάντα η δυνατότητα μη συμπίεσης. Η συμπίεση για κάθε κατεύθυνση πρέπει να είναι ανεξάρτητη του αλγόριθμου που χρησιμοποιείται στην άλλη αντίθετη φορά.

Οι ακόλουθοι ciphers υποστηρίζονται επί του παρόντος:

• Triple DES in CBC mode.
• Blowfish in CBC mode.
• ARCFOUR stream cipher (συμβατός με τον RC4).
• IDEA in CBC mode.
• CAST-128 in CBC mode.
• Καμία κρυπτογράφηση.

Από αυτούς ο Triple DES είναι υποχρεωτικά υποστηριζόμενος, ο Blowfish απλά συνιστάται, ενώ οι υπόλοιποι είναι προαιρετικοί.

Αλγόριθμοι MAC

Η ακεραιότητα των δεδομένων εξασφαλίζεται με την παραγωγή του MAC του μυστικού κλειδιού Κ, του αύξοντα αριθμού του πακέτου και των χρήσιμων περιεχομένων του πακέτου. Αρχικά, πριν την διαπραγμάτευση του αλγόριθμου, δεν υπάρχει MAC. Η παραγωγή του γίνεται πριν την κρυπτογράφηση των περιεχομένων. Τα MAC bytes μεταδίδονται στο τέλος του πακέτου, χωρίς κρυπτογράφηση.

Ο αύξοντας αριθμός του πακέτου είναι ένας ακέραιος που σε μορφή uint32 και είναι μηδέν για το πρώτο πακέτο. Αυξάνεται με την αποστολή κάθε πακέτου και μηδενίζεται κάθε 2³² πακέτα, ενώ ο ίδιος δεν περιλαμβάνεται στο πακέτο ποτέ.

Οι αλγόριθμοι MAC επιλέγονται ανεξάρτητα για κάθε κατεύθυνση και για κάθε κατεύθυνση μπορεί να τρέχει διαφορετικός αλγόριθμος.

• HMAC σε συνδυασμό με τον SHA1.
• HMAC σε συνδυασμό με τον MD5.
• Χωρίς MAC.

Ο πρώτος είναι απαιτούμενος, ο δεύτερος προαιρετικός και ο τρίτος δεν συνιστάται.

Αλγόριθμοι Ανταλλαγής Κλειδιών

Ένας τέτοιος αλγόριθμος καθορίζει πως παράγονται και ανταλλάσσονται κλειδιά κρυπτογράφησης μίας χρήσης και πως γίνεται η πιστοποίηση της ταυτότητας του server. Η μία και μοναδική μέθοδος που υποστηρίζεται είναι η Diffie-Hellman με hash αλγόριθμο τον SHA-1.

Αλγόριθμοι Ασύμμετρων Κλειδιών

• Key format: Πως κωδικοποιείται η κλείδα και πως παρουσιάζονται τα πιστοποιητικά, που περιέχουν την δημόσια κλείδα.
• Signature and/or encryption algorithms: Μερικοί τύποι κλείδων δεν υποστηρίζουν και ψηφιακές υπογραφές και κρυπτογραφία.
• Encoding of signatures and/or encrypted data: Περιλαμβάνει το απαραίτητο συμπλήρωμα και μορφή των υπογραφών και κρυπτογραφήσεων.

• DSS
• X.509 Certificates
• SPKI Certificates
• PGP Certificates

Η υποστήριξη του DSS είναι απαιτούμενη, του X.509 συνιστάται και οι υπόλοιποι δύο είναι προαιρετικοί.

5.7.5 User Authentication Protocol

Σε αυτό το πρωτόκολλο γίνεται η πιστοποίηση της ταυτότητας του χρήστη που χειρίζεται το μηχανή του client. Προορίζεται να τρέχει πάνω από το SSH Transport Layer Protocol, το οποίο παρέχει ακεραιτότητα δεδομένων και απόρρητη επικοινωνία. Η πρώτη αίτηση εξυπηρέτησης από τον client μετά την διαπραγμάτευση των αλγορίθμων και πιστοποίηση της ταυτότητας του server, είναι για την υπηρεσία με το όνομα "ssh-userauth"και αναφέρεται σε αυτό το πρωτόκολλο.

Όταν το πρωτόκολλο ξεκινά, λαμβάνει από το Transport Layer Protocol το session identifier που χρησιμοποιείται για να προσδιορίζει την σύνδεση με μοναδικό τρόπο. Ο server οδηγεί την διαδικασία της επαλήθευσης της ταυτότητας του χρήστη, λέγοντας στον client ποιες μέθοδοι μπορούν να εφαρμοστούν. Ο server έχει τον απόλυτο έλεγχο της διαδικασίας, αλλά παράλληλα παρέχει στον client την ευελιξία να επιλέξει τον αλγόριθμο που υποστηρίζει περισσότερο ή που είναι πιο βολική στον χρήστη. Οι υποστηριζόμενες μέθοδοι είναι τρεις: (α) με χρήση των δημοσίων κλείδων των χρηστών, (β) με χρήση μυστικών κωδικών και (γ) με χρήση των δημοσίων κλείδων των μηχανών που εργάζονται οι χρήστες. Θα αναλυθούν και οι τρεις παρακάτω.

Ο server θα πρέπει να έχει ένα προκαθορισμένο χρονικό όριο κατά την διάρκεια του οποίου πρέπει να έχει ολοκληρωθεί η πιστοποίηση της ταυτότητας του χρήστη. Εάν η πιστοποίηση δεν έχει γίνει δεκτή μέσα στο διάστημα αυτό, η σύνδεση θα πρέπει να διακοπεί. Ο χρόνος που συνιστάται είναι 10 λεπτά. Επιπλέον, η SSH εφαρμογή θα πρέπει να περιορίζει τον αριθμό των αποτυχημένων προσπαθειών κατά την διάρκεια μιας συγκεκριμένης σύνδεσης. Ο αριθμός αυτό συνιστάται στις 20 προσπάθειες.

Όλες αιτήσεις για πιστοποίηση του χρήστη πρέπει να έχουν την ακόλουθη μορφή:

rest of the packet is method-specific

Στο πεδίο user name δίνεται το όνομα του χρήστη. Εάν είναι άκυρο ο server μπορεί να συνδεθεί αμέσως ή να στείλει μια λίστα με τους αποδεκτές μεθόδους πιστοποίησης ταυτότητας, αλλά πότε να μην δεχθεί κανέναν από αυτούς. Με αυτόν τον τρόπο αποφεύγει να δώσει πληροφορίες με το ποια ονόματα υπάρχουν και ποια όχι.

Το πεδίο service name καθορίζει την υπηρεσία που θα ξεκινήσει μετά από την πιστοποίηση. Εάν δεν είναι διαθέσιμη o server μπορεί να αποσυνδεθεί αμέσως ή οποιαδήποτε στιγμή αργότερα και η πιστοποίηση του χρήστη δεν πρέπει να γίνει δεκτή.

Το πεδίο method name περιέχει την μέθοδο που επιθυμεί να χρησιμοποιήσει ο χρήστης. Μπορεί να χρησιμοποιηθεί η τιμή "none", αλλά τότε η προσπάθεια θα απορριφθεί από τον server. Σκοπός της, κυρίως, είναι η αποστολή των υποστηριζόμενων μεθόδων στον client.

Ακολουθούν δεδομένα που σχετίζονται με την μέθοδο πιστοποίησης που ζητήθηκε από τον χρήστη και αποτελούν την προσπάθεια του να αποδείξει την ταυτότητα του.

Απάντηση σε Αιτήσεις Πιστοποίησης Ταυτότητας

Εάν ο server απορρίψει την αίτηση, πρέπει να απαντήσει με το ακόλουθου μήνυμα:

boolean partial success

Το πεδίο partial success θα είναι "ΑΛΗΘΕΙΑ" όταν η προηγούμενη προσπάθεια ήταν επιτυχής, αλλά απαιτούνται και επιπλέον πιστοποιήσεις. Θα είναι "ΛΑΘΟΣ" όταν η αρχική προσπάθεια ήταν αποτυχημένη.

Όταν ο server δεχθεί την πρώτη προσπάθεια, τότε απαντά με:

byte SSH_MSG_USERAUTH_SUCCESS

Ο client μπορεί να στείλει πολλές αιτήσεις χωρίς να περιμένει για απάντηση από τον server. Ο server πρέπει να είναι σε θέση να αναγνωρίζει τις αποτυχημένες αιτήσεις και να στέλνει μηνύματα αποτυχίας, ενώ όταν δεχθεί μήνυμα που να μπορεί να επαληθεύσει την ταυτότητα του χρήστη να αποκρίνεται με μήνυμα επιτυχίας. Το τελευταίο μπορεί να στέλνεται μόνο μια φορά. Όταν ο server στείλει αυτό το μήνυμα, η διαδικασία έχει ολοκληρωθεί και ξεκινά την ζητούμενη υπηρεσία.

Μέθοδοι Πιστοποίησης

Είναι η μόνη απαιτούμενη μέθοδος και όλες οι εφαρμογές πρέπει να την υποστηρίζουν. Σε αυτήν, η κατοχή μίας ιδιωτικής κλείδας χρησιμεύει σαν αποδεικτικό στοιχείο της ταυτότητας του χρήστη, σε συνδυασμό με τη σχετιζόμενη δημόσια κλείδα. Λειτουργεί με την αποστολή από τον client, της υπογραφής του χρήστη που έχει δημιουργηθεί με χρήση της ιδιωτικής του κλείδας. Οι ιδιωτικές κλείδες συχνά αποθηκεύονται κρυπτογραφημένες στον client και ο χρήστης πρέπει να δώσει μία φράση – κλειδί για να αποκτήσει πρόσβαση σε αυτήν. Επειδή η διαδικασία της υπογραφής περιλαμβάνει χρονοβόρους υπολογισμούς, χρησιμοποιείται το παρακάτω μήνυμα για να ερευνηθεί εάν είναι αποδεκτή η πιστοποίηση με την συγκεκριμένη κλείδα, ώστε να αποτραπεί άχρηστη και ασύμφορη επεξεργασία.

string public key blob (=certificates)

Οι αλγόριθμοι ασύμμετρων κλειδιών αποφασίσθηκαν στο Transport Layer Protocol. Ανταποκρίνονταν, όμως, στα ασύμμετρα κλειδιά που χρησιμοποιήθηκαν κατά την πιστοποίηση της ταυτότητας του server. Οπότε, είναι δυνατόν κάποιοι από αυτούς να μην ισχύουν για αυτήν την περίπτωση πιστοποίησης. Εάν συμβαίνει κάτι τέτοιο, ο server απαντά με ένα από τα δύο μηνύματα:

SSH_MSG_USERAUTH_FAILURE ή με

string public key blob from the request

Για να πραγματοποιήσει ουσιαστική πιστοποίηση, ο client στέλνει μία υπογραφή του χρήστη που έχει δημιουργηθεί με την ιδιωτική του κλείδα. Ο client μπορεί να στείλει το παρακάτω μήνυμα χωρίς πρώτα να επαληθεύσει κατά πόσο η κλείδα είναι αποδεκτή.

string signature

Η υπογραφή γίνεται πάνω στα έξης δεδομένα: (α) το session identifier και (β) στο πεδίο payload του πακέτου. Όταν o server παραλάβει το μήνυμα, πρέπει πρώτα να ελέγξει εάν το είναι αποδεκτή η δημόσια κλείδα και έπειτα να ελέγξει εάν είναι σωστή η υπογραφή. Δεδομένου ότι και οι δύο έλεγχοι επιτύχουν, η μέθοδος έχει θετικό αποτέλεσμα και μήνυμα επιτυχίας αποστέλλεται στον client. Υπάρχει περίπτωση, όμως, ο server να απαιτεί και επιπλέον πιστοποιήσεις. Η τελική απάντηση, λοιπόν, του server πρέπει να είναι είτε SSH_MSG_USERAUTH_SUCCESS (όταν δεν χρειάζεται περαιτέρω πιστοποίηση και η υπογραφή ήταν έγκυρη) είτε SSH_MSG_USERAUTH_FAI-

LURE (όταν περισσότερες πιστοποιήσεις χρειάζονται ή η αίτηση απέτυχε).

Όλες οι SSH εφαρμογές θα πρέπει να υποστηρίζουν αυτή την μέθοδο. Τα παρακάτω πακέτα χρησιμοποιούνται:

string plaintext password (ISO-10646 UTF-8)

Παρ' όλο που ο κωδικό μεταδίδεται μη κρυπτογραφημένος μέσα στο πακέτο, ολόκληρο το πακέτο κρυπτογραφείται από το Transport Layer Protocol. Κανονικά, θα πρέπει να ελεγχθεί κατά πόσο είναι ενεργοποιημένος κάποιος αλγόριθμος κρυπτογράφησης. Εάν δεν εξασφαλίζεται η εμπιστευτικότητα της επικοινωνίας, τότε αυτή η μέθοδος θα πρέπει να πάψει να θεωρείται διαθέσιμη.

Ο server μπορεί να ζητήσει από τον χρήστη να αλλάξει κωδικό με το παρακάτω μήνυμα:

byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ

string language tag (as defined in RFC 1766)

Ο client, μετά από υπόδειξη του χρήστη, μπορεί να ανταποκριθεί με τον καινούργιο κωδικό. Ο χρήστης μπορεί να αλλάξει τον κωδικό του χωρίς να του ζητηθεί από τον server.

string plaintext new password (ISO-10646 UTF-8)

Μερικά sites επιθυμούν να επιτρέψουν πιστοποίηση του χρήστη, βασιζόμενη στην μηχανή-client που βρίσκεται αυτός σε συνδυασμό με το όνομα του. Παρ' όλο που δεν συνιστάται δίκτυα υψηλής ασφάλειας, μπορεί να είναι πολύ βολική για μερικά περιβάλλοντα. Είναι προαιρετική η υποστήριξη της μεθόδου και πρέπει να τηρείται προσοχή ώστε ο χρήστης να μην έχει την δυνατότητα να αποκτήσει την δημόσια κλείδα του client.

Η μέθοδος λειτουργεί με την αποστολή υπογραφής που έχει δημιουργηθεί με την ιδιωτική κλείδα του client, την οποία ελέγχει ο server με την δημόσια κλείδα του client. Το μήνυμα έχει ως εξής:

string signature

Οι αλγόριθμοι έχουν διαπραγματευτεί στο Transport Layer Protocol. Η υπογραφή προκύπτει από το session identifier και τα περιεχόμενα του payload του πακέτου. Ο server πρέπει να επιβεβαιώσει η δημόσια κλείδα ανήκει όντως στον client, ότι ο χρήστης επιτρέπεται να συνδεθεί και ότι η υπογραφή είναι έγκυρη.

Το Connection Protocol έχει σχεδιαστεί για να τρέχει πάνω από το SSH Transport Layer Protocol και το User Authentication Protocol. Παρέχει interactive login session, απομακρυσμένη εκτέλεση εντολών, προώθηση TCP/IP και Χ11 συνδέσεων. Οι υπηρεσίες του έπονται των υπηρεσιών του User Authentication Protocol και αναγνωρίζονται από το όνομα "ssh-connection".

Ο Μηχανισμός των Καναλιών

Όλες τερματικές sessions, οι προωθημένες TCP/IP και Χ11 συνδέσεις, η απομακρυσμένη εκτέλεση εντολών κ.α. αποτελούν κανάλια. Οποιαδήποτε πλευρά μπορεί να ανοίξει ένα κανάλι και πολλαπλά λογικά κανάλια πολυπλέκονται σε ένα φυσικό.

Τα κανάλια είναι ελεγχόμενης ροής δεδομένων (flow-controlled), που σημαίνει ότι δεν αποστέλλονται δεδομένα έως ότου παραληφθεί μήνυμα που να δηλώνει ότι υπάρχει ελεύθερος χώρος στο παράθυρο.

Όταν επιθυμείται η δημιουργία καναλιού και αφού το καινούργιο κανάλι έχει αντιστοιχηθεί με κατάλληλο αριθμό αναγνώρισης, στέλνεται το ακόλουθο μήνυμα στο άλλο άκρο:

Το πεδίο channel type περιγράφει τον τύπο του καναλιού που επιθυμεί ο αποστολέας να δημιουργήσει. Στο πεδίο sender channel περιέχεται ο αριθμός που έχει αντιστοιχήσει ο αποστολέας στο κανάλι. Στο initial window size καθορίζεται πόσα bytes Δεδομένων μπορούν να σταλούν μέσα από το κανάλι αρχικά, χωρίς να χρειάζεται να ξαναρυθμιστεί το μέγεθος του. Τέλος, το maximum packet size καθορίζει τον μέγιστο μέγεθος κάθε πακέτου που δέχεται ο αποστολέας της αίτησης.

Το απομακρυσμένο σύστημα αποφασίζει κατά πόσο μπορεί να ανοίξει το κανάλι και ανταποκρίνεται είτε με

... channel type specific data follows

όπου recipient channel είναι ο αριθμός καναλιού του συστήματος που ξεκίνησε την διαδικασία και sender channel είναι ο αριθμός του αποστολέα του παρών μηνύματος, είτε με

Εάν ο αποδέκτης του αρχικού SSH_MSG_CHANNEL_OPEN μηνύματος δεν υποστηρίζει το ζητούμενο κανάλι, τότε απλά απαντά με το SSH_MSG_CHANNEL_O- PEN_FAILURE. Στο πεδίο reason code περιέχεται ακέραιος που υποδηλώνει την αιτία που δεν μπορούσε να δημιουργηθεί το κανάλι. Στο παρακάτω πίνακα βλέπουμε τους κωδικούς με την σημασία τους.

Το μέγεθος του παραθύρου (window size) καθορίζει πόσα bytes μπορεί να στείλει η άλλη οντότητα χωρίς να χρειάζεται η εκ νέού ρύθμιση του μεγέθους του. Το ακόλουθο μήνυμα χρησιμοποιείται για την ρύθμιση του παραθύρου.

uint32 bytes to add

Με αυτό το μήνυμα το μέγεθος του παραθύρου αυξάνεται σύμφωνα με το ποσό που ορίζεται στο πεδίο bytes to add. Η μεταφορά δεδομένων γίνεται με μηνύματα του τύπου:

string data

Το μέγιστο πόσο δεδομένων που επιτρέπεται να σταλεί είναι ίσο με το μέγεθος του παραθύρου, το οποίο μειώνεται με κάθε αποστολή. Και οι δύο πλευρές μπορούν να αγνοήσουν τα δεδομένα που στέλνονται όταν το παράθυρο έχει γεμίσει.

Κλείσιμο Καναλιών

Όταν κάποιος από τους συνδιαλλέγοντες δεν θα στείλει άλλα δεδομένα στο κανάλι, θα πρέπει να στείλει το εξής μήνυμα:

uint32 recipient_channel

Όταν οποιοσδήποτε από τους δύο επιθυμεί να τερματίσει το κανάλι, στέλνει το μήνυμα

uint32 recipient_channel

το οποίο πρέπει να απαντηθεί με παρόμοιο μήνυμα από τον παραλήπτη του. Το κανάλι θεωρείται ότι έχει κλείσει για ένα άκρο όταν έχει στείλει και παραλάβει το μήνυμα αυτό και συνεπώς ο αριθμός του καναλιού μπορεί να ξαναχρησιμοποιηθεί. Η αποστολή του μηνύματος δεν προϋποθέτει την αποστολή του SSH_MSG_CHANNEL_ EOF. Ομοίως, το μήνυμα δεν καταλαμβάνει χώρο από το παράθυρο.

Αιτήσεις Σχετικές με Κανάλια

Για πολλούς τύπους καναλιών, υπάρχουν αιτήσεις εξυπηρέτησης που είναι συγκεκριμένες για κάθε κανάλι. Αυτές οι αιτήσεις αναφέρονται σε υπηρεσίες που μπορεί αν προσφέρει το κανάλι. Παράδειγμα είναι η αίτηση για ένα pseudo terminal για ένα κανάλι interactive session.

Όλες οι αιτήσεις έχουν την εξής μορφή:

... type-specific data

Εάν το πεδίο want reply είναι "FALSE", τότε δεν θα σταλεί απάντηση στην αίτηση. Διαφορετικά, η απάντηση θα είναι μία από τις παρακάτω:

uint32 recipient_channel

ή

uint32 recipient_channel

Εάν η αίτηση δεν αναγνωρίζεται ή δεν υποστηρίζεται για το κανάλι το SSH_MSG_CHANNEL_FAILURE επιστρέφεται. Όλα τα παραπάνω μηνύματα δεν καταναλώνουν τον διαθέσιμο χώρο του παραθύρου.

Στον παρακάτω πίνακα παρουσιάζονται όλοι οι κυριότεροι τύποι καναλιών και οι αντίστοιχες αιτήσεις.

Τα κανάλια X11 και AUTHENTICATION AGENT έπονται πάντα των αιτήσεων X11 FORWARDING και AUTHENTICATION AGENT REQUEST, διαφορετικά δεν γίνονται δεκτά. Ομοίως και το κανάλι TCP/IP FORWARDING το οποίο ακολουθεί πάντα μία αίτηση PORT FORWARDING.

5.7.7 Παρεχόμενη Προστασία

• IP spoofing (όταν μια μηχανή προσποιείται ότι είναι κάποια άλλη, που μπορεί να εμπιστευτεί).
• IP source routing (όταν μία μηχανή μπορεί να προσποιηθεί ότι ένα πακέτο προέρχεται από μηχανή)
• DNS spoofing (όταν κάποιος απατεώνας πλαστογραφεί τα αρχεία ενός DNS sever).
• Απόκτηση μυστικών κωδικών και άλλων ευαίσθητων πληροφοριών από ενδιάμεσα συστήματα.
• Τροποποίηση δεδομένων από ανθρώπους που χειρίζονται ενδιάμεσα συστήματα.
• Επιθέσεις που βασίζονται στην παράνομη καταγραφή Χ11 δεδομένων που κατευθύνονται σε Χ11 server.

Όλα αυτά ισχύουν όμως με την προϋπόθεση ότι δεν είναι δυνατή η απόκτηση root access με άλλα μέσα. Σε αυτήν την περίπτωση το SSH δεν μπορεί να βοηθήσει σε τίποτα.

Όσο αναφορά το SSH Transport Layer Protocol, είναι αναμενόμενο ότι μερικές φορές θα χρησιμοποιείται χωρίς αξιόπιστη συσχέτιση μεταξύ των δημοσίων κλείδων των μηχανών και της ταυτότητας των μηχανών. Τέτοια χρήση του πρωτοκόλλου είναι ανασφαλής, άλλα μπορεί να παρέχει ικανοποιητική ασφάλεια σε κάποια συστήματα.

Όταν το SSH Transport Layer Protocol δεν υποστηρίζει την κρυπτογράφηση των πακέτων, τότε οι μέθοδοι πιστοποιήσεις ταυτότητας του SSH User Authentication Protocol βασίζονται στην ανταλλαγή μυστικών δεδομένων, θα πρέπει να απαγορεύονται.

Τέλος, παρά την ασφάλεια που προστίθεται στις Χ11 συνδέσεις και στην προώθηση των TCP/IP πορτών, είναι προτιμότερο οι εφαρμογές του SSH να αποφεύγουν την υποστήριξη τους, καθ' ότι τα firewalls δεν μπορούν να εξετάσουν την κυκλοφορία λόγω του κρυπτογραφημένου καναλιού.

5.7.9 Περαιτέρω Πληροφορίες

Στις ακόλουθες ηλεκτρονικές σελίδες διατίθονται πιο αναλυτικές πληροφορίες για το SSH πρωτόκολλο:

SSH - Welcome - SSH 2.0 Protocol Specifications -- http://www.ssh.fi/drafts/

SSH - Products - SSH Protocol --

http://www.ssh.fi/sshprotocols2/standardization.html

SSH – Welcome -- http://www.ssh.fi/

5.8.1 Γενικά

Το DNS (Domain Name System) ενώ αποτελεί ουσιαστικό συστατικό στοιχείο της υποδομής του Internet στερείται μηχανισμών δυνατής ασφάλειας για την προστασία της ακεραιότητας και της ταυτότητας των δεδομένων. Για την παροχή αυτών των μηχανισμών ασφάλειας έχουν αναπτυχθεί οι λεγόμενες "DNS extensions" (επεκτάσεις του DNS), τις οποίες αντιλαμβάνονται ρυθμισμένοι για ασφάλεια servers και εφαρμογές που κάνουν χρήση κρυπτογραφημένων ψηφιακών υπογραφών. Αυτές οι ψηφιακές υπογραφές περιλαμβάνονται σε ασφαλείς ζώνες σαν RRs (Resource Records). Μπορούμε, ωστόσο, να εξασφαλίσουμε ασφάλεια και μέσω μη ρυθμισμένων, για κάτι τέτοιο, DNS servers σε πολλές περιπτώσεις.

Οι επεκτάσεις του DNS παρέχουν επιπλέον τη δυνατότητα αποθήκευσης πιστοποιημένων δημοσίων κλειδιών στο DNS. Αυτή η αποθήκευση των δημοσίων κλειδιών μπορεί να υποστηρίξει την γενικευμένη διαδικασία διανομής τους επιπρόσθετα της ασφάλειας του DNS. Τα αποθηκευμένα κλειδιά δίνουν τη δυνατότητα στους resolvers εκείνους, που έχουν ενσωματώσει χαρακτηριστικά ασφάλειας, να μαθαίνουν το κλειδί πιστοποίησης διαφόρων ζωνών εκτός εκείνων για τις οποίες έχουν ρυθμιστεί αρχικά. Κλειδιά τα οποία έχουν συσχετισθεί με DNS ονόματα μπορούν να ανακληθούν για να υποστηρίξουν άλλα πρωτόκολλα. Πρέπει να σημειωθεί ότι έχει γίνει πρόβλεψη για μια σειρά διαφορετικών τύπων κλειδιών και αλγορίθμων.

Οι επεκτάσεις του DNS δίνουν, επίσης, τη δυνατότητα της προαιρετικής πιστοποίησης των συναλλαγών του DNS πρωτοκόλλου.

5.8.2 Περιγραφή των Επεκτάσεων

Οι επεκτάσεις του DNS παρέχουν τρεις ξεχωριστές υπηρεσίες:

1. Διανομή κλειδιών
2. Πιστοποίηση προέλευσης δεδομένων
3. Πιστοποίηση αιτήσεων και συναλλαγών

Υπάρχουν, ωστόσο και υπηρεσίες που δεν παρέχουν οι επεκτάσεις του DNS. Η σχεδιαστική φιλοσοφία του DNS είναι τέτοια που προβλέπει την παροχή των ίδιων απαντήσεων σε όλες τις αιτήσεις χωρίς τη διάκριση καμιάς από αυτές. Έτσι δεν έγινε καμιά προσπάθεια για να συμπεριληφθούν λίστες πρόσβασης (access lists) ή οποιαδήποτε άλλα μέσα διάκρισης των διαφόρων αιτήσεων.

Διανομή Κλειδιών

Τα RRs ορίζονται ως αυτά που συσχετίζουν τα κλειδιά με τα DNS ονόματα. Αυτό επιτρέπει στο DNS να χρησιμοποιηθεί σαν ένας μηχανισμός διανομής δημοσίων κλειδιών σε υποστήριξη των μηχανισμών πιστοποίησης της προέλευσης των δεδομένων και άλλων υπηρεσιών ασφάλειας.

Το "Key Resource Record" περιλαμβάνει μία ταυτότητα του αλγορίθμου που χρησιμοποιείται, τις παραμέτρους του δημοσίου κλειδιού και μια πλειάδα άλλων χαρακτηριστικών παραμέτρων του τύπου της οντότητας με την οποία το κλειδί σχετίζεται.

Υπό καθορισμένες συνθήκες οι διάφοροι servers που έχουν ρυθμιστεί με γνώμονα την ασφάλεια του DNS, επιχειρούν να επιστρέψουν πληροφορίες κλειδιών σαν πρόσθετη πληροφορία μαζί με τα RRs που ζητήθηκαν έτσι ώστε να ελαττώσουν τον αριθμό των απαιτούμενων αιτήσεων.

Πιστοποίηση Προέλευσης Δεδομένων και Ακεραιότητά τους

Η πιστοποίηση παρέχεται με την συσχέτιση κρυπτογραφικά δημιουργημένων ψηφιακών υπογραφών με τα RRs. Υπάρχει ένα και μόνο μυστικό κλειδί που χαρακτηρίζει—υπογράφει μια ολόκληρη ζώνη. Εάν κάποιος resolver γνωρίζει το δημόσιο κλειδί κάποιας ζώνης μπορεί να πιστοποιήσει τα υπογεγραμμένα δεδομένα από αυτή τη ζώνη όσον αφορά την εγκυρότητα της υπογραφής τους και την επικαιρότητά τους. Το μυστικό κλειδί κάθε ζώνης κρατείται φυσικά εκτός δημοσίας θέας και χρησιμοποιείται μόνο περιοδικά για να υπογράψει τα RRs της ζώνης του.

Αυτό το κλειδί προέλευσης δεδομένων ανήκει στη ζώνη και όχι στους servers που αποθηκεύουν αντίγραφα των δεδομένων. Αυτό σημαίνει ότι κάθε πιθανό τρύπημα του ή των servers μιας ζώνης δεν επηρεάζει το βαθμό διασφάλισης που παρέχει ένας server όσον αφορά την προέλευση των δεδομένων.

Ένας resolver μπορεί να "μάθει" το δημόσιο κλειδί μιας ζώνης είτε διαβάζοντας το από το DNS είτε έχοντάς το στατικά ρυθμισμένο από την αρχή. Για να μπορεί κάποιος resolver να διαβάσει αξιόπιστα το δημόσιο κλειδί μιας ζώνης από το DNS θα πρέπει αυτό να είναι υπογεγραμμένο. Για αυτό το λόγο ο resolver θα πρέπει αρχικά να είναι ρυθμισμένος ώστε να γνωρίζει τουλάχιστον το δημόσιο κλειδί μιας ζώνης το οποίο θα χρησιμοποιεί για να πιστοποιεί υπογραφές. Από αυτό το σημείο και μετά μπορεί με ασφάλεια να διαβάζει το δημόσιο κλειδί άλλων ζωνών εάν οι ενδιάμεσες ζώνες στο DNS δέντρο είναι ασφαλείς και τα υπογεγραμμένα κλειδιά τους προσβάσιμα. Σε επίπεδο αρχής είναι πιο ασφαλές να γίνεται από την αρχή γνωστό στον server ένα πλήθος δημοσίων κλειδιών από διαφορετικές ζώνες διότι έτσι η πιθανή πτώση στα χέρια τρίτων μιας ζώνης δεν θα έχει συνέπειες για τις άλλες από ενέργειες αλλοίωσης των δεδομένων.

Για την πρόσθεση του χαρακτηριστικού πιστοποίησης της προέλευσης δεν είναι αναγκαία κανενός είδους τροποποίηση του DNS πρωτοκόλλου πέρα από την προσθήκη του τύπου υπογραφής και κλειδιών RR που χρειάζονται για τη διανομή των κλειδιών. Αυτή η υπηρεσία μπορεί να υποστηριχθεί από την υπάρχουσα δομή των resolvers και των servers αρκεί αυτοί να μπορούν να υποστηρίξουν τους επιπλέον RR τύπους.

Εάν οι υπογραφές λαμβάνονται και πιστοποιούνται ξεχωριστά κάθε φορά τότε θα υπάρχουν περισσότερα "ταξίδια" προς τον server και η απόδοση θα πέφτει. Για την αποφυγή αυτής της κατάστασης οι servers στέλνουν όποτε μπορούν τις υπογραφές που ίσως να χρειαστούν αργότερα.

To SIG Resource Record

To SIG Resource Record περιέχει τον τύπο του RR που υπογράφει, το όνομα του υπογράφοντος, το χρόνο της δημιουργίας της υπογραφής, την ημερομηνία λήξης της, τον κρυπτογραφικό αλγόριθμο που χρησιμοποιήθηκε και τέλος το υλικό της υπογραφής.

Κάθε όνομα σε μια ασφαλή ζώνη σχετίζεται με ένα SIG RR για κάθε τύπο καταχώρησης εκτός από τα glue και NS RRs. Ένας server που αντιλαμβάνεται από ασφάλεια θα επιχειρήσει πάντοτε να επιστρέψει τις υπογραφές των RRs που είναι υπό ερώτηση ενώ σε αντίθετη περίπτωση ο resolver είναι αυτός που πρέπει να συλλέξει όλες τις υπογραφές (SIGs) και να πάρει, μετά από επιλογή, αυτές που αφορούν τα records για τα οποία ενδιαφέρεται ο resolver.

Τα SIG RRs στην Σύνθεση Απαντήσεων

Οι DNS servers που έχουν ενσωματώσει στη λειτουργία τους χαρακτηριστικά ασφάλειας πρέπει να επιχειρούν να στέλνουν τα διαθέσιμα SIG RRs που πιστοποιούν τα ζητηθέντα RRs. Αυτά συμβαίνουν:

1. Όταν ένα RR δίδεται σε μια απάντηση τότε το SIG RR του έχει μεγαλύτερη προτεραιότητα για συμμετοχή στην απάντηση από κάθε άλλο RR που μπορεί να χρειάζεται να μπει. Εάν δεν υπάρχει διαθέσιμος χώρος τότε θεωρείται ότι η απάντηση έχει περικοπεί.
2. Οι υπογραφές που πιστοποιούν δεδομένα πάνω στα οποία δεν έχει αρμοδιότητα ο συγκεκριμένος server δεν χρειάζεται να σταλούν και δεν πρέπει να σταλούν.
3. Εάν η υπογραφή καλύπτει οποιοδήποτε RR το οποίο θα βρισκόταν στο απαντητικό μέρος της ανταπάντησης, τότε πρέπει να τοποθετείται αυτόματα στο μέρος της απάντησης. Εάν πάλι καλύπτει κάποιο RR το οποίο θα βρισκόταν στο μέρος αρμοδιότητας τότε πρέπει να τοποθετείται αυτόματα στο μέρος της αρμοδιότητας. Εάν τέλος, καλύπτει κάποιο RR το οποίο θα βρισκόταν στο μέρος επιπλέον πληροφορίας τότε πρέπει να τοποθετείται αυτόματα στο μέρος της επιπλέον πληροφορίας.
4. Προαιρετικά οι DNS συναλλαγές μπορούν να πιστοποιούνται από ένα SIG RR στο τέλος της απάντησης και συγκεκριμένα στον μέρος της επιπλέον πληροφορίας. Τέτοια SIG RRs υπογράφονται από τους DNS servers που δημιουργούν τις απαντήσεις.

Επεξεργασία Απαντήσεων και SIG RRs

Οι παρακάτω κανόνες εφαρμόζονται κατά την επεξεργασία των SIG RRs που περιλαμβάνονται σε μια απάντηση:

1. Ο resolver ο οποίος λαμβάνει μια απάντηση από αυτό που πιστεύει ότι είναι ένας ασφαλής server και με το AD bit (ένδειξη πιστοποιημένων δεδομένων από την πηγή τους) ενεργοποιημένο, μπορεί να επιλέξει να δεχθεί τα RRs όπως παρελήφθησαν και χωρίς τον έλεγχο των SIG RRs της ζώνης.
2. Σε άλλη περίπτωση ο resolver πρέπει να επαληθεύσει τα SIG RRs για τα RRs που τον ενδιαφέρουν. Αυτή η διαδικασία μπορεί να περιλαμβάνει την απαρχή ενός νέου κύκλου αιτήσεων για SIG και KEY RRs, εδικά στην περίπτωση που έχει λάβει απάντηση από κάποιον server χωρίς ενεργοποιημένα χαρακτηριστικά ασφάλειας.
3. Εάν τα SIG RRs έχουν ληφθεί σε απάντηση μιας ερώτησης από κάποιον χρήστη καθορίζοντας αποκλειστικά το SIG τύπο, δεν χρειάζεται καμιά επιπλέον επεξεργασία.

Πιστοποίηση Αιτήσεων και Συναλλαγών

Η υπηρεσία πιστοποίησης της προέλευσης των δεδομένων προστατεύει μεν τα RRs που διακινούνται ανάμεσα στους DNS servers και resolvers αλλά δεν παρέχει καμία προστασία στις DNS αιτήσεις και επικεφαλίδες μηνυμάτων - δηλαδή στις συναλλαγές.

Εάν τα bits κάποιας επικεφαλίδας είναι τοποθετημένα με λανθασμένο τρόπο από τον server, δεν υπάρχουν και πολλά που μπορούν να γίνουν. Ωστόσο είναι δυνατόν να προσθέσουμε το χαρακτηριστικό πιστοποίησης των συναλλαγών. Μια τέτοια πιστοποίηση θα σήμαινε ότι ο resolver θα είναι σίγουρος ότι λαμβάνει μηνύματα από τον server τον οποίο ρώτησε, για το ότι η απάντηση είναι αποτέλεσμα της ερώτησης που υπέβαλλε και για το ότι αυτά τα μηνύματα δεν αλλοιώθηκαν κατά τη μεταφορά τους. Όλα αυτά επιτυγχάνονται με την προσθήκη ενός προαιρετικού SIG Resource Record στο τέλος της απάντησης το οποίο υπογράφει ψηφιακά τη συσχέτιση της απάντησης του server και της αίτησης - ερώτησης του resolver.

Οι αιτήσεις μπορούν επίσης να πιστοποιηθούν με τη προσθήκη ενός ειδικού SIG Resource Record στο τέλος της ερώτησης. Προς το παρόν βέβαια αυτή η δυνατότητα δεν αποτελεί αντικείμενο εκμετάλλευσης από τους υπάρχοντες DNS servers. Ωστόσο αυτό το συντακτικό της υπογραφής των αιτήσεων ορίζεται σε σχέση με την πιστοποίηση μελλοντικών δυναμικών ανανεώσεων και παρόμοιων διαδικασιών.

Τα μυστικά ιδιωτικά κλειδιά που χρησιμοποιούνται για την ασφάλιση των συναλλαγών και των αιτήσεων ανήκουν στον υπολογιστή εκείνο που συνθέτει την ερώτηση ή την απάντηση και όχι στη ζώνη του. Το αντίστοιχο δημόσιο κλειδί συνήθως αποθηκεύεται στο DNS και ανακτάται από αυτό.

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

5.8.3 Το KEY Resource Record

Το KEY Resource Record χρησιμοποιείται για την αρχειοθέτηση ενός κλειδιού που σχετίζεται με κάποιο όνομα του Domain Name System (DNS). Είναι δημόσιο κλειδί μια και μόνο αυτά αποθηκεύονται στο DNS. Μπορεί να είναι το δημόσιο κλειδί μιας ζώνης, ενός υπολογιστή του δικτύου ή ενός χρήστη. Το KEY RR είναι όπως κάθε άλλο RR αντικείμενο πιστοποίησης από το SIG RR. Οι ασφαλείς εφαρμογές του DNS πρέπει να είναι σχεδιασμένες έτσι ώστε να μπορούν να διαχειρίζονται δύο τουλάχιστον έγκυρα κλειδιά, του ίδιου τύπου που σχετίζονται με κάποιο όνομα, ταυτόχρονα. Το νούμερο του KEY RR τύπου είναι το 25.

Τα KEY RRs στην Σύνθεση Απαντήσεων

Μία αποκλειστική αίτηση για KEY RRs δεν προκαλεί καμιά επιπλέον επεξεργασία πληροφορίας εκτός, φυσικά, από το αντίστοιχο SIG RR που δίδεται από τον server που είναι υπεύθυνος να απαντήσει.

Οι servers που λειτουργούν ενσωματώνοντας κάποιο σχήμα ασφάλειας είναι υποχρεωμένοι να περιλαμβάνουν στις απαντήσεις τους τα KEY RRs σαν επιπλέον πληροφορία σε διάφορες αιτήσεις συμπεριλαμβανομένων και των παρακάτω:

1. Κατά την ανάκτηση RRs του τύπου NS θα πρέπει να δίδονται και τα KEY RRs των ζωνών που εξυπηρετούνται από αυτούς τους Name Servers (NS) εάν υπάρχει διαθέσιμος χώρος.
2. Κατά την ανάκτηση RRs Α τύπου θα πρέπει να περιλαμβάνεται το KEY RR της τελικής οντότητας εάν υπάρχει διαθέσιμος χώρος.

Οι DNS servers που αντιλαμβάνονται από ασφάλεια δεν πρέπει να θεωρούν ληγμένες υπογραφές ικανές για να υπογράψουν οτιδήποτε, όπως επίσης δεν πρέπει να δέχονται την πιστοποίηση RRs από τέτοιες υπογραφές. Στα πλαίσια αυτού του περιορισμού οι servers πρέπει να ακολουθούν το σχήμα DNS TTL (Time To Live). Έτσι οι αρμόδιοι servers θα συνεχίσουν να ακολουθούν τις παραμέτρους ανανέωσης και λήξης της ζώνης ενώ κάποιος μη αρμόδιος server θα μετράει το TTL και θα αγνοεί τα RRs όταν το TTL θα είναι μηδέν. Επιπλέον, όποτε τα RRs μεταφέρονται σε απάντηση ερώτησης, τότε το TTL θα πρέπει να ισοσταθμίζεται έτσι ώστε ο παρών χρόνος συν αυτόν του TTL να μην υπερβαίνει το χρόνο λήξης της υπογραφής. Έτσι το TTL σε ένα μεταδιδόμενο RR θα είναι :

min(sigExpTim, max(zoneMinTTL, min(originalTTL, currentTTL)))

Ξεκινώντας με ένα ή περισσότερα κλειδιά τα οποία εμπιστευόμαστε για μια ζώνη, είναι δυνατό να αποκτήσουμε υπογεγραμμένα κλειδιά για όσες από τις υπο-ζώνες της αλλά και για τις υπερ-ζώνες της, εάν δεν είναι root. Κάθε αρμόδιος ασφαλής server κάποιας ζώνης θα πρέπει να περιέχει ένα KEY RR για τη υπερ-ζώνη υπογεγραμμένο από την ασφαλή ζώνη μέσω μιας οδηγίας που προέρχεται από κάποιο αρχείο-κλειδί. Με αυτό τον τρόπο γίνεται δυνατή η αναρρίχηση στις παραπάνω ζώνες στο δέντρο που αυτές έχουν σχηματίσει εάν κάποιος ξεκινά κάτω από root. Μια ασφαλής υπο-ζώνη ξεχωρίζει από ένα KEY RR με μη μηδενικές πληροφορίες κλειδιού στα NS RRs της υπο-ζώνης.

Ένας resolver πρέπει να κρατάει στοιχεία για τον αριθμό των ασφαλών ζωνών που συνάντησε από κάποιο αρχικό σημείο μέχρι οποιαδήποτε ασφαλή ζώνη που μπόρεσε να φτάσει. Γενικά, όσο μικρότερος είναι αυτός ο αριθμός τόσο μεγαλύτερη είναι η εμπιστοσύνη που έχουμε στα δεδομένα.

Ένας ασφαλής server θα πρέπει να αρνείται κατηγορηματικά να μεταβεί από μια ασφαλή ζώνη σε μια μη ασφαλή εκτός αν η μη ασφαλής ζώνη είναι πιστοποιημένη ως τέτοια ή ως πειραματική από την ύπαρξη ενός πιστοποιημένου κατάλληλου KEY RR που να καταδεικνύει αυτό το γεγονός. Εάν κάτι τέτοιο δεν συμβαίνει τότε ο resolver λαμβάνει ανακριβή δεδομένα και άρα όχι άξια εμπιστοσύνης.

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

Πρέπει να σημειωθεί ότι οι επεκτάσεις ασφάλειας του DNS δεν εγγυώνται τίποτα παραπάνω από την εγκυρότητα των RRs, συμπεριλαμβανομένων και των KEY RRs που έχουν ληφθεί από το DNS. Δεν λύνουν σε καμία περίπτωση άλλα προβλήματα ασφάλειας. Για παράδειγμα με τη χρήση των επεκτάσεων ασφάλειας στο DNS μπορεί κάποιος να είναι σίγουρος για την IP διεύθυνση που λαμβάνει για κάποιο όνομα ενός host. Ωστόσο, αυτό δεν είναι ικανό να σταματήσει κάποιον από το να αντικαταστήσει τον host αυτόν με κάποιον αναρμόδιο ή να αιχμαλωτίσει IP πακέτα που στέλνονται σε αυτήν τη διεύθυνση απαντώντας επιπλέον από κάποια άλλη. Άρα η προστασία που παρέχει το σχήμα των επεκτάσεων ασφάλειας του DNS δεν είναι καθολικό και δεν προσφέρει ολοκληρωτική λύση στο πρόβλημα ασφάλειας του Internet από μόνο του παρά μόνο αν συνδυαστεί και με άλλα συστήματα που εφαρμόζονται σε άλλα επίπεδα του Διαδικτύου.

5.8.6 Περαιτέρω Πληροφορίες

Στο RFC 2065 υπάρχουν όλες οι πληροφορίες πάνω στις οποίες στηρίχθηκε η παραπάνω μελέτη. Εκεί θα βρεθούν πιο τεχνικές και αναλυτικές πληροφορίες.

5.9.1 Εισαγωγή

Το WWW είναι ένα διανεμημένο σύστημα πολυμέσων το οποίο χαίρει μεγάλης αποδοχής από πολλούς χρήστες. Το βασικό και περισσότερο χρησιμοποιούμενο πρωτόκολλο μεταξύ WWW clients και WWW servers είναι το Hyper Text Transfer Protocol. Η ευκολία της χρήσης του WWW έχει προκαλέσει το παγκόσμιο ενδιαφέρον και χρησιμοποιείται σαν η υποδομή client / server για πολλές δικτυακές εφαρμογές. Τέτοιες εφαρμογές απαιτούν την αμοιβαία πιστοποίηση της ταυτότητας των δύο επικοινωνούντων υπολογιστών και την ικανότητα ανταλλαγής ευαίσθητων πληροφοριών. Οι τρέχοντες, όμως, HTTP εφαρμογές έχουν μέτρια έως και μηδαμινή υποστήριξη για τους κρυπτογραφικούς μηχανισμούς που είναι απαραίτητοι για τέτοιες συναλλαγές.

Το πρωτόκολλο Secure HTTP παρέχει ασφαλής μηχανισμούς επικοινωνίας μεταξύ ένα ζευγάρι HTTP server – client με σκοπό να επιτρέψει αυθόρμητες εμπορικές συναλλαγές. Στόχος της σχεδίασης ήταν ένα ευέλικτο πρωτόκολλο που διαθέτει πολλαπλούς μηχανισμούς και αλγόριθμους, και την δυνατότητα διαπραγμάτευσης αυτών. Σχεδιάστηκε από τους E. Rescorla και A. Schiffman του EIT και αποτελεί υπερσύνολο του HTTP.

5.9.2 Χαρακτηριστικά του S/HTTP

1. Το S/HTTP υποστηρίζει μία ποικιλία μηχανισμών ασφαλείας στους HTTP clients και servers. Το πρωτόκολλο παρέχει συμμετρικές δυνατότητες στον client και server που σημαίνει ότι τα μηνύματα και οι προτιμήσεις και των δύο πλευρών μεταχειρίζονται με τον ίδιο τρόπο, ενώ παράλληλα διατηρούνται το μοντέλο συναλλαγής και τα χαρακτηριστικά επικοινωνίας του HTTP.
2. Αρκετά κρυπτογραφικά στάνταρντς ενσωματώνονται στους S/HTTP clients και servers συμπεριλαμβανομένων των PEM, PGP, Kerberos και PKCS-7 (ο πρόγονος του CMS). Είναι συμβατό με το HTTP.
3. Το S/HTTP δεν απαιτεί πιστοποιητικά δημοσίων κλείδων από την μεριά του client, καθ' ότι υποστηρίζει και τα συμμετρικά κλειδιά. Αυτό είναι σημαντικό γιατί αυθόρμητες ιδιωτικές συναλλαγές μπορούν να λάβουν χώρα, χωρίς την απαίτηση από τους χρήστες να έχουν ένα έγκυρο ζεύγος δημόσιας – ιδιωτικής κλείδας. Βέβαια, είναι σε θέση να εκμεταλλευτεί την υπάρχουσα υποδομή πιστοποιητικών και ασύμμετρων κλειδιών.
4. Το S/HTTP υποστηρίζει απ' άκρη σ' άκρη ασφαλής συναλλαγές, σε αντίθεση με το HTTP που προϋποθέτει μία αποτυχημένη προσπάθεια πρόσβασης του χρήστη πριν την εφαρμογή οποιωνδήποτε μηχανισμών ασφαλείας. Με το S/HTTP, σε καμία περίπτωση ευαίσθητα δεδομένα θα μεταδοθούν στο δίκτυο απροστάτευτα.
5. Επιτρέπει πλήρη ευελιξία όσον αναφορά τους κρυπτογραφικούς αλγόριθμούς και τις παραμέτρους αυτών. Το είδος της παρεχόμενης προστασίας (κρυπτογράφηση, ψηφιακή υπογραφή, και τα δύο), οι αλγόριθμοι και τα πιστοποιητικά μπορούν να διαπραγματευτούν.
6. Οι χρήστες αναμένονται να έχουν (αν και δεν συνιστάται) πολλαπλά πιστοποιητικά.

Η προστασία ενός μηνύματος εφαρμόζεται με τρεις διαφορετικούς τρόπους: με υπογραφή, με κρυπτογράφηση και με παραγωγή MACs. Κάθε μήνυμα μπορεί να υπογραφεί, να κρυπτογραφηθεί ή οποιοσδήποτε συνδυασμός αυτών, συμπεριλαμβανομένων της παραγωγής και της παροχής καμίας προστασίας.

Υποστηρίζονται αρκετές τεχνικές διαχείρισης κλειδιών όπως συμμετρικά μυστικά κλειδιά, ασύμμετρη διαχείριση και το σύστημα Key Distribution Center (KDC) του Kerberos. Επιπλέον, ένας μηχανισμός challenge-response παρέχει στους επικοινωνούντες υπολογιστές την δυνατότητα να αναγνωρίζουν τις επιθέσεις επανάληψης (replay attacks).

Όταν υπογράφεται ψηφιακά, ένα κατάλληλο πιστοποιητικό μεταφέρεται με το μήνυμα ή ο αποστολέας μπορεί να αφήσει τον παραλήπτη να αποκτήσει το απαιτούμενο πιστοποιητικό από μόνος του.

Εκτός από την βασική κρυπτογράφηση, το S/HTTP καθορίζει δύο μηχανισμούς ανταλλαγής κλειδιών: (α) χρήση ασύμμετρης διαχείρισης κλειδιών και (β) χρήση ενός προκαθορισμένου κλειδιού.

Στην πρώτη περίπτωση, οι παράμετροι και το κλειδί του συμμετρικού κρυπτοσυστήματος κρυπτογραφούνται με την δημόσια κλείδα του παραλήπτη.

Στην δεύτερη περίπτωση, τα ίδια στοιχεία κρυπτογραφούνται με κλειδί που έχει προαποφασιστεί νωρίτερα. Τα κλειδιά αυτά μπορούν να προέλθουν και από τα tickets του Kerberos.

Το S/HTTP παρέχει επιπλέον μέσα για την επαλήθευση της ακεραιότητας των δεδομένων και την πιστοποίηση της ταυτότητας του αποστολέα. Χρησιμοποιεί το MAC του μηνύματος, το οποίο υπολογίζεται από hash αλγόριθμο σε συνδυασμό με ένα κοινό μυστικό κλειδί (π.χ. MD5). Αυτή η τεχνική δεν απαιτεί την χρήση ασύμμετρης διαχείρισης ούτε την χρήση κρυπτογράφησης.

Η δημιουργία ενός S/HTTP μηνύματος μπορεί να θεωρηθεί σαν μια συνάρτηση με τρεις εισόδους:

1. Το μήνυμα που πρόκειται να προστατευτεί. Μπορεί να είναι ένα HTTP μήνυμα ή κάποιο άλλο αντικείμενο. Το HTTP μήνυμα μπορεί να είναι οποιασδήποτε έκδοσης του HTTP πρωτοκόλλου.
2. Οι κρυπτογραφικές προτιμήσεις του παραλήπτη. Αυτές είτε έχουν καθοριστεί σε προηγούμενη επικοινωνία, είτε βασίζονται σε προρυθμίσεις.
3. Οι κρυπτογραφικές προτιμήσεις του αποστολέα.

Ο αποστολέας συνδυάζει τις προτιμήσεις και των δύο πλευρών και αποφαίνεται για τους αλγόριθμους και μηχανισμούς που θα χρησιμοποιηθούν καθώς και για την μορφή των κλειδιών. Ίσως χρειαστεί η επέμβαση του χρήστη σε περίπτωση πολλών επιλογών. Στο προστατευμένο HTTP μήνυμα, έπειτα, προστίθονται κατάλληλες S/HTTP επικεφαλίδες και παράγεται το τελικό S/HTTP μήνυμα.

Η επεξεργασία του παραληφθέντος S/HTTP μηνύματος, με την σειρά της, μπορεί να θεωρηθεί σαν συνάρτηση με τέσσερις διακριτές εισόδους:

1. Το S/HTTP μήνυμα.
2. Οι πρωτύτερα δηλωμένες κρυπτογραφικές προτιμήσεις του παραλήπτη.
3. Οι τρέχοντες κρυπτογραφικές προτιμήσεις του παραλήπτη.
4. Οι πρωτύτερα δηλωμένες κρυπτογραφικές προτιμήσεις του αποστολέα. Ο αποστολέας μπορεί να έχει δηλώσει το είδος των κρυπτογραφικών διαδικασιών που θα εφήρμοζε στο μήνυμα.

Για να μπορέσει να επεξεργαστεί το S/HTTP μήνυμα, ο παραλήπτης διαβάζει τις S/HTTP επικεφαλίδες για να ανακαλύψει τι κρυπτογραφικοί μετασχηματισμοί εφαρμόστηκαν στο μήνυμα και με την βοήθεια των προσυμφωνημένων κλειδιών τις αφαιρεί. Το αποτέλεσμα είναι το HTTP μήνυμα (ή κάποιο άλλο αντικείμενο).

Ο παραλήπτης μπορεί να επιλέξει να επαληθεύσει ότι οι εφαρμοσμένοι μηχανισμοί ταιριάζουν με αυτούς που είχε δηλώσει ο αποστολέας (είσοδος 4), με αυτούς που είχε ζητήσει ο παραλήπτης (είσοδος 2) καθώς και με τις τρέχοντες προτιμήσεις του τελευταίου (είσοδος 3), με σκοπό να αποφανθεί εάν το μήνυμα είχε μετασχηματιστεί κατάλληλα.

Ένα S/HTTP μήνυμα αποτελείται από μία γραμμή αίτησης (request line) ή απάντησης (status line), ακολουθούμενη από μια σειρά από επικεφαλίδες τύπου RFC822 και τα ασφαλισμένα ενθυλακωμένα περιεχόμενα. Τα ενθυλακωμένα περιεχόμενα μπορεί να είναι είτε ένα ακόμα S/HTTP μήνυμα, είτε ένα HTTP μήνυμα, είτε απλά δεδομένα.

Για τις HTTP αιτήσεις η γραμμή που ξεκινά το μήνυμα είναι:

Secure * Secure-HTTP/1.1

Status Line

Στις απαντήσεις του server η πρώτη γραμμή πρέπει να είναι:

Παρατηρούμε ότι δεν δηλώνεται κατά πόσο έγινε δεκτή ή όχι η αίτηση του client. Η ίδια γραμμή χρησιμοποιείται και στην περίπτωση αποτυχίας και στην περίπτωση επιτυχίας, γεγονός που αποτρέπει την επίγνωση της περίπτωσης.

Το πρωτόκολλο καθορίζει μία σειρά από νέες επικεφαλίδες που πηγαίνουν στο πεδίο των επικεφαλίδων του S/HTTP μηνύματος. Από αυτές, όλες εκτός των "Content-Type" και "Content-Privacy-Domain" είναι προαιρετικές. Τα κυρίως περιεχόμενα του μηνύματος διαχωρίζονται από τις επικεφαλίδες με δύο συνεχόμενες ακολουθίες των χαρακτήρων ελέγχου <CR><LF>.

Αυτή η επικεφαλίδα υπάρχει για να παρέχει συμβατότητα με τα S/HTTP εφαρμογές που βασίζονται στο PEM. Οι τιμές της είναι "PEM", "PKCS-7" και "PGP".

Όταν χρησιμοποιείται η επικεφαλίδα "Content-Privacy-Domain: PKCS-7", η προστασία του μηνύματος γίνεται με τους εξής τρόπους, βάσει του PKCS-7: με υπογραφή και με κρυπτογράφηση. Κάθε HTTP μήνυμα μπορεί να κρυπτογραφηθεί, να υπογραφεί ή και τα δύο. Το μήνυμα που υπογράφεται συνήθως συνοδεύεται από πιστοποιητικό ή από αλυσίδα πιστοποιητικών. Οι επικεφαλίδες "Content-Privacy-Domain: PGP" και "Content-Privacy-Domain: PEM" υποδηλώνουν εφαρμογή των κανόνων του PGP ή του PEM, αντίστοιχα.

Content-Transfer-Encoding

Εδώ καθορίζεται η κωδικοποίηση των περιεχομένων και οι τιμές που μπορεί να πάρει η επικεφαλίδα είναι "8-bit", "7-bit" και "BASE64". Η τιμή εξαρτάται από την επικεφαλίδας "Content-Privacy-Domain ".

Για την περίπτωση που είναι "Content-Privacy-Domain: PKCS-7", οι μόνες επιτρεπτές τιμές της "Content-Transfer-Encoding" είναι "BASE64" ή "8-bit".

Για την περίπτωση που είναι "Content-Privacy-Domain: PEM", η μόνη επιτρεπτή τιμή είναι η "7-bit".

Για την περίπτωση που είναι "Content-Privacy-Domain: PGP" , όλες οι παραπάνω τιμές επιτρέπονται ανάλογα με την μορφή του PGP μηνύματος.

Υπό κανονικές συνθήκες, τα ενθυλακωμένα περιεχόμενα μετά την αφαίρεση όλων κρυπτογραφικών μέτρων ασφαλείας, θα είναι ένα HTTP μήνυμα. Σε αυτήν την περίπτωση η επικεφαλίδα θα είναι:

Content-Type: application/http

Δεν αποκλείεται, όμως, τα ενθυλακωμένα περιεχόμενα να είναι κάποιου άλλου τύπου με την προϋπόθεση ότι αυτός ο τύπος δηλωθεί σωστά με την χρήση κατάλληλης επικεφαλίδας "Content-Type".

Η επικεφαλίδα αυτή έχει σαν σκοπό να συνοδεύσει πληροφορίες σχετικά με κλειδί που έχει προκανονιστεί με κάποιον τρόπο έκτος της εσωτερικής κρυπτογράφησης. Μία χρήση της επικεφαλίδας είναι η in-band επικοινωνία ενός session key στην περίπτωση που κάποια από τις δύο πλευρές δεν κατέχει ένα.

Ορίζονται τρεις μέθοδοι για την ανταλλαγή session keys: (α) Inband, (β) Kerberos και (γ) Outband. Οι δύο πρώτες μέθοδοι, Inband και Kerberos, υποδηλώνουν ότι το κλειδί έχει ανταλλαγεί πρωτύτερα, με χρήση μιας HTTP επικεφαλίδας "Key-Assign". Η Outband μέθοδος υπονοεί ότι ο client και ο server έχουν πρόσβαση σε κλειδιά που σχετίζονται με ονόματα χρηστών, είτε μέσω μιας βάσης δεδομένων, είτε από την εισαγωγή ενός κωδικού από τον χρήστη μέσω του πληκτρολόγιου.

Μεταφέρει ένα Message Authentication Code (MAC), παρέχοντας πιστοποίηση ταυτότητας και ακεραιότητας. Το MAC υπολογίζεται από τα ενθυλακωμένα περιεχόμενα, την ώρα (προαιρετικό – αποτρέπει τις επιθέσεις replay attacks) και κάποιού κοινού μυστικού που μοιράζονται ο client και ο server. Έστω ότι χρησιμοποιείται hash αλγόριθμος H, τότε η εξίσωση που περιγράφει την διαδικασία είναι (οι δύο κάθετες παύλες || σημαίνουν συνένωση):

MAC = hex(H(Message||<time>||<shared key>))

Και δύο πλευρές πρέπει να είναι σε θέση να εκφράσουν τις προτιμήσεις και τις απαιτήσεις τους σχετικά με ποίες κρυπτογραφικές ενισχύσεις επιτρέπουν ή απαιτούν. Το σύνολο των πληροφοριών που διαπραγματεύονται, χωρίζεται σε τέσσερα μέρη:

Η τιμή optional του τελευταίου πεδίου φανερώνει ότι οι αλγόριθμοι και το είδος της προστασίας που αναφέρονται στο Value και στο Property είναι προαιρετικές. Κατά την παραλαβή (reception) μηνύματος ασφαλισμένου με προαιρετικούς μηχανισμούς, ο παραλήπτης θα επιλέξει να το επεξεργαστεί αλλά δεν περιορίζεται στην επεξεργασία μόνο τέτοιων μηνυμάτων. Ο αποστολέας (origination) ο οποίος ορίζει κάποιες προτιμήσεις προαιρετικές, μπορεί να τις χρησιμοποιήσει όταν βρίσκονται σε συμφωνία με τις προτιμήσεις του παραλήπτη και δεν μπορεί όταν δεν είναι αποδεκτές.

Η τιμή required υποδηλώνει ότι ο παραλήπτης (reception) θα δέχεται S/HTTP μηνύματα μόνο με αυτές τις κρυπτογραφικές ενισχύσεις, ενώ ο αποστολέας (origination) θα χρησιμοποιεί μόνο αυτές ανεξάρτητα με τις προτιμήσεις του παραλήπτη.

Τέλος, η τιμή refused υποδηλώνει ότι ο παραλήπτης (reception) δεν θα δέχεται S/HTTP μηνύματα με τέτοιες κρυπτογραφικές ενισχύσεις, ενώ ο αποστολέας (origination) δεν θα παράγει ποτέ τέτοια μηνύματα.

Η τιμή του πεδίου Property συμπληρώνεται με κατάλληλες επικεφαλίδες που προσδιορίζουν ποια κρυπτογραφική ιδιότητα βρίσκεται υπό συζήτηση.

1. SHTTP-Privacy-Domains: Καθορίζει την διαδικασία που θα ασφαλίσει το HTTP μήνυμα (ή οποιουδήποτε άλλου τύπου δεδομένα). Οι δεκτές τιμές είναι "PEM", "PGP" και "PKCS-7". Οι υπόλοιπες επικεφαλίδες μπορούν είτε να αναφέρονται σε ένα από τα PEM", "PGP", "PKCS-7" οπότε ακολουθούν την SHTTP-Privacy-Domains, είτε να αναφέρονται και στις τρεις τιμές οπότε βρίσκονται πριν από την SHTTP-Privacy-Domains. Επιτρέπονται πολλαπλές τέτοιες επικεφαλίδες με σκοπό την υποστήριξη πολλαπλών συνδυασμό παραμέτρων.
2. SHTTP-Certificate-Types: Υποδηλώνει τον τύπο των πιστοποιητικών που θα γίνονται ή δεν θα γίνονται δεκτά (ανάλογα με το πεδίο Strength).
3. SHTTP-Key-Exchange-Algorithms: Υποδηλώνει τους αλγόριθμους που μπορεί να χρησιμοποιηθούν για την διαχείριση και ανταλλαγή κλειδιών.
4. SHTTP-Signature-Algorithms: Υποδηλώνει τους αλγόριθμους ψηφιακών υπογραφών που μπορεί να χρησιμοποιηθούν.
5. SHTTP-Message-Digest-Algorithms: Υποδηλώνει τους αλγόριθμους παραγωγής message digest.
6. SHTTP-Symmetric-Contents-Algorithms: Εδώ καθορίζονται οι αλγόριθμοι συμμετρικής κρυπτογράφησης του HTTP μηνύματος (ή οποιουδήποτε άλλου τύπου δεδομένα).
7. SHTTP-Symmetric-Header-Algorithms: Οι επικεφαλίδες ενός HTTP μηνύματος ασφαλίζονται ξεχωριστά από το υπόλοιπο μήνυμα. Οι αλγόριθμοι συμμετρικής κρυπτογράφησης που μπορεί να χρησιμοποιηθούν καθορίζονται με αυτήν την επικεφαλίδα.
8. SHTTP-Privacy-Enhancement: Υποδηλώνει εάν θα εφαρμοστεί κρυπτογράφηση ("encrypt"), ψηφιακή υπογραφή ("sign") ή MAC ("auth").

Ένα παράδειγμα που εξηγεί αυτά που συζητήσαμε παραπάνω είναι:

Όπως προείπαμε, υπάρχουν προκαθορισμένες τιμές για τους μηχανισμούς προστασίας. Αυτές είναι:

Το πρωτόκολλο S/HTTP καθορίζει μία συλλογή νέων επικεφαλίδων που τοποθετούνται στις επικεφαλίδες του HTTP μηνύματος. Με τον τρόπο αυτό οι νέες επικεφαλίδες μοιράζονται την κρυπτογραφική προστασία που παρέχεται στις υπάρχουσες. Οι νέες επικεφαλίδες παρουσιάζονται παρακάτω.

1. Security-Scheme: Είναι απαραίτητη επικεφαλίδα που καθορίζει την έκδοση του S/HTTP πρωτοκόλλου. Η τρέχουσα έκδοση είναι η 1.4.
2. Encryption-Identity: Προσδιορίζει την ταυτότητα μιας οντότητας για την οποία το μήνυμα θα μπορούσε να κρυπτογραφηθεί.
3. Certificate-Info: Περιέχει πληροφορίες για τα πιστοποιητικά της οντότητας που προσδιορίζεται στην "Encryption-Identity".
4. Key-Assign: Αυτή η επικεφαλίδα υποδηλώνει ότι το σύστημα επιθυμεί να συνδέσει ένα κλειδί με ένα συμβολικό όνομα, για μελλοντική του χρήση. Στην επικεφαλίδα περιέχεται το συμβολικό όνομα, το κλειδί, η μέθοδος σύμφωνα με την οποία θα αποκτηθεί το κλειδί (Ιnband και Kerberos), η διάρκεια ζωής του και τέλος τους αλγόριθμους με τους οποίους προορίζεται για χρήση το κλειδί. Στην περίπτωση Inband ανταλλαγής, το κλειδί μεταφέρεται σαν παράμετρος της επικεφαλίδας, ενώ στην περίπτωση Kerberos ανταλλαγής, το κλειδί μεταφέρεται στο εσωτερικό ενός ticket.
5. Nonce: Περιέχει τιμή που χρησιμοποιείται για το ταίριασμα αίτησης και απάντησης. Σκοπός της είναι η διατήρηση της επικαιρότητας της σύνδεσης (freshness) και η αποφυγή replay attacks.

Οι αλγόριθμοι που υποστηρίζει το S/HTTP χωρίζονται σε κατηγορίες, ανάλογα με είδος της παρεχόμενης προστασίας με την οποία χρησιμοποιούνται.

Αλγόριθμοι Διαχείριση Κλειδιών

Οι μηχανισμοί που καθορίζονται για την διαχείριση και ανταλλαγή κλειδιών (key management, key exchange) είναι οι RSA, Inband, Outband και Kerberos. Οι δύο ς μέθοδοι Inband και Kerberos, υποδηλώνουν ότι το κλειδί έχει ανταλλαγεί πρωτύτερα, με χρήση μιας HTTP επικεφαλίδας "Key-Assign". Η Outband μέθοδος υπονοεί ότι ο client και ο server έχουν πρόσβαση σε κλειδιά που σχετίζονται με ονόματα χρηστών, είτε μέσω μιας βάσης δεδομένων, είτε από την εισαγωγή ενός κωδικού από τον χρήστη μέσω του πληκτρολόγιου. Η RSA χρησιμοποιεί την ιδιωτική κλείδα του αποστολέα για την κρυπτογράφηση του κλειδιού κρυπτογράφησης των ενθυλακωμένων περιεχομένων που συνοδεύεται από πιστοποιητικό τύπου Χ.509 με την δημόσια κλείδα του αποστολέα.

Το S/HTTP υποστηρίζει δύο αλγόριθμους για την παραγωγή ψηφιακών υπογραφών: RSA και DSS. Για την παραγωγή message digest υποστηρίζονται οι MD2, MD5 και SHS.

Το S/HTTP, όπως και το SSL, παρέχει προστασία έναντι των επιθέσεων Man-In-The-Middle-Attack, Replay Attack και Dictionary Attack. Είναι πιο σταθερό, όμως από το SSL γιατί επιτρέπεται η επαναδιαπραγμάτευση των μηχανισμών και αλγορίθμων. Επιπλέον, οι αλγόριθμοι που υποστηρίζει το S/HTTP είναι πιο ανθεκτικοί σε επιθέσεις. Συγκεκριμένα, το κόστος ανάλυσης του DES (ο προρυθμισμένος αλγόριθμος του S/HTTP) είναι πολύ υψηλότερο από το αντίστοιχο κόστος του RC4 με 40 bit κλειδί (προρυθμισμένος αλγόριθμος του SSL).

5.9.11 Αδυναμίες του S/HTTP

Η χρήση της μεθόδου Inband για ανταλλαγή κλειδιών είναι προβληματική. Η μεταφορά των κλειδιών δεν γίνεται με αρκετή ασφάλεια και μπορούν εύκολα να πέσουν στα χέρια εισβολέων. Επίσης, άλλη μια αδυναμία του S/HTTP είναι η εξαιρετική του ευελιξία στην επιλογή μηχανισμών και αδυναμία κρυπτογράφησης όλων των ανταλλαγών μηνυμάτων. Σε αντίθεση το SSL εφαρμόζει την άποψη της κρυπτογράφησης των πάντων.

Μία σύντομη περιγραφή του S/HTTP υπάρχει στις σελίδες:

SHTTP links -- http://www3.tsl.uu.se/~micke/shttp_links.html

An Overview of SHTTP -- http://www.homeport.org/~adam/shttp.html

Πιο τεχνικές πληροφορίες για το S/HTTP είναι διαθέσιμες στις παρακάτω ηλεκτρονικές σελίδες:

SHTTP Draft -- http://search.ietf.org/internet-drafts/draft-ietf-wts-shttp-06.txt

SHTML Draft -- http://search.ietf.org/internet-drafts/draft-ietf-wts-shtml-05.txt

5.10.1 Γενικά

Τα υπολογιστικά συστήματα καθημερινά απειλούνται από χιλιάδες εισβολείς που ανακαλύπτουν συνεχώς νέες, πιο εκλεπτυσμένες μεθόδους επίθεσης. Ένα από τα πιο συνηθισμένα είδη επίθεσης είναι η παράνομη καταγραφή της κυκλοφορίας σε καίρια σημεία του δικτύου και εκμετάλλευση των αποκτηθέντων πληροφοριών για την εξαγωγή μυστικών κωδικών για νόμιμους χρήστες. Η Bellcore έχει αναπτύξει ένα πρότυπο λογισμικό, το S/KEY, που αποτελεί ένα σύστημα παραγωγής κωδικών μίας χρήσης, για αντιμετωπίσει αυτό το είδος επίθεσης.

Το σύστημα S/KEY έχει αρκετά πλεονεκτήματα σε σχέση με άλλα συστήματα πιστοποίησης ταυτότητας. Κατ' αρχήν, ο κωδικός του χρήστη δεν ταξιδεύει ποτέ στο δίκτυο κατά την διάρκεια του login ή όταν εκτελούνται εντολές όπως οι passwd και η su του UNIX. Μυστικές, ευαίσθητες πληροφορίες δεν αποθηκεύονται πουθενά, ούτε στον υπολογιστή που χρησιμοποιεί ο χρήστης και οι αλγόριθμοι που εφαρμόζονται είναι ευρέως γνωστοί.

Η Bellcore πειραματίζεται με το σύστημα S/KEY εδώ και δύο χρόνια, το οποίο είναι διαθέσιμο στο Internet με anonymous ftp.

Υπάρχει μια μεγάλη ποικιλία απειλών που μπορούμε να σκεφτούμε για ένα δίκτυο. Αυτές διαχωρίζονται σε εσωτερικές απειλές και σε εξωτερικές. Το S/KEY έχει αναπτυχθεί για καταπολεμήσει τις εξωτερικές απειλές, δηλαδή τις προσπάθειες για εισχώρηση σε ένα σύστημα υπολογιστών από πηγές εκτός των ορίων του συστήματος. Δεν ασχολείται με τα επιπρόσθετα μέτρα ασφαλείας που πρέπει να ληφθούν υπόψη για να εμποδιστούν νόμιμοι χρήστες να αποκτήσουν παραπάνω δικαιώματα από αυτά που δικαιούνται. Προστατεύει τους κωδικούς των χρηστών από τις passive attacks, επιθέσεις κατά τις οποίες ο πιθανός εισβολέας παρακολουθεί τις συναλλαγές νόμιμων χρηστών και συλλέγει κωδικούς και άλλες χρήσιμες πληροφορίες, που θα χρησιμοποιήσει αργότερα.

Το S/KEY μπορεί εύκολα και γρήγορα να προστεθεί σε σχεδόν όλα τα UNIX συστήματα, χωρίς να απαιτεί επιπλέον hardware και χωρίς να αποθηκεύει ευαίσθητες πληροφορίες. Μπορεί να χρησιμοποιηθεί σε "χαζά τερματικά" ("dumb terminals"), σε προσωπικούς υπολογιστές που έχουν εγκατεστημένα συμβατικά επικοινωνιακά προγράμματα, ή σε σταθμούς εργασίας (workstations). Είναι συμβατό με πιθανή εφαρμογή βασισμένη σε smart cards ή pocket calculators.