Regler för utgivning och hantering av elektroniska certifikat · Denna version 1.0 av ”Regler...

Regler för utgivning och hantering av elektroniska certifikat Sveriges Riksbank Certificate Policy MEDIUM ASSURANCE CERTIFICATES VERSION 1.0

SVERIGES RIKSBANK SE-103 37 Stockholm (Brunkebergstorg 11) Tel +46 8 787 00 00 Fax +46 8 21 05 31 [email protected] www.riksbank.se

DNR

Personbundna certifikat med hög tillförlitlighet avsedda för säker identifiering, sekretesskydd samt elektroniskt godkännade. Medium Assurance Certificates to be used for authentication, confidentiality and approval purposes

2 [42]

INNEHÅLLSFÖRTECKNING 1 Inledning ............................................................................................................ 4

1.1 Översikt ......................................................................................................... 4 1.2 Identifiering .................................................................................................... 5 1.3 Målgrupp och tillämplighet............................................................................... 5 1.4 Kontaktuppgifter............................................................................................. 8

2 Allmänna bestämmelser ....................................................................................... 9 2.1 Allmänna åtaganden........................................................................................ 9 2.2 Ansvar.......................................................................................................... 11 2.3 Ekonomiskt ansvar......................................................................................... 11 2.4 Tolkning och verkställighet ............................................................................. 11 2.5 Avgifter........................................................................................................ 11 2.6 Publicering och förvaringsplats........................................................................ 12 2.7 Granskning (revision)..................................................................................... 13 2.8 Sekretess ...................................................................................................... 13 2.9 Immateriella rättigheter.................................................................................. 14 2.10 Avtal........................................................................................................ 14

3 Identifiering och identitetskontroll ....................................................................... 15 3.1 Initial registrering........................................................................................... 15 3.2 Identitetskontroll vid rutinmässig nyckeluppdatering ......................................... 16 3.3 Identitetskontroll vid nyckeluppdatering efter spärr........................................... 16 3.4 Identitetskontroll vid spärrbegäran .................................................................. 16

4 Operationella krav............................................................................................. 18 4.1 Ansökan om certifikat.................................................................................... 18 4.2 Utfärdande av certifikat ................................................................................. 18 4.3 Acceptans av certifikat................................................................................... 18 4.4 Definitiv och temporär spärr av certifikat.......................................................... 18 4.5 Loggning ...................................................................................................... 20 4.6 Arkivering..................................................................................................... 22 4.7 Nyckelbyte ................................................................................................... 23 4.8 Åtgärder vid händelse av kris eller katastrof...................................................... 23 4.9 Upphörande av Utfärdarens verksamhet.......................................................... 24

5 Fysisk säkerhet och säkerhetskontroll ................................................................... 25 5.1 Fysisk säkerhet.............................................................................................. 25 5.2 Procedurorienterad säkerhet........................................................................... 26 5.3 Säkerhetskontroll av personal ......................................................................... 28

6 Teknisk säkerhet................................................................................................ 29 6.1 Generering och installation av nycklar.............................................................. 29 6.2 Skydd av privat nyckel ................................................................................... 30 6.3 Andra aspekter på hantering av nyckelpar........................................................ 31 6.4 Aktiveringsdata ............................................................................................. 32 6.5 Säkerhet i datorsystem ................................................................................... 33 6.6 Säkerhet under levnadscykel........................................................................... 33 6.7 Nätverkssäkerhet........................................................................................... 34 6.8 Kryptografisk säkerhetsmodul ......................................................................... 34

3 [42]

7 Certifikat- och CRL-profiler ................................................................................ 35 7.1 Formatversioner och profiler för certifikat......................................................... 35 7.2 CRL-profil..................................................................................................... 36

8 Förvaltning av regler.......................................................................................... 37 8.1 Förfarande vid ändring av regler ..................................................................... 37 8.2 Version och versionshantering ........................................................................ 38 8.3 Regler för publicering och spridning ................................................................ 38 8.4 Förfarande vid godkännande av utfärdardeklaration (CPS)................................. 38

9 Terminologi, förkortningar och definitioner som används i detta dokument............. 39

Medium Assurance Certificates

Inledning 4 [42]

1 Inledning

1.1 Översikt

Detta dokument är en certifikatpolicy vars struktur följer IETF RFC 25271 och omfattar regler för utgivning och hantering av elektroniska certifikat.

Dokumentet är en kravställning med en lägsta nivå av säkerhets- och funktionskrav, procedurer samt rutiner för hur Riksbanken som utfärdare skall utfärda och hantera certifikat av typen ”Medium Assurance” med tillhörande kryptografiska nycklar. Riksbanken i egenskap av utfärdare skall tillämpa dessa regler vid:

• utfärdande av certifikat av typen ”Medium Assurance”

• tillhandahållande av tjänster för spärr av utfärdade certifikat av typen ”Medium Assurance”

• tillhandahållande av information för spärrkontroll av utfärdade certifikat av typen ”Medium Assurance”

Utfärdandet av certifikat och nycklar av typen ”Medium Assurance” syftar till att certifiera en fysisk persons identitet samt bibehålla riktighet i information och processer som vid kompromettering kan leda till finansiell förlust, försämrat förtroende för Riksbanken eller få juridiska påföljder. Vidare syftar certifikat och nycklar till att skydda hemlig och sekretessklassad information från avslöjande som kan leda till försämrat förtroende för Riksbanken, juridiska påföljder eller på annat sätt orsaka förlust och skada på ekonomiska värden, egendom eller personal. Exempel för verksamhetsanvändning av ”Medium Assurance” certifikat är bl.a. förstärkt identifiering och autentisering vid åtkomst av informationssystem, säker e-post med skyddsfunktioner för sekretess, riktighet och oavvislighet samt sekretesskydd och riktighetsskydd för information lagrad i datafiler. Funktioner och stöd för signering och kryptering i applikationer ska även möjliggöra ett förstärkt skydd genom utökad spårbarhet.

Certifikat utgivna enligt denna policy är avsedda för interna användare samt ett begränsat antal externa användare. Antalet externa användare begränsas av kostnader för att utfärda certifikat och applikationer för dessa tjänster samt kostnader för tekniska lösningar att utföra validering av certifikat. Beslut om externa användares möjlighet att erhålla certifikat fattas av systemägaren för CA-systemet. Riksbanken skall fastställa en utfärdardeklaration (CPS) som beskriver hur Riksbanken tillämpar och realiserar de krav som ställts i detta dokument. Genom kravställningen och realiseringen uppnås tillit i utfärdandet och användandet av dessa certifikat.

1 Internet Engineering Task Force. Public Key Infrastructure Standards Working Group.

Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practises Framework (RFC 2527).


Inledning 5 [42]

1.2 Identifiering

Objektidentifierare skall återfinnas i samtliga av Riksbankens utfärdade giltiga certifikat. En officiell objektidentifierare skall vara knuten till varje av utfärdaren registrerad certifikattyp i syfte att särskilja de olika nivåerna av tillförlitlighet. Typbeteckningen ”Medium Assurance Certificate” skall kopplas till de utgivna certifikaten och aktuell version av utfärdarens certifikatpolicy (CP) med hjälp av en unik objektidentifierare.

Denna version 1.0 av ”Regler för utgivning och hantering av elektroniska certifikat” skall identifieras i respektive certifikat med följande objektidentifiering.

Namn på certifikattyp Objektidentifierare (OID)

Medium Assurance Certificate 1.2.752.91.21.1.2.0

I av utfärdaren fastställt dokument Sveriges Riksbank – Fastställda certifikattyper samt Sveriges Riksbank - Registrerade OID beskrivs den grundläggande kravställningen för varje certifikattyp och dess identifikation.

1.3 Målgrupp och tillämplighet

1.3.1 Utfärdare (CA)

Ett certifikat syftar till att binda en specifik certifikatinnehavare till en publik krypteringsnyckel. Utfärdare är benämningen för Riksbanken som utfärdar certifikat och är ansvarig för tilliten till de utfärdade certifikaten. Utfärdaren är ytterst ansvarig för all hantering av certifikat och nycklar men har möjlighet att delegera detta ansvar utom för följande uppgifter:

• Skapande och signering av certifikat • Tillhandahållande av status på utgivna certifikat genom att regelbundet publicera en

lista på spärrade certifikat (CRL)

1.3.2 Registreringsenhet (RA)

En registreringsenhet (Registration Authority, RA) är benämningen på en organisation inom Riksbanken som ansvarar för administrationen av certifikatinnehavare samt hantering av procedurer relaterade till beställning av certifikat, utlämnande av certifikat, utföra spärr av certifikat, nyckelgenerering m.m.

1.3.3 Katalogtjänst

Utfärdaren skall tillse att det vid varje tillfälle finns minst en katalogtjänst där spärrlistor och samtliga giltiga utfärdade certifikat finns tillgängliga. En katalogtjänst kan vara, men behöver inte vara under Utfärdarens kontroll. I det fall en katalogtjänst inte är under Utfärdarens kontroll är det Utfärdarens skyldighet att kontrollera att katalogtjänsten tillgodoser ställda krav på tillgänglighet, riktighet, spårbarhet och sekretess samt krav ställda enligt svensk lag.


Inledning 6 [42]

1.3.4 Certifikatinnehavare

En certifikatinnehavare skall vara namngiven och identifierad i certifikatet samt inneha en privat nyckel som överensstämmer med en publik nyckel angiven i certifikatet. Utfärdaren kan ge ut nycklar och certifikat till interna och externa certifikatinnehavare. En intern certifikatinnehavare skall vara;

a) en person som är anställd av Riksbanken eller b) en person som har genomgått säkerhetskontroll för arbete inom Riksbanken samt

tilldelats en PC som står under Riksbankens kontroll. En extern certifikatinnehavare skall vara en person som;

a) innehar skriftligt avtal om samarbete med Riksbanken

1.3.5 Förlitande part

En förlitande part är benämningen på en organisation, person eller system som för att verifiera en identitet eller en elektronisk signaturs riktighet litar på ett certifikat utfärdat av Riksbanken. En förlitande part skall alltid inneha ett avtal med Utfärdaren som beskriver villkor och användningsområden för de utfärdade certifikaten.

1.3.6 Tillämpning och användning

