Digitaliseringsstyrelsen

Transkript

1 NemLog-in INTERNAL USE

2 Indholdsfortegnelse 1 NEMLOG-IN-LØSNINGER GØRES SIKRERE TJENESTEUDBYDERE SKAL FORBEREDE DERES LØSNINGER HVIS LØSNINGEN IKKE FORBEREDES VEJLEDNING VEDR. SIGNERINGSTJENESTEN KOM GODT I GANG... FEJL! BOGMÆRKE ER IKKE DEFINERET. 3 SIGNERINGSTJENESTEN... FEJL! BOGMÆRKE ER IKKE DEFINERET. 3.1 REQUEST DigestAlgorithm SignedFingerPrint Lokaliser Digest Algorithm REQUEST REGLER RESPONSE Page 2 of 8

3 1 NemLog-in-løsninger gøres sikrere NemLog-in og alle tilknyttede komponenter kommer fremover til at benytte en ny og mere sikker krypteringsalgoritme end den hidtil anvendte. I juni 2018 overgår NemLog-in til udelukkende at benytte signering vha. SHA-256-kryptering, og dermed udfases brugen af SHA-1. Den nye kryptering er væsentligt sværere at bryde og dermed sikrere at benytte. 1.1 Tjenesteudbydere skal forberede deres løsninger I forbindelse med overgangen fra SHA-1 til SHA-256, skal integrationer mellem NemLog-in og de tilknyttede systemer opgraderes, og det nye setup skal testes. Skiftet kræver handling fra alle tjenesteudbydere, alt efter hvilke komponenter, der benyttes. Der findes en vejledning for hver af de fire komponenter; WebSSO (login) Signeringstjenesten AttributeQuery Secure Token Service (STS). Vejledningerne kan findes her Nærværende dokument drejer sig udelukkende om selve Signeringstjenesten. 1.2 Hvis løsningen ikke forberedes Efter produktionsdatoen vil NemLog-in afvise at tage imod kald, der ikke er signeret med SHA-256. Såfremt en specifik signeringsløsning ikke skiftes til SHA-256-opsætning, vil det betyde at løsningen ikke vil være tilgængelig for slutbrugerne. Disse vil i stedet opleve at der sker en teknisk fejl. Der vil ikke være nogen mulighed for at få det til at virke med SHA-1. Det er derfor vigtigt at alle løsninger klargøres til SHA-256-overgangen Page 3 of 8

4 2 Vejledning vedr. Signeringstjenesten 2.1 Kom godt i gang Kald mod Signeringstjenesten understøtter i dag både SHA-1 og SHA-256, men da SHA-1- understøttelsen fjernes ifm. sikkerhedsopgraderingen, er det nødvendigt at opdatere parameteropsætningen. Dette kan gøres med det samme. 2.2 Sådan skiftes til SHA-256-opsætning I kald mod Signeringstjenesten defineres en række parametre, hvoraf nogle er obligatoriske, mens andre er frivillige (mandatory og optional). Det er nødvendigt at sikre følgende opsætning direkte i kildekoden: Parameteren DigestAlgorithm sættes til SHA-256 Parameteren SignedFingerPrint sættes til signering vha. SHA-256 Parameteren DigestAlgorithm bruges til at angive hvilken SHA-kryptering, der skal benyttes. Parameteren er ikke påkrævet og kan dermed udelades. I dette tilfælde sættes den pr. default til SHA-1, som ikke understøttes fremadrettet. Tjenesteudbydere, der benytter Signeringstjenesten som del af deres løsning, skal dermed eksplicit sørge for at parameteren DigestAlgorithm sættes til SHA-256 i kald mod Signeringstjenesten. Ligeledes skal den påkrævede parameter SignedFingerPrint sættes til kryptering vha. SHA For yderligere tekniske detaljer, se afsnit Sådan testes SHA-256-opsætningen Signeringstjenesten understøtter allerede brugen af SHA-256 (og SHA-1) og er dermed klar til test med det samme. Det skal altså blot sikres at it-systemet ikke benytter sig af SHA-1 længere. I testmiljøet vil SHA-1-understøttelsen ophøre maj 2018, mens det samme sker for Signeringstjenesten i produktionsmiljøet 13. juni Page 4 of 8

5 3 Teknisk opgradering 3.1 Request Når der sendes et request imod Signeringstjenesten, definerer man en række parametre, som er henholdsvis optional og mandatory. Tabellen i Request regler nedenfor viser forretningsreglerne for kommunikation med Signeringstjenesten. Hvad angår SHA opgraderingen for Signeringstjenesten, skal man være særligt opmærksom på parameteren Digest Algorithm. Digest Algorithm er hvor man definerer, hvordan request er signeret og har tidligere supporteret SHA-1 og SHA-256. Løsningen vil dog fremadrettet kun supportere SHA DigestAlgorithm Når der sendes et request mod Signeringstjenesten, er der i den nuværende løsning altså mulighed for at definere paramteren DigestAlgorithm med både SHA-1 og SHA-256. Hvis den nuværende integration indeholder SHA-1, er der behov for, at du som service provider får dette håndteret i integrationen. Da denne parameter er optional, er det ikke sikkert at dit request indeholder parameteren. Det man skal være opmærksom på er, at hvis ikke denne paramter er sat vil default i ens request være SHA SignedFingerPrint En anden paramter man skal være særligt opmærk på er SignedFingerPrint som fremadrettet skal signeres med SHA-256. Dette er en ændring, som service provider skal foretage for at tilsikre at Signeringstjenestenn kan validere requested Lokaliser Digest Algorithm Hvis du er i tvivl om, hvad din nuværende løsning benytter i sit request, er der en række redskaber man med fordel kan benytte sig af. Kildekode I kildekoden hvor requested bliver genereret, er det rigtige sted at starte med at finde ud af, hvad parameteren er sat som. Det er i sidste ende her det skal rettes. Browser Hvis du som leverandør ikke har mulighed for at tilgå kildekoden, vil det være muligt i browseren at se de værdier, der bliver postet. Nedenfor ses et typisk request mod signing service når man rammer signer.aspx : Foretag signering via det it-system, der skal testes Page 5 of 8

6 Inspicer kildekoden vha. af et indbygget inspektionsværktøj i browseren tryk F12 (f.eks. Google Chrome eller Mozilla Firefox) Find netværksoplysninger i inspektionsværktøjet Se efter signer.aspx og tjek at DigestAlgorithm er SHA-256, se billede Bemærk: Hvis DigestAlgorithm mod forventning ikke optræder, kører du som default SHA Request regler Tabellen nedenfor beskriver de parametre og den adfærd der er reglerne som de er i dag. Hvad der er værd at bemærke er at DigestAlgorithm fremadrettet kun understøtter SHA- 256 og som default er SHA-256 Field name Virk.dk compatible Description Mandatory Processing SignText Yes This is the actual agreement text that the end user needs to sign. The text may be plain text or applet html. yes SignText = Base64Encode( Utf8Encode( [agreement text])))) Page 6 of 8

7 Field name Virk.dk compatible Description Mandatory Processing SignTextFormat New This field indicates the mime type of the SignText. Possible values are TEXT or HTML. Note that the DanId applet also supports XML and NetId. These are not supported by the Signeringstjenesten. no If the SignTextFormat field is missing the value defaults to TEXT. HTML is only allowed if CertificateType is set to OCES2. EntityId Yes Each service provider has a unique EntityId which is used to identify the service provider in the federation RequestId Yes Unique identifier (just a text, not necessarily a guid) that the service provider uses to match the response from the Signeringstjenesten with the request. TargetUrl Yes The URL that the Signeringstjenesten should use when sending the response to the service provider. Note that the Signeringstjenesten should always use https when sending the response to the service provider, even if http was specified in the TargetUrl field. yes yes yes Replace(TargetUrl, http, https ) SignedFingerPrint No A signed digest of the fields SignText, EntityId and TargetUrl. The digest must be signed using the service provider s public key. yes SignedFingerPrint = Base64Encode( SignSHA- 256WithRsa( Utf8Encode( Concat( SignText, EntityId, TargetUrl))) Page 7 of 8

8 Field name Virk.dk compatible Description Mandatory Processing SerialNumber Yes Optional field indicating the serial number on the certificate that the user needs to use for signing the agreement no SerialNumber = Base64Encode( Base10String( [certificate s serial number])) Headline Language DigestAlgorithm New Optional text describing the context of the signing process that will be displayed in the signing web page header New Optional parameter indicating the language that the signing page should be displayed in. Possible values are EN (English) and DA (Danish). New Optional parameter indicating the hash algorithm that was used when creating the SignedFingerprint. Allowed values are: SHA-256. no Base64Encode( [headline text]) no If the Language field is missing, the language defaults to DA. no UPDATED: The solution only supports SHA-256. Default SHA Response For responses vil den for alle tre scenarier fremadrettet ligeledes være signeret med SHA Page 8 of 8