Βασικές Έννοιες

5.4 S/MIME (Secure ΜΙΜΕ)

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

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

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

Το ηλεκτρονικό ταχυδρομείο του 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. Εάν περιέχεται στις επικεφαλίδες ενός μηνύματος, τότε η τιμή της υποδεικνύει το είδος των περιεχομένων που υπάρχει στον κορμό (body) του μηνύματος. Διαχωρίζεται στις παρακάτω παραμέτρους:

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

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

Υπάρχουν δύο μηχανισμοί για την επέκταση των υπαρχόντων τύπων: (α) εάν κάποιο τοπικό περιβάλλον επιθυμεί να καθορίσει τους δικούς του τύπους, μπορεί να το κάνει παραθέτοντας μπροστά από τις παραμέτρους 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 είναι μια εναλλακτική έκδοση της ίδιας πληροφορίας και το πρόγραμμα ανάγνωσης μηνυμάτων πρέπει είτε να επιλέξει τον καταλληλότερο κρίνοντας από το περιβάλλον εργασίας του χρήστη, είτε να προσφέρει στον χρήστη τις διαθέσιμες εναλλακτικές παρουσιάσεις.

Παράδειγμα ενός 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: υποδηλώνει ότι το κείμενο είναι εμπλουτισμένο, δηλαδή ότι τροποποιήθηκε με κατάλληλη γλώσσα μορφοποίησης.

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.

Πολλούς από τους παραπάνω τύπους περιεχομένων στην φυσική τους μορφή παρουσιάζονται σαν χαρακτήρες 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.

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

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

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

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

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

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

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. : Εφαρμόζεται κατάλληλη κωδικοποίηση μεταφοράς (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

Βασικές Έννοιες