Υπάρχει τρόπος να έχω asymmetric χωρίς να μπλέξω με πιστοποιητικά; Κάποιος open source αλγόριθμος ίσως;

---

Χρήστος Γεωργακόπουλος

Αν έχω καταλάβει σωστά (δεν έχω ασχοληθεί με encryption, τώρα διάβασα λίγα), δεν χρειάζονται certificates για να κάνεις assymetric encryption.  Το μόνο που χρειάζεσαι είναι ένα set από keys (public & private) τα οποία μπορείς να κάνεις generate μόνος σου.

Μπορείς να βρεις ένα πολύ καλό άρθρο για το πως να κάνεις encryption στο .NET (μεταξύ άλλων και asymmetric), εδώ.

Αν ψάχνεις για κάτι σε open source, δες αυτό.

---

Patrick

Αει γειά σου.... τα παραδείγματα του wse παίζουν όλα απ' ότι είδα με certificates και stores και δεν συμμαζεύεται... και το google φέρνει ένα σκασμό από άσχετα πράγματα (ή μου ερχόντουσαν άσχετα terms στο μυαλό).... anyway thanx.

---

Χρήστος Γεωργακόπουλος

Ακόμη, μπορείς να δεις το Cryptography Application Block και να κάνεις τη ζωή σου λίγο πιο εύκολη. To έχω χρησιμοποιήσει για αποθήκευση passwords με asymmetric encryption και όλα πάνε ρολόι...

---

Vir prudens non contra ventum mingit

Οι προλαλήσαντες έχουν δίκιο, δεν χρειάζονται certificates για να χρησιμοποιήσεις asymmetric encryption. Αλλά και οι αλγόριθμοι των certificates είναι πρότυπα, οπότε δεν τίθεται θέμα open-closed source. Αρκεί να έχεις το public key κάποιου για να μπορέσεις να του στείλεις ένα κρυπτογραφημένο μήνυμα. 

  Τώρα θα μου πεις, "και πού θα βρω εγώ το public key του άλλου?" ή "και που ξέρω εγώ ότι αυτό το public key είναι πράγματι του Α και όχι του Β?" Αυτά είνα τα θέματα που αντιμετωπίζουν τα certificates. Το certificate σου δείνει το public key κάποιου μαζί με την εγγύηση ότι το public key προέρχεται από αυτόν που λέει ότι προέρχεται. Αυτό το πετυχαίνει επειδή περιέχει την πληροφορία του ιδιοκτήτη του, προστατευμένη με την ψηφιακή υπογραφή της εταιρείας που το έκδωσε. Η αξία του πιστοποιητικού είναι ανάλογη της εμπιστοσύνης που έχεις στην εταιρεία που το εξέδωσε.
  Υπάρχουν διάφορες κατηγορίες πιστοποιητικών. Τα πιο απλά (και φθηνά) περιέχουν απλά το email του ιδιοκτήτη τους και εκδίδονται πολύ εύκολα. Τα πιο ακριβά απαιτούν να πας εσύ ο ίδιος στην εταιρεία που τα εκδίδει, με ταυτότητες και χαρτία, ή άλλη περίπλοκη διαδικασία, πιστοποιούν όμως ότι οτιδήποτε υπογράφεις ή κρυπτογραφείς προέρχεται από εσένα τον ίδιο. Μπορείς βέβαια και εσύ να δημιουργήσεις πιστοποιητικά με κάποια προγράμματα (π.χ. το cert.exe) ή τα Certificate Services των Windows, τα οποία όμως δεν θα έχουν καμμία αξία για άλλους ή έξω από το windows domain σου.

  Και εδώ είναι και ο λόγος που δεν υπάρχουν "open source" certificates, και που τα web services και το SSL χρησιμοποιούν certificates. Ο μόνος τρόπος να βεβαιωθεί κάποιος client ότι συνδέθηκε με εσένα και όχι με κάποιο πειρατικό site είναι να ελέγξει το πιστοποιητικό σου. Αυτό θα το κάνει ελέγχοντας αν έχει υπογραφεί από μια εταιρεία ή αρχή που εμπιστεύεται. Περιττό να πω ότι κάποιος εμπιστεύεται την Verisign πολύ περισσότερο από την EimaiOMitsosStoXorioPistepsteMe.

