Concepts/OpenPGP Getting Started/da: Difference between revisions

From KDE UserBase Wiki
(Importing a new version from external source)
No edit summary
 
(42 intermediate revisions by 2 users not shown)
Line 43: Line 43:




== User IDs ==
== Bruger-ID'er ==


User IDs are formally just arbitrary strings but expected to consist of a name, an optional comment, and an email address. This structure allows email software to find the suitable key for a recipient address (which most programs require you to confirm for obvious reasons). An OpenPGP public key (more precise: certificate) must have a user ID but can have as many as you like. Thus you can use the same key for several email addresses (which makes sense only if these addresses shall be used at the same security level). Combining addresses has advantages and disadvantages. The main advantage is that you need less keys and thus you and others have less work with certifications. The main disadvantages are that you can revoke user IDs but they keep visible forever and that such a combined key allows to make a trivial connections between different roles of you which you may not want connected: private person, business, other organizations (associations, political parties, whatever). You may want to keep these groups separate. And there are even reasons to keep addresses from the same group separate: reputable addresses (firstname.lastname@example.com), anonymous addresses (heejei7u@example.org), fun addresses (superman17@example.org). It also may be that you have no reason to ever use OpenPGP with certain addresses; such addresses should not be part of a user ID, of course. The decision to add an address to a key and publish that key is forever. But it is easy to add an address later. Thus consider this well before you generate the key. In case of doubt start with fewer addresses.
Formelt set er bruger-ID'er blot vilkårlige strenge, men de forventes at bestå af et navn, evt. en kommentar samt en e-mail-adresse. Denne struktur lader e-mail-programmer finde den rette nøgle hørende til en modtager-adresse (som de fleste programmer vil bede dig om at bekræfte af indlysende grunde). En OpenPGP offentlig nøgle (mere præcist: certifikat) skal have et bruger-ID og kan have så mange du ønsker. Du kan således bruge den samme nøgle til flere e-mail-adresser (hvilket kun giver mening, hvis modtagerne skal bruges på samme sikkerhedsniveau). Der er fordele og ulemper ved at kombinere adreser. Den vigtigste fordel er, at du ikke skal bruge så mange nøgler, sådan at du og andre har mindre arbejde med certificering. De vigtigste ulemper er, at du kan tilbagekalde bruger-ID'er, men de forbliver synlige for altid og at sådan en kombineret nøgle gør det muligt at foretage en simpel forbindelse imellem dine forskellige roller, som du måske ikke ønsker at få knyttet sammen: privatperson, forretning og andre organisationer (foreninger, politiske partier med mere). Det kan være en god idé at holde disse grupper adskilt. Der er endda grunde til at holde forskellige adresser til samme organisation adskilt: ordentlige adresser (fornavn.efternavn@eksempel.com), anonyme adresser (heejei7u@eksempel.org) og sjove adresser (superman17@eksempel.org). Det kan også være, at du aldrig har anledning til at anvende OpenPGP med visse adresser: Sådanne adresser bør selvfølgelig ikke indgå i noget bruger-ID. Beslutningen om at føje en adresse til en nøgle er uigenkaldelig. Men det er nemt at tilføje en adresse på et senere tidspunkt. Overvej derfor dette nøje før du genererer nøglen. Hvis du er i tvivl, så start med færre adresser.


It makes sense to have a special user ID without an email address. With most email addresses you cannot be sure to have them forever. If you revoke a User ID because you don't use the address any more then you lose all the certifications for this user ID. But you will never lose your name (even if you marry or the like there is usually little reason to revoke that user ID). So you keep the certifications for this ID at any rate. And you can use the comment for this ID for a statement about the key itself: "everyday key with secure offline main key and key policy"
Det giver god mening at have en bruger-ID uden en e-mail-adresse. For de fleste e-mail-adresser kan du ikke være sikker på at bevare dem altid. Hvis du tilbagekalder et bruger-ID fordi du ikke bruger adressen mere, så mister du alle certificeringerne af dette bruger-ID. Men du vil aldrig miste dit navn (selv hvis du gifter dig eller lignende er der ingen grund til at tilbagekalde dette bruger-ID). Du bevarer så certificeringerne af dette ID under alle omstændigheder. Og du kan bruge kommentaren til dette ID til en erklæring om nøglen selv: "hverdagsnøgle med sikker offline nøgle og nøglepolitik".




== Key type and length ==
== Nøgletype og længde ==


