Föregående

 Index

 Nästa

17 Säkerhetsarkitektur för Internet i Sverige

Arbetet med att beskriva säkerhetsarkitekturen har bedrivits i en mindre arbetsgrupp inom utredningen.

I gruppens uppgifter har ingått att göra en inventering av befintliga standarder på säkerhetsområdet och en uppskattning om vilka som används. I nuläget finns det ett flertal parallella, helt olika standarder på området. Det har ännu inte utkristalliserats någon "vinnare". Därför är det viktigt att se till att de olika systemen kan samarbeta och interoperera i en för detta gemensam infrastruktur. Gruppen lämnar också förslag om administration av säkerhetsnycklar.

På nästa sida finns en skiss över den säkerhetsarkitektur gruppens uppdrag omfattar. Det krävs skydd på olika nivåer i arkitekturen.

På tillämpningsnivån krävs textskydd, och det är den nivån som oftast diskuteras när frågor om digitala signaturer och kryptering kommer upp. På underliggande nivåer och på stamnätsnivån behövs emellertid också olika typer av säkerhetsfunktioner. Här finns exempelvis behov av att skydda själva nätet och nätets gemensamma funktioner som t.ex. adressinformation (DNS) och vägvalsinformation (routinginformation, routinguppdateringar).

I skissen anges kryptering på fem nivåer (siffrorna har sin motsvarighet på bilden):

1. kryptering av brev/meddelanden respektive signering av brev/meddelanden samt autentisering mellan användare och applikation,
2. skydd av data under transport utan autentisering av användare (förvanskningsskydd),
3. skydd av förbindelse mot angrepp,
4. autentisering (säker identifiering) av användare,
5. övervakning och konfigurering av materiel/utrustning fysiskt belägen inom ett område man inte har kontroll över (t.ex. fjärr-konfiguration av routrar).

Skissen är en beskrivning av var säkerhetsfunktionerna skall placeras i arkitekturen.

De säkerhetsfunktioner som krävs bygger på identifiering, signering och kryptering och är fundamentala.

Förslagen bygger på internationella standarder, men rör enbart den svenska delen av Internet, förutom de delar där svenska Internet ingår i ett globalt sammanhang som t.ex. när det gäller DNS.

Allt eftersom nya tillämpningar utvecklas ställer vi allt högre krav på att kommunikationen skall vara säker. De säkerhetsfunktioner som efterfrågas i den ökade användningen av Internet bygger i de allra flesta fall på någon användning av kryptoteknik. Fram till helt nyligen har kryptering varit viktigt enbart för statsmakterna, och då framför allt för militärer och diplomater. Vad som på kort tid har ändrat på detta förhållande är att andra aktörer ser behov av att skicka känslig information via tele- och datakommunikationsnät. Företag, myndigheter och enskilda utövar ett allt starkare tryck på leverantörer av IT-produkter och operatörer av nättjänster att kunna genomföra elektroniska affärer, elektronisk ärendehantering och service, distansarbete, kommunikation mellan privatpersoner etc, på ett säkert sätt, både inom och utanför Sverige.

All kommunikation är i grunden osäker. Näten är flexibla, samtidigt som de gör det möjligt att t.ex. avlyssna meddelanden och skicka meddelanden i andras namn. Användare kan alltså inte förvänta sig att öppna och allmänna nät är säkra och måste därför själva vidta åtgärder för att skydda sin information och därmed också kunna få säkerhet hela vägen från avsändare till mottagare. En del åtgärder måste emellertid också appliceras på själva nätet och de gemensamma funktioner som har att göra med drift och underhåll av nätet.

De som har det tekniska ansvaret för nätdrift kan räkna upp en lång rad situationer där information som kommuniceras mellan datorer måste skyddas från avlyssning eller modifiering. Några exempel:

• En operatör måste kunna signera routinguppdateringar så att andra operatörer kan verifiera att dessa är korrekta.
• Det måste finnas ömsesidiga avtal om routingutbyte mellan operatörer.
• En operatör behöver ha en säker förbindelse till kunders routrar, och en kunds router måste vara skyddad.
• För att ta reda på vem som äger en viss IP-adress skall varje operatör kunna gå till en gemensam databas för att se vilka nät som varje operatör annonserar (routing registry).
• Det finns behov av distribuerad autentisering av uppringande kund (roaming).
  