Πληροφοριακά, η λίστα με τις εταιρείες που εμπιστεύονται τα windows βρίσκεται στα Properties του Internet Explorer, στο tab Content (!), πατώντας το κουμπί publishers. Μπορείς να προσθέσεις trusted publishers και εσύ ο ίδιος αν θες, αλλά θα πρέπει να προσέχεις ποιόν βάζεις μέσα.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

τα πακέτα μου έχουν usernameToken και ξέρω από ποιον είναι, απλά ήθελα asymmetric για να στέλνω τα κλειδιά του symmetric χωρίς να μπλέξω με αγορές certificates και με stores και με trusts... Ίσως επειδή δεν τα ξέρω και εγώ πολύ καλά ακόμα... ίσως όταν τελιώσω με την υλοποίηση που έχω ξεκινήσει να μου είναι πιο οικεία και να παίξω και με certificates.

---

Χρήστος Γεωργακόπουλος

Το οποίο σημαίνει ότι έχεις κάνει ήδη trust τον άλλο?

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

Το .NET περιέχει την κλάση RSACryptoServiceProvider για ασύμμετρη κρυπτογράφηση. Δεν χρειάζεται certificates, της δίνεις το public key σε κάποια μορφή και μετά καλείς την μέθοδο Encrypt για να πάρεις το κρυπτογραφημένο μύνημα. Το help της μεθόδου περιέχει και sample για τη χρήση της. Δες επίσης και το κεφάλαιο για την κρυπτογράφιση στο MSDN. Δες επίσης και το άρθρο RSA in VB.Net στο DevX για μια περιγραφή της διαδικασίας και άλλο ένα sample. Στο google θα πρέπει να ψάξεις για την RSACryptoServiceProvider.Encrypt.

Τέλος, μην βιαστείς να χρησιμοποιήσεις το απλούστερο sample που θα βρεις, ή αρχικά κλειδιά ή message block με απλές τιμές (π.χ. όλα τα bytes 0).

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Το σκεπτικό είναι το εξής:
1. Ο χρήστης δίνει username και password στον client
2. O client αν δεν έχει το ήδη, ζητάει από τον server να του στείλει το δημόσιο κλειδί του
3. Σε κάθε request που γίνεται, αποστέλλονται το username και το password κωδικοποιημένα με το δημόσιο κλειδί του server.
4. Ο server αποκρυπτογραφεί το username και το password με το ιδιωτικό κλειδί του, τα ελέγχει ότι είναι valid και τότε απαντάει στο request.

Έτσι πετυχαίνω τα εξής:
1. Δεν ταξιδεύουν τα passwords ελεύθερα μέσα στο καλώδιο.
2. Δεν έχω hardcoded κλειδιά (πχ για symmetric δουλιές) μέσα στον client (ο client μοιράζεται ελεύθερα στο internet και το reflector είναι πολύ γνωστό...)

Προβλήματα που παραμένουν:
Σαφώς και μπορεί κάποιος να τσιμπίσει το encrypted token από το καλώδιο και να μου το στέλνει σε δικά του requests προσποιούμενος ότι είναι κανονικός πελάτης.
Μία λύση που έχω δεί σε παρόμοια προβλήματα είναι να μπαίνει expiration στα κλειδιά, το οποίο ναι μεν δυσκολεύει τα πράγματα για τον κακό, αλλά με βάζει σε άλλους μπελάδες.

Καμιά ιδέα; υπάρχει κάτι που έχω πιάσει στραβά;

