SITHS anpassning av IT system. Användarguide: Gör så här SITHS anpassning av IT System

SITHS anpassning av IT system Användarguide: Gör så här SITHS anpassning av IT System

Innehållsförteckning Inledning... 3 Dokumentets syfte... 3 Dokumentets målgrupp... 3 SITHS kort och certifikat... 4 Elektronisk id-handling digitala certifikat... 4 Ansvarig utfärdare CA och Rootcertifikat... 4 Tillämpning av PKI med spärrkontroll... 6 CRL, giltighetstid och uppdateringsprinciper... 6 Beskrivning av principen för PKI... 8 Smarta Kort... 9 Tillämpningsområden för SITHS-kort... 11 Mifare teknik... 11 SITHS certifikat på andras kort... 11 Inpasseringskontroll och SITHS kort... 11 Inloggning i AD... 12 SSO och Kerberos... 12 IIS webbserver... 12 Apache webbserver... 12 SITHS funktionscertifikat... 12 Certifikatanpassad webbapplikation... 12 Signerad och krypterad meddelandeöverföring... 13 Revisionshistorik Version Författare Kommentar 0.999 Thomas Näsberg Uppdatering av dokument 2011-03-10 1.0 Thomas Näsberg Uppdelning i underbilagor 2011-03-11 1.1 Christoffer Johansson Borttagning av referenser till dokument gällande Säker E-post. Då dessa blivit utdaterade. 1.2 Christoffer Johansson Borttagning av referenser till VPN Access, Applikationsportal och SAML-biljet enligt BIF Sid 2/13

Inledning Säkerhetskraven inom vård och omsorg är så höga att identifieringsmekanismen (certifikatet) måste förvaras på ett smart kort, SITHS-kortet. SITHS-kortet är en nationell säkerhetslösning som kan användas både som SIS-godkänt id-kort och som elektronisk id-handling. Med hjälp av ett SITHS-kort kan en medarbetare identifiera sig oberoende av var han eller hon arbetar i organisationen eller i landet. Det smarta kortet kan användas som fysisk och elektronisk idhandling, inpasseringskort till arbetsplatsen och vid inloggning i datorsystem. Dokumentets syfte Syftet med dokumentationen är att förenkla den tekniska anslutningen av IT system hos organisationer inom vård och omsorg till smarta kort användning SITHS korten. Dokumentets målgrupp Målgrupp för denna dokumentation är organisationer inom vård och omsorg och deras systemförvaltare av IT lösningar samt Leverantörer av IT system till sektorn vård och omsorg. Sid 3/13

SITHS kort och certifikat Elektronisk id-handling digitala certifikat Det vanligaste sättet att styrka sin identitet är att använda en godkänd id-handling. Behovet av att kunna identifiera sig finns även vid elektronisk kommunikation, t ex över Sjunet eller Internet. Ett digitalt certifikat är motsvarigheten till en fysisk id-handling. Digitala certifikat fungerar som en elektronisk legitimation. Digitala certifikat kan också användas för elektronisk underskrift av dokument. En digital signatur har samma juridiska giltighet som en bevittnad namnteckning på ett avtal. Ett digitalt certifikat enligt SITHS innehåller bland annat: utfärdarens identitet (issuer) utfärdarens elektroniska signatur (Signature Algorithm) identitet på ägaren (Subject) ägarens publika nyckel (Subject, RSA Public Key) giltighetsperiod (Validity, Not Before - Not After) löpnummer på certifikatet (Serial Number) användningsområde (Key Usage) Certifikaten följer oftast en standardiserad mall för att skapa struktur. ITU 1 har tagit fram en internationell standard, X.509 och i skrivandes stund är det X.509v4 som är aktuell standard. Ansvarig utfärdare CA och Rootcertifikat För att en id-handling skall vara godkänd måste den ha utfärdats av en organisation eller myndighet som har rätt att utfärda id-handlingar, t ex utfärdas pass av passmyndigheten och nationellt id-kort av Rikspolisstyrelsen. I egenskap av utfärdande myndighet går passmyndigheten i god för att passet är korrekt och säkerställer riktigheten genom att följa strikt kontrollerade rutiner för utfärdandet. Motsvarande gäller för digitala certifikat, men själva kvalitetssäkringen och godkännandet är mer komplicerat. SITHS CA går i god för korrekt utfärdande av HCC certifikat. Den som utfärdar digitala certifikat kallas för en certifieringsinstans, CA (Certification Authority). En CA kan variera i både storlek (antal utfärdade certifikat) och hur väl utfärdandet är kvalitetssäkrat. I mindre skala kan en CA vara uppsatt för det lilla kontoret med ett fåtal medarbetare. En sådan CA har oftast enklare rutiner och dess certifikat är enbart betrodda av den egna organisationen. I större skala har man ofta valt en global CA som levererar 1 ITU = International Telecom Union (tidigare CCITT eller Comité Consultatif International Téléphonique et Télégraphique) ansvarar för internationella standarder kring telekommuniktion. Sid 4/13