Informationen i DNS på olika nivåer måste skyddas mot förvanskning. Hur kan vi skydda DNS-noden .se? I dag finns det inget enkelt sätt att verifiera att den information som har hämtats från DNS är autentisk och inte har ändrats. Detta gör det möjligt att lura användare genom att lägga in falsk information i DNS och på så vis ge sig ut för att vara någon annan.

En gemensam tjänst som bör finnas tillgänglig i Sverige är tillgång till en tidsserver där man kan få tillgång till exakt tid. Tidsstämpling är en viktig fråga när det gäller exempelvis spårbarhet, giltighet för kryptonycklar m.m. Mer om en sådan tjänst finns i avsnitt 13.

Det finns olika tekniska lösningar för att realisera olika säkerhetstjänster. De säkerhetstjänster som är förknippade med elektroniskt informationsutbyte är integritet och autenticitet, oavvislighet samt konfidentialitet. Dessa säkerhetstjänster beskrivs i bilaga 17.

Så gott som alla tekniska lösningar för att realisera säkerhetstjänsterna har inslag av kryptering. Vad kryptering är och olika metoder för detta beskrivs också i bilaga 17. Det finns symmetrisk kryptering respektive asymmetrisk kryptering. Digitala signaturer förutsätter i nuläget användning av asymmetrisk kryptering.

En bra krypteringsalgoritm är en algoritm där det inte finns något enklare sätt att forcera den än att prova alla befintliga nycklar, och där antalet nycklar är så stort att det inte är realistiskt att prova dem alla.

Det är naturligtvis viktigt att den svenska delen av Internet har starka krypteringsalgoritmer. Detta åstadkoms bäst genom att använda öppna standardalgoritmer som har blivit testade och undersökta av kryptografer världen över under en tillräckligt lång tid och då visat sig motståndskraftiga mot attacker. Dessutom är det angeläget att använda internationellt kända algoritmer så att det går att kommunicera med parter utanför Sverige.

Hemliga algoritmer är inte lämpliga att använda då det inte går att få reda på vare sig hur de fungerar, hur de skall implementeras i programvara eller användas vid kommunikation med någon utanför landets gränser.

Ett problem är att det inte går (med få undantag) att bevisa att en algoritm är bra, utan bara att den inte är dålig på något känt sätt. Detta gör att standarder och tillämpningar inte bör vara låsta till en viss algoritm, utan att det skall vara enkelt att välja vilken algoritm som skall användas och att byta ut en algoritm som börjar visa sig tveksam.

Det finns anledning av överväga hur många algoritmer som skall vara i bruk samtidigt. Vid användning av endast ett minimum av algoritmer blir skadan stor om någon av dem skulle visa sig vara osäker. Vid många algoritmer får man dålig kompatibilitet, samtidigt som risken teoretiskt ökar för att någon skall visa sig vara osäker.

I varje verksamhet måste det finnas ett åtgärdsprogram om en algoritm blir tveksam eller central nyckel skulle röjas. Om tillämpningen är sådan att skadorna blir stora om nyckeln röjs, måste det dessutom finnas särskilt starka metoder att skydda den centrala nyckeln.

Checksummealgoritmer, eller hashfunktioner, är en funktion som tar en godtyckligt lång bitföljd och beräknar en checksumma, dvs en kortare bitföljd med fix längd. Hashfunktioner bör vara kollissionsfria, det vill säga det skall vara i det närmaste omöjligt att hitta två olika bitföljder som ger samma checksumma.

Hashfunktioner kan användas för signering och verifiering. Secure Hash Algoritm 1 (SHA 1) respektive Message Digest 5 (MD5) är de i dagsläget två dominerande algoritmerna. Tillgängliga programvaror måste både kunna känna igen och kunna verifiera båda.

Utredningsgruppen rekommenderar att generering av checksummor sker enbart med SHA1 i nya tillämpningar.

Pseudokollisioner har påträffats i MD5, vilket gör att man kan befara en viss osäkerhet.

Ett villkor för att en krypteringsalgoritm skall kunna stå emot försök att analysera (forcera) kryptotext är alltså att det finns många nycklar till algoritmen. Om det bara finns ett fåtal nycklar så är det lätt att prova att dekryptera med alla nycklar och på det sättet återskapa klartexten. Antalet nycklar måste således vara tillräckligt stort för att det inte ens med mycket snabba datorer skall gå att hitta rätt nyckel inom överskådlig tid.

