Archive for the ‘public-key’ Category

GPG – crashcourse

2014/04/02

Nån form av inledning

Jag vet att jag har skrivit sånt här förut, men upprepning är alltid bra har jag hört.
Dessutom så känns det som att ämnet är något många känner att man borde göra, men det är ju så komplicerat och jobbigt och man vet inte hur eller varför egentligen så därför faller det i glömska.
Sen var det länge sen jag ordbajsade fritt…

Varför kryptering?

Genom alla tider har människor haft behov av att kunna skydda meddelanden av olika slag och av olika anledningar, från ganska oskyldiga saker som kärleksbrev till statshemligheter.
De flesta anser att brev är privata och att endast mottagaren har rätten att bestämma vem som får se innehållet, när telegrafen infördes så blev det ganska vanligt att gemene man utnyttjade enklare krypteringar för att inte telegrafisten skulle kunna ta del av meddelandets egentliga innehåll.
Bilden av ett brev i ett kuvert är något många ser framför sig när man pratar e-mail också, bilden brukar vara att brevet går från sändaren till mottagaren och att ingen på vägen läser det. Denna bilden är helt felaktig.
Att diverse säkerhetstjänster trålar internet efter information är belagt i dagsläget, men vad många inte tänker på är att andra aktörer såsom google, hotmail och yahoo samt mer ljuskygga organisationer gör samma sak för att kartlägga våra vanor och informationsmönster i olika syften. Och även om våra e-mail inte innehåller några hemligheter så är de privata och endast för mottagarens ögon.

Så för att skydda information och se till att endast rätt personer kan läsa den får man ta till kryptering. Dock så lider kryptering av ett stort problem nämligen; hur tusan ska man kunna överföra nyckeln som låser upp informationen till mottagaren på ett säkert sätt?
Lösningen är att man skapar ett system med två nycklar där den ena används för att kryptera informationen och den andra för att dekryptera den, istället för en som används till båda sakerna. Nyckeln som används för kryptering kan spridas till vem som helst medan nyckeln för dekryptering behålls hemlig.

Så vad gör GPG?

Krypterar information. Bland annat…
Det längre svaret är att GPG är ett såkallat hybridsystem som krypterar informationen med en slumpmässigt skapad symmetrisk nyckel (alltså en nyckel som både krypterar och dekrypterar), denna slumpmässiga nyckel krypteras sedan med mottagarens publika nyckel och läggs till som ett huvud till informationen. Mottagaren kan sedan dekryptera den slumpmässiga nyckeln och därefter dekryptera resten av informationen.
Varför gör man det då så komplicerat?
Jo, systemen som utnyttjar två nycklar är extremt långsamma jämfört med systemen med en nyckel (sist jag såg siffror på det handlade det om tiopotenser i skillnad). Men problemet med systemen med en nyckel är just hur man överför nyckeln till mottagaren.

Vidare så ger tvånyckelsystemen en annan fördel; man kan skapa digitala signaturer med dem. Grundteorin här är att man istället för att kryptera informationen med mottagarens publika nyckel så krypterar man med sin egna privata nyckel. Detta får till följd att alla (som har personens publika nyckel) kan dekryptera informationen och på så vis konstatera att någon med tillgång till den privata nyckeln är den som är avsändare av meddelandet.

Jaja, så var får jag tag på GPG?

Man hoppeliskuttar till http://www.gnupg.org/, klickar på download och scrollar lite.

Hur skapar jag en nyckel?

Det är nu det kommer börja bli rörigt, eftersom det skiljer sig en del åt för olika plattformar men jag tänker göra ett försök…
Kommandorad (*nix, men troligen de andra också)
Den mest rakt på metoden, inget fancy och lull-lull. Dock kanske skrämmande för en del.
1. Öppna en kommandotolk på valfritt sätt.
2. Om gpg finns i din sökväg behöver du inte göra något, annars får du ta dig till rätt katalog.
3. Skriv följande:

gpg --gen-key [enter]

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)

Den eviga frågan är här vilken man ska välja, val 1 och 2 är jämförbara säkerhetsmässigt (det finns några quirks med val 2, men de är inte direkt allvarliga) och det finns prestandamässiga skillnader mellan dem i olika fall. Val 1 är dock standard så man kan lika väl köra på det. Den som är intresserad kan alltid googla ”gpg rsa vs. elgamal” och fundera själv ;)

1[enter]

RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)

1024 bitar räcker troligen om man vill vara säker, 2048 räcker definitivt, men med dagens processorer finns ingen anledning att inte köra på max.

4096[enter]

Requested keysize is 4096 bits
Please specify how long the key should be valid.
0 = key does not expire
n = key expires in n days
nw = key expires in n weeks
nm = key expires in n months
ny = key expires in n years
Key is valid for? (0)

Här finns lite olika skolor hur man bör/kan tänka. Värt att notera är att nyckeln inte slutar fungera helt när den gått ut, man kan dekryptera saker och man kan verifiera signaturer med en utgången nyckel. Man kan dock inte signera eller kryptera med en utgången nyckel.
Mitt upplägg är att jag har en ”huvudnyckel” som inte går ut, som används för att signera andra nycklar (mer om det senare), med ett antal subnycklar (kommer nog mer om det också) som har en livslängd på ett år.

0[enter]

Key does not expire at all
Is this correct? (y/N)


y[enter]

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) ”