The well supported key types are DSA (signatures only), ElGamal (encryption only) and RSA (both); ECDSA (elliptic curves) is going to be added soon. GnuPG offers the creation of keys with a length from 1024 to 4096 bit. This is the current situation (2013).
De velunderstøttede nøgletyper er DSA (kun signaturer), ElGamal (kun kryptering) og RSA (begge) og ECDSA (elliptiske kurver). GnuPG gør det muligt at oprette nøgler med længder fra 1024 til 4096 bit (pr. aug. 2020).


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.
Forskellene i sikkerhed, udførelsestid, signaturstørrelse og om de er obligatoriske eller blot betragtes som valgfri af standarden  (rfc4880) er irrelevante i de fleste situationer. Den eneste relevante forskel er: g10-smartcardet understøtter kun RSA. Du bør således generere en RSA-nøgle medmindre du har en konkret, god grund til at vælge en anden løsning. 1024 bit nøgler menes at kunne brydes af visse regeringsorganer nu eller i den nærmeste fremtid. 2024 bit-nøgler anses for sikre i flere årtier. Men husk: Disse velkendte regeringsorganer ville ikke spilde deres tid med at bryde dine nøgler; de ville stjæle dem. Hvis du derfor ønsker en større nøgle for at sikre dig imod den slags modstandere, så sørg for, at de ikke kan stjæle dem. Dette kræver selvfølgelig dyb viden, disciplin og nok også penge. Den praktiske grund til ikke at bruge meget lange nøgler er: Almindeligt anvendte udgaver af OpenPGP understøtter ikke nøgler som er længere end 2048 hhv. 3072 bit. Operationer med asymmetriske nøgler er generelt krævende. Og for at gøre tingene værre, så kræver operation med dobbelt så lang en nøgle otte gange så lang tid. Og det tager også lang tid at generere meget lange nøgler. For mobile enheder kan denne belastning blive et problem.


Thus: Unless you have concrete and good reason for a different decision stick to 2048 bit (at least for everyday keys).
Medmindre du altså har konkrete, gode grunde til en anden beslutning, så hold dig til 2048 bit (i hvert fald til hverdagsnøgler).


== Nøgleudløb ==


== Key expiration ==
Hovednøglen kan fastsætte (og ændre) sin egen og sine undernøglers udløbsdato. Den eneste "ulempe" ved en udløbsdato for andre er, at de skal opdatere nøglen for at den skal forblive brugbar. Men nøgler bør alligevel opdateres regelmæssigt, så man kan også betragte dette som en fordel. Den vigtigste fordel ved en udløbsdato (også for hovednøglen) er, det er let at se om en nøgle ikke længere er i brug. Der er også en "officiel" måde at opnå dette på. Hvis en nøgle opgives, så bør der udgives et tilbagekaldelsescertifikat. Men det kan være umuligt (hvis nøgle eller kodeord er gået tabt og der ikke tidligere er blevet oprettet et certifikat (eller det også er gået tabt)) eller du kan glemme at gøre det (eller at offentliggøre det overalt). Den "rette" gyldighedsperiode er et kompromis imellem at reducere forstyrrelser fra udløbne nøgler (på begge sider: husk at du skal bruge sikre omgivelser for at ændre udløbsdatoen med en offline hovednøgle) og den tid, hvor nøglen stadig optræder som gyldig. Et år kan være et godt valg.


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.


== Tilbagekaldelsescertifikat ==


== Revocation certificate ==
Et tilbagekaldelsescertifikat er en fil (eller en udskrift), som du kan oprette preventivt, for senere at kunne tilbagekalde en hel nøgle hvis du ikke længere har adgang til den. Dette er en kæmpe fordel hvis du ikke længere har adgang til nøglen men en anden har! Ulempen er: du skal beskytte denne fil eller udskrift lige så godt som den hemmelige hovednøgle. Det kan give store problemer, hvis du kun har én (passende) nøgle og har presserende brug for den og en anden så ødelægger den lige på det tidspunkt. Det er klart, at tilbagekaldelse af en hovednøgle er endegyldig (det kan ikke ændres med en senere selvsignering).


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).
Hvis du (eller en, som du virkelig stoler på) har en anden nøgle, som er sikker nok, så kan du tilføje den nøgle til dine nøgler som udpeget tilbagekalder (du behøver ikke at offentliggøre dette). En udpeget tilbagekalder kan tilbagekalde en anden nøgle. Den udpegede tilbagekalders signatur skal selvfølgelig være til stede, når den skal bruges. Hvis du ikke har givet den til den anden og tabt den sammen med din nøgle, så nytter dette ikke noget. Hvis du vægter sikkerhed over tilgængelighed, så kan du gøre din ven A til udpeget tilbagekalder, kryptere signaturen til din ven B og bede din ven C om at gemme den.


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.


