Into.the.Void.

Πριν λίγες μέρες έγινε πάρα πολύ σημαντική δίκη για το Ελληνικό Internet. Δυστυχώς όμως δεν έγινε καμία αναφορά από τους δημοσιογράφους που ασχολούνται με τα “νέα μέσα” για το θέμα, οι μόνοι οι οποίοι έχουν αναφερθεί στο θέμα και μάλιστα το έχουν παρακολουθήσει από πολύ κοντά είναι τα παιδιά του adslgr.com (Thread).

Λίγο ιστορία…
Πέρυσι είχαμε την “χαρά” το Πρωτοδικείο Αθηνών με την απόφαση 4658/2012 να δικαιώσει την ΑΕΠΙ στα ασφαλιστικά μέτρα που είχε κάνει εναντίον όλων των Ελλήνων παρόχων (ISPs) ώστε να αποκλειστεί η πρόσβαση προς 2 sites που βρισκόταν εκτός της χώρας μας. Η αίτηση των ασφαλιστικών μέτρων έγινε τον Οκτώβριο του 2010 και η τελική δίκη μετά τις αναβολές έγινε το Μάϊο του 2012. Τα 2 sites ήταν το ellinadiko.com και το music-bazaar.com. Ενώ η ΑΕΠΙ είχε ζητήσει να αποκλειστούν από τους παρόχους και οι IPs που κατείχαν τότε τα 2 sites αλλά και να αποκλειστούν από το επίπεδο του DNS, τα δικαστήρια διέταξαν μόνο τον αποκλεισμό των IPs. Οι περισσότεροι χρήστες του Ελληνικού Internet δεν έχουν την παραμικρή ιδέα για αυτή τη απόφαση και αυτό γιατί δεν τους επηρέασε στο ελάχιστο. Το ellinadiko για δικούς του λόγους είχε κλείσει πριν γίνει η δίκη, και έτσι οι χρήστες είχαν ήδη στραφεί σε άλλα sites, ενώ το music-bazaar είχε αλλάξει IP. Ενώ, δηλαδή, το δικαστήριο επέβαλε στους παρόχους να αποκλείσουν την IP 1.2.3.4 το music-bazaar είχε ήδη πριν την δίκη μεταφερθεί στην 5.6.7.8. Έτσι, και η IP του ellinadiko και η IP του music-bazaar στις οποίες γινόταν αναφορά στα ασφαλιστικά μέτρα του 2012 είναι αυτή τη στιγμή μη προσβάσιμες από τους Έλληνες χρήστες χωρίς να φιλοξενούν οτιδήποτε σχετικό με τα προηγούμενα sites. Και το ακόμα καλύτερο; Κανείς δεν γνωρίζει αν και πότε θα αρθούν αυτοί οι αποκλεισμοί, καθώς δεν υπάρχει τέτοια πρόβλεψη στην απόφαση. Οπότε ο δικαστής αυτός δημιούργησε δύο μαύρες τρύπες για το Ελληνικό Internet.

