Conceptes/Primers passos amb OpenPGP
Introducció
Quan es crea una clau, prendreu diverses decisions tècniques i d'organització (si sou o no conscient), que influeixen en gran mesura sobre la seguretat i usabilitat de la vostra clau, resultant en la vida útil de la clau. Algunes d'aquestes decisions no es podran canviar després. Per diverses raons, és desitjable que les claus normals -fins i tot les més insegures- (almenys el seu nucli) disposin d'una vida útil llarga.
De manera que el present article us familiaritzarà amb els aspectes importants de la generació de claus i us ajudarà a generar una bona clau que podreu utilitzar durant molts anys. Aquest article només cobreix els conceptes que heu de conèixer, no conté una guia d'aprenentatge pas a pas per a la generació de claus, atès que han de ser fases diferents: En primer lloc entendre i planejar el que fareu i fer els preparatius necessaris. Si heu acabat, feu una ullada a l'article Generar claus OpenPGP.
Com començar
Podeu crear amb facilitat una clau per jugar una estona. Però si permeteu que els altres verifiquin la clau, us arrisqueu a llençar el treball més tard. El vostre objectiu ha de ser la creació d'una o diverses claus de vida llarga. El millor consell és: No ho intenteu tot sol si ho podeu evitar. Contacteu amb els que tenen experiència, les persones que ja han substituït una clau pròpia i apreneu-ne. Utilitzeu un sistema segur per a crear una clau, utilitzeu una clau principal estan desconnectats i doneu tant a la clau principal com a les subclaus una data de caducitat (no més d'un any). Seleccioneu una política per a la clau (que descrigui la seguretat i l'ús de la clau principal i de les subclaus) i manteniu-la estrictament. Si certifiqueu altres claus abans de tenir una política de certificació, no se certificarà per al públic (web de confiança), en comptes d'això, creeu signatures locals (no exportables). Eviteu fer coses noves abans d'entendre bé el que signifiquen.
I recordeu això:
- El que és còmode (gairebé sempre) sempre posa en perill la vostra seguretat.
- Més seguretat no sempre és millor per a la tasca encomanada. No obstant, tingueu en compte les conseqüències (en ambdues direccions).
Benvingut al món de la criptografia!
Seguretat de la clau
Si es tracta de claus, llavors la pregunta principal és: Com de segures / fiables són i el seu ús? La regla més important de la criptografia no és «fer que sigui encara més segur», però «(1) Penseu en la quantitat de seguretat que necessiteu. (2) Decidiu quin esforç tècnic sembla necessari (límit inferior) i raonable (límit superior) per complir amb aquests requisits. (3) Observeu estrictament les regles establertes (anoteu-les). (4) Si hi estan involucrades altres persones (sol ser el cas), que sàpiguen amb precisió i seguretat quins són els límits d'ús i el nivell de seguretat d'aquesta clau». La majoria de les següents consideracions tracten sobre la seguretat i la transparència de la seva seguretat i el seu significat.
Ningú peta les claus amb atacs de força bruta. Això és (fins i tot per a les claus curtes, diguem 1024 bits) simplement impossible per a tothom per sota del nivell d'una agència governamental en un país «ric», almenys durant les pròximes dècades. I no tindria sentit: És molt més fàcil robar-les. Probablement, el sistema que esteu utilitzant per llegir aquest text (si no l'heu imprès...) no és molt segur. De fet, no existeix un sistema segur per llegir el correu electrònic o les pàgines web. No cal discutir, simplement accepteu-ho. Si no ho feu, el més probable és que només us comprometeu. Una clau mai és més segura que el sistema menys segur sobre el qual s'ha utilitzat (això, per descomptat, inclou: creació). I és més segura que el sistema menys segur sobre el que s'ha emmagatzemat, només per la seva frase de contrasenya, la qual no està protegida contra un atac de força bruta, si no és realment aleatòria o amb menys de 16 caràcters de longitud (lletres minúscules/majúscules i dígits).
És perfectament correcte utilitzar OpenPGP en sistemes segurs (és a dir, ordinadors normals). Vosaltres i els vostres companys de comunicació(!) haureu de tenir en compte el nivell de seguretat. El següent nivell de seguretat són les targetes intel·ligents. No es pot robar una clau d'una targeta intel·ligent (se'n pot abusar, si algú obté el control del sistema al qual està connectat la targeta intel·ligent). El següent nivell després de les targetes intel·ligents són els sistemes segurs: Desconnecteu el vostre disc dur, tots els dits USB (i similars) i la xarxa, arrenqueu des d'un mitjà segur com un DVD Live de Linux (d'una font de confiança, és clar). En un entorn tan segur, utilitzeu només claus de seguretat alta (i potser fins i tot limitat a formats de document no perillosos com text pla o HTML).
La clau principal i les subclaus
La majoria de les claus OpenPGP almenys tenen una subclau (totes tenen exactament una clau principal). La majoria de las vegades, no us haureu de preocupar per aquesta diferència. La vostra aplicació (o més aviat, l'aplicació base, habitualment GnuPG) selecciona la més adequada de forma automàtica. La clau principal és a la que es refereix l'empremta digital, i només pot certificar la clau principal: les vostres pròpies subclaus, els ID d'usuari i els ID d'usuari d'altres claus. Les subclaus poden fer tota la resta (sobretot el desencriptatge i la signatura) si les configureu d'aquesta manera. La raó de la diferència entre aquests tipus de clau s'esmenta aquí, atès que això és molt important per a la generació de la clau: Podeu separar la clau principal secreta de les subclaus secretes (amb GnuPG, això no forma part de l'estàndard OpenPGP). Després podreu substituir les subclaus, no així la clau principal (la qual seria una nova clau, no només una clau modificada). Per tant, si creeu una clau principal fora de línia durant la generació de claus, protegida mitjançant una contrasenya molt dura, deseu almenys la frase de contrasenya de forma segura i utilitzeu la clau principal (i la seva contrasenya) només en entorns segurs, després podreu mantenir aquesta clau «per sempre» (per exemple, 20 anys). Això és important per a les claus de cada dia. Les claus de seguretat alta en realitat no necessiten aquesta separació (en general, les subclaus no calen en absolut). Haureu de crear una subclau per a cada capacitat que necessiteu: encriptatge, signatura i potser autenticació (per SSH).
Entorn segur
La clau es generada en un entorn segur i la clau secreta principal mai s'utilitza en un entorn insegur. Però, què és un entorn segur? Això depèn del nivell de seguretat de la clau. Si voleu protegir els codis de llançament d'armes nuclears, tindreu més requeriments sobre el maquinari i el programari implicat, que si el que voleu és mantenir en secret el vostre romanç.
En qualsevol cas no heu d'arrencar des del disc dur (l'ideal és desconnectar-lo), feu-ho des d'algun mitjà fiable de només lectura. Això sol ser un Linux CD/DVD. Haureu de pagar per obtenir-lo d'una font segura. Simplement descarregant alguna imatge des d'Internet i gravant-la en un suport en blanc no tindreu un entorn segur. En general, utilitzar un CD/DVD imprès (per exemple, d'una revista o comprat pel vostre compte) sembla més digne de confiança.
El maquinari també és important. Si utilitzeu un sistema que ja se sap que s'utilitza per a la generació de claus valuoses, a algú li podria agradar la idea d'afegir-hi un capturador de teclat. Poseu atenció en els atacs més trivials: Eviteu que ningú us vegi quan escriviu la contrasenya (fins i tot a través de les finestres) i el vostre paper amb la contrasenya. Reinicieu el sistema després de la creació de la clau o (millor), apagueu-lo i manteniu-lo així durant tres minuts.
Els ID d'usuari
Els ID d'usuari formalment només són cadenes arbitràries però s'espera que constin d'un nom, un comentari opcional, i una adreça de correu electrònic. Aquesta estructura permet que el programari de correu electrònic cerqui la clau adequada per a una adreça de destinatari (que la majoria dels programes requereixen que confirmeu per raons òbvies). Una clau pública OpenPGP (més precís: certificat) ha de contenir un ID d'usuari, però pot contenir-ne tants com vulgueu. Per tant, podeu utilitzar la mateixa clau per a diverses adreces de correu electrònic (el que només té sentit si aquestes adreces s'utilitzen en el mateix nivell de seguretat). La combinació d'adreces té avantatges i desavantatges. El principal avantatge és que es necessitareu menys claus i per tant tothom tindrà menys feina amb les certificacions. Els principals desavantatges són que podeu revocar els ID d'usuari però mantenir-los sempre visibles, i una clau combinada permet fer connexions trivials entre diferents rols amb els que és possible que no vulgueu connectar: persona privada, empresa, altres organitzacions (associacions, partits polítics, el que sigui). És possible que vulgueu mantenir aquests grups per separat. Fins i tot hi ha raons per mantenir separades les adreces del mateix grup: adreces de reconegut prestigi (nom.cognom@example.com), adreces anònimes (laura7u@exemple.org), adreces divertides (superman17@exemple.org). També podríeu no tenir cap raó per utilitzar mai OpenPGP amb certes adreces. Aquestes adreces no han de perquè formar part d'un ID d'usuari. La decisió d'afegir una adreça a una clau i publicar-la és per sempre. Però és fàcil afegir una adreça més endavant. Per tant, considereu-ho bé abans de generar la clau. En cas de dubte comenceu amb menys adreces.
No té sentit tenir una ID d'usuari especial sense una adreça de correu electrònic. Amb la majoria de les adreces de correu electrònic no estareu segur de tenir-los per sempre. Si revoqueu una ID d'usuari, ja que no utilitzareu més l'adreça, llavors perdreu totes les certificacions per aquesta ID d'usuari. Però mai perdreu el vostre nom (fins i tot si us caseu o similars, generalment hi ha poques raons per revocar la ID d'usuari). De manera que en tot cas manteniu les certificacions per aquesta ID. I podeu utilitzar el comentari per a aquesta ID d'una declaració sobre la clau: «Clau diària amb clau principal i política de la clau desconnectada».
Tipus i longitud de la clau
Els tipus de claus amb una àmplia implementació són DSA (només les signatures), ElGamal (només l'encriptatge) i RSA (ambdós). Aviat s'afegirà ECDSA (utilitzant corbes el·líptiques). GnuPG ofereix la creació de claus amb una longitud de 1024 a 4096 bits. Aquesta és la situació actual (any 2013).
Les diferències en la seguretat, el temps d'execució, la mida de la signatura, i el compromís o la conveniència de certs requisits fonamentals de la norma (rfc4880) són irrellevants per a la majoria dels escenaris. L'única diferència rellevant és la següent: La targeta intel·ligent g10 només implementa RSA. Per tant, llevat que hi hagi una raó específica i important per triar un tipus de clau diferent, hem de donar prioritat a la creació de claus RSA. Les claus de 1024 bits són considerades fràgils per certs organismes governamentals avui o en un futur pròxim. Les claus de 2048 bits es consideren segures durant dècades. Però recordeu: Aquestes agències no perdran el seu temps i diners en calcular la vostra clau. És més fàcil robar-la. Per tant, si voleu una clau més llarga, ja que voleu protegir institucions d'aquest nivell, haureu de tenir cura que la clau serà difícil de robar. Això, evidentment, requereix un profund coneixement, disciplina i, probablement, una quants calers. Les raons pràctiques contra claus molt llargues són: les versions utilitzades habitualment en GnuPG no implementen claus amb una longitud superior a 2048 o 3072 bits. Les operacions amb claus asimètriques són costoses, en general. Per empitjorar les coses: L'augment doble de la mida de la clau prendrà vuit vegades més de temps per a processar-la. I es necessita molt temps per a generar claus enormes. Per a dispositius mòbils, aquesta càrrega de la CPU pot arribar a ser un problema important.
Per tant: A menys que tingueu una concreta i bona raó per a prendre una decisió diferent, utilitzeu claus de 2048 bits (almenys per a les claus d'ús quotidià).
Venciment de la clau
Es pot establir (i modificar) la data de venciment per a la clau principal i les seves subclaus. L'únic «desavantatge» -per als altres- d'una data de venciment és que han d'actualitzar la clau per a mantenir-la usable. Però de totes maneres les claus s'actualitzen periòdicament, així que també ho podeu considerar un avantatge. El principal avantatge d'una data de venciment (per a la clau principal) és que les claus que no s'utilitzen es poden reconèixer més fàcilment com a tals. La forma «oficial» és una altra, per descomptat. Si una clau és abandonada, llavors s'ha de publicar un certificat de revocació. Però això pot ser impossible (s'ha perdut la clau o la contrasenya, o no s'ha creat anteriorment un certificat -o també s'ha perdut-) o potser simplement us oblideu de fer-ho (o de publicar-lo en algun lloc). El període de validesa «correcte» és un compromís entre la reducció de la pertorbació per a les claus que han expirat (en ambdós costats, recordeu que necessiteu un entorn segur per a canviar la data de venciment amb una clau principal fora de línia) i el temps que una clau encara serà vàlida. Un any pot ser una bona opció.
Certificat de revocació
Un certificat de revocació és un fitxer (o còpia impresa), que podeu crear de forma preventiva per a revocar posteriorment tota una clau en cas de no tenir accés més a la clau principal secreta. Aquest és un gran avantatge si perdeu l'accés a la clau, però algú més hi ha accedit! El desavantatge és: Haureu de protegir el fitxer/impressió de forma similar, així com la pròpia clau principal secreta. La seva pèrdua pot causar un dany significatiu si només teniu una clau (adequat), la necessiteu amb urgència i algú la destrueix en aquest moment. És evident que una revocació de la clau principal és per sempre (no es pot substituir per una auto-signatura més recent).
If you (or someone else you really trust) have another key which is secure enough then you may add this key as a designated revoker to yours (you need not publish this). A designated revoker can revoke another key. Of course, the signature for the designated revoker must be available when this shall be used. If you have not given it to the other person and lost it together with your key then this is useless. If you prefer security over availability then you may make friend A your designated revoker, encrypt this signature for friend B and ask friend C to store it.
Frase de contrasenya, emmagatzematge segur i còpia de seguretat
You should think about where you will store the passphrase for the main key and the revocation certificate file or print-out. Secure passphrases are hard to remember. You will most probably have to write it down. You really should not use a passphrase you have ever typed on an insecure system (and, of course, you really should not ever do so in the future). You should choose something like rsbBwNl137LcWP33RI: 18 chars consisting of lower and upper case letters and digits. Don't use special chars or umlauts. You gain little security (if you cannot remember 18 random chars then you probably cannot remember 15, too) but may get problems if you are ever forced to use the key on a rescue system (text mode Linux) with "wrong" keyboard settings. You improve security if you memorize a part of the passphrase and write down just the rest or if you write down both halves of it separately and store them in different places (one in your wallet, the other one at home). But if you store an 18 chars passphrase in two parts and an attacker gets one of them then the remaining 9 chars are not a secure protection any more. If you have created a revocation certificate then you have to store that in a safe place, too.
And, of course, you should have reliable backups of your key. It is nice if you need not be afraid that somebody has stolen your key but it is probably very unpleasant if you cannot decrypt your data any more. If you have a secure passphrase then you may even put a backup of your secret main key on your web site.
Política de la clau i política de l'URL
You should write a document (plain text or HTML) which describes the intended usage and security of your key and (maybe added later) your criteria for certifying the keys of other people. You can write one or more URLs at which this document can (later) be found into the key and in every signature you make. This key component is called a policy URL. It is a good idea to publish only user ID signatures which contain this policy URL(s). It is important that the users of your key can check whether a certain document belongs to a policy URL (the web server download is not safe, not even over HTTPS). Thus you should change the policy URL every time you change the document and mention the URL well visible in the document. You may use this pattern: http://yourdomain.example.org/openpgp/0x12345678__policy.1.html This document should have a detached signature (or a cleartext signature if it is plain text) by the offline main key. You should link the detached signature from the document.
Servidor de claus preferit
Like the policy URL a key server URL can be written into the key. You should decide which key server shall be authoritative for your key so that the users of your key know where they have to search for the "officially current version" of your key. This should be the key server which you upload key updates to first. This should be the one you configure in the GnuPG config file (--keyserver) for key searches and uploads. This address should mainly be available for a long time and have only few and short outages. You may even use your own web site: http://yourdomain.example.org/openpgp/0x12345678.asc
Availability is improved if a server pool (with the same DNS address) is used. If you have no better idea then you may use hkp://pool.sks-keyservers.net or one of the more local pools hkp://eu.pool.sks-keyservers.net (Europe), hkp://na.pool.sks-keyservers.net (North America) or hkp://sa.pool.sks-keyservers.net (South America). See http://sks-keyservers.net/overview-of-pools.php
Preferències de l'algorisme
You can also write into your key (for others) and into your config file (for your actions) in which order you prefer the cipher and digest algorithms. You should do this before you generate the key (this is easier than changing it afterwards). It makes sense to avoid SHA-1. Please be aware that you cannot prevent that GnuPG creates SHA-1 signatures with your key (because that is the only digest required by the standard). You may want to put lines like these in your gpg.conf:
personal-cipher-preferences AES256,AES192,AES,CAST5,3DES personal-digest-preferences SHA512,SHA384,SHA256,SHA224,RIPEMD160,SHA1 cert-digest-algo SHA512 default-preference-list AES256,AES192,AES,CAST5,3DES,SHA512,SHA384,SHA256,SHA224,RIPEMD160,SHA1,ZLIB,BZIP2,ZIP