Filmer som beskriver referensarkitekturerna återfinns här: Referensarkitekturer för IAM och e-underskrift, deras realisering på Inera - YouTube

Dokument som beskriver referensarkitekturerna:

• Referensarkitektur för Identitet och åtkomsthantering - på denna länk hittar du dokumentet som beskriver: Referensarkitekturen för Identitet och åtkomsthantering

• Referensarkitekturen för Elektronisk underskrift och stämpel - Referensarkitekturen för Elektronisk underskrift och stämpel

Beställning och utförande av spärr

En spärr inom SITHS kan utföras enligt följande matris

Realisering av spärr

När en spärr har begärts av respektive Utförare kan det beroende på metod för kontroll ta en viss tid innan ett system kan få uppdaterad information om detta och använda den för att neka en användare att logga in.

OCSP

Är en metod där ett system kontrollerar ett certifikat åt gången

För denna metod realiseras spärren I princip omedelbart

Varje OCSP-svar får en tidsstämpel som säger hur länge svaret får användas av förlitande part. För SITHS gäller:

• notBefore → Tidpunkt då frågan ställs

• notAfter → 48 h framåt från notBefore

CRL

Är en metod där ett system kan hämta en lista över samtliga spärrade certifikat per certifikatsutfärdare

För denna metod finns en ledtid på upp till 65 minuter. En ny spärrlista ges ut av CA var 60:e minut, samt att det finns en cache på 5 minuter innan ny hämtas till den server (CDP) som är avlämningspunkt mot förlitande part.

Varje CRL får en tidsstämpel som säger hur länge den får användas av en förlitande part, för SITHS gäller:

Spärrlistor för certifikat till slutanvändare och funktionscertifikat:

• lastUpdate → Tidpunkten då CRL skapas av CA

• nextUpdate → 72h från lastUpdate

Spärrlistor som utfärdas av Root CA för utfärdande CAs:

• lastUpdate → Tidpunkten då CRL skapas manuellt då rooten är offline

• nextUpdate → ~12 månader

Net iD används för att importera certifikat från SITHS-kortet till den certifikatshanterare som finns på datorn. Tjänsten, som användaren ska logga in i, integrerar i sin tur via webbläsaren mot operativsystemets inbyggda funktioner för att be användaren presentera ett inloggningsceritfikat.

Exakt hur detta utförs rent praktiskt och hur användareupplevelsen blir varierar med vilken typ och version av:

• tjänstens servermjukvara

• användarens operativsystem

• användarens webbläsare (för webbaserade tjänster)

• eventuell övrig användarapplikation

Förutsättningar

• Användaren behöver ha en så ny version av Net iD som möjligt - Programvaror och tillbehör för SITHS

• Både servern som driftar tjänsten och ofta användarens klientdator måste ha:

  • Tillit till rätt Certifikatsutfärdare inom SITHS - Rot- och utfärdarcertifikat

  • Brandväggsöppningar för spärrkontroll och byggande av tillitskedja - Sökvägar och brandväggsöppningar - Certifikatsutfärdare

• Säkerställ att kortläsaren inte har strömsparläge aktiverat. Detta görs antingen i Datorns BIOS, Via enhetshanteraren eller genom inställningar i drivrutinerna för den enhet som används

• Säkerställ att använda så nya drivrutiner som möjligt för kortläsaren och att dessa laddas ner från tillverkaren av kortläsaren istället för via Windows Update

Användning av Net iD plugin har med tiden kommit att bli allt svårare att vidmakthålla då webbläsarutvecklarna tagit bort alternativt begränsat stödet för de API:er, NPAPI (Chrome/Firefox) och ActiveX (Internet Explorer), som använts av tredjepartsmjukvaror som Net iD plugin.

Numer kan Net iD plugin endast användas via Active X i webbläsaren Internet Explorer 11. Detta förutsätter också att användarens klientdator tillåter körning av ActiveX plugins (disabled by default) och att just SecMakers plugin för Net iD tillåts (default deny). Detta kan styras med hjälp av AD-kontrollerade Grupp principer (GPO).

För support kring användning av Net iD plugin hänvisas kunden till att teckna extra supportavtal med SecMaker som är leverantör av Net iD.

Vid underskrift via Net iD plugin används en annan kod, Underskriftskoden.

Användning av Net iD plugin har med tiden kommit att bli allt svårare att vidmakthålla då webbläsarutvecklarna tagit bort stöd för det/de API:er (NPAPI och ActiveX) som använts av tredjepartsmjukvara som Net iD plugin. Numer kan detta endast realiseras via Internet Explorer 11 och Active X.

För support kring användning av Net iD plugin hänvisas kunden till att teckna extra supportavtal med SecMaker som är leverantör av Net iD.

Två stora skillnader när det kommer till underskrifter med hjälp av Net iD plugin och Ineras nya Underskriftstjänst är:

• Underskriftslösningen med Net iD plugin blir proprietär för varje tjänst som bygger en integration mot Net iD plugin. Varpå hela ansvaret för den juridiska giltigheten för underskriften vilar på den organisation som utvecklat och/eller beställt utveckling av den tjänst som integrerar mot Net iD plugin för att skapa elektroniska underskrifter