Τώρα που πήρε φόρα…
Στις 14/01/2013 η ΑΕΠΙ επανήλθε με 2 νέες αιτήσεις ασφαλιστικών μέτρων! Η πρώτη αφορούσε αποκλειστικά το website με όνομα www.thepiratebay.se και την IP του (194.71.107.15) και η δεύτερη αφορούσε το website με όνομα www.activeloads.com και την IP του (93.190.139.103). Σαν να μην έφτανε αυτό στις 26/04/2013 έρχεται και νέα αίτηση για ασφαλιστικά μέτρα για τα παρακάτω sites: www.greek-team.cc (www.mytog.net), www.p2planet.net, www.greek.to, www.tsibato.info, www.greekddl.eu, www.greek-best.com, www.kat.ph, www.isohunt.com, www.1337x.org, www.h33t.com και τις IPs που είχαν τότε. Στα ασφαλιστικά μέτρα ζητείται να αποκλειστεί η πρόσβαση στα website ή στις IP ή αν τα παραπάνω δεν γίνουν, ζητά να απαγορευτούν τα downloads (καταφορτώσεις) μουσικών έργων από αυτά τα websites (ζητά δηλαδή την εφαρμογή DPI (Deep Packet Inspection) από τους παρόχους). Η αίτηση της ΑΕΠΙ αναφέρει με 2 λόγια πως αφού δεν μπορούν να εντοπίσουν τους ιδιοκτήτες των websites αυτών, ζητούν από τα δικαστήρια να προστατέψει τα μέλη της ΑΕΠΙ από την “πειρατεία” εξαναγκάζοντας τους παρόχους να “τα κόψουν”. Μετά από διαπραγματεύσεις καταλήγει να γίνει μία δίκη και για τις τρεις αιτήσεις, τον Σεπτέμβριο του 2013. Η δίκη αναβάλλεται για τις 13/12/2013 όπου και έγινε. Τα επιχειρήματα των παρόχων ήταν για άλλη μια φορά πολύ καλά, αλλά μάλλον δεν παίζει και ιδιαίτερο ρόλο στα αυτιά των δικαστών που κατά πάσα πιθανότητα αγνοούν εντελώς τις τεχνικές λεπτομέρειες του εγχειρήματος, αν θεωρείται δύσκολο να εξηγήσει κανείς πως ακριβώς δουλεύουν τα torrents και γιατί τα websites αυτά δεν φιλοξενούν τα ίδια παράνομο περιεχόμενο, σκεφτείτε πόσο πιο δύσκολο είναι να να εξηγήσει κανείς πως δουλεύουν τα magnet links και το DHT. Άλλωστε φαίνεται πως οι δικαστές δεν ενδιαφέρονται ιδιαίτερα για το διαδίκτυο ή για την ιδιωτικότητα γενικότερα, διότι οι όποιες αποφάσεις βγουν θα επηρεάσουν σημαντικά την ιδιωτικότητα όλων των Ελλήνων χρηστών. Είμαστε πλέον σε αναμονή της απόφασης η οποία μπορεί να κάνει ακόμα και 3 μήνες για να βγει.

Ίδια απόφαση με την 4658/2012 ή μήπως όχι;
Η απόφαση ακόμα δεν έχει βγει αλλά κατά την εκτίμηση μου υπάρχει σοβαρή περίπτωση να είναι διαφορετική από την 4658/2012 και μάλιστα προς το χειρότερο. Αυτό γιατί στο ενδιάμεσο έχει υπάρξει άλλη μια απίστευτη κίνηση από μεριάς του κράτους η οποία υπονομεύει την ελεύθερη λειτουργία του Internet στην Ελλάδα. Το κράτος λοιπόν, θέλοντας να τα τσεπώνει από τις άδειες που χορηγεί στα sites σχετικά με τον τζόγο (στοιχήματα) έχει δημιουργήσει την ΕΕΕΠ. Τι είναι η ΕΕΕΠ; Επιτροπή Εποπτείας και Ελέγχου Παιγνίων. Αυτή η επιτροπή λοιπόν έχει το δικαίωμα να αποφασίζει ποια websites τζόγου θα αποκλειστούν από τους παρόχους ώστε να μην έχουν πρόσβαση οι χρήστες τους σε αυτά. Όποιος δεν πληρώνει, κόβεται. Μάλιστα, επειδή ξέρουν πόσο δύσκολο είναι να απαγορεύσεις την πρόσβαση σε ένα site στο Internet μπλοκάροντας απλά μια IP, αυτοί έχουν την εξουσία να παραγγέλνουν από τους ISPs να μπλοκάρουν URLs χωρίς να ενδιαφέρονται για το πως θα το υλοποιήσει ο πάροχος. Κάθε τόσο λοιπόν εμφανίζουν μια λίστα με URLs στους παρόχους και τους αναγκάζουν να κόψουν την πρόσβαση. Η πιο πρόσφατη λίστα όσο γράφεται αυτό το post είναι αυτή: BlackList EEEP 22/11/2013. Αυτό το pdf είναι και το μόνο που παρέχουν στους παρόχους, ούτε καν μια λίστα σε μορφή txt για να είναι ευκολότερη η αυτοματοποίηση. Και το επισημαίνω για άλλη μια φορά, δίνουν URLs και όχι domains ή IPs.

