Concepts/OpenPGP Getting Started/ca

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ò:

1. El que és còmode (gairebé sempre) sempre posa en perill la vostra seguretat.
2. 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 desencriptat 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).

The differences in security, execution time, signature size, and being required or just considered optional by the standard (rfc4880) are irrelevant for most scenarios. The one relevant difference is: The g10 smartcard supports RSA only. Thus generate an RSA key unless you have concrete and good reason for a different decision. 1024 bit keys are considered breakable by certain well known government agencies today or in the near future. 2048 bit keys are considered safe for decades. But remember: These well known agencies would not waste their time and money by computing your key. They would steal your key. Thus if you want a larger key in order to be safe against this kind of opponent then make sure that they cannot steal it. This obviously requires profound knowledge, discipline and probably some money. The practical reasons against very long keys are: Commonly used versions of GnuPG do not support keys with more than 2048 or 3072 bit respectively length. Operations with asymmetric keys are costly in general. To make it worse: Operation with twice the key size take eight times as long. And it takes long to generate huge keys. For mobile devices this CPU load can become a problem.

Thus: Unless you have concrete and good reason for a different decision stick to 2048 bit (at least for everyday keys).

Venciment de la clau

The main key can set (and change) the expiration date for itself and its subkeys. The only "disadvantage" of an expiration date for others is that they have to update the key to keep it usable. But keys shall be updated regularly anyway so you may consider that an advantage as well. The main advantage of an expiration date (for the main key, too) is that keys which are not used any more can easily be recognized as such. The "official" way is another, of course. If a key is abandoned then a revocation certificate should be published. But this may be impossible (key or passphrase lost and no certificate created before (or lost, too)) or you may simply forget to do so (or to publish it everywhere). The "right" validity period is a compromise between reducing disturbance by expired keys (on both sides; remember that you need a secure environment to change the expiration date with an offline main key) and the time which a key still appears valid. One year may be a good choice.

Certificat de revocació

A revocation certificate is a file (or print-out) which you may create preventively to later revoke a whole key in case you have no access to the secret main key any more. This is a huge advantage if you have not just lost access to the key but someone else has! The disadvantage is: You should protect this file / print-out similarly well as the secret main key itself. It can be serious damage if you have only one (suitable) key, need it urgently and someone else destroys it right then. Obviously a main key revocation is forever (cannot be superseded by a newer self-signature).

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

Altres lectures

• KGpg

• KMail PGP/MIME

• KMail gpg

• OpenPGP per a novells

• OpenPGP per a usuaris avançats