== Adgangskoder, sikker opbevaring og backup ==


== Passphrase, safe storage, and backup ==
Du bør tænke over, hvor du vil gemme hovednøglens adgangskode og filen med eller udskriften af genkaldelsescertifikatet. Sikre adgangskoder er vanskelige at huske. Du bliver nok nødt til at skrive det ned. Du bør virkelig undgå at bruge en adgangskode, som du nogensinde har skrevet på et usikkert system (og du bør selvfølgelig heller aldrig gøre det i fremtiden). Vælg noget i retning af rsbBwNl137LcWP33RI: 18 tegn bestående af små og store bogstaver og tal. Brug ikke specielle tegn eller accenter. Du vinder ikke meget i sikkerhed (hvis du ikke kan huske 18 tilfældige tegn kan du nok heller ikke huske 15), men kan komme i problemer hvis du nogensinde bliver nødt til at bruge nøglen på et gendannelsessystem (Linux i teksttilstand) med de forkerte tastaturindstillnger. Du øger sikkerheden, hvis du kan memorere en del af adgangskoden og blot nedskriver resten eller hvis du nedskriver de to halvdele hvert sit sted og gemmer dem forskellige steder (det ene i din pung og det andet derhjemme). Men hvis du gemmer en adgangskode på 18 tegn i to dele og en angriber får fat på den ene, så er der kun 9 ukendte tegn tilbage og det er ikke længere en sikker beskyttelse. Hvis du har oprettet et genkaldelsescertifikat, så skal du også gemme det et sikkert sted.


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 sage place, too.
Og selvfølgelig bør du have et pålideligt backup af din nøgle. Det er rart ikke at skulle være nervøs for, at nogen har stjålet din nøgle, men det vil formentlig være ret ubehageligt hvis du ikke kan dekryptere dine data længere. Hvis du har en sikker adgangskode, så kan du endda lægge en kopi af din hemmelige hovednøgle på dit websted.


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.


== Nøglepolitik og politik-URL ==


== Key policy and policy URL ==
Du bør lave et dokument (i ren tekst eller html), som beskriver nøglens tilsigtede anvendelse og sikkerhed samt dine kriterier for at certificere andre (disse kan evt. tilføjes senere). Du kan angive et eller flere URL'er, hvor dette dokument (senere) kan findes i nøglen og i enhver signatur du laver. Denne komponent af nøglen kaldes en politik-URL. Det er en god idé at ikke at udgive bruger-ID-signaturer uden politik-URL'er. Det er vigtigt at brugerne af dine nøgler kan tjekke om et givet dokument hører til en politik-URL (download fra en webserver er ikke sikkert, ikke engang over HTTPS). Du bør således ændre politik-URL'en hver gang du ændrer dokumentet og nævne URL'en på et meget synligt sted i dokumentet. Du kan bruge dette mønster: <tt><nowiki>http://ditdomæne.eksempel.org/openpgp/0x12345678__politik.1.html</nowiki></tt>. Dette dokument bør have en fritstående signatur (eller en signatur i klar tekst hvis det er et rent tekstdokument) med hovednøglen, som er offline. Du bør linke til den fritstående signatur fra dokumentet.


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.


== Foretrukken nøgleserver ==


== Preferred key server ==
Ligesom med politik-URL'en kan man også angive en nøgleserver-URL i nøglen. Du bør beslutte, hvilken nøgleserver der skal være autoritativ for din nøgle, sådan at din nøgles brugere ved, hvor de kan finde den "officielt, aktuelle version" af din nøgle. Det bør være den nøgleserver, som du først uploader nøgleopdateringer til og den, som du angiver i GnuPG's konfigurationsfil (<code>--keyserver</code>) til søgning og upload af nøgler. Denne adresse bør først og fremmest være tilgængelig i lang tid og kun have få og korte udfald. Du kan endda bruge dit eget websted: <tt><nowiki>http://ditdomæne.eksempel.org/openpgp/0x12345678.asc</nowiki></tt>.


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
Tilgængeligheden forbedres, hvis du bruger en serverpool (med samme DNS-adresse). Hvis du ikke har en bedre idé, så kan du bruge <tt>hkp://pool.sks-keyservers.net</tt> eller en af den mere lokal pools <tt>hkp://eu.pool.sks-keyservers.net</tt> (Europa), <tt>hkp://na.pool.sks-keyservers.net</tt> (Nordamerika) eller <tt>hkp://sa.pool.sks-keyservers.net</tt> (Sydamerika). Se http://sks-keyservers.net/overview-of-pools.php


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