Τί σημαίνει αυτό όμως στην ουσία για παρόχους και χρήστες;
Οι πάροχοι δεν μπορούν να κόψουν τις IPs των betting sites γιατί α) είναι πιθανόν στις ίδιες IPs να συστεγάζονται και άλλα sites, β) κάποια betting sites γίνονται host σε εταιρίες τύπου Akamai, Cloudflare,κτλ δεν είναι δυνατόν να κόψει ένας πάροχος τα CDN αυτά, γ) ένα site μπορεί να αλλάζει IPs όποτε θέλει, άρα ποιος θα παρακολουθεί τι κάνει το κάθε site κάθε μέρα; Επειδή, από όσο μπορώ να γνωρίζω, οι ελληνικοί πάροχοι σταθερού Internet (xDSL) δεν έχουν αυτή τη στιγμή δυνατότητα να κάνουν DPI, να κοιτάνε δηλαδή κάθε πακέτο ποια “web/URL” (και όχι IP) διεύθυνση αναφέρει μέσα του και να κόβουν μόνο αυτά, μένουν με ένα και μοναδικό “όπλο” στα χέρια τους. Το DNS block. Δηλαδή, οι DNS servers των ελληνικών ISPs λένε ψέμματα στους χρήστες για τις πραγματικές διευθύνσεις των betting sites που θέλει να κόψει η ΕΕΕΠ. Αντί να δίνουν στους χρήστες τις σωστές IPs ενός site, δίνουν μια ψεύτικη ή δεν απαντούν καθόλου και αυτό κάνει τον χρήστη να θεωρεί πως δεν δουλεύει πλέον το website που θέλει να επισκεπτεί. Φυσικά οι χρήστες έχουν την δυνατότητα να χρησιμοποιήσουν άλλους DNS servers, εκτός του παρόχου τους – εκτός Ελλάδας βασικά, για να μάθουν τις σωστές απαντήσεις στα DNS ερωτήματά τους. Αυτό όμως με την σειρά του δημιουργεί διάφορα θέματα. Καταρχήν όταν ρωτάς ένα DNS server στο εξωτερικό όλα τα DNS ερωτήματα καθυστερούν λίγο παραπάνω, το λίγο μπορεί να σημαίνει πως από τα 10-20ms που έχει κάποιος με τους DNS servers του ISP του μπορεί να φτάσει τα 60-80 ή και 100ms, δηλαδή μια καθυστέρηση τουλάχιστον της τάξης του 3-5x. Έπειτα σημαίνει πως ο νέος “DNS” πάροχος αυτός ξέρει ό,τι κάνει κάποιος Έλληνας χρήστης και μπορεί φυσικά να χρησιμοποιήσει τα δεδομένα αυτά όπως του αρέσει. Φυσικά o πάροχος αυτός δεν υπόκειται στην Ελληνική νομοθεσία, άρα τα προσωπικά δεδομένα των χρηστών – δηλαδή το ποια sites επισκέπτεται ο καθένας, μπορεί να τα χειριστεί ο πάροχος αυτός χωρίς να χρειάζεται να συμμορφωθεί με τους ελληνικούς νόμους περί προστασίας των δεδομένων. Αν εγώ αύριο χρησιμοποιήσω ένα DNS server του εξωτερικού κανείς δεν μου εγγυάται πως α) οι δικές του απαντήσεις δεν θα με στέλνουν σε sites με malware ή δεν θα βγάλει κάποτε μια λίστα με το ποια sites ζήτησα να επισκεφτώ…Το πρόβλημα όμως δεν τελειώνει εκεί, αν διαβάσει κανείς το ένα από τα ΦΕΚ που αφορούν την λειτουργία της ΕΕΕΠ θα δει πως τα πράγματα είναι πολύ χειρότερα από όσο μπορεί να φανταστεί. Οι τολμηροί ας διαβάσουν το άρθρο 52 του ν.4002/2011 (Α 218). Παραδείγματα:
Αν σε πιάσουν ως χρήστη να παίζεις σε μη αδειοδοτημένο website…

Όποιος μετέχει σε τυχερό παίγνιο, το οποίο διοργανώνεται χωρίς άδεια από την Ελληνική Δημοκρατία, τιμωρείται με ποινή φυλάκισης έως τριών (3) μηνών και με χρηματική ποινή από 5.000 έως 20.000 ευρώ.

Αν σε πιάσουν να παρέχεις proxy ή άλλο μέσο ώστε να παίζει κάποιος τρίτος σε μη αδειοδοτημένο website…