I stället för att ange antalet nycklar brukar man prata om nyckellängder. Den enhet som nyckellängden anges i kallas för bitar. Varje extra bit i nyckeln innebär att det blir ytterligare dubbelt så många nyckelkombinationer att testa. En 8-bitsnyckel ger 256 kombinationer, en 16-bitsnyckel ger över 65 000 möjliga nycklar, en 30-bitars nyckel motsvarar ungefär en miljard. DES-algoritmen (Data Encryption Standard) är ett exempel på en symmetrisk algoritm, och har med 56 bitars nyckel 72 058 000 miljarder möjliga nycklar.

Om nyckeln är lika lång som den krypterade texten blir det omöjligt att utföra kryptoanalys, dvs att forcera och tolka kryptotexten. Ju kortare nyckel, desto lättare att analysera kryptot.

Nyckellängd är avhängigt av krypteringsmetod (asymmetrisk eller symmetrisk) och inte direkt jämförbara. Säkerheten i ett symmetriskt kryptosystem beror på nyckelns längd och algoritmens konstruktion. Det går att beräkna hur lång tid det tar att prova alla nycklar.

För att uppnå ett starkt textskydd med dagens använda algoritmer, kryptoanalyser och datakraft bör nyckellängden i ett symmetriskt kryptosystem uppgå till minst 70 bitar.

För asymmetriska krypteringsalgoritmer (öppen nyckel-system) används en annan metod vid kryptoanalys varför nyckeln måste vara betydligt längre. För RSA bör den helst vara minst 1024 bitar lång.

Om en nyckel lagras tillsammans med den information den skall skydda spelar det inte någon roll hur bra en krypteringsalgoritm är. Att säkert överföra nycklar mellan kommunicerande parter är en av de största utmaningarna när det gäller kryptering.

Det är viktigt att klargöra alla komponenter och funktioner i nyckelhantering, innan det går att skapa en nyckeladministration för något ändamål.

Det är också viktigt att klargöra hur man skall gå tillväga i de olika situationerna:

Varje nyckel måste kunna identifieras unikt. Det måste alltså stå klart från början vilken information som skall finnas i ett certifikat (I bilaga 17 beskrivs certifikat). Nyckeln namnges när den skapas, och den identitet den får behöver inte vara samma som när den distribueras. Dvs, nyckel-identitet behöver inte bytas ut för att man byter lagringsplats för distribution. Ett visst certifikat kan unikt identifieras med en kombination av utfärdarens identitet och ett serienummer. En person kan ha flera certifikat så det måste också gå att unikt identifiera personer. En enhetlig standard för hur innehavarens identitet anges är att föredra. I Sverige har vi personnummer som skulle kunna användas för det ändamålet.

Krypteringsnycklarnas längd och tekniska kvalitet är av stor vikt. Men samtliga moment från skapande, paketering, distribution och slutligen användning, är lika viktiga för att helheten skall ge det "bevisvärde" som är grunden för införande av säkerhetstjänsterna identifiering/verifiering av individer samt framställning av elektroniska dokument försedda med digitala signaturer. För att belysa skillnaden mellan två säkerhetsnivåer beskriver vi detta genom att tala om "hårda" respektive "mjuka" nycklar.

Med hårda nycklar menas de fall där krypteringsnycklarna efter framställning lagras och exekveras i maskinvara. Det är vanligtvis utrustning gjord för ändamålet som t.ex. "black box" PC-kort eller aktiva kort. Med mjuka nycklar menas följaktligen att krypteringsnycklarna skapas, lagras och används i ren programvara.

Tekniskt sett skiljer sig inte dessa nycklar från varandra. Det kan t.o.m. vara enklare och snabbare att administrera längre nycklar i programvara än i maskinvara. Men i det fall en tredje part skall ta ansvar för hur en viss nyckel används eller snarare, har använts, får detta betydelse.

Vad som gäller i det enskilda fallet är kopplat till den policy som gäller för nyckeladministrationen. Policyn avgör vilken tilltro omvärlden kan tänkas vilja fästa vid en transaktion som signerats med en viss nyckel. Därför måste det framgå av certifikatet som skyddar användarens öppna nyckel, vilken policy som gäller för just denna nyckel. Policyn omfattar i detta sammanhang inte bara om det är en hård eller mjuk nyckel, utan även i övrigt vilka administrativa krav som skall ha uppfyllts för att den skall kunna knytas till den part vilken nyckeln utfärdats för. Enligt nuvarande internationellt språkbruk ingår även i en policy information om kraven för viss "tjänsteklass".

Behovet av betrodda tredjepartstjänster (Trusted Third Party, TTP) som stöd för de växande kraven på att kunna säkerställa äkthet och konfidentialitet i elektronisk information är uppenbart och många olika typer av sådan verksamhet växer fram i olika delar av världen.