== Indstillinger for algoritmer ==


== Algorithm preferences ==
Du kan også skrive i din nøgle (til andre) og i din konfigurationsfil (til dine handlinger) i hvilken orden du foretrækker kodnings- og sammenfatningsalgoritmer. Du bør gøre dette før du genererer nøglen (dette er lettere end at ændre den efterfølgende). Det er en god idé at undgå SHA-1. Vær opmærksom på, at du ikke kan forhindre GnuPG i at generere SHA-1-signaturer med din nøgle (fordi det er den eneste sammenfatning, som standarden kræver). Du kan evt. indskrive følgende linjer i din fil <tt>gpg.conf</tt>:


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 (due to design flaws AES256 and AES192 are less secure than AES(128) is currently believed to be...):
  {{Input|1=<nowiki>personal-cipher-preferences AES256,AES192,AES,CAST5,3DES
 
personal-digest-preferences SHA512,SHA384,SHA256,SHA224,RIPEMD160,SHA1
  {{Input|1=<nowiki>
cert-digest-algo SHA512
personal-cipher-preferences AES,AES256,AES192,CAST5,3DES
default-preference-list AES256,AES192,AES,CAST5,3DES,SHA512,SHA384,SHA256,SHA224,RIPEMD160,SHA1,ZLIB,BZIP2,ZIP </nowiki>}}
personal-digest-preferences SHA512,SHA384,SHA256,SHA224,RIPEMD160,SHA1
cert-digest-algo SHA512
default-preference-list AES,AES256,AES192,CAST5,3DES,SHA512,SHA384,SHA256,SHA224,RIPEMD160,SHA1,ZLIB,BZIP2,ZIP
</nowiki>}}


== Videre læsning ==
== Videre læsning ==
Line 118: Line 115:
[[Category:Sikkerhed/da]]
[[Category:Sikkerhed/da]]
[[Category:Vejledning/da]]
[[Category:Vejledning/da]]
[[Category:Ny bruger/da]]
[[Category:Nye brugere/da]]

Latest revision as of 07:06, 12 September 2020

Other languages:

Introduktion

Når du opretter en nøgle er der adskillige tekniske og organisatoriske beslutninger (hvad enten du er opmærksom på dem eller ej), som vil have stor indflydelse på, hvor sikker og nyttig din nøgle er som et resultat af dens operative liv. Nogle af disse beslutninger kan ikke ændres efterfølgende. Af forskellige grunde er det ønskværdigt, at normale nøgler (i det mindste deres kerne) har et langt operativt lig, selv hvis de er ret usikre.

Denne artikel skal således gøre dig fortrolig med de vigtige aspekter af nøglegenerering og hjælpe dig med at generere en god nøgle, som kan bruges i mange år. Denne artikel omhandler kun de begreber, som du bør være fortrolig med; den indeholder ikke en skridt for skridt-vejledning i nøglegenerering, for disse bør være adskilte faser: Først forstå og planlæg hvad du vil gøre og foretag de nødvendige forberedelser. Når du er færdig med det, så kig på artiklen om OpenPGP-nøglegenerering

Hvordan du kommer i gang

Du kan let oprette en nøgle til at eksperimentere lidt med. Men hvis du lader andre verificere sådan en nøgle risikerer du at smide arbejde væk senere. Dit mål bør være at oprette en eller flere nøgler til langvarig brug. Det bedste råd er: Gør det ikke selv hvis du kan undgå det. Spørg eksperter hvis du kan, folk, som allerede selv har udskiftet en af deres egne nøgler og lært af den erfaring. Brug et sikkert system til at oprette en nøgle; brug en hovednøgle, som er offline og giv både hovednøglen og undernøglerne en udløbsdato (ikke mere end et år). Vælg en nøglepolitik (en beskrivelse af sikkerheden og brugen af hovednøglen og undernøgler) og hold fast i den. Hvis du certificerer andre nøgler før du har en certificeringspolitik, så certificér dem ikke for offentligheden (web of trust); lav i stedet lokale signaturer (kun til eget brug). Undgå at gøre noget nyt før du gar en god forståelse af, hvad det betyder.