Όποιος μετέχει σε παίγνια μέσω παρενθέτου φυσικού ή νομικού προσώπου τιμωρείται με φυλάκιση έως δύο (2) ετών και χρηματική ποινή από 100.000 έως 200.000 ευρώ. Με τις ίδιες ποινές τιμωρείται και το παρένθετο φυσικό πρόσωπο και αν πρόκειται για νομικό πρόσωπο, τα πρόσωπα που καθορίζονται ως αυτουργοί με την παράγραφο 11.

Και κάτι ακόμα ως τροφή για σκέψη, σε μια από τις προσκλήσεις για συζήτηση της ΕΕΕΠ προς τους παρόχους, δύο από τα θέματα της ατζέντας ήταν μεταξύ άλλων το πως θα ελεγχθεί/αποκλειστεί η πρόσβαση στα betting sites μέσω proxy και έπειτα αν μπορεί η ΕΕΕΠ να έχει μια λίστα με τους χρήστες που επισκέπτονται αυτά τα sites (!?).

Αυτά συμβαίνουν σήμερα στο Ελληνικό Internet, δεν είναι από κάποιο φαντασιακό μέλλον, αλλά από το σήμερα.

Τι μπορεί να γίνει με τα ασφαλιστικά μέτρα;
Γυρνώντας στα πρόσφατα ασφαλιστικά μέτρα, κάποιος δικαστής που θα κάνει ένα ελαφρύ διάβασμα και θα ρωτήσει και 2-3 άλλους (ή θα του το ψιθυρίσει η ΑΕΠΙ) θα δει πως υπάρχει ο 4002/2011 που απαγορεύει γενικά και αόριστα την πρόσβαση σε sites. Το πως το αφήνει στους παρόχους…κάντε ό,τι καταλαβαίνετε…αλλιώς θα πάτε φυλακή. Άρα η προσωπική μου εκτίμηση για την απόφαση είναι πως αν μείνει στον αποκλεισμό IP των websites που αναφέρονται στα ασφαλιστικά μέτρα, μάλλον θα πρόκειται για “νίκη”. Δεν θεωρώ όμως πως αυτό το σενάριο έχει ιδιαίτερη βάση. Για μένα είτε θα βγει μια ακυρωτική απόφαση για τα ασφαλιστικά μέτρα, είναι η αλήθεια πως οι πάροχοι αυτή τη φορά το είχαν πάρει το θέμα πολύ πιο σοβαρά από την προηγούμενη, είτε η απόφαση θα αναφέρει συγκεκριμένα το DNS block. Το DNS block απλά θα ανοίξει τους ασκούς του Αιόλου για το τι μπορεί να ακολουθήσει. Και να είμαστε όλοι σίγουροι πως η ΑΕΠΙ δεν θα σταματήσει στο DNS block… Αλλά δεν είναι το πρόβλημα μόνο η ΑΕΠΙ ή η ΕΕΕΠ. Το πρόβλημα είναι πως έχει αρχίσει και στην Ελλάδα να υπάρχει η νοοτροπία αλλά και η νομική κάλυψη περί απαγόρευσης πρόσβασης σε συγκεκριμένες ιστοσελίδες που οι servers τους δεν βρίσκονται καν στην χώρα μας. Με το πρόσχημα είτε της πειρατείας είτε της μη αδειοδότησης, αποκλείονται ιστότοποι από τους Έλληνες χρήστες. Μάλιστα, τα μέτρα που λαμβάνονται κάθε φορά φαίνεται να έχουν όλο και πιο προηγμένο τεχνολογικό χαρακτήρα και λίγο μας χωρίζει πλέον από το να λαμβάνει η χώρα μας μέτρα τύπου Ιράν και Κίνας. Μπορεί να ακούγεται τραβηγμένο, αλλά από την στιγμή που θα εγκατασταθεί η τεχνολογία (DPI) για να κόβεις την “πειρατεία” ή τα “παράνομα” sites τζόγου δεν μπορείς να είσαι σίγουρος για το τι άλλο θα κηρυχθεί παράνομο αύριο και θα κοπεί με την ίδια τεχνολογία.
Προσωπικά σιχαίνομαι τα betting sites όσο τίποτε άλλο, αλλά αυτό δεν με σταματάει από το να υποστηρίζω το δικαίωμά τους να μην λογοκρίνονται. Γιατί αυτό είναι και το ζουμί της υπόθεσης, αρχίζει πλέον το κράτος/εξουσία να λογοκρίνει όλο και περισσότερα κομμάτια του Internet που δεν αρέσουν.

