Ασφάλιση ζεύγους client - web service έναντι data tampering;

[parsifal]

Καλησπέρα παιδιά. Θεωρητική απορία (προς το παρόν):

 

Έστω ζεύγος client - web service. Ο client ας πούμε ότι είναι ένα desktop application που τρέχει σε ένα μηχάνημα και παράγει ένα μικρού μεγέθους dataset το οποίο πρέπει να σταλεί στο web service. Το web service είναι ένα απλό RESTful web API που περιμένει να συλλέξει τα datasets που παράγουν οι απανταχού clients.

 

Τα δεδομένα δεν περιέχουν οποιουδήποτε είδους προσωπικά ή άλλα ευαίσθητα στοιχεία, οπότε δεν υπάρχει λόγος εξασφάλισης έναντι πιθανής υποκλοπής. Υπάρχει όμως το εξής πρόβλημα ταυτοποίησης: Αν ο πηγαίος κώδικας του client δοθεί στο ευρύ κοινό, υπάρχουν τρόποι να εξασφαλίσουμε ότι το web service δε θα κάνει δεκτά «πειραγμένα» datasets που πιθανόν να προέρχονται από τροποποιημένες εκδοχές του client ή ακόμη και από κάποιο software παραγωγής custom HTTP requests (π.χ. curl, Tamper Data addon του Firefox κλπ.);

 

Ευχαριστώ!

[orotoi]

Δίνοντας τον κώδικα του client (και οχι και του server/web service) δεν γνωρίζει τι κάνεις μα τα δεδομένα που δέχεσαι [τα οποία προφανώς τα φιλτράρεις και τα ελέγχεις ώστε να είναι τα αναμενόμενα].

[PCharon]

- Πώς θα αποφύγεις αυτούς που δε γνωρίζουν προγραμματισμό ή αυτούς που γνωρίζουν αλλά βαριούνται και θα αρκεστούν και οι δύο στο να προσπαθήσουν να πειράξουν το πακετάκι με ενδιάμεσο «lamer» πρόγραμμα: υπογράφεις ψηφιακά το πακέτο με κάποιο hash.

 

- Πώς θα αποφύγεις αυτούς που γνωρίζουν προγραμματισμό και μπορούν να επέμβουν στον ανοικτό κώδικα και να φτιάξουν πειραγμένο client: εδώ δε ξέρω τί να σου πω ακριβώς. Ίσως αν γνωρίζαμε τί ΑΚΡΙΒΩΣ φάση θέλεις να αποφύγεις να εφευρίσκαμε κάποια ιδέα. Δε ξέρω δηλαδή τί ακριβώς φοβάσαι πως θα μπορεί να κάνει ο άλλος τροποποιώντας το πακετάκι.

 

- Πώς θα αποφύγεις αυτούς που δε γνωρίζουν μόνο προγραμματισμό, αλλά και τεχνικές αντίστροφης μηχανικής και είναι «για δέσιμο»: αυτούς δε μπορείς να τους αποφύγεις όσο έχουν τον client να τρέχει σε δικό τους μηχάνημα. Αν ήταν όλα cloud και ο client φορτωνόταν στη μνήμη ενός «μονωμένου» λειτουργικού/hardware, τότε ναι θα απέφευγες και αυτούς. Δε λεω κάτι καινούργιο, το αναφέρω για λόγους πληρότητας του post...

 

 

Μια σημείωση στο τέλος. Σε περίπτωση που το όποιο πείραγμα θέλεις να αποφύγεις θα απαιτεί ΣΙΓΟΥΡΑ επεξεργασία του data με το χέρι πριν αποσταλεί το πειραγμένο πακέτο/request, άσχετα αν το πείραγμα γίνεται με τρίτο προγραμματάκι ή πειραγμένο client, μπορείς να εκμεταλλευτείς το γεγονός πως ο άνθρωπος καθυστερεί και να βάλεις timeout αποδοχής του data από τη πλευρά του server. Ούτε καν μήνυμα του τί συνέβη και δε δέχτηκε το data δε θα στέλνεις στον client, θα τον κάνεις να ψάχνεται κάθε φορά που περιμένει να γράψει στο όποιο ενδιάμεσο παραθυράκι.

 