kvalitetssäkrade certifikat på kommersiell basis. Inom SITHS ansvarar Inera AB på uppdrag av CeHIS att vara CA för användare inom svensk vård och omsorg. Vissa större CA har valt att följa hårt kontrollerade rutiner och gå igenom en kvalitetssäkringsprocess som leder till att CA får en internationellt accepterad kvalitetsstämpel. Kvalitetssäkringsprocessen är både kostnadsdrivande och tar tid i anspråk, men är nödvändig för kvaliteten inför ett nationellt/internationellt arbete. WebTrust är ett exempel på en organisation som kan ge en CA en generellt accepterad kvalitetsstämpel. Kvalitetsstämpeln kan jämföras med rätten att utfärda godkända id-handlingar. En CA som har ett WebTrust godkännande kan ansöka om att hamna på olika programvarutillverkares vitlistor. En vitlistning innebär bland annat att användare slipper varningsmeddelanden vid anslutning till en WEB-sida identifierad med ett vitlistat certifikat. En rapporterad osäker webbplats har blivit bekräftad av pålitliga källor som bedräglig eller innehållande länkar till skadlig programvara och rapporterad till Microsoft. Microsoft IE rekommenderar att du inte tillhandahåller någon information till sådana webbplatser, se figur 1, 2 och 3. Figur 1. Presentation av ej betrodd webb sida. Figur 2. Presentation av betrodd webb sida (certifiering). Figur 3. Presentation av betrodd webb sida (utökad certifiering). Alla certifikat utfärdade av en CA kan sägas tillhöra en och samma familj. I jämförelsen motsvarar det som kallas rotcertifikatet familjens anfader. På samma sätt som barn ärver egenskaper från sina föräldrar så bygger alla certifikat som en CA utfärdar på rotcertifikatet. Sid 5/13