Detta dokument beskriver regler som är tillämpliga för nyckel och certifikatanvändning av typen ”Medium Assurance” där syftet är att certifiera en fysisk persons identitet samt bibehålla riktighet i information och processer som vid kompromettering kan leda till finansiell förlust, försämrat förtroende för Riksbanken eller få juridiska påföljder. Vidare är detta dokument tillämpligt för certifikat och nycklar av typen ”Medium Assurance” som används i syfte att skydda hemlig och sekretessklassad information från avslöjande som kan leda till försämrat förtroende för Riksbanken, juridiska påföljder eller på annat sätt orsaka förlust och skada på ekonomiska värden, egendom och personal. Användningen av certifikat med tillhörande nycklar är bl.a. enligt följande:

• säker identifiering och autentisering (Elektronisk identifikation) vid användning av informationssystem

• sekretesskydd genom kryptografiskt skydd av elektronisk information som är klassificerad till klassen ”Hemlig” eller sekretessbelagd enligt sekretesslagen 1980:100, exklusive sekretessklassad information enligt 2 kap 2 § som skall hanteras på särskilt sätt

• garanti för riktighet av elektronisk information genom kryptering och signeringsfunktion

• oavvislighet vid användande av elektroniskt godkännande

Certifikat utfärdade enligt denna policy skall inte användas för att erhålla oavvislighet vid användandet av avancerade eller kvalificerade elektroniska signaturer.


Inledning 7 [42]

1.3.6.1 Godkända applikationer

Endast de applikationer som fyller de verksamhetsbehov som beskrivs i tillämpningen och användningen av certifikaten, se punkt 1.1 samt 1.3.6, får användas med certifikat utfärdade enligt denna policy. Applikationer och underliggande funktioner (t.ex. operativsystemsfunktioner) som använder utfärdade certifikat och tillhörande nycklar skall följa krav ställda i detta dokument för hur CA, certifikat och nycklar används samt förekommande regler inom Riksbankens informationsskydd. Applikationer och underliggande funktioner som använder certifikat och nycklar utfärdade enligt denna policy, skall kontrolleras/evalueras på sådant sätt att de kan sägas uppfylla villkoren och säkerhetsnivån för den tillförlitlighet som anges vara nödvändig för den funktion de skall utföra. Kontroll och verifikation skall utföras vid införande och vid förändring av applikationer och underliggande funktioner. Undantag för kontroll och evaluering kan göras om applikationer och funktioner är godkända och verifierade med avseende på säkerhet och funktion genom ett av CA leverantören godkänt certifieringsprogram. Kontroll och verifikation av att applikationen syftar till att försäkra sig om att applikationen utför sin funktion på sådant sätt att skyddet för informationen är det som avsetts. Kontrollen skall dock minst omfatta följande övergripande punkter:

• att applikationen korrekt kan etablera kommunikation med och använda publika och privata nycklar från dess lagringspunkt och att denna etablering sker med en tillförlitlighet och säkerhet i överensstämmelse med vad som anges i denna policy.

• att applikationen utför en verifikation av certifikats giltighet och status i enlighet med denna certifikatspolicy och företrädesvis med en validering mot NIST PKITS (PKI Test Suite, Path Validation)

• att applikationen korrekt kan utläsa och presentera information från certifikatet.

• att applikationen korrekt meddelar certifikatsinnehavaren information om och varningar för det aktuella certifikatet på sådant sätt att det stödjer säkerhet och tillförlitlighet

• att applikationen enbart nyttjar den privata krypteringsnyckeln för krypteringsändamål och inte för identifiering.

• att applikationen enbart nyttjar den privata signeringsnyckeln för identifiering och för elektroniskt godkännande, t.ex. i form av signering av e-post meddelanden.

• att applikationen är konstruerad och nyttjar kryptografiska funktioner som kryptering, dekryptering och signering på ett säkert och tillförlitligt sätt och företrädesvis med validering i enlighet med FIPS 140-1

Systemägaren för CA-systemet skall föra en förteckning över de applikationer som får användas tillsammans med certifikat utfärdade enligt certifikattypen ”Medium Assurance”. I förteckningen skall det framgå resultat för och hur applikationen och underliggande funktioner har kontrollerats/verifierats. Förteckning skall fastställas av systemägare och vara öppen information.


Inledning 8 [42]

Certifikatsinnehavare och förlitande parter skall upplysas i avtal om vilka applikationer och användningsområden som är godkända enligt denna policy. Certifikatsinnehavare och förlitande parter skall upplysas i avtal om att certifikat och privata nycklar skall användas i en miljö som certifikatsinnehavaren kan förlita sig på och att det ligger utanför riksbankens kontroll att förhindra att privata nycklar används för otillbörliga ändamål eller i strid men certifikatsinnehavarens intentioner.

1.3.6.2 Otillåtna applikationer

Applikationer som inte uppfyller villkoren enligt 1.3.6.1 är otillåtna applikationer.

1.4 Kontaktuppgifter

1.4.1 Administrationsansvarig

Riksbankens administrativa avdelning, säkerhetsfunktionen fastställer och förvaltar detta dokument.

1.4.2 Kontaktperson

Frågor kring detta dokument och dess innebörd adresseras till säkerhetschef, administrativa avdelningen, säkerhetsfunktionen, Sveriges riksbank SE-103 37 STOCKHOLM.


Allmänna bestämmelser 9 [42]

2 Allmänna bestämmelser

2.1 Allmänna åtaganden

2.1.1 Utfärdarens (CA) skyldigheter

Utfärdaren skall i egenskap av Utfärdare av certifikat åta sig att i enlighet med detta dokument samt Riksbankens riktlinjer och regler:

• skapa certifikat på begäran och med de uppgifter som erhålls, från RA • genom systemägaren för CA-systemet ge ut en utfärdardeklaration (CPS) samt följa

denna CPS • skydda utfärdarens egna privata nycklar på ett säkert sätt • tillhandahålla information i enlighet med avsnitt 2.6 • att vara avtalspart till certifikatinnehavare och förlitande parter • utöva tillsyn enligt kapitel 4, 5 och 6 • spärra certifikat och ge ut spärrlistor i enlighet med kapitel 4 • publicera publikt certifikat för CA på sådant sätt att certifikatinnehavare och

förlitande part enkelt kan verifiera spärrlistors giltighet och riktighet • att utföra samtliga uppgifter i enlighet med svenska lagar och bestämmelser, samt

de lagar och bestämmelser som är gällande under produktanvändning

2.1.2 Registreringsenhetens (RA) skyldigheter

Registreringsenheten skall åta sig att följa kraven i detta dokument och av Utfärdaren utgiven utfärdardeklaration (CPS) samt åta sig att ansvara för följande uppgifter:

• Registrering, verifiering och administration av ansökningar för certifikat och nycklar • Registrering och administration av certifikat och nycklar med tillhörande hårdvara • Generering av krypteringsnycklar på därför avsett medium • Identifiering av användare inför utgivning av certifikat med tillhörande hårdvara • ta emot anmälan om spärr av certifikat och kort samt begära spärr

2.1.3 Systemägaren för CA-systemets skyldigheter

Systemägaren för CA-systemet skall åta sig att följa kraven i detta dokument övriga styrande dokument samt Riksbankens riktlinjer och regler.

2.1.4 Certifikatinnehavares skyldigheter

Certifikatinnehavare skall ingå ett avtal med Riksbanken som beskriver villkor för användandet av tillhandahållna nycklar och certifikat.

Det är certifikatinnehavares skyldighet att; • tillse att informationen vid ansökan och i det utfärdade certifikatet är korrekt • att omedelbart meddela utfärdaren om förändring i de vid ansökan givna

uppgifterna • att inte använda certifikat och nycklar efter det att giltighetstiden gått ut eller efter

det att certifikatet blivit spärrat • att följa övriga regler och hanteringsanvisningar som finns inom avtalet



2.1.4.1 Skydd av certifikatinnehavarens privata nyckel

Det är certifikatinnehavarens skyldighet att: • omedelbart rapportera förlust av den privata nyckeln • betrakta den privata nyckeln som hemlig handling och skydda denna därefter • välja PIN i enlighet med anvisningar • skydda PIN så att obehöriga ej får åtkomst till denna och att aldrig förvara PIN på

samma ställe som den privata nyckeln • att förvara PUK på ett säkert sätt och åtskilt från den privata nyckeln, så att

obehöriga ej får åtkomst till denna • aldrig lämna sin privata nyckel obevakad i ett ”olåst” läge • att följa övriga regler och hanteringsanvisningar som finns inom avtalet

2.1.5 Förlitande parts skyldigheter

Förlitande part skall åta sig att följa kraven i detta dokument samt ingå avtal med Utfärdaren som beskriver villkor för användandet av tillhandahållna certifikat och nycklar.

2.1.5.1 Användning av certifikat för avsedda ändamål

Förlitande part skall innan denne använder certifikatet tillse att certifikatet är lämpat för det avsedda ändamålet och är av korrekt certifikattyp.

2.1.5.2 Ansvar för att kontrollera spärr och giltighet av certifikat

Förlitande part skall innan denne använder certifikatet verifiera certifikatets giltighet enligt den procedur som beskrivs i X.5092 samt PKIX del 13. Innan ett certifikat får användas skall en statuskontroll av certifikatet göras mot senaste spärrlista (CRL) enligt de krav som specificeras i avsnitt 4.4.11. Som en del i denna process skall spärrlistans digitala signatur valideras. Spärrat certifikat får inte användas.

2.1.6 Publicerande parts (katalogtjänstens) skyldigheter

Katalogtjänsten skall åta sig:

• att utföra samtliga uppgifter i enlighet med svenska lagar och bestämmelser, samt de lagar och bestämmelser som är gällande under produktanvändning

• att tillhandahålla de funktioner och uppgifter som specificeras i detta dokument i enlighet med kraven i detta dokument samt Riksbankens regler gällande informationssäkerhet

• att vara tillgänglig för de funktioner och uppgifter som specificeras i detta dokument minst motsvarande CA-systemets angivna tillgänglighetskrav.

• att tillse att spärrlistor är tillgängliga och uppdaterade enligt avsnitt 4.4.10 för certifikatsinnehavare och förlitande part.

2 International Telecommunication Union. Information Technology, Data Networks and Open System

Communication: Directory, Recommendation X.509. 3 Internet Engineering Task Force. Public Key Infrastructure Standards Working Group.

Internet X.509 Public Key Infrastructure: Certificate and CRL Profile (RFC 2459).



2.2 Ansvar

2.2.1 Begränsning av förpliktelser

Särskild reglering saknas.

2.2.2 Begränsning av ansvar

Riksbanken ansvarar inte för skada som beror på svensk eller utländsk lag eller föreskrift, svensk eller utländsk myndighetsåtgärd, krigshändelse, elavbrott, teleavbrott, brand, vattenskada, strejk, blockad, lockout, bojkott eller annan liknande omständighet utanför Riksbankens kontroll och vars följder Riksbanken inte skäligen kunde ha undvikit eller övervunnit. Förbehållet i fråga om strejk, blockad, lockout eller bojkott gäller även om Riksbanken själv är föremål för eller vidtar sådan konfliktåtgärd.

Föreligger hinder för part att vidta en åtgärd enligt detta dokument på grund av omständighet enligt första stycket, får åtgärden uppskjutas till dess att det blivit praktiskt möjligt att vidta åtgärden.

2.2.3 Andra bestämmelser och villkor

Systemägaren för CA-systemet ansvarar för att det finns en fastställd utfärdardeklaration (CPS). Utfärdardeklarationen skall svara mot den samlade kravbilden för respektive certifikattyp.

2.3 Ekonomiskt ansvar

2.3.1 Förlitande parts rätt till skadeersättning

Separat avtal gällande ansvar skall alltid skrivas med förlitande part.

2.4 Tolkning och verkställighet

2.4.1 Tillämplig lag

Svensk lag används.

2.4.2 Oberoende, fortbestånd, samgående och underrättelse om detta

Upphörande av CA beslutas av Riksbanken enligt punkt 4.9.

2.4.3 Förfarande vid tvistlösning

Eventuell tvist skall lösas vid svensk domstol.

2.5 Avgifter

Inga avgifter förekommer om inte separat avtal mellan respektive part reglerar detta.



2.6 Publicering och förvaringsplats

2.6.1 Publicering av information om Utfärdaren

Information rörande Utfärdaren och relaterade dokument skall hållas tillgänglig på Riksbankens intranät4. Information till extern certifikatsinnehavare utan tillgång till Riksbankens intranät skall ges tillgång till information enligt 2.6.4 enligt separat överenskommelse med denne.

2.6.2 Publiceringsfrekvens

Detta dokument skall revideras var 24:e månad eller vid behov. Förändringar i dokumentet skall publiceras på Riksbankens intranät samt meddelas samtliga certifikatsinnehavare och förlitande parter. Se avsnitt 4.4.10 för publiceringsfrekvens för spärrinformation.

2.6.3 Åtkomstkontroll

Åtkomstkontroll skall följa Riktlinjer för Riksbankens Informationsskydd5. Certifikat och spärrlistor (CRL) är öppen information och skall vid utsökning från extern källa begränsas på sådant sätt att utsökningens svar ej kan fås i annan form än enskild post (exakt matchning). Detta i syfte att förhindra utsökningar av t.ex. alla publika certifikats e-postadresser.

2.6.4 Förvaringsplatser

Informationen hålls tillgänglig enligt följande: Information Publiceringsplats / omfattning Detta dokument Riksbankens intranät, samtliga

versioner Underrättelse om planerad förändring av detta dokument

Riksbankens intranät, senaste version

Resultat av granskningar i form av sammanställning och bedömning av tillförlitlighet.

Riksbankens intranät, samtliga versioner

Villkor för certifikatinnehavare Riksbankens intranät samt i avtal mellan parter, samtliga versioner av villkor.

Certifikat och CRL (Spärrlista) Riksbankens katalogtjänst, senaste version

Registrerade OID Riksbankens intranät, samtliga versioner

Förteckning över godkända applikationer Riksbankens intranät, senaste version

CA publika certifikat för validering av spärrlista Riksbankens externa webbplats, senaste version

4 http://banconatet 5 Riktlinjer för Informationsskydd, Sveriges riksbank Dnr: 2002-1199-ADM



2.7 Granskning (revision)

2.7.1 Frekvens för revision

Granskning skall utföras årligen genom en intern kontroll av säkerhetsfunktionen, administrativa avdelningen. Granskning skall utföras av extern part med maximalt tre (3) års intervall.

2.7.2 Revisorns kvalifikationer

Intern kontroll skall utföras av person med erforderlig kompetens för uppgiften och förståelse för PKI teknologi, informationssäkerhetstekniker och –verktyg samt inneha erfarenhet från IT-säkerhetsgranskningar. Extern revision skall utföras av revisor med samma kvalifikationer som för intern kontroll, genomgått utbildning i IT-revision samt vara certifierad enligt CISA (Certified Information Systems Auditor)6 eller annan jämförbar certifiering.

2.7.3 Revisors relation till granskad part

Revisor vid intern kontroll skall vara oberoende gentemot systemägaren och dess drift & förvaltningsorganisation. Revisor vid extern revision skall vara i oberoende ställning gentemot Riksbanken.

2.7.4 Förhållanden som skall granskas

Minst följande förhållanden skall granskas: • Att den fastställda utfärdardeklarationen (CPS) möter kraven i detta dokument. • Att Utfärdaren genom systemägaren för CA-systemet har implementerat och följer

tekniska krav, personella krav och procedurer beskrivna i detta dokument och utfärdardeklarationen (CPS).

• Att Utfärdaren genom systemägaren för CA-systemet når upp till den nivå av tillförlitlighet som avses i detta och övriga styrande dokument och regler som fastställer säkerhetsnivå och tillförlitlighet för certifikattypen ”Medium Assurance”.

2.7.5 Åtgärd vid upptäckt av brist

I det fall brist upptäcks vid granskning skall systemägaren ansvara för att snarast utföra en menbedömning syftande till att beskriva påverkan på tillförlitligheten på PKI, eventuella effekter av bristen under den tid den funnits och därefter besluta om åtgärder för att återställa PKI till den tillförlitlighet som avses i detta dokument. Systemägaren skall rapportera händelser som kan eller har påverkar säkerheten enligt Riksbankens regler för incidenthantering, 11-1.

2.8 Sekretess

All information som är insamlad, genererad, överförd eller underhålls av Utfärdaren skall klassificeras med avseende på sekretess enligt Riktlinjer för Riksbankens Informationsskydd. Följande information skall dock alltid vara klassificerad som öppen:

6 Information Systems Audit and Control Association (ISACA), http://www.isaca.org



• Samtliga publika certifikat exklusive administrativa rollers certifikat samt CA-systemets interna certifikat

• spärrlistor utfärdade av Utfärdaren

• detta dokument

Vid begäran om utlämnande av allmän handling skall sedvanlig sekretessbedömning utföras enligt sekretesslagen.

2.9 Immateriella rättigheter


2.10 Avtal

Utfärdande av certifikat sker i enlighet med de villkor för certifikatinnehavare och förlitande part som dessa godkänner i samband med användning av erhållet certifikat.


Identifiering och identitetskontroll 15 [42]

3 Identifiering och identitetskontroll

3.1 Initial registrering

3.1.1 Namntyper

Fysisk person Följande identitetsattribut skall anges vid ansökan och utgör underlag för de certifikat som utfärdas då certifikatinnehavaren är en (1) fysisk person. Attribut Innehållskrav Efternamn Enligt SIS-godkänd ID-handling. Förnamn Tilltalsnamn enligt SIS-godkänd ID-handling. Avdelning Avdelning inom Riksbanken Enhet Enhet inom Riksbanken E-post adress E-post adress för certifikatinnehavaren Företagsnamn officiellt namn enligt Patent- och Registreringsverkets

bolagsregister Organisationsnummer officiellt organisationsnummer enligt SFS 1974:174 Postadress Företagets officiella postadress Telefonnummer Företagets officiella telefonnummer Identitetsattribut i kursiv stil skall enbart anges vid ansökan om certifikat är menad för extern certifikatinnehavare.

3.1.2 Krav på meningsfulla namn

Namn som skrivs in i certifikatet skall minst bestå av fullständigt förnamn och efternamn. Initial eller avdelningsnamn får användas som ytterligare särskiljande attribut.

3.1.3 Regler för tolkning av olika namnformer

Namnformer tolkas i enlighet med regler för namngivning av personer i Riksbankens katalog samt styrande krav i enlighet med detta dokument.

3.1.4 Krav på att namn är unika

Namngivningen (ett eller flera attribut i kombination) av ett certifikat skall vara unik för alla certifikatinnehavare i systemet. System för generering av unika identifieringsnummer för ett certifikat skall vara uppbyggt på ett sådant sett att samma identifieringsnummer inte skall kunna genereras två gånger under hela systemets livslängd.

3.1.5 Förfarande för att lösa namnkonflikter

Namngivning följer samma procedurer som används för namngivning i Riksbankens katalogtjänst. Vid eventuella konflikter har ITA-ledning beslutsrätt.

3.1.6 Erkännande och kontroll av varumärken




3.1.7 Metod för att bevisa innehav av privat nyckel

IETF PKIX Certificate Management Protocol7 skall användas för att bevisa bindningen mellan den privata nyckeln och certifikatinnehavaren (Proof of Possession).

3.1.8 Kontroll av organisationers identitet

För externa certifikatinnehavare skall identifiering och identitetskontroll av organisationen ske vid ansökan av certifikat genom att dokumentation i form av officiellt företags/organisationsnamn från patent och registreringsverket bifogas tillsammans med underskrift av den ansvariga person som skall underteckna avtal med Utfärdaren som förlitande part. För att möjliggöra en enkel verifiering av namn bör kopia på företaget/organisationens registreringsbevis användas företrädesvis.

3.1.9 Kontroll av persons identitet

Identifiering och identitetskontroll skall vid ansökan av certifikat ske enligt följande; • Bifogad kopia av SIS-godkänd ID-handling

Identifiering och identitetskontroll skall vid utlämnande av certifikat ske enligt följande alternativ;

• Personlig närvaro med uppvisande av SIS-godkänd ID-handling • Kvittering av mottagandet med SIS-godkänd ID-handling av rekommenderad

postförsändelse (personlig mottagare)

3.2 Identitetskontroll vid rutinmässig nyckeluppdatering

All automatisk begäran om nyckeluppdatering skall autentiseras av CA-systemet genom att validera att befintliga nycklar är giltiga. Detta skall göras med ett säkert protokoll enligt IETF PKIX Certificate Management Protocols (PKIX-CMP). Kan inte identitetskontroll göras automatiskt enligt PKIX-CMP skall identitetskontroll ske enligt avsnitt 3.1.8 och 3.1.9

3.3 Identitetskontroll vid nyckeluppdatering efter spärr

Identitetskontroll vid nyckeluppdatering efter spärr skall ske efter samma rutiner som vid ansökan om nytt certifikat. Se avsnitt 3.1.8 - 3.1.9.

3.4 Identitetskontroll vid spärrbegäran

Metod för spärr Identifieringsmetod Telefonsamtal, e-postmeddelande eller personligt besök

Mottagare av spärrbegäran skall fråga efter identitet på den som begär spärr av certifikat. Uppgiven identitet, sätt på vilket spärrbegäran gavs samt om möjligt annan kompletterande information skall noteras.

7 Internet Engineering Task Force. Public Key Infrastructure Standards Working Group. Internet X.509 Public Key

Infrastructure: Certificate Management Protocols (RFC 2510).



Om det misstänks föreligga risk för missbruk av en privat nyckel som är associerad med ett certifikat som begärs spärrat så skall certifikaten spärras även om ovanstående identifieringskrav ej kan tillgodoses.


Operationella krav 18 [42]

4 Operationella krav

4.1 Ansökan om certifikat

Ansökan om certifikat skall göras av beställare i form av närmast ansvarig chef inom Riksbanken, d.v.s. enhetschef eller i vissa fall avdelningschef. Ansökan om certifikat skall ske skriftligen på därför avsedd blankett. Beställaren skall ansvara för att verifiera ansökan och dess innehåll är korrekt. Ansökan skall undertecknas av beställaren med ett namnförtydligande. Vid byte av namn för en certifikatinnehavare skall ny ansökan göras. Ansökande (tilltänkt certifikatinnehavare) skall innan certifikatet utfärdas, ingå ett avtal med Utfärdaren där certifikatinnehavaren förbinder sig att följa Riksbankens villkor för användande av certifikat. Se även avsnitt 2.1.4.

4.2 Utfärdande av certifikat

Mottagande t av ett av certifikatinnehavaren underskrivet avtal och utfärdandet av ett certifikat innebär tillsammans att Utfärdaren godkänner certifikatansökan.

4.3 Acceptans av certifikat

Certifikatinnehavaren skall efter mottagande av certifikat kontrollera att uppgifterna i det framställda certifikatet stämmer överens med de i ansökan givna uppgifterna. Genom att certifikatinnehavaren använder certifikatet godkänner certifikatinnehavaren att uppgifterna i certifikatet är korrekta.

4.4 Definitiv och temporär spärr av certifikat

En definitiv spärr skall inte kunna hävas. En temporär spärr kan hävas under speciella villkor utan att ett nytt certifikat behöver utfärdas.

4.4.1 Anledning till definitiv spärr

Ett certifikat skall spärras:

• Vid misstanke om att den privata nyckeln används av annan än dess rättmätige certifikatinnehavare eller på något annat sätt misstänks vara komprometterad

• Vid förlust av nycklar eller nyckelbärande utrustning • Vid förändring av någon av de uppgifter eller förhållande som finns inskrivet i det

utfärdade certifikatet (t ex vid namnbyte) • När certifikatinnehavarens anställning/arbete/funktion avslutas vid banken • När nyckel varit tillfälligt spärrad i 99 dagar • Då certifikatinnehavaren begär att sitt certifikat spärras

Utfärdaren äger rätt att spärra certifikat utan att informera certifikatinnehavaren:



• Om denne försummar sina skyldigheter beskrivna i detta dokument och försummelsen innebär ett väsentligt avtalsbrott

• Vid certifikatinnehavares dödsfall • Då utfärdaren är oförmögen att kontakta certifikatinnehavaren inom rimlig tid

4.4.2 Vem kan begära definitiv spärr

Alla som har anledning enligt 4.4.1 kan begära definitiv spärr av ett certifikat.

4.4.3 Procedur för spärrbegäran

Utfärdaren skall tillse att procedurer och krav gällande spärr av certifikat dokumenteras i utfärdardeklarationen (CPS). En begäran av spärr och de åtgärder Utfärdaren genomför efter spärrbegäran skall alltid dokumenteras tillsammans med orsak till spärr. Om möjligt skall den som begärt spärr identifieras och notering föras om identiteten.

4.4.4 Behandlingstid vid spärrbegäran

Spärrtjänsten skall vara operativ 24 timmar om dygnet 365 dagar om året. Information om spärr skall publiceras i spärrlista snarast möjligt, spärrlista skall dock publiceras senast en (1) timme efter spärrbegäran.

4.4.5 Anledning för temporär spärr

Temporär spärr av certifikat får användas i följande fall: • Vid tjänstledighet, föräldraledighet eller sjukskrivning understigande 99 dagar • Vid misstanke om obehörigt utnyttjande eller risk för obehörigt utnyttjande

Finns annan anledning till spärr än någon av de ovan uppräknade skall definitiv spärr göras enligt avsnitt 4.4.1.

4.4.6 Vem kan begära temporär spärr

Alla som har anledning enligt 4.4.5 kan begära temporär spärr av ett certifikat.

4.4.7 Procedur för temporär spärr

Se avsnitt 4.4.3.

4.4.8 Tidsbegränsning för temporär spärr

Temporär spärr är giltig i maximalt 99 dagar. Om inte temporär spärr hävts inom giltighetsperioden skall den övergå till definitiv spärr.

4.4.9 Procedur för hävning av temporär spärr

Utfärdaren skall tillse att procedurer och krav gällande hävning av temporär spärr dokumenteras i utfärdardeklarationen (CPS). Hävning av temporär spärr skall godkännas av närmast ansvarig chef inom Riksbanken, d.v.s. enhetschef eller i vissa fall avdelningschef. Hävning av temporär spärr får endast ske om ingen misstanke om eller risk för obehörigt utnyttjande kvarstår. Beslut om hävning av temporär spärr skall dokumenteras och lagras av registreringsenheten (RA) under certifikatets giltighetstid.



4.4.10 Utgivningsfrekvens för spärrlista

Spärrlista skall alltid uppdateras vid spärr, 24 timmar om dygnet 365 dagar om året. Ny spärrlista skall ges ut minst var 24:e timme även om ingen ny information framkommit sedan senaste utgivning.

4.4.11 Krav på kontroll mot spärrlista

Certifikatsinnehavare och förlitande part har ansvaret för att kontrollera om ett certifikat är spärrat eller inte. Om spärrkontroll enligt nedan inte kan göras, skall certifikatet inte anses tillförlitligt. Kontrollen skall utföras på följande sätt:

• Certifikatet kontrolleras mot en spärrlista som representerar den senaste tillgängliga spärrinformationen

• Kontroll att spärrlistan fortfarande är giltig enligt giltighetstid för spärrlistan • Kontroll av att spärrlistans signatur är giltig (dvs. att spärrlistan är signerad med rätt

och giltig utfärdarnyckel)

4.4.12 Kontroll av spärr i realtid


4.4.13 Krav på kontroll av spärr i realtid


4.4.14 Andra tillgängliga former för tillkännagivande av spärr


4.4.15 Krav på kontroll mot andra former för tillkännagivande av spärr


4.4.16 Speciella krav rörande kompromettering av nycklar

Om misstanke finns att nyckel utsatts för obehörig åtkomst, nyttjande eller har förlorats skall incidentanmälan utföras omedelbart efter anmälan om spärr. Om misstanke finns för att nyckel tillhörande CA-systemets administratörsroller eller CA-systemets interna nycklar utsatts för obehörig åtkomst, nyttjande eller har förlorats skall en incidenthanteringsgrupp minst bestående av systemägaren för CA-systemet och Riksbankens säkerhetschef omedelbart sammankallas för att leda incidenthanteringen och åtgärder enligt punkt 4.8.2.

4.5 Loggning

4.5.1 Typ av loggade händelser

Loggning skall utföras i sådan omfattning och utförande att det har en förebyggande verkan mot obehöriga aktiviteter eller försök till detta samt för att skapa förtroende till CA-systemet. I CA-systemet och närliggande system som t.ex. underliggande operativsystem, skyddande system och kommunikationsutrustning skall minst alla följande händelser loggas,



§ händelser som kan orsaka en negativ påverkan på CA-systemets tillämpning redovisad under punkt 1.1 och 1.3.7 samt tillförlitlighet och säkerhetsnivå framtagen ur krav på sekretess, integritet, tillgänglighet och spårbarhet

§ händelser som är av typen säkerhetsloggning (se riksbankens regelverk 7-2 Spårbarhet)

§ händelser som kan orsaka en direkt och negativ påverkan på det logiska åtkomstskyddet

§ händelser som inträffar vid fysisk åtkomst av CA-systemet, förvaringsplatser för loggar samt nycklar

§ händelser som påverkar tillgängligheten t.ex. avbrott och driftstörning § händelser som gör tillgängligheten mätbar, t.ex. start och stopp § händelser relaterade till certifikatutfärdande, genering av konton, spärr av certifikat

och utgivning av spärrlista (CRL) § förändringshanterings (Change management) åtgärder

Åtkomst till information och informationssystem inkluderande system tillhörande och i anslutning till CA-systemet, skall inneha funktion för larm/incidenthantering vid överträdelser för det logiska åtkomstskyddet enligt Riksbankens regelverk för logiskt åtkomstskydd, 7-1.

4.5.2 Utförande av loggning

Loggning i IT-system skall ske automatiskt i de fall IT-system har funktioner för detta. Manuell logg skall föras vid utförande av procedurer och rutiner samt då IT-system ej har funktion för automatisk loggning av specifika funktioner. All loggning skall ske kontinuerligt. Hantering, uppföljning och analys av loggar skall vara så utformad att den är lätt att genomföra och administrera, vid behov ska det finnas analyshjälpmedel. Samtliga logghändelser, elektroniska och manuella, skall innehålla tid och datum för händelsen samt identitet på den resurs som initierade händelsen. Datum, tid och tidzon skall hämtas från centralt placerad tidskälla vars inställning och tid är möjlig att verifiera.

4.5.3 Frekvens för kontroll av loggar

Loggar skall kontrolleras och analyseras med en sådan frekvens att det går att säkerställa att påverkan på CA-systemets tillförlitlighet och säkerhetsnivå undviks och att obehörig åtkomst eller förändring omedelbart upptäcks och hanteras. System för genomsökning och automatisk kontroll i realtid samt korrelering och eskalering av avvikande händelser i loggar bör finnas. Utöver detta skall en fullständig kontroll och analys genomföras minst en (1) gång per vecka för upptäckt av eventuella oegentliga aktiviteter. En analys för detta innebär kontroll av loggens riktighet, kortfattad genomgång av samtliga loggade händelser och en utförlig utredning av misstänkt oegentliga händelser. Allvarliga händelser som kräver omedelbar hantering skall incidentanmälas och hanteras i enlighet med Riksbankens regler. Övriga händelser i form av oegentligheter skall



