Kuverteringsprofil XHE

Figur 1 Illustration av kuverteringsprofilens fokus. Se bilden i ett större format.

Kuverteringsprofilen använder följande tekniska specifikationer:

• Exchange Envelope Header (XHE) Version 1.0, OASIS
• XML Encryption [XMLENC] (https://www.w3.org/TR/xmlenc-core1/ Länk till annan webbplats.).
• XML Signature [XMLDIGSIG] (https://www.w3.org/TR/xmldsig-core1/ Länk till annan webbplats.)

Målgrupper

Detta dokument syftar till att stödja följande intressenter i deras arbete, dess informationsbehov samt ge svar på vanligt förekommande frågeställningar.

Intressenter:

• IT-arkitekter och utvecklare
  • Som utvärderar, analyserar, designar, bygger, och testar programvaror.

Referenser

Federationsspecifika anpassningar

Denna sida innehåller ett par regler, krav eller principer som en federation kan anpassa i federationens anpassningar mot eDelivery plattformen (federationsdeklarationen). Dessa anpassningspunkter är numrerade enligt formen [A1], [A2], [A3] osv.

Meddelandemodell enligt XHE

Ett meddelande med dess metadata och nyttolast kuverteras enligt det XML-baserade regelverket XHE utgiven av OASIS.

I det fall meddelandet signeras och krypteras i deltagarens verksamhetssystem/meddelandetjänst så måste meddelandekuvertering utföras där. I fall då signering och kryptering inte nyttjas kan meddelandekuvertering alternativt utföras i accesspunktsfunktionen.

Informationsmodell

Tabellen nedan beskriver de uppgifter som ett kuvert innehåller samt deras placering (XPATH) i syntaxen XHE. Mer detaljer kring strukturen på XHE beskrivs i kapitlet Syntaxmappning.

Syntaxmappning

Kuvertet baseras på en XHE teknisk specifikation från OASIS BDXR-kommittén. Detaljer om elementens datatyper och namnrymder framgår i standarden och dess scheman [XHE].

[a] Ett kuvert måste följa de kardinalitetsbegränsningar, instruktioner och regler som beskrivs i syntaxbindningen.

Namnrymder som används i kuvertet

Följande XML namnrymder används i kuvertet. Prefix som används i syntaxbindningen (xha,xhb,ds) visar vilken namnrymd som respektive element hör hemma i.

Tomma XML-element och attribut

Ett element/attribut anses vara tomt om det inte innehåller något textinnehåll och inte några underliggande XML-element. Element och attribut som uteslutande innehåller ”whitespace” (mellanslag, tab-tecken eller radbrytning) är också att betrakta som tomt.

Ett element/attribut anses vara tomt om det inte innehåller något textinnehåll och inte några underliggande XML-element. Element och attribut som uteslutande innehåller ”whitespace” (mellanslag, tab-tecken eller radbrytning) är också att betrakta som tomt.

[a] Tomma element och attribut ska inte anges.

Exempel på tomma element:

Exempel på tomt attribut:

Valideringsregler för syntax

Denna kuverteringsprofil använder XML-standarden XHE inklusive dess XSD-scheman.

[a] Ett kuvert som inte validerar korrekt gentemot XHE XSD-scheman är inte att betrakta som följsamt gentemot denna specifikation.

En uppsättning valideringsregler finns definierade för att kontrollera att ett kuvert är följsamt gentemot denna specifikation. Reglerna finns även representerade som schematron-regler för maskinell och automatisk validering.

[b] Ett kuvert som bryter mot någon av valideringsreglerna är inte att betrakta som följsamt gentemot denna specifikation.

Kryptering och signering av meddelande

Denna kuverteringsprofil har stöd för försändelser (nyttolast) som krypterats och signerats mellan Deltagarna. Användning av kryptering och signering mellan Deltagare kräver att båda parter är förberedda och att det finns överenskommelse (mellan parterna eller inom federationen som helhet) om att dessa utökade säkerhetsmekanismer ska användas.

Certifikatspubliceringstjänsten

Certifikat för signering och kryptering finns tillgängliga genom slagning i Certifikatspubliceringstjänsten eller genom bilaterala överenskommelser mellan avsändande och mottagande Deltagare.

Ordningsföljd avseende signering och kryptering

Då signering och kryptering används ska kryptering av nyttolasten göras först och därefter signeras meddelandekuvertet i sin helh

På motsvarande sätt ska mottagaren kontrollera meddelandekuvertets signatur först och därefter dekryptera den kuverterade nyttolasten.

Om signaturen inte validerar korrekt ska dekryptering inte utföras.

Specifika krav på utgivare av signerings- och krypteringscertifikat

Denna specifikation ställer inte några formkrav (nyckellängd, utgivare osv) på certifikaten som används.

En federationsoperatör kan i sin federationens anpassningar mot eDelivery plattformen ställa följande specifika krav avseende certifikat:

• Anpassning [A1]: Formkrav på certifikat (nyckellängd, användning av attribut osv)
• Anpassning [A2]: Certifikatsutgivare som kan användas
• Anpassning [A3]: Om det ska vara separata certifikat för signering och kryptering eller om samma certifikat ska användas i båda syftena.
  

Kryptering av nyttolast - konfidentialitet

När kryptering av meddelande används ska det göras i enlighet med W3C-standarden ”XML Encryption” [XMLENC].

Standarden beskriver både processen för att kryptera XML-element och hur krypterade data representeras i XML-format. Schemat för XML Encryption är inte inkluderat i XHE utan kan laddas ner separat.

Kryptering och dekryptering görs med den avsedda mottagarens publika respektive privata nyckel. Mottagarens publika nyckel måste vara tillgänglig för den som utför krypteringen.

Krypteringen genomförs genom att en tillfällig meddelandenyckel skapas och används för att kryptera meddelandet. Denna meddelandenyckel krypteras sedan med mottagarens publika nyckel. Det innebär att det finns två block av krypterat data i XML-strukturen, den krypterade meddelandenyckeln och det krypterade meddelandet. När mottagaren ska läsa meddelandet används mottagarens privata nyckel för att dekryptera meddelandenyckeln som i sin tur används för att dekryptera det krypterade meddelandet.

I klartextform placeras nyttolasten i XHE-elementet PayloadContent. Detta element är av typen xsd:any vilket innebär att det inte är bundet till ett specifikt typ av XML-meddelandeformat. När nyttolasten i klartext krypteras enligt XML Encryption så blir resultatet en ny XML-struktur som innehåller information om nycklar, krypteringsalgoritmer mm. Denna XML-struktur, som har rotelement EncryptedData, ersätter klartextnyttolasten i PayloadContent.

Sårbarhet i XML Encryption vid användning av blockchiffer utan integritetsskydd

En sårbarhet är identifierad då icke integritetsskyddade blockchiffer-algoritmer används tillsammans med XML Encryption. Sårbarheten kan utnyttjas genom en så kallad ”oracle attack” där en anropande applikation upprepande gånger och på ett systematiskt sätt skickar ett krypterat meddelande för dekryptering där det krypterade meddelandet modifieras med mycket små förändringar varje gång. Genom att utvärdera svarsmeddelanden som returneras från den dekrypterande applikationen kan anropande applikation till slut dra slutsatser om utseendet av den klartext som krypterades. Det finns ett antal motåtgärder för denna typ av sårbarhet varav några används i denna specifikation.

1. Innan dekryptering görs så kontrolleras meddelandets signatur. Om signaturvalidering misslyckas så förkastas meddelandet och inget försök att utföra dekryptering på meddelandet görs.
2. Då meddelandet inte dekrypteras vid felaktig signatur så returneras heller ingen felkod som informerar om resultat av dekryptering som kan användas vid en ”oracle attack”.

Problemet med blockchiffer-algoritmer och XML Encryption kan lösas genom att använda krypto med integritetsskydd, så som AES GCM, som introducerades i XML Encryption version 1.1. När AES GCM används utökas krypteringsskyddet med ett integritetsskydd som kontrollerar att krypterade data inte förändrats innan dessa dekrypteras. På så sätt uppnås samma skydd vid kryptering som uppnås genom att som ovan signera krypterade data och att kontrollera denna signatur innan dekryptering.

Då Microsofts ”.Net Framework” inte har stöd för att hantera XML Encryption 1.1-standarden gör DIGG idag bedömningen att AES GCM introducerar stor komplexitet för implementationer som baseras på Microsofts ramverk. Vidare bedömer DIGG att de motåtgärder som finns inbyggda i eDelivery plattformen gör att blockchiffer-algoritmer kan användas i detta sammanhang.

Struktur för XML Encryption – EncryptedData

För information om XML namnrymder, se [XMLENC].

Parametersättning XHE

Elementet Payload innehåller vissa metadata om det meddelande som skickas.

[a] När kryptering används ska det indikeras genom att elementet InstanceEncryptionIndicator sätt till ”true”

Exempel:

Parametersättning av XML Encryption

Typ av krypterat innehåll

[a] När nyttolasten som krypteras är XML-baseras ska innehållstypen anges till ”Element”.

Exempel:

[b] När nyttolasten som krypteras inte är XML-baserad ska innehållstypen anges till ”Content”.

Exempel

Kryptering av sessionsnyckel

Sessionsnyckeln krypteras med hjälp av mottagarens publika nyckel.

Algoritmen ”rsa-oaep-mgf1p” ska användas för kryptering av den tillfälliga symmetriska sessionsnyckeln.

Exempel:

Kryptering av meddelandet

Meddelandet krypteras med hjälp av sessionsnyckeln.

[a] Algoritmen ”AES256” ska användas för kryptering av meddelandet.

Exempel:

Inkludering av X509 Certifikat

Syftet med att inkludera certifikatet är att förenkla hantering vid certifikatsbyten samt hantering av arkiverade meddelanden.

[a] Den publika delen av det certifikat som använts vid kryptering ska inkluderas i PEM-format (BASE64-kodat).

Exempel:

Signering av kuvert – undertecknande

När signering av meddelande används ska det göras i enlighet med W3C-standarden ”XML Signature” [XMLDIGSIG].

Standarden beskriver både processen för att skapa elektronisk signatur och hur den representeras i XML-format.

W3C har även publicerat ”Best Practices” [SIGPRC] som ger goda råd för behandlingen av digitala signaturer.

I XML Signature beskrivs flera olika sätt knyta signaturen till den nyttolast som signeras. Denna kuverteringsprofil nyttjar metoden ”Enveloped Signature” vilket innebär att signaturen läggs in som en del i XML-strukturen.

Vid validering måste hela XML-strukturen överensstämma med den XML som signerades. För att försäkra sig om att XML-strukturen återges på samma sätt både vid signering och vid validering används en kanoniseringstransformering och vid validering exkluderas signaturen från XML-strukturen.

[a] Mottagaren ska kontrollera signeringscertifikatets giltighet och att det inte är spärrat.

[b] Om Certifikatspubliceringstjänsten används så ska signeringscertifikatet också jämföras med det certifikat som publicerats för ändamålet.

Jämförelsen görs för att försäkra sig om att signeringscertifikatet som använts är det som är registrerat för Deltagaren i Certifikatspubliceringstjänsten.

Struktur för XML Digital signature

Parametersättning av XML Digital Signature

Följande parametrar ska användas vid användning av [XMLDIGSIG]

Kanoniseringsalgoritm

[a] Kanoniseringsmetod ska nyttja någon av de algoritmer som anges som obligatoriska att stödja i [XMLDIGSIG]

Exempel:

Signeringsalgoritm

[a] Signeringsalgoritm ska vara ”RSAwithSHA256”.

Exempel:

Transformeringsmetod

[a] Signaturen ska inkluderas i kuvertets XML-struktur genom att följa ”Enveloped”-metoden.

Exempel:

Hashningsmetod

[a] Hashvärdet ska beräknas utifrån XML-strukturen enligt algoritmen ”SHA256”.

Exempel:

Inkludering av X509 Certifikat

[a] Den publika delen av det certifikat som använts vid signering ska inkluderas i PEM-format (BASE64-kodat).

Exempel: