sou · GYB3104 · 2010-12-23 00:00:00 — Anvisningstjänsten använder federationens metadata för att fastställa vilken Identitetsutfärdare som användarens e-legitimation är kopplad till i federationen. 3.Anvisningstjänsten returnerar uppgift om Identitetsutfärdare (IdP) som en HTTP Get request enligt [SAML-Discovery] till e-tjänsten i en HTTP redirect. Utformning av webbgränssnitt där användaren väljer e-legitimation är inte specificerad. Avisningstjänsten bör erbjuda användarens klient en cookie enligt [rfc2965] för att spara användarens val av e-legitimation för att underlätta framtida val av e-legitimation. Denna cookie ska vara identisk med den cookie som användaren erbjuds i utförande 2 (se avsnitt 6) Följande avgränsningar gäller för implementering av [SAML- Discovery] Måste vara satt till false i alla request till anvisningstjänsten Ska utelämnas från request till anvisningstjänsten (Anvisningstjänsten returnerar ett entityID) Denna parameter ska alltid medfölja en request till anvisningstjänsten och ska identifiera den URL som anvisningstjänsten ska returnera användaren till efter val av e-legitimation. Om anvisningstjänsten erhåller en request som bryter mot någon av reglerna ovan, eller om anvisningstjänsten av annan anledning inte kan fastställa vilken Identitetsutfärdare som användaren ska anvisas till för autentisering, så ska anvisningstjänsten returnera användaren till e-tjänsten till den URL som anges i returnIDParam, men utan att returnera någon entityID för Identitetsutfärdare. 5.1Krav på kontroll av mottagande e-tjänst För att förhindra att någon som inte är en registrerad e-tjänst kan vidarebefordra användaren till anvisningstjänsten för att utröna användarens val av e-legitimation så måste anvisningstjänsten kontrollera att e-tjänstens internetadress som specificeras av return parametern överensstämmer med en internetadress för en legitim e-tjänst i metadataregistret. 6Utförande 2 – e-tjänst med eget gränssnitt för val av e-legitimation Det saknas någon standardiserad lösning för en Anvisnings- tjänst som tillhandahålls till e-tjänster som själv implementerar gränssnittet för val av e-legitimation. Den lösning som presenteras i detta avsnitt utgör ett grundförslag som beskriver en av många möjliga lösningar. I detta utförande tillhandahåller e-tjänsten en dynamisk webbsida (Java Server Pages) för val av e-legitimation som implementerar AJAX (Asynchronous JavaScript and XML) kommunikation med anvisningstjänsten för att hämta hem anvisningsinformation i JSON (JavaScript Object Notation) format. Då användarens webbsida hämtar JSON informationen genom AJAX anrop så skickas även användarens cookie med förvals- information till anvisningstjänsten som därmed anpassar den returnerade JSON informationen efter användarens förval. Java script i den dynamiska webbsidan anpassar användarens gränssnitt för val av e-legitimation baserat på JSON informationen från anvisningstjänsten. E-tjänsten returnerar en webbsida med logik för att hämta anvisningsdata genom AJAX utväxling 2.Webbklient gör en AJAX request (XMLHttpRequest) som inkluderar användarens cookie. Anvisningstjänsten returnerar anvisningsdata i JSON format 3.Uppdatering av cookie initierat av användarens val av e- legitimation 4.HTTP request med information om användarens val av Enligt detta utförande sker anvisning av Identitetsutfärdare enligt följande förfarande: 1.E-tjänsten tillhandahåller en dynamisk webbsida (Java Server Pages) med AJAX instruktioner 2.Användarens webbläsare gör ett AJAX anrop (XMLHttpRequest) för att hämta ett JSON objekt med anvisningsdata. Användarens cookie med information om användarens preferenser (om sådan finns) medföljer anropet. JSON objektet anpassas av anvisningstjänsten utifrån användarens preferenser. Användarens gränssnitt skapas utifrån mottagen information från anvisningstjänsten. 3.Användarens val initierar uppdatering av användarens cookie med information om användarens senaste val. 4.Ett HTTP request skickas till e-tjänsten med information om vilken Identitetsutfärdare som ska legitimera användaren. 6.1Cookie format och användning Cookie med information om användarens preferenser konsumeras endast av anvisningstjänsten. Det är upptill anvisningstjänsten att utforma cookie så att den tillhandahåller nödvändig information men ska utformas i enlighet med RFC 2965 [rfc2965]. För det fall en användare använder flera e-legitimationer, eller samma webbläsare används av flera användare med olika e- legitimationer, ska en cookie kunna lagra information om flera valda e-legitimationer. Livslängd för cookie ska sättas så att den består mellan en typisk användares utnyttjande av e-tjänster. Detta bör inte överstiga av . En cookie bör innehålla information om tidpunkt för senaste val av respektive e-legitimation så att ett förval kan tas bort om denna e-legitimation inte används mer men att cookien ändå förnyas regelbundet genom val av annan e-legitimation. 6.2Format för JSON data Format för JSON data måste följa ett väl definierat format så att e- tjänsters dynamiska webbsidor kan tolka informationen från anvisningstjänsten och dynamiskt uppdatera användarens gräns- snitt. Detta format bör utarbetas och vid behov uppdateras av e- legitimationsnämnden i samråd med federationens e-tjänster. and Profile, Specification 01, 27 2008 RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1, IETF Draft Standard, 1999. (TLS) Protocol Version 1.2, IETF Proposed standard, 2008. Mechanism, IETF Proposed Standard, Central signering för myndigheters e-tjänster med stöd av identitetsfederationen för svensk e-legitimation Detta dokument beskriver en möjlig utformning av en svensk central signeringstjänst som kan användas av svenska myndigheter och offentlig sektor för att låta användare av Svensk e-legitimation signera elektroniska handlingar. Den lösning som beskrivs är avsedd att om möjligt skapa kvalificerade elektroniska signaturer enligt svensk lag (2000:832) om kvalificerade elektroniska signaturer. Syftet är inte att ta ställning till om detta är ett nödvändigt krav för svenska myndigheter, utan för att beskriva vad som krävs för att detta ska kunna realiseras. Materialet i detta dokument har som syfte att fungera dels som beslutsunderlag men även som arkitekturförslag för ett implementeringsprojekt. Ytterligare tekniska specifikationer krävs för en komplett specificerad lösning. En viktig slutsats är att de krav som identifierats för en signeringstjänst inte kan uppfyllas av en och samma utförande av signeringstjänsten. Därför beskrivs två alternativa utföranden med respektive fördelar och nackdelar. Ytterligare utredning av myndigheters och offentlig verksamhets behov krävs för att besluta om inget, ett eller båda dessa alternativa utföranden ska implementeras. Som ytterligare del i ett sådant beslutsunderlag bör tillfogas myndigheters och offentlig verksamhets behov av elektroniska signaturfunktioner där detta ställs mot alternativa lösningar, som exempelvis att en användare godkänner information enbart genom legitimering, utan att signera informationen. För det fall att inget av de föreslagna alternativen bedöms vara genomförbara förs en diskussion om möjliga övriga alternativ med begränsad funktionalitet som kan realiseras inom ramen för en federativ infrastruktur för identifiering. Denna tekniska del av utredningen av en signeringstjänst tar inte ställning till hur många signeringstjänster som ska kunna finnas, affärsmodeller eller olika konkurrensaspekter. Följande termer används med gemensam innebörd: elektronisk underskrift, underskrift, elektronisk signatur, signatur och avancerad elektronisk signatur dokument, handling och information I detta dokument används följande begrepp: Även ofta benämnt fingeravtryck är en kontrollsekvens av data som beräknas från ett dokument med hjälp av en hashalgoritm. Hashalgoritmer är så beskaffade att ett varje dokument har ett unikt hash. När ett dokument signeras så är det dokumentets hash som signeras och inte själva Data, knutet till ett elektroniskt dokument som kan användas för att verifiera vem som signerat dokumentet och att dokumentet inte förvanskats. Not: Det generella begreppet elektronisk signatur används i detta dokument ekvivalent med begreppet avancerad elektronisk signatur enligt signaturlagen [Sig]. Data som utfärdats till en användare och signerats av en certifikatutfärdare vars användningsområde i detta dokument är begränsat till att verifiera en användares Certifikatet innehåller information om användarens identitet, nyckel för att verifiera användarens signaturer samt information om Not: Det finns certifikat som har andra användningsområden än signaturverifiering men i detta SOU 2010:104 Bilaga 17 dokument diskuteras endast certifikat som används för att verifiera innehavarens elektroniska signaturer. Ett certifikat som utfärdats som kvalificerat certifikat i enlighet med signaturlagen [Sig]. certifikat ställer särskilda krav på utfärdare och dess ansvar för utfärdade certifikat En kryptografisk modul för skapande av elektroniska signaturer som uppfyller signaturlagens [Sig] krav på en säker anordning för signaturframställning. En elektronisk signatur enlig definition ovan som framställts av en säker signeringsfunktion och som kan verifieras med ett kvalificerat certifikat Kryptografiska data knutet till ett elektroniskt dokument som intygar att ett dokument existerade i ett specifikt Not: Det dokument som tidsstämplas innefattar vanligtvis även en elektronisk signatur. intygar tidsstämpeln såväl att dokument som dess signatur existerade vid den specificerade tidpunkten. kan myndigheter låta en användare signera elektroniska handlingar med sin e-legitimation. Vid detta förfarande signerar användaren den elektroniska handlingen lokalt i sin dator med hjälp av sin egen e-legitimation. E-tjänsteleverantören ombesörjer kommunikation med klienten som resulterar i att användaren accepterar och signerar en elektronisk handling. Inom den så kallade Infratjänsten tillhandahålls ett gemensamt gränssnitt OSIF (Offentligt Sammanhållen Identifierings Funktion) mot e-legitimationsutfärdarna för att underlätta legitimering och signering med användarnas e- legitimation. Vid tillämpning av OSIF-protokollet för signering skickas den information som ska signeras först till OSIF-servern för att anpassas till respektive typ av klientprogramvara som ombesörjer signering i användarens dator. Om denna OSIF-server tillhandahålls av en extern infratjänst så innebär detta att alla dokument som signeras passerar en central tjänst. I ett senare led av signeringen verifierar samma OSIF-server att användarens signatur överensstämmer med den information som e-tjänsten begärde få signerad. Även om OSIF-protokollet är gemensamt för samtliga aktuella utfärdare av e-legitimationer så skickas olika data i skilda dataformat beroende på vilken klientprogramvara som installerats i användarens dator. Detta innebär att dagens tillämpning av OSIF- protokollet är direkt knuten till den funktionalitet och de dataformat som nuvarande klientprogramvaror kräver. Elektronisk signering enligt denna modell innebär samman- fattningsvis följande: Signeringen sker i användarens dator Endast de e-legitimationer som är certifikatbaserade kan användas för signering. Andra former av e-legitimationer, ex kryptografiska kod-dosor, kan inte användas. Användare måste ladda hem en särskild programvara som ombesörjer signering av information som skickas från e- tjänsten, en s.k. klientprogramvara. Nuvarande protokoll för att understödja e-tjänsters hantering av legitimering och signering är knuten till nuvarande klientprogramvaror. Verifiering av användares elektroniska signatur förutsätter teknisk anpassning mot samt avtal med e-legitimations- utfärdarna. Den information om spärrning av certifikat som krävs för en oberoende verifiering av signatur, är inte öppet tillgänglig. Detta innebär exempelvis att signaturer inte kan verifieras av utländska aktörer som saknar avtal med e-legitima- tionsutfärdarna. Vid tillämpning av OSIF-protokollet mot en central OSIF- server så görs handlingen som ska signeras tillgänglig för en central tjänst. I en framtida infrastruktur för Svensk e-legitimation som bygger på en SAML baserad federativ modell, innebär detta en rad problem: Den nuvarande modellen för signering är i grunden knuten till dagens leverantörer av e-legitimationer och kan inte med automatik utökas till att omfatta nya typer av e-legitimationer, särskilt inte de där användaren inte innehar certifikat för signering. Det finns visserligen leverantörer inom dagens Infratjänst som kan stödja legitimering och signering även med andra utfärdare av certifikatbaserade e-legitimationer, men detta kräver tillpassningar i de e-tjänster som ska acceptera e- legitimationerna vilket försvårar anslutning av nya e- legitimationer. Den nuvarande modellen bygger på infrastruktur-komponenter och tjänster som inte återfinns i den federativa modellen. Fortsatt signering enligt nuvarande modell innebär därför att man tillämpar två olika infrastrukturer med olika affärsmodeller, dvs. en federativ modell för identifiering och den nuvarande infrastrukturen för signering. Den nuvarande modellen tillåter inte att vem som helst, som inte har avtal med e-legitimationsleverantörerna, kan verifiera elektroniska signaturer. Dessa signaturer kan därför inte användas exempelvis vid internationell informationsutväxling. De mest signifikanta skillnaderna mellan en central signeringstjänst enligt avsnitt 0 och dagens modell och är att: Användaren behöver inte installera någon specialkonstruerad klientprogramvara. Hela processen att signera kan utföras med en vanlig webbläsare. Innehavare av alla typer av e-legitimationer ges möjlighet att skriva under elektroniskt. Även användare som inte innehar certifikatbaserade e-legitimationer1. Nya e-legitimationsutfärdare kan adderas till infrastrukturen utan att tillpassning av protokoll och implementering i e- tjänster. Alla enheter som kan hantera en e-legitimation och en webbläsare kan användas för signering, ex mobiltelefoner. Signaturer kan skapas som kvalificerade elektroniska signaturer och signaturerna kan verifieras av oberoende tredje part som inte har avtal med e-legitimationsutfärdarna. Även de som inte har förlitandeavtal gentemot e-legitimations- utfärdarna kan verifiera underskriften på signerade handlingar. 1 Användare använder endast sin e-legitimation för att legitimera sig mot signeringstjänsten som utför själva signeringen. Det som är avgörande är den tillitsnivå som e-legitimationen erbjuder, inte vilken teknik den tillämpar för legitimeringen. 4Central signering och kvalificerade elektroniska signaturer En central fråga för beslut om genomförande är om en central signeringstjänst kan uppfylla signaturlagens krav på en kvalificerad elektronisk signatur. De mest relevanta kraven i detta hänseende utgörs av 3 § signa- turlagen gällande Säkra anordningar för signaturframställning 3 § En anordning för signaturframställning som anges vara säker ska säkerställa att signaturen är tillfredsställande skyddad mot förfalskning. Anordningen ska även säkerställa att signaturframställnings- data 1.i praktiken kan förekomma endast en gång, 2.med rimlig säkerhet inte kan härledas, och 3.på ett tillfredsställande sätt kan skyddas av den behörige undertecknaren, så att andra inte kan komma åt eller använda Anordningen får inte förändra de uppgifter som ska signeras elektroniskt eller hindra att de presenteras för undertecknaren före den elektroniska signeringen. Den viktigaste frågeställningen i detta sammanhang är om signatur- framställningsdata (privat signeringsnyckel) i en central signerings- tjänst kan skyddas av den behörige undertecknaren, så att andra inte kan komma åt eller använda dem.Uppfyllelse av detta och övriga krav underlättas av om användarens privata signerings- nyckel, så som föreslås, endast existerar vid signeringstillfället i en för ändamålet säker hårdvara samt att signeringsnyckeln förstörs direkt efter användning. En sådan hårdvara utformasäven på ett sådant sätt att signaturnyckeln inte kan läsas ut ur hårdvaran. Vid ett sådant förfarande bygger kravuppfyllelse på att signeringssystemet på ett betryggande sätt kan legitimera användaren vid signeringstillfället och därmed på ett rimligt sätt säkerställa att ingen annan än användaren själv kan signera i användarens namn med hjälp av signeringstjänsten. För att belysamöjligheterna för en central signeringstjänst att tillgodose detta krav är det relevant att jämföramöjligheterna med en central signeringslösning i förhållande till en traditionell lokal lösning där själva signaturframställningen sker i användarens dator eller motsvarande lokal enhet (ex mobiltelefon). Båda lösningarna kräver att användaren som ska signera har tillgång till sin e-legitimation. Skillnaden ligger i att lokal signering bygger på att användarens datormiljö ger ett tillförlitligt skydd mot missbruk medan den centrala signeringstjänsten bygger på att den centrala signeringsmiljön kan ge ett skydd i minst motsvarande grad. Största hotet mot användarens lokala miljö utgörs av att skadlig kod (virus, trojaner, maskar mm) som användare installerat av oaktsamhet, eller som på annat sätt infiltrerat användarens dator kan ha potential att missbruka användarens signeringsfunktion. Detsamma gäller dock även i motsvarande grad en fientlig programvaras möjlighet att missbruka användarens e-legitimation vid legitimering mot en signeringstjänst. Dock finns många fler möjligheter att uppdaga problem av detta slag vid en central signeringstjänst, dels genom att legitimering vid signering loggas både av identitetsutfärdare som utfärdar identitetsintyget och av signeringstjänsten som legitimerar användaren samt möjlighet att bekräfta signering genom separat kanal, ex genom e-post eller SMS. Följande tabell redovisar en samanställning av olika säkerhetsaspekter och hot samt en uppskattning av vilken lösning (lokal eller central signering) som erbjuder fördelar (+) respektive sämre förutsättningar (-). Beroende av en trovärdig central Hot från virus och annan fientlig programvara i användarens dator (p.g.a. bättre spårbarhet) (raderas efter signering) Möjlighet att spåra vad som hänt genom loggar och trovärdig registrering av tidpunkt för Möjlighet att spärra enskilda Tredje parts bevittnade av användarens acceptans att signera presenterad handling Möjlighet att underrätta användaren om signering genom meddelande i separat kanal + vid alternativ 1 Tjänstedirektivet från EU kommissionen ställer krav på elektroniska tjänster som ska verka över landsgränser. Inom ramen för tjänstedirektivet kan medborgare behöva kommunicera elektroniskt signerade handlingar. Inom ramen för EU kommissionens stödjande aktiviteter för att underlätta utbyte av elektroniskt signerad information i samband med tjänstedirektivet har EU kommissionen i samverkan med medlemsstaterna utfärdat ett kommittologibeslut (Kommissionens Beslut /425/EU av om ändring av beslut /767/EG). I artikel 1 av detta beslut (som står oförändrat /767/EG) framgår följande: Om det är motiverat på grundval av en ändamålsenlig bedömning av berörda risker och i enlighet med artikel 5.1 och 5.3 i direktiv /123/EG, får medlemsstaterna kräva att tjänsteleverantören för fullgörandet av vissa förfaranden och formaliteter genom de gemensamma kontaktpunkterna i enlighet med artikel 8 i direktiv /123/EG ska använda avancerade elektroniska signaturer baserade på ett kvalificerat certifikat, med eller utan en säker anordning för skapande av signaturer, enligt vad som fastställs och regleras genom direktiv /93/EG. Genom detta beslut framgår tydligt att grunden för internationell samverkan i fråga om signerade handlingar utgörs av elektroniska signaturer baserat på kvalificerade certifikat men att kravet på en säker anordning för skapande av signaturer inte är obligatoriskt. Man kan därför förvänta sig at en lösning för elektroniska signaturer med central signeringstjänst enligt detta dokument kan fylla in viktig funktion inom ramen för införande av tjänstedirektivet även om vi i inte väljer att godkänna den centrala signeringstjänsten som en säker anordning för skapande av signaturer i enlighet med avsnitt 4. De signaturer som skapas inom ramen för dagens infratjänst kan endast verifieras av de myndigheter som är anslutna till infra- tjänsten (har förlitande avtal med e-legitimationsutfärdarna och därmed tillgång till aktuell spärrinformation). Detta gör dagens signaturlösning, eller motsvarande lösning där dokument signeras lokalt i användarens dator med e-legitimationer från dagens ramavtalsleverantörer, olämplig för utväxling av elektroniskt signerade handlingar inom ramen för internationell samverkan. EN stor fördel i detta hänseende med en central signeringstjänst kombinerat med en federativ infrastruktur för identifiering är främst om befintliga e-legitimationer signaturerna kan användas internationellt genom att signaturerna kan kopplas till ett kvalificerat certifikat samt genom att certifikatens spärrinformation är öppet tillgänglig. En viktig förutsättning för detta är att signeringstjänstens certifikatutfärdarfunktion kan godkännas och registreras hos PTS och att tjänsten tas med i lista över certifikatutfärdare. Vad gäller möjligheten att ge ut kvalificerade certifikat baserat på nycklar som genererats centralt av certifikatutfärdaren, eller att identifiera den som ansöker om ett certifikat med hjälp av medel som i sig inte utgörs av kvalificerade certifikat så finns klart stöd från både internationell standard såväl som implementationer i . Den allmänt accepterade standarden för utgivning av kvalificerade certifikat ETSI TS 101 456 [TS101456] ger tydligt utrymme för en sådan utfärdandeprocess. Följande kravlista har utgjort grunden för utformning av en signeringstjänst. Kravlistan är utarbetad inom ramen för utredningen om bildandet av en e-legitimationsnämnd och är resultatet av såväl diskussioner inom utredningen som diskussioner med representanter från myndigheter och offentlig verksamhet. Användarna ska kunna signera dokument med en standard dator och en standard webbläsare som kör under marknadens vanligt förekommande operativsystem (Windows, , Linux, , Android, iPhone, Blackberry, m.m.). E-tjänster ska kunna få tillgång till signeringstjänsten för att låta användare underteckna elektroniska dokument med minimala anpassningar av sin e-tjänst. E-tjänster måste kunna signera dokument som innehåller data enligt interna format som inte kan visas direkt i användarens webbläsare. E-tjänster måste kunna signera data som inte delges annan än användaren själv. I dessa fall får inte den signerade handlingens innehåll överföras till signeringstjänsten. Anslutna e-tjänster ska inte behöva befatta sig med skapande av elektronsikt signerade handlingar. Följande hantering ska kunna överlåts till signeringstjänsten: -Presentation av handlingen som ska signeras -Presentation av innebörden av att signera -Användarens godkännande av att signera handlingen -Utfärdande av signeringscertifikat2 -Signering av elektronisk handling -Tidstämpling av dokument och signatur -Framställa signerad handling enligt överenskommet signaturformat Signaturen ska om möjligt kunna uppfylla lagens krav på en kvalificerad elektronisk signatur. 2 Det är nödvändigt att signeringstjänsten utfärdar certifikat eftersom dessa kopplas till den signeringsnyckel som signeringstjänsten skapar för användaren. Dessa certifikat konkurrerar inte med andra certifikat på marknaden då dess enda funktion är att användas för att verifiera den specifika signatur som skapas. Eftersom signaturnyckeln förstörs efter signering kan certifikatet inte kopplas till eller användas för andra ändamål. Användningsfallen nedan är hypotetiska framtidsscenarier och utgör inte nödvändigtvis en korrekt beskrivning av de myndigheters e-tjänster som nämns.