sammanställas och förklaras i en rapport som delges systemägare n snarast. En sammanställning över samtliga händelser som orsakat misstanke om eller inneburit oegentligheter skall delges systemägaren för CA-systemet samt Riksbankens säkerhetschef varje kvartal.

4.5.4 Lagringstid för loggar

Loggar enligt 4.5.1 skall bevaras i loggsystemet i minst sex (6) månader för att sedan arkiveras enligt avsnitt 4.6.

4.5.5 Skydd av loggar

Loggar skall skyddas mot obehörig åtkomst, förändring eller radering genom; • Logiska skyddsmekanismer i CA-systemet, underliggande operativsystem eller

särskilt anordnat skydd • Att systemet och arkivet i sig inte är fysiskt och logiskt åtkomligt annat än för

behörig personal och att åtkomst sker med starkare autentisering än lösenord.

4.5.6 Procedurer för säkerhetskopiering av loggar

Två kopior av loggen skall lagras i fysiskt säkrade utrymmen, på fysiskt skilda platser. Loggarna skall lagras på sådant sätt att de vid misstanke om oegentligheter kan tas fram och göras läsbara för granskning under den angivna lagringstiden.

4.5.7 System för insamling av loggar

Automatiskt genererade loggar från IT-system enligt 4.5.1 skall skrivas till separat(a) loggsystem utanför CA-systemet på ett säkert och tillförlitligt sätt enligt avsnitt 4.5.5.

4.5.8 Underrättelse av händelseskapande individ

Certifikatinnehavare och förlitande part skall underrättas i avtal om att loggning av händelser i CA-systemet sker, samt informeras om syftet med denna loggning. Ingen notifiering görs individuellt till certifikatinnehavare som initierade händelsen. Vid misstanke om oegentligheter bör även andra loggar än de som omfattas av avsnitt 4.5.1 kontrolleras.

4.6 Arkivering

4.6.1 Typ av arkiverad information

Följande typ av information skall arkiveras:

• Certifikatsansökningar • Avtal med certifikatinnehavare • Avtal med förlitande part • Dokumentation rörande spärr av certifikat • Kvittenser för utrustning i form av nyckelförvaring (token), mjukvara, PIN etc. • Styrande dokument gällande CA-systemet • Dokumentation rörande personal i administrativa roller inom CA-systemet,

säkerhetskontroller, personalförändringar etc. • Protokoll från utförda granskningar (revisioner) • Loggar enligt 4.5.1



4.6.2 Lagringstid för arkiv

Information enligt 4.6.1 skall arkiveras i minst fem (5) år och skall därefter avpassas utefter sekretessens giltighetstid.

4.6.3 Skydd av arkiv

Arkiverad information skall skyddas mot otillbörlig åtkomst, förändring eller radering genom att arkivet i sig inte är fysiskt och logiskt åtkomligt annat än för behörig personal. Arkiverad information bör lagras i sådan miljö och på sådant media att läsbarheten tillgodoses under hela den bedömda lagringstiden för att undvika kostsamma kopieringar till andra media. Arkiverad information skall förslutas med sigill som ska vara av sådan typ att det går att utläsa om åtkomst, förändring eller radering har skett. Sigilleringen skall protokollföras.

4.6.4 Procedurer för säkerhetskopiering av arkiv


4.6.5 Krav på tidsstämpling av arkiverad information


4.6.6 System för arkivering

Arkiverad information skall lagras i ett format som är användbart under hela lagringstiden. Arkiverad information skall lagras organiserat så att det utan svårigheter går att se vilken information som finns arkiverad och vart i arkivet informationen är placerad.

4.6.7 Procedurer för åtkomst och verifiering av arkiverad information

Arkiverad information skall lagras på sådant sätt att den vid allvarlig misstanke om oegentligheter kan tas fram och göras läsbar för granskning under den angivna lagringstiden. Arkiverad information skall verifieras för läsbarhet och riktighet minst var 24:e månad genom att utföra stickprov avseende läsbarhet och riktighet. Omfattningen av stickprov skall vara sådan att läsbarheten och riktigheten kan antas vara god i all lagrad information.

4.7 Nyckelbyte

Vid byte av utfärdarnycklar skall signering ske av den nya nyckeln både med den gamla och den nya (självsignering).

4.8 Åtgärder vid händelse av kris eller katastrof

4.8.1 Åtgärder vid kris eller katastrof

Systemägaren skall tillse att planer, reservrutiner, procedurer och rutiner finns i sådan utsträckning att målen för Riksbankens kontinuitetsskydd uppfylls med ett bibehållande av tillförlitlighetsnivån för Utfärdaren. Se även Riktlinje för Riksbankens kontinuitetsskydd8.

8 Dnr: 2002-00288 ADM



4.8.2 Speciella åtgärder om certifikatutfärdarens privata nyckel är komprometterad

Systemägaren för CA-systemet skall ansvara för att det finns en skriftlig plan för vilka åtgärder den egna organisationen, certifikatinnehavare och förlitande parter skall ta vid händelse av kompromettering. Utfärdaren skall vidta följande åtgärder vid misstanke om att utfärdarnycklarna är komprometterade:

• Spärra samtliga CA-certifikat för den komprometterade CA-nyckeln, som utfärdats med annan överordnad CA-nyckel

• Incidentanmäla händelsen och sammankalla en incidenthanteringsorganisation minst bestående av systemägaren för CA-systemet och Riksbankens säkerhetschef

• Informera samtliga certifikatinnehavare och förlitande parter med vilka Riksbanken har avtal eller andra etablerade relationer

Utfärdaren skall säkerställa att spärrinformation finns tillgänglig för CA-certifikaten till dess att de spärrade certifikatens giltighetstid löpt ut. I händelse av att överordnad CA-nyckel (topp-CA) blir komprometterad skall utfärdaren omedelbart upphöra med tjänst för spärrkontroll. Detta medför att certifikaten inte accepteras av förlitande part som skall utföra kontroll mot spärrlista enligt 4.4.11.

4.9 Upphörande av Utfärdarens verksamhet

Beslut om upphörande får endast fattas av Utfärdaren i form av systemägaren för CA-systemet under förutsättning att Riksbankens samtliga avdelningar informerats minst tre månader innan beslut fattas. Vid beslut om upphörande av Utfärdaren skall:

• Beslut om upphörande protokollföras • Samtliga certifikatinnehavare och förlitande parter underrättas om beslutet • Plan samt procedurer tas fram, som säkerställer att krypterad information kan

återskapas och att skapade signaturer kan verifieras i minst fem (5) år efter upphörande av tjänsten

• Samtliga procedurer och åtgärder utförda för Utfärdarens upphörande dokumenteras och arkiveras

• Arkiverad information under punkt 4.6 skall hållas tillgänglig enligt dessa villkor under den tidsrymd som specificeras därunder.

• upphöra med tjänst för spärrkontroll vilket medför att certifikaten inte accepteras av förlitande part som skall utföra kontroll mot spärrlista enligt 4.4.11

• Samtliga privata nycklar skall förstöras enligt punkt 6.2.8


Fysisk säkerhet och säkerhetskontroll 25 [42]

5 Fysisk säkerhet och säkerhetskontroll

5.1 Fysisk säkerhet

5.1.1 Anläggningens läge och konstruktion

CA-systemet skall placeras i en av Riksbanken godkänd datorhall. Anläggningen som inrymmer CA-systemets centrala delar skall vara placerad i starkt skyddat utrymme. Datorhallen skall vara låst och larmad. Behörigheten till datorhallen skall vara begränsad så att enbart personer med behörighet att administrera system placerade i hallen samt vaktpersonal har behörighet dit. Behörigheter för tillträde skall kontrolleras minst en gång per år av systemägaren för CA-systemet.

5.1.2 Fysiskt tillträde till CA-systemet

I datorhall skall de av CA-systemets komponenter som är direkt anslutna till det avskilda nätverkssegmentet vara placerade i enskilt åtkomstskyddat skåp eller kapsling. Skåp eller kapsling skall vara individuellt larmat för att förhindra ej föranmäld åtkomst till CA-systemet. Åtkomst skall vid varje tillfälle begäras och godkännas av Bevakningscentralen. Logg skall föras över fysisk åtkomst till CA-systemet och dess komponenter. Systemägaren skall ansvara för att upprätta en lista över behörig personal. Fysisk åtkomst till topp-CA som ej är kontinuerligt ansluten till nätverk eller normalt placerad i datorlokal skall ske enligt speciellt anordnad och dokumenterad procedur.

5.1.3 Strömförsörjning och luftkonditionering

Strömförsörjningen skall vara anordnad så att CA-systemet med dess omkringliggande system skall kunna fungera i normal drift i enlighet med de krav som är ställda på tillgänglighet. Ventilation och klimatkontroll skall vara så konstruerad så att rekommenderade klimatvärden från leverantören följs och så att tillgängligheten ej påverkas.

5.1.4 Vattenexponering

CA-systemet skall i sin helhet skyddas från exponering av vätska. Vattenledningar av annan typ än sådana avsedda för klimatkontroll alternativt brandskydd skall ej förekomma i datorhall.

5.1.5 Brandskydd inkl. förebyggande åtgärder

Datorhall skall vara utrustad med funktioner för automatiskt släcksystem samt sensorer för snabbdetekterande brandlarm. Dörrar och väggar skall vara utformade i minst brandklass EI60.

5.1.6 Lagring av media

Media innehållande programvara och dokumentation över CA-systemet samt omkringliggande system skall förvaras i två kopior i två geografiskt separata brandskyddade utrymmen avskiljt från datorhall.



5.1.7 Avfallshantering

Datormedia som använts för lagring av information som krypteringsnycklar, aktiveringsdata eller filer från CA-systemet skall förstöras enligt Riktlinjer för Riksbankens Informationsskydd.

5.1.8 Reservanläggning

Reservanläggning skall hålla en fysisk säkerhet som minst motsvarar den ordinarie anläggningen.

5.2 Procedurorienterad säkerhet

5.2.1 Roller inom Riksbankens förvaltningsorganisation

Riksbankens riktlinjer och regler för informationsskydd kräver att det skall finnas en ägar- och förvaltningsorganisation för varje informationssystem. Följande roller skall därför vara obligatoriska för CA-systemet:

Benämning Ansvar Systemägare Systemägare äger formellt CA-systemet (PKI) och är ytterst ansvarig för

dess funktion, säkerhet, effektivitet och förhållande till andra system och verksamheter.

Systemförvaltare Systemförvaltaren utses av systemägare som delegerar uppgifter till denne efter beslut. Systemförvaltaren ansvarar för att utarbeta och kontinuerligt följa upp effektiva rutiner, metoder och informationskanaler för förvaltningen av CA-systemet.