De uppgifter som en TTP kan utföra är många och varierande, t.ex.:

• Certifieringsorgan (Certification Authority) för öppen nyckel-certifikat
• Certifieringsorgan för provning och utvärdering av systemimplementationer och produkter
• Incidenthanteringsorgan såsom t.ex. CERT (Computer Emergency Response Team)
• Elektroniska notariatstjänster (tidsstämpling, oavvislighet)
• Nyckeldeponering för återskapande av data vid förlust (data recovery)

De implementationer av TTP:er som finns har vuxit fram oberoende av och isolerade från varandra. I det globala perspektivet finns det emellertid behov av att etablera kontakter mellan olika TTP:er som erbjuder en rad olika tjänster under olika typer av lagstiftning.

En TTP kan erbjuda ett antal tjänster, var och en tillhandahållen av oberoende organisationer på kommersiell basis. En TTP-struktur kan vara modulärt uppbyggd och ha gränsytor som tillåter en flexibel konfiguration av systemet med hänsyn till de behov som finns hos olika roller och organisationer.

Användningen av TTP:er är beroende av det grundläggande kravet att TTP äger användarnas förtroende att utföra vissa funktioner. Dessutom kan en TTP också gå i god för trovärdigheten hos en annan användare genom att garantera dennes identitet. Det har den fördelen med sig att förtroende mellan olika objekt inom en TTP:s domän kan upprättas utan att objekten behöver göra bilaterala överenskommelser.

Bland annat har man inom ETSI (European Telecommunications Standards Institute) utarbetat ett dokument med tekniska krav för TTP-tjänster, Requirements for Trusted Third Party Services, som kan få viss betydelse för utvecklingen på området inom Europa.

Verifiering av certifikat och digitala signaturer skall skiljas från frågan om deponering av privata (lagrings)nycklar. Sådan deponering som innebär att man lämnar ifrån sig sin privata (lagrings)nyckel till någon annan skall vara frivillig och ske med syftet att kunna trygga återskapandet av lagrad information i en situation då det inte är möjligt att använda originalet.

Inom Europa pågår arbete med att finna tekniska lösningar för att kunna skapa signaturnycklar som inte går att använda som konfidentialitetsnycklar. Syftet med detta är att avdramatisera frågan om användning av kryptering då det anses att användning för att skapa digitala signaturer ur politisk synvinkel är mindre kontroversiell än användning för att skapa konfidentialitet.

Rätten till skydd av autenticitet, (data)integritet och mot intrång bör vara absolut. Samtidigt har rättsväsendet och samhället intresse av att rätten till konfidentialitet och anonymitet bör vara möjlig att häva vid misstanke om grov brottslighet.

En utbredd användning av asymmetriska kryptosystem kräver stöd i en infrastruktur för nyckelhantering, också kallad Public Key Infrastructure, eller kort och gott PKI. Problemet i ett asymmetriskt system med certifikat och öppna nycklar är att det är omöjligt att vara säker på att en viss persons öppna nyckel i själva verket inte är en förfalskning. Det är certifikatet som intygar bindningen mellan nyckel och individ. (Se bilaga 17 för en definition av certifikat).

Lösningen på problemet är att placera nyckeln i ett certifikat som innehåller den öppna nyckeln plus en försäkran gjord genom någon annans digitala signatur. Denna "någon annan" kallas Certification Authority eller CA. Certifikatet flyttar trovärdigheten till den nya signaturen. Om den visar sig vara verifierbar och korrekt, så finns det större anledning att tro att den öppna nyckeln är äkta.

Om du inte heller litar på CA så måste du verifiera signaturen på CA:s digitala certifikat osv. Allt certifikaten gör är att flytta trovärdigheten uppåt i kedjan. Därigenom bildas en s.k. chain of trust. En stor utmaning i sammanhanget är just att utveckla den hierarki av förtroende som behövs för verifiering av certifikat.

I dagsläget kan de många tillämpningar som använder sig av certifikat endast hantera en nivå i en hierarki, t.ex. är detta fallet med webbläsare som kopplar mot en webbserver via SSL.

Hierarkier är inte den enda lösningen. Pretty Good Privacy (PGP), den spridda krypteringsprogramvaran för meddelandehantering, använder ett nätverk av signaturer för att garantera varje öppen nyckel. Den engelska termen för detta är "web of trust". Den öppna nyckeln signeras av dem som litar på att du är du, antingen genom att de känner dig, eller genom att du kan visa vem du är.