Αν είχαμε πολύ πιο συγκεκριμένο το θέμα, δηλαδή τί ΑΚΡΙΒΩΣ θέλεις να αποφύγεις στη συγκεκριμένη υλοποίηση, ίσως εφευρίσκαμε λύσεις που δε μπορούμε να μαντέψουμε τώρα στο θεωρητικό.

[παπι]

Σε γενικες γραμμες συμφωνω με τον πανω.

 

Σε τι target group θα πας;

[_tasos]

Ένα απλό σύστημα authentication (token based) δεν θα έλυνε το πρόβλημα σου; Από ότι καταλαβαίνω, αναγνωρίζεις τον client και δέχεσαι το request, ενώ ίσως ήταν καλύτερα να αναγνωρίζεις τον user.

[parsifal]

Αν είχαμε πολύ πιο συγκεκριμένο το θέμα, δηλαδή τί ΑΚΡΙΒΩΣ θέλεις να αποφύγεις στη συγκεκριμένη υλοποίηση, ίσως εφευρίσκαμε λύσεις που δε μπορούμε να μαντέψουμε τώρα στο θεωρητικό.

Έχεις δίκιο. Ας δώσω ένα παράδειγμα:

 

Client --> benchmarking software που καλεί ένα εξωτερικό εκτελέσιμο για την εξαγωγή του benchmark result και επίσης ανιχνεύει τύπο+χρονισμό της CPU. Αυτά τα δεδομένα θέλει να τα στείλει στο web service (σε κάποια απλή μορφή, π.χ. JSON)

 

Web service --> Ένα PHP script που θα πρέπει να συλλέξει τα benchmark results και να τα καταχωρήσει σε μία Β.Δ.

 

Το πρόβλημα σε αυτήν την περίπτωση είναι προφανές νομίζω: οι επίδοξοι cheaters.

[παπι]

Αν το εχεις open source τοτε δεν μπορεις να κανεις τιποτα.

[PCharon]

Μια λύση είναι να μπορεί να τρέξει το benchmark σε φάση "offline", για λογαριασμό του χρήστη ή σε φάση "online", οπότε θα υπάρχει και internet για να ανεβάσει το αποτέλεσμα. Στο online mode πριν ξεκινήσει θα λαμβάνει ακριβώς πριν ξεκινήσει ένα μοναδικό ID από το server που επί τόπου αποθηκεύει το ID και την ώρα που το έδωσε. Όταν τελειώνει θα στέλνει αμέσως το αποτέλεσμα μαζί με το ID, οπότε ο server γνωρίζει πια όχι μόνο κάποιο/α σκορ και χρόνο/ους των τεστ, αλλά και το χρόνο που διήρκεσε η «συναλλαγή». Μπορείς να προσθέσεις και την αυτόματη καταγραφή ενός ping, άμα είσαι τρελός. Ειδικά αν το benchmark είναι χρονοβόρο κι όχι ελάχιστων δευτερολέπτων (εξάλλου πρέπει να είναι χρονοβόρο, προτείνεται), είναι μια χαρά μέτρο και με μια εύκολη λογική θα μπορείς να πετάς έξω αυτόματα αποτελέσματα με κάποιες αποκλίσεις.

 

[edit] Αργότερα που το ξανασκέφτηκα αυτό είναι ένα μέτρο που πετυχαίνει αν στο benchmark εκτελείς συγκεκριμένο αριθμό κύκλων και μετράς χρόνο. Αν έχεις σταθερό το χρόνο και μετράς κύκλους δε πιάνει το μέτρο. Πάντως ακόμα κι αν θέλεις να το κάνεις με το δεύτερο τρόπο, μπορείς να εκτελείς σύντομα ένα μικρό benchmark με τον 1ο τρόπο ώστε πάλι, με απλά Μαθηματικά, μπορείς να τεκμηριώνεις την αλήθεια του αποτελέσματος.

[defacer]