Systemansvarig Systemansvarig utses av systemägare och systemförvaltaren som delegerar uppgifter till denne efter beslut. Systemansvarig skall på uppdrag av systemförvaltaren sammanställa information, utreda, planera, bedöma effekter, kostnader och konsekvenser inom systemet och genom påverkan utanför systemet vid förändring och utveckling.

Driftsansvarig Driftansvarig utses av systemägare och systemförvaltaren som delegerar uppgifter till denna efter beslut. Driftansvarig ansvarar för att samtliga ingående driftsåtgärder för CA-systemet utförs till en med systemägare avtalad nivå.

5.2.2 Betrodda roller inom CA-systemet

Roller med arbetsuppgifter och högre behörigheter inom CA-systemet skall utföras av betrodda roller.

Respektive betrodd roll skall endast ha behörighet och åtkomst till de delar av systemet som motsvarar dennes roll och uppgifter.

CA-systemets samtliga roller skall finnas dokumenterade med beskrivning av arbetsuppgifter samt ansvar och befogenheter.



5.2.3 Krav på oberoende mellan betrodda roller

För att tillse att inte en ensam person kan kringgå säkerhetsarrangemangen, krävs att uppgifterna för CA-systemet utförs av flera olika personer i betrodda roller.

5.2.3.1 Oberoende administratörsroller

Administratör av programvara för CA respektive administratörer för informationssystem och infrastruktur som använder sig av utfärdade nycklar skall innehas av olika och av varandra oberoende personer. Initiala system där oberoende skall finnas är, domän/enterprise administratörer på Windows plattformen, administratör för e-post system samt administratörer för filkrypteringssystem.

5.2.3.2 Oberoende loggkontroll och analys

För att säkerställa ett oberoende mellan administrativa roller för CA-systemets komponenter och den roll som skall kontrollera eventuella oegentligheter skall roller för loggkontroll och analys respektive administratör av komponenter inom CA-systemet innehas av olika fysiska personer.

5.2.4 Krav på antal personer per uppgift

5.2.4.1 Krav på minsta antal personer som kan utföra uppgift

Av tillgänglighetsskäl och för att undvika nyckelpersonsberoenden skall varje betrodd identitet alltid förekomma med minst en (1) person ytterligare än vad som ytterst krävs för att utföra den rollens uppgift i CA-systemet.

5.2.4.2 Krav på dubbelkommando

För att förhindra att en ensam person kan kringgå säkerhetsarrangemangen i CA-systemet skall dubbelkommando krävas där minst två behöriga och betrodda roller skall finnas närvarande vid händelsen/operationen. Följande händelser/operationer skall kräva dubbelkommando:

• Hantering av alla Utfärdarens privata nycklar oavsett om det rör logisk eller fysisk hantering

• Förändring av befintlig eller skapande av ny betrodd roll • Förändring av befintlig eller skapande av ny certifikatprofil • Inloggning på CA-server med administratörsrättigheter

Återskapande av en certifikatinnehavares privata dekrypteringsnyckel (säkerhetskopia) skall alltid kräva närvaro av certifikatinnehavare själv, alternativt informationsägaren för den information som skall återskapas med hjälp av nyckeln eller certifikatinnehavarens närmast ansvarige chef tillsammans med person som innehar roll som CA säkerhetsadministration. Behörigheter för att beordra och själva utförandet av återskapande av säkerhetskopia skall beskrivas i särskild procedur och i enlighet med Riksbankens riktlinjer för informationsskydd.

Initiering av CA-systemet samt generering av Utfärdarens nycklar skall kräva närvaro av flera olika betrodda roller samt representant från ägarroller enligt särskild procedur som skall beskrivas i utfärdardeklarationen (CPS). Minst följande roller skall vara fysiskt närvarande vid ovanstående uppgifter:



• Samtliga personer som har roll som CA Systemtekniker • Samtliga personer som har roll som CA säkerhetsadministration • Auditor • Säkerhetschef • Systemägare

5.2.5 Identifiering och kontroll av varje roll

Identifiering av betrodda roller i CA-systemet skall ske med stark autentisering. Som alternativ till stark autentisering kan undantagsvis manuella rutiner med motsvarande styrka i autentisering tillämpas.

5.3 Säkerhetskontroll av personal

5.3.1 Bakgrund, kvalifikationer, erfarenhet och tillståndskrav

Säkerhetsprövning och kontroller med avseende på lämplighet för att utföra arbetsuppgifterna skall genomföras för personal med betrodd roll inom CA-systemet. Kontroller skall utföras i enlighet med Riksbankens riktlinjer för personskydd och regler för säker anställning.

5.3.2 Procedurer för kontroll av bakgrund

Registerkontroll (klass 3) skall genomföras för de personer som innehar roller med känsliga uppgifter inom CA-systemet. Kontroller skall utföras i enlighet med Riksbankens regler för registerkontroll.

5.3.3 Krav på utbildning

För alla betrodda roller enligt punkt 5.22, gäller att innehavare av dessa roller skall genomgå relevant och utförlig utbildning för arbetsuppgiften.

5.3.4 Frekvens och krav på repetitionsutbildning

All betrodd personal skall erbjudas relevant utbildning vid uppdateringar och förändring av CA-systemet.

5.3.5 Sekvens och frekvens för arbetsrotation


5.3.6 Påföljd för otillåtna handlingar

Systemägaren skall omgående byta ut personal där misstanke finns rörande fortsatt lämplighet för uppgiften. Systemägaren skall rapportera misstanke om oegentligheter till avdelningschef som hanterar förfarande för disciplinära åtgärder enligt Riksbankens riktlinjer för personskydd samt Riksbankens arbetsordning.

5.3.7 Krav på kontraktering av personal

Samtliga krav i avsnitt 5.3 – 5.3.5 skall gälla även kontrakterad personal. Påföljd för otillåtna handlingar för kontrakterad personal skall regleras i separat avtal med kontraktspart.


Teknisk säkerhet 29 [42]

6 Teknisk säkerhet

6.1 Generering och installation av nycklar

6.1.1 Generering av nycklar

Nycklar skall genereras utifrån slumptal. Processen att generera slumptal som bas för nyckelgenerering skall vara slumpmässig på sådant sätt att det är beräkningsmässigt ogörligt att återskapa ett genererat slumptal, oavsett mängden kunskap om genereringsprocessens beskaffenhet, vid vilken tidpunkt eller med hjälp av vetskapen om i vilken utrustning slumptalet skapades. Nycklar skall genereras på sådant sätt att ingen information om nycklarna hanteras utanför systemet för nyckelgenerering annat än genom säker överföring till avsedd lagringsplats. Nycklarnas unikhet skall uppnås genom att de genereras på sådant sätt och i sådan längd att sannolikheten för att två identiska nycklar genereras, är försumbar. Utfärdarens nycklar skall genereras av CA-systemet inuti en säkerhetsmodul certifierad enligt FIPS 140-29 nivå 3. Certifikatinnehavares nycklar för signering/identifiering skall skapas i innehavarens personliga hårdvarumodul. Generering av nyckel skall ske på sådant sätt att det minst motsvarar krav enligt FIPS 140-2 nivå 2. Certifikatinnehavares övriga nycklar skall genereras av CA-systemet eller i certifikatinnehavarens hårdvarumodul på sådant sätt att det minst motsvarar krav enligt FIPS 140-2 nivå 1.

6.1.2 Leverans av nycklar till certifikatinnehavare

Certifikatinnehavares privata signerings/identifieringsnyckel skall genereras i certifikatinnehavarens hårdvarumodul och leverans skall inte ske.

Certifikatinnehavares övriga nycklar skall levereras till certifikatinnehavare på ett säkert sätt i enlighet med IETF PKIX Certificate Management Protocols eller genom fysisk leverans med motsvarande säkerhetsnivå.

6.1.3 Leverans av publik nyckel till utfärdare

Certifikatinnehavares publika nyckel för signering/identifiering skall levereras till utfärdaren enligt IETF PKIX Certificate Management Protocols.

9 National Institute of Standards and Technology. Federal Information Processing Standards Publication 140-2: Security Requirements for Cryptographic Modules. January, 1994. FIPS 140-1 har ersatts successivt av FIPS 140-2 från och me d december 2001 och här anses dessa båda vara likvärdiga ur säkerhetssynpunkt.



6.1.4 Nyckelstorlekar

Alla nycklar skall vara så beskaffade att de överensstämmer med den säkerhetsnivå och tillförlitlighet som anges i denna policy under tillämpning och användning samt att dess integritet bibehålls under minst dubbla tiden av certifikatens angivna livslängd.

6.1.5 Generering av publika nyckelparametrar


6.1.6 Kontroll av kvalitet på nyckelparametrar


6.1.7 Användningsområde för nycklar

Utfärdarens certifikat avsedda för signering skall innehålla följande värden för attributet keyUsage: § keyCertSign § cRLSign

Certifikatinnehavares certifikat avsedda för signering skall innehålla följande värden för attributet keyUsage: § digitalSignature

Certifikatinnehavares certifikat avsedda för kryptering skall innehålla följande värden för attributet KeyUsage: § keyEncipherment

Inga andra värden skall finnas för attributet keyUsage.

6.2 Skydd av privat nyckel

6.2.1 Standard för kryptografisk modul

Utfärdarens nycklar skall skyddas i en säkerhetsmodul certifierad enligt FIPS 140-2 nivå 3. Utfärdarens privata nycklar skall aldrig lämna säkerhetsmodulen okrypterad och sammansatt i sin helhet. Certifikatinnehavares privata nycklar skall skyddas i en hårdvarumodul certifierad enligt FIPS 140-2 nivå 2.

6.2.2 Dubbelkommando vid hantering av privata nycklar

Åtkomst till utfärdarnycklarna i säkerhetsmodulen skall kräva två olika betrodda roller som innehas av två fysiskt skilda personer. Se även punkt 5.2.4.2.

6.2.3 Deposition av privata nycklar

Privata nycklar skall inte deponeras. Privata nycklar skall dock säkerhetskopieras i syfte att ge möjlighet till att dekryptera av Riksbanken ägd information då certifikatinnehavare ej är tillgänglig.



6.2.4 Säkerhetskopiering av privata nycklar

