Page History

Signeringsnycklar som används för att signera subordinate statements, entity statements eller annan federationsmetadata ska lagras i kryptografisk hårdvarumodul (HSM) eller likvärdig hårdvarubunden säkerhetsmekanism med aktiva säkerhetsmekanismer som motverkar såväl fysiska som logiska försök att röja nyckelmaterialet.

Nyckelmaterialet ska inte kunna exporteras eller läsas i klartext utanför säkerhetsmekanismen.

1. kravet gäller endast de federationsinfrastrukturtjänster som är listade under 1.1 - och inte alla federationsinfrastrukturtjänster.
2. Anslutningsoperatören signerar entity statement

I den modell vi nu sätter upp för BAS sker följande:

• Federationsoperatören TA signerar sin egen Entity Configuration samt ett Subordinate Statement om anslutningsoperatören, t ex Internetstiftelsen.
• Anslutningsoperatören, Internetstiftelsens IE signerar sin egen Entity Configuration samt ett Subordinate Statement om medlemmens tekniska entitet.
• Medlemmen signerar sin egen Entity Configuration.

Vi bedömer att kraven på nyckelhantering, framför allt K5 och K7, behöver differentieras utifrån federationsentitetens roll och tillitsposition. K4 har en tydlig säkerhetsfunktion genom att skydda det privata nyckelmaterialet mot röjning och export. Som K4 är formulerat omfattas dock all signering av Entity Statements av krav på HSM eller motsvarande hårdvarubundet nyckelskydd. Eftersom varje Federation Entity publicerar ett self-signed Entity Configuration, som är ett Entity Statement, innebär detta i praktiken ett krav på hårdvaruskyddad signeringsnyckel för samtliga entiteter i federationen. Konsekvensen av detta behöver vara uttryckligen avsedd och bedömd som proportionerlig.

Säkerhetsnyttan med backup, återställning och flerpersonkontroll för nyckellivscykeln är däremot inte densamma för alla typer av entiteter. För en subordinate entity blir en ny lokalt genererad eller aktiverad nyckel inte betrodd i federationen förrän motsvarande publika nyckel har registrerats och publicerats av dess superior. En antagonist som endast kan påverka den lokala nyckellivscykeln kan därför inte etablera en ny betrodd signing key. Den huvudsakliga konsekvensen är i stället risk för tjänsteavbrott genom exempelvis avaktivering, destruktion eller felaktig rotation av nycklar.

Mot den bakgrunden bör det övervägas om K7:s krav på flerpersonkontroll för samtliga kritiska nyckeloperationer är proportionerligt för alla Federation Entities. För många subordinate entities kan starkt skydd av den aktiva nyckeln, separation mellan administration och användning av nyckeln, spårbarhet samt en kontrollerad key rollover ge ett mer ändamålsenligt skydd.

Även K5:s generella krav på backup bör differentieras. För många subordinate entities är det både enklare och säkrare att generera en ny nyckel och genomföra en kontrollerad rollover än att möjliggöra återställning av samma privata nyckel. För en Trust Anchor kan däremot möjligheten att återställa befintligt nyckelmaterial ha större betydelse för kontinuiteten, eftersom ett nyckelbyte kan kräva koordinering med alla parter som förlitar sig på Trust Anchorn.

Vi föreslår därför att K5 och K7 utformas utifrån vilken risk den aktuella nyckeloperationen faktiskt innebär för federationens tillit och tillgänglighet, i stället för att samma modell för backup, nyckelceremonier och flerpersonkontroll tillämpas på samtliga Federation Entities.

I punkt 4.2 anges att frågor om säkerhetsarbete hanteras genom annan normering eller inom respektive federationskontext. 

Internetstiftelsen menar att federationsoperatör, anslutningsoperatör och andra essentiella tillitsbärare ska kravställas någonting i stil med nedanstående förslag:
Leverantörer av sådana federationsinfrastrukturtjänster som har stor påverkan för federationens tillit och tillgänglighet (t ex federationsoperatör, anslutningsoperatör) där part inte omfattas av MSBFS 2020:6 och MSBFS 2020:7 ska vara certifierade enligt SS-EN ISO/IEC 27001:2022 eller motsvarande. Certifieringen ska omfatta de verksamheter, processer, informationssystem och tjänster som används för att tillhandahålla federationsinfrastrukturtjänsterna. Om certifiering baserat på ett annat ramverk än ISO/IEC 27001 åberopas för att visa kravuppfyllnad, ska leverantören tillhandahålla en dokumenterad överensstämmelseanalys som visar hur det valda ramverket motsvarar relevanta krav i SS-EN ISO/IEC 27001:2022 och att inga väsentliga avvikelser föreligger.

Motivering: Även om NIS2 och den nationella cybersäkerhetsregleringen utgör grundläggande regulatoriska krav för de verksamheter som omfattas, ersätter de inte behovet av särskilda och verifierbara säkerhetskrav för leverans av federationsinfrastrukturtjänster. Kravet på certifiering enligt SS-EN ISO/IEC 27001:2022 syftar till att skapa ett enhetligt och oberoende verifierat underlag för att bedöma leverantörernas systematiska informationssäkerhetsarbete. Det förenklar även tredjepartsutlåtandet som kan fokusera på just rutiner och förmågor utifrån kraven som definieras i federationsramverket/SIB. Kraven gör också att ribban sätts på en tydlig och verifierbar grundnivå för aktörer som får en betrodd position i infrastrukturen. En sådan roll innebär trots allt ett ansvar som sträcker sig utanför den egna organisationen och kan påverka tilliten till andra aktörer och i vissa fall federationen som helhet.

Sen kan man precis som tredjepartsutlåtande välja att ha det som undantag för piloten, men i nuläget uppfyller Digg (TA) kravet redan genom att vara statlig myndighet under bl a MSBFS 2020:6 och 7. Internetstiftelsen är certifierade. Inera uppfyller kravet på motsvarande genom att ha granskats av Digg och innehar kvalitetsmärket där man bl a har tittat på ledningssystem för informationssäkerhet i tillämpliga delar baseras på ISO/IEC 27001 eller motsvarande likvärdiga principer.