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 och autentiseringslösningar baserade på dubbelriktad TLS (mTLS) finns funktioner som gör att pin-koden för legitimering inte behöver anges vid varje ny begäran om legitimering/autentisering

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 som hanterar autentisering via samma AD-miljö som den AD-miljö som hanterar användarens inloggning till själva Windows-datorn.

I referensarkitekturen baseras Single Sign-On (SSO) 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 eller OIDC).

Pin-cache är aktiverad som default i:

• Paketeringar av Net iD Enterprise under Ineras licens

• De paketeringar av SITHS eID-appen som har tilläget “MD”

Referenser

• Programvaror och tillbehör för SITHS

• Ladda ner SITHS eID Windowsklient

Legitimering med SITHS eID

Underskrift med SITHS eID

Legitimering med Mutuals TLS och Net iD

Underskrift med Net iD

Sammanfattning

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 det ska gå att använda vid interaktiv inloggning till Windows istället för angivande av användarnamn och lösenord.

Vid denna typ av interaktiva inloggning kommer även inloggning till övriga applikationer som sköter autentisering med hjälp av samma samma AD-miljö att kunna hantera via PIN-SSO/Pin-cache, för mer information se rubriken Pin-cache och Pin-SSO

Förutsättningar

Något av följande krävs för att ge stöd för interaktiv inloggning till Windows tillsammans med SITHS eID på kort:

• Lokalt i er organisation

  • Net iD Enterprise

  • Installera paket för SITHS eID-app på aktuella Windows-datorer

    • Välj paketering med tillägget “MD” = Minidriver för att få med stödet för interaktiv kortinloggning till Windows/AD.

  • Konfigurera AD-installationen och aktuella AD-konton enligt 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

Detaljer

Interaktiv inloggning till en dator (“lokal datorinloggning”) med Windows styrs enligt Windows-arkitekturen av s k autentiseringsmoduler (authentication providers) i operativsystemet. Microsoft rekommenderar inte att byta ut de inbyggda autentiseringsmodulerna till tredje-parts-programvara. Det gör att de autentiseringsmöjligheter som finns är begränsade till det som tillhandahålls i Windows. En sådan möjlighet är att använda smarta kort som följer Microsofts Minidriver-specifikation.

I miljöer där säker åtkomst till applikationerna är det primära och klientdatorerna ses som delade arbetsplatser, kan det vara lämpligast att endast kräva SITHS-kort vid applikationsåtkomst och inte för inloggning till klientdatorn.

Om man vill använda SITHS-kortet för den interaktiva inloggningen till Windows-datorer, kan SITHS installationspaket för Windows-datorer användas. I en av paketeringarna ingår en Minidriver med stöd för SITHS-korten. I paketeringen ingår även en funktion för att låsa upp ett låst SITHS-kort vid Windows inloggningsskärm med hjälp av upplåsningskod (puk).

Notera att inloggningen med SITHS-kortet sker lokalt mot Windows/AD med hjälp av det inbyggda stödet för smarta kort i Windows. I Windows/AD-miljön ställs ut s.k. Kerberos-biljetter för att användaren ska få åtkomst till olika Windows-resurser. Denna teknik är dock inte kopplad till den IdP-baserade inloggning som beskrevs ovan, vilket medför att kortinloggning i Windows/AD i sig inte ger SSO-funktionalitet mot tjänster som är kopplade till IdP. Dock har Minidrivern stöd för cachning av pin på datorn vilket i vissa.

Minidrivern eller Net iDs funktion är att agera drivrutin mot SITHS-kortet och importera certifikaten till Windows-datorns “MyStore” och därigenom göras dem valbara för användaren vid Windows inloggningsskärm förutsatt att AD-miljön har konfigurerats korrekt.

Referenser

• Programvaror och tillbehör för SITHS

• Ladda ner SITHS eID Windowsklient

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