Και στο μέλλον;
Δεν είναι τυχαίο άλλωστε πως στο σχεδιαζόμενο “samaras-wifi” ανακοινώθηκε πως φυσικά θα υπάρχει φίλτρο περιεχομένου, πριν καν μάθουμε οποιεσδήποτε άλλες ποιοτικές πληροφορίες για το δίκτυο το ίδιο:

“όταν εγκατασταθεί (το wifi), να τοποθετηθούν ειδικά φίλτρα που να απαγορεύουν πρόσβαση σε σελίδες με άσεμνο περιεχόμενο και γενικά σε σελίδες σεξ, καθώς και να υπάρχουν φίλτρα ώστε να μην μπορεί κανείς να «κατεβάσει» τραγούδια ή κινηματογραφικές ταινίες!”.

Πέραν της υπονοούμενης αναφοράς σε DPI, το ποιός θα αποφασίζει τι επιτρέπεται (τι σημαίνει “άσεμνο”;;;) και τί όχι, το πώς, κτλ αφήνεται εντελώς ασαφές. Η λογοκρισία μπαίνει στη ζωή κάθε πολίτη με μικρά αλλά σταθερά βήματα, θεωρώντας δεδομένη την κατάσταση που επικρατεί ήδη, η εκάστοτε κυριαρχία/εξουσία επιβάλει όλο και περισσότερες απαγορεύσεις, “για το καλό μας”.

Υ.Γ. Οι παραπάνω απόψεις είναι προφανώς προσωπικές πολύ πιθανόν ο εργοδότης μου να έχει εντελώς διαφορετικές 🙂
Υ.Γ.2 Ίσως να μην είναι αργά ακόμα, αν κάποιοι δημοσιογράφοι αναδείξουν το θέμα κατάλληλα μπορεί και να καταφέρουμε την ακύρωση των ασφαλιστικών μέτρων. Ελπίζω να γλυτώσουμε όμως την κλάψα μετά την απόφαση, το “δεν ήξερα” δεν μπορεί να είναι πλέον δικαιολογία.
Υ.Γ.3 Δεν είμαι νομικός, αν κάποιος νομικός γνωρίζει περισσότερα για τα παραπάνω ας με διορθώσει.

Filed by kargig at 14:51 under Greek,Internet,Networking,Privacy
Tags: 4002/2011, 4658/2012, blacklist, dns, dpi, isohunt, piratebay, ΑΕΠΙ, ασφαλιστικά μέτρα, ιδωτικότητα
14 Comments | 38,078 views

A few weeks ago I created my new GPG/PGP key with subkeys and a few people asked me why and how. The rationale for creating separate subkeys for signing and encryption is written very nicely in the subkeys page of the debian wiki. The short answer is that having separate subkeys makes key management a lot easier and protects you in certain occasions, for example you can create a new subkey when you need to travel or when your laptop gets stolen, without losing previous signatures. Obviously you need to keep your master key somewhere very very safe and certainly not online or attached to a computer.

You can find many other blog posts on the net on the subject, but most of them are missing a few parts. I’ll try to keep this post as complete as possible. If you are to use gpg subkeys you definitely need an encrypted usb to store the master key at the end. So if you don’t already have an encrypted USB go and make one first.

When this process is over you will have a gpg keypair on your laptop without the master key, you will be able to use that for everyday encryption and signing of documents but there’s a catch. You won’t be able to sign other people’s keys. To do that you will need the master key. But that is something that does not happen very often so it should not be a problem in your everyday gpg workflow. You can read about signing other people’s keys at the end of this post. AFAIK you can’t remove your master key using some of the gpg GUIs, so your only hope is the command line. Live with it…

First some basic information that will be needed later.
When listing secret keys with gpg -K keys are marked with either ‘sec’ or ‘ssb’. When listing (public) keys with gpg -k keys are marked with ‘pub’ or ‘sub’.

sec => 'SECret key'
ssb => 'Secret SuBkey'
pub => 'PUBlic key'
sub => 'public SUBkey'