Og husk dette:

  1. "Bekvemmelighed er (næsten) altid en trussel mod din sikkerhed."
  2. Mere sikker er ikke altid bedre til en given opgave. Vær blot opmærksom på konsekvenserne (i begge retninger).


Welkommen til krypteringens verden!


Nøgle sikkerhed

Hvis nøgler er involveret, så er hovedspørgsmålet: Hvor sikre/pålidelige er de og brugen af dem? Den vigtigste kryptografiske regel er ikke "Gør det endnu sikrere" men "(1) Tænk over, hvor meget sikkerhed du behøver. (2) Afgør, hvilken teknisk indsats der synes nødvendig (nedre grænse) og rimelig (øvre grænse) for at opfylde disse behov. (3) Følg de regler du har bestemt slavisk (skriv dem ned). (4) Hvis andre er involveret (hvilket i reglen er tilfældet), så lad dem vide præcist og sikkert, hvilke grænser for anvendelse af og sikkerhedsniveauet for disse nøgler." Det meste af det følgende er overvejelser over nøglernes sikkerhed og gennemskueligheden af deres sikkerhed og betydning.

Ingen bryder nøgler ved direkte angreb. Indenfor det næste årti er det (selv for ret korte nøgler på fx 1024 bit) ganske enkelt umuligt for alle andre end et "rigt" lands regeringsorganer. Og det giver ikke megen mening. Det er så let bare at stjæle dem. Med stor sandsynlighed er det system, hvor du læser denne tekst (hvis det ikke er printet ud...) ikke ret sikkert. I praksis er intet system som bruges til at læse e-mails eller websider sikkert. Det kan du lige så godt acceptere. Gør du det ikke, så udsætter du sandsynligvis dig selv for fare. En nøgle er aldrig mere sikker end det mindst sikre system, hvor den er blevet anvendt (herunder selvfølgelig også: oprettet). Og den er kun mere sikker end det mindst sikre system, hvor den er blevet gemt i forhold til dens adgangskode, som ikke beskytter mod direkte angreb medmindre den er virkelig tilfældig og mindst 16 tegn lang (med brug af store og små bogstaver og tal).

Det er helt O.k. at bruge OpenPGP på sådanne usikre systemer (dvs. normale computere). Du og dem du kommunikerer med skal blot være opmærksomme på sikkerhedsniveauet. Det næste sikkerhedsniveau er smartcards. Du kan ikke stjæle en nøgle fra et smartcard (du kan dog stadig misbruge det, hvis du kontrollerer systemet, som smatrcardet er forbundet til). Niveauet over smartcards er sikre systemer: Kobl din harddisk og netværket fra, fjern USB-sticks (og lignende), start op fra et sikkert medium som en Linux live DVD (fra en kilde, du har tillid til, selvfølgelig!). Brug kun nøgler med høj sikkerhed i sådanne sikre omgivelser (og måske endda kun med sikre dokumentformater som ren tekst og HTML).


Hovednøglen og undernøgler

De fleste OpenPGP-nøgler har mindst en undernøgle (de har alle præcis én hovednøgle). Som regel behøver du ikke at bekymre dig om forskellen: dit program (eller rettere det underliggende program, som regel "GnuPG") vælger automatisk den rigtige. Hovednøglen der den, som nøglens fingeraftryk refererer til, og kun hovednøglen kan certificere dine egne undernøgler og bruger-ID'er og andre nøglers bruger-ID'er. Undernøglerne kan gøre alt andet (hovedsaligt kryptering og signering) hvis du konfigurerer dem således. Årsagen til at nævne forskellen imellem disse nøgletyper er, at den har stor betydning under generering af nøgler. Med GnuPG kan du separere hovednøglen fra undernøglerne (dette er ikke en del af OpenPGP-standarden!) Undernøglerne kan senere erstattes, men det kan hovednøglen ikke (det ville være en ny nøgle, ikke blot en modificeret nøgle). Ved nøglegenereringen kan du således oprette en hovednøgle offline, som du kan beskytte med en meget stærk adgangskode, gemme i det mindste adgangskoden sikkert og så bruge hovednøglen (og dens adgangskode) i sikre omgivelser; kun således kan du beholde denne nøgle "altid" (lad os sige 20 år). Dette er vigtigt for dagligdagsnøgler. Nøgler med høj sikkerhed her egentlig ikke brug for denne adskillelse (som regel behøver du slet ikke undernøgler). Du bør oprette en undernøgle til hver af de funktioner, du har brug for: kryptering, signering og måske .autentifikation (til SSH)