Real name: otyg test [enter]
Email address: otyg@gallowsground.lan [enter]
Comment: Testkey [enter]

You selected this USER-ID:
”otyg test (Testkey) ”

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


O[enter]

You need a Passphrase to protect your secret key.

Se till att skapa en bra lösenfras, som du kan komma ihåg… Och spara den nånstans säkert!
Tappar du bort den så är det kört, det finns INGET sätt (för oss dödliga, och troligen inte för de odödliga heller) att knäcka nycklarna så tappas lösenfrasen bort så är nycklarna oanvändbara (eller ja, den publika kan användas…).
Efter lösenfrasen skapas nyckeln, och till det behövs en massa slump så programmet kommer be dig skriva på tangentbordet och annat för att den ska kunna samla tillräckligt med underlag till slumpgeneratorn. Därefter är nycklarna klara att användas.

Jag kommer återkomma hur man gör ovanstående i gui-varianterna (gpg4win främst eftersom jag inte har tillgång till nån Apple-maskin) när jag riggat miljö för det.

Vad gör jag med mina nycklar nu då?

Den hemliga skyddar du med ditt liv och ser till att ta backup på, filen heter secring men man kan exportera en specifik hemlig nyckel också på ungefär samma sätt som med den publika nyckeln vilket jag kommer gå igenom nedan.

Den publika sprider du antingen helt öppet eller till specifika personer, helt beroende på tycke och smak.
Att sprida den publika nyckeln fritt för vinden är löjligt enkelt, man skickar upp den till en s.k. nyckelserver (det finns en drös och majoriteten av dem synkar mellan varandra). Såhär går man tillväga för att skicka nycklarna till en server:

gpg --send-keys [nyckel-id]

Nyckel-id visades när du skapade din nyckel, men kan även tas fram med kommandot gpg –list-key som genererar nåt liknande det nedan:

pub 2048R/1EC847E0 2011-08-21
uid otyg [otyg@gallowsground.lan]

I ovanstående fall är nyckel-id 1EC847E0 eller 0x1EC847E0.

Om man nu av en eller annan anledning inte vill sprida sin nyckel till vemsomhelst så kan man exportera den till en fil som kan skickas till personen (såhär kan man även exportera sina privata nycklar) på följande sätt

gpg -a --export [nyckel-id] > [filnamn]

Flaggan a gör att saker trillar ut som ASCII och därmed kan skickas på valfritt sätt utan problem.
Det som trillar ut är något i stil med

—–BEGIN PGP PUBLIC KEY BLOCK—–
Version: GnuPG v1.4.11 (GNU/Linux)

mQSuBFLgyIsRDADT0Xa9fYM+GGRLenwJC8b6OwhCnEh6coqsLrWi+MRbNWRQqLvF
(…)
7K3vIpoIqTnh1M/4kCxjfQ==
=OF6I
—–END PGP PUBLIC KEY BLOCK—–

Hur kryptera/dekryptera/signera/kontrollera signatur?

Återigen så blir det kommandorad, och det blir att hantera filer på disk (gpg4win gör att man kan högerklicka och kryptera/dekryptera/signera/kontrollera en fil vet jag).
För att kryptera en fil är något av kommandona

gpg -e -r [mottagare] [fil]
gpg -ae -r [mottagare] [fil]

som gäller. Det senare ger en ASCII-fil medan det förra ger en binärfil som kan ställa till problem vid överföring.
För att signera en fil gör man något av följande

gpg -[a]s [fil]
gpg --clearsign [fil]
gpg --detach-sign [fil]

och uppger sin lösenfras. Den första ger en binär signatur av filen, om inte a-flaggan tas med, den andra ger en ascii-signatur av filen och den tredje ger ett separat ”certifikat” för filen. Dom mer tekniska skillnaderna mellan varianterna lämnar jag till den intresserade läsaren att utforska. Generellt så använder jag clearsign när jag bara signerar och -[a]es när jag krypterar och signerar.

För att dekryptera eller kontrollera en fil skriver man bara

gpg [filnamn.ändelse].{asc,sig,gpg}

Är den krypterad kommer du få frågan om din lösenfras, är den signerad kommer det visas av vem den är signerad och i båda fallen kommer en ny fil skapas som saknar ”extraändelsen”.

…mottagarens nyckel?

Hur får man då tag på en mottagares nyckel?
Precis som i fallet med att sprida sin egen nyckel kan man antingen plocka den från en exporterad fil som man har fått från personen, eller genom att hämta den från en nyckelserver.
Har man fått den exporterade nyckeln i en fil är operationen enkel.

gpg --import [filnamn]

För att hämta nycklarna från en nyckelserver kör man följande

gpg --recv-key [nyckel-id] --keyserver [nyckelserver]

För att hitta en persons nyckel kan man köra kommandot

gpg --search-keys [namn email] --keyserver [nyckelserver]

som även importerar den.
Slutligen så kan man importera den direkt från en url med kommandot

gpg --fetch-keys [url]

Men hur fasen vet jag att det är person Xs nyckel jag har?