Μια λύση είναι να μπορεί να τρέξει το benchmark σε φάση "offline", για λογαριασμό του χρήστη ή σε φάση "online", οπότε θα υπάρχει και internet για να ανεβάσει το αποτέλεσμα. Στο online mode πριν ξεκινήσει θα λαμβάνει ακριβώς πριν ξεκινήσει ένα μοναδικό ID από το server που επί τόπου αποθηκεύει το ID και την ώρα που το έδωσε. Όταν τελειώνει θα στέλνει αμέσως το αποτέλεσμα μαζί με το ID, οπότε ο server γνωρίζει πια όχι μόνο κάποιο/α σκορ και χρόνο/ους των τεστ, αλλά και το χρόνο που διήρκεσε η «συναλλαγή».

 

Αυτό βέβαια δε λύνει το πρόβλημα του να γράψει κάποιος έναν "client" ο οποίος μιλάει κανονικά με τον server αλλά αντί για benchmark απλά πετάει χαρταετό για Χ χρονικό διάστημα και μετά λέει "ok done".

[PCharon]

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

 

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

 

Ίσως η μόνη λύση στο θέμα είναι το ξεσκαρτάρισμα των ανεβασμένων αποτελεσμάτων στη database πια, αφού μαζευτούν αρκετά δείγματα. Αποτελέσματα που για τα ίδια χαρακτηριστικά hardware έχουν μεγάλη απόκλιση τα πετάς έξω.

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

[defacer]

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

 

Γενικά εφόσον συζητάμε το ενδεχόμενο να έχει ο άλλος source στα χέρια του δεν έχει κανένα νόημα κάτι τέτοιο.

 

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

 

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

 

Μια άλλη προσέγγισης που μπορεί να δουλέψει έχει να κάνει με το εξής: τι ακριβώς υπολογισμούς κάνει το πρόγραμμα; Υπάρχει περίπτωση οι υπολογισμοί να παράγουν κάποιο αποτέλεσμα το οποίο να βασίζεται σε κάποιο initial seed και να είναι επαληθεύσιμο;

 

Αν ναι, τότε μπορεί να γίνει ένα "online mode" όπως είπες όπου ο server δίνει στον client ένα nonce για να πραγματοποιηθούν οι υπολογισμοί. Από τη στιγμή που ο client δεν ξέρει το συγκεκριμένο nonce απο πριν, και το αποτέλεσμα των υπολογισμών μπορεί να επαληθευτεί εκ των υστέρων server-side, έχουμε κόψει όλες τις πιθανότητες κλεψίματος (μπορείς να "κλέψεις" καθυστερώντας να δώσεις την απάντηση, αλλά αυτό δε σε συμφέρει).

[PCharon]

Αυτό με το initial seed που λες φαίνεται να έχει ένα νόημα, αλλά ακόμα κι εκεί μπορεί να παίξει catch. Πχ αυτός που έχει τον κώδικα... βελτιστοποιεί τον αλγόριθμο υπολογισμού και υπολογίζει γρηγορότερα το αποτέλεσμα!

 

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

 

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

 

 

 

Υ.Γ. Τελικά ο ανοιχτός κώδικας δεν είναι πανάκεια, ε; (το έχω ξαναγράψει κάπου... )

 

[defacer]

Αυτό με το initial seed που λες φαίνεται να έχει ένα νόημα, αλλά ακόμα κι εκεί μπορεί να παίξει catch. Πχ αυτός που έχει τον κώδικα... βελτιστοποιεί τον αλγόριθμο υπολογισμού και υπολογίζει γρηγορότερα το αποτέλεσμα!

 

Η όλη ιδέα είναι το αποτέλεσμα να μη μπορεί να υπολογιστεί γρηγορότερα ακριβώς όπως γίνεται όταν π.χ. κάποιο πρόγραμμα περνάει το password που έδωσες από ένα sha1 loop 1M φορές προκειμένου να κάνει τη dictionary attack δυσκολότερη. Κάποια πράγματα όπως το sha1 δεν μπορούν να βελτιστοποιηθούν σε software -- ή τουλάχιστον αν κάποιος το κάνει θα πρόκειται για σημαντική εξέλιξη στα μαθηματικά.

 

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

 