Naturligtvis är frågan om förtroende ömsesidigt. Det ställer krav på användarna att de tar ansvar för att hantera nycklar korrekt och att de ser till att de vidtar alla nödvändiga åtgärder för att bibehålla den hemliga nyckeln hemlig. Det ansvarstagandet kommer förmodligen att vara det besvärligaste och svåraste att åstadkomma, eftersom majoriteten användare inte är särskilt medvetna om betydelsen av informationssäkerhet överhuvud taget.

När man bygger en förtroendekedja måste man ta med i beräkningen:

1. Hur nycklarna är lagrade och hanteras, efter vilka policies två inblandade nycklar har utgivits.
2. Hur hitta en kedja av verifierade certifikat mellan dessa två nycklar, genom att olika variabler i policyn ger en vikt för varje verifierat certifikat, som sammantaget avgör hur mycket du kan lita på kedjan i sin helhet.

Parametrar vars vikt bestäms av policyn är hur mycket förtroende som ligger i varje steg, antalet steg, hur nyckeln är lagrad och hur mycket man litar på något, exempelvis en CA.

Policyn bestäms av vilken tillämpning det gäller. Den skall publiceras och i vissa fall också kunna påverkas, accepteras eller förkastas av användarna.

I bilden nedan återfinns en beskrivning av de funktioner som måste ingå i en infrastruktur för nyckelhantering (Public Key Infrastructure).

1. Nycklar som skapas (genereras) måste innehålla tillräckligt många bitar med ett standardiserat nyckelformat. Nycklar kan skapas av vem som helst. Nycklarna är initialt mycket sårbara, men genom att de signeras så erhåller de ett skydd.
   
   Generering/signering bör alltså ske samlat (2B). I fallet PGP sker det genom "självsignering", den hemliga delen signerar den öppna delen, varefter man kan gå till en CA som intygar att den öppna nyckeln tillhör den person som man påstår sig vara. I fallet X.509 är det vanligare att CA såväl skapar som signerar nycklarna initialt. I fallet med aktiva kort som lagringsplats för nycklar blir distributionskedjan enklare om man låter en CA eller annan tredje part producera nycklarna åt användaren.
   
2. a) Den hemliga nyckeln måste lagras på ett säkert sätt, men den måste fortfarande kunna användas effektivt.

2 b) Den öppna nyckeln signeras av en CA, som har till ansvar att intyga att den tillhör den som det påstås.

3. En kopia av den hemliga nyckeln kan arkiveras hos någon eller något som erbjuder den funktionen som en tjänst. Detta för att kunna återskapa klartext även om den egna privata nyckeln av någon anledning inte kan användas (glömt lösenord, någon har slutat sin anställning, filen där nyckeln lagras har kraschat etc).
4. Nyckeldistribution görs för att den öppna nyckeln måste göras tillgänglig för de som behöver använda den och för att kunna skapa förtroendekedjor (chain of trust) eller -nät (web of trust). Distributionen kan göras på en rad olika sätt, via kataloger, visitkort, personliga kontakter, tidningar etc.
5. Revokering är den viktigaste tjänst som användaren har till sitt förfogande för att verifiera att en nyckel fortfarande är korrekt och giltig. Nycklar kan behöva revokeras av olika anledningar t.ex. om ägaren förlorar kontrollen över nyckeln när ett aktivt kort tappas bort, eller om någon får sin dator stulen där nyckeln ligger lagrad. Då måste det finnas en möjlighet att ogiltigförklara sin hemliga nyckel, genom att revokera nyckelparet.
   
   Revokeringsinformation (Certification Revocation List, CRL) ger svar på frågor om nycklars giltighet. Svaret måste man också kunna lita på, alltså måste också det kunna säkras. Svaret måste signeras med revokeringsserverns nyckel, som också måste kunna verifieras etc. Processen upprepas intill dess att man är förvissad om att informationen är korrekt. Det är den som utfärdar certifikat som också måste tillhandahålla revokeringsinformation. Här återstår en hel del att lösa. En är frågan hur användare kan finna rätt CRL. En annan fråga är att dessa revokeringslistor med tiden blir tämligen omfattande, kräver stort utrymme och riskerar att göra verifieringen långsammare.
6. Användning av nycklar/verifiering av certifikat (se nästa figur).

1. Förutsättningen är att användaren litar på nyckel 4 signerad av nyckel 5.
   
2. Användaren får nyckel 0 signerad med nyckel 1. Litar användaren på nyckel 0? Svar: Nej.
   
