Εθνικό Μετσόβιο Πολυτεχνείο Σχολή Ηλεκτρολόγων Μηχανικών και Μηχανικών Υπολογιστών

Διατμηματικό Πρόγραμμα Μεταπτυχιακών Σπουδών στη Βιοϊατρική Τεχνολογία.

ΔΙΠΛΩΜΑΤΙΚΗ ΕΡΓΑΣΙΑ του Κέντρου Σωτήρη

Τίτλος Εργασίας Ανοιχτή πλατφόρμα για την ασφαλή ανταλλαγή πληροφορίας σε περιβάλλον κινητών επικοινωνιών.

Πάτρα, Σεπτέμβριος 2008

2

Περιεχόμενα Στόχος............................................................................................................................4 1. Τεχνολογίες Κινητής Τηλεφωνίας ..........................................................................4 1.1 Εισαγωγή ..........................................................................................................4 1.2 GPRS .................................................................................................................7 1.3 UMTS ..............................................................................................................28 2. Πρωτόκολλα Επικοινωνίας ...................................................................................36 2.1 WAP ................................................................................................................36 2.2 WAP 2.0 ..........................................................................................................57 3. Γλώσσες προγραμματισμού ..................................................................................69 3.1 Η ασύρματη γλώσσα σήμανσης (WML-Wireless Markup Language).....69 3.2 XHTML MP and WCSS ...............................................................................71 4. Βασικές Αρχές Κρυπτογραφίας ............................................................................77 4.1 Κρυπτογραφία ................................................................................................78 4.1.1 Συμμετρική Κρυπτογραφία ......................................................................79 4.1.2 Ασύμμετρη Κρυπτογραφία ή Κρυπτογραφία Δημοσίου Κλειδιού .......81 4.1.3 Υβριδική Κρυπτογραφία Ψηφιακού Φακέλου........................................84 4.2 Κρυπτογραφία Δημοσίου Κλειδιού ..............................................................85 4.3 Συναρτήσεις Κατακερματισμού (Hash Functions).....................................94 4.4 Υπηρεσίες .......................................................................................................96 5. Προτεινόμενο Σύστημα .......................................................................................100 5.1 Αρχιτεκτονική Συστήματος ........................................................................101 5.2 Αδυναμίες Ασφαλείας ..................................................................................103 5.3 Προστασία της ευαίσθητης πληροφορίας του χρήστη .............................104 5.4 Κρυπτογράφηση και αποκρυπτογράφηση.................................................105 5.4.1 Κρυπτογράφηση ασύμμετρου κλειδιού .................................................106 5.4.2 Κρυπτογράφηση συμμετρικού κλειδιού ................................................106 5.4.3 Σύγκριση κρυπτογράφησης ασύμμετρου και συμμετρικού κλειδιού .107 5.4.4 Ο αλγόριθμος κρυπτογράφησης AES ....................................................107 5.5 Διαχείριση κρυφού κλειδιού .......................................................................108 5.5.1 Αποθήκευση του κρυφού κλειδιού, προβλήματα και λύσεις ...............108 5.5.2 Επαναδημιουργία του ίδιου κλειδιού. ....................................................110 5.6 Κρυπτογράφηση βασισμένη σε μυστικό κωδικό (Password-Based Encryption)...............................................................................................................111 5.6.1 Δημιουργία του κλειδιού από το μυστικό κωδικό ................................112 5.6.2 Επίδραση στο σύστημά μας ....................................................................113 5.7 Περιγραφή τελικής λύσης ...........................................................................114 6. Εφαρμογή του συστήματος .................................................................................116 6.1 Τεχνολογίες Υλοποίησης .............................................................................116 6.1.1 J2EE (Java 2 Platform, Enterprise Edition) .........................................116 6.1.2 EJB (Enterprise JavaBeans) ...................................................................117 6.2 Αναλυτικός Σχεδιασμός...............................................................................120 6.2.1 Διαγράμματα Ροής του Προγράμματος .................................................121 6.2.2 Η βάση δεδομένων ...................................................................................123 6.2.3 Δομή κώδικα.............................................................................................126 6.2.4 Περιγραφή διαδικασίας εκτέλεσης συναλλαγής ...................................132 6.3 Δοκιμές του συστήματος .............................................................................134 6.3.1 Περιβάλλον δοκιμών................................................................................134 6.3.2 Αποτελέσματα των δοκιμών ...................................................................134

3

7. Βιβλιογραφία ........................................................................................................139 Παράρτημα – Κώδικας............................................................................................142

4

Στόχος

Στόχος της παρούσας διπλωματικής εργασίας είναι ο σχεδιασμός ενός

συστήματος ασφαλούς μεταφοράς δεδομένων από κινητές τερματικές

συσκευές όπως κινητά τηλέφωνα και PDAs (Personal Digital Assistants). Ένα

τέτοιο σύστημα θα μπορούσε να χρησιμοποιηθεί για τη μετάδοση ευαίσθητων

προσωπικών δεδομένων, όπως βιοϊατρικά δεδομένα που συλλέγονται από

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

κάνουμε μία σύνοψη των τελευταίων τεχνολογιών στην κινητή τηλεφωνία, τα

πρωτόκολλα επικοινωνίας για διαδικτύωση σε περιβάλλον κινητών

επικοινωνιών, καθώς και βασικών κρυπτογραφικών πρωτοκόλλων, ώστε να

οδηγηθούμε ομαλά στο σχεδιασμό του επιθυμητού συστήματος. Τέλος,

αναπτύξαμε και παρουσιάζουμε ένα σύστημα ηλεκτρονικών πληρωμών, που

φασίζεται στο σύστημα για την ασφαλή ανταλλαγή πληροφορίας σε

περιβάλλον κινητών επικοινωνιών, που σχεδιάστικε προηγουμένος,

υλοποιώντας έτσι μια εφαρμογή του προταθέντως συστήματος.

1. Τεχνολογίες Κινητής Τηλεφωνίας

1.1 Εισαγωγή

Η πρόσβαση στο διαδίκτυο μέσο κινητών συσκευών έχει γίνει

πραγματικότητα. Η χρήση κινητών τηλεφώνων και άλλων ασύρματων

συσκευών για την αποστολή και λήψη ηλεκτρονικού ταχυδρομείου, για την

ενημέρωσή μας πάνω σε θέματα επικαιρότητας, καθώς και για την

πραγματοποίηση οικονομικών ηλεκτρονικών συναλλαγών (μέσο των

παρόχων κινητής τηλεφωνίας) είναι γεγονός. Το κινητό τηλέφωνο

χρησιμοποιείται όλο και περισσότερο ως συσκευή πρόσβασης στο διαδίκτυο

και ο αριθμός των συνδρομητών εκτιμάται ότι θα ξεπεράσει παγκοσμίως το

ένα δισεκατομμύριο έως το έτος 2005, σύμφωνα με την μελέτη που

πραγματοποιήθηκε από τον Οργανισμό IDC .

5

Στην Ευρώπη, στην Αμερική και κυρίως στην Ασία, έχουν υλοποιηθεί

υπηρεσίες που υποστηρίζουν την ασύρματη τεχνολογία, ενώ έχει

παρατηρηθεί ενθουσιώδης αποδοχή ορισμένων υπηρεσιών από το

καταναλωτικό κοινό.

Όσον αφορά τον Ευρωπαϊκό χώρο (συμπεριλαμβανομένης και της

Ελλάδας), οι εξελίξεις στον τομέα των τηλεπικοινωνιών έχουν εισάγει νέες

τεχνολογίες ως αποτέλεσμα της σύγκλισης των τηλεπικοινωνιών με το

Internet. Σταδιακά θα δοθεί σε όλους η δυνατότητα να έχουν πρόσβαση στο

διαδίκτυο μέσο του κινητού τους τηλεφώνου οπουδήποτε και αν βρίσκονται.

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

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

GPRS (General Packet Radio Switching), διότι προσφέρει διαρκή σύνδεση,

με μεγαλύτερες ταχύτητες πρόσβασης και με πιο οικονομικό τρόπο.

Συγχρόνως, έχουν εισαχθεί στην αγορά τα δίκτυα τρίτης γενεάς (3G

Networks) που προσφέρουν ακόμα μεγαλύτερη ταχύτητα πρόσβασης, με

αποτέλεσμα να αναμένεται η ραγδαία αύξηση των χρηστών και η ταχεία

διάδοση των υπηρεσιών που προσφέρονται μέσο κινητών, καθώς η ταχύτητα

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

ένταξης νέων χρηστών, οι οποίοι θα έχουν περισσότερες απαιτήσεις και

μεγαλύτερες ανάγκες.

Εδώ, θα πρέπει να αναφέρουμε ότι τα συστήματα τρίτης γενιάς UMTS

(Universal Mobile Telecommunications System), παρέχουν την δυνατότητα να

διαδοθούν νέες υπηρεσίες που δεν μπορούν να προσφερθούν από τα

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

Τηλεκπαίδευσης, Videoconferencing κ.λ.π

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

εταιρείες παροχής υπηρεσιών στο διαδίκτυο οδηγούνται στο να παρέχουν

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

επιτυγχάνεται δημιουργώντας ιστοσελίδες κατανοητές και εύκολα

προσπελάσιμες, διότι ο χρήστης απαιτεί, στην on-line σύνδεσή του με την

ασύρματη συσκευή του, να βλέπει, να αποφασίζει και να αγοράζει γρήγορα

6

και εύκολα. Θα πρέπει να τονιστεί η ευκολία που προσφέρει η ασύρματη

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

μεγάλο εύρος πληροφοριών (καιρός, χρηματιστήριο, καθυστερήσεις πτήσεων,

emails κ.α.), ανεξαρτήτως τοποθεσίας. Ένα ακόμα πλεονέκτημα είναι ότι οι

ιστοσελίδες για ασύρματη τεχνολογία είναι δομημένες έτσι, ώστε να

προσφέρουν στον χρήστη όσο το δυνατό αρτιότερες πληροφορίες σε

περιορισμένο αριθμό λέξεων, υποσκελίζοντας κατ’ αυτόν τον τρόπο το πιθανό

μειονέκτημα της μικρής οθόνης της ασύρματης συσκευής του χρήστη.

Τα τελευταία χρόνια, μεγάλος αριθμός εταιρειών παροχής υπηρεσιών

έχουν επενδύσει και συνεχίζουν να επενδύσουν τεράστια ποσά στον ολοένα

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

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

αγορά να κινηθεί προς την σωστή κατεύθυνση. Πρωταρχικός σκοπός, λοιπόν,

των εταιρειών αυτών είναι να μπορούν να προσφέρουν τρία βασικά στοιχεία:

i) “οικειότητα”, ώστε να οδηγήσουν στην ευρύτερη χρήση ασύρματων

συσκευών, ii) φαντασία, ώστε να δημιουργήσουν τις υπηρεσίες που θέλει και

χρειάζεται ο χρήστης και iii) απλότητα, ώστε να επιτυγχάνεται η ταύτιση του

χρήστη με το προσφερόμενο προϊόν.

Είναι γνωστό ότι κάθε πρωτοποριακό προϊόν επηρεάζει με κάποιον τρόπο

την ανθρώπινη συμπεριφορά και τις ανθρώπινες αξίες. Όπως δηλαδή στην

αρχή του 19ου αιώνα με την βιομηχανική επανάσταση και την ταυτόχρονη

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

την μεγάλη ανάπτυξη της ασύρματης τεχνολογίας παγκοσμίως τα επόμενα 10

χρόνια, θα παρατηρηθεί μία τεράστια αλλαγή. Αυτή η αλλαγή θα έχει σαν

αποτέλεσμα την αλληλεπίδραση ανθρώπου (χρήστη) με την πραγματικότητα

“του ανοίγω και ψάχνω όποτε και από όπου θέλω”. Αυτή ακριβώς η

αλληλεπίδραση είναι η μικρή “επανάσταση” στον τρόπο ζωής του χρήστη-

ανθρώπου. Βεβαίως η στιγμή που η ασύρματη τεχνολογία θα είναι αυτό που

λέμε “τρόπος ζωής” είναι ακόμα μακριά, αλλά όχι για πολύ.

Παρακάτω εισάγουμε τις τεχνολογίες του GPRS και του UMTS. Οι

τεχνολογίες αυτές φέρνουν τις υπηρεσίες του διαδικτύου στα κινητά τερματικά

7

και θα αποτελέσουν το εφαλτήριο για τη διάδοση και ευρεία διείσδυση των

υπηρεσιών αυτών στην κινητή τηλεφωνία.

1.2 GPRS

Tο GPRS είναι ένα πρωτόκολλο που παρέχει υπηρεσίες Internet στην

κινητή τηλεφωνία. Είναι ένα ραγδαία αναπτυσσόμενο και διαδιδόμενο μέσο

παροχής τέτοιων υπηρεσιών σ’ ολόκληρο τον κόσμο και κυρίως στην

Ευρώπη, όπου ήδη έχει καταφέρει να κατακτήσει, αν και σε πρώιμο ακόμη

στάδιο, το μεγαλύτερο μέρος της αγοράς σε σχέση με άλλα αντίστοιχα

πρωτόκολλα, όπως για παράδειγμα το WAP (Web Access Protocol).

Η καινοτομία του GPRS έγκειται στο γεγονός ότι ο χρήστης δεν συνδέεται

στο Internet κάθε φορά που χρειάζεται να το χρησιμοποιήσει, αλλά είναι

μονίμως συνδεδεμένος σε αυτό και οι πληροφορίες που θέλει να «κατεβάσει»

έρχονται με την μορφή πακέτου (Switched Packet System) κάθε φορά που

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

κάποια «παράθυρα» στη σηματοδοσία του κινητού τερματικού είναι μόνιμοι

δίαυλοι GPRS, δηλαδή το κινητό τερματικό έχει μόνιμη πρόσβαση στο

Internet και τις υπηρεσίες του.

Η μόνιμη κατάσταση σύνδεσης με το Internet παρέχει απεριόριστη ευκολία

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

και με πολύ οικονομικότερο τρόπο, αφού η χρέωση γίνεται ανά πακέτο

πληροφορίας που «κατεβαίνει» στο κινητό τερματικό και όχι ανάλογα με τον

χρόνο που είναι συνδεδεμένος ο χρήστης στο διαδίκτυο.

Το λειτουργικό σύστημα που χρησιμοποιεί το GPRS είναι πολύ φιλικότερο

στον χρήστη (user friendly) από ότι το αντίστοιχο του WAP που είναι και το

αμέσως προηγούμενο πιο διαδεδομένο σύστημα. Για το λόγο αυτό τα

τηλέφωνα τρίτης γενιάς (3G mobile phones) είναι εξοπλισμένα με κατάλληλα

λογισμικά που θυμίζουν κατά πολύ το περιβάλλον του κόσμου του Internet,

όπως τον έχουμε γνωρίσει μέσα από τα PC. Οι ιστοσελίδες κατεβαίνουν στον

κινητό δέκτη στην ίδια σχεδόν μορφή και παρέχουν και ανάλογα applets με

εκείνα που παρέχονται στον υπολογιστή.

8

Το GPRS ως πρωτόκολλο έχει να επιδείξει ένα πολύ καλά οργανωμένο

σύστημα ασφαλείας χρηστών τόσο σε επίπεδο ιών και άλλων bugs που

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

όσο και σε επίπεδο λήψης και διάδοσης προσωπικών δεδομένων. Είναι ένα

πρωτόκολλο εξίσου καλά δομημένο με το Web σε θέματα ασφάλειας και που

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

Web το κάνει εξ ορισμού ακόμα περισσότερο ασφαλές.

Σήμερα οι περισσότερες εταιρίες παροχής κινητής τηλεφωνίας στην

Ελλάδα έχουν αρχίσει να εισάγουν συχνότητες σηματοδοσίας για τo GPRS.

Το γεγονός αυτό δηλώνει την μεγάλη ζήτηση που πρόκειται να υπάρξει

στο μέλλον για την παροχή των υπηρεσιών GPRS. Ήδη η αγορά έχει

αρχίσει να κατακλύζεται από κινητούς δέκτες που είναι GPRS enabled ακόμα

και σε κινητά τηλέφωνα δεύτερης γενιάς.

Η ανάγκη, λοιπόν, για εύκολη, γρήγορη και οικονομική πρόσβαση στο

Διαδίκτυο μέσο κινητών τηλεφώνων φαίνεται να καλύπτεται τώρα μέσο του

GPRS. Είναι φανερή η στροφή του κόσμου της κινητής τηλεφωνίας στο GPRS

και η βαθμιαία εγκατάλειψη του WAP σαν ένα πιο πρωτόγονο και πιο

δύσχρηστο μέσο παροχής Internet υπηρεσιών.

1.2.1 Αρχιτεκτονική ασφάλειας του GPRS

Η ασφάλεια στο GPRS αντιμετωπίζεται με διαφορετική οπτική. Αφενός,

ελέγχεται η ταυτότητα του συνδρομητή, αφετέρου, η κίνηση των δεδομένων

συνιστάται να ελέγχεται σε όλο το δίκτυο και να προστατεύεται με χρήση

ειδικού μηχανισμού (π.χ. ηλεκτρονικού τείχους), ώστε να αποφεύγεται το

ενδεχόμενο παρείσφρησης σε αυτό [GSM09.61].

Όπως και για το GSM, έτσι και για το GPRS, υπάρχουν ορισμένα θέματα

που αφορούν τις σχετικές υπηρεσίες και τη λειτουργικότητα ασφάλειας. Η

λειτουργικότητα ασφάλειας στο GPRS ασχολείται με [GSM03.20]:

• Εμπιστευτικότητα ταυτότητας του συνδρομητή

9

• Αυθεντικοποίηση ταυτότητας του συνδρομητή

• Εμπιστευτικότητα της πληροφορίας του χρήστη και της

σηματοδότησης μεταξύ ΚΣ και SGSN.

• Ασφάλεια του δικτύου κορμού του GPRS και διαλειτουργικότητας

GPRS

Προκειμένου να προστατεύεται η επικοινωνία, μπορούν να

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

[GSM01.61]. Επιπλέον, παρέχονται διαδικασίες για την ανάκαμψη από

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

Κρυπτογράφηση στο GPRS

Ο αλγόριθμος κρυπτογράφησης του GPRS χρησιμοποιείται για την παροχή

αντιμέτρων ασφάλειας και σχετικών λειτουργιών, όπως αυτές έχουν

παρουσιαστεί σε αυτή την εργασία [GSM02.60], [GSM03.60]. Συγκεκριμένα

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

μεταξύ του ΚΣ και του δικτύου (SGSN) και αποτελεί ουσιαστικά τον αλγόριθμο

A5 για το GPRS. Στόχοι του νέου αλγορίθμου είναι [GSM01.61]:

• να παρέχει προστασία της εμπιστευτικότητας και της ακεραιότητας των

δεδομένων του χρήστη που διακινούνται στο GPRS σε συνδέσεις από

σημείο σε σημείο μεταξύ ενός ΚΣ και άλλων οντοτήτων.

• να παρέχει προστασία της εμπιστευτικότητας και της ακεραιότητας των

δεδομένων του χρήστη που μεταδίδονται στο GPRS σε συνδέσεις από

ένα σημείο σε πολλά σημεία (Point-to-Multipoint Group).

Η χρήση του αλγόριθμου περιορίζεται στην κρυπτογράφηση μεταξύ ΚΣ και

SGSN.

Ο αλγόριθμος εγκαθίσταται τόσο στο SGSN, όσο και στον ΚΣ. Ο ΚΣ

αποτελείται από Τερματικό εξοπλισμό (ΤΕ), Terminal adaptation (TA) και

Mobile Equipment (ME). Ο ΚΣ είναι και αυτόνομη συσκευή. Ο αλγόριθμος

είναι εγκαταστημένος στα ME, TA, TE.

10

Θα πρέπει να σημειωθεί, ότι, όπως όλοι οι αλγόριθμοι του GSM, έτσι και οι

αλγόριθμοι του GPRS δεν επιτρέπεται να δημοσιοποιηθούν για λόγους

ασφαλείας. Επιπλέον, υπάρχουν νομικοί περιορισμοί στη χρήση ή στην

εξαγωγή εξοπλισμού, που περιέχει κρυπτογραφικά χαρακτηριστικά, οι οποίοι

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

Ευρωπαϊκές κυβερνήσεις. Χρήστες των αλγορίθμων επιτρέπεται να είναι οι

ΠΤΥΚΤ οι οποίοι χρησιμοποιούν τους αλγορίθμους στην πλευρά του δικτύου

και οι κατασκευαστές υλικού (π.χ. ΚΣ ή SIMs), οι οποίοι κατασκευάζουν

συσκευές, περιλαμβάνουν ένα τέτοιο αλγόριθμο.

Οι αλγόριθμοι κρυπτογράφησης του GPRS υλοποιούνται κατά προτίμηση

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

λογισμικό, τότε οι περιορισμοί χρήσης είναι ακόμη πιο αυστηροί.

Σχήμα 1: Βασικό περιβάλλον κρυπτογράφησης GPRS

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

της κρυπτογράφησης, INPUT είναι μια τιμή που εξαρτάται από το τρέχον

πλαίσιο (frame) του LLC, DIRECTION είναι η κατεύθυνση μεταφοράς

(uplink/downlink). Επιπλέον, PLAIN TEXT και CIPHERED TEXT είναι

αντίστοιχα το αρχικό κείμενο και το κρυπτογραφημένο που προκύπτει. Οι

παράμετροι του αλγορίθμου έχουν τα μήκη:

11

Kc 64 bits INPUT 32 bits DIRECTION 1 bit OUTPUT 1600 octets (max)

Το Kc δημιουργείται από τη διαδικασία αυθεντικοποίησης και διαχείρισης

κλειδιών του GPRS. To Kc δεν μεταδίδεται ποτέ από την ασύρματη ζεύξη.

Στην οντότητα που αποστέλλει, εκτελείται η πράξη XOR μεταξύ της

συμβολοσειράς OUTPUT και του PLAINTEXT και το αποτέλεσμα είναι το

CIPHER TEXT. Τίθενται περιορισμοί απόδοσης στον αλγόριθμο, έτσι ώστε να

μην καθυστερεί πέρα από κάποια όρια η ασύρματη μετάδοση.

Εμπιστευτικότητα ταυτότητας του συνδρομητή

Στόχος αυτής της λειτουργίας είναι να αποφεύγεται η πιθανότητα, ένας

εισβολέας να μπορέσει να εντοπίσει, ποιος συνδρομητής χρησιμοποιεί ένα

συγκεκριμένο πόρο στην ασύρματη ζεύξη, καταγράφοντας την ανταλλαγή

σημάτων στην ασύρματη ζεύξη [GSM03.20]. Αυτού του είδους η προστασία

επιτρέπει αφενός υψηλό βαθμό εμπιστευτικότητας της πληροφορίας του

χρήστη και της σηματοδοσίας, αφετέρου προστασία από τον εντοπισμό της

θέσης του συνδρομητή. Η συγκεκριμένη απαίτηση προϋποθέτει ότι δεν θα

μεταδίδεται στην ασύρματη ζεύξη οποιαδήποτε πληροφορία που θα επέτρεπε

τον εντοπισμό του χρήστη και ιδιαίτερα το IMSI του κάθε συνδρομητή χωρίς

να έχει κρυπτογραφηθεί πρώτα. Είναι λοιπόν απαραίτητο:

• Να μη χρησιμοποιείται το IMSI αλλά κάποιο άλλο μέσο για ταυτοποίηση

στην ασύρματη ζεύξη

• Να πραγματοποιείται κρυπτογράφηση σημάτων που μεταφέρουν

πληροφορία για την ταυτότητα του συνδρομητή στην ασύρματη ζεύξη,

όπου είναι δυνατό

Επιπλέον, η ανώνυμη προσπέλαση, η οποία παρέχεται ως δυνατότητα

από το GPRS, επιτρέπει σε ένα χρήστη να χρησιμοποιεί πόρους του δικτύου

GPRS χωρίς τη χρήση ταυτότητας συνδρομητή. Αυτή η δυνατότητα

12

διασφαλίζει εξ ορισμού την εμπιστευτικότητα της ταυτότητας του συνδρομητή

[GSM03.60].

Το μέσο για να επιτευχθεί ταυτοποίηση του συνδρομητή /ΚΣ στην

ασύρματη ζεύξη είναι μία προσωρινή μεταβλητή που ονομάζεται TLLI. Αυτός

ο αριθμός είναι ένας τοπικός αριθμός ο οποίος έχει έννοια μόνο σε μία

συγκεκριμένη Περιοχή Δρομολόγησης (ΠΔ). Το TLLI θα πρέπει να

συνοδεύεται από την Ταυτότητα ΠΔ (Routing Area Identity ή RAI), ώστε να

αποφεύγονται ασάφειες.

To SGSN περιέχει κατάλληλες βάσεις δεδομένων για την καταγραφή των

συσχετίσεων μεταξύ των TLLI και IMSI. Όταν λαμβάνεται ένα TLLI με ένα RAI

το οποίο δεν αντιστοιχεί στο τρέχον SGSN, τότε το IMSI του ΚΣ πρέπει να

ζητηθεί από το SGSN της συγκεκριμένης ΠΔ, που αναφέρεται από το RAI,

εφόσον αυτή είναι γνωστή. Διαφορετικά το IMSI ζητείται από τον ΚΣ. Ένα νέο

TLLI ανατίθεται σε ένα ΚΣ σε κάθε διαδικασία Ενημέρωσης ΠΔ. Μόλις

δημιουργείται το νέο TLLI (που αφορά άλλη ΠΔ), το παλιό διαγράφεται.

Σε περιπτώσεις δυσλειτουργιών, που μπορεί να προκύψουν π.χ. από μία

αποτυχία στο λογισμικό, το δίκτυο ενδέχεται να ζητήσει την ταυτοποίηση του

ΚΣ με βάση το IMSI χωρίς να είναι σε αυτή την περίπτωση δυνατή η

κρυπτογράφηση. Αυτή η περίπτωση αποτελεί αδυναμία ολόκληρης της

υπηρεσίας και θα πρέπει κατά το δυνατό να αποφεύγεται.

Κάθε φορά που δημιουργείται ένα νέο TLLI, μεταφέρεται στον ΚΣ

κρυπτογραφημένο. Ο ΚΣ αποθηκεύει το TLLI και το RAI σε μνήμη της οποίας

το περιεχόμενο δεν σβήνεται, όταν απενεργοποιηθεί η συσκευή του ΚΣ.

Οι διαδικασίες οι οποίες σχετίζονται με την ταυτοποίηση ενός ΚΣ με βάση

το TLLI είναι οι εξής [GSM03.20]:

• Ενημέρωση ΠΔ στην ίδια περιοχή του SGSN

• Ενημέρωση ΠΔ σε ένα νέο SGSN, όταν το προηγούμενο SGSN είναι

προσπελάσιμο (IMSI από SGSNo προς SGSNn)

13

• Ενημέρωση ΠΔ σε ένα νέο SGSN, όταν το προηγούμενο SGSN δεν είναι

προσπελάσιμο (IMSI από ΚΣ προς SGSNn)

• Αναδημιουργία TLLI (περίπτωση διαγραφής IMSI από HLR, όπου

ταυτόχρονα χρησιμοποιείται το TLLI)

• Άγνωστο τοπικό TLLI, σε περίπτωση απώλειας δεδομένων (IMSI από ΚΣ

προς SGSN)

• Ενημέρωση ΠΔ σε ένα νέο SGSN, όταν το SGSN χάσει δεδομένα (IMSI

από ΚΣ προς SGSNn)

• Αποτυχημένη κατανομή TLLI (IMSI από ΚΣ προς SGSN)

Από τις παραπάνω περιπτώσεις, αυτές που περιλαμβάνουν αδυναμίες

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

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

• Ενημέρωση ΠΔ σε ένα νέο SGSN, όταν το προηγούμενο SGSN δεν είναι

προσπελάσιμο (IMSI από ΚΣ προς SGSNn)

• Άγνωστο τοπικό TLLI, σε περίπτωση απώλειας δεδομένων (IMSI από ΚΣ

προς SGSN)

• Ενημέρωση ΠΔ σε ένα νέο SGSN, όταν το SGSN χάσει δεδομένα

(IMSI από ΚΣ προς SGSNn)

• Αποτυχημένη κατανομή TLLI (IMSI από ΚΣ προς SGSN)

Αυθεντικοποίηση ταυτότητας του συνδρομητή

Η αυθεντικοποίηση στο GPRS είναι ανάλογη με αυτή που χρησιμοποιείται

στο GSM. Οι λειτουργίες δικτύου που απαιτούνται είναι:

• Η διαδικασία της αυθεντικοποίησης

• Η διαχείριση κλειδιών

Η διαδικασία της αυθεντικοποίησης χρησιμοποιείται και για την δημιουργία

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

14

του συνδρομητή (IMSI/TLLI) στο δίκτυο, οπότε αποστέλλεται το κατάλληλο

RAND για να πραγματοποιηθεί η κρυπτογράφηση.

Γενικά, οι διαδικασίες που αφορούν την αυθεντικοποίηση της ταυτότητας

του συνδρομητή είναι:

• Διαδικασία αυθεντικοποίησης σύμφωνα με το GSM

• Διαχείριση κλειδιών αυθεντικοποίησης συνδρομητή σύμφωνα με το

GSM

• Γενική διαδικασία αυθεντικοποίησης (IMSI από SGSN προς

HLR/AuC)

• Αυθεντικοποίηση σε ενημέρωση ΠΔ σε ένα νέο SGSN, με τη χρήση

TLLI (IMSI από SGSNo προς SGSNn)

• Αυθεντικοποίηση κατά την ενημέρωση ΠΔ σε ένα νέο SGSN, όταν

το προηγούμενο δεν είναι προσπελάσιμο (IMSI από ΚΣ προς

SGSNn και από SGSNn προς HLR/AuC)

• Αυθεντικοποίηση κατά την ενημέρωση ΠΔ σε ένα νέο SGSN, όταν

το TLLI είναι άγνωστο στο προηγούμενο SGSN σε απώλεια

δεδομένων (IMSI από ΚΣ προς SGSNn και από SGSNn προς

HLR/AuC)

• Αυθεντικοποίηση με τη χρήση του IMSI, όταν αποτύχει η

αυθεντικοποίηση με το TLLI (IMSI από ΚΣ προς SGSN)

• Επαναχρησιμοποίηση πληροφορίας ασφάλειας σε περιπτώσεις

αποτυχιών

15

Σχήμα: Γενική διαδικασία αυθεντικοποίησης στο GPRS

Σχήμα: Ενημέρωση των εγγραφών πληροφορίας ασφάλειας RAND/SRES στο SGSN

16

Από τις παραπάνω περιπτώσεις υπάρχουν ορισμένες οι οποίες περιέχουν

αδυναμίες ασφάλειας που σχετίζονται κυρίως με τη μεταφορά του IMSI χωρίς

κρυπτογράφησης από την ασύρματη ζεύξη:

• Αυθεντικοποίηση κατά την ενημέρωση ΠΔ σε ένα νέο SGSN, όταν

το προηγούμενο δεν είναι προσπελάσιμο

• Αυθεντικοποίηση κατά την ενημέρωση ΠΔ σε ένα νέο SGSN, όταν

το TLLI είναι άγνωστο στο προηγούμενο SGSN σε απώλεια

δεδομένων

• Αυθεντικοποίηση με τη χρήση του IMSI, όταν αποτύχει η

αυθεντικοποίηση με το TLLI

Εμπιστευτικότητα πληροφορίας χρήστη και σηματοδοσίας μεταξύ

Κινητού Σταθμού και SGSN

Η εμπιστευτικότητα της πληροφορίας του χρήστη αφορά τη μεταφορά της

πληροφορίας στη λογική σύνδεση μεταξύ ΚΣ και SGSN. Για να διασφαλιστεί η

εμπιστευτικότητα το TLLI μεταφέρεται κρυπτογραφημένο στη φάση της

δημιουργίας του. Η κρυπτογράφηση αυτή παρέχεται από το επίπεδο LLC και

δεν αποτελεί υπηρεσία εμπιστευτικότητας από σημείο σε σημείο [GSM03.20].

Θα πρέπει να καθοριστούν τα εξής:

• Η μέθοδος κρυπτογράφησης

• Δημιουργία κλειδιού GPRS-Kc

• Έναρξη κρυπτογράφησης και αποκρυπτογράφησης

• Συγχρονισμός

• Μεταφορά κλειδιού και άλλων παραμέτρων μεταξύ SGSN σε

ενημέρωση ΠΔ

• Ορίζονται δύο ζεύγη μεταβλητών που αφορούν την κρυπτογράφηση:

17

• Kc και CKSN (Αριθμός Ακολουθίας Κλειδιού Κρυπτογράφησης

(Ciphering Key Sequence Number)) που αφορούν τη μεταγωγή

κυκλώματος

• GPRS-Kc και GPRS-CKSN που αφορούν τη μεταγωγή πακέτου και

το GPRS

Ασφάλεια δικτύου κορμού του GPRS και Διαλειτουργικότητας

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

που έχει εγκαταστήσει και που περιέχει όλους τους απαιτούμενους κόμβους

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

εξουσιοδοτημένη προσπέλαση. Ένα ασφαλές δίκτυο κορμού ενός ΠΤΥΚΤ

GPRS εγγυάται ότι δεν θα μπορέσει κάποιος εισβολέας να παρακολουθήσει ή

να τροποποιήσει την πληροφορία του χρήστη και την σηματοδοσία στο

εσωτερικό δίκτυο.

Η αρχιτεκτονική του GPRS χρησιμοποιεί ιδιωτική διευθυνσιοδότηση IP και

GPRS tunnelling στο δίκτυο κορμού. Περιεχόμενο χρηστών το οποίο

απευθύνεται σε κάποιο στοιχείο του δικτύου απορρίπτεται. Συνίσταται η

χρήση ηλεκτρονικών τειχών στα σημεία πρόσβασης Gi και Gp του δικτύου

κορμού του GPRS.

Οι συνδέσεις μεταξύ ΠΤΥΚΤ GPRS συμφωνούνται από τους παρόχους και

διασφαλίζουν ότι είναι ασφαλείς και ότι παρέχουν ακεραιότητα και

εμπιστευτικότητα. Κάθε πάροχος GPRS μπορεί να υποστηρίζει το IPsec (RFC

1825) καθώς και τις συνοδευτικές προδιαγραφές για αυθεντικοποίηση (RFC

1826) και κρυπτογράφηση (RFC 1827), ως βασική λειτουργικότητα ασφάλειας

στα BG που χρησιμοποιεί [GSM09.61]. Γενικά, συνίσταται να

χρησιμοποιούνται για τις συνδέσεις:

• Συνδέσεις από σημείο σε σημείο

• Ιδιωτικά δίκτυα κορμού μεταξύ ΠΤΥΚΤ GPRS

18

• Κρυπτογραφημένες σήραγγες μεταξύ ΠΤΥΚΤ GPRS, οι οποίες

ενδέχεται να χρησιμοποιούν και το Internet

Όσον αφορά τη διαλειτουργικότητα με διαφορετικά δίκτυα πακέτων

δεδομένων, προκειμένου να προστατεύεται το δίκτυο GPRS εφαρμόζονται

κατάλληλα αντίμετρα ασφάλειας στο σημείο πρόσβασης της διεπαφής Gi,

όπως π.χ. ένα ηλεκτρονικό τείχος, το οποίο περιορίζει τα είδη των πακέτων

που διακινούνται και ενδεχομένως και τα είδη των εφαρμογών που

επιτρέπεται να προσφέρονται.

Ειδική μέριμνα έχει δοθεί στην ασφάλεια του εξυπηρετητή DNS και της

διευθυνσιοδότησης IP (που γίνεται π.χ. με τη χρήση ενός εξυπηρετητή

DHCP). Έτσι διασφαλίζεται η ορθότητα των DNS ονομάτων, καθώς και η

προστασία των IP διευθύνσεων.

Σχετικά με τη χρήση ενός ΚΣ από ένα χρήστη για σύνδεση σε IP δίκτυα,

όπως το Internet, ένα Intranet ή ένας ISP, παρέχονται ειδικές λειτουργίες

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

κρυπτογράφηση από άκρο σε άκρο μεταξύ ΚΣ και της άλλης ομότιμης

οντότητας, ανάθεση μίας δυναμικής διεύθυνσης IP που ανήκει στο χώρο

διευθύνσεων του Internet ή του Intranet ή του ISP, κλπ. [GSM09.61].

Σύμφωνα με όσα αναφέρθηκαν σε προηγούμενη παράγραφο, εφαρμόζονται

ειδικές μέθοδοι αυθεντικοποίησης του συνδρομητή και προστασίας της

πληροφορίας που μεταδίδεται κατά τη επικοινωνία του με ένα

απομακρυσμένο Intranet ή ISP δίκτυο. Η σχετική σύνδεση γίνεται είτε με

διαφανή είτε με αδιαφανή τρόπο και προστατεύεται με πρωτόκολλα όπως π.χ.

το IPSec. Ταυτόχρονα, παρέχεται και στον ΚΣ αυθεντικοποίηση του δικτύου

του ΠΤΥ, ώστε να διασφαλίζεται ότι επικοινωνεί με τον αληθινό εξυπηρετητή

και όχι με πλαστό (Ran-93).

Διευθύνσεις δικτύου και ασφάλεια

Ένα σημαντικό πρόβλημα το οποίο αντιμετωπίζεται προκειμένου κάθε ΚΣ

να αποκτά δυνατότητα σύνδεσης σε ένα δίκτυο πακέτων δεδομένων, όπως

είναι το Internet, σχετίζεται με την διαθεσιμότητα των διευθύνσεων δικτύου.

19

Ήδη στην τρέχουσα έκδοση του Internet, ο αριθμός των διαθέσιμων

διευθύνσεων είναι εξαιρετικά περιορισμένος. Συνεπώς, είναι σκόπιμο να

αναζητηθούν οι πλέον αποδοτικοί τρόποι για την κατανομή διευθύνσεων τόσο

από τους αρμόδιους φορείς στους ΠΤΥΚΤ, όσο και από τους ΠΤΥΚΤ στους

ΚΣ. Τόσο η ανάθεση διευθύνσεων IP, η στατική και κυρίως η δυναμική, όσο

και η ανάθεση ονομάτων DNS ενέχει σημαντικούς κινδύνους ασφάλειας, οι

οποίοι με κατάλληλα μέτρα προλαμβάνονται και αντιμετωπίζονται.

Ταυτόχρονα, η σύνδεση ενός ΚΣ στο Internet από διαφορετικούς ΠΤΥΚΤ,

π.χ. σε περίπτωση ταξιδιού του χρήστη σε ξένη χώρα, θέτει το ζήτημα της

μεταφοράς διεύθυνσης (address migration) .

Αξιολόγηση Ασφάλειας GPRS

Η προστασία της ασφάλειας και της ιδιωτικής ζωής στο GPRS αποτελεί

βασική προϋπόθεση για την ανάπτυξη κρίσιμων εφαρμογών όπως είναι οι

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

ευαίσθητων προσωπικών δεδομένων του συνδρομητή. Στο GPRS όμως,

όπως και γενικά στο GSM, προδιαγράφονται μέτρα προστασίας και, κατά

βάση, για την ασύρματη ζεύξη. Η προστασία στο GPRS εκτείνεται από τον ΚΣ

και περιλαμβάνει τους BTS/BSC και φθάνει μέχρι το SGSN.

Ακόμα όμως και σε αυτή την περίπτωση, η παρεχόμενη ασφάλεια έχει τα

μειονεκτήματα και τις αδυναμίες του GSM. Οι διαφορετικές οντότητες SGSN

ακόμα και αν ανήκουν σε διαφορετικούς παρόχους θεωρούνται έμπιστες. Η

εμπιστοσύνη αυτή βασίζεται στις συμφωνίες που προδιαγράφεται και

υπογράφονται μεταξύ των παρόχων, όσον αφορά την ασφάλεια της

διασύνδεσης μεταξύ τους.

Συγκεκριμένα οι σχετικές αδυναμίες, που αφορούν το εσωτερικό δίκτυο

GPRS, συνοψίζονται στα εξής σημεία:

20

• Η σχεδίαση ασφάλειας στο GPRS αφορά κυρίως την ασύρματη σύνδεση

και εκτείνεται μέχρι το SGSN (περιλαμβάνει τους BSC και BTS)

[GSM03.20], [GSM03.60]

• Παρέχεται προστασία της Ιδιωτικής Ζωής της θέσεως του ΚΣ/ συνδρομητή

μόνο από τον ΚΣ μέχρι το SGSN και όχι σε όλο το δίκτυο GSM

[GSM03.02]

• Δεν υπάρχει προστασία της Ιδιωτικής Ζωής μεταξύ των διαφορετικών

SGSN, και των άλλων οντοτήτων του δικτύου όπως τα VLR και HLR

• Δεν υπάρχει προστασία της Ιδιωτικής Ζωής μεταξύ των οντοτήτων SGSN

του παρόχου και των SGSN, τα οποία ανήκουν σε άλλα δίκτυα

• Αναφορικά με την αυθεντικοποίηση της ταυτότητας του χρήστη:

• Η ασφάλεια βασίζεται κυρίως στην μυστικότητα των αλγορίθμων

κρυπτογράφησης

• Η αυθεντικοποίηση ενός ΚΣ γίνεται στο SGSN και υποστηρίζεται από το

HLR

• Κατανάλωση εύρους ζώνης μεταξύ SGSN και HLR,όταν το SGSN

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

Δεν έχει σχεδιαστεί και υλοποιηθεί στο GPRS η αυθεντικοποίηση των

SGSN. Ένα ψευδές SGSN είναι δυνατό να δώσει λανθασμένη πληροφορία σε

ένα ΚΣ και κατά συνέπεια να προκαλέσει διαρροή των δεδομένων του ΚΣ και

γενικά παραβίαση της ασφάλειας του ΚΣ και της Ιδιωτικής Ζωής του

συνδρομητή

Εάν η ευαίσθητη πληροφορία που είναι αποθηκευμένη σε ένα SGSN

καταγράφεται από μία άλλη μη εξουσιοδοτημένη οντότητα, τότε η επικοινωνία

παρακολουθείται

Αναφορικά με την εμπιστευτικότητα της ταυτότητας του χρήστη:

• Δεν παρέχεται ασφάλεια από σημείο σε σημείο, διότι δεν παρέχεται

ασφάλεια, που να βασίζεται σε μια πρότυπη διαδικασία που να

περιλαμβάνει όλη τη διαδρομή των δεδομένων από τον πομπό στο

δέκτη και αντίστροφα.

21

• Ένα SGSN, το οποίο ανήκει σε άλλο ΠΤΥΚΤ ή γενικά σε άλλο χώρο

δικαιοδοσίας δεν μπορεί να θεωρείται ότι είναι έμπιστο. Κατά

συνέπεια, η μετάδοση μεταξύ SGSN και SGSN ή HLR δεν είναι

ασφαλής στο GSM. Θα μπορούσε ένα ψευδές SGSN σε συνεργασία

με κατάλληλο εξοπλισμό MSC να παραπλανήσει τον ΚΣ και να

υποκλέψει την επικοινωνία.

• Ο αλγόριθμος GPRS-A5 αναφέρεται ότι μπορεί να παραβιαστεί σε

λιγότερο από 1sec σε μία μηχανή PC με 128MB RAM και μεγάλους

σκληρούς δίσκους. Από την άλλη πλευρά δεν είναι εύκολο να

καταγραφεί μία σύνοδος GPRS στην ασύρματη ζεύξη.

Όσον αφορά την προστασία της ιδιωτικότητας θέσης του χρήστη:

• Η προστασία της ιδιωτικότητας θέσης βασίζεται στην ασφάλεια της

ενσύρματης σύνδεσης μεταξύ SGSN και HLR

• Όταν γίνεται ενημέρωση για τη θέση ενός ΚΣ, το IMSI μεταδίδεται

στο εσωτερικό του (ενσύρματου) δικτύου του GPRS χωρίς καμία

προστασία.

• Όποτε υπάρχει κάποιο πρόβλημα στο δίκτυο και έχει χαθεί το TLLI

από το SGSN, θα πρέπει να γίνει από την αρχή ταυτοποίηση του ΚΣ

με βάση το IMSI, το οποίο θα μεταδοθεί χωρίς κρυπτογράφηση.

• Εάν υπάρχει πρόβλημα στο SGSN και δεν είναι δυνατό να

εντοπιστεί το TLLI και στη συνέχεια γίνει κάποια κλήση, τότε το

SGSN κάνει paging στον ΚΣ και χρησιμοποιείται το IMSI αντί για το

TLLI. Το IMSI μεταδίδεται σε αυτή την περίπτωση χωρίς

κρυπτογράφηση.

• Όταν ένας χρήστης μετακινηθεί στην περιοχή ενός διαφορετικού

SGSN και το προηγούμενο SGSN δεν είναι διαθέσιμο/

προσπελάσιμο (και κατά συνέπεια ούτε το TLLI), τότε θα γίνει η

ενημέρωση θέσης με τη χρήση του ίδιου του IMSI, το οποίο θα

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

Αναφορικά με την χρέωση ενός συνδρομητή:

22

• Αναφέρεται από ορισμένους ΠΤΥΚΤ ότι η χρέωση στο GPRS γίνεται

με βάση τον όγκο των δεδομένων που μεταδίδονται. Παρόλο που

αυτό πιθανόν να συμφέρει τον συνδρομητή περισσότερο το

συνδρομητή υπάρχει κίνδυνος υπερβολικής χρέωσης [HansH]. Θα

μπορούσε κάποια άλλη κακόβουλη οντότητα του δικτύου να

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

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

του συγκεκριμένου χρήστη.

Αναφορικά με την νόμιμη παρέμβαση και παρακολούθηση:

• Η δυνατότητα νόμιμης παρέμβασης δέχεται έντονη κριτική σχετικά

με τις επιπτώσεις που μπορεί να έχει στην Ιδιωτική Ζωή των

συνδρομητών

• Η χρήση πρωτοκόλλων επιπέδου εφαρμογής για κρυπτογράφηση

(π.χ. IPsec) θέτει ερωτηματικά για την αποδοτικότητα και

χρησιμότητα της Νόμιμης Παρέμβασης. Απάντηση θα μπορούσε να

δοθεί με χρήση τεχνολογιών escrowed κρυπτογράφηση [HansH].

• Πέρα από την ασφάλεια του δικτύου GPRS, που αφορά είτε το

δίκτυο κορμού του είτε τη διεπαφή μεταξύ του δικτύου και του ΚΣ, το

όλο σύστημα συμπεριφέρεται ως ένα αυτόνομο σύστημα, εάν το

εξετάσουμε σε σχέση με τη διαλειτουργικότητά του με το Internet. Ως

τέτοιο, προστατεύει τα σημεία πρόσβασης προς αυτό με στόχο να

παρέχει ασφαλή υπηρεσία στους χρήστες του.

Παρόλα αυτά δεν είναι ευνόητο ότι προστατεύει τον κάθε χρήστη

ξεχωριστά, όσον αφορά πάντα τις υπηρεσίες του πρωτοκόλλου IP, εφόσον

κάθε χρήστης ενδέχεται να έχει διαφορετικές απαιτήσεις ασφάλειας. Δεν είναι

λογικό ίσως π.χ.. να προστατεύει τους χρήστες σε υπηρεσίες του επιπέδου

εφαρμογής, και γενικά σε υπηρεσίες που παρέχονται με βάση το πρωτόκολλο

IP. Όμως υπάρχουν απαιτήσεις ασφάλειας, όπως για παράδειγμα ορισμένες

πτυχές της προστασίας της Ιδιωτικής Ζωής, τις οποίες προστατεύει ο

πάροχος του δικτύου GPRS.

23

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

προστατεύεται. Ο βαθμός προστασίας αυτής της πληροφορίας είναι υπό

αμφισβήτηση στο εσωτερικό δίκτυο του GPRS. Όμως, στην περίπτωση του

επιπέδου IP και της σύνδεσης ενός ΚΣ με ένα απομακρυσμένο σύστημα στο

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

γίνεται γνωστό είναι, ότι ο συγκεκριμένος χρήστης επικοινωνεί με το

απομακρυσμένο σύστημα μέσα από το δίκτυο του συγκεκριμένου ΠΤΥΚΤ.

Εάν ο πάροχος δεν πραγματοποιούσε ο ίδιος την κατανομή των IP

διευθύνσεων αλλά, μετά από συμφωνία, αυτή η υπηρεσία προσφερόταν από

εξωτερικό ISP, με τη χρήση κάποιου DHCP, ή RADIUS, τότε ίσως δεν θα

διέρρεε ούτε αυτή η πληροφορία που αφορά της εγγραφή σε συγκεκριμένο

ΠΤΥΚΤ.

Επιπλέον, η προστασία της Ιδιωτικής Ζωής σχετικά με τη θέση ενδέχεται

να απειλείται κατά τη χρήση εφαρμογών που λαμβάνουν υπόψη τη θέση του

συνδρομητή. Για παράδειγμα, μία υπηρεσία/ εφαρμογή που δίνει στο χρήστη

τη δυνατότητα να βλέπει πληροφορίες στον ΚΣ για τα εστιατόρια, ή τα

φαρμακεία της πόλης, ή της περιοχής που βρίσκεται, πρέπει να έχει μέσα από

ειδικό σύστημα πρόσβαση στις αντίστοιχες πληροφορίες του ΠΤΥΚΤ

[GSM03.71].

Η Υποδομή Δημοσίου Κλειδιού (PKI) και οι Αρχές Πιστοποίησης

(Certification Authorities) πιστοποιούν υπηρεσίες που παρέχονται από το

GPRS, εφόσον ορίζονται σε επίπεδο Internet. Η πιστοποίηση εξυπηρετητών

ιστού χρησιμεύει σε ένα ΚΣ για να αποκτά πρόσβαση σε εξυπηρετητές που

θεωρούνται έμπιστοι. Χρησιμοποιούνται με τον ίδιο τρόπο οι υπηρεσίες της

ψηφιακής υπογραφής και της αποστολής και λήψης ασφαλών μηνυμάτων

ηλεκτρονικού ταχυδρομείο.

Στην περίπτωση που τα SGSN και GGSN στεγάζονται σε διαφορετικό

πάροχο, θα πρέπει να γίνει ανάλογη πιστοποίηση. Ενδιαφέρον θέμα αποτελεί

η εμπλοκή των ΠΤΥΚΤ στην παροχή υπηρεσιών πιστοποίησης.

24

1.2.2 Νόμιμες Παρεμβάσεις από τη Δικαιοσύνη

Σε ορισμένες περιπτώσεις κρίνετε απαραίτητο από τη Δικαιοσύνη να

πραγματοποιηθεί καταγραφή περιεχομένου κάποιου είδους επικοινωνίας

καθώς και άλλων σχετικών πληροφοριών, τόσο στο GSM όσο και στο GPRS

[GSM03.33]. Σε ορισμένες χώρες όπως στις ΗΠΑ, τέτοιου είδους

παρακολούθηση και καταγραφή προϋποθέτει απόφαση δικαστηρίου. Σε άλλες

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

επείγοντος (π.χ. εντοπισμός ενός συνδρομητή σε περίπτωση ατυχήματος)

προϋποθέτει την παρακολούθηση και καταγραφή των στοιχείων επικοινωνίας

του.

Η πληροφορία που χρειάζεται να καταγραφεί είναι:

• Θέση του συνδρομητή (χώρα, πάροχος, ΠΔ, κελί, …)

• Ενέργειες του συνδρομητή

• Περιεχόμενο μετάδοσης αποκρυπτογραφημένο

Σε περίπτωση κρυπτογράφησης σε επίπεδο εφαρμογής (από άκρο σε

άκρο) δεν είναι δυνατή η καταγραφή του περιεχομένου του

κρυπτογραφήματος.

Παρόλα αυτά, σε όλα τα άλλα πρωτόκολλα που βασίζονται στο IP

καταγράφονται:

• Πηγή και προορισμός δεδομένων

• Πληροφορίες πρωτοκόλλου

Στο GPRS καταγράφεται η πληροφορία που αφορά την εξέλιξη μιας

κλήσης [GSM02.33]. Πραγματοποιείται παρακολούθηση στα:

• SGSN

• GGSN

Στη διάθεση της Δικαιοσύνης παρέχονται πληροφορίες για τα ακόλουθα

γεγονότα, τα οποία καταγράφονται στο SGSN:

25

• Σύνδεση GPRS

• ΑποσύνδεσηGPRS

• Ενεργοποίηση PDP context

• Έναρξη καταγραφής/ παρακολούθησης όσο το PDP context είναι

ενεργό

• Απενεργοποίηση PDP context

• Ενημέρωση κελιού ή ΠΔ

• SMS

• Επιπλέον, στα GGSN καταγράφονται τα εξής:

• Ενεργοποίηση PDP context

• Έναρξη καταγραφής/ παρακολούθησης, όσο το PDP context είναι

ενεργό

• Απενεργοποίηση PDP context

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

πρωτόκολλο που βασίζεται π.χ. στο IP, τότε στη διάθεση της

Δικαιοσύνης παρέχονται τα πακέτα που διακινήθηκαν. Το παρακάτω

σχήμα δείχνει τα πιθανά σημεία παρεμβολής σε ένα δίκτυο

GSM/GPRS.

26

Intra-PLMNδίκτυοΚορμού

(IP-based)

Router

SGSN

Inter-PLMNδίκτυοκορμού

(IP-based)

FW

Internet

X.25network

Server

GGSN

FW

BG

PSTNBSS

MSC/VLR

HLR

SMS-GMSC/SMS-IWMSC

SM-SC

FWGi (IP)

Gi(X.25)

Gc

Gp

PLMN1Υποδομή

GPRS

Gn

Gn

Gr

Gd C

Gb Gs

A

DE

SGSN

PLMN2Υποδομή

GPRS

GpΝόμιμη

Παρακολούθησηαπό τη Δικαιοσύνη

Σχήμα: Σημεία παρεμβολής από τη Δικαιοσύνη σε ένα δίκτυο GSM-GPRS

Η μέθοδος προσπέλασης για την παράδοση προϊόντος παρακολούθησης

GPRS βασίζεται στην αντιγραφή των πακέτων χωρίς να γίνεται τροποποίηση

στα GSN.

Ένας κατάλογος του είδους της πληροφορίας που παρέχεται μετά από

καταγραφή αφορά:

• Πληροφορία ενεργοποίησης (σε MSC/VLR, GSN, κλπ.)

27

• Την οντότητα που είναι ο στόχος της παρακολούθησης (π.χ.,

MSISDN, IMSI, IMEI)

• Το είδος του πρωτοκόλλου που χρησιμοποιείται (π.χ. IP, ή X.25)

• Διεύθυνση PDP που χρησιμοποιεί ο στόχος της παρακολούθησης

• Πληροφορίας Θέσης του στόχου (Cell Global Identity)

• Χρονική στιγμή του γεγονότος

LEA

DeliveryFunction 3P

Συνδρομητής πουπαρακολουθείται

Άλληοντότητα

GSN

Αντιγραφήπακέτων

Σχήμα: Εγκατάσταση για την παρέμβαση στα δεδομένα του GPRS

Συγκεκριμένα, οι πληροφορίες που καταγράφονται είναι οι εξής

[GSM03.33]:

• MSISDN στόχου

• IMSI στόχου

• IMEI στόχου

• Τύπος γεγονότος (π.χ., ενεργοποίηση PDP context, κλπ.)

• Ημερομηνία γεγονότος

• Ώρα δημιουργίας του γεγονότος στο GSN

• Διεύθυνση PDP του στόχου (πιθανά δυναμική)

• Το APN του σημείου πρόσβασης

• Κωδικός ΠΔ του στόχου

• Τύπος του πρωτοκόλλου πακέτων (PDP)

• Αριθμός συσχέτισης μεταξύ IP και IRI

• Περιεχόμενο μετάδοσης SMS και SMS-Centre address

• Πληροφορίας Θέσης του στόχου (Cell Global Identity)

• Αιτία αποτυχημένης σύνδεσης του στόχου

28

• Αιτία αποτυχημένης ενεργοποίησης PDP context του στόχου

• Interception Area υπό παρακολούθηση

1.3 UMTS

Εισαγωγή

Το UMTS (Universal Mobile Telecommunications System) είναι η

υλοποίηση τεχνολογίας νέας γενιάς κινητών επικοινωνιών για έναν κόσμο

όπου "οι προσωπικές υπηρεσίες βασίζονται σε ένα συνδυασμό σταθερών και

ασύρματων / κινητών υπηρεσιών για τη δημιουργία μίας seamless από άκρη

σε άκρη (end-to-end) υπηρεσίας για το χρήστη". Ως συνέπεια οι

τηλεπικοινωνιακές εταιρείες κατευθύνονται προς :

• Την παροχή ενοποιημένης παρουσίασης υπηρεσιών προς το

χρήστη σε ασύρματα και ενσύρματα περιβάλλοντα,

• Μία κινητή τεχνολογία η οποία υποστηρίζει ένα ευρύ φάσμα

επικοινωνιακών υπηρεσιών και εφαρμογών,

• Μία κατ' απαίτηση ευέλικτη κατανομή εύρους (on-demand flexible

bandwidth allocation) και σε μεγάλη ποικιλία εφαρμογών, και

• Μία προτυποποίηση η οποία επιτρέπει πλήρη περιαγωγή (roaming)

και ικανότητα διαδικτύωσης (interworking capability), όπου

απαιτείται, αλλά επίσης ανταποκρινόμενη σε proprietary,

καινοτομικές και niche αγορές.

Με εκμετάλλευση της πλήρους δυναμικότητας του UMTS, οι

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

τεχνικά ολοκληρωμένου, περιεκτικού και συνεπούς (consistent) συστήματος

προσωπικών επικοινωνιών υποστηριζόμενου και από σταθερά και από κινητά

τερματικά/ συσκευές. Σαν αποτέλεσμα, κινητά δίκτυα πρόσβασης (mobile

access networks) προσφέρουν υπηρεσίες οι οποίες παραδοσιακά παρέχονται

μόνο από σταθερά δίκτυα, συμπεριλαμβανομένων υπηρεσιών ευρείας ζώνης

29

μέχρι 2Mb/s. Το UMTS λειτουργεί επίσης ως υλοποίηση σε stand-alone

δίκτυο.

Η αναγκαιότητα του UMTS

Στα πρώτα χρόνια της νέας χιλιετίας αυξάνονται οι απαιτήσεις των

χρηστών για αδιάλειπτη παροχή τηλεπικοινωνιακών υπηρεσιών ακόμα και

μετά την απομάκρυνση από το χώρο εργασίας ή κατοικίας. Οι υπηρεσίες

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

βασισμένη στο κείμενο πληροφορίας επιπρόσθετα στη «βασική φωνή».

Τα υπάρχοντα ασύρματα ή κινητά συστήματα περιορίζονται σε

συγκεκριμένους ρυθμούς μετάδοσης δεδομένων και δεν διαθέτουν ευελιξία ως

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

απαιτεί ένα καινούριο σύστημα, ικανό να διαχειρίζεται και να παρέχει μια πολύ

ευρύτερη περιοχή υπηρεσιών πληροφορίας στη μαζική αγορά.

Για να υλοποιηθεί ένα τέτοιο σύστημα απαιτούνται:

• Ευρεία βιομηχανική και κυβερνητική σύμπραξη σε όλον τον κόσμο

• Ένα πρόγραμμα που να αγκαλιάζει το φάσμα (spectrum), τα

πρότυπα και την τεχνολογία

• Αρχικές επίγειες και δορυφορικές υπηρεσίες διαθέσιμες το 2002 σε

μεγάλες αγορές, με πλατειά διαβάθμιση εξέλιξης κι υιοθέτηση στο

2005

• Μεγάλες ποσότητες από φάσμα που ήδη έχουν σχεδιαστεί

• Συνέργιες μεταξύ επικοινωνιών, τεχνολογίας της πληροφορίας και

μέσων , που εργάζονται προς την κατεύθυνση της δημιουργίας

σφαιρικών ευκαιριών για τις επιχειρήσεις και τους καταναλωτές και

της δημιουργίας καινούριων τρόπων για την εκτέλεση

επιχειρηματικών και άλλων σχεδίων.

• Μαζική αγορά, που για την Ευρώπη εκτιμάται ότι θα ανέρχεται στα

ECU 45 bn μόνο το 2005

30

Τι είναι το UMTS

Το UMTS είναι ένα από τα μεγαλύτερα κινητά συστήματα τρίτης γενιάς, το

οποίο σχεδιάστηκε στο πλαίσιο εργασίας που έχει οριστεί από τη διεθνή

ένωση τηλεπικοινωνιακών (ITU), γνωστό και ως IMT-2000. Είναι αποτέλεσμα

επίμονων προσπαθειών που έγιναν σε ολόκληρο τον κόσμο στην έρευνα και

την ανάπτυξη την τελευταία δεκαετία. Το UMTS έχει την υποστήριξη από

πολλούς μεγάλους λειτουργούς τηλεπικοινωνιών και κατασκευαστών επειδή

παρουσιάζει μια μοναδική ευκαιρία να δημιουργήσει μαζική αγορά για υψηλή

προσωπική και φιλική προς το χρήστη κινητή πρόσβαση στην κοινωνία της

πληροφορίας.

Το UMTS έχει τη δυνατότητα να κατασκευάσει και να επεκτείνει την

ικανότητα των σημερινών κινητών cordless και δορυφορικών τεχνολογιών,

παρέχοντας αυξημένη χωρητικότητα, ικανότητα δεδομένων κι ένα μεγάλο

εύρος υπηρεσιών, χρησιμοποιώντας καινοτόμο σχήμα πρόσβασης

ραδιοφώνου και μια αυξημένο, αναπτυσσόμενο κορμό δικτύου.

• Φάσμα για το UMTS

Το 1992, το παγκόσμιο συνέδριο ραδιοφώνου αναγνώρισε τα φάσματα

συχνοτήτων 1885-2025 ΜΗz και 2110-2200 ΜΗz για τα μελλοντικά ΙΜΤ-2000

συστήματα. Από αυτά τα φάσματα, τα 1980-2010 ΜΗz και 2170-2200 ΜΗz

σχεδιάζεται να χρησιμοποιηθούν για το δορυφορικό κομμάτι των μελλοντικών

συστημάτων.

Η Ευρώπη κι η Ιαπωνία έχουν αποφασίσει να υλοποιήσουν το επίγειο

κομμάτι των UMTS στα ζεύγη φασμάτων 1920-1980 ΜΗz και 2110-2170

ΜΗz. Η Ευρώπη επίσης αποφάσισε να υλοποιήσει το UTRA στα φάσματα

που δεν αποτελούν ζεύγη (unpaired bands) 1900-1920 ΜΗz και 2010-2025

ΜΗz. Στις αρχές του 1998, η Ευρωπαϊκή επιτροπή εξέδωσε την «πρόταση EC

για το ευρωπαϊκό κοινοβούλιο και το συμβούλιο απόφασης για το UMTS για

να επιβεβαιώσει ότι τα μέλη του ευρωπαϊκού κοινοβουλίου θα προβούν στα

κατάλληλα βήματα για να δημιουργήσουν την ευρωπαϊκή επιτροπή

31

αποφάσεων ραδιοφώνου on spectrum. Αυτό, σε συνδυασμό με την

υπάρχουσα οδηγία αδειών, επιβεβαιώνει ότι οι υπηρεσίες UMTS ξεκίνησαν το

2002.

Στις Ηνωμένες Πολιτείες της Αμερικής, υπάρχει η αρχή σύμφωνα με την

οποία κάθε άδεια είναι ελεύθερη να υλοποιήσει όποια τεχνολογία επιλέγει.

Φάσματα για τις τεχνολογίες τρίτης γενιάς είναι τα φάσματα PCS, SCS και

τμήματα από τα φάσματα UHF TV.

Τι προσφέρει το UMTS

• Ευκολία στη χρήση και χαμηλό κόστος

Οι χρήστες των κινητών υπηρεσιών απαιτούν κυρίως χρήσιμες υπηρεσίες,

απλά τερματικά και ποιότητα παροχής υπηρεσίας που να ανταποκρίνεται στο

κόστος της.

Το UMTS προσφέρει:

• Υπηρεσίες που απευθύνονται στις ατομικές ανάγκες των χρηστών και

τις προτιμήσεις τους με κύριο χαρακτηριστικό την ευκολία χρήσης τους

• Τερματικά κι άλλο εξοπλισμό-interface με τον χρήστη που επιτρέπει

εύκολη πρόσβαση στις προσφερόμενες υπηρεσίες

• Χαμηλό κόστος προσφερόμενων υπηρεσιών για τον χρήστη, που

δημιουργεί αγορά παροχής μαζικών, ανταγωνιστικών προϊόντων

• Μεγάλη ποικιλία τερματικών συσκευών χαμηλού κόστους που

υποστηρίζουν την τεχνολογία UMTS

• Καινούριες και καλύτερες υπηρεσίες

Οι μελέτες αγοράς δείχνουν ότι η ομιλία παραμένει η επικρατέστερη

υπηρεσία μέχρι το 2005 για τα υπάρχοντα σταθερά και κινητά δίκτυα

τηλεφώνων, περιλαμβανομένου του GSM. Οι χρήστες απαιτούν χαμηλού

32

κόστους-υψηλής ποιότητας υπηρεσίες ομιλίας από το UMTS, ενώ αυξημένα

έσοδα πάνω στα σημερινά συστήματα έρχονται από την παροχή

προχωρημένων υπηρεσιών δεδομένων και πληροφοριών. Στο μέλλον, οι

προβλέψεις της βιομηχανίας για το UMTS δείχνουν μια δυνατή

αναπτυσσόμενη βάση συνδρομητών για υπηρεσίες πολυμέσων μέχρι το έτος

2010.

• Γρήγορη πρόσβαση

Παράγοντας-ένδειξη ότι το UMTS υπερτερεί των κινητών συστημάτων

δεύτερης γενιάς είναι η δυνατότητα του να υποστηρίζει αφενός ρυθμούς

δεδομένων στα 2 Μbit/sec για τους χρήστες και αφετέρου το Internet UMTS

πρωτόκολλο. Με αυτόν τον τρόπο είναι δυνατή η παροχή αλληλεπιδρόμενων

υπηρεσιών πολυμέσων, καθώς και νέων εφαρμογών ευρέως φάσματος όπως

η βίντεο-τηλεφωνία και η βιντεο-συνδιάσκεψη.

Καθώς οι απαιτήσεις των χρηστών για ρυθμούς δεδομένων θα αυξάνονται

στο μέλλον, το UMTS αναπτύσσεται με σκοπό την υποστήριξη ακόμα

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

μεγαλύτεροι.

Σε διαφορές φάσεις της ανάπτυξης του UMTS υπάρχει σύγκλιση με

συστήματα που υποστηρίζουν ακόμα μεγαλύτερους ρυθμούς δεδομένων

χρησιμοποιώντας κινητές ασύρματες LAN τεχνολογίες (παρέχοντας π.χ.

ρυθμούς δεδομένων 155 Μbit/s σε εσωτερικά περιβάλλοντα).

• Μετάδοση πακέτων και ρυθμοί δεδομένων κατά απαίτηση

Τα περισσότερα κυψελοειδή συστήματα που βρίσκονται σε χρήση σήμερα

χρησιμοποιούν την τεχνολογία μεταγωγής κυκλώματος για τη ασύρματη

μετάδοση δεδομένων αν και το UMTS ολοκληρώνει (συνδυάζει) τη μετάδοση

δεδομένων με μεταγωγή κυκλώματος και πακέτου. Τα πλεονεκτήματα για

τους χρήστες είναι:

• Διαρκής εικονική σύνδεση στο δίκτυο

33

• Εναλλακτικοί τρόποι χρέωσης - για παράδειγμα ογκοχρέωση,

χρονοχρέωση

• Ασύμμετρο εύρος ζώνης στην άνοδο και την κάθοδο, όπως ζητείται από

πολλές αναδυόμενες υπηρεσίες δεδομένων, όπου η μία κατεύθυνση του

συνδέσμου μεταφέρει απλές εντολές κι η άλλη μεταφέρει μεγάλο όγκο

πληροφοριών (π.χ. αναζήτηση στο Web σε αντίθεση με μετάδοση βίντεο).

Το UMTS επίσης σχεδιάστηκε να προσφέρει ρυθμούς δεδομένων κατά

απαίτηση, όπου το δίκτυο αντιδρά ευέλικτα στις απαιτήσεις του χρήστη, στο

προφίλ του και στη τρέχουσα κατάσταση του δικτύου. Τα πρωτόκολλα

μεταφοράς προσανατολισμένα στα πακέτα, όπως το πρωτόκολλο του Internet

(ΙΡ) έχει προβλεφθεί για το UMTS με τρόπο, ώστε να εκπληρωθούν αυτές οι

απαιτήσεις. Η αποστολή και λήψη δεδομένων σε πακέτα σε συνδυασμό με

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

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

• Φιλικό και συνεπές περιβάλλον υπηρεσιών

Οι υπηρεσίες UMTS βασίζονται σε κοινά πρότυπα για όλους τους χρήστες

του UMTS και των περιβαλλόντων του ραδιοφώνου. Αυτό σημαίνει ότι ένας

χρήστης έχει την εμπειρία ενός συνεπούς συνόλου από υπηρεσίες ακόμα κι

αν κάνει roam από το δίκτυο του σπιτιού σε άλλους UMTS operators,

δημιουργώντας έτσι ένα «εικονικό περιβάλλον σπιτιού» (VHE). Το VHΕ

επιβεβαιώνει την παροχή ενός ολοκληρωμένου περιβάλλοντος από τον

παροχέα υπηρεσιών, π.χ. το εικονικό περιβάλλον εργασίας ενός χρήστη

συσσωματωμένο, ανεξάρτητα από την τοποθεσία του κι από τον τρόπο

πρόσβασης (επίγειο ή δορυφορικό).

Το VHE επίσης επιτρέπει στα τερματικά να διαπραγματεύονται

λειτουργικότητα με το επισκεπτόμενο δίκτυο, με πιθανότητα ακόμη και

τροποποίησης του λογισμικού ώστε να παρέχει υπηρεσίες με απόλυτη

34

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

στόχος είναι ότι όλα τα δίκτυα, οι σηματοδοτήσεις, η σύνδεση, η εγγραφή κι

όποια άλλη τεχνολογία είναι αόρατα στο χρήστη, έτσι ώστε οι κινητές

υπηρεσίες πολυμέσων να είναι απλές, φιλικές προς το χρήστη κι αποδοτικές.

• Προσαρμοστικότητα και κάλυψη

Το UMTS σχεδιάστηκε από την αρχή ως παγκόσμιο σύστημα που

περιλαμβάνει επίγεια και δορυφορικά στοιχεία. Τερματικά που είναι ικανά να

λειτουργούν μέσο συστημάτων δεύτερης γενιάς όπως το GSM 900 και 1800

επεκτείνουν τη λειτουργία τους σε UMTS υπηρεσίες. Είναι πιθανό να

υπάρχουν ακόμα περισσότερα δίκτυα που θα χρησιμοποιούν αυτά κι άλλα

πρότυπα: ο στόχος είναι να επιτευχθούν προσωπικές επικοινωνίες, με

τερματικά ικανά να υποστηρίζουν περιαγωγή μεταξύ διαφορετικών δικτύων.

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

ιδιωτικό δίκτυο σ’ ένα πικοκυψελοειδές/ μικροκυψελοειδές δημόσιο δίκτυο,

έπειτα σε ένα ευρείας περιοχής μακροκυψελοειδές δίκτυο (που μπορεί να

είναι ένα δίκτυο δεύτερης γενιάς) και στη συνέχεια σε ένα δορυφορικό κινητό

δίκτυο με ελάχιστη διακοπή στην επικοινωνία.

• Δημιουργία υπηρεσιών

Το UMTS κάνει ένα μεγάλο βήμα εμπρός στις κινητές τηλεπικοινωνίες

καθώς παρέχει ένα περιβάλλον δημιουργίας υπηρεσιών (μέρος του VHE) που

επιτρέπει τους UMTS διαχειριστές και σε άλλες οντότητες να δημιουργούν

νέες υπηρεσίες σε ελάχιστο χρόνο, ανεξάρτητα από το δίκτυο, την πρόσβαση

ή το τερματικό.

Οι παραδοσιακές μέθοδοι ορισμού υπηρεσιών, για παράδειγμα μέσο

προτύπων από διάφορους οργανισμούς, είναι χρονοβόρες και εμποδίζουν

τους διαχειριστές να εργάζονται απρόσκοπτα στο σημερινό ανταγωνιστικό

περιβάλλον. Το VHE παρακάμπτει αυτό το πρόβλημα, επιτρέποντας εύκολη

δημιουργία νέων υπηρεσιών.

35

Το VHE και τα εργαλεία που το συνοδεύουν παρέχουν μια ιδανική

πλατφόρμα για χρήση από ανεξάρτητες οντότητες (όπως ιδιωτικά δίκτυα και

intranets) που επιθυμούν να παρέχουν στους συνδρομητές τους υπηρεσίες

βασισμένες στις τηλεπικοινωνίες. Η τεχνολογία επίσης επιτρέπει τη

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

αξίας. Οι παροχείς υπηρεσιών και οι διαχειριστές δικτύου έχουν για πρώτη

φορά ένα αληθινό εργαλείο και την ευκαιρία να συνεισφέρουν στην ανάπτυξη

της κοινωνίας της πληροφορίας και καθίστανται κυριολεκτικά «Μεσίτες

υπηρεσιών» παραδίνοντας, βελτιστοποιώντας και πακετάροντας διαθέσιμες

υπηρεσίες, προερχόμενες από μια τεράστια ποικιλία πηγών.

Η ευελιξία που εισάγεται με το VHE όχι μόνο αυξάνει το εύρος των

υπηρεσιών που μπορούν να προσφερθούν στους συνδρομητές και τους

χρήστες αλλά επιτρέπει και την παρακολούθηση διαφορετικών τύπων χρήστη

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

ώστε οι υπηρεσίες να είναι συνεπείς αλλά και ικανές να προσαρμόζονται

τόσο στις συνθήκες των χρηστών όσο και στο τερματικό τους και στις

προσβάσεις του δικτύου.

36

2. Πρωτόκολλα Επικοινωνίας

2.1 WAP

Ορισμός

Στις 26 Ιουνίου 1997 η Ericsson σε συνεργασία με τις Motorola, Nokia και

Unwired Planet, ξεκίνησαν μία προσπάθεια δημιουργίας ενός πρωτοκόλλου

(de facto standard) που θα ενοποιούσε όλες τις μέχρι τότε μεμονωμένες

προσπάθειες δημιουργίας εφαρμογών που αποσκοπούσαν στην προσφορά

υπηρεσιών Internet μέσα από την οθόνη του κινητού τηλεφώνου.

Αυτή η προσπάθεια οδήγησε στην δημιουργία του WAP Forum που είχε

αρχικά τέσσερα μέλη, τις μεγαλύτερες εταιρείες παραγωγής κινητών

τηλεφώνων στον κόσμο Το WAP Forum οδήγησε στην δημιουργία του

πρωτοκόλλου WAP (Wireless Application Protocol) και αποτελεί πλέον το de

facto standard προσφοράς υπηρεσιών Internet μέσα από το κινητό τηλέφωνο.

Αργότερα το WAP Forum «άνοιξε» τις πόρτες του και σε άλλες εταιρείες

τηλεπικοινωνιών και πληροφορικής με αποτέλεσμα να αριθμεί σήμερα

εκατοντάδες μέλη από ολόκληρο τον κόσμο.

To WAP (Wireless Application Protocol) είναι ένα ανοιχτό διεθνές

περιβάλλον, μέσο του οποίου οι χρήστες ασύρματων συσκευών έχουν

δυνατότητα πρόσβασης και αμφίδρομης επικοινωνίας σε πληροφορίες και

υπηρεσίες του Διαδικτύου.

Το WAP (Wireless Application Protocol) είναι μια ανοιχτή εφαρμογή που

προσφέρει μια πρότυπη μέθοδο πρόσβασης σε δεδομένα και εφαρμογές που

είναι βασισμένες στη μορφή του Διαδικτύου από ασύρματες συσκευές, όπως

κινητά τηλέφωνα και PDA’s (Personal Digital Assistants).

Το μοντέλο WAP είναι παρόμοιο με τον παραδοσιακό τρόπο πρόσβασης

στο Internet. Η κινητή συσκευή έχει ενσωματωμένο λογισμικό φυλλομετρητή

(browser) ο οποίος συνδέεται με μια πύλη WAP (WAP gateway) και κάνει

37

αιτήσεις για πληροφορίες από web servers στην κανονική μορφή μιας

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

προσαρμοσμένο στη μικρή οθόνη των κινητών τηλεφώνων και στις

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

περιεχόμενο είναι γραμμένο σε μια γλώσσα που καλείται WML (Wireless

Markup Language). Η WML δίνει τη δυνατότητα για ικανότητες και από την

πλευρά του εξυπηρετούμενου (client).

Το WAP λαμβάνει υπόψιν την μικρή οθόνη του κινητού σε σχέση με αυτήν

του PC καθώς επίσης και το περιορισμένο πληκτρολόγιο, την μικρή μνήμη και

τέλος την χαμηλή ταχύτητα ασύρματης επικοινωνίας ανάμεσα στο τερματικό

και την κυψέλη κινητής τηλεφωνίας.

Τα βασικά οφέλη του WAP περιλαμβάνουν:

• Μη αποκλειστική μέθοδο πρόσβασης σε δεδομένα και υπηρεσίες στη

μορφή διαδικτύου.

• Το δικτυακά ανεξάρτητο WAP λειτουργεί πάνω σε υπάρχοντα δίκτυα,

όπως τα CDPD, CDMA (IS 95 ή IS-707), GSM (900, 1800 και 1900 MHz),

PDC, PHS, TDMA/D-AMPS (IS-136), FLEX, ReFLEX, ( τα δυο τελευταία

είναι paging standards από τη Motorola), iDEN, TETRA, DECT, DataTAC,

Mobitex (της Ericsson). Επίσης έχει προβλεφθεί να μπορεί να λειτουργήσει

και πάνω σε μελλοντικά δίκτυα όπως το GPRS.

• To WAP έχει υιοθετηθεί από το 95% των κατασκευαστών κινητών

τηλεφώνων και άλλων συσκευών με προηγμένες εφαρμογές του

διαδικτύου και εφαρμόζεται από την πλειοψηφία των προμηθευτών.

• Το WAP είναι πρωτόκολλο επικοινωνίας και περιβάλλον εφαρμογών. Οι

φυλλομετρητές WAP μπορούν να εδραιωθούν πάνω σε οποιοδήποτε

λειτουργικό σύστημα συμπεριλαμβανομένων των PalmOS, EPOC,

Windows CE, FLEXOS, OS/9, JavaOS και άλλα.

Ωστόσο το WAP δεν πρόκειται να φτάσει στο σημείο να συναγωνιστεί τις

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

38

υπολογιστές. Δεν είναι σωστό να θεωρηθεί ότι το WAP μπορεί να προσφέρει

τη δυνατότητα για ολοκληρωμένη πλοήγηση στο διαδίκτυο. Ένα από τα

προβλήματα είναι η χαμηλή ποιότητα εικόνας και το μικρό μέγεθος της οθόνης

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

WAP συσκευής. Όμως παρατηρώντας το πρώτο κύμα των WAP-συμβατών

τηλεφώνων όπως είναι το 7110 της Nokia, το R380 της Ericsson και το One

Touch Pocket της Alcatel έχουν αρχίσει να βρίσκονται πρακτικές λύσεις στα

παραπάνω προβλήματα. Τις λύσεις αυτές έχουν υιοθετήσει και άλλοι

κατασκευαστές, όπως η Siemens με το S25 και Samsung με το Ν100.

Όσο για το μέλλον, ο βασικός λόγος που θα χρησιμοποιηθεί το WAP και

όχι το HTML είναι το χαμηλό εύρος ζώνης, δηλαδή τα σημερινά δίκτυα κινητής

τηλεφωνίας είναι υπερβολικά αργά όταν πρόκειται για υποστήριξη σύνθετων

ιστοσελίδων. Πιστεύεται ότι σε λίγα χρόνια το WAP θα αποτελέσει το

σημαντικότερο μηχανισμό για μεταφορά πληροφοριών στο ευρύ κοινό.

Αρχιτεκτονική

• Γενική περιγραφή του WAP

Το περιβάλλον του WAP είναι παρόμοιο με αυτό του World Wide Web

(WWW). Το WWW αποτελείται από τρία πρωτεύοντα συστατικά, τον Web

Client (Πελάτη), το Internet Protocol-IP (πρωτόκολλο επικοινωνίας) και τον

Web Server (εξυπηρετητή) τα οποία λειτουργούν και επικοινωνούν μεταξύ

τους μέσο ενός συνόλου προτυποποιημένων μηχανισμών: standard naming

model (URL), specific content typing, standard content formats (HTML,

JavaScript) και standard protocols (HTTP).

Το WAP διευρύνει τις δυνατότητες του διαδικτύου σε ασύρματα δίκτυα. Το

WAP-Internet περιβάλλον αποτελείται από έναν WAP Client (WAE user agent

– micro browser), ένα ασύρματο δίκτυο, μία WAP πύλη (WAP Gateway), ένα

IP δίκτυο και έναν εξυπηρετητή περιεχομένου (Content Server). O WAP Client

επικοινωνεί με τη WAP πύλη στέλνοντας δεδομένα δομημένα με χρήση της

Wireless Markup Language (WML), πάνω από το ασύρματο δίκτυο. Η πύλη

39

WAP μεταφράζει τα WML δεδομένα από/ σε HTML και στη συνέχεια

αναμεταδίδει τα δεδομένα μεταξύ του ασύρματου και ενσύρματου δικτύου

επικοινωνώντας με τον Web Server. Στο επόμενο σχήμα φαίνονται όλα τα

συστατικά και η ροή δεδομένων στο περιβάλλον WAP-Internet.

Παρόλο που το τυπικό περιβάλλον WAP είναι αυτό που παρουσιάσαμε πιο

πάνω, η αρχιτεκτονική WAP μπορεί εύκολα να δεχτεί και διαφορετική

διαμόρφωση. Ειδικότερα, είναι δυνατό ο εξυπηρετητής περιεχομένου (Content

Server) να περιλαμβάνει και τη λειτουργικότητα της WAP πύλης με στόχο να

διευκολύνει την υιοθέτηση end-to-end λύσεων ασφάλειας.

WMLClient

WAEuseragent

Gateway

Encoders andDecoders

Content Server

Content

CGI scripts,etc

HTML

WML HTML

Εικόνα: Περιγραφή του περιβάλλοντος WAP

• Σημείωση:

Πρέπει να σημειωθεί εδώ ότι παρόλο που το WAP αποτελεί μια πολλά

υποσχόμενη νέα τεχνολογία, αποκτά επιπλέον αξία όταν χρησιμοποιείται σε

κυψελωτά δίκτυα (σε αντίθεση με άλλα ασύρματα δίκτυα). Αυτό είναι

σημαντικό, από τη στιγμή που ασύρματη επικοινωνία μπορεί να εγκαθιδρυθεί

και μέσο ασύρματων IP δικτύων (ασύρματα LAN), τα οποία είναι εν γένει

φθηνότερα από τα κυψελωτά και δεν είναι απαραίτητο να βασίζονται στο

πρωτόκολλο WAP.

Κάθε τερματικό είναι εφοδιασμένο με έναν WAP Browser που είναι κάτι

ανάλογο του Internet Browser. Η γλώσσα που χρησιμοποιείται ονομάζεται

WML (Wireless Markup Language) σε αντιστοιχία με την HTML (Hypertext

Markup Language).

40

Εικόνα: Internet και WAP

Η «μεταφορά» της πληροφορίας από τον κόσμο του WAP στον κόσμο του

Internet επιτυγχάνεται από το WAP Gateway/Proxy.

Η σύνδεση του WAP Gateway (G/W) με το κέντρο μεταγωγής κινητής

τηλεφωνίας (MSC, Mobile Switching Center) είναι δυνατό να επιτευχθεί με

δύο τρόπους. Ο πρώτος είναι η σύνδεση του MSC με έναν IAS (Internet

Access Server) και κατόπιν σύνδεση του IAS με το WAP G/W μέσο Ethernet.

Ο δεύτερος τρόπος είναι η απευθείας σύνδεση του WAP G/W με το MSC

μέσο του πρωτοκόλλου SS7 (SMS).

Εικόνα: Αρχιτεκτονική του WAP

41

Ασφάλεια

Ασφάλεια Επιπέδου Δοσοληψίας (Wireless Transaction Layer Security-WTLS)

To WTLS είναι ένα πρωτόκολλο ασφάλειας που βασίζεται στην

τυποποίηση: πρωτόκολλο ασφαλείας επιπέδου δοσοληψίας ή πρωτόκολλο

TLS, πιο παλιά γνωστό ως Secure Sockets Layer (SSL). To WTLS

προορίζεται για χρήση με τα πρωτόκολλα δοσοληψιών του WAP και έχει

βελτιωθεί, ώστε να είναι κατάλληλο για χρήση σε τηλεπικοινωνιακά κανάλια

μικρού εύρους. Βρίσκεται ανάμεσα στα επίπεδα WTP και WDP και είναι

υπεύθυνο για την ασφάλεια του επιπέδου δοσοληψίας ανάμεσα σε ένα WAP

πελάτη και σε μια WAP πύλη ή proxy server.

Χαρακτηριστικά του WTLS

Το WTLS διαθέτει τα ακόλουθα χαρακτηριστικά:

• Ακεραιότητα δεδομένων (data integrity): λειτουργίες που εξασφαλίζουν ότι

τα δεδομένα που ανταλλάσσονται ανάμεσα σε ένα τερματικό και έναν

εξυπηρετητή εφαρμογών παραμένουν αμετάβλητα και μη κατεστραμμένα.

Επιτυγχάνεται με τους Κώδικες Αυθεντικότητας Μηνυμάτων (Message

Authentication Codes-MAC)

• Απομόνωση (privacy): λειτουργίες που διασφαλίζουν ότι η ανταλλαγή

δεδομένων ανάμεσα σε ένα τερματικό και έναν εξυπηρετητή εφαρμογών

είναι ιδιωτικά και δεν μπορούν να γίνουν καταληπτά από κανέναν

ενδιάμεσο που μπορεί να έχει παρέμβει στη ροή των δεδομένων. Αυτό

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

• Απόδειξη Αυθεντικότητας (Authentication): λειτουργίες που εξασφαλίζουν

την αυθεντικότητα του τερματικού και του εξυπηρετητή εφαρμογών και

επιτυγχάνεται με τη χρήση ψηφιακών πιστοποιητικών (digital certificates)

• Προστασία από άρνηση υπηρεσίας (denial-of-service protection):

λειτουργίες που ανιχνεύουν και απορρίπτουν δεδομένα που

42

επαναλαμβάνονται ή που δεν έχουν εξακριβωθεί με επιτυχία. To WTLS

αποτρέπει τις περισσότερες συνηθισμένες επιθέσεις άρνησης υπηρεσίας

από το να επιτύχουν και με τον τρόπο αυτό προστατεύει τα ανώτερα

επίπεδα του πρωτοκόλλου.

Η πιο σημαντική λειτουργία του WTLS είναι ότι διασφαλίζει τη μετάδοση

των δεδομένων από την παρέμβαση τρίτων και ότι εγγυάται το γεγονός ότι τα

δεδομένα είναι ιδιωτικά. Αυτό είναι πολύ σημαντικό για δοσοληψίες

ηλεκτρονικού εμπορίου. Επίσης, δίνεται η δυνατότητα να προσδιορίζεται ο

συντάκτης ενός μηνύματος, ώστε μη επιθυμητά μηνύματα να

απομακρύνονται.

Για να εγκατασταθεί μια ασφαλής σύνδεση, ανταλλάσσονται και ελέγχονται

για την αυθεντικότητά τους κλειδιά κατά τη διάρκεια των διαπραγματεύσεων

στη φάση της εγκατάστασης. Με αυτό τον τρόπο εξασφαλίζεται ότι και οι δυο

πλευρές επιβεβαιώνονται η μια στην άλλη και δεν μπορούν να αρνηθούν την

αποστολή δεδομένων. Μια ασφαλής σύνοδος μπορεί να ακυρωθεί

οποιαδήποτε στιγμή πριν ή κατά τη διάρκεια της συνόδου. Το WTLS μπορεί

να χρησιμοποιηθεί όποτε είναι απαραίτητο και λειτουργεί τόσο σε κατάσταση

με συνδέσεις όσο και χωρίς συνδέσεις. Ακόμα και λειτουργίες τηλεφωνίας

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

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

απενεργοποιούν τις λειτουργίες του WTLS κατά βούληση, ανάλογα με τις

απαιτήσεις για ασφάλεια και τα χαρακτηριστικά του δικτύου στο οποίο

βασίζονται.

Τμήματα του WTLS

Το επίπεδο ασφάλειας μπορεί να χωριστεί σε δυο υποεπίπεδα:

• Πρωτόκολλο Χειραψίας (Handshake Protocol)

• Πρωτόκολλο Εγγραφής (Record Protocol)

43

Το πρωτόκολλο χειραψίας είναι το ανώτερο υποεπίπεδο. Επιτρέπει

στους πελάτες και τους εξυπηρετητές να συμφωνούν για αλγόριθμους

κρυπτογράφησης και να ανταλλάσσουν τις απαραίτητες για την

κρυπτογράφηση παραμέτρους. Μπορεί, ακόμα, να επιβεβαιώσει ότι και τα

δυο μέρη έχουν υπολογίσει τις ίδιες παραμέτρους ασφάλειας και ότι η

χειραψία έγινε χωρίς να απειληθεί από κάποιο εισβολέα

Η χειραψία ξεκινά, όταν ο πελάτης στέλνει ένα μήνυμα ClientHello που

περιέχει την έκδοση του πρωτοκόλλου και άλλες πληροφορίες που

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

εξυπηρετητής απαντά με ένα μήνυμα ServerHello επιβεβαιώνοντας την

αίτηση του πελάτη. Ο εξυπηρετητής τώρα εκκινεί μια διαδικασία ανταλλαγής

πιστοποιητικών. Αν ο πελάτης (στο ClientHello μήνυμα) ζήτησε από τον

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

πιστοποιητικό του στον πελάτη. Ο εξυπηρετητής μπορεί επίσης να ζητήσει

από τον πελάτη να στείλει το δικό του πιστοποιητικό. Όταν αυτή η ανταλλαγή

πιστοποιητικών τελειώσει, ο εξυπηρετητής στέλνει ένα μήνυμα HelloDone

στον πελάτη, δείχνοντας ότι η φάση αυτή της χειραψίας με τα μηνύματα

χαιρετισμού έχει ολοκληρωθεί. Όταν ο πελάτης λάβει το ServerHello μήνυμα

στέλνει με τη σειρά του ένα μήνυμα τέλους στον εξυπηρετητή και αυτός

απαντά με ένα ίδιο μήνυμα. Τώρα η χειραψία έχει ολοκληρωθεί και τα δυο

μέρη μπορούν να στείλουν κρυπτογραφημένα δεδομένα ο ένας στον άλλο.

Το πρωτόκολλο εγγραφής είναι υπεύθυνο για την κρυπτογράφηση και

αποκρυπτογράφηση των μηνυμάτων. Αν ένα μήνυμα πρόκειται να μεταδοθεί,

το πρωτόκολλο εγγραφής το συμπιέζει, το κρυπτογραφεί και το στέλνει στα

χαμηλότερα επίπεδα για μετάδοση. Αντίθετα, αν ένα μήνυμα ληφθεί, το

αποκωδικοποιεί και το αποσυμπιέζει πριν να το στείλει στα ανώτερα επίπεδα.

Το μοντέλο του WAP PKI

Τα σενάρια για την ασφάλεια του WAP που παρουσιάστηκαν παραπάνω

εμπεριέχουν την πλήρη χρήση μιας Υποδομής Δημοσίου Κλειδιού (Public Key

Infrastructure – PKI) μέσο της οποίας οι πιστοποιήσεις μπορούν να

διαχειρίζονται και να είναι διαθέσιμες σε κάθε εμπλεκόμενο μέρος σε μια

44

τέτοια συναλλαγή. Η Υποδομή Δημοσίου Κλειδιού έχει την φροντίδα όλων των

εγγραφών των χρηστών και τις διαδικασίες επιβεβαίωσης και οι πιστοποιήσεις

είναι διαθέσιμες σε οποιονδήποτε τις ζητήσει μέσο ενός LDAP καταλόγου ή

μέσο HTTP.

Η Υποδομή Δημοσίου Κλειδιού για WAP (WPKI) είναι μια προτεινόμενη

(από το WAP Forum) προδιαγραφή, η οποία στοχεύει στον καθορισμό της

απαιτούμενης λειτουργικότητας για την διευθέτηση της καθορισμένης από το

WAP 1.2 λειτουργικότητας της ασφάλειας. Αυτό περιληπτικά φαίνεται

παρακάτω:

• Πιστοποιητικό Δημοσίου Κλειδιού της CA (Certificate Authority) για την

WTLS κλάση 2

• Πιστοποιητικό Δημοσίου Κλειδιού του Client για την WTLS κλάση 3

• Πιστοποιητικό Δημοσίου Κλειδιού του Client σε συνδυασμό με το

WMLScript signText

Η έννοια του WPKI βασίζεται γύρω από την ιδέα μιας ΡΚΙ δικτυακής πύλης,

η οποία παίζει τον κύριο ρόλο για την εγγραφή του χρήστη και την

πιστοποίησή του. Αν ένας χρήστης, ο οποίος δεν έχει εγγραφεί με ένα ΡΚΙ,

προσπαθήσει να συνδεθεί σε ένα παροχέα περιεχομένου (content server)

απαιτώντας ψηφιακές υπογραφές στις συναλλαγές του και/ ή ασφαλείς

επικοινωνίες, ο server συνιστά στον χρήστη να ακολουθήσει την ΡΚΙ πύλη

(και προμηθεύει τον χρήστη με το URL της πύλης, το CA name, κτλ). Η εικόνα

5 δείχνει μια διαδικασία ροής δεδομένων για την WTLS κλάση 3 του WPKI και

για μια επικοινωνία από άκρο σε άκρο ανάμεσα στον client και της PKI πύλης.

45

8. Secure SSL/TLSsession between WAPgateway and contentserver

7. Secure WTLS session between client and WAP gateway

6. Content serverretrieves certificates andrevocation information

5. PKI Portal creates& relays thecertificate location(URL) to the EE user

1. End user applies for certificate

PKI

(RA)CA

WAGateway

M- or Commerce

Server

2. RA approvescertificate requests,sends it to CA

3. CA issuescertificate

Director

4. CA posts certificatein the PKI Directory

CA PRIVATE KEY

SERVER PRIVATE KEY SERVER PK CERTIFICATE

CA ROOT PK USER PRIVATE KEY

End Entity

Εικόνα: Βασικά τεχνικά χαρακτηριστικά και ροή λειτουργίας του WPKI

Όπως φαίνεται στην εικόνα, το WPKI απαιτεί τα ίδια συστατικά τα οποία

χρησιμοποιούνται στο παραδοσιακό PKI:

• End-Entity Application (EE) – Κινούμενος χρήστης

• Υπηρεσία Εγγραφών (RA)

• Υπηρεσία Πιστοποίησης (CA)

• Κατάλογος PKI

Παρ’όλα αυτά, στο WPKI τα EE και RA εφαρμόζονται κάπως διαφορετικά.

Το ΕΕ στο WPKI εφαρμόζεται σαν βελτιωμένο πρόγραμμα το οποίο τρέχει

στην συσκευή WAP. Βασίζεται στο WMLSCrypt API για υπηρεσίες κλειδιού

και λειτουργίες κρυπτογράφησης και είναι υπεύθυνο για τις ίδιες λειτουργίες

όπως και το ΕΕ στο παραδοσιακό ΡΚΙ συμπεριλαμβανομένου και ότι:

• παράγει, αποθηκεύει και επιτρέπει την πρόσβαση στο δημόσιο

κλειδί ενός χρήστη

46

• ολοκληρώνει, υπογράφει ψηφιακά και υποβάλλει τις αιτήσεις

πιστοποίησης για πρώτη φορά

• ολοκληρώνει, υπογράφει ψηφιακά και υποβάλλει τις αιτήσεις

ανανέωσης της πιστοποίησης

• ολοκληρώνει, υπογράφει ψηφιακά και υποβάλλει τις αιτήσεις

ανάκλησης των πιστοποιήσεων

• αναζητά και επαναφέρει τις πιστοποιήσεις και τις πληροφορίες

ανάκλησης

• αξιολογεί τις πιστοποιήσεις και διαβάζει τα περιεχόμενά τους

• παράγει και επιβεβαιώνει τις ψηφιακές υπογραφές

Η ΡΚΙ πύλη είναι ένας δικτυακός server, όπως και η WAP πύλη μπορεί να

λειτουργεί λογικά σαν το RA και είναι υπεύθυνος για τη μετάφραση των

αιτήσεων που γίνονται από τον WAP client στο RA και στο CA στο PKI. Η ΡΚΙ

πύλη τυπικά ενσωματώνει τις συναρτήσεις RA και αλληλεπιδρά με τις WAP

συσκευές στο ασύρματο δίκτυο και με το CA στο ενσύρματο δίκτυο.

Το WAP PKI το οποίο παρουσιάζεται στην εικόνα 5 καλύπτει την

πιστοποίηση της κλάσης 3 του WTLS. Η ίδια σχεδίαση μπορούσε να

χρησιμοποιηθεί για το signText. Η μόνη διαφορά στη δεύτερη περίπτωση είναι

ότι το signText παρέχει ένα μηχανισμό για τη συσκευή του client ώστε να

δημιουργεί ψηφιακή υπογραφή κειμένου χρησιμοποιώντας το WMLScript.

Ασφάλεια στο M-commerce

Πέρα από την ασφάλεια του ίδιου του WAP, η θέση της πύλης WAP στο

δίκτυο είναι αρκετά συσχετισμένη με τα χαρακτηριστικά ασφαλείας των

συναλλαγών που λαμβάνουν χώρα.

• Πύλη WAPστον παροχέα υπηρεσιών κινητών επικοινωνιών

Όπως αναφέρθηκε πρωτύτερα το πιο συχνά χρησιμοποιούμενο σχήμα

είναι ότι η πύλη WAP gateway εγκαθίσταται στον παροχέα υπηρεσιών

κινητών επικοινωνιών, έτσι εκτελεί μια λειτουργία μεσάζοντος στην ασφάλεια,

47

συνδέοντας δηλαδή ένα WAP/WTLS περιβάλλον στην ασύρματη πλευρά και

ένα HTTP/SSL περιβάλλον στην ενσύρματη πλευρά. Αρχικά τα

κωδικοποιημένα δεδομένα μεταφέρονται πάνω από το WTLS από το κινητό

τερματικό στην πύλη WAP. Εκεί γίνεται αποκρυπτογράφηση όλων των

δεδομένων στη μνήμη του server και ξανά κρυπτογράφηση, με σκοπό να

μεταδοθούν πάνω από το SSL στο μηχάνημα του παροχέα περιεχομένου.

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

κάποιος επιτείθετω στην πύλη WAP θα μπορούσε να προσβάλει την

ασφάλεια όλης της συναλλαγής. Επιπλέον, ένας παροχέας περιεχομένου

(όπως μια τράπεζα) πιθανότατα θα ζητούσε από τους πελάτες του να

πιστοποιήσουν τους εαυτούς τους, και στις περισσότερες περιπτώσεις η

πιστοποίηση τρίτων μερών, όπως ο παροχέας υπηρεσιών κινητών

επικοινωνιών ο οποίος λειτουργεί στην πύλη WAP, δεν είναι επαρκής. Ως εκ

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

αποδεκτή λύση.

Χωρίς να αλλάξουμε τη θέση της πύλης WAP, το πρόβλημα θα μπορούσε

να λυθεί στο επίπεδο εφαρμογών. Αντί να κρυπτογραφείται ο δίαυλος μέσα

από τον οποίο τα πακέτα δεδομένων περνάν, θα ήταν δυνατό να

κρυπτογραφείται καθένα από τα πακέτα. Η κρυπτογράφηση στο επίπεδο

εφαρμογών σημαίνει επιπρόσθετες WMLScript λειτουργίες, κάτι που δεν

υποστηρίζεται τώρα. Η μόνη λειτουργία η οποία παρουσιάστηκε από το WAP

Forum είναι το SignText στην εκδοχή 1.2 των προδιαγραφών WAP.

• Πύλη WAP στον παροχέα περιεχομένου

Η πύλη WAP μπορεί επίσης να εγκατασταθεί στο οίκημα του παροχέα

περιεχομένου (για παράδειγμα μια τράπεζα). Το αδύναμο σημείο που

αναφέρθηκε προηγουμένως δεν υφίσταται σε αυτή την εκδοχή γιατί το WTLS

τμήμα τοποθετημένο κατευθείαν μεταξύ του κινητού τερματικού και της πύλης

λειτουργώντας μέσα στο ασφαλές δίκτυο του παροχέα περιεχομένου. Αυτό

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

48

προσθέτει επιπλέον κόστος στον παροχέα περιεχομένου όπως η αγορά και η

εγκατάσταση της πύλης WAP και του αναγκαίου modem pool και του RAS

server.

Εκτός από το πρόβλημα κόστους για τον παροχέα περιεχομένου, ο κινητός

χρήστης πρέπει να είναι ικανός να διαλέγει ανάμεσα σε διαφορετικές

σχεδιάσεις στο τηλέφωνο κάθε φορά που θα θέλει να χρησιμοποιήσει

διαφορετική πύλη.

Μια ακόμα καλύτερη προσέγγιση στην από άκρο σε άκρο ασφάλεια μπορεί

να επιτευχθεί θέτοντας σε εφαρμογή την Ε2Ε προδιαγραφή ασφαλείας για το

επίπεδο μεταφοράς WAP. Σε αυτή την προδιαγραφή ο χρήστης αρχικά

επικοινωνεί με την default πύλη, και μετά το πρωτόκολλο αναλαμβάνει όλες

τις διαδικασίες αλλαγής της κατεύθυνσης έτσι ώστε να συνδεθεί ασφαλώς

στην πύλη WAP του παροχέα περιεχομένου. Αυτό φαίνεται καλύτερα στην

επόμενη εικόνα 6:

ContentProvide

WAPGatewayWTLS

Certificate

X.509certificate

(This is located most probably atthe Network Operator)

DefaultWAPGatewayWTLS

Certificate

WirelessPort Proxy

NetworkAccess Point

UDP

UDP

PSTN

WDP

Εικόνα: Εφαρμογή προδιαγραφών ασφάλειας από άκρο σε άκρο στο επίπεδο μετάδοσης

Όπως φαίνεται, οι προδιαγραφές προσφέρουν τρεις τρόπους σύνδεσης του

τερματικού στην πύλη WAP του παροχέα περιεχομένου, που κάθε φορά

εξαρτώνται από το πρωτόκολλο datagram που υποστηρίζουν. Οι clients που

49

χρησιμοποιούν UDP επικοινωνούν κατ’ευθείαν μέσο UDP. Οι clients που

χρησιμοποιούν WDP επικοινωνούν μέσο του Wireless Port Proxy, το οποίο

λειτουργεί σαν υπηρεσία πύλης μέσο του WDP και του UDP. Ή ένας client

που χρησιμοποιεί ένα κύκλωμα δεδομένων (circuit data) εγκαθιστά ένα

κύκλωμα με το Network Access Point (π.χ. το modem pool του παροχέα

περιεχομένου). Και στις τρεις περιπτώσεις το τμήμα WTLS το οποίο

εγκαθίσταται κατόπιν είναι ανάμεσα στο τερματικό και στην πύλη WAP, και

έτσι από άκρο σε άκρο.

WAP PKI εργαλεία και υπηρεσίες

Αφού η ανάπτυξη του WAP και του PKI διαμορφώνεται σαν ένα ζωτικό

ζήτημα, οι περισσότερες εταιρίες που προσφέρουν PKI εφαρμογές

προσφέρουν και υπηρεσίες ασφαλείας που σχετίζονται με το WAP για να

καλύψουν τις σχετικές ανάγκες. Ειδικότερα οι εφαρμογές WAP μέχρι τώρα

αφορούσαν οικονομικούς/ τραπεζικούς τομείς. Παρ’όλα αυτά καμία ειδική

λύση PKI WAP για αυτούς τους τομείς δεν έχει ευρέως διαδοθεί και δεν έχει

γίνει αποδεκτή.

Ο παρακάτω πίνακας παρουσιάζει μια λίστα με κάποια από τα εμπορικά

προϊόντα και εργαλεία που σχετίζονται με το WAP/PKI, τα οποία βρέθηκαν

στο διαδίκτυο από διαφορετικούς προμηθευτές (vendors) (μια λεπτομερής

περιγραφή και/ ή σύγκριση μεταξύ αυτών των προϊόντων είναι εκτός των

σκοπών του κειμένου). Οι πληροφορίες σε αυτή τη λίστα συγκεντρώθηκαν

από πηγές στο διαδίκτυο και δεν καλύπτουν αναγκαστικά όλο το εύρος των

διαθέσιμων προϊόντων συσχετισμένων με το PKI/WAP. Είναι όμως ενδεικτικές

της γενικότερης κατάστασης της αγοράς στο συγκεκριμένο πεδίο. Ειδικότερα,

φαίνεται ότι οι περισσότερες εφαρμογές ασφαλείας που σχετίζονται με το

WAP μέχρι τώρα βασίζονταν στο WAP 1.1, παρέχοντας στην πραγματικότητα

μια υλοποίηση του WTLS. Έτσι, οι αναβαθμισμένες λύσεις του WAP PKI

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

βασιζόμενες πάνω στη συνεργασία ανάμεσα στους παροχείς κινητού

διαδικτύου και στους παροχείς υπηρεσιών ασφαλείας. Η ολοκλήρωση του

50

WAP PKI με άλλες εξειδικευμένες υπηρεσίες και εργαλεία σε διάφορους

τομείς (όπως οι κάρτες υγείας για τον τομέα της υγείας) είναι ένα πολύ

σημαντικό θέμα για τις εφαρμογές του WAP.

COMPANY PRODUCT

Baltimore

Technologies

Telepathy WST: a software development kit allowing application

developers to create secure encrypted sessions between online

networked applications - contains an implementation of Wireless

Transport Layer Security (WTLS) 1.1

Certicom Trustpoint PKI Portal: extends network/application security and

PKI to wireless devices

Columbitech Columbitech WAP Connector: a corporate WAP server product

for secure access to web server content with WAP devices.

Diversinet Passport Certificate Server Security: software for wireless e-

commerce applications (digital certificate software for WTLS 1.1)

enCommerce,

Inc

getAccess Mobile Server: Web access via wireless devices,

such as mobile telephones and personal digital assistants (PDAs).

Entrust

Technologies

Entrust/PKI: for WAP server and client certificates

(Entrust/Toolkit)

F-Secure F-Secure Anti-Virus for WAP Gateways: protection against

malicious code for WAP enabled devices

mi4e ThunderWAP WTLS Security: end-to-end connection from

ThunderWAP™ enabled web server to WAP clients.

Sonera

SmartTrust

Sonera SmartTrust: embed PKI security functionality into the

SIM card of a mobile phone.

Πίνακας: Εμπορικά εργαλεία σχετικά με το WAP PKI

Πλεονεκτήματα

Στην παράγραφο αυτή θα παρουσιαστούν ορισμένα από τα πλεονεκτήματα

του WAP

51

To WAP είναι ήδη δημοφιλές στους κατασκευαστές:

Από την πλευρά των κατασκευαστών το πιο σημαντικό πλεονέκτημα του

WAP είναι ότι δημιουργεί μια πραγματικά παγκόσμια αγορά με την έννοια ότι

οι συσκευές που το υποστηρίζουν μπορούν να βασίζονται σε οποιοδήποτε

δίκτυο. Για παράδειγμα, ενώ στην Ευρώπη χρησιμοποιούνται GSM συσκευές

με WAP φυλλομετρητές, στις Η.Π.Α. και στην Κορέα τα WAP τηλέφωνα

τρέχουν πάνω από CDMA δίκτυα και το WAP μπορεί να δουλέψει ακόμα και

με ορισμένα από τα λιγότερο γνωστά κινητά δίκτυα, όπως το TDMA στις

Η.Π.Α. Ακόμα καλύτερα, το WAP δε χρειάζεται να περιορισθεί μόνο σε

ασύρματα τηλέφωνα, αλλά μπορεί για παράδειγμα να ενσωματωθεί και σε

τερματικά για αφοσιωμένα δίκτυα δεδομένων. Τέλος, είναι αρκετά ευέλικτο,

ώστε να μπορεί να τοποθετηθεί ένας WAP φυλλομετρητής σε ένα φορητό

υπολογιστή και μετά να γίνει η σύνδεση με το κινητό δίκτυο με ένα κοινό

κινητό τηλέφωνο.

Είναι ανεξάρτητο από το δίκτυο και το λειτουργικό σύστημα:

Το WAP λειτουργεί πάνω σε υπάρχοντα δίκτυα, όπως τα CDPD, CDMA

(IS 95 ή IS-707), GSM (900, 1800 και 1900 MHz), PDC, PHS, TDMA/D-AMPS

(IS-136), FLEX, ReFLEX, (τα δυο τελευταία είναι paging standards από τη

Motorola), iDEN, TETRA, DECT, DataTAC, Mobitex (της Ericsson). Επίσης

έχει προβλεφθεί να μπορεί να λειτουργήσει και πάνω σε μελλοντικά δίκτυα

όπως το GPRS. Επιπλέον, οι φυλλομετρητές WAP μπορούν να εδραιωθούν

πάνω σε οποιοδήποτε λειτουργικό σύστημα συμπεριλαμβανομένων των

PalmOS, EPOC, Windows CE, FLEXOS, OS/9, JavaOS και άλλα.

Ακριβής χωρικός εντοπισμός:

Το κινητό δίκτυο γνωρίζει ακριβώς ποια είναι η θέση του χρήστη. Δεν έχει

βέβαια το είδος της ακρίβειας του GPS, αλλά γενικά λειτουργεί αρκετά

ικανοποιητικά. Με την ανάπτυξη τεχνολογιών ικανών να χρησιμοποιήσουν

ραδιοφωνικά σήματα μπορούν να επιτευχθούν ακόμα εντυπωσιακότερα

αποτελέσματα. Έτσι αρχίζει το p-commerce (position based commerce). Με

τη συναίνεση του χρήστη, είναι δυνατόν ο περίπατός του για ψώνια στην

52

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

για τις τιμές, τις προσφορές και την ποικιλία των παρακείμενων

καταστημάτων, ενώ ταυτόχρονα θα του δείχνει σε ποιο σημείο της πόλης

βρίσκονται οι φίλοι του.

Παροχή υπηρεσιών και πληροφοριών για τον πολύ κόσμο:

Το WAP είναι ουσιαστικά το Internet χωρίς τα εντυπωσιακά στοιχεία του.

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

πληροφοριών στις μάζες, αν ανταγωνιστεί όλα τα υπόλοιπα μέσα που κάνουν

την ίδια δουλειά (δηλαδή οτιδήποτε μπορεί να μεταφέρει πληροφορίες ακόμα

και μηνύματα στο ευρύ κοινό). Ο ρόλος του WAP θα είναι ίσως μια κινητή

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

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

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

καταστάσεις (πυρκαγιές, ακραίες καιρικές συνθήκες, αλλαγή τιμολογίων και

υπηρεσιών), προγράμματα ειδικών δημοψηφισμάτων και

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

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

την επόμενη γενιά κινητών τέλος: η τακτοποίηση των λογαριασμών, η αγορά

εισιτηρίων, το διάβασμα του σώματος των εφημερίδων, τα παιχνίδια στο

Διαδίκτυο θα γίνουν πραγματικότητα, όπως και το ανοιχτό video conferencing

με το κινητό, η ζωντανή σύνδεση με κάμερες σε αίθουσες πανεπιστημίων και

διαλέξεων.

Μειονεκτήματα - Περιορισμοί

Παρακάτω παρουσιάζονται ορισμένα από τα μειονεκτήματα του WAP.

Μικρή ταχύτητα Ο κύριος λόγος για τον οποίο χρησιμοποιείται το WAP

και όχι το HTML είναι το πολύ μικρό εύρος ζώνης. Με άλλα λόγια τα σημερινά

κινητά δίκτυα είναι υπερβολικά αργά, για να υποστηρίξουν σύνθετες

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

σύνδεσης και μικρή προβλεψιμότητα. Ας πάρουμε για παράδειγμα τα GSM

53

δίκτυα. Τα περισσότερα υπάρχοντα δίκτυα περιορίζονται σε ταχύτητες 9.6

Κbit/s, οι οποίες είναι περίπου τέσσερις φορές χαμηλότερες από την ταχύτητα

ενός συνηθισμένου modem και έξι φορές χαμηλότερες από μια γραμμή ISDN.

Όπως έχει αποδειχθεί από τη Nokia, είναι δυνατές ταχύτητες μέχρι 14.4 Κbit/s

πάνω από τα υπάρχοντα δίκτυα GSM. Υπάρχουν δυο τεχνολογίες που

στοχεύουν στο να αντιμετωπίσουν αυτό το πρόβλημα: HSCSD (High Speed

Circuit Switched Data) και GPRS (General Packet Radio Services). Οι

κατασκευαστές έχουν ένα ισχυρό κίνητρο να αυξήσουν τις ταχύτητες πολύ

περισσότερο με τη βοήθεια του προτύπου IMT-2000 (International Mobile

Telecommunications 2000) της ITU. Αυτό το πρότυπο απαιτεί 144 Kbit/s για

μετακίνηση, 384Kbit/s για χαμηλές ταχύτητες και 2Mbit/s για ακινησία.

Φυσικοί περιορισμοί των κινητών συσκευών Η εξέλιξη των κινητών

συσκευών οδηγεί σε όλο και πιο μικρές και ελαφριές συσκευές. Ένα από τα

προβλήματα που δημιουργεί αυτό είναι το μέγεθος της οθόνης. Η LCD οθόνη

του κινητού τηλεφώνου δεν μπορεί εξ ορισμού να δίνει την ίδια ποιότητα

εικόνας με μια έγχρωμη 17 οθόνη υπολογιστή. Ένα άλλο πρόβλημα είναι το

πληκτρολόγιο. Ακόμα και αν η συσκευή έχει πρότυπο πληκτρολόγιο, τα

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

κινητών τηλεφώνων έχουν βρει πρακτικές λύσεις σε αυτά τα προβλήματα,

όπως το Navi roller bar, το οποίο λειτουργεί, όπως το ποντίκι. Επίσης, μια

άλλη σημαντική ευκολία είναι η Predictive Text ή Τ9, με την οποία γίνεται

«έξυπνη» πρόβλεψη της λέξης που εισάγεται από το πληκτρολόγιο. Τέλος,

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

να πληκτρολογεί, αγγίζοντας τα πλήκτρα του πληκτρολογίου που έχει

αναπαρασταθεί στην οθόνη με ένα ειδικό στυλό.

Περιορισμοί του υλικού των κινητών συσκευών Οι κινητές συσκευές δε

διαθέτουν επαρκείς προδιαγραφές υλικού για πλοήγηση στο διαδίκτυο και

καθίστανται, έτσι, ανεπαρκή υποκατάστατα των προσωπικών υπολογιστών.

Οι κατασκευαστές ασχολήθηκαν κυρίως με την κατασκευή μικρότερων

συσκευών και την επέκταση του χρόνου ζωής της μπαταρίας. Κατά συνέπεια,

οι κινητές συσκευές δεν μπορούν να υποστηρίξουν ακόμα και απλούς

επεξεργαστές ή δεν έχουν το χώρο να κρατήσουν σημαντικές ποσότητες

54

μνήμης RAM. Επιπλέον και η ενέργειά τους (μπαταρίες) είναι ακόμα

περιορισμένη. Αυτοί οι παράγοντες εμποδίζουν τις κινητές συσκευές να

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

Έλλειψη Ομοιομορφίας στην ασύρματη σηματοδοσία Στη Βόρεια

Αμερική δεν υπάρχει μια ομοιόμορφη τεχνολογία σηματοδοσίας για τις

ασύρματες επικοινωνίες. To Code Division Multiple Access (CDMA) και το

Time Division Multiple Access (TDMA) συναγωνίζονται για την αποδοχή τους

ως του μοναδικού προτύπου της Βόρειας Αμερικής. Αυτές οι τεχνολογίες

απαιτούν η καθεμιά μια ειδικά διαμορφωμένη έκδοση του WAP. Αυτός είναι

και ο λόγος για τον οποίο δεν υπάρχει μια πρότυπη WAP γλώσσα, ώστε οι

κατασκευαστές να μπορούν να δημιουργήσουν εφαρμογές ανεξάρτητες από

τη συμβατότητα με την ασύρματη σηματοδοσία, πράγμα που παίζει αρνητικό

ρόλο στην παραπέρα ανάπτυξη του WAP.

Οι σχεδιαστές ιστοσελίδων δε συμπαθούν τη δημιουργία WAP ιστοσελίδων Το WAP είναι ένα πρότυπο στο οποίο οι πληροφορίες πρέπει

να τοποθετούνται σε τμήματα, στα οποία μπορεί να γίνει επεξεργασία με τις

περιορισμένες δυνατότητες μιας WAP συσκευής. Οι σχεδιαστές των WAP

αναγκάζονται να βελτιστοποιούν κάθε υπηρεσία για συγκεκριμένες συσκευές

και τους περιορισμούς τους. Όσο περισσότερους περιορισμούς έχει η

συσκευή, τόσο περισσότερο χρόνο πρέπει να αφιερώσει ο σχεδιαστής, για να

βελτιστοποιήσει τα δεδομένα του δικτύου. Η ανάπτυξη εφαρμογών για το

WAP κοστίζει περισσότερο από την αντίστοιχη εργασία για τους συμβατικούς

προσωπικούς υπολογιστές. Το WAP επαναφέρει το πρόβλημα που ξεπέρασε

με επιτυχία το διαδίκτυο: τη διατήρηση πολλαπλών εκδοχών του κώδικα μιας

ιστοσελίδας.

Οι κατασκευαστές διαφωνούν με τα περιοριστικά περιβάλλοντα εφαρμογών Οι κατασκευαστές εφαρμογών για το WAP συναντούν

προβλήματα, εξαιτίας των περιορισμών που θέτει το WAP. Αφού η τεχνολογία

του φυλλομετρητή των κινητών συσκευών εξαρτάται από συγκεκριμένο υλικό

και λειτουργικό σύστημα, η WAP εφαρμογή που αναπτύσσεται μπορεί να

λειτουργήσει μόνο για συγκεκριμένες συσκευές. Άρα οι WAP εφαρμογές είναι

περιορισμένες στις συγκεκριμένες συσκευές για τις οποίες αναπτύχθηκαν και

55

δεν μπορούν να διαδοθούν παγκόσμια, δηλαδή ενώ απαιτούν σημαντικούς

πόρους, το αντιστάθμισμα είναι μικρό.

Οι περιορισμοί πρόσβασης του WAP σε σχέση με το PC είναι οι

ακόλουθοι:

Ποιότητα οθόνης: Όσο τα κινητά τηλέφωνα είναι μικρά ελαφρά, η οθόνη

θα παραμένει μικρή. Προφανώς ο χρήστης δεν μπορεί να διαβάσει την ίδια

ποσότητα πληροφορίας που διαβάζει στην οθόνη ενός προσωπικού

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

Κάποιος μπορεί για παράδειγμα να στείλει φωτογραφίες μέσο WAP, αλλά η

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

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

Ταχύτητα πρόσβασης: Οι ερευνητές των μεγάλων τηλεπικοινωνιακών

οργανισμών εργάζονται πυρετωδώς για μία καλύτερη και γρηγορότερη

πρόσβαση. Νέες δικτυακές τεχνολογίες λειτουργούν ήδη πειραματικά (HSCD-

high speed circuit switch data και GPRS-General Packet Radio Service) που

θα προσφέρουν πολύ μεγαλύτερες ταχύτητες.

Πληκτρολόγηση δεδομένων : Είναι σίγουρα πολύ δυσκολότερο να

πληκτρολογήσει κάποιος το ηλεκτρονικό του μήνυμα σε κινητό τηλέφωνο από

ότι σε ένα κανονικό πληκτρολόγιο. Ήδη γίνονται σημαντικές έρευνες για τη

βελτίωση των πληκτρολογίων, όπως και για φωνητική αναγνώριση.

Περιορισμός στη μνήμη: Οι συσκευές WAP που κυκλοφορούν σήμερα

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

εξάπλωση της χρήσης των συσκευών αυτών θα οδηγήσει τους

κατασκευαστές σε σημαντική αναβάθμιση ώστε να μπορεί το τηλέφωνο να

διατηρεί σημαντικό αριθμό πληροφοριών.

Εφαρμογές του WAP σήμερα

Οι υπηρεσίες του WAP βρίσκουν εφαρμογή σε αρκετούς τομείς της

σύγχρονης ζωής και αναφέρονται παρακάτω:

56

Υπηρεσίες πληροφοριών: ειδήσεις, πρόβλεψη καιρού, ωροσκόπια,

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

on-line δραστηριότητες, π.χ. κλείσιμο δωματίου ξενοδοχείου

Κινητό ηλεκτρονικό εμπόριο: χρήση του κινητού όπως ένα PC για

αγορές από το δίκτυο

Επιχειρησιακή επικοινωνία: πρόσβαση στο intranet μιας επιχείρησης,

αλλαγή των σχεδίων παράδοσης, ανακοίνωση ολοκλήρωσης εργασίας,

επαφή διαφορετικών τμημάτων μίας εταιρείας.

Ηλεκτρονικό ταχυδρομείο: χρήση του ηλεκτρονικού ταχυδρομείου και του

φωνητικού ταχυδρομείου, αποστολή συγχρονισμένων multiple e-mail

Προσωπική διαχείριση πληροφοριών: υπηρεσίες όπως η διαχείριση

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

των προσωπικών πληροφοριών

Οικονομικές υπηρεσίες: mobile τραπεζικές εργασίες και mobile

υπηρεσίες ηλεκτρονικού εμπορίου, αντίγραφα κινήσεως τραπεζικών

λογαριασμών, μεταφορές χρηματικών κεφαλαίων, ανταλλαγή μετοχών

Location-smart συσκευές: περιλαμβάνουν χαρτογράφηση, πληροφορίες

κενών θέσεων οχημάτων για parking, εκπτώσεις εμπορικών καταστημάτων

και προτάσεις για διασκέδαση

M-billing: ειδοποίηση, παρουσίαση και πληρωμή λογαριασμών

M-care: υπηρεσίες πελατών, κατάσταση πληρωμής

Διασκέδαση: παιχνίδια, τυχερά παιχνίδια

Συναλλαγές που απαιτούν υψηλή ασφάλεια εκτελούνται με WAP :

• Τραπεζικές (Citicorp, Deutsche, Allied Irish Bank, Schwab)

• Οικονομικές (Abbey National and Halifax Bank mortgages online)

• Εμπορικές (Amazon.com, MySimon)

57

Ενδεικτικά παραδείγματα χρήσης του WAP περιλαμβάνονται στον

παρακάτω πίνακα

Επιχείρηση/ χώρα Παραδείγματα υπηρεσιών

France Telecom Πληροφορίες για κινηματογράφο, τιμές μετοχών και μερικές τραπεζικές υπηρεσίες

KPN Telecom, The Netherlands Πληροφορίες για ταινίες, πληροφορίες για ξενοδοχεία και ειδήσεις

Omnitel, Italy Ειδήσεις , πληροφορίες για πτήσεις, πληροφορίες για τα λαχεία και καταλόγους ταινιών

Optus, Australia Τιμές μετοχών, ειδήσεις, καιρικές προβλέψεις και e-mail

Orange, UK Πληροφορίες για κινηματογράφο, last minute offers (via lastminute.com), news and business directories

SmarTone, Hong Kong Ειδήσεις, e-mail, SmarTone WAP portal, μετάφραση και directories

Sonera, Finland Υπηρεσίες πληροφοριών, e-mail, directories και οικονομικά δεδομένα

Sprint, US Ειδήσεις, τιμές μετοχών, χαρτογράφηση, καιρικές προβλέψεις, directories και e-mail

Telefonica Moviles, Spain Ειδήσεις, ενημέρωση για την κυκλοφορία στους δρόμους, τραπεζικές συναλλαγές, directories and e-mail

Πίνακας: Παραδείγματα χρήσης του WAP

2.2 WAP 2.0

Η τεχνολογία WAP τυποποίησε το mobile browsing με την εισαγωγή του

WAP 1.Χ στο τέλος του 1990. Εκείνη την περίοδο, στην αγορά είχε μεγάλη

επιτυχία η χρήση των SMS μηνυμάτων σε ασπρόμαυρες οθόνες με

αποτέλεσμα να υπάρχουν υψηλές προσδοκίες για μια παρόμοια επιτυχία στο

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

WAP 1.Χ με τις δυνατότητες που προσφέρει το Web. Με μια μετάδοση

στοιχείων σε 9600 BPS και σε ασπρόμαυρη οθόνη, ήταν δύσκολο το WAP

1.Χ να σταθεί σε αυτή την σύγκριση. Εντούτοις, η ανάγκη για το mobile

browsing παραμένει. Το mobile browsing γίνετε μια από τις πιο σημαντικές

58

τηλεφωνικές εφαρμογές καθώς γίνετε ένας τρόπος εξερεύνησης web

περιεχομένου, ενημέρωσης και διασκέδασης.

Η κινητή τηλεφωνία υιοθετεί πρόσφατα το WAP 2.0 ως μια σημαντική

εξέλιξη για το κινητό ξεφύλλισμα επόμενης γενεάς. Η νέα τεχνολογία

χρησιμοποιεί XHTML και MP/WCSS. Οι πληροφορίες που παρουσιάζονται σε

XHTML σε μια κανονική ιστοσελίδα μπορούν να παρουσιαστούν σε

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

WAP 2.0, χωρίς μετάφραση σε άλλη γλώσσα ή πρωτόκολλο επικοινωνίας.

Το WAP 2.0 περιλαμβάνει τις πρώτες υπηρεσίες μηνύματος πολυμέσων

(MMS), επιτρέποντας στους χρήστες να στέλνουν μηνύματα πολυμέσων με τη

δυνατότητα να συνδυαστούν ήχοι και εικόνες με το κείμενο. Ενσωματώνει

επίσης μια εξελιγμένη έκδοση του WAP Push, που είναι ένα σύστημα

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

όπως για μια δημοπρασία ή για μια τιμή αποθεμάτων όταν φθάνει σε ένα

ορισμένο επίπεδο.

Σχήμα: Η εξέλιξη του Mobile Browsing

Αρχιτεκτονική του WAP 2.0

Με την νέα τεχνολογία WAP 2.0 η γλώσσα ανάπτυξης εξελίσσεται από

WML σε XHTML/WCSS και το πρωτόκολλο επικοινωνίας από WAP σε

wTCP/IP. Τα δυο αυτά επίπεδα μπορούν να εξελιχθούν ανεξάρτητα.

59

Σχήμα: Επίπεδα περιεχομένου και επικοινωνίας

Το XHTML MP και WCSS δίνουν τις προδιαγραφές ανάπτυξης εφαρμογών

για την κινητή τηλεφωνία με δυνατότητα χρήσης έγχρωμων γραφικών και

πολύπλοκου σχεδιασμού περιεχομένου. Διπλού τύπου browsers κινητών

είναι αναγκαίοι για να εξασφαλίσουν την παρουσίαση περιεχομένου σε

περίπτωση που είναι είτε αναπτυγμένο με WML είτε με την νέα τεχνολογία

XHTML/WCSS. Σε περίπτωση που το κινητό τηλέφωνο δεν έχει αυτή την

δυνατότητα τότε το WAP gateway θα πρέπει να είναι σε θέση να χειριστεί την

μετατροπή.

Σχήμα: Μετατροπή περιεχομένου μέσο Nokia WAP gateway

60

Στο transport layer όπως περνάει η νέα τεχνολογία κινητών από WAP σε

wTCP/IP βελτιώνεται η αποδοτικότητα και οι ταχύτητες μεταφοράς μεγάλων

αρχείων πολυμέσων καθώς επίσης παρέχεται ένα επίπεδο ασφάλειας

συμβατό με αυτό του TCP/IP συμπεριλαμβάνοντας συγχρόνως νέες

παραμέτρους όπου βελτιώνουν την απόδοση πληροφορίας στις ασύρματες

συνδέσεις.

Σχήμα: Νέα Αρχιτεκτονική

Στόχοι της Νέας Τεχνολογίας

Ένας από τους στόχους που επιτεύχθηκε με το WAP 2.0 είναι η

υποστήριξη τυποποιημένων πρωτοκόλλων όπως το IP, TCP και HTTP. Με

την προσθήκη αυτών των πρωτοκόλλων και προτύπων Διαδικτύου και την

παροχή των διαλειτουργικών βελτιστοποιήσεων κατάλληλων στο ασύρματο

περιβάλλον τηλεπικοινωνιών, οι προδιαγραφές WAP 2.0 παρέχουν ένα

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

υπάρχουσες τεχνολογίες του Διαδικτύου.

61

Σχήμα: Παρουσίαση ίδιου XHTML MP περιεχομένου σε κινητό και Διαδίκτυο.

Με την βελτίωση του WAP και επιτρέποντας τυποποιημένες εφαρμογές και

υπηρεσίες ήρθε και η ανάπτυξη ασύρματων συσκευών και επικοινωνίας από

τους φορείς τηλεπικοινωνίας με την εισαγωγή τεχνολογιών υψηλής ταχύτητας

GPRS και κινητών 3ης γενιάς.

Το WAP 2.0 επιτρέπει την χρήση ασύρματων συσκευών τελευταίας

τεχνολογίας με χαρακτηριστικά όπως μικρότερες οθόνες, πλοήγηση

περιεχομένου οθόνης με ένα δάκτυλο και αλλά όπου προκαλούν ακόμα και το

παραδοσιακό τρόπο χρήσης του Διαδικτύου.

Με την νέα τεχνολογία ελαχιστοποιείται η χρήση επεξεργαστικής δύναμης

των συσκευών και βελτιώνεται η χρήση του δικτύου με αποτέλεσμα να

μειώνονται οι δαπάνες και να μεγιστοποιείται η απόδοση.

Τέλος το WAP 2.0 ενσωματώνει την ευελιξία, παρέχοντας μια ποικιλία

σχεδιασμού User Interface στους κατασκευαστές δίνοντας την δυνατότητα

διαφοροποίησης σύμφωνα με την μορφή της συσκευής και τις απαιτήσεις της

αγοράς.

WAP 2.0 Νέες και Προηγμένες Υπηρεσίες

Εκτός από τις αλλαγές στο περιβάλλον εφαρμογών και την αύξηση στην

ικανότητα του micro-browser, το WAP 2.0 επίσης υποστηρίζει άλλα

62

χαρακτηριστικά γνωρίσματα για να βελτιώσει την εμπειρία χρηστών. Αυτά τα

χαρακτηριστικά γνωρίσματα επεκτείνουν τις ικανότητες των ασύρματων

συσκευών και βελτιώνουν τη δυνατότητα να παραδοθούν οι χρήσιμες

εφαρμογές και οι υπηρεσίες. Μερικά από αυτά τα πρόσθετα χαρακτηριστικά

γνωρίσματα του WAP 2.0 είναι:

WAP Push - Αυτή η υπηρεσία επιτρέπει στο περιεχόμενο να σταλεί ή να

προωθηθεί στις συσκευές μέσο server-based εφαρμογών και Push Proxy. Η

λειτουργία Push (ώθησης) είναι ιδιαίτερα σχετική με τις σε πραγματικό χρόνο

εφαρμογές όπως το μήνυμα, αναπροσαρμογές τιμών του χρηματιστηρίου και

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

ώθησης, αυτοί οι τύποι εφαρμογών θα απαιτούσαν τις συσκευές να

χρησιμοποιήσουν Poll εφαρμογές από τους κεντρικούς υπολογιστές για να

πάρουν νέα πληροφορία. Στα ασύρματα περιβάλλοντα τέτοιες δραστηριότητες

polling θα αποτελούσαν ανεπαρκή και σπάταλη χρήση πόρων ασύρματων

δικτύων.

Σχήμα: Proxy model υποστηρίζοντας βελτιστοποίηση χρήσης δικτύου

User Agent Profile (UAProf) – Αυτή η υπηρεσία παρέχει τον μηχανισμό

περιγραφής δυνατοτήτων κεντρικού υπολογιστή εφαρμογών και προτιμήσεων

χρηστών. Το UAProf υποστηρίζει το πρότυπο συναλλαγής client-server

63

στέλνοντας με αίτημα πληροφορία χρηστών στους κεντρικούς υπολογιστές.

Είναι βασισμένο στο CC/PP (Composite Capabilities/Preference Profiles)

έργο του W3C. Αυτή η πληροφορία επιτρέπει στους κεντρικούς υπολογιστές

να προσαρμόσουν το περιεχόμενο τους αναλόγως σε προετοιμασία προς

απάντηση. Αυτό το πρότυπο υπηρεσιών επιτρέπει επίσης τα proxy που

παρεμβαίνουν ώστε να παρέχονται προστιθέμενης αξίας υπηρεσίες με το να

παράσχει υπηρεσίες προσαρμογής άμεσα. Αναγνωρίζοντας την σοβαρότητα

της ασφάλειας προσωπικών δεδομένων, προσωπική πληροφορία που

υποβάλλετε μπορεί να ελεγχθεί από το χρηστή.

Wireless Telephony Application (WTA) - Αυτή η υπηρεσία παρέχει τα

εργαλεία που επιτρέπουν μια σειρά προηγμένων εφαρμογών τηλεφωνίας να

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

υποστηρίζει λειτουργικότητα της πληροφορίας. Αυτές οι υπηρεσίες

διαχείρισης κλήσεων όπως κάνοντας μια κλήση, απαντώντας μια κλήση,

βάζοντας μια κλήση σε αναμονή και κάνοντας εκτροπή μπορούν να

λειτουργήσουν ανώδυνα μαζί με άλλες υπηρεσίες διαχείρισης πληροφορίας.

Αυτό πραγματικά επιτρέπει στα κινητά με WAP WTA να λειτουργούν ως

συσκευές που μπορούν να ενσωματώσουν πλήρως υπηρεσίες φωνητικής

αναγνώρισης και Διαδυκτίου.

External Functionality Interface (EFI) - Αυτή η υπηρεσία διευκρινίζει τη

διεπαφή μεταξύ WAE και των συστατικών ή τις οντότητες με ενσωματωμένες

εφαρμογές που εκτελούν έξω από τις καθορισμένες ικανότητες WAE. Αυτή

είναι μια ανάλογη υπηρεσία με μια plug-in η οποία επεκτείνει και ενισχύει τις

δυνατότητες ενός browser και άλλων εφαρμογών. Το EFI πλαίσιο επιτρέπει

μελλοντική επέκταση συσκευών που υποστηρίζουν WAP. Αυτό το πλαίσιο

μπορεί να χρησιμοποιηθεί για να καθορίσει τις συγκεκριμένες διεπαφές που

απαιτούνται για την πρόσβαση εξωτερικών συσκευών όπως για παράδειγμα

smart cards, GPS συσκευές, συσκευές υγειονομικής περίθαλψης και

ψηφιακές φωτογραφικές μηχανές.

64

Persistent Storage Interface – Αυτή η υπηρεσία διευκρινίζει ένα

τυποποιημένο σύνολο υπηρεσιών αποθήκευσης που συνδέονται με μια

καθορισμένη διεπαφή για την οργάνωση, πρόσβαση, αποθήκευση και

ανάκτηση των στοιχείων όσον αφορά την ασύρματη συσκευή ή άλλη

συνδεδεμένη συσκευή μνήμης.

Data Synchronization – Το WAP Forum σε μια προσπάθεια να

εξασφαλίσει ένα κοινό πλαίσιο λύσης αναζήτησε μια λύση για το συγχρονισμό

στοιχείων. Κατά συνέπεια το WAP 2.0 αναγνωρίζει και υιοθετεί την γλώσσα

SyncML ως επιλογή του για τη λύση συγχρονισμού στοιχείων. Τα SyncML

μηνύματα υποστηρίζονται και από τα δυο πρωτόκολλα WSP και HTTP/1.1.

Multimedia Messaging Service (MMS) - Αυτή η υπηρεσία παρέχει το

πλαίσιο για την εφαρμογή μιας πλούσιας σε υπηρεσίες λύσης για μηνύματα.

Το MMS παρέχει τα χαρακτηριστικά γνωρίσματα και τη λειτουργία που

επιτρέπει την παράδοση ποικίλων τύπων περιεχομένου. Ανάλογα με το

πρότυπο υπηρεσιών, το MMS επιτρέπει μια γρήγορη παράδοση

πληροφορίας (όπως το SMS) ή αποθήκευση και μεταβίβαση πληροφορίας

(όπως το ηλεκτρονικό ταχυδρομείο). Αυτή η ευελιξία επιτρέπει στους χρήστες

και τους χειριστές να προσαρμόσουν τις υπηρεσίες που μπορούν να

παρέχουν ανάλογα με τις εμπειρίες χρηστών. Με τη χρησιμοποίηση άλλων

υπηρεσιών WAP, όπως την ώθηση και το UAProf, το MMS παρέχει μια

αποδοτική λύση μηνύματος που είναι σε θέση προσαρμογής αναλόγως με το

περιεχόμενο και την μορφή του έτσι ώστε να ληφθεί αποτελεσματικά από την

ανάλογη συσκευή.

Provisioning - Αυτή η υπηρεσία παρέχει μια τυποποιημένη προσέγγιση

παρέχοντας στους πελάτες WAP τις πληροφορίες που απαιτούνται για να

λειτουργήσουν στα ασύρματα δίκτυα. Αυτό επιτρέπει στο χειριστή δικτύων να

διαχειριστεί τις συσκευές στο δίκτυό του χρησιμοποιώντας ένα κοινό σύνολο

εργαλείων.

Pictogram - Αυτή η υπηρεσία επιτρέπει τη χρήση των μικροσκοπικών

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

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

65

ποσό χώρου. Τέτοια επικοινωνία μπορεί να ξεπεράσει τα παραδοσιακά

γλωσσικά όρια.

Το μέλλον του WAP

Όσον αφορά την ανάπτυξη της ασύρματης πρόσβασης στο Internet, τo

WAP βρίσκεται ακόμα σε αρχικό στάδιο. Το GPRS (ένα ευρυζωνικό δίκτυο)

θα αντικαταστήσει το GSM (ένα δίκτυο φωνής που επιτρέπει μόνο τις

ταχύτητες σύνδεσης μέχρι 9.6kbs ανά δευτερόλεπτο), και η τεχνολογία Wap

πρέπει να προσαρμοστεί σε αυτές τις νέες εξελίξεις.

Εξελίξεις στον τομέα του WAP για τα επόμενα χρόνια

• 3G (Third Generation )

Τα 3G δίκτυα θα εισαγάγουν βελτιωμένες υπηρεσίες: Video-on-demand,

high-speed multimedia και mobile Internet πρόσβαση στο Internet είναι

μερικές μόνο τις δυνατότητες που θα προσφέρονται στον χρήστη στο μέλλον.

Τα συστήματα 3ης γενιάς θα επεκτείνουν τους υπάρχοντες τρόπους

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

high-end υπηρεσίες, πράγμα που σημαίνει καλύτερη ποιότητα, μεγαλύτερη

χωρητικότητα και data rates. Επιπλέον θα γεφυρώσουν το κενό μεταξύ

ασύρματου και του Internet κόσμου.

• HSCSD (High Speed Circuit Switched Data )

Το HSCSD είναι μια νέα high-speed εφαρμογή των GSM (Global System

for Mobile Communication (cellular phone technology)) τεχνικών δεδομένων.

Θα επιτρέψει στους χρήστες να έχουν πρόσβαση στο Διαδίκτυο μέσο του

δικτύου GSM με πολύ υψηλότερα data rates από τα σημερινά. Το HSCSD

επιτρέπει στα ασύρματα δεδομένα να έχουν ρυθμούς μετάδοσης 38,4 kbps ή

ακόμα και γρηγορότερους στα δίκτυα GSM.

66

• GPRS (General Packet Radio System)

Ένα από τα κύρια οφέλη αυτής της νέας τεχνολογίας είναι ότι οι χρήστες

είναι διαρκώς on-line και μπορεί να χρεωθoύν μόνο για το ποσό δεδομένων

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

μια data connection λειτουργεί. Οι χρήστες θα ωφεληθούν επίσης από την

γρήγορη και εύκολη 114 kbps data access στις διαφορετικές υπηρεσίες. Με

την αύξηση των transmission rates η μετάδοση video θα είναι εφικτή.

• EDGE (Enhanced Data Rates for Global Evolution)

Το Enhanced Data Rates for Global Evolution (EDGE) θα ωθήσει την

network cabability (το ποσό δεδομένων που μπορεί να χειριστεί ένα δίκτυο σε

οποιαδήποτε στιγμή) και την αύξηση των air interface data rates. Για τους

προμηθευτές GSM, αυτή η νέα τεχνολογία θα αυξήσει τα data rates

μεταγωγής πακέτου (GPRS) και μεταγωγής κυκλώματος (HSCSD) στο

τριπλάσιο.

• UMTS (Universal Mobile Telecommunications System)

Το UMTS θα διαδραματίσει έναν βασικό ρόλο στη δημιουργία της

μελλοντικής μαζικής αγοράς για τις υψηλής ποιότητας ασύρματες

επικοινωνίες πολυμέσων που θα πλησιάσουν τα 2 δισεκατομμύρια χρήστες

παγκοσμίως μέχρι το έτος 2010. Το UMTS θα ενεργοποιήσει την αυριανή

ασύρματη κοινωνία των πληροφοριών με την παράδοση των μεγάλης αξίας

ευρυζωνικών υπηρεσιών πληροφοριών, εμπορίου και ψυχαγωγίας στους

κινητούς χρήστες μέσο των σταθερών, ασύρματων και δορυφορικών δικτύων.

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

επικοινωνίες προσφέροντας data rates πάνω από 2Mbps με global roaming

και άλλες προηγμένες υπηρεσίες UMTS, οι οποίες έχουν προωθηθεί

εμπορικά από το 2002.

67

Συμπεράσματα

Το κινητό τηλέφωνο έχει μεγάλη διείσδυση στον πληθυσμό (μέχρι και 70%

σε μερικές χώρες), αλλά η τεράστια κρυφή του δύναμη είναι ο ακριβής

χωρικός εντοπισμός: η θέση του χρήστη του μπορεί να προσδιοριστεί με

ακρίβεια ακτίνας 50 μέτρων, ενώ αναπτύσσονται τεχνολογίες ικανές να

χρησιμοποιήσουν ραδιοφωνικά σήματα και να πετύχουν ακόμα

εντυπωσιακότερα αποτελέσματα -εκμηδενίζοντας σχεδόν την απόκλιση. Έτσι

αρχίζει το p-commerce (position based commerce). Με τη συναίνεση του

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

κινητό θα τον πληροφορεί ανά πάσα στιγμή για τις τιμές, τις προσφορές και

την ποικιλία των παρακείμενων καταστημάτων, ενώ ταυτόχρονα θα του

δείχνει σε ποιο σημείο της πόλης βρίσκονται φίλοι και γνωστοί του με του

ίδιου πρωτοκόλλου τηλέφωνα. Καθένας μπορεί πλέον με ευχέρεια να βρίσκει

και να ειδοποιεί το πλησιέστερο αστυνομικό τμήμα ή το καταλληλότερο

νοσοκομείο, να πληροφορείται για την κοντινότερη θέση πάρκινγκ, αλλά και

να παρακολουθεί ανά πάσα στιγμή πού βρίσκονται τα παιδιά του. Μεγάλοι

δήμοι σε Αγγλία, Ισπανία και Σουηδία υιοθέτησαν ενεργά την ευκαιρία του

κοινοτικού, κινητού Διαδικτύου. Η διαρκής ενημέρωση για τοπικά γεγονότα, η

αυτόματη ειδοποίηση για έκτακτες καταστάσεις (πυρκαγιές, ακραίες καιρικές

συνθήκες, αλλαγή τιμολογίων και υπηρεσιών), οι ανακοινώσεις και τα

προγράμματα της δημοτικής αρχής, ο συντονισμός συλλογικών επιχειρήσεων,

τα προγράμματα ειδικών δημοψηφισμάτων και κυβερνοδημοκρατίας είναι

μερικές μόνο από τις ευκαιρίες που δίνει η προοπτική της ευρηματικής

δημόσιας χρήσης του WAP. Οι δυνατότητες που παρέχονται είναι πολλές.

Ανοιχτό video conferencing με το κινητό, multimedia chat καθ' οδόν, ζωντανή

σύνδεση με κάμερες σε αίθουσες πανεπιστημίων και διαλέξεων, ψηφιακή

χαρτογράφηση της κυκλοφορίας στην πόλη.

Η αιτία μη ευρείας αποδοχής του WAP από τους χρήστες φαίνεται να είναι

το περιορισμένων δυνατοτήτων UI (User Integrface) που προσφέρει. Οι

διαθέσιμες τερματικές συσκευές (κινητά τηλέφωνα), δεν διαθέτουν την

απαιτούμενη υπολογιστική ισχύ ή οθόνη που να επιτρέπει την δημιουργία

ενός πραγματικά εύχρηστου GUI (grafical user Interface). Τον τελευταίο καιρό

68

όμως, εμφανίζονται όλο και περισσότερες συσκευές με μεγαλύτερες οθόνες ή

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

πιο εύχρηστων GUI και κατά συνέπεια την αύξηση χρήσης εφαρμογών WAP

69

3. Γλώσσες προγραμματισμού

3.1 Η ασύρματη γλώσσα σήμανσης (WML-Wireless Markup Language)

Η WML είναι μια γλώσσα σήμανσης βασισμένη σε XML (extensible Markup

Language). Η επίσημη προδιαγραφή WML αναπτύσσεται και διατηρείται από

το WAP Forum, μια κοινοπραξία που ιδρύθηκε σε βιομηχανικό επίπεδο από

τις Nokia, Phone.com, Motorola και Ericsson. Αυτή η προδιαγραφή καθορίζει

τη σύνταξη, τις μεταβλητές και τα στοιχεία που χρησιμοποιούνται σε ένα

έγκυρο αρχείο WML Σε αυτήν την ενότητα θα παρουσιάσουμε τα βασικά

στοιχεία της WML και ένα παράδειγμα.

Κατανόηση της WML

Η WML είναι βασισμένη στην XML, μια γλώσσα σήμανσης που έχει

συγκεντρώσει τεράστια υποστήριξη, εξαιτίας της δυνατότητάς της να

περιγράψει τα στοιχεία (αντίθετα με την HTML, η οποία χρησιμοποιείται για να

περιγράψει την παρουσίαση των στοιχείων). Ενώ η HTML προκαθορίζει ένα

«κονσερβοποιημένο» σύνολο ετικετών που εγγυάται να γίνει κατανοητό και να

επιδειχθεί σε έναν ομοιόμορφο τύπο από έναν web browser, η XML επιτρέπει

στον δημιουργό εγγράφων να καθορίσει οποιαδήποτε ομάδα ετικετών

επιθυμεί. Αυτό το σύνολο ετικετών ομαδοποιείται έπειτα σε ένα σύνολο

γραμματικής «κανόνες» που είναι γνωστοί ως καθορισμός τύπων εγγράφων,

ή DTD.

Όταν λέμε ότι ένα τηλέφωνο ή άλλη συσκευή επικοινωνίας είναι WAP-

ικανό, αυτό σημαίνει ότι έχει ένα κομμάτι του λογισμικού φορτωμένο επάνω

του (γνωστό ως microbrowser) που καταλαβαίνει πλήρως πώς να χειριστεί

όλες τις οντότητες στο WML 1.1 DTD.

Η πρώτη δήλωση μέσα ένα έγγραφο XML είναι γνωστή ως Prolog. Η

Prolog είναι προαιρετική και αποτελείται από δύο γραμμές κώδικα: τη δήλωση

XML (που χρησιμοποιείται για να καθορίσει την έκδοση XML) και τη δήλωση

τύπων εγγράφων (ένας δείκτης σε ένα αρχείο που περιέχει DTD του

παρόντος εγγράφου).

70

Μετά τη δήλωση Prolog, κάθε έγγραφο XML περιλαμβάνει ένα στοιχείο που

περιέχει όλα τα υπόλοιπα υποστοιχεία και οντότητες. Όπως και στην HTML,

όλα τα στοιχεία τοποθετούνται ανάμεσα στα άγκιστρα : < > και τους

χαρακτήρες.

Μπορεί μόνο να υπάρξει ένα στοιχείο εγγράφων ανά έγγραφο. Στην WML,

το στοιχείο εγγράφων είναι όλα τα άλλα στοιχεία που περιλαμβάνονται μέσα

σε αυτό.

Οι δύο πιο κοινοί τρόποι για αποθήκευση δεδομένων μέσα σε ένα έγγραφο

XML είναι τα στοιχεία και οι ιδιότητες. Τα στοιχεία είναι δομημένα αντικείμενα

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

ετικετών στοιχείων. Τα στοιχεία μπορούν επίσης να περιέχουν και

υποστοιχεία. Οι ιδιότητες χρησιμοποιούνται για να περιγράψουν ένα στοιχείο.

Σε μια δευτερεύουσα σημείωση, ένα σχόλιο σε WML πρέπει να εμφανίζεται

μεταξύ των ετικετών.

Η ασύρματη γλώσσα σήμανσης (WML) είναι το HTML των φυλλομετρητών

WAP και διαβιβάζεται μέσο του πρωτοκόλλου HTTP. Τα αρχεία μπορούν να

εκδοθούν από οποιοδήποτε συντάκτη κειμένων (στους επεξεργαστές λέξεων

όπως το Word αποθηκευμένο μόνο ως κείμενο) και πρέπει να έχει την

επέκταση .wml. Αυτά τα αρχεία μπορούν έπειτα να φορτωθούν στον

προμηθευτή Ιστού (web space provider) με ένα πρόγραμμα FTP.

Συμπεράσματα

Χωρίς τη δυνατότητα εκτέλεσης συναλλαγών μεταξύ των κεντρικών

υπολογιστών, η WML θα χρησίμευε μόνο στο να παρέχει έναν τυποποιημένο

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

δυναμικής σύνδεσης με τους απομακρυσμένους κεντρικούς υπολογιστές

διευρύνει τη χρήση κάθε συσκευής WAP και την εισάγει στον κόσμο του

διαδικτυακού μηνύματος, των επιχειρησιακών δεδομένων και του

ηλεκτρονικού εμπορίου. Οι συσκευές WAP αλληλεπιδρούν με τις πηγές

δεδομένων μέσο μιας πύλης WAP. Αυτή η πύλη πρέπει να διασυνδεθεί με

έναν διακομιστή CDMA, GSM, ή GPRS. Ωστόσο, είναι δυνατό να

71

εγκατασταθούν και να εξεταστούν τα προϊόντα πυλών σε συνδυασμό με τους

δημοφιλείς κεντρικούς υπολογιστές δικτύου-Web servers (όπως Microsoft

Internet Information Server ή Apache) στο τοπικό LAN δίκτυο.

Η WML σε συνδυασμό με το WAP προσφέρει μια εξ ολοκλήρου νέα και

εντυπωσιακή πλατφόρμα, με την οποία μπορούν να επεκταθούν οι

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

3.2 XHTML MP and WCSS

Το πρώην WAP Forum και η κοινοπραξία World Wide Web (W3C) έχουν

καθορίσει τα διαδυκτιακά κινητά πρότυπα κατά τη διάρκεια προηγούμενων

αρκετών χρόνων. Το έτος του 2002 διάφορα σημαντικά φόρουμ βιομηχανίας

ένωσαν δυνάμεις και δημιούργησαν το Open Mobile Alliance (OMA). Το OMA

έχει ως σκοπό να είναι η εστίαση της εργασίας προδιαγραφών για τις κινητές

υπηρεσίες και δημιουργίας διαλειτουργικών κινητών υπηρεσιών σε όλες τις

χώρες, σε χειριστές και κινητά τερματικά.

Το Mobile Applications Group (MAG) μέσα στα πλαίσια του OMA έχει τώρα

την ευθύνη για προδιαγραφές σχετικά με το browsing. Η πρώτη κίνησή ήταν

να δημιουργήσει ένα κατώτατο επίπεδο προσαρμογής για WCSS,

επιτρέποντας έτσι στους σχεδιαστές περιεχομένου και όλους τους

υπεύθυνους για την ανάπτυξη περιεχομένου να στηριχθούν στο WCSS 1.1

ως τον τρόπο πρόσθεσης προηγμένων σχεδιαγραμμάτων, μαρκάρισμα, και

οπτική εξατομίκευση σε ασύρματες ιστοσελίδες.

Η επόμενη γενεά της κινητής τεχνολογίας ξεφυλλίσματος (browsing) , WAP

2.0 αποτελείται από XHTML MP και WCSS. Το World Wide Web Consortium

(W3C) περιγράφει το XHTML (Extensible Hypertext Markup Language) ως «

μια αναδιατύπωση του HTML 4 και επέκταση του Extensible Markup

Language (XML)». Το XHTML φέρνει το κινητό και σταθερό Διαδίκτυο πιο

κοντά δεδομένου ότι είναι η μόνη διευκρινισμένη γλώσσα και για τον

ασύρματο και συνδεμένο με καλώδιο Ιστό. Το XHTML επιτρέπει καλύτερο και

72

ευκολότερο έλεγχο της παρουσίασης από WML, ενισχύοντας έτσι τη

δυνατότητα χρησιμοποίησης των κινητών υπηρεσιών για τους καταναλωτές.

XHTML MP η γλώσσα του κινητού Internet

Στην πιο απλουστευμένη μορφή του ένας κινητός φυλλομετρητής (browser)

είναι μια εφαρμογή που προσκομίζει το περιεχόμενο από τους κεντρικούς

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

αλληλεπιδράσει με το περιεχόμενο, παράγοντας νέα αιτήματα για άλλο

περιεχόμενο που προσκομίζεται από τους κεντρικούς υπολογιστές.

Ο κύριος τύπος περιεχομένου που υποστηρίζεται από τους κινητούς

φυλλομετρητές είναι σελίδες XHTML, οι όποιες είναι η βάση για όλες τις

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

υποστηριχθεί, είτε είναι στατική (προστιθέμενη στο χρόνο εφαρμογής), είτε

είναι δυναμική (προστιθέμενη στο χρόνο εκτέλεσης) ανάλογα με το εάν

χρειάζεται τακτοποίηση βασισμένο στις ιδιαίτερες δυνατότητες συσκευών

χρηστών, όπως το πλάτος οθόνης. Άλλες μορφές περιεχομένου μπορούν να

παρουσιαστούν ως συνδέσεις (links) σε XHTML έγγραφο, όπως αρχεία για

download, ήχοι, βίντεο, ring tones, κτλ. Η προκύπτουσα σελίδα με τις εικόνες

της δίνεται (συνημμένη και επιδειγμένη) από τον φυλλομετρητή.

Σχήμα: Μορφή ενός XHTML MP κειμένου στα δυο μέσα

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

ανάπτυξη τεχνολογιών για την καλύτερη προσαρμογή του κινητού

περιβάλλοντος. Αυτές είναι:

73

• Το μέγεθος της επίδειξης περιεχομένου είναι μικρό λόγω του μικρού

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

περιεχομένου ήταν περιορισμένη σε ασπρόμαυρη οθόνη με αρκετά

χαμηλή ψηφιακή ικανότητα. Τώρα τα τερματικά έχουν ένα πλήρη

φάσμα χρωμάτων, με ψηφιακή δυνατότητα μέχρι και 176*208. Το

μέγεθος του τερματικού θέτει επίσης προκλήσεις για τους

μηχανισμούς εισαγωγής περιεχομένου, μνήμης και ικανότητα

μπαταριών.

• Η βέλτιστη χρήση του ασύρματου εύρους ζώνης δικτύων είναι

επίσης μια πρόκληση. Οι υπηρεσίες πρέπει να είναι γρήγορες για να

χρησιμοποιηθούν.

• Τέλος, οι υπηρεσίες πρέπει να προσαρμοστούν για να

ανταποκριθούν στις ανάγκες ενός πελάτη κινητού. Η αναζήτηση

τους πρέπει να είναι γρήγορη, εύχρηστη, και να παρέχετε χωρίς τις

πρόσθετες ανάγκες, προκειμένου να κρατηθούν οι δαπάνες

πελατών χαμηλά.

Στα πλαίσια της κινητής τηλεφωνίας το XHTML MP είναι ένα υποσύνολο

της γλώσσας XHTML και παρέχει όλες τις δυνατότητες του μεγάλου αδελφού

της, εξαιρώντας μόνο τα πράγματα που δεν είναι χρήσιμα για τις μικρές

οθόνες, όπως τα πλαίσια.

Το XHTML είναι η βάση της προσπάθειας του W3C να δημιουργήσει τα

πρότυπα παροχής πλουσιότερου διαδυκιτακού περιεχόμενου σε μια συνεχώς

αυξανόμενη σειρά των πλατφόρμων. Με τη χρήση του XHTML οι

προμηθευτές θα βρουν ευκολότερο να παραγάγουν το περιεχόμενο για ένα

ευρύ σύνολο πλατφόρμων και με την καλύτερη διαβεβαίωση για το πώς το

περιεχόμενο επιδεικνύεται. Αντίθετα, η αρχική γλώσσα WML (Wireless Mark-

up Language) 1.x δεν εξασφαλίζει κοινή πλατφόρμα στις διάφορες συσκευές.

Αυτό φέρνει ιδιαίτερες ανησυχίες σε αυτούς που διαχειρίζονται κινητά

τηλέφωνα από διάφορους προμηθευτές και με τα διαφορετικά μέσα

παρουσίασης (interfaces) από το ένα κινητό μοντέλο στο άλλο.

74

XHTML είναι μια ακριβέστερη διατύπωση της καθιερωμένης γλώσσας

HTML, δεδομένου ότι είναι βασισμένη στις ίδιες ετικέτες που

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

υπεύθυνοι για την ανάπτυξη Ιστού δεν χρειάζεται να μάθουν μια νέα γλώσσα,

και ότι τα τρέχοντα εργαλεία προσαρμόζονται για να παραγάγουν XHTML MP

κωδικό. Παρομοίως ένας προγραμματιστής μπορεί να δει ένα XHTML MP

έγγραφο σε έναν τυποποιημένο φυλλομετρητή Ιστού και το σχεδιάγραμμα θα

είναι σύμφωνο με αυτό που παρουσιάζεται σε μια κινητή συσκευή.

Σχήμα: Το ίδιο XHTML περιεχόμενο εμφανίζεται σε διάφορες συσκευές

Wireless Cascading Style Sheets (WCSS)

Ένα από τα βασικά σημεία του XHTML MP είναι η υποστήριξη του

Wireless Cascading Style Sheets (WCSS, στο παρελθόν αποκαλούμενο WAP

CSS). Το W3C έχει ενθαρρύνει τη χρήση css στον Ιστό με όλους τους

φυλλομετρητές είτε είναι σε υπολογιστές γραφείου είτε σε κινητές συσκευές.

Το CSS περιγράφει πώς τα έγγραφα παρουσιάζονται στην οθόνη από τον

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

ελέγξουν την παρουσίαση των εγγράφων χωρίς να θυσιάσουν την δυνατότητα

ανεξαρτησίας συσκευών ή προσθήκη των νέων γλωσσικών ετικετών όπως

έγινε με την WML 1.Χ.

75

Η χρήση γνωστών τυποποιημένων ετικετών HTML και CSS ιδιοτήτων

μειώνει τις δαπάνες ανάπτυξης με την εξάλειψη της ανάγκης για τους

υπεύθυνους για την ανάπτυξη να μάθουν νέες ετικέτες, για να αποθηκευτούν

διάφορες εκδόσεις περιεχομένου, ή για να κυριαρχήσουν τα διάφορα

εργαλεία. Επιπλέον, οι κεντρικοί υπολογιστές δεν επωμίζονται προστιθέμενες

καθυστερήσεις που προκύπτουν από την ακριβή διακωδικοποίηση που

απαιτείται για να προετοιμαστεί το περιεχόμενο για μια σειρά διαφορετικών

γλωσσών.

Η δύναμη του CSS βρίσκεται στον ακριβή έλεγχο που προσφέρει τους

δημιουργούς εγγράφων και την ευκολία με την οποία μπορούν να

βελτιώσουν το περιεχόμενο για την παρουσίαση σε οποιαδήποτε συσκευή.

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

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

μπορεί να καθοριστεί στο φύλλο ύφους (style sheet). Εάν η παρουσίαση

πρέπει να αλλαχτεί οποιαδήποτε στιγμή, η αλλαγή γίνεται μόνο στο φύλλο

ύφους και η τροποποίηση εμφανίζεται σε όλες τις σελίδες του site.

To CSS δίνει στους χειριστές μεγαλύτερο έλεγχο του look&feel των

υπηρεσιών που παρέχουν μέσο της ασύρματης πύλης τους. Για παράδειγμα

ένας χειριστής μπορεί να διευκρινίσει ότι όλες οι συνδέσεις πρέπει να

υπογραμμίζονται και να είναι κόκκινες. Φυσικά, οι υπεύθυνοι για την ανάπτυξη

θα μπορούσαν να επιλέξουν να τροποποιήσουν το συγκεκριμένο ύφος μέσο

της χρήσης CSS εάν μια διαφορετική συμπεριφορά απαιτείται, αλλά το φύλλο

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

Περίληψη οφελών από την χρήση της νέας τεχνολογίας

Για τους Φορείς κινητής τηλεφωνίας

• Οι νέες γραφικές ικανότητες UI επιτρέπουν πλουσιότερες υπηρεσίες

για τους χρήστες (χρώμα, τίτλοι, σύνορα, σχεδιάγραμμα, κ.λ.π....)

76

• Ικανοποιητικά αποδοτική φορητότητα περιεχομένου από άποψη

κόστους για όλες τις ασύρματες συσκευές για όλους τους φορείς

κινητής τηλεφωνίας (CSS)

• Δυνατότητα εξειδικευμένης εμφάνισης για ένα φορέα κινητής

τηλεφωνίας

Για τους Σχεδιαστές περιεχομένου:

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

• Διευκόλυνση φορητότητας περιεχομένου σε διάφορες ασύρματες

συσκευές

Για τους Χρήστες κινητών

• Πλουσιότερο περιεχόμενο

• Πλουσιότερες γραφικές υπηρεσίες

77

4.Βασικές Αρχές Κρυπτογραφίας

Εισαγωγή

Από την απαρχή του ανθρώπινου πολιτισμού μέχρι τις υψηλά δικτυωμένες

κοινωνίες στις οποίες ζούμε σήμερα, η επικοινωνία αποτελούσε πάντοτε ένα

αναπόσπαστο κομμάτι της ύπαρξης μας. Αυτό που ξεκίνησε ως απλός

τρόπος επικοινωνίας πριν από αιώνες, έχει σήμερα εξελιχθεί σε πολλές

μορφές, με το Διαδίκτυο να είναι μια από αυτές.

Τα δίκτυα υπολογιστών, στις λίγες πρώτες δεκαετίες της ύπαρξης τους,

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

ηλεκτρονικού ταχυδρομείου και από υπαλλήλους οργανισμών για την από

κοινού εκτύπωση χαρτιού. Υπό τις συνθήκες αυτές η ασφάλεια δεν

συγκέντρωνε την προσοχή. Σήμερα όμως που εκατομμύρια χρηστών

χρησιμοποιούν τα δίκτυα για διεκπεραίωση τραπεζικών συναλλαγών, αγορές

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

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

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

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

μέσα και οι υπηρεσίες, παρά τη διαφορετικότητα τους, θα πρέπει να

ικανοποιούν 4 σημαντικές προϋποθέσεις ασφάλειας:

• Απόρρητο(εμπιστευτικότητα): αφορά στο να κρατούνται οι

πληροφορίες ιδιωτικές και μυστικές έτσι ώστε μονό ο

εξουσιοδοτημένος παραλήπτης να μπορεί να τις καταλαβαίνει. Για

παράδειγμα, αν ο χρήστης Α στείλει ένα μήνυμα στο χρήστη Β τότε

θα πρέπει ο B (και μόνο ο B) να είναι σε θέση να διαβάσει και να

καταλάβει την πληροφορία.

• Πιστοποίηση αυθεντικότητας: αφορά στην απόδειξη της ταυτότητας

του αποστολέα στον παραλήπτη, έτσι ώστε ο παραλήπτης να

μπορεί να είναι σίγουρος ότι ο αποστολέας είναι πράγματι αυτός

που ισχυρίζεται ότι είναι. Για παράδειγμα, αν ο χρήστης B λάβει ένα

μήνυμα από το χρήστη Α, θα πρέπει να είναι σε θέση να

78

πιστοποιήσει την ταυτότητα του Α και να ξέρει ότι το μήνυμα που

έλαβε είναι πράγματι από αυτόν.

• Έλεγχος ακεραιότητας: αφορά στο να διασφαλίσει ότι η πληροφορία

του μηνύματος δεν έχει αλλοιωθεί κατά τη διάρκεια της μεταφοράς

της ή της αποθήκευσής της στο δίκτυο. Οποιοδήποτε μη

εξουσιοδοτημένο άτομο δε θα πρέπει να είναι σε θέση να αλλάξει

την πληροφορία κατά τη μεταφορά της. Για παράδειγμα, αν ο

χρήστης Α στείλει ένα μήνυμα στο χρήστη Β, το περιεχόμενο του

μηνύματος θα πρέπει να μην αλλαχθεί και να μείνει ίδιο με αυτό που

έστειλε ο Α.

• Μη αποκήρυξη: αφορά στο να διασφαλίσει ότι ο αποστολέας του

μηνύματος δε θα αρνηθεί ότι πράγματι έστειλε την πληροφορία. Για

παράδειγμα, αν ο χρήστης Α στείλει ένα μήνυμα στο χρήστη Β τότε ο

Α δε θα μπορεί να αρνηθεί αργότερα ότι έστειλε το μήνυμα.

4.1 Κρυπτογραφία

Κρυπτογραφία είναι η επιστήμη της προστασίας δεδομένων, η οποία

παρέχει τρόπους και μεθόδους για μετατροπή των δεδομένων σε μη

αναγνώσιμη μορφή έτσι ώστε να καθίσταται αδύνατη η επεξεργασία και

ανάγνωσή τους από μη εξουσιοδοτημένα άτομα. Την πληροφορία θα μπορεί

να τη διαβάσει μόνο το άτομο για το οποίο προορίζεται.

Η κρυπτογραφία, λοιπόν, είναι το τεχνολογικό μέσο που παρέχει ασφάλεια

στη μετάδοση των δεδομένων σε πληροφοριακά ή επικοινωνιακά συστήματα.

Είναι ιδιαίτερα χρήσιμη σε περιπτώσεις αποστολής οικονομικών και

προσωπικών δεδομένων και αποτελεί ένα χρήσιμο εργαλείο για την

πιστοποίηση της αυθεντικότητας των εμπλεκομένων στη συναλλαγή, αλλά και

για τον προσδιορισμό του ενόχου σε περίπτωση που η εμπιστευτικότητα και η

ακεραιότητα των δεδομένων έχει παραβιαστεί. Εξαιτίας της ανάπτυξης του

ηλεκτρονικού εμπορίου, οι κρυπτογραφικές τεχνικές είναι ιδιαίτερα κρίσιμες

για την ανάπτυξη και τη χρήση καλά προστατευμένων πληροφοριακών και

επικοινωνιακών δικτύων.

79

4.1.1 Συμμετρική Κρυπτογραφία

Η συμμετρική κρυπτογραφία βασίζεται στην ύπαρξη ενός μοναδικού

κλειδιού, γνωστό ως μυστικό ή συμμετρικό κλειδί (secret key), με το οποίο

γίνεται η κρυπτογράφηση και η αποκρυπτογράφηση της πληροφορίας. Ο

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

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

της συμμετρικής κρυπτογραφίας. Τα μηνύματα προς κρυπτογράφηση,

γνωστά ως το σαφές κείμενο (plaintext), κρυπτογραφούνται με χρήση του

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

έξοδο ένα κείμενο σε ακατανόητη μορφή, γνωστό ως κρυπτογράφημα

(ciphertext). Η ασφάλεια της μεταδιδόμενης πληροφορίας επιτυγχάνεται

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

διαδικασία της ανάκτησης της αρχικής πληροφορίας με τη χρήση του ίδιου

συμμετρικού κλειδιού ονομάζεται αποκρυπτογράφηση.

ΣαφέςΚείμενο

Κρυπτογράφηση

Συμμετρικό Κλειδί

Κρυπτογράφημα

Αποκρυπτογράφηση

Συμμετρικό Κλειδί

ΣαφέςΚείμενο

Κρυπτογράφημα

Σχήμα: Διαδικασία συμμετρικής κρυπτογραφίας

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

Ένας από τους παλιότερους γνωστούς κώδικες κρυπτογραφίας είναι ο

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

80

Άλλοι γνωστοί και πιο σύγχρονοι αλγόριθμοι είναι οι αλγόριθμοι DES, IDEA,

RC5, CAST-128 και AES.

Στα πλεονεκτήματα της συμμετρικής κρυπτογραφίας συγκαταλέγονται οι

υψηλές ταχύτητες κρυπτογράφησης και αποκρυπτογράφησης που μπορούν

να υπερβούν τα 100Mbps καθώς επίσης και οι μικρές απαιτήσεις της σε

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

περιβάλλοντα όπως αυτά ενός κινητού τηλεφώνου ή μιας έξυπνης κάρτας.

Επίσης το μέγεθος του κρυπτογραφήματος είναι αρκετά μικρότερο από αυτό

του αρχικού κειμένου.

Η ανάγκη της ανταλλαγής του συμμετρικού κλειδιού μεταξύ αποστολέα και

παραλήπτη είναι ένας από τους σημαντικότερους περιορισμούς της

συμμετρικής κρυπτογραφίας. Η ασφάλεια της συμμετρικής κρυπτογραφίας

βασίζεται αποκλειστικά στο γεγονός ότι ο αποστολέας και ο παραλήπτης

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

Έτσι κρίνεται απαραίτητη η επίτευξη μιας ασφαλούς ζεύξης για την μεταφορά

του συμμετρικού κλειδιού. Κάτι τέτοιο όμως δεν είναι πάντα εφικτό εξαιτίας

πρακτικών αλλά και λειτουργικών δυσκολιών. Η διαδικασία της ασφαλούς

ανταλλαγής του συμμετρικού κλειδιού γίνεται ακόμα μεγαλύτερη όταν οι δύο

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

αυτή την περίπτωση προκύπτει η ανάγκη πιστοποίησης της ταυτότητας κάθε

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

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

μεταφορά του κλειδιού γίνεται είτε μέσο μιας φυσικής ζεύξης (ανταλλαγή

κλειδιού πρόσωπο με πρόσωπο) είτε μέσο μίας έμπιστης τρίτης οντότητας,

την οποία οι χρήστες εμπιστεύονται για την ασφαλή μεταφορά του κλειδιού

Ένας ακόμη σημαντικός περιορισμός αφορά στη δυσκολία κλιμάκωσης της

μεθόδου. Καθώς το πλήθος των χρηστών που θέλουν να επικοινωνήσουν

μεταξύ τους μεγαλώνει, γίνεται αυτονόητο ότι μεγαλώνει και το πλήθος των

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

επίτευξη επικοινωνίας μεταξύ n χρηστών απαιτούνται 2/2n μοναδικά

συμμετρικά κλειδιά, συμπεριλαμβανομένου και του κλειδιού που έχει κάθε

81

χρήστης για τον εαυτό του. Τα προβλήματα της διαχείρισης των κλειδιών (key

management) γίνονται ακόμα μεγαλύτερα γιατί κάθε κλειδί θα πρέπει

περιοδικά να αντικαθίσταται από κάποιο καινούριο με σκοπό τη μείωση των

δεδομένων που κρυπτογραφούνται με το ίδιο κλειδί.

4.1.2 Ασύμμετρη Κρυπτογραφία ή Κρυπτογραφία Δημοσίου Κλειδιού

Στα μέσα της δεκαετίας του ‘70 οι Whitfield Diffie και Martin Hellman

πρότειναν μια νέα τεχνική για τον περιορισμό των προβλημάτων της

συμμετρικής κρυπτογραφίας. Η τεχνική αυτή, γνωστή ως κρυπτογραφία

δημοσίου κλειδιού ή ασύμμετρη κρυπτογραφία, βασίζεται στην ύπαρξη ενός

ζεύγους κλειδιών (key pair). Σε αυτό το ζεύγος, τα κλειδιά, αν και σχετίζονται

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

ώστε η γνώση του ενός να μην επιτρέπει την παραγωγή ή τον υπολογισμό

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

γνωστό και διαθέσιμο. Το κλειδί αυτό ονομάζεται δημόσιο κλειδί (public key)

και χρησιμοποιείται για την κρυπτογράφηση των δεδομένων. Το δεύτερο

κλειδί είναι απαραίτητο να μένει ιδιωτικό, γι’ αυτό και ονομάζεται ιδιωτικό

κλειδί (private key) και χρησιμοποιείται για την αποκρυπτογράφηση των

δεδομένων.

Τα βασικά χαρακτηριστικά του δημόσιου και του ιδιωτικού κλειδιού είναι:

Κάθε κλειδί είναι ένα δυαδικό αλφαριθμητικό.

• Τα κλειδιά, δημόσια και ιδιωτικά, παράγονται ταυτόχρονα από ειδικό

πρόγραμμα λογισμικού.

• Τα κλειδιά δεν είναι ταυτόσημα, αλλά σχετίζονται μοναδικά έτσι

ώστε να είναι δυνατή η χρήση τους για κρυπτογράφηση και

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

παράγεται το ζεύγος των κλειδιών εξασφαλίζει ότι κάθε κλειδί

σχετίζεται μοναδικά με το ταίρι του και κανένα κλειδί δεν μπορεί να

παραχθεί από το άλλο.

82

• Τα κλειδιά, δημόσια και ιδιωτικά, που ανήκουν σε ένα ζεύγος είναι

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

με το ένα κλειδί μπορούν να αποκρυπτογραφηθούν μόνο με το άλλο

και αντίστροφα. Με άλλα λόγια, ένα μήνυμα που έχει

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

αποκρυπτογραφηθεί μόνο χρησιμοποιώντας το αντίστοιχο ιδιωτικό

κλειδί.

• Κάθε οντότητα που συμμετέχει σε ένα σύστημα επικοινωνίας

δημοσίου κλειδιού έχει το δικό της ζεύγος δημόσιου και ιδιωτικού

κλειδιού.

• Το ιδιωτικό κλειδί:

• Προστατεύεται από τον ιδιοκτήτη του

• Χρησιμοποιείται για την ψηφιακή υπογραφή μηνυμάτων

• Το δημόσιο κλειδί:

• Διανέμεται ελεύθερα και είναι προσβάσιμο σε οποιονδήποτε

• Χρησιμοποιείται για την πιστοποίηση ψηφιακών υπογραφών

• Χρησιμοποιείται για την κρυπτογράφηση μηνυμάτων

• Αποθηκεύεται μέσα σε «ψηφιακά πιστοποιητικά» που παρέχουν

την ακεραιότητα και την αυθεντικότητα του ιδιοκτήτη του κλειδιού

• Παρόλο που τα δημόσια κλειδιά μπορούν να διανέμονται ελεύθερα,

τα ιδιωτικά κλειδιά δε θα πρέπει ποτέ να γίνονται γνωστά σε μη

εξουσιοδοτημένες οντότητες.

Το σχήμα 2.2 περιγράφει τη διαδικασία κρυπτογράφησης δημοσίου

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

το οποίο είναι ελεύθερα διαθέσιμο, το μήνυμα που θέλει να του στείλει. Το

κρυπτογραφημένο μήνυμα φτάνει στον παραλήπτη ο οποίος το

αποκρυπτογραφεί με το ιδιωτικό κλειδί του.

83

ΣαφέςΚείμενο

Κρυπτογράφηση

Δημόσιο Κλειδί Αποστολέα

Κρυπτογράφημα

Αποκρυπτογράφηση

Ιδιωτικό Κλειδί Αποστολέα

ΣαφέςΚείμενο

Κρυπτογράφημα

Σχήμα: Διαδικασία Κρυπτογράφησης Δημοσίου Κλειδιού

Η κρυπτογραφία δημοσίου κλειδιού χρησιμοποιείται για την

κρυπτογράφηση και αποκρυπτογράφηση δεδομένων καθώς και για την

ψηφιακή υπογραφή τους. Η ασφάλεια της κρυπτογραφίας δημοσίου κλειδιού

βασίζεται ακριβώς στο γεγονός ότι είναι υπολογιστικά αδύνατη η παραγωγή

του ιδιωτικού από το δημόσιο κλειδί. Θεωρητικά, βέβαια, το ιδιωτικό κλειδί

μπορεί πάντα να υπολογιστεί αλλά το κόστος σε χρόνο, μνήμη και

υπολογιστική ισχύ για κάτι τέτοιο είναι τόσο μεγάλο που καθίσταται πρακτικά

αδύνατο.

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

δεν απαιτείται ανταλλαγή μυστικού κλειδιού. Το δημόσιο κλειδί είναι ελεύθερα

διαθέσιμο, πράγμα που κάνει τη διαχείριση των κλειδιών (key management)

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

καθιστώντας έτσι δυσκολότερη την παραποίησή του. Επίσης με την

κρυπτογραφία δημοσίου κλειδιού καθίσταται δυνατή η υλοποίηση μιας πολύ

σημαντικής κρυπτογραφικής λειτουργίας, αυτή της ψηφιακής υπογραφής

δεδομένων.

Η κρυπτογραφία δημοσίου κλειδιού έχει μεγάλες απαιτήσεις σε

υπολογιστική ισχύ, σχεδόν 100 φορές παραπάνω από αυτή που απαιτείται

84

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

αρκετά αργή ειδικά όταν πρόκειται για μεγάλα μηνύματα. Γι’ αυτό το λόγο

συνήθως δεν κρυπτογραφούνται δεδομένα αλλά συμμετρικά κλειδιά, με τη

μέθοδο του ψηφιακού φακέλου που περιγράφεται στη συνέχεια.

4.1.3 Υβριδική Κρυπτογραφία Ψηφιακού Φακέλου

Ιδιαίτερο ενδιαφέρον για την επίτευξη ασφαλούς επικοινωνίας μεταξύ δύο

μερών παρουσιάζει η υβριδική κρυπτογραφία που είναι γνωστή και ως

ψηφιακός φάκελος (digital envelope) και αξιοποιεί ταυτόχρονα τις τεχνικές

συμμετρικής και ασύμμετρης κρυπτογραφίας. Η υβριδική αυτή κρυπτογραφία

μπορεί να χρησιμοποιηθεί για πολλούς παραλήπτες ταυτόχρονα. Τα βήματα

που ακολουθούνται για τη δημιουργία ενός ψηφιακού φακέλου είναι τα εξής:

1. Δημιουργείται ένα συμμετρικό κλειδί με χρήση ενός αλγορίθμου

συμμετρικής κρυπτογραφίας (π.χ. του DES).

2. Η αρχική πληροφορία κρυπτογραφείται με το συμμετρικό κλειδί που

έχει δημιουργηθεί.

3. Το συμμετρικό κλειδί κρυπτογραφείται με το δημόσιο κλειδί του

παραλήπτη.

4. Τα δύο κρυπτογραφημένα κείμενα αποτελούν τον ψηφιακό φάκελο

του παραλήπτη.

Ο παραλήπτης ανοίγει τον ψηφιακό του φάκελο αποκρυπτογραφώντας με

το ιδιωτικό κλειδί του το κρυπτογραφημένο συμμετρικό κλειδί. Με χρήση του

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

Μετά την επίτευξη μιας ασφαλούς επικοινωνίας μεταξύ αποστολέα και

παραλήπτη το συμμετρικό κλειδί καταστρέφεται.

Η χρήση της υβριδικής κρυπτογραφίας βοήθα στο να ξεπεραστούν κάποιες

σημαντικές αδυναμίες της κρυπτογραφίας δημοσίου κλειδιού. Συγκεκριμένα η

κρυπτογραφία δημοσίου κλειδιού είναι αρκετά αργή σε σύγκριση με την

συμμετρική κρυπτογραφία, ειδικά όταν πρόκειται να κρυπτογραφηθούν

μεγάλα μηνύματα. Ακόμα όμως και στην περίπτωση που ο όγκος των προς

κρυπτογράφηση δεδομένων είναι μικρός, έχει καθιερωθεί να χρησιμοποιείται

85

η κρυπτογραφία ψηφιακού φακέλου. Με αυτόν τον τρόπο αποφεύγεται

οποιαδήποτε σύγχυση ως προς το αν το αποτέλεσμα της

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

4.2 Κρυπτογραφία Δημοσίου Κλειδιού

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

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

καθένας από τους οποίους είναι κατάλληλος για την υλοποίηση μιας ή

περισσοτέρων από τις υπηρεσίες που προσφέρει η κρυπτογραφία δημοσίου

κλειδιού και οι οποίες θα εξεταστούν στην ενότητα Υπηρεσίες. Στη συνέχεια

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

κρυπτογράφησης δημοσίου κλειδιού.

Αλγόριθμος Rivest Shamir Adleman (RSA)

Το 1978 οι Ron Rivest, Adi Shamir και Len Adleman πρότειναν έναν

αλγόριθμο, γνωστό ως RSA, ο οποίος είναι ένας από τους πιο διαδεδομένους

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

δημοσίου κλειδιού. Αυτός ο αλγόριθμος είναι κατάλληλος για κρυπτογράφηση/

αποκρυπτογράφηση δεδομένων, για την δημιουργία ψηφιακών υπογραφών

και την επαλήθευσή τους καθώς και για την ασφαλή μεταφορά κλειδιών.

Χρησιμοποιείται ως βάση για τη δημιουργία μιας ασφαλούς γεννήτριας

ψευδοτυχαίων αριθμών καθώς και για την ασφάλεια σε ορισμένα ηλεκτρονικά

παιχνίδια. Ο RSA βασίζεται στις αρχές της θεωρίας αριθμών. Στη συνέχεια

αναφέρονται συνοπτικά τα βήματα που ακολουθούνται για την υλοποίηση του

αλγορίθμου 28):

1. Επιλέγονται δύο μεγάλοι πρώτοι αριθμοί, p και q (συνήθως πολύ

μεγαλύτεροι από 10100)

2. Υπολογίζεται qpn ×= και )1()1( −×−= qpz . Ο n ονομάζεται

υπόλοιπο RSA (RSA modulus)

3. Επιλέγεται ένας πρώτος αριθμός ως προς τον z ο οποίος

ονομάζεται e.

86

4. Υπολογίζεται ο d έτσι ώστε zed mod1=×

5. Το δημόσιο κλειδί αποτελείται από το ζευγάρι ),( ne και το ιδιωτικό

κλειδί από το ζευγάρι ).,( nd

Έχοντας υπολογίσει εκ των προτέρων τις παραπάνω παραμέτρους ξεκινά

η κρυπτογράφηση. Τα βήματα που ακολουθούνται για την κρυπτογράφηση

ενός κειμένου m περιγράφονται παρακάτω:

1. Το κείμενο το οποίο θα κρυπτογραφηθεί (που θεωρείται ως συρμός

bit) διαιρείται σε μπλοκ, έτσι ώστε κάθε μήνυμα κειμένου, m , να

πέφτει στο διάστημα nm <≤0 . Αυτό μπορεί να γίνει με

ομαδοποίηση του κειμένου σε μπλοκ των k bit, όπου το k είναι ο

μεγαλύτερος ακέραιος για τον οποίο η σχέση nk <2 είναι αληθής.

2. Υπολογίζεται το )(mod nmc e= όπου το c είναι το

κρυπτογραφημένο κείμενο.

Για την αποκρυπτογράφηση του μηνύματος c ακολουθούνται τα παρακάτω

βήματα:

1. Υπολογίζεται το (mod )dm c n= όπου το m είναι το αρχικό κείμενο.

Η ασφάλεια της μεθόδου οφείλεται στην δυσκολία της παραγοντοποίησης

μεγάλων αριθμών. Εάν ο κρυπτοαναλυτής μπορούσε να παραγοντοποιήσει

το δημόσια γνωστό n, θα μπορούσε στη συνέχεια να βρει τα p και q και από

αυτά το z. Αν διαθέτει τα z και e μπορεί να βρει το d με τη βοήθεια του

αλγορίθμου του Ευκλείδη. Σύμφωνα τον Rivest και τους συναδέλφους του, η

παραγοντοποίηση ενός αριθμού με 200 ψηφία απαιτεί 4 δισεκατομμύρια

χρόνια υπολογιστικού χρόνου θεωρώντας ότι γίνεται χρήση ενός υπολογιστή

με χρόνο εντολής 1 μsec. Ακόμα και αν οι υπολογιστές συνεχίσουν να

γίνονται ταχύτεροι κατά μία τάξη μεγέθους ανά δεκαετία θα χρειαστούν αιώνες

για να γίνει δυνατή η παραγοντοποίηση αριθμών με 500 ψηφία, αλλά και τότε

θα μπορούμε απλά να επιλέγουμε μεγαλύτερα p και q . Το σημερινό επίπεδο

της έρευνας πάνω στην παραγοντοποίηση των αριθμών απαιτεί τα κλειδιά

87

που παράγονται με τον αλγόριθμο RSA να έχουν μήκος τουλάχιστον 1024

bits έτσι ώστε να παρέχεται ικανοποιητική ασφάλεια στις επικοινωνίες μέσα

στα επόμενα χρόνια.

Πλεονεκτήματα του RSA

Ο RSA παρέχει μερικά πλεονεκτήματα τα οποία βοήθησαν στην υλοποίηση

πιο ασφαλών και ευκολότερα διαχειρίσιμων συναλλαγών. Τα πλεονεκτήματα

αυτά περιλαμβάνουν:

• Απλοποίηση του προβλήματος της διαχείρισης κλειδιών: στην

συμμετρική κρυπτογραφία ο αριθμός των κλειδιών που απαιτείται

για την επικοινωνία n οντοτήτων σε ένα κρυπτοσύστημα είναι

ανάλογος του 2n . Στην ασύμμετρη κρυπτογραφία όμως κάθε

χρήστης χρειάζεται δύο κλειδιά, έτσι ο απαιτούμενος αριθμός

κλειδιών είναι απλά n2 . Γίνεται κατανοητό λοιπόν ότι σε ένα

κρυπτοσύστημα δημοσίου κλειδιού η σχέση που συνδέει τον αριθμό

των χρηστών με τον αριθμό των κλειδιών είναι γραμμική και για αυτό

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

είναι πολύ μεγάλος.

• Ενισχυμένη ασφάλεια των συναλλαγών: κάθε χρήστης παράγει

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

κλειδί θα πρέπει να μένει μυστικό και κρυφό από οποιαδήποτε μη

εξουσιοδοτημένη οντότητα εξαλείφοντας έτσι όχι μόνο το πρόβλημα

της μεταφοράς του αλλά και την απαίτηση για την εγκατάσταση ενός

ασφαλούς διαύλου επικοινωνίας. Το δημόσιο κλειδί από την άλλη

είναι ευρέως διαθέσιμο και άρα μπορεί να μεταφερθεί με

οποιαδήποτε βολική μέθοδο σε ένα δίκτυο χωρίς να τίθεται θέμα για

την διατήρηση της μυστικότητάς του.

Ο αλγόριθμος RSA είναι κάτι παραπάνω από δεδομένο στην

κρυπτογραφία δημοσίου κλειδιού σε σημείο μάλιστα που οι δύο έννοιες να

θεωρούνται ταυτόσημες. Η ισχύς του RSA είναι τόσο μεγάλη που η

88

κυβέρνηση των ΗΠΑ έχει περιορίσει σημαντικά την εξαγωγή του αλγορίθμου

σε ξένες χώρες.

Πιθανές επιθέσεις στον RSA

Αν και ο αλγόριθμος RSA είναι ο επικρατέστερος στο χώρο της

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

σημαντικά προβλήματα που θα μπορούσε να αντιμετωπίσει ο αλγόριθμος

αυτός είναι τα παρακάτω:

• Παραγοντοποίηση του δημοσίου κλειδιού: αυτό που θα ήθελε φυσικά να

πετύχει κάθε εισβολέας σε ένα δίκτυο επικοινωνίας είναι να ανακτήσει

το αρχικό κείμενο m από το αντίστοιχο κρυπτοκείμενο c, δοσμένου του

δημοσίου κλειδιού ),( ne του παραλήπτη. Το παραπάνω είναι γνωστό

και ως πρόβλημα RSA (RSA problem, RSAP). Μια πιθανή προσέγγιση

που θα μπορούσε να υλοποιήσει ο εισβολέας για να λύσει το πρόβλημα

RSA είναι αρχικά να παραγοντοποιήσει το n και στη συνέχεια να

υπολογίσει τα z και d ακριβώς όπως έκανε και ο χρήστης του δικτύου.

Από τη στιγμή που ο εισβολέας καταφέρει να υπολογίσει το d τότε

μπορεί να αποκρυπτογραφήσει οποιαδήποτε πληροφορία στέλνεται σε

αυτόν το χρήστη. Το παραπάνω σενάριο πρόκειται για την πιο μεγάλη

απειλή που μπορεί να αντιμετωπίσει ο αλγόριθμος αυτός. Προς το

παρόν ο RSA φαίνεται να είναι εξαιρετικά δυνατός και ασφαλής. Αν και,

όπως αναφέρθηκε παραπάνω, η παραγοντοποίηση του υπολοίπου

RSA n είναι πολύ δύσκολη, σε περίπτωση που κάτι τέτοιο επιτευχθεί

όλα τα μηνύματα που κρυπτογραφούνται με το δημόσιο κλειδί θα

μπορούν να αποκρυπτογραφηθούν.

• Επίθεση επανάληψης (cycle attack): σε αυτό το είδος επίθεσης το

κρυπτοκείμενο αποκρυπτογραφείται επαναλαμβανόμενα μέχρι να

προκύψει το αρχικό κείμενο. Ένας μεγάλος αριθμός επαναλήψεων

μπορεί να καταφέρει να αποκρυπτογραφήσει οποιοδήποτε

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

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

89

• Επίθεση στο υπόλοιπο RSA, n: η επίθεση στο υπόλοιπο n μπορεί να

εφαρμοσθεί σε περιπτώσεις όπου υπάρχει μια ομάδα επικοινωνούντων

που έχουν κλειδιά των οποίων το n είναι ίδιο. Όταν γίνεται χρήση του

RSA είναι απαραίτητο κάθε οντότητα να διαλέγει το δικό της υπόλοιπο

RSA n. Ο λόγος εξηγείται στη συνέχεια. Κάποιες φορές προτείνεται μια

έμπιστη κεντρική αρχή για να διαλέγει το υπόλοιπο RSA n. Η ίδια αρχή

στη συνέχεια διανέμει σε κάθε χρήστη του δικτύου ένα ζεύγος ),( ii de .

Όμως, μπορεί να αποδειχθεί ότι η γνώση οποιουδήποτε ζεύγους

),( ii de επιτρέπει την παραγοντοποίηση του n. Έτσι, οποιαδήποτε

οντότητα θα μπορούσε να υπολογίσει το d για οποιοδήποτε άλλη

οντότητα μέσα στο δίκτυο. Συνεπώς, αν ένα κρυπτογραφημένο μήνυμα

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

τεχνική με την οποία ένας εισβολέας έχει μεγάλες πιθανότητες να

ανακτήσει το αρχικό μήνυμα χρησιμοποιώντας μόνο μια πληροφορία

που είναι δημόσια διαθέσιμη (δηλαδή το δημόσιο κλειδί ),( ne )

Παρ’ όλες τις οποιεσδήποτε αδυναμίες του, o RSA συνεχίζει να θεωρείται

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

όταν πρόκειται για δεδομένα που μεταφέρονται στο Internet.

Αλγόριθμος Digital Signature Algorithm (DSA)

Ο αλγόριθμος DSA (Digital Signature Algorithm) προτάθηκε τον Αύγουστο

του 1991 από το NIST (National Institute of Standards and Technology) της

Αμερικής. Έχει προτυποποιηθεί ως FIPS 186 (Federal Information Processing

Standard). Το πρότυπο αυτό έχει ονομαστεί DSS (Digital Signature Standard)

30) και είναι ο πρώτος αλγόριθμος ψηφιακής υπογραφής που αναγνωρίστηκε

παγκόσμια. Ο DSA αποτελεί μια παραλλαγή του αλγορίθμου ElGamal για

ψηφιακές υπογραφές και σχεδιάστηκε αποκλειστικά για τη δημιουργία και

επαλήθευση ψηφιακών υπογραφών και κατά συνέπεια και για τον έλεγχο της

90

ακεραιότητας των δεδομένων. Η λογική του αλγορίθμου βασίζεται σε αυτήν

της ασύμμετρης κρυπτογραφίας, αφού και σε αυτήν την περίπτωση κάθε

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

που ακολουθούνται για την υλοποίηση του αλγορίθμου είναι τα παρακάτω:

1. Επιλέγεται ένας πρώτος αριθμός q τέτοιος ώστε 160159 22 << q

2. Επιλέγεται ένας αριθμός t τέτοιος ώστε 80 ≤≤ t και ένας πρώτος

αριθμός p τέτοιος ώστε tt p 6451264511 22 ++ << με την ιδιότητα ο q να

διαιρεί τον (p – 1)

3. phg qp mod/)1( −= , όπου h είναι ένας ακέραιος 11 −<< ph έτσι

ώστε 1mod/)1( >− ph qp .

4. Έστω x ένας τυχαίος ακέραιος έτσι ώστε 11 −≤≤ qx

5. Υπολογίζεται το pgy x mod=

6. Το δημόσιο κλειδί είναι το (p, q, g, y). Το ιδιωτικό κλειδί είναι το x.

Έχοντας υπολογίσει τις παραπάνω παραμέτρους μπορούμε να

δημιουργήσουμε μία ψηφιακή υπογραφή. Τα παρακάτω βήματα περιγράφουν

τον τρόπο με τον οποίο μπορεί να υπογραφεί ψηφιακά, σύμφωνα με τον

αλγόριθμο DSA, ένα μήνυμα m τυχαίου μήκους:

1. Επιλέγεται ένας τυχαίος ακέραιος k, qk <<0 . Ο ακέραιος k θα

πρέπει να μείνει μυστικός.

2. Υπολογίζεται το qpgr k mod)mod(= .

3. Υπολογίζεται το qk mod1− .

4. Υπολογίζεται το qxrmhks mod)(1 += − . Η ( )h m είναι μια συνάρτηση

κατακερματισμού (hash function).Πρόκείται για ένα αλφαριθμητικό

μήκους 160 bits που προκύπτει ως έξοδος του αλγορίθμου SHA-1 ο

οποίος περιγράφεται παρακάτω.

5. Η ψηφιακή υπογραφή για το μήνυμα m είναι το ζεύγος (r, s)

Από τη στιγμή που ένας χρήστης Α ενός επικοινωνιακού συστήματος έχει

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

91

συστήματος να είναι σε θέση να επαληθεύσουν την υπογραφή του. Αυτό

γίνεται με τη χρήση του δημοσίου κλειδιού του Α. Τα παρακάτω βήματα

περιγράφουν τη διαδικασία της επαλήθευσης μιας ψηφιακής υπογραφής:

1. Το δημόσιο κλειδί (p, q, g, y) του χρήστη Α είναι διαθέσιμο.

2. Επαληθεύεται ότι qr <<0 και qs <<0 . Αν δεν ισχύουν τα

παραπάνω η υπογραφή απορρίπτεται.

3. Υπολογίζεται qsw mod1−= και την ( )h m .

4. Υπολογίζεται το qmhwu mod)(1 ⋅= και το qrwu mod2 = .

5. Υπολογίζεται το qpyg uu mod)mod( 21=υ .

6. Η υπογραφή είναι αποδεκτή μόνο όταν r=υ .

Ασφάλεια του DSA

Η ασφάλεια του DSA βασίζεται στη δυσκολία του υπολογισμού διακριτών

λογαρίθμων μέσα σε ένα πεπερασμένο σώμα. Έρευνες πάνω στον αλγόριθμο

έχουν δείξει την ύπαρξη πρώτων αριθμών οι οποίοι θα μπορούσαν να

οδηγήσουν στη δημιουργία κλειδιών ευάλωτων σε επιθέσεις. Όμως, αυτοί οι

αριθμοί είναι ελάχιστοι και μπορούν εύκολα να αποφευχθούν σε μία σωστή

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

του αλγορίθμου το μέγεθος του q πρέπει να είναι 160 bits ενώ το μέγεθος του

p μπορεί να είναι οποιοδήποτε πολλαπλάσιο του 64 ανάμεσα στο 512 και το

1024. Ένας πρώτος αριθμός p μεγέθους 512 bit προστατεύει το σύστημα

οριακά από μια ενδεχόμενη επίθεση. Από το 1996 προτείνεται το μέγεθος του

p να είναι τουλάχιστον 768 bits. Το πρότυπο FIPS 186 δεν επιτρέπει πρώτους

αριθμούς p που το μέγεθός τους ξεπερνά τα 1024 bits.

Ένα σημαντικό πλεονέκτημα του DSA είναι ότι, η εκθετοποίηση ως

διαδικασία μπορεί να προηγείται της δημιουργίας της ψηφιακής υπογραφής,

κάτι που δεν είναι εφικτό με τον RSA.

92

Αλγόριθμος Diffie και Hellman

Ο πρώτος αλγόριθμος δημοσίου κλειδιού προτάθηκε το 1976 από τους

Diffie και Hellman. Ο αλγόριθμος αυτός, γνωστός ως DH, είναι αποκλειστικά

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

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

δημόσιο κλειδί της άλλης με σκοπό τη δημιουργία ενός συμμετρικού κλειδιού

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

οντότητες Α και Β θέλουν να επικοινωνήσουν. Τα βήματα που θα πρέπει να

ακολουθήσουν είναι τα παρακάτω:

1. Αρχικά επιλέγονται και δημοσιεύονται ένας κατάλληλος αριθμός p

και ένας αριθμός α έτσι ώστε 22 −≤≤ pa .

2. O Α διαλέγει ένα τυχαίο μυστικό αριθμό x, 21 −≤≤ px , και στέλνει

στον Β το μήνυμα pax mod . Το μήνυμα αυτό είναι η δημόσια τιμή

του Α

3. O Β διαλέγει ένα τυχαίο μυστικό αριθμό y, 21 −≤≤ py , και στέλνει

στον Β το μήνυμα pa y mod . Το μήνυμα αυτό είναι η δημόσια τιμή

του Β.

4. ο B λαμβάνει το xa και υπολογίζει το συμμετρικό κλειδί

paK yx mod)(= .

5. ο Α λαμβάνει το ya και υπολογίζει το συμμετρικό κλειδί

paK xy mod)(= .

Η ασφάλεια του πρωτοκόλλου προκύπτει από την δυσκολία υπολογισμού

των λογαρίθμων mod p εδικά στην περίπτωση που το p είναι μεγάλο.

Οι πρώτες εκδόσεις του μηχανισμού Diffie-Hellman ήταν ευάλωτες σε

επιθέσεις man-in-the-middle. Σε αυτή την επίθεση ο χρήστης C

παρεμβάλλεται στην επικοινωνία των Α και Β και όταν ανταλλάσσουν τις

δημόσιες τιμές τους τις αντικαθιστά με τις δικές του. Δηλαδή όταν ο Α

μεταδίδει την δημόσια τιμή του στον Β, ο C την αντικαθιστά με την δικιά του

και την στέλνει στον Β. Ομοίως όταν ο Β στέλνει την δημόσια τιμή του στον Α.

93

Σαν συνέπεια, οι C και Α συμφωνούν για ένα μυστικό κλειδί και οι C και Β

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

που μεταδίδουν ο Α στον Β και πιθανώς να τα τροποποιήσει πριν τα

προωθήσει σε έναν από τους δύο.

Το 1992 αναπτύχθηκε μία ανανεωμένη έκδοση από τους Diffie, Van

Oorschot και Wiener που υποστήριζε την πιστοποίηση της ταυτότητας των

δύο πλευρών και είχε σαν σκοπό να καταπολεμήσει την επίθεση man-in-the-

middle. Τα μηνύματα ανταλλάσσονται υπογεγραμμένα με τα ιδιωτικά κλειδιά

των Α και Β, ενώ χρησιμοποιούνται και πιστοποιητικά για την απόκτηση των

σωστών δημοσίων κλείδων. Έτσι, ακόμα και αν ο C είναι σε θέση να

παρακολουθεί την επικοινωνία των Α και Β, δεν μπορεί να πλαστογραφήσει

τα μηνύματα.

Αλγόριθμοι Ελλειπτικών Καμπυλών

Το 1985, οι Neal Koblitz και V. S. Miller πρότειναν ανεξάρτητα ο ένας από

τον άλλον την λεγόμενη κρυπτογραφία ελλειπτικών καμπυλών (Elliptic Curve

Cryptography). Η Κρυπτογραφία Ελλειπτικών Καμπυλών βασίζεται στο

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

αλγόριθμος που να επιλύει το πρόβλημα αυτό σε μια κατάλληλα επιλεγμένη

ελλειπτική καμπύλη (ECDLP). Η Κρυπτογραφία Ελλειπτικών Καμπυλών

βρίσκει εφαρμογή με τη χρήση των αλγορίθμων DSA και DH ελλειπτικών

καμπυλών (ECDSA και ECDH). Οι αλγόριθμοι ECDSA και ECDH

υλοποιούνται κάνοντας χρήση ενός συνόλου σημείων, που προκύπτουν ως

λύση της εξίσωσης μιας ελλειπτικής καμπύλης πάνω σε ένα πεπερασμένο

σώμα (finite field). Η ασφάλειά τους βασίζεται στη δυσκολία του υπολογισμού

λογαρίθμων πάνω σε ένα σύνολο σημείων ελλειπτικής καμπύλης.

Λαμβάνοντας υπόψη της το πρόβλημα του διακριτού λογαρίθμου σε μια

ελλειπτική καμπύλη, η μέχρι σήμερα έρευνα στον τομέα της κρυπτογραφίας

έχει δείξει ότι το μήκος των κλειδιών που παράγονται από τους αλγόριθμους

ECDSA και ECDH θα πρέπει να είναι τουλάχιστον 192 bits προκειμένου να

εξασφαλίζεται επαρκής ασφάλεια στα συστήματα επικοινωνίας τα επόμενα

χρόνια.

94

Ο αλγόριθμος ECDSA είναι ένας κατά FIPS (Federal Information

Processing Standard) εγκεκριμένος αλγόριθμος για δημιουργία και

επαλήθευση ψηφιακών υπογραφών. Ο ECDSA περιγράφεται στο ANSI X9.62

33). Ας σημειωθεί επίσης ότι είναι δυνατόν να υλοποιηθεί και ο RSA ως

αλγόριθμος ελλειπτικής καμπύλης. Όμως, η βάση της ασφάλειας αυτού του

αλγορίθμου είναι η δυσκολία παραγοντοποίησης μεγάλων ακεραίων και όχι το

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

να μην είναι σημαντικά μικρότερο από αυτό του συνηθισμένου RSA. Έτσι, η

πρόσθετη πολυπλοκότητα δεν έχει κάποιο σημαντικό όφελος, με αποτέλεσμα

η χρήση του ECRSA να είναι ιδιαίτερα περιορισμένη.

4.3 Συναρτήσεις Κατακερματισμού (Hash Functions)

Ο όρος συνάρτηση κατακερματισμού (hash function) υποδηλώνει ένα

μετασχηματισμό Η ο οποίος παίρνει ως είσοδο ένα μήνυμα m ανεξαρτήτου

μήκους και δίνει ως έξοδο μία ακολουθία χαρακτήρων h, είναι δηλαδή

)(mHh = . Η έξοδος h μιας συνάρτησης κατακερματισμού ονομάζεται τιμή

κατακερματισμού (hash value) ή σύνοψη μηνύματος (message digest) και έχει

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

που χρησιμοποιείται, συνήθως πολύ μικρότερο από αυτό του αρχικού

μηνύματος (σχήμα 2.3). Μπορούμε να φανταστούμε την σύνοψη μηνύματος

ως το “ψηφιακό αποτύπωμα” (“digital fingerprint”) του εγγράφου.

C8235A B 4DE

ΜήνυμαΣυνάρτηση κατακερματισμού

Σύνοψη Μηνύματος

Σχήμα: Συνάρτηση κατακερματισμού

Οι σημαντικότερες ιδιότητες των συναρτήσεων κατακερματισμού με μορφή

)(xHy = είναι:

95

• Η είσοδος x μπορεί να έχει οποιοδήποτε μήκος

• Η έξοδος y έχει περιορισμένο μήκος

• Δεδομένου του x και της συνάρτησης H είναι εύκολος ο υπολογισμός

του Η(x)

• Η Η(x) είναι μονόδρομη (one way function)

• H Η(x) είναι αμφιμονοσήμαντη (συνάρτηση ένα προς ένα)

Μια μονόδρομη συνάρτηση κατακερματισμού είναι μία συνάρτηση

κατακερματισμού για την οποία είναι υπολογιστικά ανέφικτο να υπολογιστεί η

αντίστροφή της, δηλαδή το αρχικό μήνυμα δεν μπορεί να ανακτηθεί από τη

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

πολύ δύσκολο να βρεθούν δύο διαφορετικά μηνύματα με την ίδια σύνοψη.

Στην περίπτωση που κάτι τέτοιο συμβεί τότε υπάρχει σύγκρουση (collision) .

Οι πιο γνωστοί αλγόριθμοι κατακερματισμού είναι οι MD5 με σύνοψη 128

bit, o SHA-1 με σύνοψη 160 bits και ο RIPEMD-160 με σύνοψη 160 bits. Οι

νέες εκδόσεις του αλγορίθμου SHA, SHA-256, SHA-384 και SHA-512 δίνουν

σύνοψη μηνύματος 256, 384 και 512 bits αντίστοιχα.

Αλγόριθμος Κατακερματισμού Secure Hash Algorithm-1 (SHA-1)

Ο ασφαλής αλγόριθμος κατακερματισμού SHA-1 (Secure Hash Algorithm-

1) αποτελεί μια βελτιωμένη έκδοση του αρχικού αλγορίθμου κατακερματισμού

SHA. Αυτός ο αλγόριθμος κατακερματισμού (hash algorithm) σχεδιάστηκε

αποκλειστικά για χρήση σε συνδυασμό με τον DSA και συνεπώς δεν μπορεί

να χρησιμοποιηθεί με τον RSA ή οποιοδήποτε άλλο αλγόριθμο δημοσίου

κλειδιού για ψηφιακή υπογραφή. Οι σχεδιαστικές αρχές του SHA-1 είναι

παρεμφερείς με αυτές των συναρτήσεων κατακερματισμού MD2, MD4, και

κυρίως της συνάρτησης MD5 .

Ο αλγόριθμος μπορεί να έχει ως είσοδο μηνύματα μήκους μικρότερου από 642 bits. Η έξοδος του αλγορίθμου ονομάζεται σύνοψη μηνύματος (message

digest ή hash value ή message fingerprint) και έχει μήκος 160 bit. Είναι πιο

αργός από τον MD5 αλλά το μεγαλύτερο message digest που παράγει (ο

96

MD5 παράγει message digest μήκους 128 bits) τον καθιστούν πιο ισχυρό σε

προσπάθειες αντιστροφής του.

Οι συναρτήσεις κατακερματισμού περιγράφονται αναλυτικά στην επόμενη

ενότητα

4.4 Υπηρεσίες

Με τη χρήση της κρυπτογραφίας δημοσίου κλειδιού εισήχθηκαν στα δίκτυα

επικοινωνιών νέες υπηρεσίες οι οποίες ήταν, είτε αδύνατες, είτε πολύ

δύσκολα επιτεύξιμες με τη χρήση της συμμετρικής κρυπτογραφίας. Σε αυτήν

την ενότητα αναλύονται μερικές από τις σημαντικότερες και πιο

ενδιαφέρουσες υπηρεσίες.

Ασφάλεια μεταξύ ξένων οντοτήτων

Ένα από τα σημαντικότερα κίνητρα πίσω από τη δημιουργία της

κρυπτογραφίας δημοσίου κλειδιού ήταν η έμφυτη δυσκολία της επίτευξης μιας

ασφαλούς επικοινωνιακής ζεύξης μεταξύ αγνώστων οντοτήτων σε ένα

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

δυσκολίας υπολογισμού του ιδιωτικού κλειδιού, ακόμα και αν όλες οι

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

ευρεία διάδοση του δημοσίου κλειδιού κάθε χρήστη που συμμετέχει σε ένα

τέτοιο σύστημα. Για παράδειγμα, κάθε δημόσιο κλειδί μπορεί να αποθηκευτεί

σε ένα χώρο, που μπορεί να ονομαστεί αποθήκη κλειδιών, εύκολα

προσβάσιμο από τον οποιοδήποτε (αφαιρετικά, αυτός ο χώρος αποθήκευσης

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

Ας πάρουμε για παράδειγμα δύο χρήστες, τους Α και Β. Ακόμα και αν ο Α δεν

έχει επικοινωνήσει ποτέ ξανά με τον B, μπορεί να βρει το δημόσιο κλειδί του

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

προϋπόθεση ότι ο Α αισθάνεται σίγουρος πως το δημόσιο κλειδί που βρίσκει,

ανήκει πράγματι στον Β. Υπάρχουν γενικά δύο μηχανισμοί για να επιτευχθεί

κάτι τέτοιο:

97

• Ο Α εμπιστεύεται την αποθήκη κλειδιών. Αυτό σημαίνει ότι ο Α είναι

σίγουρος ότι η αποθήκη κλειδιών είναι αξιόπιστη και θα του επιστρέψει

τη σωστή πληροφορία που ζήτησε.

• Ο Α εμπιστεύεται την πληροφορία. Ακόμα και αν η αποθήκη είναι

αναξιόπιστη, η πληροφορία που παρέχει μπορεί ανεξάρτητα να

ελεγχθεί ως προς την ακρίβειά της.

Είναι κατανοητό πως στον ηλεκτρονικό κόσμο οι αποθήκες δημοσίων

κλειδιών είναι κατά κανόνα αναξιόπιστες ως προς τις πληροφορίες που

επιστρέφουν. Γι’ αυτό το λόγο καθίσταται σημαντικό, οι πληροφορίες να

μπορούν να είναι ανεξάρτητα επαληθεύσιμες. Ένας μηχανισμός για την

επίτευξη αυτού του σκοπού είναι τα πιστοποιητικά δημοσίου κλειδιού τα οποία

περιγράφονται αναλυτικά στη παράγραφο.

Κρυπτογράφηση

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

δεδομένα με το δημόσιο κλειδί. Στη συνέχεια το κρυπτογραφημένο κείμενο

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

έχει ήδη αναφερθεί, αυτοί οι αλγόριθμοι είναι εξαιρετικά αργοί και για αυτό το

λόγο πρακτικά μη εφαρμόσιμοι σε πολλά συστήματα επικοινωνίας. Το

πρόβλημα αυτό μπορεί να λυθεί με τη χρήση της κρυπτογραφίας ψηφιακού

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

απλή χρήση της κρυπτογραφίας δημοσίου κλειδιού παρέχει εμπιστευτικότητα

αλλά όχι αυθεντικότητα και ακεραιότητα. Ας πάρουμε πάλι το παράδειγμα

όπου ο Α στέλνει ένα μήνυμα στον Β. Ο Α κρυπτογραφεί το μήνυμά του με το

δημόσιο κλειδί του Β και ο Β το αποκρυπτογραφεί με το ιδιωτικό κλειδί του.

Αυτή η μέθοδος δεν παρέχει καμία εγγύηση ότι το μήνυμα προέρχεται

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

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

μόνο ο Β μπορεί να αποκρυπτογραφήσει το μήνυμα.

Για να πιστοποιήσει την αυθεντικότητά του, ο Α θα πρέπει να

κρυπτογραφήσει το μήνυμά του με το ιδιωτικό κλειδί του και ο Β να το

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

98

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

πιστοποίηση αυθεντικότητας του αποστολέα αλλά όχι το απόρρητο του

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

Για την εξασφάλιση τόσο του απορρήτου όσο και της αυθεντικότητας ο Α

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

Έτσι εξασφαλίζει την πιστοποίηση αυθεντικότητας. Στη συνέχεια θα πρέπει να

κρυπτογραφήσει το ήδη κρυπτογραφημένο μήνυμα με το δημόσιο κλειδί του B

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

παραπάνω μεθόδου είναι ότι είναι αρκετά χρονοβόρα και πολύπλοκη αφού η

κρυπτογράφηση και αποκρυπτογράφηση θα πρέπει συνολικά να γίνει

τέσσερις φορές και το μέγεθος του δημοσίου κλειδιού που απαιτείται είναι

πολύ μεγάλο (από 1024 ως 4096 bits).

Ψηφιακή υπογραφή (digital signature)

Η κρυπτογραφία δημοσίου κλειδιού έκανε δυνατή την υλοποίηση μιας

εφαρμογής η οποία ήταν δύσκολα επιτεύξιμη με τη χρήση της συμβατικής

συμμετρικής κρυπτογραφίας. Πρόκειται για την υπηρεσία της ψηφιακής

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

για τον πραγματικό.

Μια απλή εφαρμογή της κρυπτογραφίας δημοσίου κλειδιού εξασφαλίζει το

απόρρητο των δεδομένων όταν αυτά μεταφέρονται μέσα σε ένα δίκτυο

επικοινωνιών. Η χρήση της ψηφιακής υπογραφής έρχεται να καλύψει το κενό

των υπόλοιπων τριών τομέων ασφάλειας, δηλαδή της πιστοποίησης

αυθεντικότητας, του ελέγχου ακεραιότητας και της μη αποκήρυξης. Η μέθοδος

της ψηφιακής υπογραφής περιγράφεται αναλυτικά στη παράγραφο.

Ανταλλαγή κλειδιών (key exchange)

Η κρυπτογραφία δημοσίου κλειδιού μπορεί να χρησιμοποιηθεί και για την

ανταλλαγή κλειδιών μεταξύ δύο οντοτήτων. Αυτό σημαίνει ότι ένα

πρωτόκολλο μπορεί να χρησιμοποιεί δημόσια και ιδιωτικά κλειδιά έτσι ώστε,

99

κατά τη λήξη του πρωτοκόλλου, οι δύο οντότητες να μοιράζονται ένα

συμμετρικό κλειδί άγνωστο σε κάθε άλλη οντότητα.

Η ανταλλαγή κλειδιών μπορεί να πραγματοποιηθεί με δύο τρόπους:

• Κατά τη μεταφορά κλειδιού (key transfer) η μία οντότητα παράγει το

συμμετρικό κλειδί και το στέλνει στην δεύτερη οντότητα. Η

κρυπτογραφία δημοσίου κλειδιού μπορεί να χρησιμοποιηθεί για να

προστατέψει το απόρρητο της συγκεκριμένης μεταφοράς.

• Κατά τη συμφωνία κλειδιού (key agreement) και οι δύο οντότητες

συμβάλουν στη δημιουργία του συμμετρικού κλειδιού. Η κρυπτογραφία

δημοσίου κλειδιού κάνει αυτή τη διαδικασία πολύ απλή σε σύγκριση με

τη χρήση της συμμετρικής κρυπτογραφίας.

100

5. Προτεινόμενο Σύστημα

Το σύστημα που προτείνεται είναι ένα σύστημα ανταλλαγής πληροφορίας

που στηρίζεται στο SSL για την μετάδοση της κρίσιμης πληροφορίας.

Ουσιαστικά αποτελεί την τυπική λύση για μεταφορά πληροφορίας, με τη

διαφορά ότι αντί να επικοινωνούμε με τον χρήστη με SSL, χρησιμοποιούμε

WTLS που είναι πιο κατάλληλο για κινητά τερματικά.

Συγκεκριμένα θέλουμε να δημιουργήσουμε ένα σύστημα που θα επιτρέπει

σε την ασφαλή ανταλλαγή πληροφορίας μεταξύ ενός χρήστη και ενός

παρόχου κάποιας υπηρεσίες. Στο σενάριο που εξετάζουμε, ο πάροχος

υπηρεσιών παρέχει τις υπερεσίες αυτές μέσο διαδυκτίου. Το σύστημά μας

αναλαμβάνει να μεταφέρει την κρίσιμη πληροφορία του πελάτη που

χρησιμοποιεί το κινητό του τερματικό στον πάροχο της υπηρεσίας,

διασφαλίζοντας την ιδιοτικότητα της πληροφορίας του πελάτη.

Επιπλέον, στο server μας μπορούμε να συμπεριλάβουμε όποιες υπηρεσίες

επιπρόσθετης αξίας θέλουμε, όπως αυτόματη συμπλήρωση πεδίων. Δηλαδή

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

χρήστες μας, δημιουργώντας λογαριασμούς για αυτούς στο σύστημά μας,

ώστε να μην χρειάζεται να συμπληρώνουν κάθε φόρα όλα τα πεδία που

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

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

συγκεκριμένο χαρακτηριστικό είναι ιδιαίτερα θεμιτό στις εφαρμογές για κινητά

τερματικά, δεδομένης της δυσκολίας που αντιμετωπίζουν οι χρήστες τους

στην πληκτρολόγηση, λόγο της ιδιομορφίας του πληκτρολογίου. Τέλος

μπορούμε να συνδέσουμε τις συναλλαγές με τον αριθμό του κινητού του

χρήστη, αποκτώντας ένα στοιχείο πιστοποίησης του χρήστη.

101

5.1 Αρχιτεκτονική Συστήματος

Στο παραπάνω σχήμα φαίνεται η αρχιτεκτονική του συστήματος

ανταλλαγής πληροφορίας. Για την επικοινωνία ανάμεσα στη σύστημά μας και

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

στη χρήση κάποιου ‘plug-in’ που παρέχεται από το πάροχο υπηρεσιών. Το

μοντέλο αυτό συχνά το καλούμε ‘API’ μοντέλο και είναι αυτό στο οποίο θα

στηριχτούμε. Η δεύτερη μορφή είναι με τη χρήση υπερ-συνδέσμων, ώστε ο

χρήστης να ανακατευθυνθεί στο δικτυακό τόπου του παρόχου. Το μοντέλο

αυτό συχνά καλείται ‘URL’ μοντέλο. Είναι εμφανές ότι το δεύτερο αυτό

μοντέλο δε μας βολεύει, αφού στην περίπτωση αυτή ο πάροχος θα έπρεπε να

υποστηρίζει και τα ανάλογα πρωτόκολλα για επικοινωνία με κινητά τερματικά

μέσο WAP.

Επιλέγοντας το πρώτο μοντέλο η συναλλαγή έχει ως εξής:

• Ο χρήστης επιλέγει με ποίο πάροχο θέλει να ανταλλάξει πληροφορία.

Για την επικοινωνία αυτή μπορούμε να χρησιμοποιήσουμε ασθενή ή και

καθόλου κρυπτογράφηση.

• Ο χρήστης αποστέλλει τα δεδομένα που θέλει στον πάροχο. Για την

επικοινωνία αυτή χρησιμοποιούμε ισχυρή κρυπτογράφηση 56 έως 128

Open System

Server Plugin

Server Gateway

End Server

User

SSL 128bits

WTLS

102

bits μέσο WTLS ανάλογα με τις δυνατότητες της τερματική συσκευής

του χρήστη.

• Μέσο του plug-in περνάμε στην πύλη του παρόχου την κρίσιμη

πληροφορία του πελάτη.. Χρήση ισχυρής κρυπτογράφησης SSL 128

bits για την αποστολή των στοιχείων της συναλλαγής στην τράπεζα.

• Ολοκλήρωση της συναλλαγής με τον χρήστη.

Από τα σημαντικότερα στοιχεία του συστήματός μας είναι η επικοινωνία με

τον χρήστη. Η ιδιαιτερότητά είναι ότι ο χρήστης χρησιμοποιεί κάποιο κινητό

τερματικό και συνδέεται μαζί μας μέσο της υπηρεσίας Internet που του

προσφέρει ο πάροχος κινητής τηλεφωνίας. Για την ασφάλεια της σύνδεσης

αυτής θα χρησιμοποιήσουμε WTLS. Το WTLS είναι ένα πρωτόκολλο

ασφάλειας που βασίζεται στην τυποποίηση TLS (πρωτόκολλο ασφαλείας

επιπέδου, πιο παλιά γνωστό ως Secure Sockets Layer - SSL). Το WTLS

προορίζεται για χρήση με τα πρωτόκολλα δοσοληψιών του WAP και έχει

τροποποιηθεί, ώστε να είναι κατάλληλο για χρήση σε τηλεπικοινωνιακά

κανάλια μικρού εύρους. Βρίσκεται ανάμεσα στα επίπεδα WTP και WDP και

είναι υπεύθυνο για την ασφάλεια του επιπέδου δοσοληψίας ανάμεσα σε ένα

WAP πελάτη και σε μια WAP πύλη. Η πιο σημαντική λειτουργία του WTLS

είναι ότι διασφαλίζει τη μετάδοση των δεδομένων από την παρέμβαση τρίτων

και ότι εγγυάται το γεγονός ότι τα δεδομένα είναι ιδιωτικά.

Το κομβικό σημείο σε μία δοσοληψία WTLS είναι η πύλη WAP (WAP

gateway). Η θέση της πύλης WAP στο δίκτυο είναι αρκετή σημαντική. Για την

δική μας περίπτωση προτείνεται η WAP πύλη να βρίσκεται στον παροχέα

υπηρεσιών κινητών επικοινωνιών όπως φαίνεται στο σχήμα που

ακολουθείται:

Customer

Mobile Terminal

Mobile Services Provider

WAP Gateway

End Server

Service Provider

WTLS SSL

103

Βλέπουμε ότι ο χρήστης συνδέεται στο ασύρματό κομμάτι με το WAP

gateway του παρόχου υπηρεσιών κινητής τηλεφωνίας χρησιμοποιώντας

WAP/WTLS. Το WAP gateway συνδέεται με ενσύρματο κανάλι με τον

εξυπηρετητή του εμπόρου χρησιμοποιώντας HTTP/SSL. Τα δεδομένα

μεταδίδονται κρυπτογραφημένα με WTLS στο WAP gateway, εκεί

αποκρυπτογραφούνται και επανακρυπτογραφούνται με SSL για να σταλούν

στο εξυπηρετητή του εμπόρου.

Η άλλη δυνατότητα που υπάρχει είναι η πύλη WAP να βρίσκεται σε εμάς.

Από τεχνικής απόψεως και σε σχέση με τις προδιαγραφές ασφαλείας, η

δεύτερη λύση είναι αρτιότερη, αλλά προσθέτει κόστος αγοράς, εγκατάστασης

και συντήρησης της πύλης WAP, ενώ αυξάνει και την πολυπλοκότητα της

επικοινωνίας με τον πελάτη, καθώς η πύλη WAP του παροχέα υπηρεσιών

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

πύλη WAP.

5.2 Αδυναμίες Ασφαλείας

Η μεγαλύτερη αδυναμία ασφαλείας του WTLS εντοπίζεται στο ότι

υποστηρίζονται από αυτό και ασθενή πρωτόκολλα κρυπτογράφησης (40 bits

κρυπτογράφησης) ή και καθόλου κρυπτογράφηση. Συγκεκριμένα, κατά την

χειραψία συμφωνείται ανάμεσα στο WAP gateway και τη συσκευή του χρήστη

το πρωτόκολλο κρυπτογράφησης. Η συσκευή προτείνει μια σειρά από

υποστηριζόμενα πρωτόκολλα και το WAP gateway αποφασίζει ποιο από αυτά

θα χρησιμοποιηθεί. Αν η συσκευή προτείνει μόνο ασθενή ή καθόλου

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

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

χρήστη να κινδυνεύει. Εμείς θα προτιμούσαμε να απορριφθεί η σύνδεση και

να προταθεί στον χρήστη να χρησιμοποιήσει κάποιον άλλο τρόπο για να

αποστείλει την κρίσιμη πληροφορία του, ή τουλάχιστον να τον ενημερώσουμε

για τον κίνδυνο που διατρέχει. Αφού η πύλη WAP βρίσκεται στον πάροχο

κινητής τηλεφωνίας, ο χειρισμός τέτοιων καταστάσεων εξαρτάται κυρίως από

αυτόν.

104

Ένα άλλο θέμα αφορά την αποκρυπτογράφηση και επανακρυπτογράφηση

των δεδομένων στην πύλη WAP, αφού αν αυτή πέσει θύμα επίθεσης, θα

μπορούσαμε να έχουμε διαρροή της κρίσιμης πληροφορίας. Γενικά η πύλη

WAP του παρόχου δεν είναι τόσο ευαίσθητη, αφού συνήθως βρίσκεται πίσω

από ‘firewall’.

Τα παραπάνω προβλήματα θα μπορούσαν να λυθούν σε επίπεδο

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

υπολογιστική ισχύ και χρόνο προετοιμασίας (set up time) για τον πελάτη δεν

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

Για άλλες πάλι, όπου η κρίσιμη πληροφορία του χρήστη είναι ιδιαίτερης

σημασίας, όπως στην περίπτωση αποστολής βιοϊατρικών δεδομένων ενός

ασθενούς, end-to-end κρυπτογράφηση σε επίπεδο εφαρμογής είναι

προτεινόμενη.

Τέλος, στόχος επίθεσης θα μπορούσε να είναι και ο δικός μας

εξυπηρετητής. Για το λόγο αυτό η ασφάλειά του αποτελεί ένα σημαντικό

κομμάτι. Η χρήση ‘firewall’ στα σημεία σύνδεσης με το Internet είναι

επιβεβλημένη. Επιπλέον η ευαίσθητη πληροφορία του πελάτη θα πρέπει να

διατηρείται στον εξυπηρετητή μας όσο το δυνατόν λιγότερο. Αν η κρίσιμη

πληροφορία του πελάτη αποθηκεύεται στο σύστημά μας, θα πρέπει να

αποθηκεύεται κρυπτογραφημένη σε κάποια βάση δεδομένων, ώστε ακόμα και

αν ο εξυπηρετητής μας γίνει στόχος επίθεσης, ο πιθανός εισβολέας να μην

μπορεί να ανακτήσει την συγκεκριμένη πληροφορία.

5.3 Προστασία της ευαίσθητης πληροφορίας του χρήστη

Όπως αναφέρθηκε προηγουμένως, στόχος επίθεσης θα μπορούσε να

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

κάποια μέτρα προστασίας, όπως να τοποθετήσουμε τον εξυπηρετητή μας

πίσω από κάποιο ‘firewall’, ώστε να μην είναι ευάλωτος σε επιθέσεις.

Επιπλέον, θα πρέπει να διασφαλίζουμε ότι ακόμα και αν το σύστημά μας

105

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

ευαίσθητη πληροφορία του πελάτη μας. Η λύση που προτείνεται για το

πρόβλημα αυτό, είναι η κρυπτογράφηση της ευαίσθητης πληροφορίας του

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

5.4 Κρυπτογράφηση και αποκρυπτογράφηση

Κρυπτογράφηση είναι η διαδικασία κατά την οποία παίρνεις κάποια

δεδομένα και τα μετασχηματίζεις, έτσι ώστε τα καινούρια δεδομένα να μην

εμφανίζουν νόημα σε κάποιον τρίτο. Η αντίστροφη διαδικασία, δηλαδή η

ανάκτηση της αρχικής πληροφορίας από το κρυπτόγραμμα, ονομάζεται

αποκρυπτογράφηση. Η κρυπτογράφηση και αποκρυπτογράφηση

χρησιμοποιούν κάποια κρυφή πληροφορία, που συχνά ονομάζεται κλειδί.

Application Server

DB

Encryption Module

Firewall

Internet

Open System

106

5.4.1 Κρυπτογράφηση ασύμμετρου κλειδιού

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

χρησιμοποιούν, σε κρυπτογραφία ασύμμετρου και συμμετρικού κλειδιού. Η

πρώτη κατηγορία χρησιμοποιεί διαφορετικό κλειδί για την κρυπτογράφηση, το

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

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

σύνηθες είναι οι ενδιαφερόμενοι να μοιράζουν το δημόσιο κλειδί τους στα

μέλη με τα οποία θέλουν να επικοινωνήσουν. Έτσι σε μία επικοινωνία, ο

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

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

αποκρυπτογραφεί χρησιμοποιώντας το ιδιωτικό κλειδί του, που μόνο αυτός

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

εύρεσης του ιδιωτικού κλειδιού από το δημόσιο κλειδί. Χαρακτηριστικό

παράδειγμα κρυπτογραφικού σχήματος ασύμμετρου κλειδιού είναι το RSA,

που προτάθηκε το 1977 από τους Ron Rivest, Adi Shamir και Leonard

Adleman.

5.4.2 Κρυπτογράφηση συμμετρικού κλειδιού

Στα κρυπτογραφικά σχήματα συμμετρικού κλειδιού, χρησιμοποιείται το ίδιο

κλειδί για την κρυπτογράφηση και την αποκρυπτογράφηση των δεδομένων.

Το κλειδί αυτό ονομάζεται κρυφό κλειδί. Παραδείγματα κρυπτογραφικών

αλγορίθμων συμμετρικού κλειδιού είναι οι DES (Digital Encryption Standard),

DESede (Triple DES Encryption), Blowfish (σχεδιασμένος από τον Bruce

Schneier) και AES (Advanced Encryption Standard) που αποτελεί το νέο

στάνταρ για κρυπτογράφηση της NIST (National Institute of Standards and

Technology) των ΗΠΑ.

107

5.4.3 Σύγκριση κρυπτογράφησης ασύμμετρου και συμμετρικού κλειδιού

Γενικά τα κρυπτογραφικά συστήματα συμμετρικού κλειδιού προσφέρουν

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

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

χρησιμοποιούνται για επικοινωνία ανάμεσα σε δύο μέρη, αφού τα δύο μέρη

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

συχνά μεταδίδοντας ο ένας στον άλλο το κλειδί αυτό. Υπάρχει πληθώρα

λύσεων για το πρόβλημα αυτό. Οι λύσεις αυτές ξεφεύγουν από τους σκοπούς

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

Εμείς θα κρυπτογραφήσουμε και θα αποκρυπτογραφήσουμε τα δεδομένα

(την ευαίσθητη πληροφορία του πελάτη μας), κατά την αποθήκευσή της, ώστε

κάποιος που θα εισβάλει στην βάση δεδομένων μας να μην μπορεί να

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

Από τα παραπάνω συμπεραίνουμε ότι για την περίπτωσή μας ενδείκνυται

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

5.4.4 Ο αλγόριθμος κρυπτογράφησης AES

Θα επιλέξουμε τον AES μια και αποτελεί το νέο πρότυπο κρυπτογράφησης

που χρησιμοποιείται από το αμερικανικό δημόσιο. Το βασικότερο

πλεονέκτημά του σε σχέση με το DES που αποτέλεσε το προηγούμενο

πρότυπο κρυπτογράφησης που χρησιμοποιήθηκε από το αμερικανικό

δημόσιο είναι ότι ο DES υποστηρίζει μόνο κλειδιά μήκους 56bit, ενώ ο AES

υποστηρίζει κλειδιά των 128, 192 και 256bits. Γενικά ο AES είναι από τους

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

108

5.5 Διαχείριση κρυφού κλειδιού

Το επόμενο πρόβλημα που προκύπτει αφορά το κρυφό κλειδί.

Συγκεκριμένα, αφού δημιουργήσουμε κάποιο κρυφό κλειδί και

κρυπτογραφήσουμε την κρίσιμη πληροφορία, θα πρέπει είτε να α)

αποθηκεύσουμε κάπου αυτό το κλειδί, ώστε να μπορούμε να το

χρησιμοποιήσουμε κατά την αποκρυπτογράφηση της πληροφορίας, είτε β) να

μπορούμε να ξαναδημιουργήσουμε το ίδιο κλειδί.

5.5.1 Αποθήκευση του κρυφού κλειδιού, προβλήματα και λύσεις

Στην πρώτη περίπτωση, αν κάποιος αποκτήσει πρόσβαση στο σύστημά

μας και βρει που είναι αποθηκευμένο το κρυφό κλειδί θα μπορούσε να το

χρησιμοποιήσει για να ανακτήσει την κρίσιμη πληροφορία από τα

κρυπτογραφημένα δεδομένα που έχουμε αποθηκεύσει στη βάση δεδομένων.

o Προστασία του κλειδιού με κωδικό (password)

Για να προσθέσουμε επιπλέον ασφάλεια στο σύστημα μπορούμε να

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

προστατεύσουμε με κάποιο password. Η εφαρμογή προφανώς θα πρέπει να

έχει πρόσβαση με κάποιο τρόπο στο password αυτό, ώστε να μπορεί να

ανακτήσει το κρυφό κλειδί όταν το χρειάζεται.

o Διαχείριση κωδικού

• Μία λύση θα ήταν η εφαρμογή να ζητάει τον κωδικό κάθε φορά που τον

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

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

δημιουργήσουμε ένα αυτόματο σύστημα πληρωμών, και επομένως η

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

109

• Μια άλλη επιλογή είναι να ζητάει τον κωδικό από τον διαχειριστή του

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

αλλά περιορίζει το σύστημα. Το σύστημα δεν θα μπορεί να επανεκκινείται

αυτόματα, αλλά θα απαιτείται η παρουσία κάποιου διαχειριστή κατά την

επανεκκίνηση. Επιπλέον ο κωδικός θα πρέπει είτε να διατηρείται στη

μνήμη του συστήματος, είτε να αποθηκεύεται σε κάποιο αρχείο. Η πρώτη

περίπτωση εμπεριέχει τον κίνδυνο κάποιος να «επιτεθεί» στην εφαρμογή

και να την ξεγελάσει ώστε αυτή να του δώσει τον κωδικό. Η δεύτερη λύση

αναιρεί την ανάγκη να δίνεται ο κωδικός από κάποιο διαχειριστή του

συστήματος, αφού το σύστημα κατά την επανεκκίνησή του θα μπορούσε

να ανακτήσει τον κωδικό από το αρχείο στο οποίο είναι αποθηκευμένος.

Γενικά, ο περιορισμός για παρουσία κάποιου διαχειριστή κατά την

επανεκκίνηση, παρόλο που είναι λογικός, δεν αποτελεί ιδανική λύση.

• Από τα παραπάνω, οδηγούμαστε στο συμπέρασμα ότι είναι πιο πρακτικό

ο συγκεκριμένος κωδικός να παράγεται από το σύστημα και να

αποθηκεύεται σε κάποιο αρχείο. Το βασικότερο μειονέκτημα αυτής της

επιλογής είναι πως αν κάποιος έχει πρόσβαση στο σύστημά μας, μπορεί

δυνητικά να βρει τη δομή βάσεως δεδομένων στην οποία είναι

αποθηκευμένο το κλειδί και τον κωδικό που το προστατεύει σε κάποιο

αρχείο, και επομένως να το ανακτήσει. Έχοντας πρόσβαση και στην βάση

δεδομένων μπορεί πλέον να αποκρυπτογραφήσει την κρίσιμη πληροφορία

του πελάτη χρησιμοποιώντας το κλειδί αυτό. Μία προσέγγιση είναι να

κωδικοποιούμε με κάποιο συμμετρικό τρόπο τον κωδικό πριν τον

αποθηκεύσουμε στο αρχείο. Αυτό μπορεί να επιτευχθεί είτε

χρησιμοποιώντας κάποιο σταθερό αλφαριθμητικό (υλοποιημένο μέσα στον

κώδικα) και κάνοντας XOR του αλφαριθμητικού με τον κωδικό, είτε

κρυπτογραφώντας τον κωδικό με κάποιο αλγόριθμο συμμετρικού κλειδιού

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

μπορέσει να ανακτήσει το τελικό κλειδί χρειάζεται και πρόσβαση στα

εκτελέσιμα αρχεία, ή στον πηγαίο κώδικα. Επομένως για να αποκτήσει

κάποιος την κρίσιμη πληροφορίας του πελάτη χρειάζεται πρόσβαση στην

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

συγκεκριμένα στην δομή που είναι αποθηκευμένο το κλειδί, στο αρχείο με

110

τον κωδικό που προστατεύει το κλειδί και στα εκτελέσιμα αρχεία ή στον

πηγαίο κώδικα του συστήματος.

Γίνεται φανερό ότι το σενάριο που εξετάζουμε είναι κάπως ακραίο. Για να

μπορεί κάποιος να προσπελάσει την βάση δεδομένων, το σύστημα αρχείων

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

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

όλων των κωδικών ασφαλείας ή να παραβιάσει τα firewall του συστήματος και

να καταφέρει να αποκτήσει πλήρη πρόσβαση στο σύστημά μας, δηλαδή να

παραβιάσει και όλους τους κωδικούς ασφαλείας.

5.5.2 Επαναδημιουργία του ίδιου κλειδιού.

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

ξαναδημιουργήσουμε το ίδιο κρυφό κλειδί, δεν χρειάζεται να το

αποθηκεύσουμε.

Μια απλοϊκή προσέγγιση είναι να φροντίσουμε η εφαρμογή μας να

δημιουργεί πάντα το ίδιο κρυφό κλειδί. Προφανώς αυτό δεν είναι αποδεκτό,

αφού όλα τα συστήματα που θα χρησιμοποιούν την εφαρμογή θα έχουν ένα

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

αρχεία και την πληροφορία της βάσης, έχει αυτομάτως πρόσβαση στην

κρίσιμη πληροφορία.

Το επόμενο βήμα είναι να αναζητήσουμε ένα τρόπο για να δημιουργούμε

κατά την αποκρυπτογράφηση, το ίδιο κλειδί που δημιουργήσαμε για να

κρυπτογραφήσουμε την κρίσιμη πληροφορία. Αυτό σημαίνει ότι αναζητούμε

ένα συστηματικό τρόπο για δημιουργία κλειδιών κατά την κρυπτογράφηση και

την αποκρυπτογράφηση. Παρατηρήσουμε ότι η κρίσιμη πληροφορία

συνδέεται με το χρήστη από τον οποίο προέρχεται. Επομένως, μπορούμε να

χρησιμοποιήσουμε τον συνθηματικό κωδικό (password) του χρήστη και να τον

μετασχηματίσουμε με συστηματικό τρόπο ώστε να δημιουργήσουμε ένα

μυστικό κλειδί για την κρυπτογράφηση και αποκρυπτογράφηση της κρίσιμης

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

111

απαίτηση το ίδιο μυστικό κλειδί για την κρυπτογράφηση και

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

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

κρίσιμη πληροφορία κάθε χρήστη. Ένα επιπλέον όφελος, είναι ότι ουσιαστικά

δεν μπορούμε να αποκρυπτογραφήσουμε την κρίσιμη πληροφορία του

χρήστη, χωρίς την συναίνεση αυτού, δηλαδή χωρίς αυτός να μας δώσει το

μυστικό κωδικό του.

5.6 Κρυπτογράφηση βασισμένη σε μυστικό κωδικό (Password-Based Encryption)

Από τα παραπάνω οδηγούμαστε ουσιαστικά σε ένα μοντέλο

κρυπτογράφησης βασισμένης σε μυστικό κωδικό (Password-Based

Encryption). Σε αυτό το σχήμα κρυπτογράφησης χρησιμοποιείται κάποιος

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

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

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

αποκρυπτογραφήσουμε. Ο κωδικός αυτός είναι άμεσα διαθέσιμος όσο ο

συγκεκριμένος χρήστης βρίσκεται συνδεδεμένος στο σύστημά μας, ενώ όταν

ο χρήστης δεν είναι συνδεδεμένος, δεν έχουμε πρόσβαση σ’ αυτό τον κωδικό.

Αυτό σημαίνει ότι όταν ο χρήστης βρίσκεται εκτός συστήματος είναι αδύνατο

να ανακτηθεί το κρυφό κλειδί που χρησιμοποιήθηκε κατά την κρυπτογράφηση

της κρίσιμης πληροφορίας. Αυτό διασφαλίζει ότι ακόμα και αν κάποιος

αποκτήσει τα κρυπτογραφημένα δεδομένα, δεν μπορεί να τα ερμηνεύσει αν

δεν βρει και τον κωδικό του πελάτη στον οποίο αντιστοιχούν. Αυτό, έχοντας

μόνο πρόσβαση στη βάση μας και το σύστημά μας (ακόμα και φυσική

πρόσβαση) είναι αδύνατο, αφού ο κωδικός του πελάτη μετασχηματίζεται με

μονόδρομους αλγορίθμους (hash functions) πριν αποθηκευτεί σε αυτή.

112

5.6.1 Δημιουργία του κλειδιού από το μυστικό κωδικό

Ένα θέμα που καλούμαστε να αντιμετωπίσουμε, είναι η επιλογή του

μετασχηματισμού που θα εφαρμόσουμε στον κρυφό κωδικό του χρήστη για

να πάρουμε το κρυφό κλειδί για τον συμμετρικό αλγόριθμο κρυπτογράφησης

που χρησιμοποιούμε. Βασικά στο συγκεκριμένο θέμα δεν έχουμε πολλούς

περιορισμούς, καθώς στον AES δεν έχει ανακαλυφθεί ακόμα η ύπαρξη

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

των τελικών αποτελεσμάτων, δηλαδή η απόσταση μεταξύ των κλειδιών που

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

Μία κλασσική λύση για το πρόβλημα αυτό είναι η χρήση μονόδρομων

συναρτήσεων (hash functions). Για να μπορεί κάποιος τρίτος να μεταβεί

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

τυχαίο αριθμό (γνωστό ως salt) με τον οποίο θα μπλέξουμε τον κωδικό του

χρήστη. Το salt θα μπορούσε να είναι πάντα το ίδιο και κωδικοποιημένο στον

εκτελέσιμο κώδικα. Έτσι για να το αποκτήσει κάποιος χρειάζεται είτε τα

εκτελέσιμα αρχεία ή τον πηγαίο κώδικα.

o Τι είναι Hash Function

Εδώ θα ήταν σκόπιμο να εξηγήσουμε τι είναι μία Hash Function. Μία Hash

Function ορίζεται ως ένας μετασχηματισμός H που δέχεται μία είσοδο

μεταβλητού μεγέθους και επιστρέφει ένα αλφαριθμητικό σταθερού μεγέθους h

που ονομάζεται hash value (h = H(m)). Η βασικότερη εφαρμογή των Hash

Functions στην κρυπτογραφία είναι στις ψηφιακές υπόγραφές (digital

signatures).

Επιθυμητές ιδιότητες των Hash Functions στην κρυπτογραφία είναι:

• Να δέχονται είσοδο οποιουδήποτε μεγέθους

• Να παράγουν έξοδο σταθερού μεγέθους

• Να είναι υπολογιστικά εύκολο να βρεις το H(x) για κάποιο δοθέν x.

• Η H(x) να είναι μονόδρομη.

• Η H(x) να μην εμφανίζει συγκρούσεις.

113

Με τον όρο μονόδρομη εννοούμε να είναι δύσκολο να αντιστραφεί η H,

δηλαδή να είναι υπολογιστικά ανέφικτο να βρεθεί το x από το h = H(x).

Λέγοντας υπολογιστικά ανέφικτο εννοούμε να χρειάζονται 2n προσπάθειες

ώστε δοθέντος κάποιου h να βρεθεί x τέτοιο ώστε h = H(x) όπου n το μήκος

του h σε bits.

Με τον όρο να μην εμφανίζει συγκρούσεις εννοούμε δοθέντος κάποιου x να

είναι υπολογιστικά ανέφικτο να βρεθεί y τέτοιο ώστε H(x) = H(y). Λέγοντας

υπολογιστικά ανέφικτο εννοούμε να χρειάζονται 2n/2 προσπάθειες για την

εύρεση του y.

Γνωστές hash functions είναι οι MD2, MD4, MD5 και SHA1. Η οικογένεια

MD παράγει 128bits hash values, ενώ η SHA1 160bits. Την SHA1 τη

χρησιμοποιούμε για την αποθήκευση των κωδικών πρόσβασης στη βάση

δεδομένων. Θα επιλέξουμε τη χρήση του MD5 αφού η παραγωγή 128bits

hash values μας βολεύει, καθώς σκοπεύουμε να χρησιμοποιήσουμε 128bits

secret keys.

5.6.2 Επίδραση στο σύστημά μας

H βασισμένη σε μυστικό κωδικό κρυπτογράφηση αυξάνει την

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

αλλάζει κωδικό, θα πρέπει η κρίσιμη πληροφορία που σχετίζεται με αυτόν, να

αποκρυπτογραφείται με το κλειδί που προκύπτει από παλιό κωδικό, και να

επανακρυπτογραφείται με το κλειδί που προκύπτει από τον νέο κωδικό. Είναι

φανερό πως αν κάποιος χρήστης ξεχάσει τον παλιό του κωδικό και ζητήσει

την έκδοση ενός νέου, χάνουμε τη δυνατότητα να αποκρυπτογραφήσουμε την

κρίσιμη πληροφορία του. Σε αυτή την περίπτωση θα πρέπει να ζητήσουμε

από το χρήστη να μας ξαναδώσει την κρίσιμη πληροφορία του.

Παρόλο που προσθέτει κάποια πολυπλοκότητα η λύση με χρήση

μοντέλου κρυπτογράφησης βασισμένης σε μυστικό κωδικό προσφέρει

114

μεγαλύτερη ασφάλεια στην μυστική πληροφορία του χρήστη από την λύση με

χρήση ενός μόνο μυστικού κλειδιού που θα αποθηκεύεται προστατευμένο ή

μη σε κάποιο σημείο του δίσκου.

5.7 Περιγραφή τελικής λύσης

Από τα παραπάνω, η λύση στην οποία καταλήγουμε για την

προστασία της κρίσιμης πληροφορίας του χρήστη έχει ως εξής:

Θα χρησιμοποιήσουμε κρυπτογράφηση βασισμένη σε μυστικό κωδικό για

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

περίπτωση θα είναι ο κωδικός του χρήστη του οποίου την κρίσιμη

πληροφορία θέλουμε να προστατέψουμε. Θα χρησιμοποιήσουμε τον

αλγόριθμο συμμετρικού κλειδιού AES που αποτελεί το νέο πρότυπο

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

παραγωγή του κρυφού κλειδιού από το κωδικό του χρήστη θα

χρησιμοποιήσουμε την MD5 hash function. Επιπλέον, για να μπορεί κάποιος

τρίτος να μεταβεί δύσκολα από τον κρυφό κωδικό στο κλειδί, θα

χρησιμοποιήσουμε κάποιο τυχαίο αριθμό (γνωστό ως salt) με τον οποίο θα

μπλέξουμε τον κωδικό του χρήστη πριν την εφαρμογή της hash function. Το

salt θα είναι σταθερό και κωδικοποιημένο στον εκτελέσιμο κώδικα.

Το σχήμα που ακολουθεί δείχνει το κρυπτογραφικό σχήμα που θα

χρησιμοποιήσουμε:

User Password

Salt

MD5 Secret Key 128 bits

Cleartext Ciphertext AES

115

Τα παραπάνω διασφαλίζουν ότι ακόμα και αν κάποιος αποκτήσει

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

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

των πελατών μας. Για να μπορέσει να το κάνει αυτό θα πρέπει να έχει γνώση

των μυστικών κωδικών πρόσβασης των πελατών στο σύστημα, γνώση που

δεν μπορεί να αποκτήσει από το σύστημά μας.

User Password

Salt

MD5 Secret Key 128 bits

Chiphertext Cleartext AES

116

6. Εφαρμογή του συστήματος

Παρακάτω παρουσιάζουμε την υλοποίηση ενός συστήματος ηλεκτρονικών

πληρωμών για κινητές τερματικές συσκευές, που στηρίζεται στo σύστημα

ασφαλούς ανταλλαγής πληροφορίας σε περιβάλλον κινητών επικοινωνιών

που παρουσιάστηκε παραπάνω.

6.1 Τεχνολογίες Υλοποίησης

6.1.1 J2EE (Java 2 Platform, Enterprise Edition)

Η εφαρμογή υλοποιήθηκε σε Java. Συγκεκριμένα επιλέξαμε J2EE 1.4 (Java

2 Platform, Enterprise Edition). Οι εφαρμογές της J2EE χρειάζονται ένα J2EE

εξυπηρετητή για να τρέξουν. Για την εφαρμογή μας μπορεί να χρησιμοποιηθεί

οποιοσδήποτε συμβατός με την J2EE 1.4 πλατφόρμα Application Server που

υποστηρίζει EJB 2.0 (Enterprise Java Beans).

Η πλατφόρμα J2EE παρέχει σημαντικά εργαλεία για μια σειρά κρίσιμων

εφαρμογών. Παρακάτω αναφέρουμε μερικά από τα πλεονεκτήματα της J2EE.

• Μια εφαρμογή υλοποιημένη σε περιβάλλον J2EE και χρησιμοποιώντας

τον κατάλληλο Application Server μπορεί να εγκατασταθεί σε

κατανεμημένο περιβάλλον. Σε πρώτη φάση η εφαρμογή μας θα

εγκατασταθεί σε ένα server, αλλά η ίδια θα μπορεί στο μέλλον να

εγκατασταθεί σε μία ομάδα από Application Servers αν αυτό κριθεί

σκόπιμο, για παράδειγμα λόγω αυξημένου φόρτου.

• Η πλατφόρμα J2EE μέσο του Application Server μπορεί και υποστηρίζει

transactions, δηλαδή την ομαδοποίηση κάποιων κρίσιμων εργασιών, έτσι

ώστε σε περίπτωση κάποιου σφάλματος να μπορεί να γίνει επιστροφή

στην αρχική κατάσταση.

• Η J2EE μέσο του Application Server, παρέχει πολύ καλό recovery στην

περίπτωση που κάποιος server αντιμετωπίσει κάποιο πρόβλημα. Αυτό

117

μπορεί να επιτευχθεί με τη χρησιμοποίηση ενός κατανεμημένου

συστήματος. Σε ένα τέτοιο σύστημα γίνονται μεταγωγές από έναν server

σε ένα άλλον και πιθανά προβλήματα δε φαίνονται, καθώς οι διαδικασίες

είναι διάφανες προς το χρήστη

• Ένα σημαντικό πλεονέκτημα της πλατφόρμας J2EE είναι το “WORE” ή

“Write once, run everywhere”. Αυτή η ιδιότητα της πλατφόρμας δίνει τη

δυνατότητα σε μία εφαρμογή που είναι σχεδιασμένη με τα στάνταρ της

J2EE να τρέχει σε οποιονδήποτε J2EE εξυπηρετητή, χωρίς να απαιτούνται

αλλαγές στον κώδικα. Επιπλέον με τη χρήση CMP (Container Managed

Persistence), η εφαρμογή δε χρειάζεται να είναι στενά συνδεδεμένη ούτε

με τη βάση δεδομένων που χρησιμοποιείται. Η ιδιότητα CMP μας δίνει τη

δυνατότητα με συγκεκριμένο τρόπο γραφής του κώδικα ο εξυπηρετητής να

αναλάβει την επικοινωνία με τη βάση δεδομένων και να υλοποιήσει εκείνος

όλες της συναρτήσεις επικοινωνίας μαζί της, κάτι που επιτρέπει τη χρήση

οποιουδήποτε μηχανισμού βάσεως δεδομένων.

Οι παραπάνω ιδιότητες τόσο της πλατφόρμας J2EE όσο και των

εξυπηρετητών που την υποστηρίζουν προσδίδουν στην εφαρμογή πολύ

υψηλούς χρόνους διαθεσιμότητας και μεγάλη ευελιξία ως προς την

εγκατάστασή της, την εκτέλεση και την επεκτασιμότητά της.

6.1.2 EJB (Enterprise JavaBeans)

Μία από της σημαντικότερες τεχνολογίες της J2EE είναι τα Enterprise

JavaBeans. Στην εφαρμογή μας χρησιμοποιούμε Session Beans και Entity

Beans. Παρακάτω παρουσιάζουμε τα βασικά χαρακτηριστικά τους.

118

Entity Beans

Τα Entity Beans αποτελούν την αναπαράσταση των δεδομένων της βάσης

ως αντικείμενα στη μνήμη του συστήματος. Η ιδιαιτερότητα τους είναι ότι

αποτελούν αντικείμενα που σώνονται σε μόνιμο αποθηκευτικό χώρο

(persistence storage). Η δημιουργία ενός τέτοιου αντικειμένου στη μνήμη του

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

Κάνοντας χρήση των δυνατοτήτων των Entity Beans που υπακούουν τις

προδιαγραφές των EJB 2.0, μπορεί ο προγραμματιστής να μην ασχοληθεί με

τις συναρτήσεις αναφοράς στη βάση, αλλά αντί γι’ αυτόν να τις δημιουργήσει

δυναμικά ο EJB container. Αυτή η δυνατότητα ονομάζεται Container Managed

Persistence. Σε αντίθετη περίπτωση πρέπει ο προγραμματιστής να γράψει

όλες τις συναρτήσεις για την προσπέλαση της βάσης δεδομένων, οπότε

έχουμε Bean Managed Persistence.

Στα Entity Beans με βάση τις προδιαγραφές, πρέπει να ορίζεται μία

συνάρτηση εύρεσης κάθε αντικειμένου βάση του πρωτεύοντος κλειδιού του

στον πίνακα που το αναπαριστά στη βάση δεδομένων. Αυτή η συνάρτηση

πρέπει να έχει το όνομα «findByPrimaryKey» και να δέχεται ως όρισμα το

πρωτεύον κλειδί του αντικείμενου. Επιπλέον, μπορούν να οριστούν διάφορες

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

πρώτο όρισμα στο όνομά τους το “find”.

Επίσης τα Entity Beans μπορούν να διαθέτουν διάφορους constructor με

πρώτο συνθετικό ονόματος το “create”, ένας constructor καλείται πάντα όταν

θέλουμε να δημιουργήσουμε ένα καινούργιο αντικείμενο στη Java.

Τέλος μπορούν να προστεθούν συναρτήσεις που να επενεργούν πάνω στα

δεδομένα, οι οποίες ονομάζονται business methods.

119

Session Beans

Τα sessions beans δημιουργούνται για να προσφέρουν συναρτήσεις στους

χρήστες της εφαρμογής. Σε πολλές περιπτώσεις αποτελούν το interface των

entity beans. Ο χρήστης του προγράμματος (servlet, applet κτλ.) χρησιμοποιεί

ένα Session Bean ώστε να εκτελέσει κάποιες συναρτήσεις της εφαρμογής,

αυτές ονομάζονται όπως και παραπάνω business methods.

Τα Session Bean είναι αντικείμενα της μνήμης σε αντίθεση με τα Entity

Beans. Έτσι σε περίπτωση που ο Application Server για κάποιο λόγο

σταματήσει τη λειτουργία του οι τιμές των μεταβλητών τους θα χαθούν.

Τα Session Bean χωρίζονται σε δύο κατηγορίες, τα “statefull” και τα

“stateless”. Στην πρώτη κατηγορία δημιουργούνται αντικείμενα τα οποία

«δένονται» με τον χρήστη. Μόλις ο χρήστης ολοκληρώσει την χρήση τους, τα

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

ο Application Server (AS) δημιουργεί κάποια αντικείμενα και τα διατηρεί σε μία

«πισίνα» (pool). Όταν κάποιος χρήστης ζητήσει ένα Session Bean ο AS του

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

ένα νέο.

Γενικά, αν δε χρειάζεται να σώνονται πληροφορίες για κάθε χρήστη τότε η

χρήση stateless Session Beans είναι προτιμότερη, καθώς δεν υπάρχει

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

αντικείμενο, εκτελεί κάποιες συναρτήσεις και στη συνέχεια το επιστρέφει στον

container για να το χρησιμοποιήσει κάποιος άλλος χρήστης.

120

6.2 Αναλυτικός Σχεδιασμός

Στόχος μας είναι δημιουργία ενός συστήματος πληρωμών που θα μπορεί

να συνδεθεί με πολλές εταιρείες που χρειάζονται να κάνουν δοσοληψίες με

τραπεζικούς ή πιστωτικούς φορείς. Ένα γενικό σχήμα των φορέων που

συναλλάσσονται με την εφαρμογή πληρωμών είναι το ακόλουθο.

Ειδικότερα η δομή λειτουργίας του υποσυστήματος πληρωμών φαίνεται

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

με τη βάση γίνεται μέσα από το τμήμα κρυπτογράφησης των ευαίσθητων

προσωπικών δεδομένων. Με αυτό τον τρόπο, όπως αναλύσαμε στη

παράγραφο 4 (Ασφάλεια Προτεινόμενου Συστήματος) επιτυγχάνεται η

προστασία της κρίσιμης πληροφορίας του πελάτη κατά την αποθήκευσή της

στη βάση δεδομένων του συστήματός μας.

Σύστημα πληρωμών

Τραπεζικοί και πιστωτικοί φορείς

Πελάτης Α Πελάτης Β Πελάτης C

Εταιρεία Α Εταιρεία Β

Πελάτης Α

121

6.2.1 Διαγράμματα Ροής του Προγράμματος

]Στα επόμενα δύο σχήματα παρουσιάζεται η τυπική ροή του

προγράμματος, δηλαδή πώς ένας χρήστης τελικά φτάνει στο να εκτελέσει

κάποια πιστωτική κίνηση μέσα από το σύστημα πληρωμών.

User interface

Αυθεντικοποίηση Χρηστών

Βάση Δεδομένων Καταγραφή

Συναλλαγών

Επικοινωνία με Τραπεζικούς Οργανισμούς

Κρυπτογράφηση

Module αυθεντικοποίησης εταιριών

(Enterprise JavaBeans)

Η εταιρεία, συνδέεται στην

υπηρεσία

User interface (Java Servlets + SSL),

αποστέλλονται username + password εταιρίας

Επιτυχημένη

Μήνυμα λάθους

Δημιουργία εισιτηρίου, για τη συναλλαγή

(Enterprise JavaBeans)

Ο χρήστης πλοηγείται στο site μιας εταιρείας, φτάνει στο σημείο να κάνει μία

αγορά

Αποτυχημένη

Βάση Δεδομένων

122

Το εισιτήριο που αναφέρεται στο παραπάνω σχήμα, είναι ένα αντικείμενο

που θα δημιουργείται από το σύστημα και θα συντηρείται στη μνήμη του για

ορισμένο χρόνο. Το εισιτήριο περιέχει τα στοιχεία του χρήστη, και τα στοιχεία

της συναλλαγής που θέλει να πραγματοποιήσει. Ο χρήστης για να

ολοκληρώσει τη συναλλαγή πρέπει να έχει ένα έγκυρο (μη ληγμένο) εισιτήριο

για τη συγκεκριμένη συναλλαγή.

Αυθεντικοποίηση Χρηστών

(Enterprise JavaBeans)

User interface (xHTML, Java Servlets +

SSL), αποστολή username και password

Επιτυχημένη

Αποτυχημένη

Μήνυμα λάθους

Επικοινωνία με τον επιθυμητό οργανισμό, για ολοκλήρωση της

συναλλαγής

Ο χρήστης έχει πάρει το εισιτήριο και συνεχίζει για την ολοκλήρωση της

συναλλαγής

User interface (xHTML, Java Servlets +

SSL), εισαγωγή στοιχείων κάρτας ή επαναφορά στοιχείων από βάση

δεδομένων

Βάση Δεδομένων

Module κρυπτογράφησης – αποκρυπτογράφησης

δεδομένων

Ολοκλήρωση συναλλαγής

Αποστολή μηνύματος

Αποθήκευση στοιχείων συναλλαγής

123

6.2.2 Η βάση δεδομένων

Το σύστημα πληρωμών υποστηρίζεται από βάση δεδομένων για την

μόνιμη αποθήκευση των συναλλαγών και των στοιχείων των χρηστών του,

των εταιριών και των πελατών τους.

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

και η περιγραφή των στοιχείων τους:

T_COMPANY

PK company_id

company_namepassword

T_TICKETS

PK ticket_id

FK1 company_idfullnameamountchargetypecreationdateexpiredate

T_TRANSACTIONS

PK transaction_id

FK1 company_idFK2 user_id

amountstatustransaction_referencecharge_typetransaction_date

T_USERS

PK user_id

fullnamepasswordemailext_user_idcurrencycardcc_fullnamecc_numbercc_expiration_datecvccvv_codebanknamk_number

Πίνακας T_COMPANY

Σε αυτό τον πίνακα αποθηκεύονται οι εταιρίες που οι χρήστες τους έχουν

δικαίωμα να κάνουν πράξεις με πιστωτικές κάρτες μέσα από το σύστημά μας.

Τα πεδία του πίνακα είναι τα παρακάτω:

124

• COMPANY_ID: ο μοναδικός αριθμός κάθε εταιρίας • COMPANY_NAME: το όνομα της εταιρίας, χρησιμοποιείται και ως

username • PASSWORD: ο μυστικός κωδικός της εταιρίας, αποθηκεύεται

κρυπτογραφημένος στη βάση με τον αλγόριθμο SHA-1 και είναι γνωστός μονάχα στη εταιρία.

Πίνακας T_TICKETS

Σε αυτό το πίνακα αποθηκεύονται προσωρινά τα εισιτήρια (tickets) που

δημιουργεί το σύστημα για κάθε μία πράξη που κάνει κάποιος χρήστης μέσο

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

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

Το εισιτήριο δένει τον χρήστη, με την εταιρία μέσο της οποίας επιθυμεί να

κάνει την κίνηση, καθώς επίσης και με το ποσό και τον τρόπο χρέωσης.

Ο χρόνος ζωής του εισιτηρίου είναι 10 λεπτά, εάν σε αυτό το χρόνο δεν έχει

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

της εταιρίας ένα καινούργιο εισιτήριο. Μετά το πέρας των δέκα λεπτών τα

εισιτήρια διαγράφονται από τη βάση.

Τα πεδία του πίνακα είναι τα παρακάτω:

• TICKET_ID: ο μοναδικός αριθμός κάθε εισιτηρίου • COMPANY_ID: ο μοναδικός αριθμός της εταιρίας μέσο της οποίας

δημιουργείται αυτό το εισιτήριο • FULLNAME: το ονοματεπώνυμο του χρήστη που θα κάνει την πράξη • AMOUNT: το πόσο χρέωσης της πιστωτικής κάρτας ή του

λογαριασμού του χρήστη • CHARGETYPE: ο τρόπος χρέωσης του χρήστη. • CREATIONDATE: η ημερομηνία που δημιουργήθηκε το εισιτήριο. • EXPIREDATE: η ημερομηνία λήξης του εισιτηρίου

Πίνακας T_TRANSACTIONS

Σε αυτό τον πίνακα κρατούνται όλες οι κινήσεις, είτε επιτυχημένες, είτε

αποτυχημένες που έχουν πραγματοποιηθεί στο σύστημα.

Τα πεδία του πίνακα είναι τα παρακάτω:

125

• TRANSACTION_ID: ο μοναδικός αριθμός κάθε συναλλαγής που

πραγματοποιείται στο σύστημα • COMPANY_ID: ο μοναδικός αριθμός της συνεργαζόμενης εταιρείας

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

τη συναλλαγή. • AMOUNT: το ποσό των χρημάτων για το οποίο πραγματοποιήθηκε η

συναλλαγή • STATUS: η κατάσταση στην οποία βρίσκεται αυτή τη στιγμή η

συναλλαγή • TRANSACTION_REFERENCE: κείμενο στο οποίο αποθηκεύεται η

πιθανή απόδειξη συναλλαγής που επιστρέφει το τραπεζικό σύστημα. • CHARGE_TYPE: ο τρόπος χρέωσης του χρήστη. • TRANSACTION_DATE: η ημερομηνία εκτέλεσης της συναλλαγής.

Πίνακας T_USERS

Σε αυτό τον πίνακα αποθηκεύονται οι χρήστες της υπηρεσίας. Οι χρήστες

μπορεί να μπαίνουν και να ψωνίζουν από διαφορετικές συνεργαζόμενες

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

το μόνο που χρειάζεται να κάνουν μετά την εγγραφή τους στο σύστημα, είναι

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

βάση δεδομένων. Τα ευαίσθητα στοιχεία του χρήστη που διατηρούνται

κρυπτογραφημένα είναι: αριθμός της πιστωτικής κάρτας, ο αριθμός

λογαριασμού, η ημερομηνία λήξης της πιστωτικής κάρτας, τριψήφιος αριθμός

πιστοποίησης της πιστωτικής κάρτας και ο τύπος της πιστωτικής κάρτας .

Τα πεδία του πίνακα είναι τα παρακάτω:

• USER_ID: ο μοναδικός αριθμός κάθε χρήστη. • FULLNAME: το ονοματεπώνυμο του χρήστη • PASSWORD: ο μυστικός κωδικός του χρήστη • EMAIL: το email του χρήστη της υπηρεσίας • EXT_USER_ID: μοναδικός αριθμός χρήστη, που βρίσκεται

αποθηκευμένος και σε μία βάση εκτός της παρούσης. • CARD: το όνομα της πιστωτική κάρτας του χρήστη (Visa, Mastercard

κτλ.)

126

• CC_FULLNAME: το ονοματεπώνυμο που είναι γραμμένο πάνω στη πιστωτική κάρτα του χρήστη.

• CC_NUMBER: ο αριθμός της πιστωτικής κάρτας του χρήστη • CC_EXPIRATION_DATE: η ημερομηνία λήξης της πιστωτικής κάρτας

του χρήστη. • CVCCVV_CODE: ο τριψήφιος αριθμός πιστοποίησης της πιστωτικής

κάρτας. • CURRENCY: ο τύπος του νομίσματος που χρησιμοποιεί ο χρήστης για

τις αγορές του (Euro, Dollars κτλ.) • BANK: το όνομα της τράπεζας του χρήστη του συστήματος • BANK_NUMBER: ο αριθμός λογαριασμού που έχει ο χρήστης.

6.2.3 Δομή κώδικα

Η λογική του συστήματος υλοποιείται από τέσσερα Entity Beans, και από

δύο Session Beans.

Τα τέσσερα Entity Beans θα είναι τα :

• CompanyEJB • TicketEJB • TransactionEJB • UserEJB

Ενώ τα δύο Session Bean θα είναι τα:

• CompanySessionEJB • UserSessionEJB

Ο κώδικας για των Enterprise JavaBeans παρατίθεται στο παράρτημα.

Η διεπαφή του συστήματος αποτελείται από τρία servlets και σελίδες jsp.

Τα servlet θα χρησιμοποιούνται για να γίνεται το login των συνεργαζόμενων

εταιριών και των χρηστών του συστήματος, καθώς και η δημιουργία των

Session Beans και οι κλήση της λογικής που αυτά υλοποιούν. Οι σελίδες JSP

χρησιμοποιούνται από το σύστημα για την εισαγωγή και επιβεβαίωση των

στοιχείων των χρηστών, και της συναλλαγής.

127

Τα τρία Servlets είναι:

• companyGetTicketServlet • newtransactionServlet • transactionResultServlet

Entity Beans

ComapnyEJB

Το ComapnyEJB αναλαμβάνει την επικοινωνία του συστήματος με το table

T_COMPANY της βάσης δεδομένων. Πέρα από την default συνάρτηση

εύρεσης (findByPrimaryKey), υλοποιήσαμε μία ακόμη συνάρτηση με όνομα

findByCompanyName, η οποία βρίσκει μία ζητούμενη εταιρία βάση του

ονόματος της το οποίο δεν αποτελεί πρωτεύων κλειδί.

Company findByCompanyName(String Companyname) TicketEJB

Το TicketEJB αναλαμβάνει την επικοινωνία του συστήματος με το table της

βάσης T_TICKETS. Ο default constructor της κλάσης είναι ο παρακάτω :

public Ticket create(Integer company_id, String userfullname, Float

amount, Integer chargeType)

Αυτός δημιουργεί ένα καινούργιο εισιτήριο παίρνοντας τα απαραίτητα

στοιχεία από τον πίνακα T_COMPANY, μέσο του «company_id» και επιπλέον

θέτει στο εισιτήριο τα απαραίτητα στοιχεία για να είναι έγκυρο όπως

ημερομηνία λήξης, ονοματεπώνυμο του χρήστη και το ποσό της χρέωσης.

128

Τέλος θα υλοποιηθεί μία business method με όνομα «hasExpired()» η

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

public Boolean hasExpired()

TransactionEJB

Το TransactionEJB αναλαμβάνει την επικοινωνία του συστήματος με τον

πίνακα της βάσης T_TRANSACTIONS. Σε αυτόν τον πίνακα θα σώνονται

όλες οι κινήσεις που κάνουν οι χρήστες.

Ο default constructor του Bean θα είναι ο παρακάτω:

public Transaction create(TransactionEJBVO value)

Αυτός δημιουργεί ένα καινούργιο αντικείμενο τύπου Transaction στη βάση,

χρησιμοποιώντας τα στοιχεία που βρίσκονται στο object

«TransactionEJBVO». To τελευταίο περιέχει τα στοιχεία:

private final Integer user_id; private final Float ammount; private final Integer charge_type; private final Integer status; private final Integer company_id;

Τα παραπάνω στοιχεία είναι απαραίτητα για τη δημιουργία του καινούργιου

Transaction.

Επίσης πέρα από την default συνάρτηση εύρεσης (findByPrimaryKey) θα

προστεθεί μία ακόμη η findByUserId η οποία θα μπορεί να βρίσκει όλα τα

129

transactions ενός συγκεκριμένου χρήστη. Ο ορισμός της συνάρτησης θα είναι

ο παρακάτω:

public Collection findByUserId(Integer userId)

Εύκολα μπορεί παρατηρηθεί ότι η παραπάνω συνάρτηση δεν επιστρέφει

ένα αντικείμενο τύπου Transaction, αλλά ένα σύνολο (Collection) από τέτοιου

τύπου αντικείμενα.

Τέλος θα προστεθεί μία business method με όνομα executeTransaction.

Αυτή καλεί τις κατάλληλες συναρτήσεις επικοινωνίας με τα payment gateways

των τραπεζικών και των πιστωτικών φορέων, έτσι ώστε να εκτελεστεί η

ζητούμενη συναλλαγή. Ο ορισμός της συνάρτησης είναι ο παρακάτω:

public void executeTransaction()

UserEJB

Το τελευταίο Entity Bean που χρησιμοποιούμε είναι το UserEJB, αυτό

αναλαμβάνει την επικοινωνία του συστήματος με τον πίνακα T_USERS της

βάσης.

Σε αυτό το entity θα προστεθεί μία business method με όνομα

newTransaction, αυτή θα δημιουργεί ένα καινούργιο transaction, για τον

συγκεκριμένο χρήστη. Ο ορισμός της συνάρτησης είναι ο ακόλουθος

public void newTransaction(Ticket ticket)

Ως όρισμα η συνάρτηση θα δέχεται ένα ticket (εισιτήριο) απ’ όπου θα

παίρνει όλα τα απαραίτητα στοιχεία για τη δημιουργία του νέου transaction.

130

Session Beans

CompanySessionEJB

Το παραπάνω Session Bean είναι ένα stateless bean το οποίο

χρησιμοποιείται για την επικοινωνία των clients με το σύστημα των

πληρωμών. Οι clients σε αυτή την περίπτωση είναι οι εταιρίες που επιθυμούν

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

Επιλέχθηκε η λύση του stateless session bean, γιατί δεν συντρέχει

ιδιαίτερος λόγος να δεσμεύεται κάποιο αντικείμενο στη μνήμη του Application

Server καθ’ όλη τη διάρκεια που κάνει πράξεις ένας client (- εταιρία), εφόσον

η μόνη χρήση του Session Bean είναι να δημιουργεί το εισιτήριο.

Στο session bean υλοποιήθηκε μία business method με όνομα getTicket.

μέσο αυτής της συνάρτησης γίνεται το login της εταιρίας στο σύστημα και κατ’

επέκταση ο έλεγχος εάν μέσο της συγκεκριμένης εταιρίας μπορεί κάποιος

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

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

εκτελέσει τη συναλλαγή.

Ο ορισμός της συνάρτησης είναι ο παρακάτω:

public Ticket getTicket(String companyname, String password, String username, Float ammount, Integer ChargeType).

Τα στοιχεία που χρειάζεται για να δημιουργήσει το καινούργιο εισιτήριο

είναι τα παρακάτω:

companyname, password: για να κάνει το απαραίτητο login για την

εταιρία.

131

username, amount, chargeType: τα στοιχεία που αφορούν έναν

συγκεκριμένο χρήστη και μία συναλλαγή έτσι ώστε να μπορέσει να

δημιουργήσει το εισιτήριο.

UserSessionEJB

Το δεύτερο session bean που χρησιμοποιείται είναι ένα statefull session

bean. Τα statefull session beans, όπως είδαμε δημιουργούνται μόλις ο

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

από αυτή.

Ο default constructor του bean θα είναι ο παρακάτω:

public Integer create(String username, String password)

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

σύνδεση τότε ένα καινούργιο exception τύπου LoginException στέλνεται προς

το χρήστη.

Μόλις ο χρήστης συνδεθεί και δημιουργηθεί σωστά το session object, τότε

μπορεί να κάνει συναλλαγές. Αυτές πραγματοποιούνται με τη συνάρτηση

newTransaction(). Παρακάτω βλέπουμε τον ορισμό της συνάρτησης:

public Object newTransaction(Ticket ticket)

Η newTransaction() χρειάζεται ως παραμέτρους ένα αντικείμενο τύπου

ticket, ώστε να είναι σίγουρο ότι ο χρήστης έχει έρθει από κάποια

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

του εγγραφής συναλλαγής που δημιούργησε στη βάση. Το εισιτήριο εννοείται

ότι πρέπει να είναι έγκυρο.

132

Servlets

companyGetTicketServlet

Το servlet αυτό καλείται από την εταιρία για να δημιουργήσει το

εισιτήριο που θα χρησιμοποιηθεί από το χρήστη για τη διεξαγωγή της

συναλλαγής. Δέχεται το όνομα εισόδου της εταιρίας στο σύστημα (login

name), τον μυστικό της κωδικό (password) και το όνομα εισόδου του πελάτη

(user login name). Αφού πιστοποιήσει την ύπαρξη της εταιρίας στο σύστημα,

δημιουργεί ένα εισιτήριο για τον πελάτη. Για τη δημιουργία του εισιτηρίου

χρειάζεται επιπλέον το ποσό της συναλλαγής.

newtransactionServlet

Το servlet αυτό καλείται μετά το login του πελάτη για να δημιουργήσει

και να διεξάγει τη συναλλαγή. Για να δημιουργήσει και να διεξάγει τη

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

UserSession, το οποίο δημιουργείται με την είσοδο του χρήστη στο σύστημα.

transactionResultServlet

Το servlet αυτό καλείται για να ελέγξει το αποτέλεσμα της συναλλαγής.

Το αποτέλεσμα της συναλλαγής επιστρέφεται από τον τραπεζικό φορέα και

αποθηκεύεται στη βάση δεδομένων σαν πεδίο του πίνακα

T_TRANSACTIONS.

6.2.4 Περιγραφή διαδικασίας εκτέλεσης συναλλαγής

Η λειτουργία του συστήματος έχει ως εξής: Οι χρήστες έρχονται στην

υπηρεσία μέσο κάποιας εταιρείας, το σύστημα δημιουργεί ένα εισιτήριο για τη

συγκεκριμένη κίνηση, στο χρήστης δίνεται κάποιος συγκεκριμένος χρόνος

μέσα στον οποίο θα πρέπει να εκτελέσει την κίνηση του.

133

A. Δημιουργία εισιτηρίου

Πρώτο βήμα στη διαδικασία πληρωμής είναι η δημιουργία του απαραίτητου

εισιτηρίου. Η εταιρία που συνεργάζεται με την υπηρεσία πληρωμών,

συνδέεται με την υπηρεσία (δίνοντας κάποιο όνομα χρήστη και κάποιο

μυστικό κωδικό), επίσης θα δίνει τα απαραίτητα στοιχεία για τη συναλλαγή

• Όνομα χρήστη • Ποσό χρημάτων • Τρόπος χρέωσης

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

εισιτήριο το οποίο «δένει» τη συγκεκριμένη κίνηση του χρήστη με την εταιρία

και του αφήνει ένα χρονικό περιθώριο για να την εκτελέσει. Διαφορετικά, εάν

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

λάθους.

Εφόσον το εισιτήριο δημιουργηθεί τότε αυτό δίνεται στο χρήστη, και προτού

λήξει μπορεί να εκτελέσει τη συναλλαγή που επιθυμεί.

B. Εκτέλεση συναλλαγής

Από τη στιγμή που ο χρήστης θα πάρει το εισιτήριο τότε μπορεί να

πραγματοποιήσει τη συναλλαγή που επιθυμεί σε κάποιο συγκεκριμένο

χρονικό διάστημα, για να το πραγματοποιήσει αυτό θα πρέπει να

ακολουθήσει τα παρακάτω δύο βήματα.

• Να συνδεθεί με τη υπηρεσία, χρησιμοποιώντας το username και

password του • Εάν η σύνδεση πετύχει να επιβεβαιώσει τη συναλλαγή του. •

134

6.3 Δοκιμές του συστήματος

6.3.1 Περιβάλλον δοκιμών

Για τις δοκιμές του συστήματος χρησιμοποιήσαμε τον Application Server

της Sun.

• Sun Java System Application Server Platform Edition 8.0.0_01 (build b08-fcs)

Ο Sun Java System Application Server PE 8 είναι συμβατός με την J2EE

1.4 πλατφόρμα, και διανέμεται δωρεάν από τη Sun μαζί με το jdk για την

J2EE 1.4.

Η βάση δεδομένων που χρησιμοποιήθηκε είναι:

• Microsoft SQL Server 2000 SP3

Για την διασύνδεση του Application Server με την βάση δεδομένων

χρησιμοποιήσαμε το Microsoft SQL Server 2000 Driver for JDBC SP 3,

Version 2.2.0040, που είναι ένας type 4 JDBC driver.

Τα παραπάνω στοιχεία εγκαταστάθηκαν σε ένα μηχάνημα με Windows XP

v2002 SP2.

Τέλος για τον έλεγχο των σελίδων χρησιμοποιήσαμε το Nokia Mobile

Internet Toolkit.

6.3.2 Αποτελέσματα των δοκιμών

Μεταφορά χρήστη στο σύστημα

Για τους σκοπούς των δοκιμών έχουμε αντικαταστήσει τις σελίδες του

εμπόρου με μία εισαγωγική σελίδα intro.jsp. Εκεί καλείται ο χρήστης

(εμπορικό κατάστημα) να δώσει το όνομα εισόδου και τον κωδικό της εταιρία

135

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

παραπάνω φαίνονται στο screenshot που ακολουθεί:

Αν τα στοιχεία δοθούν σωστά, καλείται το companyGetTicketServlet,

δημιουργείται το εισιτήριο και οδηγούμαστε στη σελίδα εισόδου userlogin.jsp,

για την εισαγωγή του χρήστη στο σύστημα.

Αν προκύψει κάποιο λάθος εμφανίζεται σχετικό μήνυμα λάθους. Για

παράδειγμα αν το password δεν είναι έγκυρο, εμφανίζεται το μήνυμα

Login Failed

136

Εισαγωγή χρήστη στο σύστημα

Αφού ο χρήστης μεταφερθεί από το δικτυακό τόπο του εμπόρου στο

σύστημα πληρωμών, έχοντας κάποιο έγκυρο εισιτήριο, πρέπει να δώσει login

name και password για να εισαχθεί στο σύστημα. Με την επιτυχή είσοδο του

χρήστη στο σύστημα, δημιουργείται ένα UserSession και ο χρήστη

ανακατευθύνεται στη σελίδα requestinfo.jsp. Αν η ταυτοποίηση του χρήστη

αποτύχει, εμφανίζεται σχετικό μήνυμα λάθους:

Login Failed

Αν κάποιος προσπαθήσει να μπει στο σύστημα πληρωμών χωρίς να έχει

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

No valid ticket ID!

137

Επιβεβαίωση συναλλαγής και αποτέλεσμα.

Στη σελίδα requestinfo.jsp, εμφανίζονται τα στοιχεία του χρήστη, τα

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

ενημερώσει τα στοιχεία του, αν αυτά δεν είναι έγκυρα και να επιβεβαιώσει τη

συναλλαγή.

Αν επιβεβαιωθεί η συναλλαγή, καλείται το newtransactionServlet, όπου

δημιουργείται και εκτελείται η συναλλαγή. Το αποτέλεσμα της συναλλαγής

αποθηκεύεται στη βάση δεδομένων. Ακολούθως καλείται το η σελίδα

result.jsp για να ελέγξει το αποτέλεσμα της συναλλαγής.

Τα πιθανά αποτελέσματα της συναλλαγής είναι:

• Approved • Rejected • Failed • Waiting for approval • Server unreachable

Αντίστοιχα τα μηνύματα που

εμφανίζονται στη result.jsp είναι:

Your transaction with ID : __ has completed successfully Your transaction with ID : __ has been rejected Υour transaction with ID : __ has failed Your transaction with ID : __ has not been finished yet, we will try finish it 5-10 minutes Your transaction with ID : __ has not been finished yet, due an error in connection, we will to try finish it in 5-10 minutes

138

Το ID της συναλλαγής είναι ένας εννιαψήφιος αριθμός που αντιστοιχεί στο

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

μας.

139

7. Βιβλιογραφία

1) ETSI, GSM01.61: Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); GPRS ciphering algorithm requirements, TS 101 106 V6.0.1 (Release 1997), 1998-07.

2) ETSI, GSM 02.09: Digital cellular telecommunications system (Phase 2+); Security aspects. ETSI EN 300 920, version 7.1.1, Release 1998, 2000-08

3) ETSI, GSM 02.33: Digital cellular telecommunications system (Phase 2+); Lawful Interception – stage 1, ETSI TS 101 507 V7.3.0 (Release 1998), 1999-11.

4) ETSI, GSM 02.60: Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS);Service Description; Stage 1, ETSI EN 301 113 V6.2.1 (Release 1997), 1999-08.

5) ETSI, GSM 03.20: Digital cellular telecommunications system (Phase 2+); Security related network functions. ETSI TS 100 929 version 7.2.0 Release 1998, 11-1999.

6) ETSI, GSM 03.33: Digital cellular telecommunications system (Phase 2+);Lawful Interception;Stage 2, ETSI TS 101 509 V7.1.0 (Release 1998), 1999-11.

7) ETSI, GSM 03.60: Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS);Service Description; Stage 2, ETSI EN 301 344 V7.4.0 (Release 1998), 2000-04.

8) ETSI, GSM 03.71: Digital cellular telecommunications system (Phase 2+); Location Services (LCS); (Functional description) – Stage 2, ETSI TS 101 724 V8.0.0, (Release 1999), 2000-10.

9) ETSI, GSM 09.02: Digital cellular telecommunications system (Phase 2); Mobile Application Part (MAP) specification, ETSI TS 100 974 V7.5.1(Release 1998), 2000-09.

10) ETSI, GSM 09.61: Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS);Interworking between the Public Land Mobile Network

11) Wireless Application Protocol Architecture Specification (WAP-210-WAPArch-20010712)

12) Wireless Transport Layer Security (WAP-261-WTLS-20010406-a) 13) Sami Jormalainen & Jouni Laine: Security in the WTLS

http://www.hut.fi/~jtlaine2/wtls/ 14) Markku-Juhani Saarinen: Attacks Against the WAP WTLS protocol. 15) JCE Reference Guide for the Java 2 SDK, Standard Edition, v 1.4

http://java.sun.com/j2se/1.4.2/docs/guide/security/jce/JCERefGuide.html 16) RSA Laboratories' Frequently Asked Questions About Today's Cryptography,

Version 4.1 http://www.rsasecurity.com/rsalabs/node.asp?id=2152

17) Andrew S. Tanenbaum, “Δίκτυα Υπολογιστών”, Παπασωτηρίου 2000 18) Federal Information Processing Standards Publication 46-3, “Data Encryption

Standard”, U.S Department of Commerce/National Institute of Standards and Technology, 1999. http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf

140

19) X. Lai, “On the design and security of block ciphers”, ETH Series in Information Processing (J.L. Massey, ed.), Vol. 1, Hartung-Gorre Verlag Konstanz, Technische Hochschule (Zurich), 1992.

20) R. Baldwin, R. Rivest, “The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms” RFC2040, 1996

21) http://www.ietf.org/rfc/rfc2040.txt 22) Adams C, “The CAST-128 Encryption Algorithm” RFC2144, May 1997. 23) Federal Information Processing Standards Publication 197, “Announcing the

Advanced Encryption Standard (AES)”, NIST, 2001 24) http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf. 25) Whitfield Diffie and Martin E. Hellman, “New Directions in Cryptography”,

Invited Paper, 1976. 26) RSA Laboratories, PKCS#1 v2.1, “RSA Cryptography Standard, RSA” Security

Inc., 2002 27) http://www..rsasecurity.com/rsalabs/node.asp?id=2125. 28) Menezes A., P. van Oorschot and S. Vastone, “Handbook of Applied

Cryptography”, Boca Raton, CRC Press, 1997 29) http://www.cacr.math.uwaterloo.ca/hac 30) Federal Information Processing Standards Publication 186-2, “Digital

Signature Standard.” U.S Department of Commerce/National Institute of Standards and Technology, 2000

31) http://csrc.nist.gov/publications/fips/fips186-2/fips186-2change1.pdf 32) W.Diffie, P. van Oorschot and M. Wiener, “Authentication and authenticated

key exchanges”, Designes, Codes and Cryptography, 1992. 33) ANSI X9.62, Public Key Cryptography for the Financial Services Industry: The

Elliptic Curve Digital Signature Algorithm (ECDSA), 1998. 34) Federal Information Processing Standards Publication180-2 “Secure Hash

Standard”, NIST 2002 35) http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf 36) Kaliski B., “The MD2 Message-Digest Algorithm”, RFC1319, IETF, 1992

http://www.ietf.org/rfc/rfc1319.txt 37) Rivest R., “The MD4 Message-Digest Algorithm”, RFC1320, IETF, 1992

http://www.ietf.org/rfc/rfc1320.txt 38) Rivest R., “The MD5 Message-Digest Algorithm”, RFC1321, IETF, 1992

http://www.ietf.org/rfc/rfc1321.txt 39) Dobbertin H., Bosselaers A., Preneel B., “RIPEMD-160, A Strengthened

Version of RIPEMD”, 1996 40) Descriptions of SHA-256, SHA-384 and SHA-512,

http://csrc.nist.gov/CryptoToolkit/shs/sha256-384-512.pdf 41) 42) An Overview of Cryptography by DiJ,

http://www.hack.gr/users/dij/crypto/overview/ 43) Advanced Encryption Standard (AES) FIPS-197

http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf 44) RFC 1321 - The MD5 Message-Digest Algorithm

http://www.faqs.org/rfcs/rfc1321.html

141

45) RFC 1320 - The MD4 Message-Digest Algorithm http://www.faqs.org/rfcs/rfc1320.html

46) RFC 1319 - The MD2 Message-Digest Algorithm http://www.faqs.org/rfcs/rfc1319.html

47) Secure Hash Standard FIPS PUB 180-1 http://www.itl.nist.gov/fipspubs/fip180-1.htm

48) J2EE 1.4 Specification - Final Release November 24, 2003 http://java.sun.com/j2ee/j2ee-1_4-fr-spec.pdf

49) J2EE 1.4 Tutorial Update 2 (for Sun Java System Application Server Platform Edition 8 Update 1) http://java.sun.com/j2ee/1.4/download.html#tutorial

142

Παράρτημα – Κώδικας CompanyEJB CompanyBean.java package nettechn.BankClearence.Company; import javax.ejb.*; import java.util.Collection; /** * Created by IntelliJ IDEA. * User: skentros * Date: 22 Ιουλ 2004 * Time: 3:22:15 μμ * To change this template use File | Settings | File Templates. */ public abstract class CompanyBean implements EntityBean public CompanyBean() public void setEntityContext(EntityContext entityContext) throws EJBException public void unsetEntityContext() throws EJBException /* public Object ejbCreate( String name, String password) throws CreateException setCompany_name(name); setPassword(password); return null; */ public void ejbRemove() throws RemoveException, EJBException public void ejbActivate() throws EJBException public void ejbPassivate() throws EJBException public void ejbLoad() throws EJBException public void ejbStore() throws EJBException public abstract String getCompany_name(); public abstract void setCompany_name(String company_name); public abstract Collection getUser(); public abstract void setUser(Collection user); public abstract Collection getTransaction();

143

public abstract void setTransaction(Collection transaction); public abstract String getPassword(); public abstract void setPassword(String password); public abstract Integer getCompany_id(); public abstract void setCompany_id(Integer company_id); Company.java package nettechn.BankClearence.Company; import javax.ejb.EJBObject; import java.rmi.RemoteException; import java.util.Collection; /** * Created by IntelliJ IDEA. * User: skentros * Date: 22 Ιουλ 2004 * Time: 3:22:13 μμ * To change this template use File | Settings | File Templates. */ public interface Company extends EJBObject String getCompany_name() throws RemoteException; void setCompany_name(String company_name) throws RemoteException; Collection getUser() throws RemoteException; void setUser(Collection user) throws RemoteException; Collection getTransaction() throws RemoteException; void setTransaction(Collection transaction) throws RemoteException; String getPassword() throws RemoteException; void setPassword(String password) throws RemoteException; void setCompany_id(Integer company_id) throws RemoteException; Integer getCompany_id() throws RemoteException; CompanyHome.java package nettechn.BankClearence.Company; import javax.ejb.FinderException; import javax.ejb.EJBHome; import java.rmi.RemoteException; /**

144

* Created by IntelliJ IDEA. * User: skentros * Date: 22 Ιουλ 2004 * Time: 3:22:15 μμ * To change this template use File | Settings | File Templates. */ public interface CompanyHome extends EJBHome Company findByPrimaryKey(Integer key) throws FinderException, RemoteException; Company findByCompanyName(String Companyname) throws FinderException, RemoteException; LocalCompany.java /** * Created by IntelliJ IDEA. * User: skentros * Date: 22 Ιουλ 2004 * Time: 1:40:32 μμ * To change this template use File | Settings | File Templates. */ package nettechn.BankClearence.Company; import javax.ejb.EJBLocalObject; import java.util.Collection; public interface LocalCompany extends EJBLocalObject String getCompany_name(); void setCompany_name(String company_name); Collection getUser(); void setUser(Collection user); Collection getTransaction(); void setTransaction(Collection transaction); String getPassword(); void setPassword(String password); void setCompany_id(Integer company_id); Integer getCompany_id(); LocalCompanyHome.java /** * Created by IntelliJ IDEA. * User: skentros * Date: 22 Ιουλ 2004 * Time: 1:40:31 μμ * To change this template use File | Settings | File Templates. */ package nettechn.BankClearence.Company;

145

import javax.ejb.EJBLocalHome; import javax.ejb.FinderException; public interface LocalCompanyHome extends EJBLocalHome LocalCompany findByPrimaryKey(Integer key) throws FinderException; LocalCompany findByCompanyName(String Companyname) throws FinderException; TicketEJB TicketBean.java /** * Created by IntelliJ IDEA. * User: skentros * Date: 22 Ιουλ 2004 * Time: 5:53:27 μμ * To change this template use File | Settings | File Templates. */ package nettechn.BankClearence.Ticket; import javax.ejb.*; import java.util.Calendar; import java.util.ResourceBundle; import java.util.Date; import nettechn.utilities.encoder; public abstract class TicketBean implements EntityBean public TicketBean() public void setEntityContext(EntityContext entityContext) throws EJBException public void unsetEntityContext() throws EJBException public void ejbRemove() throws RemoveException, EJBException public void ejbActivate() throws EJBException public void ejbPassivate() throws EJBException public void ejbLoad() throws EJBException public void ejbStore() throws EJBException public abstract Integer getCompany_id(); public abstract void setCompany_id(Integer company_id); public abstract String getFullname();

146

public abstract void setFullname(String fullname); public abstract String getCreationdate(); public abstract void setCreationdate(String creationdate); public abstract Date getExpiredate(); public abstract void setExpiredate(Date expiredate); public Object ejbCreate(Integer company_id, String userfullname, Float ammount, Integer chargeType) throws CreateException ResourceBundle rb = ResourceBundle.getBundle("nettechn.BankClearence.resources.messages"); if (!(ammount.intValue() > 0)) throw new CreateException(rb.getString("1003")); setCompany_id(company_id); setFullname(userfullname); setAmmount(ammount); System.out.println("We are going to store the charge type"); System.out.println(chargeType); setChargettype(chargeType); Calendar cal = java.util.Calendar.getInstance(); setCreationdate(cal.getTime().toString()); cal.add(Calendar.MINUTE, 10); System.out.print("Ticket calling word. ExpirationDate created."); setExpiredate(cal.getTime()); System.out.print("Ticket calling word. End of create._"); // To be reedited on first opportunity return null; public void ejbPostCreate(Integer company_id, String userfullname, Float ammount, Integer chargeType) throws CreateException //To change body of implemented methods use File | Settings | File Templates. public abstract Float getAmmount(); public abstract void setAmmount(Float ammount); public abstract Integer getChargettype(); public abstract void setChargettype(Integer chargettype); public Boolean ejbHomeHasExpired() return hasExpired(); public Boolean hasExpired() if (getExpiredate().compareTo(Calendar.getInstance().getTime()) > 0) return new Boolean(false);

147

return new Boolean(true); TicketDelegate.java package nettechn.BankClearence.Ticket; import nettechn.ServiceLocator.exceptions.ServiceLocatorException; import nettechn.ServiceLocator.ejb.EJBLocator; import javax.ejb.FinderException; import java.rmi.RemoteException; /** * Created by IntelliJ IDEA. * User: skentros * Date: 10 Αυγ 2004 * Time: 3:08:40 μμ * To change this template use File | Settings | File Templates. */ public class TicketDelegate public TicketDelegate() /** * Given a TicketID this function returnes the Ticket object, if exists and the Ticket is still valid. * @param TicketID The ID of the Ticket to look for * @return return the Ticket Object if it is valid, otherwise returns false */ public Ticket getTicket(String TicketID) EJBLocator serviceLocator = EJBLocator.getEJBInstance(); Long tckID = new Long(TicketID); System.out.println("Hello there"); try TicketHome ticketHome = (TicketHome) serviceLocator.getRemoteHome("java:comp/env/ejb/ticket", TicketHome.class); Ticket ticket = null; if ((ticket = ticketHome.findByPrimaryKey(tckID)) == null) return null; if (ticket.hasExpired().booleanValue()) return null; System.out.println("And the ticket we return!!!!!! "); return ticket; catch (ServiceLocatorException ex) ex.printStackTrace(); catch (RemoteException ex) ex.printStackTrace(); catch (FinderException ex) ex.printStackTrace();

148

return null; Ticket.java /** * Created by IntelliJ IDEA. * User: skentros * Date: 22 Ιουλ 2004 * Time: 5:53:26 μμ * To change this template use File | Settings | File Templates. */ package nettechn.BankClearence.Ticket; import javax.ejb.EJBObject; import java.rmi.RemoteException; import java.sql.Timestamp; import java.util.Date; public interface Ticket extends EJBObject Integer getCompany_id() throws RemoteException; void setCompany_id(Integer company_id) throws RemoteException; String getFullname() throws RemoteException; void setFullname(String fullname) throws RemoteException; String getCreationdate() throws RemoteException; void setCreationdate(String creationdate) throws RemoteException; Date getExpiredate() throws RemoteException; void setExpiredate(Date expiredate) throws RemoteException; Float getAmmount() throws RemoteException; void setAmmount(Float ammount) throws RemoteException; Integer getChargettype() throws RemoteException; void setChargettype(Integer chargettype) throws RemoteException; //Business Methods public Boolean hasExpired() throws RemoteException; TicketHome.java /** * Created by IntelliJ IDEA. * User: skentros * Date: 22 Ιουλ 2004 * Time: 5:53:25 μμ

149

* To change this template use File | Settings | File Templates. */ package nettechn.BankClearence.Ticket; import javax.ejb.EJBHome; import javax.ejb.FinderException; import javax.ejb.CreateException; import java.rmi.RemoteException; public interface TicketHome extends EJBHome Ticket findByPrimaryKey(Object key) throws RemoteException, FinderException; //Constructors /** * Ticket constrcutor * * @param company_id The company ID for which this ticket is being created * @param userfullname The fullname of the customer for whom the ticket is created * @param ammount The ammount of money of the transaction * @param chargetype The charge type of the transaction * @return Ticket being created * @throws RemoteException * @throws CreateException If ticket can not be created, eg ammount not set. */ public Ticket create(Integer company_id, String userfullname, Float ammount, Integer chargeType) throws RemoteException, CreateException; LocalTicket.java /** * Created by IntelliJ IDEA. * User: skentros * Date: 22 Ιουλ 2004 * Time: 5:53:26 μμ * To change this template use File | Settings | File Templates. */ package nettechn.BankClearence.Ticket; import javax.ejb.EJBLocalObject; import java.sql.Timestamp; import java.util.Date; public interface LocalTicket extends EJBLocalObject Integer getCompany_id(); void setCompany_id(Integer company_id); String getFullname(); void setFullname(String fullname); String getCreationdate(); void setCreationdate(String creationdate); Date getExpiredate();

150

void setExpiredate(Date expiredate); Float getAmmount(); void setAmmount(Float ammount); Integer getChargettype(); void setChargettype(Integer chargettype); LocalTicketHome.java /** * Created by IntelliJ IDEA. * User: skentros * Date: 22 Ιουλ 2004 * Time: 5:53:26 μμ * To change this template use File | Settings | File Templates. */ package nettechn.BankClearence.Ticket; import javax.ejb.EJBLocalHome; import javax.ejb.FinderException; public interface LocalTicketHome extends EJBLocalHome LocalTicket findByPrimaryKey(Object key) throws FinderException; //Business Methods public Boolean hasExpired(); TransactionEJB TransactionBean.java /** * Created by IntelliJ IDEA. * User: skentros * Date: 15 Ιουλ 2004 * Time: 3:24:26 μμ * To change this template use File | Settings | File Templates. */ package nettechn.BankClearence.Transactions; import com.element.proxypay3.paymentmethod.apacs.api.data.OnlineResponse; import com.element.proxypay3.paymentmethod.apacs.api.data.OrderInfo; import com.element.proxypay3.paymentmethod.apacs.api.data.PaymentInfo; import com.element.proxypay3.paymentmethod.apacs.api.processing.OnlineProcessor; import nettechn.BankClearence.User.LocalUser; import nettechn.BankClearence.User.User; import nettechn.BankClearence.User.UserHome; import nettechn.BankClearence.Company.LocalCompany; import nettechn.BankClearence.exceptions.NotDefinedChargingTypeException; import nettechn.BankClearence.exceptions.TransactionRejectedException; import nettechn.BankClearence.exceptions.ServerUnreachableException; import nettechn.ServiceLocator.ejb.EJBLocator; import nettechn.ServiceLocator.exceptions.ServiceLocatorException;

151

import javax.ejb.*; import java.rmi.RemoteException; import java.util.Calendar; import java.sql.Timestamp; public abstract class TransactionBean implements EntityBean public final static int CreditCard = 2; public final static int BankTransfer = 1; EntityContext ejbContext; public TransactionBean() public void setEntityContext(EntityContext entityContext) throws EJBException this.ejbContext = entityContext; public void unsetEntityContext() throws EJBException public void ejbRemove() throws RemoveException, EJBException public void ejbActivate() throws EJBException public void ejbPassivate() throws EJBException public void ejbLoad() throws EJBException public void ejbStore() throws EJBException public abstract Integer getUser_id(); public abstract void setUser_id(Integer user_id); public abstract Float getAmount(); public abstract void setAmount(Float ammount); public abstract Integer getCharge_type(); public abstract void setCharge_type(Integer charge_type); public abstract Integer getStatus(); public abstract void setStatus(Integer status); public abstract LocalUser getUser1(); public abstract void setUser1(LocalUser user1); private int getTransactionAmmount() String ammount = String.valueOf(getAmount()); if (ammount.indexOf('.') == -1)

152

return Integer.parseInt(ammount); else float f = Float.parseFloat(ammount); f = f * (float) Math.pow(10, ammount.length() - ammount.indexOf('.')); return Math.round(f); public TransactionEJBVO getTransactionEJBVO() return new TransactionEJBVO(getUser_id(), getFullname(), getAmount(), getCharge_type(), getStatus(), getCompany_id()); public void setTransactionEJBVO(TransactionEJBVO value) setUser_id(value.getUser_id()); setAmount(value.getAmmount()); setCharge_type(value.getCharge_type()); setStatus(value.getStatus()); setFullname(value.getFullname()); setCompany_id(value.getCompanyID()); public Object ejbCreate(TransactionEJBVO value) throws CreateException setTransactionEJBVO(value); return null; public void ejbPostCreate(TransactionEJBVO value) throws CreateException //nop public abstract String getTransaction_reference(); public abstract void setTransaction_reference(String transaction_reference); public abstract Timestamp getTransaction_date(); public abstract void setTransaction_date(Timestamp transaction_date); //Business Methods public void executeTransaction() throws NotDefinedChargingTypeException, TransactionRejectedException, ServerUnreachableException try setStatus(new Integer(Transaction.ExecutionStarted)); ejbStore(); EJBLocator locator = EJBLocator.getEJBInstance(); UserHome userHome = (UserHome) locator.getRemoteHome("java:comp/env/ejb/user", UserHome.class); User user = userHome.findByPrimaryKey(getUser_id()); if (getCharge_type().intValue() == CreditCard) setTransaction_date(new Timestamp(Calendar.getInstance().getTimeInMillis())); setStatus(new Integer(Transaction.WAITINGFROAPROVAL)); ejbStore(); OnlineProcessor op = new OnlineProcessor(); OrderInfo oi = new OrderInfo(getTransactionAmmount(), "REF " + "", //merchantRef

153

"Online testing using API", //merchant Description user.getCurrency(), //currency user.getEmail(), //customer Email "var1", //var1 "var2", //var2 "var3", //var3 "var4", //var4 "var5", //var5 "var6", //var6 "var7", //var7 "var8", //var8 "var9"); //var9 PaymentInfo pi = new PaymentInfo(user.getCc_number(), //cc number (Mandatory) user.getCc_expiration_date(), //expiration date (Mandatory) user.getCvccvv_code(), //CVCCVVcode "0", //installment offset "0"); //installment period OnlineResponse response = op.DoPreAuth(oi, //order information pi //payment information ); setTransaction_date(new Timestamp(Calendar.getInstance().getTimeInMillis())); switch (response.getErrorCode()) case 0: setStatus(new Integer(Transaction.APPROVED)); setTransaction_reference(response.getProxypayref()); ejbStore(); break; case 30: setStatus(new Integer(Transaction.REJECTED)); setTransaction_reference(response.getErrorMessage()); ejbStore(); throw new TransactionRejectedException(getTransaction_reference()); case 1000: setStatus(new Integer(Transaction.SERVERANREACHABLE)); ejbStore(); throw new ServerUnreachableException(getTransaction_reference()); else if (getCharge_type().intValue() == BankTransfer) //@todo implement Bank Credit //not yet implemented! else throw new NotDefinedChargingTypeException("Charging type is not defined"); catch (ServiceLocatorException ex) ex.printStackTrace(); catch (RemoteException ex)

154

ex.printStackTrace(); catch (FinderException ex) ex.printStackTrace(); public abstract Integer getCompany_id(); public abstract void setCompany_id(Integer company_id); public abstract LocalCompany getCompany(); public abstract void setCompany(LocalCompany company); public void ejbHomeExecuteTransaction() throws NotDefinedChargingTypeException, TransactionRejectedException, ServerUnreachableException executeTransaction(); public abstract String getFullname(); public abstract void setFullname(String fullname); TransactionDelegate.java package nettechn.BankClearence.Transactions; import nettechn.ServiceLocator.ejb.EJBLocator; import nettechn.ServiceLocator.exceptions.ServiceLocatorException; import javax.ejb.FinderException; import java.rmi.RemoteException; /** * Created by IntelliJ IDEA. * User: skentros * Date: 11 Αυγ 2004 * Time: 2:47:37 μμ * To change this template use File | Settings | File Templates. */ public class TransactionDelegate public static TransactionEJBVO getTransactionDetails(String transid) if (transid == null) return null; Long trsID = new Long(transid); try TransactionHome transactionHome = (TransactionHome) EJBLocator.getEJBInstance().getRemoteHome("java:comp/env/ejb/transaction",TransactionHome.class ); Transaction trans = transactionHome.findByPrimaryKey(trsID); return trans.getTransactionEJBVO(); catch (ServiceLocatorException ex) ex.printStackTrace(); catch (RemoteException ex) ex.printStackTrace(); catch (FinderException ex)

155

ex.printStackTrace(); return null; TransactionEJBVO.java package nettechn.BankClearence.Transactions; import java.io.Serializable; /** * Created by IntelliJ IDEA. * User: skentros * Date: 19 Ιουλ 2004 * Time: 2:35:25 μμ * To change this template use File | Settings | File Templates. */ public class TransactionEJBVO implements Serializable //private final Integer TransactionID; private final Integer user_id; private final String fullname; private final Float ammount; private final Integer charge_type; private final Integer status; private final Integer company_id; public TransactionEJBVO(Integer user_id,String fullname, Float ammount, Integer charge_type, Integer status, Integer company_id) this.user_id = user_id; this.ammount = ammount; this.charge_type = charge_type; this.status = status; this.company_id = company_id; this.fullname = fullname; //this.TransactionID = TransactionID; /*public Integer getTransactionID() return TransactionID; */ public Integer getCompanyID() return company_id; public Integer getUser_id() return user_id; public Float getAmmount() return ammount; public Integer getCharge_type() return charge_type;

156

public Integer getStatus() return status; public String getFullname() return this.fullname; Transaction.java /** * Created by IntelliJ IDEA. * User: skentros * Date: 15 Ιουλ 2004 * Time: 3:24:26 μμ * To change this template use File | Settings | File Templates. */ package nettechn.BankClearence.Transactions; import nettechn.BankClearence.exceptions.NotDefinedChargingTypeException; import nettechn.BankClearence.exceptions.TransactionRejectedException; import nettechn.BankClearence.exceptions.ServerUnreachableException; import javax.ejb.EJBObject; import java.rmi.RemoteException; import java.sql.Timestamp; public interface Transaction extends EJBObject public static final int ExecutionStarted = 0; public static final int WAITINGFROAPROVAL = 1; public static final int APPROVED = 2; public static final int REJECTED = 3; public static final int FAILED = 4; public static final int SERVERANREACHABLE = 5; Integer getUser_id() throws RemoteException; void setUser_id(Integer user_id) throws RemoteException; Float getAmount() throws RemoteException; void setAmount(Float ammount) throws RemoteException; Integer getCharge_type() throws RemoteException; void setCharge_type(Integer charge_type) throws RemoteException; Integer getStatus() throws RemoteException; void setStatus(Integer status) throws RemoteException; TransactionEJBVO getTransactionEJBVO() throws RemoteException; void setTransactionEJBVO(TransactionEJBVO value) throws RemoteException; String getTransaction_reference() throws RemoteException; void setTransaction_reference(String transaction_reference) throws RemoteException;

157

Timestamp getTransaction_date() throws RemoteException; void setTransaction_date(Timestamp transaction_date) throws RemoteException; Integer getCompany_id() throws RemoteException; void setCompany_id(Integer company_id) throws RemoteException; String getFullname() throws RemoteException; void setFullname(String fullname) throws RemoteException; //Bussiness Methods public void executeTransaction() throws RemoteException, NotDefinedChargingTypeException, TransactionRejectedException, ServerUnreachableException; TransactionHome.java /** * Created by IntelliJ IDEA. * User: skentros * Date: 15 Ιουλ 2004 * Time: 3:24:25 μμ * To change this template use File | Settings | File Templates. */ package nettechn.BankClearence.Transactions; import nettechn.BankClearence.exceptions.NotDefinedChargingTypeException; import nettechn.BankClearence.exceptions.TransactionRejectedException; import nettechn.BankClearence.exceptions.ServerUnreachableException; import javax.ejb.EJBHome; import javax.ejb.FinderException; import javax.ejb.CreateException; import java.rmi.RemoteException; import java.util.Collection; public interface TransactionHome extends EJBHome Transaction findByPrimaryKey(Object key) throws RemoteException, FinderException; public Collection findByUserId(Integer userId) throws RemoteException,FinderException; public Collection findByStatus(Integer status) throws RemoteException,FinderException; public Transaction create(TransactionEJBVO value) throws RemoteException, CreateException; LocalTransaction.java /** * Created by IntelliJ IDEA. * User: skentros * Date: 15 Ιουλ 2004 * Time: 3:24:26 μμ * To change this template use File | Settings | File Templates. */ package nettechn.BankClearence.Transactions; import nettechn.BankClearence.User.LocalUser;

158

import nettechn.BankClearence.Company.LocalCompany; import nettechn.BankClearence.exceptions.NotDefinedChargingTypeException; import nettechn.BankClearence.exceptions.TransactionRejectedException; import nettechn.BankClearence.exceptions.ServerUnreachableException; import javax.ejb.EJBLocalObject; import java.sql.Timestamp; public interface LocalTransaction extends EJBLocalObject Integer getUser_id(); void setUser_id(Integer user_id); Float getAmount(); void setAmount(Float ammount); Integer getCharge_type(); void setCharge_type(Integer charge_type); LocalUser getUser1(); void setUser1(LocalUser user1); TransactionEJBVO getTransactionEJBVO(); void setTransactionEJBVO(TransactionEJBVO value); String getTransaction_reference(); void setTransaction_reference(String transaction_reference); Timestamp getTransaction_date(); void setTransaction_date(Timestamp transaction_date); Integer getCompany_id(); void setCompany_id(Integer company_id); LocalCompany getCompany(); void setCompany(LocalCompany company); String getFullname(); void setFullname(String fullname); void executeTransaction() throws NotDefinedChargingTypeException, TransactionRejectedException, ServerUnreachableException; LocalTransactionHome.java /** * Created by IntelliJ IDEA. * User: skentros * Date: 15 Ιουλ 2004

159

* Time: 3:24:26 μμ * To change this template use File | Settings | File Templates. */ package nettechn.BankClearence.Transactions; import javax.ejb.EJBLocalHome; import javax.ejb.FinderException; import javax.ejb.CreateException; public interface LocalTransactionHome extends EJBLocalHome LocalTransaction findByPrimaryKey(Object key) throws FinderException; LocalTransaction create(TransactionEJBVO value) throws CreateException; NotDefinedChargingType.java package nettechn.BankClearence.Transactions; /** * Created by IntelliJ IDEA. * User: skentros * Date: 19 Ιουλ 2004 * Time: 2:02:20 μμ * To change this template use File | Settings | File Templates. */ public class NotDefinedChargingType extends Exception public NotDefinedChargingType(String message) super(message); public String getMessage() return super.getMessage(); TransactionRejected.java package nettechn.BankClearence.Transactions; /** * Created by IntelliJ IDEA. * User: skentros * Date: 20 Ιουλ 2004 * Time: 1:38:26 μμ * To change this template use File | Settings | File Templates. */ public class TransactionRejected extends Exception public TransactionRejected(String message) super(message); public String getMessage() return super.getMessage();

160

UserEJB UserBean.java /** * Created by IntelliJ IDEA. * User: skentros * Date: 15 Ιουλ 2004 * Time: 12:44:19 μμ * To change this template use File | Settings | File Templates. */ package nettechn.BankClearence.User; import nettechn.BankClearence.Ticket.Ticket; import nettechn.BankClearence.Transactions.*; import nettechn.BankClearence.exceptions.NotDefinedChargingTypeException; import nettechn.BankClearence.exceptions.TransactionRejectedException; import nettechn.BankClearence.exceptions.ServerUnreachableException; import nettechn.BankClearence.TransactionComplete.TransactionComplete; import nettechn.BankClearence.TransactionComplete.TransactionCompleteHome; import nettechn.ServiceLocator.ejb.EJBLocator; import nettechn.ServiceLocator.exceptions.ServiceLocatorException; import nettechn.utilities.AESCipher; import javax.ejb.*; import java.util.Collection; import java.util.ResourceBundle; public abstract class UserBean implements EntityBean // private javax.ejb.EntityContext context; public UserBean() public void setEntityContext(EntityContext entityContext) throws EJBException public void unsetEntityContext() throws EJBException public Integer ejbCreate(Integer userID, String userName, String password) throws CreateException setUser_id(userID); setUsername(userName); setPassword(password); return null; public void ejbPostCreate(Integer userID, String userName, String password) throws CreateException public void ejbRemove() throws RemoveException, EJBException public void ejbActivate() throws EJBException public void ejbPassivate() throws EJBException

161

public void ejbLoad() throws EJBException public void ejbStore() throws EJBException public abstract Integer getUser_id(); public abstract void setUser_id(Integer user_id); public abstract String getCc_number(); public abstract void setCc_number(String cc_number); public abstract String getCc_expiration_date(); public abstract void setCc_expiration_date(String cc_expiration_date); public abstract String getCard(); public abstract void setCard(String card); public abstract String getBank_number(); public abstract void setBank_number(String bank_number); public abstract String getBank(); public abstract void setBank(String bank); public abstract String getFullname(); public abstract void setFullname(String fullname); public abstract Collection getTransaction(); public abstract void setTransaction(Collection transaction); //public abstract Collection getUserSession(); //public abstract void setUserSession(Collection userSession); //business methods public void newTransaction(Ticket ticket) throws TransactionRejectedException, NotDefinedChargingTypeException, ServerUnreachableException ResourceBundle rb = ResourceBundle.getBundle("nettechn.BankClearence.resources.messages"); try if (ticket.hasExpired().booleanValue()) throw new TransactionRejectedException(rb.getString("1004")); if (ticket.getAmmount().intValue() > 0) TransactionEJBVO value = new TransactionEJBVO(getUser_id(), ticket.getFullname(), ticket.getAmmount(), ticket.getChargettype(), new Integer(Transaction.WAITINGFROAPROVAL), ticket.getCompany_id());

162

TransactionCompleteHome transactionCompleteHome = (TransactionCompleteHome) EJBLocator.getEJBInstance().getRemoteHome("java:comp/env/ejb/transactionComplete", TransactionCompleteHome.class); TransactionComplete transactionComplete = null; try transactionComplete = transactionCompleteHome.create(); getTransaction().add(transactionComplete.createAndExecuteNewTransaction(value)); catch (CreateException e) e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates. return; catch (java.rmi.RemoteException ex) ex.printStackTrace(); catch (ServiceLocatorException ex) ex.printStackTrace(); throw new TransactionRejectedException(rb.getString("1005")); public abstract String getCvccvv_code(); public abstract void setCvccvv_code(String cvccvv_code); public abstract String getCurrency(); public abstract void setCurrency(String currency); public abstract String getEmail(); public abstract void setEmail(String email); public abstract Integer getExt_user_id(); public abstract void setExt_user_id(Integer ext_user_id); public abstract String getPassword(); public abstract void setPassword(String password); public abstract Collection getCompany(); public abstract void setCompany(Collection company); /* public UserEJBVO getUserEJBVO() return new UserEJBVO(getCc_number(), getCc_expiration_date(), getFullname(), getCard(), getBank_number(), getBank(), getFullname(), getCvccvv_code(), getCurrency(), getEmail()); */ public void setUserEJBVO(UserEJBVO value, byte[] wrappedKey) throws AESCipher.EncryptionException try AESCipher aes = new AESCipher(); aes.setWithWrappedKey(wrappedKey);

163

setCc_number(aes.encrypt(value.getCc_number())); setCc_expiration_date(aes.encrypt(value.getCc_expiration_date())); setCard(aes.encrypt(value.getCard())); setBank_number(aes.encrypt(value.getBank_number())); setBank(aes.encrypt(value.getBank())); setFullname(aes.encrypt(value.getFullname())); setCvccvv_code(aes.encrypt(value.getCvccvv_code())); setCurrency(aes.encrypt(value.getCurrency())); setEmail(value.getEmail()); this.setCc_fullname(aes.encrypt(value.getCc_fullname())); catch (AESCipher.EncryptionException ex) ex.printStackTrace(); public abstract String getCc_fullname(); public abstract void setCc_fullname(String cc_fullname); public abstract String getUsername(); public abstract void setUsername(String username); UserEJBVO.java package nettechn.BankClearence.User; import java.io.Serializable; /** * Created by IntelliJ IDEA. * User: skentros * Date: 23 Ιουλ 2004 * Time: 1:28:40 μμ * To change this template use File | Settings | File Templates. */ public class UserEJBVO implements Serializable private final String cc_number; private final String cc_expiration_date; private final String card; private final String bank_number; private final String bank; private final String fullname; private final String cvccvv_code; private final String currency; private final String email; public String getCc_fullname() return cc_fullname; private final String cc_fullname; public UserEJBVO(String cc_number, String cc_expiration_date, String card, String bank_number, String bank, String fullname, String cvccvv_code, String currency, String email, String cc_fullname) this.cc_number = cc_number; this.cc_expiration_date = cc_expiration_date; this.card = card;

164

this.bank_number = bank_number; this.bank = bank; this.fullname = fullname; this.cvccvv_code = cvccvv_code; this.currency = currency; this.email = email; this.cc_fullname = cc_fullname; public String getCc_number() return cc_number; public String getCc_expiration_date() return cc_expiration_date; public String getCard() return card; public String getBank_number() return bank_number; public String getBank() return bank; public String getFullname() return fullname; public String getCvccvv_code() return cvccvv_code; public String getCurrency() return currency; public String getEmail() return email; User.java /** * Created by IntelliJ IDEA. * User: skentros * Date: 15 Ιουλ 2004 * Time: 12:44:19 μμ * To change this template use File | Settings | File Templates. */ package nettechn.BankClearence.User; import nettechn.BankClearence.Ticket.Ticket; import nettechn.BankClearence.exceptions.TransactionRejectedException; import nettechn.BankClearence.exceptions.NotDefinedChargingTypeException;

165

import nettechn.BankClearence.exceptions.NotDefinedChargingTypeException; import nettechn.BankClearence.exceptions.ServerUnreachableException; import nettechn.utilities.AESCipher; import javax.ejb.EJBObject; import java.rmi.RemoteException; public interface User extends EJBObject Integer getUser_id() throws RemoteException; void setUser_id(Integer user_id) throws RemoteException; String getCc_number() throws RemoteException; void setCc_number(String cc_number) throws RemoteException; String getCc_expiration_date() throws RemoteException; void setCc_expiration_date(String cc_expiration_date) throws RemoteException; String getCard() throws RemoteException; void setCard(String card) throws RemoteException; String getBank_number() throws RemoteException; void setBank_number(String bank_number) throws RemoteException; String getBank() throws RemoteException; void setBank(String bank) throws RemoteException; String getFullname() throws RemoteException; void setFullname(String fullname) throws RemoteException; String getCvccvv_code() throws RemoteException; void setCvccvv_code(String cvccvv_code) throws RemoteException; String getCurrency() throws RemoteException; void setCurrency(String currency) throws RemoteException; String getEmail() throws RemoteException; void setEmail(String email) throws RemoteException; Integer getExt_user_id() throws RemoteException; void setExt_user_id(Integer ext_user_id) throws RemoteException; String getPassword() throws RemoteException; public void setPassword(String password) throws RemoteException; String getUsername() throws RemoteException; void setUsername(String username) throws RemoteException;

166

String getCc_fullname() throws RemoteException; void setCc_fullname(String cc_fullname) throws RemoteException; //BUSSINESS METHODS public void newTransaction(Ticket ticket) throws RemoteException, TransactionRejectedException, NotDefinedChargingTypeException, ServerUnreachableException; /* public UserEJBVO getUserEJBVO() throws RemoteException;*/ public void setUserEJBVO(UserEJBVO value, byte[] wrappedKey) throws RemoteException, AESCipher.EncryptionException; UserHome.java /** * Created by IntelliJ IDEA. * User: skentros * Date: 15 Ιουλ 2004 * Time: 12:44:18 μμ * To change this template use File | Settings | File Templates. */ package nettechn.BankClearence.User; import javax.ejb.EJBHome; import javax.ejb.FinderException; import javax.ejb.CreateException; import java.rmi.RemoteException; public interface UserHome extends EJBHome User findByPrimaryKey(Integer key) throws RemoteException, FinderException; User findByUsernameAndPassword(String userName, String password) throws RemoteException, FinderException; public User create(Integer userID, String userName, String password) throws RemoteException, CreateException; LocalUser.java /** * Created by IntelliJ IDEA. * User: skentros * Date: 15 Ιουλ 2004 * Time: 12:44:19 μμ * To change this template use File | Settings | File Templates. */ package nettechn.BankClearence.User; import nettechn.BankClearence.Company.LocalCompany; import nettechn.BankClearence.Ticket.Ticket; import nettechn.BankClearence.exceptions.TransactionRejectedException; import nettechn.BankClearence.exceptions.NotDefinedChargingTypeException; import nettechn.BankClearence.exceptions.NotDefinedChargingTypeException; import nettechn.BankClearence.exceptions.ServerUnreachableException; import javax.ejb.EJBLocalObject; import java.util.Collection;

167

public interface LocalUser extends EJBLocalObject Integer getUser_id(); void setUser_id(Integer user_id); String getCc_number(); void setCc_number(String cc_number); String getCc_expiration_date(); void setCc_expiration_date(String cc_expiration_date); String getCard(); void setCard(String card); String getBank_number(); void setBank_number(String bank_number); String getBank(); void setBank(String bank); String getFullname(); void setFullname(String fullname); Collection getTransaction(); void setTransaction(Collection transaction); //Collection getUserSession(); //void setUserSession(Collection userSession); String getCvccvv_code(); void setCvccvv_code(String cvccvv_code); String getCurrency(); void setCurrency(String currency); String getEmail(); void setEmail(String email); Integer getExt_user_id(); void setExt_user_id(Integer ext_user_id); String getUsername(); void setUsername(String username); String getPassword(); void setPassword(String password);

168

Collection getCompany(); void setCompany(Collection company); //public UserEJBVO getUserEJBVO(); //public void setUserEJBVO(UserEJBVO value); String getCc_fullname(); void setCc_fullname(String cc_fullname); //Business method public void newTransaction(Ticket ticket) throws TransactionRejectedException, NotDefinedChargingTypeException, ServerUnreachableException; LocalUserHome.java /** * Created by IntelliJ IDEA. * User: skentros * Date: 15 Ιουλ 2004 * Time: 12:44:19 μμ * To change this template use File | Settings | File Templates. */ package nettechn.BankClearence.User; import javax.ejb.EJBLocalHome; import javax.ejb.FinderException; public interface LocalUserHome extends EJBLocalHome LocalUser findByPrimaryKey(Integer key) throws FinderException; LocalUser findByUsernameAndPassword(String userName, String password) throws FinderException; CompanySessionEJB CompanySessionBean.java /** * Created by IntelliJ IDEA. * User: skentros * Date: 22 Ιουλ 2004 * Time: 3:09:23 μμ * To change this template use File | Settings | File Templates. */ package nettechn.BankClearence.CompanySession; import nettechn.BankClearence.Company.Company; import nettechn.BankClearence.Company.CompanyHome; import nettechn.BankClearence.Ticket.Ticket; import nettechn.BankClearence.Ticket.TicketHome; import nettechn.BankClearence.exceptions.LoginException; import nettechn.ServiceLocator.ejb.EJBLocator;

169

import nettechn.ServiceLocator.exceptions.ServiceLocatorException; import javax.ejb.*; import java.rmi.RemoteException; import java.util.ResourceBundle; public class CompanySessionBean implements SessionBean private SessionContext sessionContext; public CompanySessionBean() public Ticket getTicket(String companyname, String password, String username, Float ammount, Integer chargeType) throws LoginException ResourceBundle rb = ResourceBundle.getBundle("nettechn.BankClearence.resources.messages"); try EJBLocator locator = EJBLocator.getEJBInstance(); CompanyHome companyHome = (CompanyHome) locator.getRemoteHome("java:comp/env/ejb/company",CompanyHome.class); Company tmp = companyHome.findByCompanyName(companyname.trim()); if (tmp == null) throw new LoginException(rb.getString("1000")); if (tmp.getPassword().compareTo(password) != 0) throw new LoginException(rb.getString("1001")); TicketHome ticketHome = (TicketHome) locator.getRemoteHome("java:comp/env/ejb/ticket",TicketHome.class); System.out.println("Before creating the ticket"); return ticketHome.create(tmp.getCompany_id(), username, ammount, chargeType); catch (ServiceLocatorException ex) ex.printStackTrace(); catch (FinderException ex) ex.printStackTrace(); catch (RemoteException ex) ex.printStackTrace(); catch (CreateException ex) ex.printStackTrace(); throw new LoginException(rb.getString("1002")); public void ejbCreate() throws CreateException public void setSessionContext(SessionContext sessionContext) throws EJBException this.sessionContext = sessionContext; public void ejbRemove() throws EJBException

170

public void ejbActivate() throws EJBException public void ejbPassivate() throws EJBException public Ticket ejbHomeGetTicket(String companyname, String password, String username, Float ammount, Integer ChargeType) throws LoginException return getTicket(companyname, password, username, ammount, ChargeType); CompanySession.java /** * Created by IntelliJ IDEA. * User: skentros * Date: 22 Ιουλ 2004 * Time: 3:09:23 μμ * To change this template use File | Settings | File Templates. */ package nettechn.BankClearence.CompanySession; import nettechn.BankClearence.exceptions.LoginException; import nettechn.BankClearence.Ticket.Ticket; import javax.ejb.EJBObject; import java.rmi.RemoteException; public interface CompanySession extends EJBObject public Ticket getTicket(String companyname, String password, String username, Float ammount, Integer ChargeType) throws RemoteException, LoginException; CompanySessionHome.java /** * Created by IntelliJ IDEA. * User: skentros * Date: 22 Ιουλ 2004 * Time: 3:09:23 μμ * To change this template use File | Settings | File Templates. */ package nettechn.BankClearence.CompanySession; import nettechn.BankClearence.exceptions.LoginException; import nettechn.BankClearence.Ticket.Ticket; import javax.ejb.EJBHome; import javax.ejb.CreateException; import java.rmi.RemoteException; public interface CompanySessionHome extends EJBHome CompanySession create() throws RemoteException, CreateException;

171

UserSessionEJB UserSessionBean.java /** * Created by IntelliJ IDEA. * User: skentros * Date: 22 Ιουλ 2004 * Time: 1:51:23 μμ * To change this template use File | Settings | File Templates. */ package nettechn.BankClearence.UserSession; import nettechn.BankClearence.Ticket.Ticket; import nettechn.BankClearence.User.UserEJBVO; import nettechn.BankClearence.User.UserHome; import nettechn.BankClearence.User.User; import nettechn.BankClearence.Transactions.*; import nettechn.BankClearence.Company.CompanyHome; import nettechn.BankClearence.exceptions.*; import nettechn.ServiceLocator.ejb.EJBLocator; import nettechn.ServiceLocator.exceptions.ServiceLocatorException; import nettechn.utilities.AESCipher; import javax.ejb.*; import java.util.ResourceBundle; import java.rmi.RemoteException; public class UserSessionBean implements SessionBean User user = null; public UserSessionBean() public void setSessionContext(SessionContext sessionContext) throws EJBException public void ejbRemove() throws EJBException public void ejbActivate() throws EJBException public void ejbPassivate() throws EJBException public Integer create(String username, String password) throws LoginException try UserHome userHome = (UserHome) EJBLocator.getEJBInstance().getRemoteHome("java:comp/env/ejb/user", UserHome.class); user = null; if ((user = userHome.findByUsernameAndPassword(username, password)) != null) return user.getUser_id(); else throw new LoginException("User not found!"); catch (ServiceLocatorException ex) ex.printStackTrace();

172

catch (RemoteException ex) ex.printStackTrace(); catch (FinderException ex) ex.printStackTrace(); return null; public void ejbCreate() throws CreateException, LoginException throw new CreateException("User should login first, use create(username,password) instead of this"); public Integer create() throws LoginException throw new LoginException("User should login first, use create(username,password) instead of this"); public void ejbCreate(String username, String password) throws CreateException, LoginException create(username, password); //business methods public Object newTransaction(Ticket ticket) throws NotDefinedChargingTypeException, TransactionRejectedException, ServerUnreachableException try ResourceBundle rb = ResourceBundle.getBundle("nettechn.BankClearence.resources.messages"); if (ticket.hasExpired().booleanValue()) throw new TransactionRejectedException(rb.getString("1004")); EJBLocator locator = EJBLocator.getEJBInstance(); TransactionHome transactionHome = (TransactionHome) locator.getRemoteHome("java:comp/env/ejb/transaction", TransactionHome.class); CompanyHome companyHome = (CompanyHome) locator.getRemoteHome("java:comp/env/ejb/company", CompanyHome.class); if (ticket.getAmmount().intValue() > 0) TransactionEJBVO value = new TransactionEJBVO(this.getUserID(), ticket.getFullname(), ticket.getAmmount(), ticket.getChargettype(), new Integer(Transaction.WAITINGFROAPROVAL), ticket.getCompany_id()); Transaction trans = transactionHome.create(value); companyHome.findByPrimaryKey(ticket.getCompany_id()).getTransaction().add(trans); trans.executeTransaction(); return trans.getPrimaryKey(); catch (ServiceLocatorException ex) ex.printStackTrace(); catch (RemoteException ex) ex.printStackTrace(); catch (CreateException ex)

173

ex.printStackTrace(); catch (FinderException ex) ex.printStackTrace(); return null; public Integer getUserID() Integer userid = null; try userid = user.getUser_id(); catch (RemoteException e) e.printStackTrace(); return userid; public UserEJBVO getUserDetails(byte[] wrappedKey) throws UserNotSetException, AESCipher.EncryptionException if (this.user == null) throw new UserNotSetException(""); else try AESCipher aes = new AESCipher(); aes.setWithWrappedKey(wrappedKey); UserEJBVO details = new UserEJBVO(aes.decrypt(user.getCc_number()), aes.decrypt(user.getCc_expiration_date()), aes.decrypt(user.getCard()), aes.decrypt(user.getBank_number()), aes.decrypt(user.getBank()), aes.decrypt(user.getFullname()), aes.decrypt(user.getCvccvv_code()), aes.decrypt(user.getCurrency()), user.getEmail(), aes.decrypt(user.getCc_fullname())); return details; catch (RemoteException ex) ex.printStackTrace(); catch (AESCipher.EncryptionException ex) ex.printStackTrace(); return null; public void ejbHomeNewTransaction(Ticket ticket, UserEJBVO details) throws NotDefinedChargingTypeException, TransactionRejectedException, ServerUnreachableException newTransaction(ticket,details); public UserEJBVO ejbHomeGetUserDetails(byte[] wrappedKey) throws UserNotSetException, AESCipher.EncryptionException return getUserDetails(wrappedKey);

174

UserSession.java /** * Created by IntelliJ IDEA. * User: skentros * Date: 22 Ιουλ 2004 * Time: 1:51:23 μμ * To change this template use File | Settings | File Templates. */ package nettechn.BankClearence.UserSession; import nettechn.BankClearence.Ticket.Ticket; import nettechn.BankClearence.User.UserEJBVO; import nettechn.BankClearence.exceptions.TransactionRejectedException; import nettechn.BankClearence.exceptions.*; import nettechn.utilities.AESCipher; import javax.ejb.EJBObject; import java.rmi.RemoteException; public interface UserSession extends EJBObject public Integer create(String username, String password) throws RemoteException, LoginException; public Integer create() throws RemoteException, LoginException; //Business methods public Object newTransaction(Ticket ticket) throws RemoteException, NotDefinedChargingTypeException, TransactionRejectedException, ServerUnreachableException; public Integer getUserID() throws RemoteException; public UserEJBVO getUserDetails(byte[] wrappedKey) throws UserNotSetException, RemoteException, AESCipher.EncryptionException; UserSessionHome.java /** * Created by IntelliJ IDEA. * User: skentros * Date: 22 Ιουλ 2004 * Time: 1:51:23 μμ * To change this template use File | Settings | File Templates. */ package nettechn.BankClearence.UserSession; import nettechn.BankClearence.Ticket.Ticket; import nettechn.BankClearence.User.UserEJBVO; import nettechn.BankClearence.exceptions.NotDefinedChargingTypeException; import nettechn.BankClearence.exceptions.TransactionRejectedException; import nettechn.BankClearence.exceptions.LoginException; import nettechn.BankClearence.exceptions.UserNotSetException; import nettechn.utilities.AESCipher; import javax.ejb.EJBHome; import javax.ejb.CreateException; import java.rmi.RemoteException; public interface UserSessionHome extends EJBHome UserSession create() throws RemoteException, CreateException, LoginException;

175

UserSession create(String username, String password) throws RemoteException, CreateException, LoginException; UserDelegate.java package nettechn.BankClearence.UserSession; import nettechn.ServiceLocator.ejb.EJBLocator; import nettechn.ServiceLocator.exceptions.ServiceLocatorException; import nettechn.BankClearence.exceptions.LoginException; import nettechn.utilities.encoder; import javax.ejb.CreateException; import java.rmi.RemoteException; /** * Created by IntelliJ IDEA. * User: skentros * Date: 10 Αυγ 2004 * Time: 9:37:34 πμ * To change this template use File | Settings | File Templates. */ public class UserDelegate /** * This function performs a user login, if the login is completed correctly then it returns * the UserID, otherwise returns null. * * @param username The username of the user * @param password The password of the user * @return The UserID if the login is performed correctly * @throws LoginException if somethings goes wrong while trying to login the user */ public static UserSession UserLogin(String username, String password) throws LoginException UserSession res; res = null; System.out.println("Get prepared!!!"); try System.out.println("One big step!!!"); UserSessionHome userSessionHome = (UserSessionHome) EJBLocator.getEJBInstance().getRemoteHome("java:comp/env/ejb/userSession", UserSessionHome.class); try System.out.println("Two big steps!!!"); res = userSessionHome.create(username, encoder.OneWayEncrypt(password)); catch (RemoteException e) e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates. catch (CreateException e) e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates. catch (ServiceLocatorException ex) ex.printStackTrace(); return res;

176

LoginException.java package nettechn.BankClearence.exceptions; /** * Created by IntelliJ IDEA. * User: skentros * Date: 22 Ιουλ 2004 * Time: 4:53:28 μμ * To change this template use File | Settings | File Templates. */ public class LoginException extends Exception public LoginException(String msg) super(msg); public LoginException() super(); public String getMessage() return super.getMessage(); NotDefinedChargingTypeException.java package nettechn.BankClearence.exceptions; /** * Created by IntelliJ IDEA. * User: skentros * Date: 19 Ιουλ 2004 * Time: 2:02:20 μμ * To change this template use File | Settings | File Templates. */ public class NotDefinedChargingTypeException extends Exception public NotDefinedChargingTypeException(String message) super(message); public String getMessage() return super.getMessage(); ServerUnreachableException.java package nettechn.BankClearence.exceptions; /** * Created by IntelliJ IDEA. * User: skentros * Date: 11 Αυγ 2004 * Time: 5:20:43 μμ * To change this template use File | Settings | File Templates. */ public class ServerUnreachableException extends Exception public ServerUnreachableException(String message)

177

super(message); public String getMessage() return super.getMessage(); TransactionRejectedException.java package nettechn.BankClearence.exceptions; /** * Created by IntelliJ IDEA. * User: skentros * Date: 20 Ιουλ 2004 * Time: 1:38:26 μμ * To change this template use File | Settings | File Templates. */ public class TransactionRejectedException extends Exception public TransactionRejectedException(String message) super(message); public String getMessage() return super.getMessage(); UserNotSetException.java package nettechn.BankClearence.exceptions; /** * Created by IntelliJ IDEA. * User: skentros * Date: 10 Αυγ 2004 * Time: 1:37:54 μμ * To change this template use File | Settings | File Templates. */ public class UserNotSetException extends Exception public UserNotSetException(String msg) super(msg); companyGetTicketServlet.java package nettechn.clearence.web; import nettechn.ServiceLocator.ejb.EJBLocator; import nettechn.ServiceLocator.exceptions.ServiceLocatorException; import nettechn.BankClearence.CompanySession.CompanySession; import nettechn.BankClearence.CompanySession.CompanySessionHome; import nettechn.BankClearence.exceptions.LoginException; import nettechn.BankClearence.Ticket.Ticket; import nettechn.utilities.encoder; import javax.servlet.http.HttpServlet;

178

import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.servlet.ServletException; import javax.ejb.CreateException; import java.io.IOException; /** * Created by IntelliJ IDEA. * User: skentros * Date: 9 Αυγ 2004 * Time: 2:20:32 μμ * To change this template use File | Settings | File Templates. */ public class companyGetTicketServlet extends HttpServlet public final static String C_COMPANY_NAME = "companyname"; public final static String C_PASSWORD = "password"; public final static String C_USER_NAME = "username"; public final static String C_AMMOUNT = "ammount"; public final static String C_CHARGE_TYPE = "chargetype"; protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException String companyname = request.getParameter(C_COMPANY_NAME); if (companyname == null) throw new ServletException("Missing parameter"); String password = request.getParameter(C_PASSWORD); if (password == null) throw new ServletException("Missing password"); else password = encoder.OneWayEncrypt(password); String username = request.getParameter(C_USER_NAME); if (username == null) throw new ServletException("Missing parameter"); Float amount = null; Integer chargetype = null; try amount = Float.valueOf(request.getParameter(C_AMMOUNT)); if (amount == null) throw new ServletException("Missing parameter"); chargetype = Integer.valueOf(request.getParameter(C_CHARGE_TYPE)); if (chargetype == null) throw new ServletException("Missing parameter"); catch (NumberFormatException ex) throw new ServletException("Wrong number format"); EJBLocator locator = EJBLocator.getEJBInstance(); try

179

CompanySessionHome companySessionHome = (CompanySessionHome) locator.getRemoteHome("java:comp/env/ejb/companySession", CompanySessionHome.class); CompanySession companySession = companySessionHome.create(); Ticket tckt = companySession.getTicket(companyname, password, username, amount, chargetype); response.sendRedirect("/clearence/web/userlogin.jsp?TicketID=" + tckt.getPrimaryKey()); catch (ServiceLocatorException ex) throw new ServletException("Internal Error. Please try again."); catch (CreateException cex) throw new ServletException("Internal Error. Please try again."); catch (LoginException ex) throw new ServletException("Login Failed"); protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException doPost(request, response); newtransactionServlet.java /** * Created by IntelliJ IDEA. * User: skentros * Date: 20 Ιουλ 2004 * Time: 11:25:31 πμ * To change this template use File | Settings | File Templates. */ package nettechn.clearence.web; import nettechn.ServiceLocator.ejb.EJBLocator; import nettechn.ServiceLocator.exceptions.ServiceLocatorException; import nettechn.BankClearence.Transactions.Transaction; import nettechn.BankClearence.Transactions.TransactionHome; import nettechn.BankClearence.Transactions.TransactionEJBVO; import nettechn.BankClearence.Ticket.TicketDelegate; import nettechn.BankClearence.Ticket.Ticket; import nettechn.BankClearence.UserSession.UserSession; import nettechn.BankClearence.exceptions.NotDefinedChargingTypeException; import nettechn.BankClearence.exceptions.TransactionRejectedException; import nettechn.BankClearence.exceptions.ServerUnreachableException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.servlet.http.HttpSession; import javax.servlet.ServletException; import javax.ejb.CreateException; import java.io.IOException; public class newtransactionServlet extends HttpServlet private final static String head = ""; protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException String ticketID = null;

180

try ticketID = request.getParameter("ticketid"); catch (NumberFormatException ex) ex.printStackTrace(); boolean transactionDone = false; Object transID = null; EJBLocator locator = EJBLocator.getEJBInstance(); try HttpSession ses = request.getSession(true); UserSession usersession = (UserSession) ses.getAttribute("UserSession"); TicketDelegate ticketDelegate = new TicketDelegate(); Ticket ticket = null; if ((ticket = ticketDelegate.getTicket(ticketID)) == null) request.setAttribute("error","1002"); getServletConfig().getServletContext().getRequestDispatcher("/error.jsp").forward(request,response); try transID = usersession.newTransaction(ticket); catch (NotDefinedChargingTypeException ex) ex.printStackTrace(); catch (TransactionRejectedException ex) ex.printStackTrace(); catch (ServerUnreachableException ex) ex.printStackTrace(); catch (ServiceLocatorException ex) ex.printStackTrace(); catch (CreateException ex) ex.printStackTrace(); if (transID != null) response.sendRedirect("/clearence/transactionResult?trnsid=" + transID); else response.sendRedirect("/error.jsp"); protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException doPost(request, response); transactionResultServlet.java package nettechn.clearence.web; import nettechn.utilities.http.userAgent; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.servlet.ServletException;

181

import java.io.IOException; /** * Created by IntelliJ IDEA. * User: skentros * Date: 11 Αυγ 2004 * Time: 2:00:34 μμ * To change this template use File | Settings | File Templates. */ public class transactionResultServlet extends HttpServlet protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException String userStyle = userAgent.getStyle(request.getHeader("User-Agent"), request.getHeader("Accept")); if (userStyle.compareTo(userAgent.C_HTML) == 0) getServletConfig().getServletContext().getRequestDispatcher("/web/result.jsp").forward(request,response); else if (userStyle.compareTo(userAgent.C_xHTML) == 0) getServletConfig().getServletContext().getRequestDispatcher("/xhtml/result.jsp").forward(request,response); protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException doPost(request, response); SSLCheckFilter.java package nettechn.clearence.web; import javax.servlet.*; import javax.servlet.http.HttpServletRequest; import java.io.IOException; /** * Created by IntelliJ IDEA. * User: skentros * Date: 9 Αυγ 2004 * Time: 2:47:26 μμ * To change this template use File | Settings | File Templates. */ public class SSLCheckFilter implements Filter public void destroy() public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws ServletException, IOException if (!(req.isSecure())) HttpServletRequest request = (HttpServletRequest) req; req.setAttribute("error","Connection is not secure!"); request.getSession().getServletContext().getRequestDispatcher("/error.jsp").forward(req,resp);

182

chain.doFilter(req, resp); public void init(FilterConfig config) throws ServletException intro.jsp <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <%@ page contentType="application/xhtml+xml; charset=utf-8" session="true" language="java" %> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Intro</title> <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=utf-8" /> </head> <body> <table> <FORM action="/clearence/companyGetTicket" method="post"> <tr> <td width="80">Company</td> <td><INPUT TYPE="text" NAME="companyname" SIZE=20 VALUE="Net"></td> </tr> <tr> <td width="80">Password</td> <td><INPUT TYPE="password" NAME="password" SIZE=20 VALUE="123"></td> </tr> <tr> <td width="80">Client</td> <td><INPUT TYPE="text" NAME="username" SIZE=20 VALUE="Kentros"></td> </tr> <tr> <td width="80">Ammount</td> <td><INPUT TYPE="text" NAME="ammount" SIZE=20 VALUE="673.35"></td> </tr> <INPUT TYPE="hidden" NAME="chargetype" SIZE=20 VALUE="2"> <tr> <td width="80"><INPUT TYPE="submit" NAME="button" VALUE=Submit></td> </tr> <tr> <td width="80"><INPUT TYPE="reset" VALUE="Reset"></td> </tr> </FORM> </table> </body> </html> userlogin.jsp <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <%@ page contentType="application/xhtml+xml; charset=utf-8" session="true"

183

language="java" import="nettechn.BankClearence.UserSession.UserDelegate, nettechn.BankClearence.UserSession.UserSession" %> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Login</title> <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=utf-8" /> </head> <% String ticketID = null; ticketID = request.getParameter("TicketID"); if (ticketID == null) request.setAttribute("error","No valid ticket ID!"); getServletConfig().getServletContext().getRequestDispatcher("/error.jsp").forward(request,response); String username = ""; if (request.getParameter("fullname") != null) username = request.getParameter("fullname"); String password = ""; if (request.getParameter("password") != null) password = request.getParameter("password"); if ((username.length() > 0) && (password.length() > 0)) UserSession usersession = null; if ((usersession = UserDelegate.UserLogin(username, password)) != null) HttpSession ses = request.getSession(true); ses.setAttribute("UserSession", usersession); request.setAttribute("userid", usersession.getUserID()); getServletConfig().getServletContext().getRequestDispatcher("/web/requestinfo.jsp").forward(request, response); else request.setAttribute("error","Login Failed."); getServletConfig().getServletContext().getRequestDispatcher("/error.jsp").forward(request,response); %> <body bgcolor="#ffffff"> <table width="300" border="0" cellpadding="0" cellspacing="0"> <form action="userlogin.jsp" target="_top" method="post"> <input type="hidden" name="TicketID" value="<%=ticketID%>"/> <tr> <td width="80">User name</td> <td><input name="fullname" type="text" SIZE=20 value="<%=username%>"></td> </tr>

184

<tr> <td width="80">Password</td> <td><input name="password" type="password" SIZE=20 value="<%=password%>"></td> </tr> <tr> <td><INPUT TYPE="submit" NAME="button" VALUE=Submit></td> </tr> <tr> <td><INPUT TYPE="reset" VALUE="Reset"></td> </tr> </form> </table> </body> </html> requestinfo.jsp <%@ page import="nettechn.utilities.AESCipher, nettechn.BankClearence.User.UserEJBVO, nettechn.BankClearence.UserSession.UserSession, nettechn.BankClearence.Ticket.TicketDelegate, nettechn.BankClearence.Ticket.Ticket, java.util.Calendar, nettechn.utilities.strings, nettechn.BankClearence.UserSession.UserDelegate"%> <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <%@ page contentType="application/xhtml+xml; charset=utf-8" session="true" language="java" %> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>UserInfo</title> <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=utf-8" /> </head> <% HttpSession ses = request.getSession(true); UserSession usersession = (UserSession) ses.getAttribute("UserSession"); String ticketID = request.getParameter("TicketID"); TicketDelegate ticketDelegate = new TicketDelegate(); Ticket ticket = null; if (usersession == null) request.setAttribute("error","1000"); getServletConfig().getServletContext().getRequestDispatcher("/error.jsp").forward(request,response); else if (ticketID == null) request.setAttribute("error","1001"); getServletConfig().getServletContext().getRequestDispatcher("/error.jsp").forward(request,response); else if ((ticket = ticketDelegate.getTicket(ticketID)) == null) request.setAttribute("error","1002");

185

getServletConfig().getServletContext().getRequestDispatcher("/error.jsp").forward(request,response); String password = request.getParameter("password"); AESCipher aes = new AESCipher(password); UserEJBVO details = usersession.getUserDetails(aes.getWrappedKey()); String fullname = details.getFullname(); String card = details.getCard(); String cc_num = details.getCc_number(); String cvccvv_code = details.getCvccvv_code(); String cc_expiration_date = details.getCc_expiration_date(); String email = details.getEmail(); String bank = details.getBank(); String bank_number = details.getBank_number(); Integer charging_type = ticket.getChargettype(); Float ammount = ticket.getAmmount(); %> <body bgcolor="#ffffff"> <table width="300" border="0" cellpadding="0" cellspacing="0"> <form action="/clearence/newTransaction" method="post"> <input type="hidden" name="ticketid" value=<%=ticketID%>/> <tr> <td>Fullname</td> <td><input name="fullname" type="text" value="<%=fullname%>"/></td> </tr> <tr> <td>email</td> <td><input name="email" type="text" value="<%=email%>"/></td> </tr> <tr><td colspan="2"> <% if (charging_type.intValue() == 1) %> <div title="Bank account transfer"> <tr> <td>Bank name</td> <td><input name="bank" type="text" value="<%=bank%>"/></td> </tr> <tr> <td>Bank account</td> <td> <% if (bank_number.length() > 5) out.print(bank_number.substring(0,bank_number.length() - 5) + "*****"); else %><input name="bank_number" type="text" value=""/><%

186

%> </td> </tr> </div> <% else %> <div title="Credit card charge"> <tr> <td>Credit card</td> <td><input name="CCName" type="text" value="<%=card%>"/></td> </tr> <tr> <td>CC Number</td> <td> <% if (cc_num.length() > 5) out.print(cc_num.substring(0,cc_num.length() - 5) + "*****"); else %><input name="CCNumber" type="text" value="<%=cc_num%>"/><% %> </td> </tr> <tr> <td>Exp. Date</td> <td><input name="cc_exp_date" type="text" value="<%=cc_expiration_date%>"/> </td> </tr> <tr> <td>CVC/CVV</td> <td><input name="CVCCode" type="text" value="<%=cvccvv_code%>"/></td> </tr> </div> <% %> </td></tr> <tr><td>Amount</td><td><b><%=ammount%></b></td></tr> <tr><td colspan="2" align="right"><input type="submit" name="Submit" value="Submit"/></td></tr> <tr><td><INPUT TYPE="reset" VALUE="Reset"></td> </tr> </form> </table> </body> </html>

187

result.jsp <%@ page import="nettechn.BankClearence.Transactions.TransactionEJBVO, nettechn.BankClearence.Transactions.TransactionDelegate, java.util.ResourceBundle, nettechn.BankClearence.Transactions.Transaction"%><?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <%@ page contentType="application/xhtml+xml; charset=utf-8" session="true" language="java" %> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Net Technologies</title> <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=utf-8" /> </head> <body> <table cellpadding="0" cellspacing="0" border="0"> <tr> <% String trnsID = null; try trnsID = request.getParameter("trnsid"); catch (NumberFormatException ex) catch (NullPointerException ex) if (trnsID == null) getServletConfig().getServletContext().getRequestDispatcher("/error.jsp").forward(request,response); TransactionEJBVO to = TransactionDelegate.getTransactionDetails(trnsID); ResourceBundle rb = ResourceBundle.getBundle("nettechn.clearence.resources.messages"); int trnsStatus = to.getStatus().intValue(); if (trnsStatus == Transaction.ExecutionStarted) %><td><%="The Status is executionStarted"%></td><% else if (trnsStatus == Transaction.APPROVED) %><td><%=rb.getString("1001").replaceAll("%aaa%",trnsID)%></td><% else if (trnsStatus == Transaction.REJECTED) %><td><%=rb.getString("1002").replaceAll("%aaa%",trnsID)%></td><% else if (trnsStatus == Transaction.FAILED) %><td><%=rb.getString("1003").replaceAll("%aaa%",trnsID)%></td><% else if (trnsStatus == Transaction.WAITINGFROAPROVAL) %><td><%=rb.getString("1004").replaceAll("%aaa%",trnsID)%></td><% else if (trnsStatus == Transaction.SERVERANREACHABLE) %><td><%=rb.getString("1005").replaceAll("%aaa%",trnsID)%></td><% %> </tr> </table> </body> </html>

188

EJBLocator.java package nettechn.ServiceLocator.ejb; import nettechn.ServiceLocator.ServiceLocator; import nettechn.ServiceLocator.exceptions.ServiceLocatorException; import javax.ejb.EJBLocalHome; import javax.ejb.EJBHome; import javax.naming.NamingException; import javax.naming.InitialContext; import javax.rmi.PortableRemoteObject; import java.util.Map; import java.util.Collections; import java.util.HashMap; /** * Created by IntelliJ IDEA. * User: skentros * Date: 9 Αυγ 2004 * Time: 11:23:14 πμ * To change this template use File | Settings | File Templates. */ public class EJBLocator private InitialContext initialContext; private Map cache; private static EJBLocator ourInstance; static try ourInstance = new EJBLocator(); catch (ServiceLocatorException se) System.err.println(se); se.printStackTrace(); private EJBLocator() throws ServiceLocatorException try initialContext = new InitialContext(); cache = Collections.synchronizedMap(new HashMap()); catch (NamingException nex) throw new ServiceLocatorException(nex); catch (Exception ex) throw new ServiceLocatorException(ex); public static EJBLocator getEJBInstance() return ourInstance; //private EJBLocator() // super(); // //public static EJBLocator getEJBInstance() // return (EJBLocator) getInstance(); //

189

public EJBLocalHome getLocalHome(String jndiHomeName) throws ServiceLocatorException EJBLocalHome localhome = null; try if (cache.containsKey(jndiHomeName)) localhome = (EJBLocalHome) cache.get(jndiHomeName); else localhome = (EJBLocalHome) initialContext.lookup(jndiHomeName); cache.put(jndiHomeName, localhome); catch (NamingException nex) throw new ServiceLocatorException(nex); catch (Exception ex) throw new ServiceLocatorException(ex); return localhome; public EJBHome getRemoteHome(String jndiHomeName, Class homeClassName) throws ServiceLocatorException EJBHome remoteHome = null; try if (cache.containsKey(jndiHomeName)) remoteHome = (EJBHome) cache.get(jndiHomeName); else System.out.print("Here we are:"); System.out.println(jndiHomeName); Object objref = initialContext.lookup(jndiHomeName); System.out.println("Hello2"); Object obj = PortableRemoteObject.narrow(objref, homeClassName); System.out.println("Hello3"); remoteHome = (EJBHome) obj; cache.put(jndiHomeName, remoteHome); catch (NamingException nex) throw new ServiceLocatorException(nex); catch (Exception ex) throw new ServiceLocatorException(ex); return remoteHome; ServiceLocatorException.java package nettechn.ServiceLocator.exceptions; /** * Created by IntelliJ IDEA. * User: skentros * Date: 9 Αυγ 2004

190

* Time: 11:31:39 πμ * To change this template use File | Settings | File Templates. */ public class ServiceLocatorException extends Exception public ServiceLocatorException(Throwable t) super(t); public String getMessage() return super.getMessage(); userAgent.java package nettechn.utilities.http; /** * Created by IntelliJ IDEA. * User: skentros * Date: 10 Αυγ 2004 * Time: 11:38:24 πμ * To change this template use File | Settings | File Templates. */ public class userAgent public final static String C_HTML = "html"; public final static String C_xHTML = "xhtml"; /** * This function, checks UserAgentHeader and AcceptTypesHeader and returns the style that should * be used in the pages. * * @param UserAgentHeader the user agent header, coming with HTTP request (request.getHeader("User-Agent")) * @param AcceptTypesHeader the accept type header, coming with HTTP request (request.getHeader("Accept")) * @return the style should be used C_HTML, C_WML, ... */ public static String getStyle(String UserAgentHeader, String AcceptTypesHeader) String style = new String(""); if (AcceptTypesHeader == null) AcceptTypesHeader = new String("*/*"); if (AcceptTypesHeader.indexOf("html") > -1) style = C_HTML; //=========net technologies=========== //user agent search if (UserAgentHeader.indexOf("Mozilla") > -1) style = C_HTML; if (UserAgentHeader.indexOf("XHTML") > -1) style = C_xHTML;

191

return style; encoder.java package nettechn.utilities; import java.security.NoSuchAlgorithmException; /** * Created by IntelliJ IDEA. * User: skentros * Date: 22 Ιουλ 2004 * Time: 4:12:23 μμ * To change this template use File | Settings | File Templates. */ public class encoder /** * This function uses an one way encryption algorith to encode * a given String. * * @param x String to be encoded * @return The encoded String */ public static String OneWayEncrypt(String x) java.security.MessageDigest d = null; try d = java.security.MessageDigest.getInstance("SHA-1"); catch (NoSuchAlgorithmException ex) ex.printStackTrace(); return x; d.reset(); d.update(x.getBytes()); sun.misc.BASE64Encoder encoder = new sun.misc.BASE64Encoder(); return encoder.encode(d.digest()); AESCipher.java package nettechn.utilities; /** * Created by IntelliJ IDEA. * User: skentros * Date: 9 Αυγ 2004 * Time: 12:43:01 μμ * To change this template use File | Settings | File Templates. */ import sun.misc.BASE64Decoder; import sun.misc.BASE64Encoder; import java.security.*; import javax.crypto.*;

192

import javax.crypto.spec.*; public class AESCipher final int ENCRYPT_MODE = 1; final int DECRYPT_MODE = 2; private final byte[] salt = "Warfare is based on deception".getBytes(); private final byte[] wrapKeyMaterial = " The art of war is of vital importance to the State.".getBytes(); private MessageDigest md5; private SecretKeySpec secretKey; private SecretKeySpec wrapKey; public AESCipher() throws EncryptionException try md5 = MessageDigest.getInstance("MD5"); catch (Exception e) throw new EncryptionException(e); secretKey = null; public AESCipher(char[] password) throws EncryptionException try md5 = MessageDigest.getInstance("MD5"); String pass = new String(password); md5.update(pass.getBytes()); byte[] keyMaterial = md5.digest(salt); secretKey = new SecretKeySpec(keyMaterial, "AES"); pass = null; for (int i = 0; i < password.length; i++) password[i] = 0; catch (Exception e) throw new EncryptionException(e); public AESCipher(byte[] password) throws EncryptionException try md5 = MessageDigest.getInstance("MD5"); md5.update(password); byte[] keyMaterial = md5.digest(salt); secretKey = new SecretKeySpec(keyMaterial, "AES"); for (int i = 0; i < password.length; i++) password[i] = 0; catch (Exception e) throw new EncryptionException(e); public AESCipher(String pass) throws EncryptionException try md5 = MessageDigest.getInstance("MD5");

193

md5.update(pass.getBytes()); byte[] keyMaterial = md5.digest(salt); secretKey = new SecretKeySpec(keyMaterial, "AES"); pass = null; catch (Exception e) throw new EncryptionException(e); public void init(char[] password) String pass = new String(password); md5.update(pass.getBytes()); byte[] keyMaterial = md5.digest(salt); secretKey = new SecretKeySpec(keyMaterial, "AES"); pass = null; for (int i = 0; i < password.length; i++) password[i] = 0; public void init(byte[] password) md5.update(password); byte[] keyMaterial = md5.digest(salt); secretKey = new SecretKeySpec(keyMaterial, "AES"); for (int i = 0; i < password.length; i++) password[i] = 0; public void init(String pass) md5.update(pass.getBytes()); byte[] keyMaterial = md5.digest(salt); secretKey = new SecretKeySpec(keyMaterial, "AES"); pass = null; public byte[] getWrappedKey() throws EncryptionException Cipher cipher; if (secretKey != null) try cipher = Cipher.getInstance("AES"); byte[] keyMaterial = md5.digest(wrapKeyMaterial); wrapKey = new SecretKeySpec(keyMaterial,"AES"); cipher.init(Cipher.WRAP_MODE, wrapKey); return cipher.wrap(secretKey); catch (Exception e) throw new EncryptionException(e); else throw new IllegalArgumentException("Error: Secret Key is null!"); public void setWithWrappedKey(byte[] wrappedKey) throws EncryptionException Cipher cipher; try

194

cipher = Cipher.getInstance("AES"); byte[] keyMaterial = md5.digest(wrapKeyMaterial); wrapKey = new SecretKeySpec(keyMaterial,"AES"); cipher.init(Cipher.UNWRAP_MODE, wrapKey); secretKey = (SecretKeySpec) cipher.unwrap(wrappedKey, "AES", Cipher.SECRET_KEY); catch (Exception e) throw new EncryptionException(e); public String encrypt(String clearString) throws EncryptionException Cipher cipher; String cipherString; byte[] ciphertext; if (secretKey != null) if (clearString.length() > 0) try cipher = Cipher.getInstance("AES"); cipher.init(Cipher.ENCRYPT_MODE, secretKey); ciphertext = cipher.doFinal(clearString.getBytes()); BASE64Encoder base64encoder = new BASE64Encoder(); cipherString = base64encoder.encodeBuffer(ciphertext); return cipherString; catch (Exception e) throw new EncryptionException(e); else return ""; else throw new IllegalArgumentException("Error: Secret Key is null!"); public String decrypt(String cipherString) throws EncryptionException Cipher cipher; String clearString; byte[] cleartext; if (secretKey != null) if ( (cipherString != null) && (cipherString.length() > 0)) try cipher = Cipher.getInstance("AES"); cipher.init(Cipher.DECRYPT_MODE, secretKey); BASE64Decoder base64decoder = new BASE64Decoder(); byte[] ciphertext = base64decoder.decodeBuffer(cipherString); cleartext = cipher.doFinal(ciphertext); clearString = new String(cleartext); return clearString; catch (Exception e) throw new EncryptionException(e); else

195

return ""; else throw new IllegalArgumentException("Error: Secret Key is null!"); public void clear() secretKey = null; public static class EncryptionException extends Exception public EncryptionException(Throwable t) super(t);