Ny GPG-nøkkel og et forslag til nøkkelstruktur

GPG-nøkkelen min fra 2002 er etter hvert moden for utskifting. Verden har gått fremover, så 1024 bits nøkler er ikke så sikre som de en gang var. Både hovednøkkelen (med signeringsnøkkel) og undernøkkelen for kryptering har ligget på de fleste datamaskinene jeg har hatt de siste ti årene, så det er heller ikke mulig å utelukke at en av dem har vært kompromittert i løpet av den tiden. Nylig kjøpte jeg en CryptoStick – en USB-implementasjon av OpenPGP smartkort. CryptoSticken kan holde på tre RSA-nøkler, og de kan ikke hentes ut derfra igjen. Skadepotensialet ved trojanere på PCen blir derfor begrenset, og som en hyggelig bieffekt av å lage helt ny nøkkel får jeg samtidig muligheten til å unngå å ha privat-delen av hovednøkkelen innom en datamaskin annet enn i unntakstilfeller. Her følger en liten oppskrift på hva jeg har gjort for å få et sett med nøkler som er forenelige med det jeganser som fornuftig bruk av CryptoStick eller OpenPGP-kort.

En GPG-nøkkel består av en hovednøkkel og vanligvis en eller flere subnøkler. Det er fire mulige egenskaper disse nøklene kan ha:

Sertifisering (C). Identifiserer en hovednøkkel, og kan ikke brukes på subnøkler. Sertifisering sier at nøkkelen kan brukes til å signere andre nøkler.

Sigering (S). Signering/sjekk av signaturer på filer eller andre ting som ikke er nøkler.

Kryptering (E). Brukes for kryptering/dekryptering av filer.

Autentisering (A). Angir at nøkkelen kan brukes for å bekrefte en bruker-identitet, for eksempel ved bruk sammen med ssh.

En hovednøkkel har alltid C-egenskapen, og ved å ikke gi den mer enn det slipper du å ha den i daglig bruk. Da trenger du tilgang til den private delen av hovednøkkelen i bare noen få tilfeller; når du skal signere andres nøkler (sjelden), når du skal lage deg en ny subnøkkel (enda sjeldnere) og for å tilbakekalle signaturer eller nøkler (forhåpentlig unødvendig). Samtidig er det denne nøkkelen som krever den største innsatsen i web-of-trust, siden det er den andre har signert og du har brukt for å signere andres nøkler. Å lage ny hovednøkkel krever derfor at du fysisk møter folk i kretsene du skal kommunisere med, noe som fort tar tid og er upraktisk på tvers av landegrenser eller kontinenter. Siden den private delen av hovednøkkelen ikke behøves til daglig er det ingen vits å ha den liggende på en maskin som kan hackes: Oppbevar den offline på en minnepinne eller lignende.

Dette går ikke med standard-oppsettet til GPG. Der får hovednøkkelen CS-egenskaper, dvs både sertifisering og signering, og man lager normalt en subnøkkel til kryptering. Min gamle nøkkel ser slik ut:

pub  1024D/02334990  opprettet: 2002-09-15 \
 utgår: never       bruksmåte: SC  
                     tillit: ultimate      gyldighet: ultimate
sub  1024g/22C80055  opprettet: 2002-09-15 \
 utgår: never       bruksmåte: E   
[ultimate] (1). Einar Ryeng <einarr@pvv.org>
[ultimate] (2)  Einar Ryeng <einarr@pvv.ntnu.no>
[ultimate] (3)  Einar Ryeng <einaryen@hinux.hin.no>

For å lage ny nøkkel uten S på hovednøkkelen må man bevise sin nerdete natur ved å bruke –expert.

gpg2 --expert --gen-key

Velg «(8) RSA (sette dine egne muligheter)» her. Da får du muligheten til å sette selv hvilke egenskaper nøkkelen skal ha. Velg bort alt unntatt «bekrefte» og gå videre. Etter at CryptoStick og OpenPGP smartkort nå kan brukes sammen med 4096 bits nøkler er det liten grunn til å velge noe mindre. Dette krever dog gpg2 >= 2.0.18 som kom i November 2011. Lag ferdig nøkkelen, og rediger den deretter ved å kjøre:

gpg2 --expert --edit-key 0x8B584606

(hvor du selvsagt bytter ut min nøkkel-ID med IDen til hovednøkkelen du akkurat lagde). Inne i gpg2 kjører du så kommandoen add-key for hver subnøkkel du vil lage. Du vil igjen få spørsmål om hvilke egenskaper nøkkelen skal ha. Jeg foretrekker å ha en nøkkel til hver av egenskapene, men det er egentlig ikke noe i veien for å legge flere egenskaper til samme nøkkel. Den nye nøkkelen min består derfor av en hovednøkkel og tre subnøkler, en for hver egenskap jeg har tenkt å bruke den til:

pub  4096R/8B584606  opprettet: 2011-12-14 \
 utgår: never       bruksmåte: C   
                     tillit: ultimate      gyldighet: ultimate
sub  4096R/35E560BF  opprettet: 2011-12-14 \
 utgår: never       bruksmåte: S   
sub  4096R/9A6EE054  opprettet: 2011-12-14 \
 utgår: never       bruksmåte: E   
sub  4096R/7C22D7C5  opprettet: 2011-12-14 \
 utgår: never       bruksmåte: A   
[ultimate] (1). Einar Ryeng <einarr@pvv.org>
[ultimate] (2)  Einar Ryeng <einarr@pvv.ntnu.no>

Den private delen av hovednøkkelen ligger nå offline. Jeg har endog laget meg en bootbar minnepinne jeg kan starte en PC med for å få tilgang til den. Dersom en undernøkkel skulle bli kompromittert har jeg derfor mulighet til å trekke den tilbake og lage en ny tilsvarende undernøkkel, uten å måtte lage ny hovednøkkel med tilhørende styr med signeringer.

Obs: Husk å ta backup av nøklene dine! Jeg kjenner flere som har mistet den private delen av nøkkelen, og derfor har nøkler liggende ute på keyserverne uten at de er i stand til å tilbakekalle dem. Dessuten kjenner jeg tilsvarende mange som har glemt passordet sitt. Lag derfor et sertifikat for å trekke tilbake hele nøkkelen og legg det på et lurt nok sted til at bare du har tilgang til det, men hvor du ikke mister det.

gpg --gen-revoke 0x8B584606

Et alternativ er å gi en person du stoler på muligheten til å trekke tilbake nøkkelen din. Vær i så fall oppmerksom på at dette ikke kan omgjøres.

gpg --edit-key 0x8B584606
> addrevoker

Dette er ca så langt jeg er kommet i nøkkelbyttet. Stadig er den gamle nøkkelen  i bruk, siden den nye ikke har fått signaturer ennå. Neste steg etter signaturer blir å trekke tilbake godkjennelsen av den gamle nøkkelen, slik at andre ikke bruker den til å sende meg noe. Å pensjonere den private nøkkelen kommer til å ta lang tid, siden jeg har epost og filer som må rekrypteres først. Mest sannsynlig blir den bare liggende på minst en av PCene mine i uoverskuelig fremtid. Det tar tid å pensjonere kryptonøkler, så det er like greit å opprette dem på rett måte i utgangspunktet så man ikke får for mange.

One Response to Ny GPG-nøkkel og et forslag til nøkkelstruktur

  1. Oppdatering: Jeg har endret litt mening på punktet om hvorvidt hovednøkkelen skal være C (bare certify) eller CS (certify+sign). I noen få tilfeller, særlig der du ønsker å ha et dokument som beskriver hvordan nøkkelen brukes, er det praktisk å kunne signere med hovednøkkelen i stedet for med en subnøkkel. For personlige nøkler er det antakelig få som trenger et slikt dokument, men for en egen nøkkel assossiert med jobb-epost-adresse kan det være praktisk å kunne si hva det egentlig betyr når nøkkelen signerer noe.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>