3. Användaren hämtar nyckel 1 (eftersom nyckel 0 var signerad med nyckel 1) Användaren får nyckel 1 signerad med nyckel 3. Litar användaren på nyckel 1. Svar: Nej.
   
4. Användaren hämtar nyckel 3 eftersom nyckel 1 signerats med nyckel 3. Användaren får nyckel 3 signerad med nyckel 4. Litar användaren på nyckel 3. Svar: Nej.
   
5. Nyckel 3 är signerad med nyckel 4. Användaren litar på nyckel 4, vilket gör att han också kan lita på nyckel 3, nyckel 1 och nyckel 0.

Med hänsyn till att PGP används av många finns det behov av att erbjuda privatpersoner möjligheten att få sin PGP-nyckel signerad på ett enkelt sätt och i stor skala. Nedanstående modell utgör alltså ingen generell PKI-modell. Den beskriver bara ett sätt att realisera en PKI för PGP. Posten är i detta fall bara ett exempel, det kan lika väl vara en annan organisation med stor geografisk spridning t.ex. folkbiblioteken.

Nisse Tuta skapar och signerar initialt sina nycklar. Nycklarna tar han med sig till postkontoret i Nätby där han bor. Posten kollar Nisses identitet samt signerar Nisses nyckel med hjälp av posten i Nätbys certifikat. Posten i Nätbys certifikat är signerat av Posten HK. Posten HK har certifierats att vara CA i Sverige. Certifieringen kan till exempel innebära att Posten HK:s nyckel har signerats med Swedacs nyckel. När nu Nisse skall skicka ett signerat meddelande till RSV så kan RSV verifiera hela kedjan och därigenom lita på att Nisses nyckel är korrekt.

Det bör finnas PGP-nyckelservrar centralt placerade. Behovet av tillgång till individers öppna certifikat ställer krav på en funktion som möjliggör detta. Det är dock i dagsläget för tidigt att säga något om hur dessa servrar skall implementeras och finansieras.

För att initiera en förtroendekedja måste man ha distribuerat en nyckel. Idag sker det, t.ex. inom SSL, på ett osäkert sätt. Det är oklart hur det skall göras, och det är en funktion som måste specificeras av den som bygger en PKI. Ett alternativ finns, nämligen att sprida nyckeln på ett osäkert sätt, men ge möjlighet för användaren att verifiera med användning av ett s.k. fingerprint eller en checksumma.

Hur mycket kan du lita på ett certifikat? Vilka garantier skapar de egentligen? De CA som finns måste kunna verka på kommersiella grunder. Det innebär att de tjänster de tillhandahåller måste balansera mellan trovärdighet och ekonomisk försvarbarhet.

Det är CA:s uppgift att distribuera sin öppna nyckel på ett säkert sätt till de användare som behöver kunna lita på den. Ett sätt är att när användaren får sin nyckel signerad av CA så erhåller användaren också CA:s öppna nyckel. Flera olika sätt att sprida den öppna nyckeln bör användas för att öka förtroendet; genom publicering i tidningar, radio, etc.

I nedanstående tabell finns en förteckning över befintliga säkerhetsstandarder för användning på Internet. Tabellen omfattar en beskrivning av deras funktion, styrka, svaghet och geografisk spridning. Tabellen bygger på de fakta som gäller juni 1997.

Ett certifikat är den informationsmängd som, signerad av en CA, skapar en bindning mellan exempelvis en person och en nyckel (ett nyckelpar). En mer detaljerad beskrivning av detta återfinns i bilaga 17.

I dagsläget finns det två dominerande certifikatstyper, PGP-certifikat respektive X.509-certifikat. Båda varianterna skall kunna ingå i infrastrukturen. En användare skall ha möjlighet att skaffa såväl PGP- som X.509-certifikat från en CA.

Ett problem med X.509-certifikat är att de innehåller olika information i olika implementationer. Det finns behov vid användning av X.509 att standardisera innehållet i ett certifikat. Särskilt viktigt är det att nyckelidentifieraren, (Distinguished name, DN), specificeras. Nyckelidentifieraren bör innehålla organisationsnummer för organisationer, personnummer för personer (eller annan unik identifierare för individer).

Arbete har initierats inom IETF med att standardisera nyckelinnehållet så att samma nyckel kan användas både i X.509 och PGP, dock med olika format. Separat arbete pågår vad gäller standardisering av nyckelidentitet för koppling till domännamn.