Utfärdarens privata nycklar skall säkerhetskopieras. Säkerhetskopian skall förvaras inlåst, i krypterad form och på plats som är geografiskt skild från den plats där originalet förvaras. Certifikatinnehavarens privata nyckel avsedd för kryptering skall säkerhetskopieras. Certifikatinnehavarens privata nyckel avsedd för signering/identifiering skall inte säkerhetskopieras. Säkerhetskopiering och hantering av säkerhetskopior av nycklar skall skyddas motsvarande för vad som gäller för originalnycklar. Procedurer för säkerhetskopiering och hantering av säkerhetskopierade nycklar skall dokumenteras i utfärdardeklarationen (CPS).

6.2.5 Arkivering av privata nycklar

Se avsnitt 4.6 Arkivering.

6.2.6 Aktivering av privat nyckel

Certifikatinnehavares privata nycklar skall enbart kunna aktiveras med de algoritmiska funktionerna i hårdvarumodulen. För aktivering skall krävas att rätt PIN anges.

6.2.7 Metod för deaktivering av privat nyckel

Certifikatinnehavares privata nycklar skall deaktiveras vid minst följande händelser: • Hårdvarumodul kopplas bort från PC • Tidsutloggning vid inaktivitet • När hårdvarumodulens strömförsörjning bryts • Certifikatinnehavare loggar ut

6.2.8 Metod för förstörande av privat nyckel

Uttjänta nycklar skall destrueras på sådant sätt att nyckel ej kan återanvändas eller läsas. Procedur för förstöring skall beskrivas i utfärdardeklaration (CPS).

6.3 Andra aspekter på hantering av nyckelpar

6.3.1 Arkivering av publika nycklar

Samtliga publika nycklar arkiveras genom att utgivna certifikat arkiveras. Se punkt 4.6.

6.3.2 Användningsperiod för publika- och privata nycklar

Enhet Giltighetsperiod

Utfärdarens nycklar för topp-CA 240 månader

Utfärdarens nycklar för underordnad-CA 120 månader

Interna certifikatinnehavares nycklar 24 månader

Externa certifikatinnehavare nycklar 12 månader



Rutinmässig och automatisk uppdatering av interna certifikatinnehavares nycklar skall ske senast 24 månader efter utgivandet. För extern certifikatinnehavare skall inte någon rutinmässig och automatisk nyckeluppdatering göras

6.4 Aktiveringsdata

• PIN för skydd av privata nycklar lagrade i hårdvarumodul skall bestå av minst fem (5) tecken.

• PUK skall bestå av minst åtta (8) tecken. • Aktiveringsdata avsedd för certifikatbegäran skall bestå av ett löpnummer samt en

slumpmässigt genererad aktiveringskod • Aktiveringskod avsedd för certifikatbegäran skall bestå av minst 12 tecken

6.4.1 Generering och installation av aktiveringsdata

Generering av PIN skall ske på sådant sätt att det är säkerställt att endast certifikatinnehavaren har tillgång till PIN.

PIN och skall kunna förändras av certifikatinnehavaren, PUK skall kunna förändras vid behov enligt särskild procedur.

6.4.2 Skydd av aktiveringsdata

Hårdvarumodul med PIN för aktivering av nycklar skall ha skydd mot att obehörig person slumpmässigt skall kunna ange korrekt PIN. Hårdvarumodul skall förhindra mer än tre (3) felaktiga försök att ange PIN genom att låsa vidare försök att ange korrekt PIN. För upplåsning av hårdvarumodul skall personlig upplåsningskod (PUK) anges. PUK skall vara personlig för certifikatinnehavare och hanteras enligt punkt 2.1.4.1. PUK skall säkerhetskopieras och förvaras som hemlig handling under säkra former av registreringsenheten (RA). PUK får endast lämnas ut till certifikatinnehavare mot säker identifiering.

6.4.3 Distribution av aktiveringsdata

PIN och PUK skall distribueras i separat försändelse till certifikatinnehavaren.

I de fall leverans sker utanför Riksbankens lokaler skall PIN och PUK distribueras som rekommenderad postförsändelse separat från och vid annan tidpunkt än försändelse av hårdvarumodul innehållande certifikat och nycklar.



6.5 Säkerhet i datorsystem

6.5.1 Specifika tekniska krav på datorsäkerhet

CA-systemet skall uppfylla nedanstående krav, endera genom operativsystemet eller som en kombination av operativsystem, CA-applikation, fysiskt skydd och manuella rutiner:

• Accesskontrollsystem skall identifiera operatörer på individuell nivå • All information i CA-systemet som är klassificerad som hemlig skall vara lagrad så

att obehörig åtkomst förhindras, informationen bör krypteras • All kommunikation till/från CA-applikationen som är klassifierad som hemlig skall

vara krypterad • Operativsystem som används som plattform för CA-systemet och omkringliggande

system skall vara installerat och härdat enligt Riksbankens anvisningar och instruktioner för respektive plattform

• Operativsystem och applikationer skall inte tillåta fjärradministration från annan plats än inom det avskilda nätverkssegmentet

6.5.2 Krav på klassificerad datorsäkerhet


6.6 Säkerhet under levnadscykel

6.6.1 Systemutveckling

Systemutveckling skall följa krav angivna i Riksbankens regler för informationsskydd, 8-1 Systemutveckling.

6.6.2 Säkerhetsadministration

Med säkerhetsadministration avses det säkerhetsarbete som kontinuerligt skall finnas integrerat i de drift och förvaltningsprocesser som finns för CA-systemet och tillhörande system under dess levnadscykel.

Systemägaren för CA-systemet skall tillse att det grundläggande säkerhetsarbetet utförs i enlighet med Riksbankens riktlinjer för informationsskydd samt regelverk gällande säkerhetsplan, 2-2 och risk och sårbarhetsanalys, 2-3.

Systemägaren för CA-systemet skall tillse att driftåtgärder och dokumentation utförs i enlighet med Riksbankens regelverk säker IT-drift, 6-2.

Systemägaren för CA-systemet skall tillse att systemförvaltning utförs i enlighet med Riksbankens regelverk systemförvaltning, 6-3.

Systemägaren för CA-systemet skall tillse att en väl fungerande rutin för förändringshantering existerar och att denna utförs i enlighet med Riksbankens regler för ändringshantering, 8-2. All system och driftsdokumentation skall uppdateras innan och praktiskt verifieras efter förändring skett i CA-systemet samt tillhörande system.

Systemägaren för CA-systemet skall tillse att rutiner för incidenthantering existerar och fungerar tillfredställande och att incidenthantering utförs i enlighet med Riksbankens regler för incidenthantering, 11-1.



Systemägaren för CA-systemet skall tillse att det finns rutiner för att åtgärda uppkomna brister och sårbarheter i programvaror och utrustning i enlighet med Riksbankens riktlinje för informationsskydd samt regler för styrning av kommunikation och drift, 2.6.

6.7 Nätverkssäkerhet

Logisk skydd för det datornätverk som CA-systemet och dess tillhörande system kommunicerar genom, skall utformas i enlighet med Riksbankens riktlinjer och regelverk. Det logiska skyddet skall vara starkt och förutom ordinära skyddsåtgärder omfatta följande,

• CA-systemet skall använda sig av ett eget åtskilt nätsegment • Nätsegmentet skall skyddas av brandvägg speciellt avsedd för segmentet. • IDS skall övervaka CA-systemets nätsegment i syfte att upptäcka skadlig eller

obehörig nätverkstrafik • Endast de protokoll som krävs för drift av CA-systemet skall tillåtas på

nätverkssegmentet. • All kommunikation till och från CA-applikationen som är klassificerad som hemlig,

skall skyddas enligt Riksbankens regler för Data och telekommunikation, 6-1

6.8 Kryptografisk säkerhetsmodul

CA-systemets, RA och certifikatinnehavares samtliga kryptografiska operationer skall ske på hårdvara speciellt framtagen för att klara kraven för nivå 3 respektive 2 enligt FIPS 140-2.


Certifikat- och CRL-profiler 35 [42]

7 Certifikat- och CRL-profiler

7.1 Formatversioner och profiler för certifikat

Certifikat skall utformas enligt X.509 v3, samt följa rekommendationerna i RFC 303910 och 2459 med de förtydliganden som redovisas i detta avsnitt.

7.1.1 Versionsnummer

Certifikat skall utfärdas enligt X.509 version 3.

7.1.2 Certifikatextensioner

Fältet PolicyInformation skall innehålla OID bunden till gällande policy enligt avsnitt 1.2.

7.1.3 Objektidentifierare för algoritmer


7.1.4 Användning av namnfält

DN för subject och issuer skall följa PKIX standarden och finnas i samtliga utfärdade certifikat. Attribut enligt under subject skall minst omfatta följande:

§ Landskod, enligt ISO 3166-1 A2 (Country Name)

§ Efternamn (Surname)

§ Förnamn (Given Name)

§ Tilltalsnamn + Efternamn (CommonName)

§ Företagsnamn (Organization Name)

7.1.5 Namnbegränsningar och former för namnbegränsningar


7.1.6 Objektidentifierare för detta dokument

Utfärdaren skall tillse att objektidentifierare enligt avsnitt 1.2 finns i samtliga till nyckelinnehavare utfärdade certifikat.

7.1.7 Användning av ”policy constraints extension”


7.1.8 Syntax och semantik för ”policy qualifiers”


7.1.9 Processregler för ”critical certificate policy extensions”


10 Internet Engineering Task Force. Public Key Infrastructure Standards Working Group.

Internet X.509 Public Key Infrastructure: Qualified Certificates Profile


Certifikat- och CRL-profiler 36 [42]

7.2 CRL-profil

7.2.1 CRL-versionsnummer

CRL skall utformas enligt X509 v2, CRL.

7.2.2 ”Extensions” för CRL och ”CRL entry” och deras status (critical eller non-critical)



Förvaltning av regler 37 [42]

8 Förvaltning av regler

8.1 Förfarande vid ändring av regler

8.1.1 Ändringar som kan ske utan underrättelse

Enbart språkliga justeringar och omdispositioner som inte påverkar säkerhetsnivån i beskrivna procedurer och regelverk skall företas i detta dokument utan att certifikatinnehavare och förlitande parter informeras.

8.1.2 Ändringar som kräver underrättelse

8.1.2.1 Typ av ändringar

Förändringar utöver punkt 8.1.1 som påverkar säkerhetsnivå oavsett omfattning i beskrivna procedurer och regelverk skall underrättas certifikatinnehavare och förlitande parter minst 30 dagar innan förändring sker.

8.1.2.2 Procedur för underrättelse

Underrättelse om förändringar i detta dokument enligt 8.1.2.1 skall publiceras på angiven plats enligt avsnitt 2.6. Underrättelse av externa parter skall ske via signerad e-post.