Det korta svaret är: det vet du inte om du har hämtat den från en nyckelserver, e-mail eller url.
Men för att kunna avgöra ifall man kan lita på att en nyckel kommer från den person som man tror att den tillhör så kan andra personer signera en nyckel, och om tillräckligt många personer som du litar på bevisligen har signerat en nyckel så kan man anta att den nyckeln tillhör en person de litar på.
Ett exempel som tillämpar en annan modell är SSL-certifikaten som man använder när man surfar säkert, dessa är hierarkiskt signerade av en rot-auktoritet som säger att den litar på utfärdarna av certifikaten som säger att de litar på de som vill ha sina certifikat signerade.
Tillitsmodellen i gpg är decentraliserad och du väljer själv ifall du litar på en publik nyckel eller ej, och du väljer själv att berätta för omvärlden att du litar på en nyckel eller ej. Om man litar på att en nyckel kommer från den som den verkar komma ifrån så signerar man den, exporterar och skickar till ägaren av nyckeln (som sedan väljer ifall den vill publicera den signerade nyckeln eller ej). På detta sättet byggs ett nät av tillit upp runt en nyckel, dock så är många signaturer på en nyckel inte samma sak som att nyckeln är att lita på.
Tanken är snarare att man ska kunna hitta en kedja från en okänd nyckel till en person som man litar på, den där six degree of separation-grejen.
Så hur signerar man en nyckel då? Såhär:

gpg --sign-key [nyckel-id]
gpg -a --export [nyckel-id]

Den sista är bara om man vill skicka den till ägaren till nyckeln så att hän vet att ytterligare en person litar på nyckeln.

Check… Låter jobbigt… Kan man göra det roligt?

Jadå, man kan dra ihop en nyckelsigneringsfest och beroende på antalet deltagare kan man göra det hur jobbigt (och roligt) som helst. Grundbulten här är att alla ska kunna identifieras och kunna kopplas med deras nyckel-id och nyckel-fingeravtryck, sen kan man antingen på plats signera varandras nycklar eller göra det i hemmets lugna vrå.
För mer info och idéer hur det ska gå till; se dessa sidor!

Ok, fint. Men hur får jag skiten att funka med min mejlklient/gmail/whatever?

Det är här det riktigt jobbiga börjar. Det finns plugins till de flesta mejlklienter som är mer eller mindre användarvänliga, till Thunderbird (och derivat) rekommenderar jag EnigMail, gpg4win tror jag har en del plugins eller integrationer till Outlook och windows mail, men det enklaste är att googla.
Kör man webmail som gmail eller hotmail så får man leta reda på plugins till webbläsaren som kan sköta operationerna via klipp-klistra, WebPG är ett sådant plugin till Firefox och Chrome(/ium) som jag har använt med skiftande resultat.
Fattigmansversionen är att skriva det man vill i lämplig editor, kryptera/signera till ascii-armoured och klippa ut och klistra in manuellt.

Das Ände

Helt ärligt så är jag inte särskilt nöjd med ovanstående textvägg, men jag hoppas att någon någonstans kommer finna den användbar på ett eller annat sätt.
För den som vill hitta åt min gpg-nyckel så finns den här.

Ny kommentar om Oneswarm

2009/03/30

Har kört Oneswarm ett tag nu och det funkar för mina behov. Det största problemet som jag har upptäckt är att många i praktiken endast har en torrentfil som innehåller allt i deras share.

Jag tror att detta beror på att själva utdelningsförfarandet inte är helt solklart, väljer man att dela ut en katalog skapas en torrent av hela katalogen. På pappret delar man ut de enskilda filerna, men i praktiken är det en mastodont torrent som läggs upp.
Valet ”Share multiple directorys and files” löser det problemet, vad jag har förstått, och skapar enskilda torrenter för underkataloger och filer. Men jag kan ha fel ;)
Autobevakningen av kataloger har jag inte kollat än, men jag antar att den funkar som share multiple.

Nästa sak, och det är att ragga kompisar till höger och vänster på forum och liknande. Det upplägget tror jag inte är speciellt bra alls, förvisso så ser man bara sina kompisars ip-adresser (vad jag har förstått) och F2F-kopplingar är anonyma från den bryggande kompisens.
Bristen jag ser i att ragga vänner är att man inte har någon koll på personen i fråga, och även om man inte kan se adresserna till de som finns bortanför så kan han se din adress och din share.

För att anonymiteten ska fungera i praktiken måste man hålla stenhårt på att personerna i vännerlistan är personer som man vet vilka det är (på ett eller annat sätt), att skaffa anonyma kompisar bara för att ha många innebär att man sannolikt förr eller senare kommer få någon från antipiratbyrån i vännerlistan.

För att understryka det hela; anonymiteten är inte bättre skyddat än den svagaste länken. Vänner kan se andra vänners utdelningar och deras ip-adresser!
Slutsatsen är att man endast ska lägga till vänner som man på ett eller annat sätt kan anse vara pålitliga.

Samma sak gäller public-key-kryptering överhuvudtaget, det finns inga garantier för att en publik nyckel tillhör personen som man tror den tillhör. Samma sak gäller Oneswarm, det finns inga garantier för att en okänd person inte tillhör antipiratbyrån bara för att personen ber dig om din nyckel och ger dig sin.

Kommentarer mottages gärna på denna texten!

Intressant

GnuPG + Mozilla Thunderbird + gmail

2008/10/20

Tänkte fortsätta med det jag påbörjade i min postning ”Att kryptera eller inte kryptera, någon form av guide” och berätta hur man får gnuPG att samarbeta med Mozilla Thunderbird.
Om någon undrar varför jag inte tar upp Outlook så beror det på att jag aldrig har använt den mejlklienten, jag vet dock att man kan använda gnuPG med den mejlklienten också.