Sikkert omgivelser

Nøglen skal genereres i sikre omgivelser og den hemmelige hovednøglen må aldrig bruges i usikre omgivelser. Men hvad er sikre omgivelser? Det afhænger af nøglens sikkerhedsniveau. Hvis du vil sikre kernevåbens affyringskoder, så vil du stille større krav end hvis du blot vil beskytte dit eget privatliv.

Under alle omstændigheder bør du ikke starte op fra din harddisk (ideelt set bør du koble den fra); brug i stedet et ikke-skrivbart medium, som du har tillid til. Dette er som regel en Linux-CD/DVD. Du bør være opmærksom på at få denne fra en sikker kilde. Du kan ikke lave sikre omgivelser ved blot at downloade og brænde et iso-billede fra internettet. Generelt synes en produceret CD/DVD (fx fra et blad eller købt særskilt) at være mere pålidelig.

Hardware er også vigtig. Hvis du bruger et system, som på forhånd var udset til at generere nøgler, så kan nogen have fundet på at tilføje en hardware-keylogger. Vær opmærksom på simple angreb: Sørg for at ingen kan se dig indtaste din adgangskode (heller ikke igennem et vindue) eller det stykke papir, hvor du har skrevet adgangskoden på. Genstart systemet efter oprettelsen af nøglen eller (bedre) sluk det helt og hold det slukket i tre minutter.


Bruger-ID'er

Formelt set er bruger-ID'er blot vilkårlige strenge, men de forventes at bestå af et navn, evt. en kommentar samt en e-mail-adresse. Denne struktur lader e-mail-programmer finde den rette nøgle hørende til en modtager-adresse (som de fleste programmer vil bede dig om at bekræfte af indlysende grunde). En OpenPGP offentlig nøgle (mere præcist: certifikat) skal have et bruger-ID og kan have så mange du ønsker. Du kan således bruge den samme nøgle til flere e-mail-adresser (hvilket kun giver mening, hvis modtagerne skal bruges på samme sikkerhedsniveau). Der er fordele og ulemper ved at kombinere adreser. Den vigtigste fordel er, at du ikke skal bruge så mange nøgler, sådan at du og andre har mindre arbejde med certificering. De vigtigste ulemper er, at du kan tilbagekalde bruger-ID'er, men de forbliver synlige for altid og at sådan en kombineret nøgle gør det muligt at foretage en simpel forbindelse imellem dine forskellige roller, som du måske ikke ønsker at få knyttet sammen: privatperson, forretning og andre organisationer (foreninger, politiske partier med mere). Det kan være en god idé at holde disse grupper adskilt. Der er endda grunde til at holde forskellige adresser til samme organisation adskilt: ordentlige adresser ([email protected]), anonyme adresser ([email protected]) og sjove adresser ([email protected]). Det kan også være, at du aldrig har anledning til at anvende OpenPGP med visse adresser: Sådanne adresser bør selvfølgelig ikke indgå i noget bruger-ID. Beslutningen om at føje en adresse til en nøgle er uigenkaldelig. Men det er nemt at tilføje en adresse på et senere tidspunkt. Overvej derfor dette nøje før du genererer nøglen. Hvis du er i tvivl, så start med færre adresser.

Det giver god mening at have en bruger-ID uden en e-mail-adresse. For de fleste e-mail-adresser kan du ikke være sikker på at bevare dem altid. Hvis du tilbagekalder et bruger-ID fordi du ikke bruger adressen mere, så mister du alle certificeringerne af dette bruger-ID. Men du vil aldrig miste dit navn (selv hvis du gifter dig eller lignende er der ingen grund til at tilbagekalde dette bruger-ID). Du bevarer så certificeringerne af dette ID under alle omstændigheder. Og du kan bruge kommentaren til dette ID til en erklæring om nøglen selv: "hverdagsnøgle med sikker offline nøgle og nøglepolitik".


Nøgletype og længde

De velunderstøttede nøgletyper er DSA (kun signaturer), ElGamal (kun kryptering) og RSA (begge) og ECDSA (elliptiske kurver). GnuPG gør det muligt at oprette nøgler med længder fra 1024 til 4096 bit (pr. aug. 2020).