8.1.2.3 Tid för kommentarer

För att kunna beaktas skall kommentarer på förändringar vara inkomna senast 15 dagar innan förändring planeras ske.

8.1.2.4 Procedur för hantering av kommentarer

I dokumenterade beslut om förändringar skall inkomna kommentarer anges samt hur dessa har behandlats.

8.1.2.5 Tid för notis av slutlig förändring

Om inkomna kommentarer föranleder förändringar i det ursprungliga förändringsförslaget som inte täcks av den ursprungliga underrättelsen skall dessa förändringar träda i kraft tidigast 15 dagar efter publiceringen av en ny modifierad underrättelse i enlighet med 8.1.2.1.

8.1.3 Förändring som kräver fastställande av nytt dokument

Förändring som bedöms innebära en signifikant förändring av säkerhetsnivån i detta dokument eller tillhörande styrande dokument skall resultera i en ny publikation som ges en ny identitet (objektidentifierare enligt 1.2). På så vis kan certifikat utfärdade efter nya regler särskiljas från certifikat utfärdade efter tidigare gällande regler. Med signifikant förändring avses t.ex. förändringar som påverkar tillförlitligheten till Utfärdarens certifikat, förändring av logiska skyddsåtgärder, förändring av dubbelkommando för procedurer och rutiner alternativt att ny funktionalitet tillförs CA-systemets med en förändrad riskbedömning utifrån, sekretess, riktighet, tillgänglighet och spårbarhet.


Förvaltning av regler 38 [42]

8.2 Version och versionshantering

Detta dokument är fastställt i version 1.0 och gäller från och med 2004-XX-XX.

8.2.1 Versionshantering

Vid förändringar av detta dokument enligt avsnitt 8.1 som leder till ett fastställande av ett nytt dokument skall dokumentet ges ett nytt versionsnummer angivet i heltal. Tidigare fastställda versioner skall redovisas i det gällande dokumentet.

Följande versioner av detta dokument har tidigare fastställts

Version Datum Diarienummer -- -- --

8.3 Regler för publicering och spridning

8.3.1 Distribution av regelverk och utfärdardeklaration (CPS)

Se avsnitt 2.6, publicering och förvaringsplats.

8.4 Förfarande vid godkännande av utfärdardeklaration (CPS)

Systemägaren för CA-systemet ansvarar för att en utfärdardeklaration fastställs.

Utöver fastställandet av utfärdardeklarationen skall denna godkännas enligt en procedur som säkerställer att nedanstående punkter tillgodoses:

• Systemägaren skall kontrollera att samtliga krav och regler är tillgodosedda i CPS genom att genomföra ett driftgodkännande, se Riksbankens regler för informationsskydd, driftgodkännande, 8-3

• Systemägaren skall dokumentera kravuppfyllnaden gentemot CP och Riksbankens övriga regler på ett tydligt sätt i CPS och vid behov i övriga styrande dokument.

• All dokumentation skall utföras i skriftlig form och vara så utförd att den kan tjäna som ett gott underlag för att kontrollera kravuppfyllnaden vid granskning

• Systemägaren skall formellt fastställa CPS genom protokollfört beslut. CPS, övriga styrande dokument och beslutsprotokoll för fastställande, skall delges ägare/utgivare av CP. Beslutsprotokoll för godkännande och fastställande skall publiceras på samma plats som CP.


Förkortningar och definitioner 39 [42]

9 Terminologi, förkortningar och definitioner som används i detta dokument

Aktiveringsdata Information (ofta i form av en lösenordssträng) som måste anges för att aktivera en viss funktion och som syftar till att tillgodose att enbart behörig aktivering kan ske.

Beställare Den person som godkänner beställning av ett certifikat för en certifikatinnehavare.

CA (Certification Authority) Den logiska funktion som utfärdar certifikat. En CA består av en CA-applikation och en CA-server.

CA-applikation Applikation som är installerad på CA-server som används för framställande av certifikat.

CA-certifikat Certifikat som används för att validera äktheten i ett av CA framställt certifikat. Kopplar ihop en CA-nyckel med en namngiven CA.

CA-nyckel Nyckel som används av CA för att framställa certifikat.

CA-server Server som CA är installerad på inklusive operativsystem.

CA-system Fysisk representation av CA. Består av den utrustning som finns installerad på det interna PKI-nätet innanför CA:s interna brandvägg. (CA-applikation, CA-server samt nätverksutrustning och eventuell övrig kringutrustning för drift av CA)

Certifikat Ett intyg i elektronisk form av en CA som kopplar ihop en nyckel med en innehavare och bekräftar vem innehavaren är. CA förser intyget med en elektronisk stämpel (signatur) vars äkthet kan valideras med hjälp av CA-certifikatet.

Certifikatinnehavare, extern Den fysiska person för vilken ett certifikat har utfärdats och som har certifikatet i sin ägo. En extern certifikatinnehavare innehar INTE en e-postadress från Riksbanken.

Certifikatinnehavare, intern Den fysiska person för vilken ett certifikat har utfärdats och som har certifikatet i sin ägo. En intern certifikatinnehavare innehar e-postadress från Riksbanken.

Certifikatpolicy(CP) Ett regelverk enligt vilket ett certifikat avses användas inom en viss grupp eller klass av tillämpningar med gemensamma krav på säkerhet. Synonymt med detta dokument.



Certifikatutfärdare, Utfärdare

Den organisation som ger ut och ansvarar för tillförlitligheten i certifikatinnehavarnas certifikat.

Dubbelkommando System för att kräva minst två behöriga olika fysiska personer för att godkänna en åtgärd. Jmfr flerpersonskontroll

Elektroniskt godkännande En lägre grad av elektronisk signatur motsvarande en intern attest som kan härledas till godkännaren men inte har något direkt juridiskt värde.

Förlitande part Person/system som förlitar sig på ett certifikat vid verifiering av digitala signaturer och/eller kryptering av information eller säker identifiering.

Hårdvarumodul Hårdvara (t. ex smart kort eller USB-token) speciellt framtagen för att skydda en kryptografisk nyckel under dess användning och lagring. En hårdvarumodul skall minst hålla en säkerhetsnivå enligt FIPS 140-1 level 2.

Katalogtjänst Lagringsplats för certifikat och spärrlistor som är allmänt tillgänglig för alla certifikatinnehavare och förlitande parter.

Krypteringsnyckel Nyckel som används för att kryptera information.

Nyckel, privat Den hemliga delen av ett nyckelpar för kryptering i ett PKI-system där olika nycklar används för att kryptera och dekryptera.

Nyckel, publik Den publika(öppna) delen av ett nyckelpar för kryptering i ett PKI-system där olika nycklar används för att kryptera och dekryptera.

OID, objektidentifierare Ett sätt att erhålla en unik identifierare. En objektidentifierare registreras hos SIS som garanterar att den är unik i världen. Riksbanken har blivit tilldelade delträdet 1.2.752.91 och får fritt använda detta delträd.

PIN, PIN-kod Personligt identifikationsnummer, eller kod. Jämför lösenord.

PKI Infrastruktur för distribution av publika nycklar för kryptering eller signering. (Public Key Infrastructure)

PUK Personlig upplåsningskod, en upplåsningskod som måste anges för att låsa upp en hårdvarumodul före användning i de fall PIN saknas eller då felaktig PIN angivits för många gånger.



RA, Registreringsenhet Logisk enhet inom Riksbankens PKI som är CA:s gränsyta gentemot certifikatinnehavarna.

Roll, betrodd Roll inom Riksbanken som kräver att särskild prövning görs innan person tilldelas roll.

Signatur (elektronisk) Funktion som knyts till ett visst informationsbjekt. Används för att säkerställa att informationsobjektet oavvisligen skapats av den som framstår som skapare och att det inte har förvanskats/förändrats sedan skapandet.

Signeringsnyckel Nyckel som används för att skapa en elektronisk signatur.

Spärr En markering om att ett certifikat inte längre skall anses tillförlitligt. Spärr distribueras i form av spärrlistor i Riksbankens katalog. En spärr är oåterkallelig.

Spärr, temporär Se Spärr, med undantaget att en temporär spärr inte är oåterkallelig och alltså kan hävas vid ett senare tillfälle.

Spärrkontroll Kontroll som förlitande part gör av att certifikat inte är spärrat. Spärrkontroll görs vanligen gentemot en spärrlista i Riksbankens katalog.

Spärrlista (CRL) En signerad lista över spärrade certifikat.

Spärrtjänst Den operativa funktion som tar emot spärrbegäran och utför spärr av certifikat enligt fastställda procedurer.

Säkerhetsmodul Hårdvara speciellt framtagen för att skydda en kryptografisk nyckel under dess användning och lagring. En säkerhetsmodul skall minst hålla en säkerhetsnivå enligt FIPS 140-1 level 3. Kallas också för HSM (Hardware Security Module) och används främst för att skydda utfärdarnycklar.

Tillförlitlighet Mått på i vilken grad systemet levererar den information av given kvalitet den säger sig leverera samt tilltron till nivån. (SIS HB 550 Utg.2)

Topp-CA (Root) CA som befinner sig överst i en säkerhetshierarki. Topp-CA utfärdar och spärrar certifikat för en underordnad CA. (Se även underordnad CA)

Underordnad CA (sub) CA som i säkerhetshierarkin befinner sig under en annan CA. En underordnad CA har ett delegerat förtroende av en topp-CA att utfärda och spärra certifikat åt t ex fysiska personer.



Utfärdardeklaration (CPS) (Certificate Practise Statement) Beskrivning av de procedurer och rutiner som en certifikatutfärdare tillämpar för att uppfylla kraven i en certifikatpolicy.

Utfärdare Den roll som ansvarar för utfärdande av certifikat.

Utfärdarnyckel se CA-nyckel.

Validering Kontroll av följaktighet gentemot dokument, standard, process etc. Att validera ett certifikat är att kontrollera att detta är korrekt vad avser t.ex. giltighet och data.

Jmf. validitet – ”Mått på hur väl data speglar det verkliga förhållandet, giltigheten hos data”.

Verifiering Process för att kontrollera att ett antagande är korrekt. Begreppet avser främst processer för att kontrollera att en viss certifikatinnehavares privata nyckel – och ingen annans – använts vid signering eller liknande funktion.

Regler för utgivning och hantering av elektroniska certifikat · Denna version 1.0 av ”Regler...

Documents

Transcript of Regler för utgivning och hantering av elektroniska certifikat · Denna version 1.0 av ”Regler...