Ömsesidig autentisering

Ömsesidig autentisering eller tvåvägsautentisering (inte att förväxla med tvåfaktorsautentisering ) hänvisar till två parter som autentiserar varandra samtidigt i ett autentiseringsprotokoll . Det är ett standardläge för autentisering i vissa protokoll ( IKE , SSH ) och valfritt i andra ( TLS ).

Ömsesidig autentisering är en önskad egenskap i verifieringssystem som överför känsliga data, för att säkerställa datasäkerhet . Ömsesidig autentisering kan åstadkommas med två typer av autentiseringsuppgifter: användarnamn och lösenord och certifikat för offentliga nyckel .

Ömsesidig autentisering används ofta i Internet of Things (IoT). Att skriva effektiva säkerhetsscheman i IoT-system kan bli utmanande, särskilt när system önskas vara lätta och ha låga beräkningskostnader. Ömsesidig autentisering är ett avgörande säkerhetssteg som kan försvara sig mot många motstridiga attacker, vilket annars kan få stora konsekvenser om IoT-system (som e-sjukvårdsservrar) hackas. I systemanalyser gjorda av tidigare arbeten hade bristen på ömsesidig autentisering ansetts vara en svaghet i dataöverföringsscheman.

Processsteg och verifiering

Schema som har ett ömsesidigt autentiseringssteg kan använda olika metoder för kryptering, kommunikation och verifiering, men de har alla en sak gemensamt: varje enhet som är involverad i kommunikationen verifieras. Om Alice vill kommunicera med Bob kommer de både att autentisera den andre och verifiera att det är den de förväntar sig att kommunicera med innan några data eller meddelanden överförs. En ömsesidig autentiseringsprocess som utbyter användar-ID:n kan implementeras enligt följande: [ citat behövs ]

  1. Alice skickar ett krypterat meddelande till Bob för att visa att Alice är en giltig användare.
  2. Bob verifierar meddelandet:
    1. Bob kontrollerar formatet och tidsstämpeln. Om någon av dem är felaktig eller ogiltig avbryts sessionen.
    2. Meddelandet dekrypteras sedan med Bobs hemliga nyckel, vilket ger Alices ID.
      1. Bob kontrollerar om meddelandet matchar en giltig användare. Om inte, avbryts sessionen.
  3. Bob skickar tillbaka ett meddelande till Alice för att visa att Bob är en giltig användare.
  4. Alice verifierar meddelandet:
    1. Alice kontrollerar formatet och tidsstämpeln. Om någon av dem är felaktig eller ogiltig avbryts sessionen.
    2. Sedan dekrypteras meddelandet med Alices hemliga nyckel, vilket ger Bobs ID.
      1. Alice kontrollerar om meddelandet matchar en giltig användare. Om inte, avbryts sessionen.
  5. Vid denna tidpunkt är båda parter verifierade att vara de de utger sig för att vara och säkra för den andra att kommunicera med. Till sist kommer Alice och Bob att skapa en delad hemlig nyckel så att de kan fortsätta kommunicera på ett säkert sätt.

För att verifiera att ömsesidig autentisering har skett framgångsrikt är Burrows-Abadi-Needham-logik (BAN-logik) en väl ansedd och allmänt accepterad metod att använda, eftersom den verifierar att ett meddelande kom från en pålitlig enhet. BAN-logik antar först att en enhet inte är att lita på och kommer sedan att verifiera dess laglighet.

Försvar

Ömsesidig autentisering stöder noll trust-nätverk eftersom det kan skydda kommunikation mot kontradiktoriska attacker, särskilt:

Man-in-the-middle-attack
Man-in-the-middle (MITM)-attacker är när en tredje part vill avlyssna eller avlyssna ett meddelande och ibland ändra det avsedda meddelandet för mottagaren. De två parterna tar öppet emot meddelanden utan att verifiera avsändaren, så de inser inte att en motståndare har lagt sig i kommunikationslinjen. Ömsesidig autentisering kan förhindra MITM-attacker eftersom både avsändaren och mottagaren verifierar varandra innan de skickar sina meddelandenycklar till dem, så om en av parterna inte verifieras att vara den de påstår att de är kommer sessionen att avslutas.
Replay attack
En replay attack liknar en MITM attack där äldre meddelanden spelas upp ur sitt sammanhang för att lura servern. Detta fungerar dock inte mot scheman som använder ömsesidig autentisering eftersom tidsstämplar är en verifieringsfaktor som används i protokollen. Om tidsförändringen är större än den maximalt tillåtna tidsfördröjningen kommer sessionen att avbrytas. På samma sätt kan meddelanden innehålla ett slumpmässigt genererat nummer för att hålla reda på när ett meddelande skickades.
Spoofing-attack
Spoofing-attacker är beroende av att använda falska data för att posera som en annan användare för att få tillgång till en server eller identifieras som någon annan. Ömsesidig autentisering kan förhindra falska attacker eftersom servern också kommer att autentisera användaren och verifiera att de har rätt sessionsnyckel innan ytterligare kommunikation och åtkomst tillåts.
Imitationsattacker
När varje part autentiserar den andra skickar de ett certifikat till varandra som bara den andra parten vet hur man avkodar, och verifierar sig som en pålitlig källa. På så sätt kan motståndare inte använda identitetsattacker eftersom de inte har rätt certifikat för att agera som om de vore den andra parten.