Hursomhelst, för att gnuPG ska fungera fint med Thunderbird så krävs det ett plugin vid namn Enigmail till Thunderbird. Installationsfilen kan laddas ner från denna sidan, tänk dock på att högerklicka på länken och välja ”spara som” om du använder FireFox och välj rätt operativsystem och mejlprogram i listan. Ladda även ner OpenPGP-signaturen och kontrollera den med hjälp av gpg (hur du gör det får du lista ut själv, men projektets publika nyckel finns här ;)).

För att installera Enigmail behöver du starta Thunderbird, välj därefter menyn Tools och alternativet Add-ons. I rutan som öppnas klickar du på knappen ”Install” och letar reda på Enigmail-filen. En ruta kommer dyka upp och fråga dig om du är säker på att du vill installera pluginen, och det är du antagligen så det är bara att trycka på rätt knapp. När installationen är klar måste du starta om Thunderbird.

Det kan vara en idé att kolla så att Enigmail har hittat gpg. I menyn OpenPGP (som bör ha dykt upp i Thunderbird) väljer du ”Preferences” där bör sökvägen stå under ”Files and Directorys” i basic-fliken. Gör det inte det får du knacka in sökvägen manuellt i fältet ”Override with”. Den som är sugen kan kika på ”Expert settings” också.

Nästa steg är att ändra kontoinställningarna i Thunderbird. Öppna Tools, Account settings. För varje konto i Thunderbird finns nu ”OpenPGP Security”, det som ska göras är att kryssa i rutan ”Enable OpenPGP support for this identity”. I övrigt brukar man inte behöva ändra något, undantaget är om ens nyckel inte har samma mejl-adress som kontot. Då får man manuellt välja nyckel.
Tänk dock på att om du inte har någon annans publika nyckel, så kommer du bara kunna kryptera till dig själv. Ska du kommunicera säkert med någon annan part behöver denne också GnuPG (dock krävs inte enigmail) och du behöver personens publika nyckel.

Hur var det då med Gmail?
Jo, jag snubblade över ett add-on till Firefox som kallas FireGPG som erbjuder GnuPG-stöd till Gmail (och signerade/krypterade hemsidor). Jag har dock inte provat det fullt ut än, men jag återkommer på den punkten.
För att installera det får man gå in på FireGPG’s hemsida och trycka på Install-länken och därefter ”Download firegpg”. Firefox varnar dig med en liten list i överkanten, tryck allow och bekräfta valet i rutan som öppnas. Starta om Firefox och i Tools-menyn ska det nu finnas alternativet ”FireGPG”. Om FireGPG inte hittar gpg så får du klicka options i Tools -> FireGPG och välja fliken ”GPG”. Där finns ett alternativ som heter ”Specify path to gpg”.
Svårare än så var det inte där.
Lycka till!

Att kryptera eller inte kryptera, någon form av guide

2008/10/20

På förekommen anledning tänkte jag viga denna bloggposten åt den ädla krypteringskonsten. Anledningarna är flera till att jag gör det, men den huvudsakliga anledningen är faktiskt inte FRA-lagen, och andra liknande lagar.
Den huvudsakliga anledningen är att de flesta jag känner inte krypterar sina e-brev, och som jag skrivit om tidigare så är e-brev lika svårlästa för en utomstående som ett vykort.

Kryptering kan delas upp i två kategorier; symmetrisk och asymmetrisk.

Symmetriska chiffer, eller krypteringsalgoritmer, kallas ibland för secret-key och använder en och samma nyckel för kryptering och dekryptering.
Nackdelen med denna typen av system är att krypteringsnyckeln måste överföras på ett säkert sätt mellan sändaren och mottagaren.
Fördelen med de symmetriska algoritmerna är att de generellt sett är snabba både i mjukvara och hårdvara.

Asymmetriska chiffer kallas ibland för public-key och fungerar på ett sådant sätt att man använder skilda nycklar för att kryptera och dekryptera.
Fördelen med dessa chiffren är att nyckelutbytet kan ske över en osäker kanal, utan att en angripare kommer kunna läsa meddelanden som utväxlas (eftersom nyckeln som överförs bara kommer kryptera data), en annan fördel är att man kan använda dessa systemen för att digitalt signera mejl och filer.
Nackdelen med dessa systemen är att man måste generera långa nycklar för att nå upp till samma säkerhetsnivå som de symmetriska alternativen och de är rejält långsamma jämfört med de symmetriska kryptoalgoritmerna.

Det verkar som att man måste välja mellan snabbhet eller enkel nyckelhantering eftersom inget av alternativen erbjuder båda fördelarna.

Lösningen
Philip Zimmermann funderade över denna problematiken och påbörjade ett arbete som senare skulle bli känt som Pretty Good Privacy, eller PGP. PGP erbjöd snabb kryptering och public-key i ett och samma paket.
Hur lyckades han med detta kan man fråga sig?
PGP fungerar på så sätt att en slumpmässig nyckel, en sk. sessionsnyckel, och för meddelandet unik genereras. Sessionsnyckeln används sedan för att kryptera meddelandet med en snabb symmetrisk algoritm (PGP använde algoritmen IDEA vill jag minnas), nästa steg var sedan att kryptera sessionsnyckeln med en asymmetrisk algoritm (RSA) och bifoga den med meddelandet.
Vid dekryptering användes mottagarens privata nyckel för att dekryptera sessionsnyckeln som sedan användes för att dekryptera resten av meddelandet.
På detta sätt fick man tillgång till de symmetriska chiffrens snabbhet och de asymmetriska chiffrens enkelhet då det gällde nyckelhantering.

