Το /dev/random, μια κρυπτογραφικά ασφαλής γεννήτρια ψευδοτυχαίων αριθμών (CSPRNG), είναι γνωστό ότι έχει ένα ενοχλητικό πρόβλημα: τον αποκλεισμό. Αυτό το άρθρο εξηγεί πώς μπορείτε να το λύσετε.
Τους τελευταίους μήνες, οι εγκαταστάσεις παραγωγής τυχαίων αριθμών στον πυρήνα έχουν ελαφρώς επεξεργασθεί, αλλά τα προβλήματα σε αυτό το υποσύστημα έχουν επιλυθεί κατά τη διάρκεια του ευρύτερου . Το περισσότερο έγιναν για να αποτραπεί ο αποκλεισμός της κλήσης συστήματος getrandom() για μεγάλο χρονικό διάστημα κατά την εκκίνηση του συστήματος, αλλά ο βασικός λόγος για αυτό ήταν η συμπεριφορά αποκλεισμού της τυχαίας ομάδας συγκέντρωσης. Μια πρόσφατη ενημέρωση κώδικα θα είχε αφαιρέσει αυτό το pool και θα αναμενόταν να κατευθυνθεί προς τον κύριο πυρήνα.
Ο Andy Lutomirski δημοσίευσε την τρίτη έκδοση του patch στα τέλη Δεκεμβρίου. Συμβάλλει "δύο σημαντικές σημασιολογικές αλλαγές σε τυχαία API Linux". Η ενημερωμένη έκδοση κώδικα προσθέτει μια νέα σημαία GRND_INSECURE στην κλήση συστήματος getrandom() (αν και ο Lutomirsky την αναφέρεται ως getentropy(), η οποία υλοποιείται στο glibc χρησιμοποιώντας getrandom() με σταθερές σημαίες). Αυτή η σημαία κάνει την κλήση να επιστρέφει πάντα την ποσότητα των δεδομένων που ζητήθηκε, αλλά χωρίς να εγγυάται ότι τα δεδομένα είναι τυχαία. Ο πυρήνας απλώς θα κάνει ό,τι καλύτερο μπορεί για να παράγει τα καλύτερα τυχαία δεδομένα που έχει τη δεδομένη στιγμή. «Πιθανώς το καλύτερο που έχετε να κάνετε είναι να το ονομάσετε «ΑΝΑΣΦΑΛΕΙΑ» (ανασφαλές) για να αποτρέψετε τη χρήση αυτού του API για πράγματα που χρειάζονται ασφάλεια."
Τα μπαλώματα αφαιρούν επίσης την πισίνα αποκλεισμού. Ο πυρήνας διατηρεί αυτήν τη στιγμή δύο τυχαίες ομάδες δεδομένων, το ένα αντιστοιχεί στο /dev/random και το άλλο στο /dev/urandom, όπως περιγράφεται σε αυτό 2015. Η ομάδα αποκλεισμού είναι η ομάδα για το /dev/random. διαβάζει για αυτή τη συσκευή θα μπλοκάρει (που σημαίνει το όνομά της) έως ότου συλλεχθεί "αρκετή" εντροπία από το σύστημα για την ικανοποίηση του αιτήματος. Περαιτέρω αναγνώσεις από αυτό το αρχείο αποκλείονται επίσης εάν δεν υπάρχει αρκετή εντροπία στο pool.
Η κατάργηση του lock pool σημαίνει ότι η ανάγνωση από το /dev/random συμπεριφέρεται σαν getrandom() με σημαίες μηδενικές (και μετατρέπει τη σημαία GRND_RANDOM σε noop). Μόλις αρχικοποιηθεί η κρυπτογραφική γεννήτρια τυχαίων αριθμών (CRNG), η ανάγνωση από το /dev/random και οι κλήσεις στο getrandom(...,0) δεν θα μπλοκάρουν και θα επιστρέψουν την απαιτούμενη ποσότητα τυχαίων δεδομένων.
Ο/Η Lutomirsky λέει: «Πιστεύω ότι η ομάδα αποκλεισμού Linux έχει καταστεί απαρχαιωμένη. Το CRNG Linux παράγει έξοδο που είναι αρκετά καλό για να χρησιμοποιηθεί ακόμη και για παραγωγή κλειδιών. Η δεξαμενή αποκλεισμού δεν είναι ισχυρότερη από οποιαδήποτε υλική έννοια και απαιτεί πολλή υποδομή αμφίβολης αξίας για να την υποστηρίξει».
Οι αλλαγές έγιναν με στόχο να διασφαλιστεί ότι τα υπάρχοντα προγράμματα δεν θα επηρεαστούν πραγματικά και, στην πραγματικότητα, θα υπήρχαν λιγότερα προβλήματα με μεγάλες αναμονές για πράγματα όπως η δημιουργία κλειδιών GnuPG.
«Αυτά τα επεισόδια δεν πρέπει να διαταράσσουν κανένα υπάρχον πρόγραμμα. Το /dev/urandom παραμένει αμετάβλητο. Το /dev/random εξακολουθεί να μπλοκάρει αμέσως μετά την εκκίνηση, αλλά μπλοκάρει λιγότερο από πριν. Το getentropy() με τις υπάρχουσες σημαίες θα επιστρέψει ένα αποτέλεσμα που είναι εξίσου κατάλληλο για πρακτικούς σκοπούς όπως πριν."
Ο Lutomirsky σημείωσε ότι είναι ακόμα ένα ανοιχτό ερώτημα εάν ο πυρήνας θα πρέπει να παρέχει τους λεγόμενους «αληθινούς τυχαίους αριθμούς», κάτι που υποτίθεται ότι θα έκανε σε κάποιο βαθμό ο πυρήνας αποκλεισμού. Βλέπει μόνο έναν λόγο για αυτό: «τη συμμόρφωση με τα κυβερνητικά πρότυπα». Ο Lutomirsky πρότεινε ότι εάν ο πυρήνας το παρείχε αυτό, θα έπρεπε να γίνει μέσω μιας εντελώς διαφορετικής διεπαφής ή θα έπρεπε να μετακινηθεί στο χώρο χρήστη, επιτρέποντας στον χρήστη να ανακτήσει ακατέργαστα δείγματα συμβάντων που θα μπορούσαν να χρησιμοποιηθούν για τη δημιουργία ενός τέτοιου lock pool.
Ο Stephan Müller πρότεινε το σετ του για το Linux Random Number Generator (LRNG) (επί του παρόντος κυκλοφορεί η έκδοση 26) θα μπορούσε να είναι ένας τρόπος παροχής πραγματικών τυχαίων αριθμών για εφαρμογές που το χρειάζονται. Το LRNG είναι "πλήρως συμβατό με τις Οδηγίες SP800-90B σχετικά με τις πηγές εντροπίας που χρησιμοποιούνται για τη δημιουργία τυχαίων δυαδικών ψηφίων", καθιστώντας το μια λύση στο πρόβλημα των κρατικών προτύπων.
Ο Μάθιου Γκάρετ αντιτάχθηκε στον όρο «αληθινά τυχαία δεδομένα», σημειώνοντας ότι οι συσκευές που ελήφθησαν δειγματοληπτικά θα μπορούσαν κατ' αρχήν να μοντελοποιηθούν με επαρκή ακρίβεια ώστε να είναι προβλέψιμες: «δεν δειγματοληπτούμε κβαντικά γεγονότα εδώ».
Ο Müller απάντησε ότι ο όρος προέρχεται από το γερμανικό πρότυπο AIS 31 για να περιγράψει μια γεννήτρια τυχαίων αριθμών που παράγει μόνο ένα αποτέλεσμα «με τον ίδιο ρυθμό που η υποκείμενη πηγή θορύβου παράγει εντροπία».
Πέρα από τις διαφορές στην ορολογία, η ύπαρξη ενός lock pool όπως προτείνεται από τις ενημερώσεις κώδικα LRNG θα οδηγήσει απλώς σε διάφορα προβλήματα, τουλάχιστον εάν η πρόσβαση είναι χωρίς προνόμια.
Όπως είπε ο Lutomirsky: «Αυτό δεν λύνει το πρόβλημα. Εάν δύο διαφορετικοί χρήστες τρέχουν ανόητα προγράμματα όπως το gnupg, απλώς θα στραγγίζουν ο ένας τον άλλον. Βλέπω ότι υπάρχουν επί του παρόντος δύο κύρια προβλήματα με το /dev/random: είναι επιρρεπές σε DoS (δηλαδή εξάντληση πόρων, κακόβουλη επιρροή ή κάτι παρόμοιο) και επειδή δεν απαιτούνται προνόμια για τη χρήση του, είναι επίσης επιρρεπής σε κατάχρηση. Το Gnupg είναι λάθος, είναι πλήρης κατάρρευση. Αν προσθέσουμε μια νέα μη προνομιούχα διεπαφή που θα χρησιμοποιούν το gnupg και παρόμοια προγράμματα, θα χάσουμε ξανά."
Ο Mueller σημείωσε ότι η προσθήκη του getrandom() θα επιτρέψει πλέον στο GnuPG να χρησιμοποιήσει αυτήν τη διεπαφή, καθώς θα παρέχει την απαραίτητη εγγύηση ότι το pool έχει αρχικοποιηθεί. Με βάση τις συζητήσεις με τον προγραμματιστή του GnuPG Werner Koch, ο Mueller πιστεύει ότι η εγγύηση είναι ο μόνος λόγος που το GnuPG διαβάζει αυτήν τη στιγμή απευθείας από το /dev/random. Αλλά εάν υπάρχει μια μη προνομιούχα διεπαφή που είναι επιρρεπής σε άρνηση υπηρεσίας (όπως είναι σήμερα το /dev/random), ο Lutomirsky υποστηρίζει ότι θα γίνει κατάχρηση από ορισμένες εφαρμογές.
Ο Theodore Yue Tak Ts'o, προγραμματιστής του υποσυστήματος τυχαίων αριθμών του Linux, φαίνεται να έχει αλλάξει γνώμη σχετικά με την ανάγκη για μια ομάδα αποκλεισμού. Είπε ότι η κατάργηση αυτής της δεξαμενής θα απαλλαγεί αποτελεσματικά από την ιδέα ότι το Linux έχει μια πραγματική γεννήτρια τυχαίων αριθμών (TRNG): "Αυτό δεν είναι ανοησία, αφού αυτό ακριβώς έκανε πάντα η *BSD."
Ανησυχεί επίσης ότι η παροχή ενός μηχανισμού TRNG θα χρησιμεύσει απλώς ως δόλωμα για τους προγραμματιστές εφαρμογών και πιστεύει ότι στην πραγματικότητα, δεδομένων των διαφορετικών τύπων υλικού που υποστηρίζονται από το Linux, είναι αδύνατο να εγγυηθεί το TRNG στον πυρήνα. Ακόμη και η δυνατότητα εργασίας με εξοπλισμό μόνο με δικαιώματα root δεν θα λύσει το πρόβλημα: "Οι προγραμματιστές εφαρμογών καθορίζουν ότι η εφαρμογή τους θα εγκατασταθεί ως root για λόγους ασφαλείας, έτσι ώστε αυτός είναι ο μόνος τρόπος για να έχετε πρόσβαση στους "πολύ καλούς" τυχαίους αριθμούς."
Ο Mueller ρώτησε εάν ο Cao είχε εγκαταλείψει την εφαρμογή της ομάδας αποκλεισμού που ο ίδιος είχε προτείνει εδώ και καιρό. Ο Cao απάντησε ότι σχεδιάζει να πάρει τις ενημερώσεις κώδικα του Lutomirsky και αντιτίθεται ενεργά στην προσθήκη μιας διεπαφής αποκλεισμού πίσω στον πυρήνα.
«Ο πυρήνας δεν μπορεί να εγγυηθεί εάν η πηγή θορύβου έχει χαρακτηριστεί σωστά. Το μόνο πράγμα που μπορεί να αποκτήσει ένας προγραμματιστής GPG ή OpenSSL είναι μια αόριστη αίσθηση ότι το TRUERANDOM είναι "καλύτερο" και δεδομένου ότι θέλουν περισσότερη ασφάλεια, αναμφίβολα θα προσπαθήσουν να το χρησιμοποιήσουν. Κάποια στιγμή θα αποκλειστεί και όταν κάποιος άλλος έξυπνος χρήστης (ίσως ένας ειδικός διανομής) το εισάγει στο σενάριο έναρξης και τα συστήματα σταματήσουν να λειτουργούν, οι χρήστες θα πρέπει μόνο να παραπονεθούν στον ίδιο τον Linus Torvalds."
Ο Cao υποστηρίζει επίσης να δοθεί στους κρυπτογράφους και σε εκείνους που χρειάζονται πραγματικά το TRNG έναν τρόπο να συλλέξουν τη δική τους εντροπία στο χώρο των χρηστών για να τον χρησιμοποιήσουν όπως τους βολεύει. Λέει ότι η συλλογή εντροπίας δεν είναι μια διαδικασία που μπορεί να εκτελεστεί από τον πυρήνα σε όλο το διαφορετικό υλικό που υποστηρίζει, ούτε ο ίδιος ο πυρήνας μπορεί να εκτιμήσει το ποσό της εντροπίας που παρέχεται από διαφορετικές πηγές.
«Ο πυρήνας δεν πρέπει να αναμειγνύει διαφορετικές πηγές θορύβου και σίγουρα δεν θα πρέπει να προσπαθεί να ισχυριστεί ότι γνωρίζει πόσα bits εντροπίας παίρνει όταν προσπαθεί να παίξει κάποιο είδος «παιχνιδιού εντροπίας με σπασμούς» σε μια εξωφρενικά απλή CPU αρχιτεκτονική για χρήστες.
«Μπορείτε να μιλήσετε για την παροχή εργαλείων που προσπαθούν να κάνουν αυτούς τους υπολογισμούς, αλλά τέτοια πράγματα πρέπει να γίνονται στο υλικό κάθε χρήστη, κάτι που απλά δεν είναι πρακτικό για τους περισσότερους χρήστες διανομής. Εάν αυτό προορίζεται μόνο για κρυπτογράφους, τότε αφήστε το να γίνει στον χώρο χρήστη τους. Και ας μην απλοποιήσουμε το GPG, το OpenSSL κ.λπ. για να λένε όλοι «θέλουμε «αληθινή τυχαιότητα» και δεν συμβιβαζόμαστε με λιγότερο». Μπορούμε να μιλήσουμε για το πώς παρέχουμε διεπαφές στους κρυπτογράφους, ώστε να μπορούν να λάβουν τις πληροφορίες που χρειάζονται με πρόσβαση στις κύριες πηγές θορύβου, διαχωρισμένες και ονομασμένες, και ίσως με κάποιο τρόπο η πηγή θορύβου να μπορεί να πιστοποιηθεί σε μια βιβλιοθήκη ή εφαρμογή χώρου χρήστη."
Έγινε κάποια συζήτηση σχετικά με το πώς μπορεί να μοιάζει μια τέτοια διεπαφή, καθώς για παράδειγμα μπορεί να υπάρχουν επιπτώσεις στην ασφάλεια για ορισμένα συμβάντα. Ο Cao σημείωσε ότι οι κώδικες σάρωσης πληκτρολογίου (δηλαδή πατήματα πλήκτρων) αναμιγνύονται σε ένα pool ως μέρος της συλλογής εντροπίας: "Η μεταφορά αυτού στο χώρο του χρήστη, ακόμη και μέσω μιας προνομιακής κλήσης συστήματος, θα ήταν τουλάχιστον άσοφο." Είναι πολύ πιθανό ότι άλλοι χρονισμοί συμβάντων μπορεί να δημιουργήσουν κάποιου είδους διαρροή πληροφοριών μέσω πλευρικών καναλιών.
Φαίνεται λοιπόν ότι ένα μακροχρόνιο πρόβλημα με το υποσύστημα τυχαίων αριθμών του Linux βρίσκεται στο δρόμο προς τη λύση. Οι αλλαγές στις οποίες έχει υποστεί πρόσφατα το υποσύστημα τυχαίων αριθμών στην πραγματικότητα οδήγησαν μόνο σε ζητήματα DoS κατά τη χρήση του. Τώρα υπάρχουν αποτελεσματικοί τρόποι για να λάβετε τους καλύτερους τυχαίους αριθμούς που μπορεί να παρέχει ο πυρήνας. Εάν το TRNG εξακολουθεί να είναι επιθυμητό στο Linux, τότε αυτό το ελάττωμα θα πρέπει να αντιμετωπιστεί στο μέλλον, αλλά πιθανότατα αυτό δεν θα γίνει μέσα στον ίδιο τον πυρήνα.
Μερικές διαφημίσεις 🙂
Σας ευχαριστούμε που μείνατε μαζί μας. Σας αρέσουν τα άρθρα μας; Θέλετε να δείτε πιο ενδιαφέρον περιεχόμενο; Υποστηρίξτε μας κάνοντας μια παραγγελία ή προτείνοντας σε φίλους, , ένα μοναδικό ανάλογο διακομιστών εισαγωγικού επιπέδου, το οποίο εφευρέθηκε από εμάς για εσάς: (διατίθεται με RAID1 και RAID10, έως 24 πυρήνες και έως 40 GB DDR4).
Το Dell R730xd 2 φορές φθηνότερο στο κέντρο δεδομένων Equinix Tier IV στο Άμστερνταμ; Μόνο εδώ στην Ολλανδία! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - από 99$! Διαβάστε σχετικά
Πηγή: www.habr.com