When editing a key you will see a usage flag on the right. Each key has a role and that is represented by a character. These are the roles and their corresponding characters:

Constant           Character      Explanation
─────────────────────────────────────────────────────
PUBKEY_USAGE_SIG      S       key is good for signing
PUBKEY_USAGE_CERT     C       key is good for certifying other signatures
PUBKEY_USAGE_ENC      E       key is good for encryption
PUBKEY_USAGE_AUTH     A       key is good for authentication

Before doing anything make sure you have a backup of your .gnupg dir.
$ umask 077; tar -cf $HOME/gnupg-backup.tar -C $HOME .gnupg

Secure preferences
Now edit your .gnupg/gpg.conf and add or change the following settings (most are stolen from Riseup: OpenPGP Best Practices):

# when outputting certificates, view user IDs distinctly from keys:
fixed-list-mode
# long keyids are more collision-resistant than short keyids (it's trivial to make a key with any desired short keyid)
keyid-format 0xlong
# when multiple digests are supported by all recipients, choose the strongest one:
personal-digest-preferences SHA512 SHA384 SHA256 SHA224
# preferences chosen for new keys should prioritize stronger algorithms:
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed
# If you use a graphical environment (and even if you don't) you should be using an agent:
# (similar arguments as https://www.debian-administration.org/users/dkg/weblog/64)
use-agent
# You should always know at a glance which User IDs gpg thinks are legitimately bound to the keys in your keyring:
verify-options show-uid-validity
list-options show-uid-validity
# when making an OpenPGP certification, use a stronger digest than the default SHA1:
cert-digest-algo SHA256
# prevent version string from appearing in your signatures/public keys
no-emit-version 

Create new key
Time to create the new key. I’m marking user input with bold (↞) arrows

$ gpg --gen-key
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection?

Your selection?  1 ↞↞↞↞ 

RSA keys may be between 1024 and 4096 bits long.

What keysize do you want? (2048)  4096 ↞↞↞↞ 

Requested keysize is 4096 bits
Please specify how long the key should be valid.
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years

Key is valid for? (0)  0 ↞↞↞↞ 

Key does not expire at all

Is this correct? (y/N)  y ↞↞↞↞ 

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
    "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"

Real name: foo bar ↞↞↞↞ 

Email address: foobar@void.gr ↞↞↞↞ 

Comment:
You selected this USER-ID:
"foo bar <foobar@void.gr>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?  O ↞↞↞↞ 

You need a Passphrase to protect your secret key.

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
.............+++++
..+++++

gpg: key 0x6F87F32E2234961E marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   3  signed:  14  trust: 0-, 0q, 0n, 0m, 0f, 3u
gpg: depth: 1  valid:  14  signed:   9  trust: 13-, 1q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2014-03-18
pub   4096R/0x6F87F32E2234961E 2013-12-01
      Key fingerprint = 407E 45F0 D914 8277 3D28  CDD8 6F87 F32E 2234 961E
uid                 [ultimate] foo bar <foobar@void.gr>
sub   4096R/0xD3DCB1F51C37970B 2013-12-01

Optionally, you can add another uid and add it as the default:

$ gpg --edit-key 0x6F87F32E2234961E                                      
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  4096R/0x6F87F32E2234961E  created: 2013-12-01  expires: never       usage: SC  
                               trust: ultimate      validity: ultimate
sub  4096R/0xD3DCB1F51C37970B  created: 2013-12-01  expires: never       usage: E   
[ultimate] (1). foo bar <foobar@void.gr>

gpg> adduid ↞↞↞↞ 

Real name: foo bar ↞↞↞↞ 

Email address: foobar@riseup.net ↞↞↞↞ 

Comment: 
You selected this USER-ID:
    "foo bar <foobar@riseup.net>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?  O ↞↞↞↞ 

You need a passphrase to unlock the secret key for
user: "foo bar <foobar@void.gr>"
4096-bit RSA key, ID 0x6F87F32E2234961E, created 2013-12-01

pub  4096R/0x6F87F32E2234961E  created: 2013-12-01  expires: never       usage: SC  
                               trust: ultimate      validity: ultimate