Forskellene i sikkerhed, udførelsestid, signaturstørrelse og om de er obligatoriske eller blot betragtes som valgfri af standarden (rfc4880) er irrelevante i de fleste situationer. Den eneste relevante forskel er: g10-smartcardet understøtter kun RSA. Du bør således generere en RSA-nøgle medmindre du har en konkret, god grund til at vælge en anden løsning. 1024 bit nøgler menes at kunne brydes af visse regeringsorganer nu eller i den nærmeste fremtid. 2024 bit-nøgler anses for sikre i flere årtier. Men husk: Disse velkendte regeringsorganer ville ikke spilde deres tid med at bryde dine nøgler; de ville stjæle dem. Hvis du derfor ønsker en større nøgle for at sikre dig imod den slags modstandere, så sørg for, at de ikke kan stjæle dem. Dette kræver selvfølgelig dyb viden, disciplin og nok også penge. Den praktiske grund til ikke at bruge meget lange nøgler er: Almindeligt anvendte udgaver af OpenPGP understøtter ikke nøgler som er længere end 2048 hhv. 3072 bit. Operationer med asymmetriske nøgler er generelt krævende. Og for at gøre tingene værre, så kræver operation med dobbelt så lang en nøgle otte gange så lang tid. Og det tager også lang tid at generere meget lange nøgler. For mobile enheder kan denne belastning blive et problem.

Medmindre du altså har konkrete, gode grunde til en anden beslutning, så hold dig til 2048 bit (i hvert fald til hverdagsnøgler).

Nøgleudløb

Hovednøglen kan fastsætte (og ændre) sin egen og sine undernøglers udløbsdato. Den eneste "ulempe" ved en udløbsdato for andre er, at de skal opdatere nøglen for at den skal forblive brugbar. Men nøgler bør alligevel opdateres regelmæssigt, så man kan også betragte dette som en fordel. Den vigtigste fordel ved en udløbsdato (også for hovednøglen) er, det er let at se om en nøgle ikke længere er i brug. Der er også en "officiel" måde at opnå dette på. Hvis en nøgle opgives, så bør der udgives et tilbagekaldelsescertifikat. Men det kan være umuligt (hvis nøgle eller kodeord er gået tabt og der ikke tidligere er blevet oprettet et certifikat (eller det også er gået tabt)) eller du kan glemme at gøre det (eller at offentliggøre det overalt). Den "rette" gyldighedsperiode er et kompromis imellem at reducere forstyrrelser fra udløbne nøgler (på begge sider: husk at du skal bruge sikre omgivelser for at ændre udløbsdatoen med en offline hovednøgle) og den tid, hvor nøglen stadig optræder som gyldig. Et år kan være et godt valg.


Tilbagekaldelsescertifikat

Et tilbagekaldelsescertifikat er en fil (eller en udskrift), som du kan oprette preventivt, for senere at kunne tilbagekalde en hel nøgle hvis du ikke længere har adgang til den. Dette er en kæmpe fordel hvis du ikke længere har adgang til nøglen men en anden har! Ulempen er: du skal beskytte denne fil eller udskrift lige så godt som den hemmelige hovednøgle. Det kan give store problemer, hvis du kun har én (passende) nøgle og har presserende brug for den og en anden så ødelægger den lige på det tidspunkt. Det er klart, at tilbagekaldelse af en hovednøgle er endegyldig (det kan ikke ændres med en senere selvsignering).

Hvis du (eller en, som du virkelig stoler på) har en anden nøgle, som er sikker nok, så kan du tilføje den nøgle til dine nøgler som udpeget tilbagekalder (du behøver ikke at offentliggøre dette). En udpeget tilbagekalder kan tilbagekalde en anden nøgle. Den udpegede tilbagekalders signatur skal selvfølgelig være til stede, når den skal bruges. Hvis du ikke har givet den til den anden og tabt den sammen med din nøgle, så nytter dette ikke noget. Hvis du vægter sikkerhed over tilgængelighed, så kan du gøre din ven A til udpeget tilbagekalder, kryptere signaturen til din ven B og bede din ven C om at gemme den.


Adgangskoder, sikker opbevaring og backup