Ömsesidig autentisering säkerställer också informationens integritet, eftersom om parterna verifieras att vara den korrekta källan är den mottagna informationen också tillförlitlig.

mTLS

Som standard bevisar TLS- protokollet endast serverns identitet för klienten med hjälp av X.509-certifikat , och autentiseringen av klienten till servern överlåts till applikationslagret. TLS erbjuder även klient-till-server-autentisering med X.509-autentisering på klientsidan. Eftersom det kräver tillhandahållande av certifikaten till kunderna och innebär mindre användarvänlig upplevelse, används det sällan i slutanvändarapplikationer.

Ömsesidig TLS-autentisering (mTLS) används oftare i business-to-business (B2B) applikationer, där ett begränsat antal programmatiska och homogena klienter ansluter till specifika webbtjänster, den operativa bördan är begränsad och säkerhetskraven vanligtvis är mycket högre jämfört med konsumentmiljöer.

mTLS används också i mikrotjänster -baserade applikationer baserade på körtider som Dapr , via system som SPIFFE.

Lättviktsscheman kontra säkrade scheman

Även om lätta scheman och säkra scheman inte utesluter varandra, kan det ofta öka prestandakörningstiden och beräkningskostnaderna att lägga till ett ömsesidigt autentiseringssteg till dataöverföringsprotokoll. Detta kan bli ett problem för nätverkssystem som inte kan hantera stora datamängder eller de som ständigt måste uppdateras för ny realtidsdata (t.ex. platsspårning, hälsodata i realtid).

Sålunda blir det en önskad egenskap hos många ömsesidiga autentiseringsscheman att ha lätta egenskaper (t.ex. ha ett lågt minnesutrymme ) för att tillgodose systemet som lagrar mycket data. Många system implementerar cloud computing , vilket ger snabb åtkomst till stora mängder data, men ibland kan stora mängder data bromsa kommunikationen. Även med kantbaserad cloud computing, som är snabbare än allmän cloud computing på grund av en närmare närhet mellan servern och användaren, möjliggör lätta system för högre hastighet när man hanterar större mängder data. En lösning för att hålla scheman lätta under den ömsesidiga autentiseringsprocessen är att begränsa antalet bitar som används under kommunikation.

Applikationer som enbart förlitar sig på enhet-till-enhet- kommunikation (D2D), där flera enheter kan kommunicera lokalt i närheten, tar bort tredje parts nätverk. Detta kan i sin tur påskynda kommunikationstiden. Men autentiseringen sker fortfarande genom osäkra kanaler, så forskare anser att det fortfarande är viktigt att säkerställa ömsesidig autentisering för att upprätthålla ett säkert system.

Schemen kan offra en bättre körtid eller lagringskostnad när man säkerställer ömsesidig autentisering för att prioritera skyddet av känsliga data.

Lösenordsbaserade system

I ömsesidiga autentiseringssystem som kräver en användares inmatningslösenord som en del av verifieringsprocessen, finns det en högre sårbarhet för hackare eftersom lösenordet är mänskligt skapat snarare än ett datorgenererat certifikat. Även om applikationer helt enkelt kan kräva att användarna använder ett datorgenererat lösenord, är det obekvämt för människor att komma ihåg. Användargjorda lösenord och möjligheten att ändra sitt lösenord är viktiga för att göra en applikation användarvänlig, så många system fungerar för att tillgodose egenskapen. Forskare noterar att ett lösenordsbaserat protokoll med ömsesidig autentisering är viktigt eftersom användaridentiteter och lösenord fortfarande är skyddade, eftersom meddelandena bara är läsbara för de två inblandade parterna.

En negativ aspekt med lösenordsbaserad autentisering är dock att lösenordstabeller kan ta upp mycket minnesutrymme. Ett sätt att använda mycket minne under ett lösenordsbaserat autentiseringssystem är att implementera engångslösenord (OTP), som är ett lösenord som skickas till användaren via SMS eller e-post. OTP:er är tidskänsliga, vilket innebär att de upphör efter en viss tid och att minnet inte behöver lagras.

Multi-faktor autentisering

Nyligen har fler system autentisering på högre nivå än lösenordsbaserade system. Medan lösenordsbaserad autentisering betraktas som "enfaktorsautentisering", börjar system att implementera smartkort ( tvåfaktors ) eller biometriskt baserade (trefaktors) autentiseringsscheman. Smartkort är enklare att implementera och lätta för autentisering, men riskerar fortfarande att manipuleras. Biometri har blivit mer populärt än lösenordsbaserade system eftersom det är svårare att kopiera eller gissa sessionsnycklar när du använder biometri, men det kan vara svårt att kryptera bullriga data. På grund av dessa säkerhetsrisker och begränsningar kan system fortfarande använda ömsesidig autentisering oavsett hur många autentiseringsfaktorer som läggs till.