Rent tekniskt så signerar CA certifikaten som utfärdas med rotcertifikatet. Det är ungefär som att varje barn till anfadern alltid bär med sig sin födelseattest. Om certifikatutfärdaren inte är vitlistad, så måste användaren aktivt välja att lita på CA. SITHS CA har här valt att certifiera sig som betrodd CA inför Microsofts Internet Explorer. Aktiviteter är påbörjade kring Mozillas Firefox och Adobe. Tillämpning av PKI med spärrkontroll Jämförelsen slutar inte här för Anfadern har dessutom total kontroll över alla sina barn. Reglerna är hårda och de barn som inte följer reglerna blir uteslutna ur familjen och hamnar på en svartlista. Reglerna i liknelsen är de policys och rutiner som CA följer. Uteslutningen ur familjen motsvarar den revokering (spärr) som en CA gör då ett certifikat missbrukats eller kommit i orätta händer. Svartlistan heter i certifikatsammanhang revokeringslista (CRL). En något modernare teknik av spärrkontroller sker med sk OCSP förfrågningar. En OCSP fråga ställer bara frågan om ett givet certifikat är spärrat medan en crl hantering går igenom hundratusentals rader i en datafil. Specifikationerna för dessa standarder finns i RFC 5280, Certificate Revocation List (CRL) Profile RFC 2560, Online Certificate Status Protocol - OCSP Ett sätt att optimera spärrkontrollen är att kontrollera certifikatets giltighet, vilket bör bygga på tre principer: 1. Litar jag på den ansvarige utfärdaren, dvs rotcertifikatet (SITHS CA ver 3)? attributet "Utfärdare" (eller "Issuer") 2. Har certifikatet passerat eller inte passerat "bäst före datum"? attributet "Giltigt till" (eller "Valid: Not After") 3. Är certifikatet spärrat? attributet "Distributionspunkt för lista över återkallade certifikat (CRL)" (eller "CRL Distribution Points") = CRL Spärrlista attributet "Åtkomst till information om utfärdare" (eller "Authority Information Access") = OCSP Spärrserver Släktskapet och den strikta kontrollen gör att den som litar på anfadern med automatik även kan lita på alla barnen. Den tekniska jämförelsen är att den som installerat en CA rotcertifikat med automatik även litar på alla certifikat som CA utfärdat. CRL, giltighetstid och uppdateringsprinciper I specifikationen för hur en CRL fomatteras och hanteras (rfc5280) finns ett antal attribut som informerar om när och hur ofta en CRL skall uppdateras. Dessa attribut är This Update Den tidpunkt när CRL:en publicerades Sid 6/13

Next Update Den tidpunkt när nästa CRL senast skall publiceras. Next CRL Publish En Microsoft crl extension, som indikerar när nästa CRL kommer att publiceras Då det finns ett visst utrymme för tolkningar i specifikationen har följaktligen olika tillverkare tolkat den lite olika. Detta gör att den organisation som skall använda CRL:erna måste hantera de olika tolkningarna. Tolkning1: Den vanligaste tolkningen av Next Update är att det är den tid man senast kan förvänta sig en uppdaterad CRL-lista (bäst före datum). Vad som skall hända om det inte kommer någon uppdatering i tid, eller att man av något annat skäl misslyckas med att hämta en ny CRL innan tiden i den gamla CRL:en har passerat Next Update, är upp till den organisation som använder CRL:en. Att Next Update har passerats innebär med denna tolkning därför inte automatiskt att systemet är trasigt, utan att situationen skall hanteras enligt den säkerhetspolicy som gäller för den organisation eller system som utnyttjar PKI n. Tolkning2: Microsoft, och därmed alla system och applikationer som baseras på Windows PKI gör en annan tolkning av Next Update. I denna tolkning är Next Update det samma som sista förbrukningsdag, och om/när CRL ens Next Update har passerats utan att en ny CRL har kunnat hämtas kommer all användning av certifikat och PKI funktioner att blockeras. Följden av denna hårdare tolkning är att tekniska fel, avbrott på förbindelsen mellan användande system och det som publicerar CRL:en, och liknande situationer kommer att riskera utestänga alla från de system som utnyttjar PKIn. Microsoft har därför lagt till ett extra attribut i sina CRL:er, Next CRL Publish, som talar om när nästa CRL förväntas publiceras, och när det lokala systemet bör uppdatera sin CRL för att undvika att bli utestängd. Konsekvenser: Man kan se två olika huvudspår för systemens beteende om Next Update har överskridits. 1. Kör vidare under en begränsad tid medan felet avhjälps. 2. Stäng av alla autenticeringsfunktioner då PKI:n inte kan garantera giltigheten av certifikaten. Utgår man från Tolkning1 av rfc:n är den naturliga konsekvensen att använda spår 1, och endast i vissa fall med extrema krav på säkerhet använda spår 2. Med Tolkning2 av rfc:n blir konsekvensen att spår alltid 2 används, och det blir därför extremt viktigt att systemet utnyttjar Next CRL Publish attributet för att i god tid hämta en ny CRL med längre giltighetstid eller larma om en ny CRL inte är tillgänglig. Flera leverantörer: Knuten, eller det besvärliga med de olika tolkningarna uppstår i en blandad miljö där en PKI från en leverantör använder Tolkning1, och ett tillämpningssystem baserar sig på Tolkning2. I Sid 7/13