För den som vill läsa mer om ämnet kryptering hänvisar jag till Wikipedia och för dom som vill läsa saker i böcker är Simon Singhs ”Kodboken” en bra läsning liksom David Kahn’s ”Codebreakers” och Bruce Schneiers ”Applied Cryptohraphy”.

Guide till GnuPG
För den som själv vill skydda sina e-brev rekommenderar jag GnuPG, dels för att den är open source (vilket inte PGP är, längre) och dels för att den är PGP-kompatibel (eller OpenPGP som standarden heter). Jag tänkte ta upp hur man installerar gnuPG, vad man ska tänka på vid nyckelgenerering och hur man offentliggör sin publika nyckel.
Jag tänkte även ta upp hur man använder gnuPG med Mozilla Thunderbird och ett sätt att använda gnuPG tillsammans med gmail i en senare postning.

Att installera gnuPG är enklare än att knyta sina skor, man glider in på http://gnupg.org/download/ och laddar ned lämplig fil (om man använder windows, dom som kör Linux kan sannolikt ladda ned gnuPG via systemets pakethanterare och Mac-användare kan hitta en portning här) SHA1-summan för installationsfilen bör även laddas ned och kontrolleras.

Program för att kontrollera SHA1 summan finns här. Kontroll av checksumman görs på följande sätt

1. Kontrollera att signaturfilen är i samma katalog som exe-filen (föreslagsvis så läggs sha1sum.exe i samma katalog).

2. Öppna en kommandorad (start->kör->cmd [enter])

3. Gå till katalogen där exe och sigfilerna finns genom kommandot cd mappnamn (föreslagsvis kopieras filerna till en enkel sökväg innan detta, förslagsvis C:\tmp)

4. Kör kommandot sha1sum.exe -c gnupg-w32cli-1.4.9.exe.sig

5. Förhoppningsvis så säger programmet OK. Får man ett felmeddelande så kotrollera först att det är rätt signaturfil till rätt exe-fil (de ska ha samma namn bortsett filändelsen). Om det är rätt fil så skall INTE programmet installeras då det kan vara något lurt med det.

När GnuPG är installerat så är det dags att skapa sitt nyckelpar (här väljer jag att köra kommandoradsversionen, jag vet att det finns GUI’n men kommandoraden är likadan i både Win och Linux).

1. Starta en kommandorad, på samma sätt som ovan om du använder Windows. Linux-användare SKA veta hur man får igång en kommandorad så det tänker jag inte säga hur man gör;)

2. Om du använder Windows så är förslaget att byta katalog till katalogen där GnuPG installerades; cd katalog (antagligen cd c:\program\gnupg)

3. Kör kommandot gpg –gen-key [enter]

4. Skriv 1 och tryck enter på första frågan

5. På frågan om nyckelstorlek är standardsvaret 2048, vilket räcker. Är man paranoid skriver man 4096 och har man en långsam dator skriver man 1024 innan man trycker enter.

6. Att byta sin nyckel med jämna mellanrum är en god vana, mina nycklar brukar vara giltiga mellan 6 månader och ett år. Standard är att nyckeln aldrig kommer att bli för gammal, är du nöjd med detta så tryck enter.

7. Svara y på kontrollfrågan.

8. Skriv in ditt namn, enter, email-adress, enter, och en kommentar om du vill.

9. Svara O på kontrollfrågan om du inte vill ändra något av fälten.

10. Skriv en ”passphrase”, denna bör vara lång 10-20 tecken och slumpmässig eller svårgissad. Det finns flera sätt att skapa en bra passphrase på. Personligen så använder jag Password-safe för att skapa och lagra lösenfrasen, Diceware är ett ganska simpelt och säkert system som jag tidigare utnyttjade.

11. Klart!

När man ska publicera sin publika nyckel kan man göra på olika sätt.
Antingen kan man skicka den i ett e-brev till sina vänner och bekanta, eller så kan man ladda upp den till en nyckelserver (dessa funkar sedan som DNS-systemet, så nyckeln sprids mellan servrarna).
Om man vill skicka sin publika nyckel i ett e-brev så måste man först exportera den. För att göra detta skriver man kommandot
gpg –export –armor -o public.asc
Nu finns den publika nyckeln i textfilen public.asc, denna filen kan bifogas med e-mail.
Ska man ladda upp sin nyckel till en nyckelserver så är det, enligt mig, enklaste sättet att surfa in på MIT PGP Key server och klistra in den exporterade nyckeln i det stora fältet och trycka submit. Man kan även göra detta inifrån gnuPG med kommandot gpg –send-keys.

När det gäller nycklarna och nyckelgenerering så ska man komma ihåg följande:
1. Nyckellängden är viktig, men inte allt. 1024 bitar ger sannolikt ett tillräckligt skydd men för att vara på den säkra sidan rekommenderas 2048 bitar.

