sou · GYB3104 · 2010-12-23 00:00:00 — Dess syfte är uteslutande att beskriva situationer som belyser olika tillämpningar av en central signeringstjänst. 6.1Signering av handling från e-tjänst som presenteras av signeringstjänsten besöker webbplats för att deklarera. För att komma åt deklarationstjänsten loggar in på skatteverkets webbplats med sin e-legitimation. När alla uppgifter matats in vill godkänna sin deklaration. webbplats skapar då ett elektroniskt dokument som innehåller deklaration med alla lämnade uppgifter införda varefter dirigeras om till signeringstjänsten. I signeringstjänsten får information av att vill att ska skriva under sin deklaration elektroniskt. Deklarationen som sammanställts av visas upp för som kan gå igenom uppgifterna med sin webbläsare. väljer funktionen Jag skriver under hos signerings- tjänsten varvid dirigeras till sin Identitetsutfärdare för legitimering för underskrift. godkänner underskriften genom att legitimera sig med sin e-legitimation. Dokumentet signeras av signeringstjänsten och förses med en kvalificerad elektronisk signatur enligt det signaturformat som e- tjänsten begärt. returneras tillbaks till skatteverkets webbtjänst (via signeringstjänsten) som meddelar att deklarationen nu är under- skriven. 6.2Signering av handling från e-tjänst som presenteras av e-tjänsten besöker webbplats och loggar in för att ansöka om föräldrapenning. webbplats presenterar information som ska undertecknas varvid accepterar att skriva under elektroniskt med sin e-legitimation genom funktionen Jag skriver under. dirigeras till sin Identitetsutfärdare som begär legitimering för underskrift. godkänner underskrift genom att legitimera sig med sin e-legitimation. returneras till med en signatur som framställts av signeringstjänsten. meddelar att ansökan har signerats. 6.3Signering av handling vald av användaren ska signera en ansökan om tillstånd att få leverera tjänster i . har fyllt i ett formulär som sparats i PDF format. kontaktat signeringstjänsten och presenterar det doku- ment som ska signeras samt väljer att dokumentet ska tidsstämplas. Signeringstjänsten presenterar via webbgränssnitt det dokument som kommer att signeras. verifierar dokumentet och väljer funktionen Jag skriver under varvid dirigeras till sin Identitetsutfärdare för legitimering för underskrift. godkänner underskriften genom att legitimera sig med sin e- legitimation. returneras till signeringstjänsten där får ladda hem det signerade dokumentet som försetts med en kvalificerad elektronisk signatur samt en kryptografisk tidsstämpel. För att uppfylla alla funktionella krav måste signeringstjänsten ha utförandealternativ som både kan hantera fall där presentation av information som ska signeras hanteras av signeringstjänsten och fall där detta hanteras av e-tjänsten. I detta avseende innefattar hanteringen av information som ska signeras: Presentation av information som ska signeras Presentation av innebörden av att signera (detta kan framgå av informationen som signeras eller genom annan information) Funktion genom vilken användaren kan acceptera För att uppfylla dessa krav presenteras två olika utförandealternativ som presenteras i detta avsnitt. Utförandealternativen representerar främst skillnader mellan användningsfallen i avsnitt 6.1 och 6.2. Användningsfallet i avsnitt 6.3, där handlingen som signeras väljs av användaren, går att realisera inom ramen för båda alternativen genom att skapa en tjänst där användaren kan ladda upp ett dokument som ska signeras. Denna tjänst kan fylla funktionen av en e-tjänst i enlighet med både alternativ 1 och alternativ 2. 6.4Alternativ 1 – Dokument som ska signeras hanteras av signeringstjänsten I detta alternativa utförande överlåter e-tjänsten hela signe- ringsförfarandet till signeringstjänsten. Identitetsutfärdare (IdP) 4.Användaren identifierar sig för en e-tjänst genom sin e-legiti- mation och utnyttjar en tjänst som kräver användarens elek- troniska underskrift (signatur) 5.Användaren överförs till signeringstjänsten med en begäran om signering från e-tjänsten. 6.Signeringstjänsten inhämtar elektronisk handling för under- skrift från e-tjänsten. 7.Signeringstjänsten presenterar handlingen som ska signeras för användaren och användaren accepterar att signera 8.Användaren överförs till sin identitetsutfärdare med begäran om legitimering. Användaren legitimeras med stöd av sin e- legitimation och ett identitetsintyg returneras till signerings- tjänsten. 9.Signeringstjänsten skapar användarens nyckelpar, utfärdar ett certifikat för användaren samt signerar den elektroniska handlingen. Vid behov tidsstämplas handlingen. Handling med underskrift skapas genom att foga samman handlingen med certifikat, signatur och eventuell tidsstämpel enligt efterfrågat signaturformat. 10.Användaren returneras till e-tjänsten med en bekräftelse på att handlingen är underskriven. 11.E-tjänsten hämtar hem den signerade handlingen från signe- ringstjänsten från angiven plats. Genom detta förfarande kan en e-tjänst få tillgång till en signering- sfunktion som enkelt kan integreras med en e-tjänst med minimala insatser. En viktig fördel är att en tredje part (Signeringstjänsten) står som garant för att användaren verkligen accepterat att signera handlingen och att den information som användaren fått presente- rat för sig och accepterat överensstämmer med den signatur som skapats. En annan fördel är att signeringstjänsten kan hantera alla de olika signaturformat som kan komma i fråga, särskilt om signaturen ska kunna användas/verifieras internationellt. Den stora nackdelen med detta alternativ är att den handling som ska signeras måste hanteras av signeringstjänsten. Detta alternativ kan därför inte tillämpas om: E-tjänsten av något skäl inte kan eller får lämna ut handlingen som ska signeras till signeringstjänsten Handlingen som ska signerats inte förekommer i ett format som signeringstjänsten kan presentera för användaren på ett för användaren meningsfullt sätt endast med stöd av användarens webbläsare. Då någon av dessa omständigheter gäller för signeringen så måste alternativ 2 tillämpas. 6.5Alternativ 2 – Dokumentet som ska signeras hanteras av e-tjänsten I detta alternativa utförande av signeringstjänsten hanterar signeringstjänsten inte den elektronisk handling som ska signeras. Gränssnittet mot användaren vid signering hanteras i sin helhet av signeringstjänsten Identitetsutfärdare (IdP) 1.Användaren identifierar sig för en e-tjänst genom sin e- legitimation och utnyttjar en tjänst som kräver användarens elektroniska underskrift (signatur). E-tjänsten presenterar den elektroniska handling som ska signeras för användaren och användaren accepterar att skriva under handlingen. 2.Användaren överförs till signeringstjänsten med en begäran om signering från e-tjänsten. Begäran om signering innehåller bl.a. en hash representation av dokumentet som ska signeras. 3.Användaren överförs till sin identitetsutfärdare med begäran om legitimering. Användaren legitimeras med stöd av sin e- legitimation och ett identitetsintyg returneras till signerings- tjänsten. 4.Signeringstjänsten skapar användarens nyckelpar, utfärdar ett certifikat för användaren samt signerar den elektroniska handlingen. Vid behov skapas en tidsstämpel. 5.Användaren returneras till e-tjänsten med en bekräftelse på att handlingen är underskriven. Bekräftelsen innefattar bl.a. signatur, certifikat och eventuell tidsstämpel. 6.Handling med underskrift skapas av e-tjänsten genom att foga samman handlingen med certifikat, signatur och eventuell tidsstämpel enligt efterfrågat signaturformat. Genom detta förfarande kan e-tjänsten få en handling signerad utan att lämna ut uppgifter om den elektroniska handlingen till signeringstjänsten. Detta gör det även möjligt för e-tjänsten att signera handlingar som innehållsmässigt är strukturerade enligt att dataformat som inte signeringstjänsten kan presentera på ett för användaren meningsfullt sätt. 6.6Fördelning av roller och uppgifter Sammantaget innebär alternativ 1 och 2 följande skillnader i roller och vem som i praktiken utför väsentliga steg i signerings- processen. Tjänst som hanterar förfarandet Presentation av dokument som ska signeras Skapande av en hash representation av Motta användarens acceptans att signera Generera nycklar för användaren samt utfärda certifikat till användaren (Endast om detta begärs av e-tjänsten) (Foga samman dokument, certifikat ev. tidsstämpel samt signatur till ett signerat dokument enligt vedertagen standard) 7 Krav på E-tjänster De e-tjänster som utnyttjar signeringstjänsten enligt alternativ 2 kommer att bära ett viktigt ansvar för att signaturen är tillförlitlig. Om e-tjänsten är oärlig kan denne skicka med ett hash till signeringstjänsten som inte motsvarar det som e-tjänsten visat upp för användaren. Varken signaturtjänsten eller användaren har någon möjlighet att kontrollera att hash värdet som signeras överens- stämmer med den information som användaren väljer att signera innan signering sker. Detta kan i viss mån motverkas om användarens får tillgång till den signerade handlingen efter signering för kontroll men detta förutsätter att den signerade handlingen har ett format som användaren lätt kan tillgodogöra sig. Denna problemställning är dock inte ny för central signering. Även vid lokal signering är det svårt att uppnå en hög tillförlitlighet av att användaren faktiskt ser det som signeras då användaren måste förlita sig på den information som kan utläsas från lokal programvara för presentation av information och för signering. Även i många av dagens lösningar är användaren i slutändan tvungen att lita på att e-tjänsten inte beter sig bedrägligt. Det bör klargöras, mot bakgrund av denna hotbild, vilka typer av e-tjänster som kan tillåtas utnyttja signeringstjänsten enligt alternativ 2, exempelvis om detta bör begränsas till statliga myndigheter. 8Krav på signeringstjänstens organisation och driftsmiljö Det är avgörande för förtroendet för utfärdade signaturer att signeringstjänsten hanteras under en organisation som har samhällets förtroende. Driftsmiljö och säkerhetsrutiner måste på ett tillförlitligt sätt garantera systemets integritet och förhindra att enskilda administratörer kan missbruka systemet för egna syften. Signeringstjänsten realiseras i grunden som en webbtjänst. Signeringstjänsten kommunicerar med användaren via HTTP samt kommunicerar vid behov med e-tjänsten via lämpligt gränssnitt. 9 Alternativ till central signering Om en framtida utvärdering central signering kommer till slut- satsen att ingen form av central signering är acceptabelt, så finns andra alternativ till signering i samverkan med en federativ infra- struktur för identifiering i enlighet med utredningens förslag. Som exempel kan följande lösning etableras: Identitetsutfärdare (IdP) 1.Användaren identifierar sig för en e-tjänst genom sin e- legitimation och utnyttjar en tjänst som kräver användarens elektroniska underskrift (signatur). 2.Användaren överförs till signeringstjänsten med en begäran om signering från e-tjänsten. 3.Signeringstjänsten överför den information som ska signeras till användaren som signerar informationen med stöd av sin e- legitimation och sin klientapplikation för signering som användaren erhållit från utfärdaren av användarens e- legitimation. 4.Signeringstjänsten verifierar att rätt användare signerat handlingen genom en kontroll mot identitetsutfärdaren (Förslagsvis genom att tillämpa standarden [SAMLX509]. 5.Signeringstjänsten överför användaren tillbaks till e-tjänsten samt överför nödvändigsigneringsinformation. Genom detta förfarande kan en e-tjänst befrias helt från såväl integration med användarens funktioner för signering, som tolkning av användarens e-legitimation för att fastställa användarens identitet. Signeringstjänsten sköter all integration med olika signeringslösningar i användarnas klienter och information om identitet ges i enlighet med federationens gemensamma attributsprofil i det attributsintyg som erhålls i samband med kontroll av signaturcertifikat (steg 4 enligt [SAMLX509]. Dock är en lösning av detta slag behäftat med i stort sett samma tidigare nämnda svagheter jämfört med dagens lösning på så sätt attanvändarens e-legitimation fortsatt måste vara certifikatbaserad samt att dessa signaturer inte kan verifieras av förlitande part i utlandet som inte har tillgång till aktuell spärrinformation eller den svenska infrastrukturen för identifiering. Av detta skäl förs inte denna typ av lösning fram som ett primärt förslag. I de utförande exempel som anges i detta avsnitt sker även kommunikation mellan signeringstjänst och e-tjänst via HTTP. Följande funktioner ingår i signeringstjänsten utöver webbgräns- snittet mot användare och kommunikation med e-tjänster Beskrivningarna i detta avsnitt utgör exempel på utförande som uppfyller ställda krav. De utgör ett grundförslag på utförande och specificerar inte en komplett design för implementering. Olika aspekter av arkitekturen kan komma att ändras vid ett slutgiltigt genomförandeprojekt. Grunden för kommunikation mellan e-tjänst och signeringstjänst samt mellan signeringstjänst och identitetsutfärdare är att kommunicera information via användaren så samma sätt som sker vid SAML authentication request och respons. Utgångspunkten är att denna kommunikation sker i enlighet med binding [SAML-Bindings]. Vid binding kommuniceras ett svar till användaren när denne gör ett aktivt val i sin webbläsare (ex. väljer att skriva under). Användarens val resulterar i en HTTP request från användaren till webbtjänsten. Detta resulterar i en HTTP response som innehåller en XHTML form som innehåller informationen som ska vidarebefordras till nästa webbtjänst (ex en signing request till signeringstjänsten eller en authentication request till identitetsutfärdaren. När XHTML formen öppnas i användarens webbläsare så innehåller denna en instruktion att skicka information till mottagande webbtjänst som . [SAML-Bindings] specificerar genom binding hur request och response meddelanden kan förmedlas via användaren på detta sätt. det enda som krävs för en komplett specifikation av den informationsutväxling mellan e-tjänsten och signeringstjänsten som går via användaren är att specificera ett signing request och ett signing response meddelande som kan förmedlas i XHTML form via . 10.2Informationsflöden - utförande enligt alternativ 1 Informationsutväxling mellan parterna i utförande enligt alternativ ett kan ske på följande sätt: 1.Användare nyttjar e-tjänst som kräver signatur 2.Signing Request returnerat i XHTML form riktat till Signaturtjänsten. Vidarebefordras till Signaturtjänst som HTTP POST 3.Signaturtjänsten hämtar dokument som skall signeras (URL) 4.Signaturtjänsten presenterar dokument som skall 5.SAML Authentication Request i XHTML fom riktat till IdP. Vidarebefordras till IdP som HTTP POST 6.Användaren autentiseras av IdP med användarens e-legitimation 7.SAML Assertion returnerat i XHTML form, riktat till Signaturtjänsten. Vidarebefordras till Signaturtjänsten som HTTP POST. 8.Signing Response returnerat i XHTML form, riktat till e-tjänsten. Vidarebefordras till e-tjänsten som HTTP POST. 9. e-tjänsten hämtar signerat dokument (URL) 10. e-tjänsten bekräftar signering I detta utförande sker signering i signeringstjänsten efter det att användaren autentiserats och ett giltigt identitetsintyg (authentication response) mottagits av signeringstjänsten i steg 7. Det dokument som signeras skickas inte via användaren för att undvika fördröjningar om dokumentet är stort och användaren har begränsad kommunikationshastighet. Dokument som ska signeras och signerat dokument hämtas av parterna via en URL i setgen 3 och 9. URL till dokumenten medföljer signing request respektive signing reponse i stegen 2 och 8. 10.3Informationsutväxling – utförande enligt alternativ 2 Informationsutväxling mellan parterna i utförande enligt alternativ två kan ske på följande sätt: 1.Användare nyttjar e-tjänst som kräver signatur 2.Användaren accepterar att skriva under ett dokument 3.Signing Request returnerat i XHTML form riktat till Signaturtjänsten. Vidarebefordras till Signaturtjänst som HTTP POST 4.SAML Authentication Request i XHTML fom riktat till IdP. Vidarebefordras till IdP som HTTP POST 5.Användaren autentiseras av IdP med användarens e-legitimation 6.SAML Assertion returnerat i XHTML form, riktat till Signaturtjänsten. Vidarebefordras till Signaturtjänsten som HTTP POST. 7.Signing Response returnerat i XHTML form, riktat till e-tjänsten. Vidarebefordras till e-tjänsten som HTTP POST. I detta utförande sker signering i signeringstjänsten efter det att användaren autentiserats och ett giltigt identitetsintyg (authentication response) mottagits av signeringstjänsten i steg 6. Det dokument som ska signeras överförs inte till signeringstjänsten. Istället överför e-tjänsten en hash av dokument som ska signeras i steg 3 till signeringstjänsten. Med hjälp av denna hash kan signeringstjänsten signera dokumentet utan att få tillgång till dokumentet i klartext (i läsbart skick). På motsvarande vis skickas inte heller ett signerat dokument till e-tjänsten. Istället skickas signaturen på dokumentet till e-tjänsten tillsammans med användarens certifikat i steg 7. Utifrån denna information kan e-tjänsten själv skapa det signerade dokumentet enligt ett för ändamålet lämpligt signaturformat. 10.3.1Authentication request och response Begäran och erhållande av identitetsintyg för användaren (stegen 5 och 7 i alternativ 1 och stegen 4 och 6 i alternativ 2) genomförs som är en ren SAML identifiering in enlighet med HTTP POST Binging, definierat i [SAML-Bindings]. Detta förfarande ska följa tekniska specifikationer för identitetsfederationen för svensk e-legitimering. i relation till Identitetsutfärdaren så agerar signeringstjänsten som en förlitande e-tjänst (service provider) gentemot identitets- utfärdaren. 10.4Signing request och response Signing Request och Signing Response (steg 2 och 8 i alternativ 1 och steg 3 och 7 i alternativ 2) ska innehålla all information som signeringstjänsten och e-tjänsten behöver utbyta för att genom föra signering och hantera felsituationer med undantag för utväxling av dokument i alternativ 1. Utgångspunkten är att följande information bör ingå: Version (protokollversion) Request type (identifierar typ av request. Olika request type identifierare måste definieras för utförande enligt alternativ 1 och alternativ 2) Nonce (en unik identifierare för denna request) Identitetsattribut för användaren (Attribute assertion) (ej psudonym). Detta utgör de identitetsattribut som signerings- tjänsten måste kunna kontrolleras genom det identitetsintyg som signeringstjänsten erhåller från identitetsutfärdaren. Dessa attribut måste vara en delmängd av de attribut som signeringstjänsten registrerat som antingen required eller requested attributes i federationens metadata (federations- registret) Entity ID för den IdP som ska autentisera användaren vid signering En referens till det dokument som ska signeras i URL format (Endast alternativ 1) Referens till presentationsformat (stylesheeet) (URL format) (endast vid alternativ 1 och endast vid behov) Krypteringsnyckel/nycklar för att dekryptera information som hämtas direkt från e-tjänsten En hash av det dokument som ska signeras Identifierare av önskat signaturformat ([CMS]?, [XML Dsig], [PDF], [CAdES], [XAdES], [PAdES] etc) (Endast alternativ 1) mm (Listan ska vara öppen för framtida utvidgning) Version (protokollversion) Response type (typ av response) Nonce (samma som request nonce) Statuskod (ex Signatur skapad, Signatur ej skapad med felkod) Referens till signerat dokument (URL) (endast alternativ 1) Krypteringsnyckel/nycklar för att dekryptera signerat dokument som hämtas direkt från signeringstjänsten (endast alternativ 1) Signatur på dokument som signerats (endast alternativ 2 10.4.1Övrig kommunikation i flödesmodellerna Informationsutväxling direkt mellan användare och e-tjänst samt mellan användare och identitetsutfärdare specificeras inte. Denna informationsutväxling utformas i sin helhet av e-tjänsten respektive identitetsutfärdaren. Hämtning av dokument i stegen 3 och 9 sker med en HTTP GET metod enligt [HTTP] protokollet. 10.5Tidsstämpling i alternativ 2 I alternativ 1 ombesörjer signeringstjänsten eventuell tidsstämpling av signerat dokument och bifogar tidsstämpeln i den signerade handlingen. I alternativ 2 är detta inte möjligt eftersom signeringstjänsten inte har tillgång till det signerade dokumentet. Om en e-tjänst behöver tidsstämpla den signerade handlingen och inkludera detta i den signerade handlingen måste e-tjänsten göra en separat begäran om tidsstämpling efter mottagande av signing response. Detta kan ske utan att röja dokumentet för signeringstjänsten dels genom att följa tillämpliga standarder för signaturformat [CAdES], [XAdES] eller [PAdES] med avseende på vilken data som ska tidsstämplas och hur tidsstämpeln ska inkluderas i den signerade handlingen, samt dels genom att följa tidsstämplings- standarden RFC 3161 [RFC3161] för att skicka en begäran om tidsstämpling och ta emot tidsstämpel. Följande krav kommunikations och meddelandesäkerhet bör gälla: Kommunikation mellan signeringsserver och användare krypteras med SSL/TLS [TLS] med stöd av servercertifikat (ingen klientautentisering). Kommunikation mellan användare och e-tjänst skyddas företrädelsevis med SSL/TLS med stöd av servercertifikat (ingen klientautenticering). Kommunikation med IdP samt Authentication request och response meddelanden skyddas i enlighet med identitets- e-legitimation. Signature request och response ska krypteras till respektive mottagare och signeras av respektive avsändare. Dokument som ska signeras och signerat dokument krypteras med nyckel som medföljer signing request repsektive signing response. Publika nycklar för verifiering av signaturer hämtas från federationsregistret (metadata där signaturtjänsten såväl som e-tjänsten är registrerade som e- tjänsteleverantörer). Signeringstjänsten behöver bland annat logga följande information för varje signering Signing request och signing response meddelanden hash av dokument som signerats Användarens identitetsintyg från acceptans av signering Dokumentet som signerats och det signerade dokumentet bör inte loggas. Loggar ska förses med tidsinformation som är tillförlitlig och spårbar till svensk tid (UTC(SP)). Signeringstjänsten ska signera elektroniska dokument och i utförande enligt alternativ 1 även skapa ett signerat dokument. Signeringstjänsten ska kunna skapa en kvalificerad elektronisk signatur enlig svensk lag om kvalificerade signaturer [Sig]. Signeringsprocessen följer ett antal väl definierade steg. 1.En hash av det dokument som ska signeras skapas med en godkänd hash algoritm 2.Dokumentets hash signeras med användarens privata signerings- nyckel 3.Ett signerat dokument skapas genom att foga samman dokumentet med signaturen och användarens signerings- certifikat. Då signering sker enligt utförande alternativ 2 utför signerings- tjänsten endast steg 2, medan steg 1 och 3 utförs av e-tjänsten som begär signering. Innan steg 2 kan utföras måste användarens signeringsnyckel vara genererad och användarens tillhörande signeringscertifikat måste vara utfärdat. Certifikaten som påförs den signerade handlingen i steg 3 innefattar förutom användarens certifikat även certifikat för de certifikatutfärdare som krävs för att verifiera användarens certifikat. Om det signerade dokumentet ska tidsstämplas utförs dessutom följande steg 4.En hash av den information som ska tidsstämplas skapas med en godkänd hash algorithm (normalt en hash av själva signaturen som skapades i steg 3) 6.Tidsstämpeln infogas i det signerade dokumentet