Certifikatbaserade system och systemapplikationer

Ömsesidig autentisering finns ofta i system som används i Internet of Things (IoT), där fysiska objekt är inkorporerade i Internet och kan kommunicera via IP-adress. Autentiseringsscheman kan tillämpas på många typer av system som involverar dataöverföring. När Internets närvaro i mekaniska system ökar, kan det bli svårt att skriva effektiva säkerhetsscheman för ett stort antal användare, objekt och servrar, särskilt när scheman behöver vara lätta och ha låga beräkningskostnader. Istället för lösenordsbaserad autentisering kommer enheter att använda certifikat för att verifiera varandras identiteter.

Radionätverk

Ömsesidig autentisering kan uppfyllas i radionätverk, där dataöverföringar via radiofrekvenser är säkra efter verifiering av sändare och mottagare.

Radiofrekvensidentifiering (RFID)-taggar används ofta för objektdetektering, vilket många tillverkare implementerar i sina lagersystem för automatisering. Detta möjliggör ett snabbare sätt att hålla jämna steg med inventering och spåra objekt. Att hålla reda på artiklar i ett system med RFID-taggar som överför data till en molnserver ökar dock chanserna för säkerhetsrisker, eftersom det nu finns fler digitala element att hålla reda på. En trevägs ömsesidig autentisering kan ske mellan RFID-taggar, taggläsarna och molnnätverket som lagrar denna data för att hålla RFID-taggdata säker och oförmögen att manipuleras.

På samma sätt har ett alternativt RFID-tagg- och läsarsystem som tilldelar utsedda läsare till taggar föreslagits för extra säkerhet och låg minneskostnad. Istället för att betrakta alla taggläsare som en enhet, kan bara vissa läsare läsa specifika taggar. Med den här metoden, om en läsare bryter mot, kommer det inte att påverka hela systemet. Enskilda läsare kommer att kommunicera med specifika taggar under ömsesidig autentisering, som körs konstant eftersom läsarna använder samma privata nyckel för autentiseringsprocessen.

Många e-sjukvårdssystem som fjärrövervakar patienthälsodata använder trådlösa kroppsnätverk (WBAN) som överför data via radiofrekvenser. Detta är fördelaktigt för patienter som inte bör störas medan de övervakas, och kan minska arbetsbelastningen för medicinsk personal och tillåta dem att fokusera på de mer praktiska jobben. En stor oro för vårdgivare och patienter när det gäller att använda fjärrspårning av hälsodata är att känslig patientdata överförs via osäkra kanaler, så autentisering sker mellan den medicinska nätverksanvändaren (patienten), vårdleverantören (HSP) och den betrodda tredje parten.

Molnbaserad datoranvändning

e-sjukvårdsmoln är ett annat sätt att lagra patientdata som samlats in på distans. Moln är användbara för att lagra stora mängder data, såsom medicinsk information, som kan nås av många enheter när det behövs. Telecare Medical Information Systems (TMIS), ett viktigt sätt för medicinska patienter att ta emot sjukvård på distans, kan säkerställa säkrad data med ömsesidiga autentiseringssystem. Blockchain är ett sätt som har föreslagits för att ömsesidigt autentisera användaren till databasen, genom att autentisera med huvudnoden mediBchain och behålla patientens anonymitet.

Fog-cloud computing är ett nätverkssystem som kan hantera stora mängder data, men som fortfarande har begränsningar vad gäller beräknings- och minneskostnad. Mobile edge computing (MEC) anses vara ett förbättrat, mer lättviktigt fog-cloud computing-nätverkssystem och kan användas för medicinsk teknik som också kretsar kring platsbaserad data. På grund av den stora fysiska räckvidden som krävs för platsspårning 5G-nätverk skicka data till molnets kant för att lagra data. En applikation som smarta klockor som spårar patienthälsodata kan användas för att ringa närmaste sjukhus om patienten visar en negativ förändring i vitals.

Dimnodnätverk kan implementeras i bilautomation , vilket håller data om bilen och dess omgivande tillstånd säkra. Genom att autentisera dimnoderna och fordonet blir fordonsöverlämning en säker process och bilens system är säkert från hackare.

Maskin till maskin verifiering

Många system som inte kräver en mänsklig användare som en del av systemet har också protokoll som ömsesidigt autentiserar mellan parter. I för obemannade flygfarkoster (UAV) sker en plattformsautentisering snarare än användarautentisering. Ömsesidig autentisering under fordonskommunikation förhindrar att ett fordons system bryts, vilket då kan påverka hela systemet negativt. Till exempel kan ett system av drönare användas för jordbruksarbete och lastleverans, men om en drönare skulle bli inträngd har hela systemet potential att kollapsa.

externa länkar