• Formatet för själva underskriften hanteras helt av den egna tjänsten. Ineras Underskriftstjänst följer DIGGs specifikationer och använder nationellt och internationellt godkända underskriftsformat.

Vid användning av SITHS med Net iD finns funktioner som gör att pin-koden för legitimering inte behöver anges vid varje ny begäran.

Detta är ett måste för användarupplevelsen vid exempelvis inloggning till Windows. Det har också gett ett mervärde vid inloggning till tjänster som inte följer Referensarkitekturen för Identitet- och åtkomsthantering eftersom användaren inte behöver ange sin pin-kod upprepade gånger eller när man ska logga in i en annan tjänst utan att ha lämnat datorn

I referensarkitekturen baseras Single Sign-On upplevelsen på att man utfärdar identitetsintyg som är giltiga för inloggning i flera tjänster som använder samma IdP (enligt standarderna SAMLv2 och OIDC)

Legitimering med SITHS eID

Underskrift med SITHS eID

Legitimering med Mutuals TLS och Net iD

Underskrift med Net iD

Om användaren har ett användarnamn (domäninloggningsnamn) angivet i HSA när certifikatet eller kortet beställs inkluderas det i certifikatet som ett “User Principal Name”. Certifikatet får då också övriga egenskaper som behövs för att fungera för interaktiv inloggning till Windows

Därefter kan man följa instruktioner från Microsoft för hur man implementerar stöd för inloggning till Microsoft AD med certifikat från en tredjepartsutfärdare (SITHS), se Guidlines for enabling smart card logon with third-party certification authorities

I dagsläget används klientprogramvaran Net iD Enterprise för att ge stöd för interaktiv inloggning till Windows tillsammans med SITHS e-legitimation på SITHS-kort.

Net iD

Net iD Enterprise importerar certifikaten från SITHS-kortet till Windows egen certifikatslagring. Detta följer samma logik som Mutual TLS för legitimering med SITHS och Net iD

Beroende på vilken paktering av Net iD som används kan man också skräddarsy användarupplevelsen vid inloggning till AD med egen grafik på inloggningsskärmen.

Det finns också pakteringar av Net iD som använder Windows egna funktioner, men som bara tillför stöd för SITHS-korten, Net iD installeras då som en så kallad minidriver som används under Microsofts egen BaseCSP

Mifarekodning

Användning av sektorer

Sektor 0

MAD information

Sektor 14

På alla kortprodukter kodas de 16 sista siffrorna kortets serienummer i sektor 14 på både block 0 och block 1.

• Block 0 – ASCII

  • Block0Sector14 = 30 38 33 35 32 35 34 30 31 31 30 35 39 37 30 32

  • ASCIIDecode(Block0Sector14) = 0835254011059702

• Block 1 – 2 binära heltal, SystemNo och CardNo

  • Block1Sector14 = 00 7F 73 1C 00 A8 C1 F6 00 00 00 00 00 00 00 00

  • SystemNo = Int32(00 7F 73 1C)

  • CardNo = Int32(00 A8 C1 F6)

  • SystemNo + CardNo = 0835254011059702

• Block 2 - Innehåller det statiska värdet ”1.3KNR”.

Sektor 15

På de kortprodukter som i fabrik förses med HSA-id certifikat kodas dessutom HSA-id i sektor 15.

• Block 0 används till den första delen av HSA-id (HSA-id prefix) upp till 16 ASCII tecken. Om HSA-id inte tar upp 16 bytes på sektorn nulltermineras strängen med 0x00

• Block 1 används till den andra delen av HSA-id (HSA-id suffix) upp till 16 tecken ASCII. Om HSA-id inte tar upp 16 bytes på sektorn nulltermineras strängen med 0x00

Bindestrecket som separerar prefix och suffix utelämnas. {hsa-id prefix}-{hsa-id suffix}

Övriga sektorer

Får användas fritt av Ineras kunder.

Applikations ID

Health Services Carelink AB, dvs Inera AB, är registerar som ägare AID ”A00C” hos NXP.

Specifikationen beskriver att informationen läggs på en sektor med 4 block men skulle likaväl läggas på en sektor med 16 block. I detta fall så kommer MAD2 att användas.

Åtkomststyrning och kryptering

Sektor 0

Låst så att endast Leverantör av Kortproduktionstjänst kan ändra i MAD

Sektor 14 & 15

Sektor 14 och 15 är skrivskyddade och är ej publikt åtkomliga varken för läsning eller skrivning. Kontakta Inera support om du behöver det hemliga värde som används som A- och B-nyckel och som kan användas för att läsa dessa sektorer

Övriga sektorer

Lämnas orörd med standard accessvillkor och nycklar

MIFARE-dokument

Nedan finns en specifikation över vilken information som skrivs i detta chip och hur den kodas:

• SITHS MIFARE Classic specifikation

Här finns också ett par guider för verifiering av dessa chip:

• Verifiering av RFID utan A-nyckel

• Verifiering av RFID med A-nyckel