(Πι ες: ο administrator ας βάλει το FTB να αφήνει html editing (αν αφήνει και ο community server) γιατί τα κουμπάκια πάνω κάνουν τα δικά τους)

---

Χρήστος Γεωργακόπουλος

Ιδέα !
Ο Client να ρίχνει μέσα στο username token και το IP του, ή αν είναι πίσω από proxy, το IP του proxy. Ο server όταν ανοίγει το πακέτο μπορεί να συγκρίνει το IP που έχει μέσα στο πακέτο με το IP από το οποίο προήλθε το request.

Μένει η περίπτωση του IP spoofing, το οποίο μάλλον είναι πολύ extreme για να το καλύψω.

Ο client όμως μπορεί να βρεί το IP που χρησιμοποιεί ο proxy εξωτερικά; δύσκολα πράγματα... μου χαλάει τη δουλιά ο proxy....

---

Χρήστος Γεωργακόπουλος

Ρίξε μια ματιά στο παράδειγμα του TaskVision και συγκεκριμένα στο Web Service Security. Υλοποιεί την τεχνική των tickets που γίνονται expire. Συγκεκριμένα, επειδή η λύση βασίζεται σε web services, κάθε χρήστης μόλις γίνει authenticated αποκτά ένα ticket το οποίο το περνάει μαζί με τις απαραίτητες παραμέτρους σε κάθε κλήση web method. Το ticket γίνεται expire βάσει κάποιου policy οπότε στην περίπτωση που ξαναγίνει κλήση του WS με ληγμένο ticket, ξαναγίνεται silent authenticate ο χρήσης με τα credencials που ήδη έχει και παράγεται νέο ticket. Δηλαδή το username/password ταξιδεύει μόνο μία φορά πάνω στο δίκτυο (οπότε μπορείς να το προστατέψεις με HTTPS/IPsec αν ανησυχείς τόσο πολύ για sniffers) και κατόπιν με το συγκεκριμένο set username/password δημιουργούνται tockens τα οποία δεν χρειάζονται προστασία γιατί έτσι κι αλλιώς γίνονται πολύ γρήγορα expire.

Δεν ξέρω πως ακριβώς υλοποιείς την client/server αρχιτεκτονική στο project σου, αλλά μπορείς να πάρεις αρκετές ιδέες από το παραπάνω παράδειγμα.

Γενικά πάντως (και sorry αν με πιάνει το δασκαλίστικο αλλά ενδεχομένως να ενδιαφέρει και άλλους το post), θα πρέπει να προσδιορίσεις ποια είναι τα αποδεκτά risks σε ότι αφορά το security.
Πχ χρειάζεσαι να κάνεις encrypt το password ώστε να το αποθηκεύσεις σε κάποια DB?  Αν ναι, θα μπορεί να το δει (έστω και encrypted) ο DBA, οπότε θα πρέπει να βρεις το δικό σου secured store. Αν ο DBA δει το encrypted password υπάρχει περίπτωση να κάνει κρυπτανάλυση για να το δει σε plain text; Γιατί τότε θα πρέπει να υλοποιήσεις assymetric encryption με salt. Υπάρχει περίπτωση να κλέψει το username/password κάποιος πάνω από το καλώδιο? Αν όχι, τότε το HTTPS/IPsec είναι υπερβολικό. Αν υπάρχει περίπτωση τότε με τα ίδια τα data που θα ταξιδεύουν πάνω στο δίκτυο τί γίνεται; Μήπως θα μπορούσε κάποιος να τα κλέψει κι αυτά;

Αν επιχειρήσεις να κάνεις την εφαρμογή σου 99% bullet proof θα πρέπει να επενδύσεις αρκετά resources (χρόνο, χρήμα, κλπ) ενώ αν προσδιορίσεις τι ακριβώς και από ποιόν θέλεις να προστατέψεις μπορείς να κάνεις συγκεκριμένα πράγματα για να είσαι ήσυχος.

 

---