Tills dess att detta arbete är avslutat måste standardisering ske per tillämpning. Detta sker exempelvis inom SEIS. SEIS bör fortsättningsvis aktivt delta i arbetet inom dessa två områden, samt anpassa sitt eget arbete till den i framtiden fastslagna standarden, när den kommer.

Den som är innehavare av zonen .se blir därmed root-CA för denna hierarki och DNS kan här användas för nyckeldistribution och verifiering av nycklar. Hos zonen "." (punkt) kommer i sin tur .se-certifikatet att kunna verifieras. Det kan dröja innan det existerar någon nyckel och certifikat för ".", men genom att använda nyckeln för .se är vi inte heller beroende av detta.

För att få till stånd en kontrollorganisation kring dem som vill erbjuda CA-tjänster på den svenska marknaden, föreslår utredningsgruppen att SWEDAC bör få i uppdrag att utreda om det med stöd av Lagen om teknisk kontroll kan skapas en ordning där SWEDAC bedömer och ackrediterar provnings- och certifieringsorgan med uppgift att prova och certifiera dessa CA.

Styrelsen för ackreditering och teknisk kontroll (SWEDAC) är central förvaltningsmyndighet för teknisk kontroll och mätteknik, och nationellt ackrediteringsorgan för ackreditering av laboratorier, certifierings- och kontrollorgan.

Certifieringsprocessen kan delas upp i fyra delar: Examinering, bedömning, certifiering och övervakning. Examineringen bör bestå av en bedömning av organisatoriska förhållanden, kompetens, ekonomi samt praktiska tester av tekniska implementationer. En certifieringsordning som endast omfattar dokumentgranskning accepteras inte. Efter genomförd certifiering har certifieringsorganet ansvar för att övervaka hur den certifierade CA:n uppfyller certifieringsvillkoren under certifikatets giltighetstid, som kan omfatta ett visst antal år.

SWEDAC tillkallar enligt sin instruktion tekniska kommittéer med uppgift att vara rådgivande i de tekniska frågor som SWEDAC bestämmer, och som faller inom myndighetens ram. Främst gäller det frågor som berör ackreditering och tillsyn av laboratorier, certifieringsorgan och kontrollorgan, utvecklingsprojekt, standardisering, investeringar, utbildning m.m. Det är i detta sammanhang viktigt att de personer som bemannar en teknisk kommitté för att vara rådgivande vid ackrediteringen av de organisationer som skall granska och certifiera CA sätts samman med såväl djup som bred kompetens inom juridik, säkerhet och om Internettekniken och dess villkor.

För att slippa vandra genom hela förtroendekedjan är det lämpligt att utnyttja möjligheten med korscertifikat. Korscertifikat används vanligtvis när inte alltför många organisationer samverkar. Detta är en möjlighet att skapa genvägar vid verifieringen av certifikat. Normalt är sådana certifikat ömsesidiga, dvs organisationerna certifierar varandra. Det bygger på att parterna har förtroende för varandra (jag litar på dig, du litar på mig).

De för utredningsgruppen viktigaste rättsliga delarna bedöms vara att fastställa begrepp som omnämns i bilaga 17 under "Elektronisk dokumenthantering", i första hand begreppet digital signatur. Även internationellt är det den digitala signaturen som står i centrum för intresset. Resultatet av regeringskansliets referensgrupp i krypteringsfrågor förväntas styra prioriteringen inom det rättsliga området.

Inom Internetsäkerhetsområdet finns det i dagsläget ett stort antal standarder som är under utveckling och oftast inte omsatts i någon större mängd tillämpningar. Det finns också ett stort antal konkurrerande standarder, dvs. standarder som är avsedda att lösa samma problem, på olika sätt, och som därmed inte är kompatibla. Utvecklingen kommer förhoppningsvis att gå i en riktning så att enighet kan uppnås inom några avgörande områden, men vi är inte där ännu.

Vad gäller exempelvis certifikatsstandarder så finns det i dagsläget två konkurrerande standarder, PGP och X.509. Båda används men för olika tillämpningar. Användningen av dessa ökar stadigt i tillväxt, och det finns inget som tyder på att den ena eller andra kommer att gå segrande ur kampen. Det kan till och med vara så att ett alternativ uppstår som tar vara på fördelarna hos de båda andra. Ytterligare en möjlighet är att nyckelinnehållet kommer att vara ett och samma men formaten olika, dvs samma nyckel kan användas både i PGP och X.509-tillämpningar. Användningen av dessa standarder i tillämpningar på Internet diskuteras inom IETF.