sub  4096R/0xD3DCB1F51C37970B  created: 2013-12-01  expires: never       usage: E   
[ultimate] (1)  foo bar <foobar@void.gr>
[ unknown] (2). foo bar <foobar@riseup.net>

gpg> uid 2 ↞↞↞↞ 

gpg> primary ↞↞↞↞ 

gpg> save ↞↞↞↞ 

Let’s see what we’ve got until now, 0x6F87F32E2234961E is the master key (SC flags) and 0xD3DCB1F51C37970B (E flag)is a separate subkey for encryption.

Add new signing subkey
Since we already have a separate encryption subkey, it’s time for a new signing subkey. Expiration dates for keys is a very hot topic. IMHO there’s no point in having an encryption subkey with an expiration date, expired keys are working just fine for decryption anyways, so I’ll leave it without one, but I want the signing key that I’m regularly using to have an expiration date. You can read more about this topic on the gnupg manual (Selecting expiration dates and using subkeys).

$ gpg --edit-key 0x6F87F32E2234961E
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  4096R/0x6F87F32E2234961E  created: 2013-12-01  expires: never       usage: SC  
                               trust: ultimate      validity: ultimate
sub  4096R/0xD3DCB1F51C37970B  created: 2013-12-01  expires: never       usage: E   
[ultimate] (1). foo bar <foobar@riseup.net>
[ultimate] (2)  foo bar <foobar@void.gr>

gpg> addkey ↞↞↞↞ 

Key is protected.

You need a passphrase to unlock the secret key for
user: “foo bar <foobar@riseup.net>”
4096-bit RSA key, ID 0x6F87F32E2234961E, created 2013-12-01

Please select what kind of key you want:
(3) DSA (sign only)
(4) RSA (sign only)
(5) Elgamal (encrypt only)
(6) RSA (encrypt only)

Your selection? 4 ↞↞↞↞ 

RSA keys may be between 1024 and 4096 bits long.

What keysize do you want? (2048) 4096 ↞↞↞↞ 

Requested keysize is 4096 bits
Please specify how long the key should be valid.
         0 = key does not expire
        = key expires in n days
      w = key expires in n weeks
      m = key expires in n months
      y = key expires in n years

Key is valid for? (0) 5y ↞↞↞↞ 

Key expires at Fri 30 Nov 2018 03:36:47 PM EET

Is this correct? (y/N) y ↞↞↞↞ 

Really create? (y/N) y ↞↞↞↞ 

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
+++++
...............+++++

pub  4096R/0x6F87F32E2234961E  created: 2013-12-01  expires: never       usage: SC  
                               trust: ultimate      validity: ultimate
sub  4096R/0xD3DCB1F51C37970B  created: 2013-12-01  expires: never       usage: E   
sub  4096R/0x296B12D067F65B03  created: 2013-12-01  expires: 2018-11-30  usage: S   
[ultimate] (1). foo bar <foobar@riseup.net>
[ultimate] (2)  foo bar <foobar@void.gr>

gpg> save ↞↞↞↞ 

As you can see there’s a new subkey 0x296B12D067F65B03 with just the S flag, that the signing subkey.
Before moving forward it’s wise to create a revocation certificate:

$ gpg --output 0x6F87F32E2234961E.gpg-revocation-certificate --armor --gen-revoke 0x6F87F32E2234961E
sec  4096R/0x6F87F32E2234961E 2013-12-01 foo bar <foobar@riseup.net>

Create a revocation certificate for this key? (y/N) y
Please select the reason for the revocation:
  0 = No reason specified
  1 = Key has been compromised
  2 = Key is superseded
  3 = Key is no longer used
  Q = Cancel
(Probably you want to select 1 here)

Your decision?  1 ↞↞↞↞ 

Enter an optional description; end it with an empty line:

> This revocation certificate was generated when the key was created. ↞↞↞↞ 
> 

Reason for revocation: Key has been compromised
This revocation certificate was generated when the key was created.

Is this okay? (y/N) y ↞↞↞↞ 

You need a passphrase to unlock the secret key for
user: "foo bar <foobar@riseup.net>"
4096-bit RSA key, ID 0x6F87F32E2234961E, created 2013-12-01

Revocation certificate created.

Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable.  But have some caution:  The print system of
your machine might store the data and make it available to others!