dessa fall kommer det tillämpningssystemet sannolikt inte att hitta något Next CRL publish attribut i CRL-listan, utan den första varningen man får om något har gått fel är att man blir utestängd. Implementationen av ett tillämpningssystem i en sådan miljö måste därför vara väldigt noga med att ha tillförlitliga förbindelser med en CRLDP, för att på så sätt minska risken för utelåsning. Microsoft har uppmärksammat detta problem och har från och med Windows Vista SP1, och Windows Server 2008 öppnat för att via en AD GPO sätta en extra tidsperiod för giltigheten efter NextUpdate, och på så sätt låta systemet fungera en viss tid efter en överskriden Next Update, och i praktiken använda spår 1. Beskrivning av principen för PKI Public Key Infrastructure (PKI) är en metod och teknik som gör det möjligt att med hög säkerhet utbyta information över ett i grunden osäkert offentligt nätverk, som till exempel Internet. PKI baseras på asymmetrisk kryptering. Basen för asymmetrisk kryptering är nyckelpar bestående av en privat och en publik nyckel. Nycklar i ett nyckelpar är unika. Det som krypterats med nyckelparets privata nyckel kan enbart öppnas med nyckelparets publika nyckel. På motsvarande sätt kan det som krypterats med den publika nyckeln endast öppnas med den privata nyckeln. Nyckelparen skapas av CA och distributionen sker i form av digitala certifikat. Certifikaten registreras och hanteras av en registreringsinstans, RA (Registration Authority). RA har bland annat ansvar för att rätt person erhåller den privata nyckeln i ett nyckelpar. Den privata nyckeln kan lagras på smarta kort, detta kallas ofta ett hårt certifikat, eller i en dator i form av ett mjukt certifikat. I båda fallen tillåts åtkomst med hjälp av en PIN-kod eller ett lösenord, som en extra säkerhet mot missbruk. Den anslutna RA organisationen har här ett delegerat ansvar för det lokala/regionala arbetet. Användare som tillhör en PKI har alla tillit till samma CA. De litar därmed på samtliga andra enskilda användare. En användare behöver därmed inte utbyta publika nycklar med alla andra, vilket skulle bli ohållbart med många användare. De publika nycklarna görs tillgängliga för samtliga PKI användare. Enbart den enskilde användaren har tillgång till sin privata nyckel. Systemet bygger på att det inte går att utröna den privata nyckeln även om man har den tillgång till den publika. Varje användares publika nyckel knyts till användarens uppgifter med hjälp av ett digitalt certifikat. Detta certifikat försäkrar att den man kommunicerar med verkligen är den person den uppger sig vara. Certifikaten och dess nycklar gör det möjligt att elektroniskt identifiera, signera eller kryptera information. PKI erbjuder därför användarna följande: Identifiering Autentisering, att med säkerhet kunna fastställa en identitet, t.ex. vid en inloggning. Signering Oavvislighet, att en handling inte skall kunnas förnekas i efterhand av användaren som skapat den. Innehållet ska vara juridiskt bindande. Riktighet, förmåga att upprätthålla skydd mot oönskad modifiering av information. Kryptering Konfidentialitet, att informationen endast är tillgänglig för den som ska ha rättighet till den. Sid 8/13