Utredningsgruppen föreslår att frågan om en modell för en generell infrastruktur för nyckelhantering belyses inom ramen för det uppdrag om bl.a. IT-säkerhetsstrategi som regeringen lagt på Statskontoret i september 1997.

En av de grundläggande komponenterna i användningen av öppen nyckel-system är tillskapandet av en Public Key Infrastructure (PKI). Utan en gemensam struktur för detta kommer Sverige att hamna i en situation likt den på 70-talet med isolerade system och tillämpningsspecifika lösningar som inte kan fungera tillsammans.

Om man i Sverige tänker genomföra ett allmänt införande av elektroniska ID-kort är en PKI nödvändig. Denna måste fungera för såväl handel, banktransaktioner och vid kontakt med myndigheter som vid behörighetskontroll.

För att kunna få fram ett regelverk på området måste redovisningen av rollerna TTP, CA, etc vara helt stringent.

Med funktioner för verifiering av certifikat avses att såväl certifikatsservrar som accessmetoder måste definieras, som klarar användning i stor skala. Exempel på accessprotokoll är LDAPv3 (Light Directory Access Protocol, version 3), eller HKP (Horowitz Key Protocol). Utan sådana funktioner som stöd för verifiering av certifikats äkthet eller giltighet har vi ingen fungerande infrastruktur.

Det måste finnas programvaror som stödjer den lösning vi väljer i Sverige. En svensk lösning måste ha stöd i standardprogramvaror (utvecklade utanför specifika projekts ramar).

Ett trettiotal stater har genom att underteckna Wassenaar-arrangemanget kommit överens om att motverka spridningen av produkter som kan användas både för militära och civila ändamål, s.k. dual use-produkter. Krypteringsprodukter hör till denna kategori. Syftet är att förhindra, eller åtminstone försvåra, att stater som stödjer terrorism eller där terrorism eller annan allvarlig brottslighet, t.ex. narkotikabrott förekommer, skall få tillgång till sådan teknik.

Sverige deltar i detta samarbete och inom EU regleras handeln mellan EU:s medlemsstater och med tredje land. Det medel som används för kontroll av exporten bygger på ett system med licensgivning. Licenser kan beviljas för export av dual use-produkter efter prövning av ansökan om sådan licens från den som vill exportera.

Programvara för kryptering är undantagen från licenskravet om det är allmänt tillgänglig för allmänheten genom att den säljs via detaljist över disk, via postorder eller telefonförsäljning. Den skall också vara konstruerad så att användaren själv kan installera programvaran utan väsentlig medverkan av försäljaren. Detta är innebörden i den s.k. General Software Note (GSN). Mer om vad som gäller för dessa frågor står att finna i SFS 1994:2060, Förordning om strategiska produkter.

En begränsning av användningen av kryptering hämmar införandet av krypteringsteknik på Internet av gällande exportrestriktioner. Sverige bör undersöka möjligheterna att lätta på dessa restriktioner och verka för att andra gör likadant, åtminstone mellan EU:s medlemsstater. Med hänsyn till svenska företags intressen av att kunna importera produkter från andra länder som undertecknat Wassenaar-arrangemanget kan emellertid inte Sverige ensidigt avskaffa exportrestriktionerna. Ett ensidigt avskaffande skulle kunna rubba andra länders förtroende för Sverige och försvåra import av högteknologi. Detta är en politisk fråga som är föremål för diskussioner inom regeringskansliet.

Många tillämpningar som använder krypteringsalgoritmer använder sig i dag av RSA-algoritmen. Den algoritmen är patentskyddad och programvaror som skall använda RSA måste erhålla licens från patentinnehavaren, RSA Data Incorporated. Patentskyddet för RSA upphör 2003.

Inom IETF har man på senare tid uppmanat användningen av algoritmen Diffie-Hellman/El Gamal vid utveckling av nya programvaror, en algoritm vars patentskydd gick ut den 6 september 1997.

Stöd för RSA bör emellertid finnas i programvaror även i fortsättningen för att kunna acceptera information krypterad med RSA, dvs. man måste kunna ta emot information med RSA och DH/El Gamal, medan det är tillräckligt att kunna skicka enbart med DH/El Gamal.

Utredningsgruppen anser emellertid inte att det finns anledning att bromsa existerande arbete på området inom exempelvis Bankföreningen, SEIS, Postgirot, universitetsvärlden m.fl. Vi måste acceptera att fram till dess att en gemensam lösning finns är det enda tillgängliga alternativet att utveckla tillämpningsspecifika lösningar.

 Föregående    Index    Nästa