Encrypt this file and store it someplace safe, eg your encrypted USB. You should definitely not leave it at your laptop’s hard disk. You can even print it and keep it in this form, it’s small enough so one could type it if needed.

Remove Master key
And now the interesting part, it’s time to remove the master key from your laptops’s keychain and just leave the subkeys. You will store the master key in the encrypted usb so it stays safe.

First go and backup your .gnupg dir on your encrypted USB. Don’t move forward until you do that. DON’T!

$ rsync -avp $HOME/.gnupg /media/encrypted-usb
or
$ umask 077; tar -cf /media/encrypted-usb/gnupg-backup-new.tar -C $HOME .gnupg

Did you backup your key? Are you sure ?

Then it’s time to remove the master key!

$ gpg --export-secret-subkeys 0x6F87F32E2234961E > /media/encrypted-usb/subkeys
$ gpg --delete-secret-key 0x6F87F32E2234961E
$ gpg --import /media/encrypted-usb/subkeys
$ shred -u /media/encrypted-usb/subkeys

What you’ve accomplished with this process is export the subkeys to /media/encrypted-usb/subkeys then delete the master key and re-import just the subkeys. Master key resides only on the encrypted USB key now. Don’t lose that USB key. USB keys are extremely cheap, make multiple copies of the encrypted key and place them in safe places, you can give one such key to your parents or your closest friend in case of emergency. For safety, make sure there’s at least one copy outside of your residence.

You can see the difference of the deleted master key by comparing the listing of the secret keys in your .gnupg and your /media/encrypted-usb/.gnupg/ dir.

$ gpg -K 0x6F87F32E2234961E                                             
sec#   4096R/0x6F87F32E2234961E 2013-12-01
uid                            foo bar <foobar@riseup.net>
uid                            foo bar <foobar@void.gr>
ssb   4096R/0xD3DCB1F51C37970B 2013-12-01
ssb   4096R/0x296B12D067F65B03 2013-12-01 [expires: 2018-11-30] 

$ gpg --home=/media/encrypted-usb/.gnupg/ -K 0x6F87F32E2234961E                                             
sec   4096R/0x6F87F32E2234961E 2013-12-01
uid                            foo bar <foobar@riseup.net>
uid                            foo bar <foobar@void.gr>
ssb   4096R/0xD3DCB1F51C37970B 2013-12-01
ssb   4096R/0x296B12D067F65B03 2013-12-01 [expires: 2018-11-30] 

Notice the pound (#) in the ‘sec’ line from your ~/.gnupg/. That means that the master key is missing.

Upload your new key to the keyservers if you want to…

Key Migration
In case you’re migrating from an older key you need to sign your new key with the old one (not the other way around!)
$ gpg --default-key 0xOLD_KEY --sign-key 0x6F87F32E2234961E

Write a transition statement and sign it with both the old and the new key:

$ gpg --armor -b -u 0xOLD_KEY -o sig1.txt gpg-transition.txt
$ gpg --armor -b -u 0x6F87F32E2234961E -o sig2.txt gpg-transition.txt

That’s about it…upload the transition statement and your signatures to some public space (or mail it to your web of trust).

Signing other people’s keys
Because your laptop’s keypair does not have the master key anymore and the master key is the only one with the ‘C’ flag, when you want to sign someone else’s key, you will need to mount your encrypted USB and then issue a command that’s using that encrypted directory:
$ gpg --home=/media/encrypted-usb/.gnupg/ --sign-key 0xSomeones_keyid
Export your signature and send it back to people whose key you just signed..

Things to play with in the future
Next stop ? An OpenPGP Smartcard! (eshop) or a yubikey NEO, (related blogpost). Any Greeks want to join me for a mass (5+) order?

References
https://wiki.debian.org/subkeys
https://help.riseup.net/en/security/message-security/openpgp/best-practices
https://alexcabal.com/creating-the-perfect-gpg-keypair/

P.S. 0x6F87F32E2234961E is obviously just a demo key. You can find my real key here.
P.S.2 The above commands were executed on gpg 1.4.12 on Debian Wheezy. In the future the output of the commands will probably differ.

Filed by kargig at 13:07 under Encryption,Internet,Linux,Networking,Privacy
Tags: debian, encrypted usb, Encryption, gpg, keyring, master key, pgp, private, public, signing, subkeys, wheezy
14 Comments | 241,782 views