Smarta Kort Smarta kort, som ibland även kallas aktiva kort, skiljer sig från traditionella kort med enbart magnetremsa. Kort med magnetremsa innehåller oskyddad information. Smarta kort har ett chip som skyddar informationen. Smarta kort finns i två varianter, de med minne och de som även innehåller en mikroprocessor. Smarta kort med minne kan enbart lagra data medan de med mikroprocessor kan ta bort och manipulera information. Kortet är en miniatyrdator med en I/O port, operativsystem och en hårddisk med inbyggda säkerhetsfunktioner. Ett smart kort med mikroprocessor går att programmera så att det kan utföra olika operationer. Det kan till exempel fungera som: elektroniskt ID-kort, smart bankkort, passerkort, telefonkort eller tjänstekort, etc. SITHS-kortet, se figur 3, är ett s.k. smart kort med mikroprocessor. Det finns två olika sätt att läsa informationen på korten (dual interface eller kontakt/kontaktlösa kort). Så kallade kontaktkort kräver en kortläsare för att kommunicera med chippet medan kontaktlösa kort har en inbyggd antenn som gör det möjligt för en speciell kortläsare att på kort avstånd kommunicera via radiosignaler med kortet. Kontaktlösa kort är snabbare. SITHS-kortet är ett kontaktkort. De flesta smarta kort är personliga och kräver att innehavaren till kortet matar in en PIN-kod då det används för till exempel inloggning eller identifiering. I säkerhetssammanhang pratar men om tvåfaktoridentifiering 2. SITHS-kortet är en två-faktoriseringsmekanism: du kan något (PINkoden) och du har något (SITHS kortet). Figur 4. SITHS smarta kort (SIS-kort, Företagskort och Reservkort). För att få en fungerande PKI inom SITHS används följande referensmiljö: Operativsystem: Windows XP (SP3), Windows Vista (SP2), Windows 7 Webbläsare: Internet Explorer, version 7 eller 8, säkerhetsnivå mellan (tillförlitliga 2 Principen med en-, två- eller tre-faktorisering: {Kan, Kan/Har, Kan/Har/Är} Sid 9/13

platser/ trusted site ) CSP: Net ID 3 version 5.3.0.28 eller senare Användarnamn och lösenord ansågs tillräckligt när användarna arbetade på ett och samma kontor eller arbetsplats. I värsta fall kunde kollegorna logga in med varandras användarnamn och lösenord. Säkerhetskraven ökar med distans- och gästanvändare. I och med att distansarbete tillåts exponeras organisationens datamiljö mot Internet. Enbart användarnamn och lösenord ger inte längre tillfredställande säkerhet. Med hjälp av SITHS-kort kan användaren enkelt och säkert logga in med sitt smarta kort i sin datormiljö på arbetsplatsen eller via VPN (virtuellt privat nätverk). Inloggningen kan ske i en domän, eller med hjälp av tunna klienter som Citrix eller Windows Terminal Server. Om tunna klienter används kan användaren även logga ut genom att ta ut SITHS-kortet och sedan logga in igen med kortet från samma eller från en annan arbetsplats (kiosk mode/hot seeting). Användaren kommer då tillbaka till samma session som tidigare och kan omedelbart fortsätta arbeta. 3 Net id är en kryptografisk klientprogramvara (CSP) som möjliggör användning av individuella certifikat för användaren. Net id läser certifikat på smartkort, signerar dokument och identifierar användare i olika system. Med Net id får man inte bara inloggning via smartkort utan även tillgång till Internetbaserade tjänster som kräver elektronisk identifiering och signering (PKI). Man kan till exempel skicka säker e-post via ex. Microsoft Outlook. Det går även att använda Net id för inloggning i olika typer av Single-Sign-On lösningar. Sid 10/13