2. Skapa en bra passphrase! Om den innehåller stora och små bokstäver, siffror och specialtecken samt är slumpmässigt skapad räcker sannolikt en längd på 10-12 tecken. Används ord som återfinns i en ordlista bör man använda minst fem slumpmässigt valda ord, och hela strängen bör åtminstone vara 20 tecken.

3. Skydda den privata nyckeln! Den publika nyckeln är till för att spridas, den privata nyckeln ska hållas privat. Så enkelt är det. Förloras den privata nyckeln kan du inte dekryptera något som har krypterats med den publika motsvarigheten. Hamnar den privata nyckeln i någon annans händer kan hän utge sig för att vara dig med hjälp av signaturer och hän kan dekryptera korrespondensen. Alltså gäller backup av den privata nyckeln och säker lagring av den samma.

4. Var förutseende; skapa ett revocation-certificate till ditt nyckelpar. Om du förlorar din privata nyckel så laddar du upp certifikatet till nyckelservern och skickar det till dem du kommunicerar med. Certificatet ogiltigförklarar nyckeln som det är kopplat till. Skapa med kommandot gpg –gen-revoke [key-id].

5. Lita aldrig på en publik nyckel! Kontrollera med avsändaren att det verkligen är rätt nyckel, dels genom nyckel-id och dels genom fingerprint.

Så, då är det bara att köra igång ordentligt. För att få hjälp av gnupg vid kommandoraden används kommandot gpg –help, kryptering görs med gpg -e -r [mottagarens namn] och dekryptering görs med gpg -d, för att kunna kryptera till någon annan än dig själv krävs personens publica nyckel. Den läggs till nyckelringen med kommandot gpg –import [filnamn].

För mer info, besök Dokumentationssidan!

Hoppas det var intressant, kritik mottages tacksamt.
Inom kort kommer en postning om hur man får Gpg att fungera med Mozilla Thunderbird och Gmail (under vissa förutsättningar).

(Om någon undrar över taggarna, så beror dom på att jag anser att kryptering är en demokratisk rättighet och rätten till stark kryptering är en politisk fråga.)

Skillnaden mellan brev och e-brev

2008/10/06

När jag stod i duschen så tog en liten tanke form, och den tanken var i folkbildningens anda. Jag har från och till funderat över om folk (i detta fall även myndighetsfolk) har insett skillnaderna mellan ett vanligt brev och ett e-brev. Tyvärr så har jag kommit till slutsatsen att folk har insett vissa av skillnaderna, men inte alla. Så därför tänkte jag skriva lite om några av skillnaderna och mina tankar om detta.

Tjuvläsning
Jag tänkte börja med tjuvläsning av brev, eller otillåten läsning av brev för den som vill låta formell. För att tjuvläsa ett brev så måste man på något sätt öppna och återförsluta kuvertet utan att mottagaren upptäcker det, jag väljer nu att bortse från fallen där man läser brevet hos avsändaren eller hos mottagaren innan kuvertet har förseglats respektive efter att det har öppnats igen.
För att lyckas med detta måste jag få brevet i min ägo rent fysiskt, tillexempel genom stöld ur en brevlåda eller på postterminalen.
Därefter måste jag öppna kuvertet på något sätt som inte lämnar spår, det mest klassiska är sannolikt att ånga upp det men det finns sannolikt andra sätt. Efter detta kan jag läsa brevet och återförsluta kuvertet.
Här kommer även en form av tidsbegränsning in, det det är god sed att skriva datum i ett brev så får inte proceduren ovan ta alltför lång tid eftersom det då verkar suspekt för mottagaren att brevet har dröjt på posten. Stölden av brevet måste även ske innan det poststämplas av samma anledning, om jag får ett brev som poststämplats för flera dagar sedan så kommer jag börja fundera över vad posten sysslar med.
Själva stölden av brevet är inte heller helt enkel, men fullt realistisk beroende på innehållet i brevet.

I fallet med e-post är det hela långt mycket enklare. Samma sak gäller som förut, att jag måste ”stjäla” brevet under transporten till mottagaren. För att lyckas med detta räcker det att jag har lokal åtkomst (med lokal åtkomst menar jag att jag kan logga in interaktivt på noden som priviligerad användare) till en lämplig nod i kedjan, tillexempel en smtp-server eller gränsrouter. Detta är tyvärr inte så svårt som det låter (men inte heller fullt så enkelt), och jag tror att det för en person med rätt kunskaper är lättare att lyckas med detta än att bryta sig in i en brevlåda eller postterminal utan att det märks.
Har man väl lyckats med detta så behövs bara lite fingerfärdighet för att knåpa ihop ett script, eller ett program, som scannar e-post-strömmen efter e-post som ska till respektive från de intressanta personerna. När ett intressant e-brev upptäcks kopieras det helt enkelt till min e-post.
Meddelande kopieras alltså i flykten och man behöver inte ånga upp något kuvert. Mottagare och avsändare kommer inte få någon indikation på att det har hamnat på avvägar.

Summasummarum: Vanliga brev erbjuder bättre insynsskydd än e-post. För att kunna läsa ett e-brev räcker det med att kontroll över en lämplig nod i kedjan mellan avsändare och mottagare.

För att skydda sig mot detta krävs det att man krypterar sina e-brev. Lösningar för detta finns, men en del av problematiken kommer i nästa stycke.