Du bør tænke over, hvor du vil gemme hovednøglens adgangskode og filen med eller udskriften af genkaldelsescertifikatet. Sikre adgangskoder er vanskelige at huske. Du bliver nok nødt til at skrive det ned. Du bør virkelig undgå at bruge en adgangskode, som du nogensinde har skrevet på et usikkert system (og du bør selvfølgelig heller aldrig gøre det i fremtiden). Vælg noget i retning af rsbBwNl137LcWP33RI: 18 tegn bestående af små og store bogstaver og tal. Brug ikke specielle tegn eller accenter. Du vinder ikke meget i sikkerhed (hvis du ikke kan huske 18 tilfældige tegn kan du nok heller ikke huske 15), men kan komme i problemer hvis du nogensinde bliver nødt til at bruge nøglen på et gendannelsessystem (Linux i teksttilstand) med de forkerte tastaturindstillnger. Du øger sikkerheden, hvis du kan memorere en del af adgangskoden og blot nedskriver resten eller hvis du nedskriver de to halvdele hvert sit sted og gemmer dem forskellige steder (det ene i din pung og det andet derhjemme). Men hvis du gemmer en adgangskode på 18 tegn i to dele og en angriber får fat på den ene, så er der kun 9 ukendte tegn tilbage og det er ikke længere en sikker beskyttelse. Hvis du har oprettet et genkaldelsescertifikat, så skal du også gemme det et sikkert sted.

Og selvfølgelig bør du have et pålideligt backup af din nøgle. Det er rart ikke at skulle være nervøs for, at nogen har stjålet din nøgle, men det vil formentlig være ret ubehageligt hvis du ikke kan dekryptere dine data længere. Hvis du har en sikker adgangskode, så kan du endda lægge en kopi af din hemmelige hovednøgle på dit websted.


Nøglepolitik og politik-URL

Du bør lave et dokument (i ren tekst eller html), som beskriver nøglens tilsigtede anvendelse og sikkerhed samt dine kriterier for at certificere andre (disse kan evt. tilføjes senere). Du kan angive et eller flere URL'er, hvor dette dokument (senere) kan findes i nøglen og i enhver signatur du laver. Denne komponent af nøglen kaldes en politik-URL. Det er en god idé at ikke at udgive bruger-ID-signaturer uden politik-URL'er. Det er vigtigt at brugerne af dine nøgler kan tjekke om et givet dokument hører til en politik-URL (download fra en webserver er ikke sikkert, ikke engang over HTTPS). Du bør således ændre politik-URL'en hver gang du ændrer dokumentet og nævne URL'en på et meget synligt sted i dokumentet. Du kan bruge dette mønster: http://ditdomæne.eksempel.org/openpgp/0x12345678__politik.1.html. Dette dokument bør have en fritstående signatur (eller en signatur i klar tekst hvis det er et rent tekstdokument) med hovednøglen, som er offline. Du bør linke til den fritstående signatur fra dokumentet.


Foretrukken nøgleserver

Ligesom med politik-URL'en kan man også angive en nøgleserver-URL i nøglen. Du bør beslutte, hvilken nøgleserver der skal være autoritativ for din nøgle, sådan at din nøgles brugere ved, hvor de kan finde den "officielt, aktuelle version" af din nøgle. Det bør være den nøgleserver, som du først uploader nøgleopdateringer til og den, som du angiver i GnuPG's konfigurationsfil (--keyserver) til søgning og upload af nøgler. Denne adresse bør først og fremmest være tilgængelig i lang tid og kun have få og korte udfald. Du kan endda bruge dit eget websted: http://ditdomæne.eksempel.org/openpgp/0x12345678.asc.

Tilgængeligheden forbedres, hvis du bruger en serverpool (med samme DNS-adresse). Hvis du ikke har en bedre idé, så kan du bruge hkp://pool.sks-keyservers.net eller en af den mere lokal pools hkp://eu.pool.sks-keyservers.net (Europa), hkp://na.pool.sks-keyservers.net (Nordamerika) eller hkp://sa.pool.sks-keyservers.net (Sydamerika). Se http://sks-keyservers.net/overview-of-pools.php


Indstillinger for algoritmer

Du kan også skrive i din nøgle (til andre) og i din konfigurationsfil (til dine handlinger) i hvilken orden du foretrækker kodnings- og sammenfatningsalgoritmer. Du bør gøre dette før du genererer nøglen (dette er lettere end at ændre den efterfølgende). Det er en god idé at undgå SHA-1. Vær opmærksom på, at du ikke kan forhindre GnuPG i at generere SHA-1-signaturer med din nøgle (fordi det er den eneste sammenfatning, som standarden kræver). Du kan evt. indskrive følgende linjer i din fil 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

Videre læsning

Retrieved from "https://userbase.kde.org/index.php?title=Concepts/OpenPGP_Getting_Started/da&oldid=459520"