Vir prudens non contra ventum mingit

Ή να χρησιμοποιήσεις τα certificates και τα Certificate Services, που δημιουργήθηκαν ακριβώς για να αποφύγεις όλο αυτό τον μπελά!

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

cgeo wrote:

(Πι ες: ο administrator ας βάλει το FTB να αφήνει html editing (αν αφήνει και ο community server) γιατί τα κουμπάκια πάνω κάνουν τα δικά τους)

Χμμ - ενδιαφέρον!  Εμένα μου βγάζει HTML editing, και στον IE και στον Firefox, και δεν βλέπω πουθενά να έχει setting που να το απαγορεύει στους κανονικούς χρήστες.  Θα το ψάξω περισσότερο και θα σας πω...

---

Patrick

To TaskVision ήταν το πρώτο που είχα δεί όταν πρωτοβγήκε για αυτά τα θέματα. Η υπάρχουσα υλοποίηση βασίζεται πάνω σε αυτό. But:

1. Tα passwords μεταδίδονται σε plain text στο αρχικό request (το έχω ξεπεράσει αυτό χρησιμοποιώντας symmetric, το οποίο όμως έχει hardcoded κλειδί μέσα στον client...)
2. Σε κάθε request που γίνεται πρέπει να υπάρχει ειδικό handling για να πιάνει το null response που σημαίνει ότι έχει λήξει το authentication ticket.

Για να λύσω το πρώτο το ψάχνω με asymmetric.

Για το δεύτερο μία πρόχειρη λύση είναι να ελέγχω το validity του authentication ticket που έχει στα χέρια του ο client πριν από κάθε request με drowback ότι μου διπλασιάζει τον αριθμό των request το οποίο είναι καταστροφικό για το performance απομακρυσμένων clients. Μια άλλη λύση είναι να μου λέει ο server το timeout του και να μην ανανεώνω το ticket αν δεν έχει περάσει το timeout, με drawback να μένει ο client με το πουλί στο χέρι σε περίπτωση που ο server κάνει expire τα tickets πριν από την ώρα τους (πχ, γιατί έγινε restart το application).

Για τα data θα παίξει ένα απλό symmetric με κλειδιά που θα ανταλλάσονται κωδικοποιημένα με asymmetric.

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

---

Χρήστος Γεωργακόπουλος

Γεια και απο μένα.

Καινούργιος εδώ και έκοβα λίγο βόλτες στα θέματα και είδα αυτό.

Ενα καλό implementation θα ήτανε το εξής:
Η δημιουργεία του κλειδιού για μετάδοση γίνεται σύμφωνα με το ρολόι(time & date) και ισχύει για Χ χρόνο (οχι σαν το expire που λέγατε παραπάνο).Σύμφωνα με την Mac Address την IP και την ώρα που έγινε το request βγάζεις το αντίστοιχο κλειδί.Ο client στέλνει αυτό ενώ ο server ξέρει πως να υπολογίσει και αυτός το κλειδί σύμφωνα με τα στοιχεία αυτά(MAC Address,IP,Time & Date).Το κλειδί το κάνεις να είναι valid για X secs.Έτσι δεν υπάρχει περίπτωση κάποιος να καταφέρει να κάνει intercept το connection σου.Ετσι και αλλοιώς και να σπάσει το κλειδί σου, το κλειδί θα είναι valid μόνο για την ημερομηνία, την ώρα και την ip που κατάφερε να το σπάσει.Κοινός θα του είναι άχρηστο!

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

Ευχαριστώ,
Panagiotis aka [email protected]/#php

---

Παναγιώτης Κεφαλίδης

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

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

Ποιανού το ρολόι; Έχω clients που το ρολόι τους έχει ξεφύγει και δεν είναι μέσα στο domain μου για να μπορώ να επέμβω. Αν έχω client με 15 λεπτά διαφορά στο ρολόι τι γίνεται;

---

Χρήστος Γεωργακόπουλος