Identifiering av avsändare
När det gäller försändelser där det är noga med vem som är avsändare är vi vana vid att underteckna detta med en handskriven signatur. Egentligen så är den handskrivna signaturen inte ett fullgott skydd mot folk som försöker luras, men det finns en liten risk att signaturen jämförs med tidigare exempel och därmed accepteras som riktig eller avfärdas som förfalskad (nu tror jag personligen inte att detta sker speciellt ofta, men det går i alla fall).

Signering av elektroniska dokument är på ett sätt säkrare och på ett annat sätt osäkrare. För det första så finns det ett problem idag med vilken teknisk lösning som ska väljas för signering, vilka som ska utfärda certifikat med mera. Dessa lösningar bygger på kryptering med öppen nyckel och går i stora drag till så att man beräknar en checksumma av meddelandet som krypteras med min privata nyckel så att mottagaren kan dekryptera den med min publika och jämföra med checksumman han räknade fram.
Problemet här är att hur kan mottagaren vara säker på att det verkligen är min publika nyckel han har fått och inte en nyckel från någon som utger sig för att vara mig?
Alla som har en legitimation eller ett pass vet att det inte bara är att klampa in med en bild, fylla i papprena, lämna in personbeviset och sedan är det klart. Har man ingen tidigare id-handling krävs det att någon närstående familjemedlem kan verifiera att du är den du utger dig för att vara.
När det gäller nyckelpar för signering så beror det på teknisk lösning hur man går tillväga; används gnuPG/PGP så genererar användaren själv sina nycklar vilket inte ger någon som helst garanti för vem som finns bakom dem.
Det finns andra varianter där nyckelparet kommer från tredje part, tillexempel Verisign, dock så lämnas såvitt jag vet inga garantier om att personen verkligen är den han utger sig för att vara här heller.
Slutligen så har vi i Sverige BankID, som bygger på samma typ av certifikat som utfärdas av t.ex. Verisign (som jag har förstått det, någon som vet mer exakt får gärna upplysa mig om hur det ligger till!). Här görs en koppling mellan nyckelparet och en fysisk person, nämligen den som står bakom bankkontot.
Tyvärr så verkar det som att BankID bara kan användas till webbtjänster, för att logga in och liknande.

Jag skulle vilja se en lösning som låter mig signera mina e-brev med på ett enkelt sätt (så enkelt att jag inte behöver bry mig nämnvärt om det).
Vidare så måste lösningen vara plattformsoberoende, eller i alla fall kunna köras på många plattformar, för att så många som möjligt ska kunna använda det.
Nästa sak är att systemet ska vara byggt på ett sådant sätt att nyckel ska kunna kopplas till fysisk person med stor säkerhet (typ BankID), men vem som helst ska kunna få tillgång till publik nyckel för kontroll av signatur.
Ett sista krav på lösningen är att den ska bygga på en öppen standard och att källkoden till lösningen ska finnas tillgänglig för granskning av utomstående.

Det var nog allt för denna gången… Kommer antagligen komma på en hel hög andra saker, men jag nöjer mig här… Sannolikt så dyker det snart upp en post från min sida om hur man krypterar sina e-brev smidigt också.

Ha det gott, ursäkta svammlet och hoppas det var intressant!

Ett trygghets-USB

2008/09/15

Har suttit och funderat på att fylla ett USB-minne med säkerhetsrelaterade prylar så att man kan klara det mesta på vilken dator som helst.
Det jag tänkte mig på minnet var verktyg såsom GnuPG (och tillhörande nycklar), PasswordSafe (med tillhörande lösenordsfil), säkerhetsprogrammet till Bank-ID (eller i alla fall installen) och certifikatet.

Dock så insåg jag att det finns en hel del saker som inte är så bra om de hamnar i fel händer (privata gnuPG-nycklar, databasen till PasswordSafe och certifiktatet till Bank-ID). Så vad göra?
Jo, man skapar en TrueCrypt-container som innehåller ovanstående ”hemliga” saker, vilket medför att även TrueCrypt måste finnas med på USB-minnet. Alltså måste man hålla reda på två skilda lösenord, ett till TrueCrypt-containern och ett till PasswordSafe-filen (annars är det ganska kört, finns ju dock inget som hindrar en att ha backup på det som finns i containern om man tappar det lösenordet.).

Min grundtanke med detta lilla USB-minne är i första hand att verkligen kunna ha olika inloggningsuppgifter/lösenord till olika webbplatser, och dessutom kunna använda bra lösenord på samtliga. Därför vill jag ha med mig min passwordsafe.
Jag vill även kunna kryptera och signera e-mails och liknande oavsett vilken dator jag använder mig av.
BankID’et är inte så nödvändigt att bära med sig, men det har vart tillfällen då jag svurit över att jag inte haft det med mig alls (det är därför det ligger usb-minnet i nyckelknippan nu).

Hade faktiskt vart lite schysst om man kunde köra TOR direkt från usb-pinnen också så man kan surfa anonymt var man än är… Nåt att testa.

Ska fixa ett lagom stort USB-minne nu och skapa denna säkerhetspinne.
Ha en bra kväll!

Anonyma e-mail

2008/09/12

Detta inlägget har sin grund i ett skolarbete jag skrev i gymnasiet i början av 2000-talet.