Tillämpningsområden för SITHS-kort Mifare teknik Se bilaga Mifare Specifikation HCC v 1.0.pdf Se bilaga Mifare Specifikation utan HCC v 1.0.pdf SITHS certifikat på andras kort Se bilaga SITHS certifikat på kort och koppling till HSA v1.0. Inpasseringskontroll och SITHS kort Streckkodning Streckkod kodas normalt på kortets baksida med teckenkodning xxx och innehåller medarbetarens personnummer (eller Reservkortets serienummer), men kan som Kundunik produkt kodas med annan information (t ex HSA-ID) och placeras på kortets framsida. Magnetbandskodning Enligt den med SITHS överenskomna standarden (HiCo magnetband med 3 spår - ISO standard 7811 1-6) för dessa kort kodas kortets serienummer med dess 16 sista siffror på magnetbandets spår 2. Det finns dock möjlighet att för vissa korttyper välja vilka spår som ska kodas och vilken information som ska kodas på magnetremsan. Organisationen kan själva fritt koda om spår 2 (eller 1 och 3). RFID kodning SITHS korten använder sig av en Mifare Classic standard, Mifare RF Interface (ISO 14443 A). Antingen kan mifareserienumret i mifareslingan (sektor 0) användas för kontaktlös inpassering, eller så kan man använda sektorläsning. Sektor 14 kodas med de 16 sista tecknen i kortserienumret och sektor 15 kodas med HSA-id (om kortet har ett HCC), se specifikation Mifare Specifikation HCC v 1.0. Sektorläsningen kräver tillgång till en A-nyckel, se särskild instruktion Instruktion överlämning av Mifare A-nyckel. Tanken är att HSA-ID och/eller kortets serienummer exporteras till användarens HSA katalog (precis som certifikatet). En export därifrån till organisationens logistik/intelligens för inpasseringssystemen kan sedan genomföras. Kortläsarna skall då kunna känna igen det som presenteras från Mifaresignalen, dvs. HSA-id eller Kortets serienummer. Följande sektorer är nu reserverade inom SITHS: Sektor noll: Leverantörens inläsning av Mifarekretsens serienummer (9-10 tecken) Sektor 14: SITHS inläsning av kortets serienummer (16 + 16 tecken) Sektor 15: SITHS inläsning av medarbetarens HSA-ID (16 + 16 + 16 tecken) Sid 11/13

Sektor 13: Västra Götalands inläsning av information för lokaltrafiken Sektor 16-32: Västra Götalands inläsning av information för lokaltrafiken Inloggning i AD Se bilaga SITHS inloggning i AD v1.0. SSO och Kerberos Se bilaga SITHS SSO och Kerberos v1.0. IIS webbserver Se bilaga SITHS IIS inloggning v1.0. Apache webbserver Se bilaga SITHS Apache inloggning v1.0. SITHS funktionscertifikat Funktionscertifikat är ett certifikat som företräder en funktion, oftast i form av en server och kallas därför ofta servercertifikat. Själva formatet på certifikatet är en krypterad fil, en PKCS#12-fil (alternativt PKCS#10-fil). Denna fil innehåller dels det publika certifikatet som mottagaren behöver känna till och dels den privata delen med nyckel som endast ägaren till certifikatet skall ha kännedom om. En publik kopia av funktionscertifikatet laddas med automatik ned till organisationens externa HSA katalog. Tillhörande PIN-kod är nödvändig för att kunna öppna det låsta certifikatet och dela upp det med dess privata nyckel och det publika certifikatet för att slutligen installera certifikatet på servern. Ett tillhörande regelverk avgör hur en beställning går till, se utbildningsmaterial för RA. Certifikatanpassad webbapplikation Se bilaga SITHS certifikatanpassad webbapplikationv1.0. Sid 12/13

Signerad och krypterad meddelandeöverföring Identifiering Autentisering, att med säkerhet kunna fastställa en identitet, t.ex. vid en inloggning. Signering Oavvislighet, att en handling inte skall kunnas förnekas i efterhand av användaren som skapat den. Innehållet ska vara juridiskt bindande. Riktighet, förmåga att upprätthålla skydd mot oönskad modifiering av information. Kryptering Konfidentialitet, att informationen endast är tillgänglig för den som ska ha rättighet till den. Sid 13/13