Το ζητούμενο είναι να μη μπορεί να τροποποιήσει τον κώδικα με τέτοιο τρόπο που να επιτρέπει "κλέψιμο", γιατί τον εκτελέσιμο κώδικα πάντα μπορεί κανείς να τον τροποποιήσει (ή να τον αντικαταστήσει) ακόμα κι αν δε δίνεις source. Φαντάσου τι θα γινόταν αν μπορούσε κανείς με μια "τοπική" αλλαγή να κλέψει π.χ. στο WoW ή σε κάποιο fps.

 

Υ.Γ. Τελικά ο ανοιχτός κώδικας δεν είναι πανάκεια, ε; (το έχω ξαναγράψει κάπου... )

 

Κακή σύνδεση κατά την άποψή μου.

 

Το πρόβλημα αυτό δεν έχει να κάνει με ανοιχτό ή κλειστό κώδικα. Ακόμα και στην υποθετική περίπτωση που με κάποιο μαγικό τρόπο δε θα μπορούσε κανείς να πειράξει το εκτελέσιμο του parsifal, και ούτε θα είχε source στα χέρια του, και πάλι θα μπορούσε να κλέψει πολύ απλά κάνοντας reverse engineer το πρωτόκολλο επικοινωνίας client/server (κάτι που στη συγκεκριμένη περίπτωση θα ήταν παραπάνω από γελοίο καθώς μιλάμε για REST) και γράφοντας ένα δικό του πρόγραμμα που απλά θα έστελνε ψευδή δεδομένα στον server.

[PCharon]

1) Βελτιστοποίηση εννοώ φυσικά optimize επί του κώδικα, όχι επί του τρόπου υπολογισμού! Έστω κι ελάχιστο φτάνει, ειδικά σε πολλούς κύκλους εκτέλεσης, ένα κλικ θα τον βάλει πάνω από κάποιους άλλους. Κι αυτό γίνεται πάρα πολύ εύκολα.

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

 

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

 

3) Σχετικά με τη δυνατότητα αντίστροφης μηχανικής, το έγραψα κι εγώ αμέσως στο #3 (τρίτη παύλα). Όμως δεν αποτελεί επιχείρημα αποτρεπτικό για να κλείσεις τον κώδικα ο όποιος insane θεωρητικός τρόπος τροποποίησής του, θα τον θεωρήσουμε μη πρακτικό και δε θα μας απασχολήσει. Αν αρχίσουν να μας απασχολούν και αυτά σε κάθε εφαρμογή κλειστού κώδικα, θα πρέπει να παραδώσουμε τα όπλα γενικώς επειδή κάποιος-κάπου μπορεί να το αλλάξει με τη τρέλα του.

 

4) Δεν αποτελεί αρχή η σύνδεση, αλλά ούτε είναι κακή, αντιθέτως πχ στη προκειμένη περίπτωση εφαρμογής είναι απολύτως ρεαλιστική σκέψη (για το επιχείρημα «και κλειστός, πάλι μπορεί να τροποποιηθεί» βλέπε πάλι το 3).

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

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

 

[edit] Έγινε επιδιόρθωση κι εξομάλυνση του post.

[firewalker]

Αν τον TS δεν τον ενδιαφέρει να λειτουργεί το όλο θέμα με κώδικα που έχει κάνει compile ο χρήστης (συνήθως μας χρειάζεται για Linux εφαρμογές. Μπορεί όμως να μοιράζει static εκτελέσιμα) αλλά μόνο από το δικό του pre-compiled πρόγραμμα θα μπορούσε να εφαρμοστεί κάποια ασύμμετρη κρυπτογράφηση στο αρχείο. Το public key στον client να είναι user defined πριν το compile. Έτσι, και μόνο αρχεία που προέρχονται από το "original" compiled πρόγραμμα θα γίνονται δεκτά (αφού εκεί θα είναι το σωστό key), και ο κώδικας θα είναι ανοικτός. Βέβαια από reverse engineering κ.τ.λ. δεν σε προστατεύει. Απλά από την μεγάλη πλειοψηφία των χρηστών σε εξασφαλίζει.