Debatten om FRA-lagen och massavlyssningen som den öppnar upp för har trolitvis inte undgått speciellt många. Att FRA skulle få möjlighet att avlyssna våra mejl gjorde många upprörda och att kryptera sina e-mail blev aktuellt, dock så sades det redan i ett tidigt skede att krypterad trafik inte var något problem för FRA.
Mark Klamberg m.fl. pekade i en debattartikel i DN bland annat på att det FRA skulle göra var sociogram, i grova drag diagram över vem som ”pratar” med vem. Mot denna typen av övervakning hjälper det inte att kryptera sina e-mail, eftersom innehållet är av underordnat intresse medan addressaterna är det intressanta.

Hur skyddar man sig mot detta?
Det finns naturligtvis flera sätt, där det mest effektiva är att helt enkelt sluta skicka e-mail. Ett mer realistiskt sätt är att anonymisera sina e-mail.
När jag skrev mitt ursprungliga arbete så fanns det en tjänst som erbjöd just anonyma e-mail-försändelser (ska kolla upp om den fortfarande finns). Tekniken som användes var egentligen ganska simpel, men det krävdes en del handpåläggning för att få det att fungera. Grunden var ett nätverk av mejlservrar (anon-servrar) som klarade av public-key krypterad trafik, som alla hade en publik nyckel för att dekryptera mejlheaders. För att förtydliga det hela så gör jag ett litet exempel där Adam vill skicka ett anonymt mejl till Bertil:

  1. Adam skriver sitt meddelande till Bertil
  2. Adam väljer ut ett antal anon-servrar, låt oss säga tre, som mejlet ska passera (vi kallar dem Sigurd, Tore, Urban).
  3. Han fortsätter med att bestämma i vilken ordning servrarna ska passeras (t.ex. Urban, Sigurd, Tore).
  4. Kedjan ser nu ut såhär: Adam->Urban->Sigurd->Tore->Bertil.
  5. Adam skapar nu mejlheaders (To: & From:) som för mejlet mellan Tore och Bertil och krypterar dessa och grundmejlet med Tore’s öppna nyckel.
  6. Han fortsätter att skapa headers som för mejlet från Sigurd till Tore och krypterar detta och föregående steg med Sigurds öppna nyckel.
  7. Därefter skapas headerfält från Urban till Sigurd, dessa och blocket från föregående steg krypteras med Urban’s publika nyckel.
  8. Slutligen så skapar han headers från sig själv till Urban och skickar ut mejlet på internet.
  9. När mejlet når Urban så dekrypterar servern det med sin publika nyckel och ser att det ska vidare till Sigurd.
  10. Samma sak sker i de två andra servrarna tills mejlet slutligen når Bertil som kan läsa det.

Tillsynes ett ganska enkelt system. Och för någon som är intresserad av vem Adam mejlar med finns det inte mycket att se eftersom det enda som skickas i klartext är steget mellan Adam om Urban respektive Tore och Bertil, således finns det inga spår som säger att Adam och Bertil kommunicerar med varandra. Detta är förutsatt att Adam inte har skrivit ut sin mejladress i mejlet eller satt en Reply-to med sin mejladress.

En nackdel med systemet är att om en av servrarna i ”molnet” skulle gå ner så kommer inte mejlet fram alls och ett felmeddelande (bounce) kommer sannolikt inte att nå Adam (om inte föregående server sparade att det bouncade mejlet kom från honom).

Tiden det tar för mejlet att komma fram till mottagaren ökar även för varje server som läggs till i kedjan.

Ytterligare en stor nackdel är att kommunikationen blir enkelriktad då hela systemet fallerar om Adam skriver sin mejladress i klartext eller i en Reply-to, eftersom en avlyssnare kan ser varifrån mejlet kommer lika enkelt som Bertil kan. Lösningen på detta skulle vara att Adam krypterar klartexten med Bertils publika nyckel och skriva ut sin mejladress i mejlet. Problemet här är att om Bertil inte använder anonservrarna av någon anledning så röjs kommunikationen mellan dem ändå.

Dock så vill jag minnas att det fanns en lösning på denna problematiken som gick ut på att Adam skapade ett mejlkonto på en speciell anonserver som sedan agerade gateway för ett svar från Bertil. Jag är inte helt säker på hur detta fungerade, men jag tror att det funkade något såhär:

  1. Adam har kontot ABCDEF på anongatewayen Xerxes och adressen ABCDEF@xerxes står i reply-to-headern i Bertils mejl, Xerxes har Adams riktiga mejladress och publika nyckel.
  2. Bertil författar sitt svar till Adam och skickar detta till ABCDEF@xerxes.
  3. Xerxes översätter ABCDEF till Adams riktiga mejladress och krypterar svaret med Adams publika nyckel.
  4. Därefter väljer Xerxes ut ett antal servrar och gör stegen från det föregående exemplet.
  5. Adam mottar det krypterade mejlet från den sista anonservern i kedjan och dekrypterar det med sin egen privata nyckel.

På detta sätt behålls anonymiteten mellan de båda och Bertil tillåts svara på Adams mejl, det enda som syns utåt är kommunikationen till gatewayen. Systemet erbjuder även skydd mot övertagna servrar i kedjan, då det enda servern kan ”se” är föregående server och nästa server i kedjan.

Nackdelarna lång tid och servrar som går ner kvarstår dock.
Tilläggas kan att det är ungefär på samma sätt som TOR-nätverket jobbar, med publika nycklar och uppsatta kedjor av ”routrar” som trafiken skuttar mellan.
Intressant?