MIKEY

Den här artikeln handlar om det kryptografiska protokollet. För CPU, se Atari Lynx . För annan användning, se Mikey .

Multimedia Internet KEYing (MIKEY) är ett nyckelhanteringsprotokoll som är avsett för användning med realtidsapplikationer. Det kan specifikt användas för att ställa in krypteringsnycklar för multimediasessioner som är säkrade med SRTP , säkerhetsprotokollet som vanligtvis används för att säkra realtidskommunikation som VoIP.

MIKEY definierades först i RFC 3830. Ytterligare MIKEY-lägen har definierats i RFC 4650, RFC 4738, RFC 6043, RFC 6267 och RFC 6509.

Syftet med MIKEY

Som beskrivs i RFC 3830 är MIKEY-protokollet avsett att tillhandahålla end-to-end-säkerhet mellan användare för att stödja en kommunikation. För att göra detta delar den en sessionsnyckel, känd som Traffic Encryption Key (TEK), mellan deltagarna i en kommunikationssession. MIKEY-protokollet kan också autentisera deltagarna i kommunikationen.

MIKEY tillhandahåller många metoder för att dela sessionsnyckeln och autentisera deltagare.

Använder MIKEY i praktiken

MIKEY används för att utföra nyckelhantering för att säkra ett multimediakommunikationsprotokoll. Som sådan sker MIKEY-utbyten i allmänhet inom signaleringsprotokollet som stöder kommunikationen.

En vanlig installation är att MIKEY stöder Secure VoIP genom att tillhandahålla nyckelhanteringsmekanismen för VoIP-protokollet (SRTP). Nyckelhantering utförs genom att inkludera MIKEY-meddelanden i SDP- innehållet i SIP- signaleringsmeddelanden.

Användningsfall

MIKEY överväger hur man säkrar följande användningsfall:

  • En-till-en-kommunikation
  • Konferenskommunikation
  • Gruppsändning
  • Vidarekoppling
  • Ring Forking
  • Försenad leverans (röstbrevlåda)

Inte alla MIKEY-metoder stöder varje användningsfall. Varje MIKEY-metod har också sina egna fördelar och nackdelar när det gäller funktionsstöd, beräkningskomplexitet och latens för kommunikationsinställning.

Viktiga transport- och utbytesmetoder

MIKEY stöder åtta olika metoder för att ställa in en gemensam hemlighet (att användas som t.ex. en sessionsnyckel eller en session KEK ):

  • Fördelad nyckel (MIKEY-PSK) : Detta är det mest effektiva sättet att hantera transporten av den gemensamma hemligheten, eftersom endast symmetrisk kryptering används och endast en liten mängd data behöver utbytas. En individuell nyckel måste dock delas med varje enskild peer, vilket leder till skalbarhetsproblem för större användargrupper.
  • Public-Key (MIKEY-PK) : Den gemensamma hemligheten utbyts med hjälp av kryptering av offentlig nyckel . I större system kräver detta en PKI för att hantera säker distribution av publika nycklar.
  • Diffie–Hellman (MIKEY-DH) : Ett Diffie–Hellman-nyckelutbyte används för att skapa den gemensamma hemligheten. Denna metod har en högre resursförbrukning (både beräkningstid och bandbredd) än de tidigare, men har fördelen av att ge perfekt framåtsekretess . Den kan också användas utan någon PKI.
  • DH-HMAC (MIKEY-DHHMAC) (HMAC-autenticerad Diffie–Hellman): Detta är en lätt version av Diffie–Hellman MIKEY: istället för certifikat och RSA-signaturer använder den HMAC för att autentisera de två delarna till varandra. DH-HMAC definieras i RFC 4650.
  • RSA-R (MIKEY-RSA-R) (Omvänd RSA ): Den gemensamma hemligheten utbyts med hjälp av kryptering av offentlig nyckel på ett sätt som inte kräver någon PKI: initiatorn skickar sin offentliga RSA-nyckel till svararen, vilket svarar genom att välja den gemensamma hemligheten och sedan skicka tillbaka den till initiatorn krypterad med initiatorns publika nyckel. RSA-R definieras i RFC 4738.
  • TICKET (MIKEY-TICKET) : Biljettbaserade lägen för nyckeldistribution i multimediainternetnyckel (MIKEY). MIKEY-TICKET definieras i RFC 6043.
  • IBAKE (MIKEY-IBAKE) : Identitetsbaserat autentiserat nyckelutbyte (IBAKE) läge för nyckeldistribution i multimediainternet-KEYing (MIKEY). MIKEY-IBAKE definieras i RFC 6267.
  • SAKKE (MIKEY-SAKKE) : Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY). Detta är en identitetsbaserad metod för autentiserat nyckelutbyte. MIKEY-SAKKE definieras i RFC 6509.

MIKEY meddelanden

Majoriteten av MIKEY-metoderna kräver att initiatorn skickar ett meddelande till deltagarna (I_MESSAGE), och att mottagarna svarar med ett annat meddelande (R_MESSAGE). När detta utbyte har slutförts kan sessionsnyckeln genereras av deltagarna. MIKEY-SAKKE kräver ingen R_MESSAGE.

MIKEY meddelandeinnehåll

MIKEY-meddelanden består av ett antal nyttolaster. Varje nyttolast beskriver nästa nyttolast i MIKEY-meddelandet. På så sätt har MIKEY-protokollet visat att det är flexibelt att utökas och anpassas.

Den första nyttolasten är alltid Common Header (HDR). Detta identifierar versionen av MIKEY-protokollet, metoden som används (datatyp), om ett svar krävs och det identifierar den kryptografiska sessionen som kommer att upprättas via utbytet.

Ytterligare nyttolaster definieras av MIKEY-metoden som används. Dessa inkluderar ofta informationsnyttolaster som:

  • En tidsstämpel nyttolast (T) - denna innehåller tiden och hjälper därför till att skydda mot reprisattacker.
  • Identity Payloads (ID) - detta identifierar deltagarna. Denna nyttolasttyp kan också innehålla certifikat (CERT). Detta utökades i RFC 6043 till att omfatta användarens "roll" som en del av ID (IDR).
  • En RAND-nyttolast (RAND) - detta är slumpmässiga data som används för att salta nyckelhärledningen efter utbyte.
  • Säkerhetspolicyer (SP) - detta innehåller en begränsad uppsättning säkerhetspolicyer för att stödja kommunikationen.
  • Certificate Hash (CHASH) - en hash som indikerar ett certifikat som används för kryptering med publik nyckel.

Utöver detta kommer MIKEY-meddelandet att innehålla minst en nyttolast som kapslar in nyckelmaterial. Dessa inkluderar:

  • Nyckeldatatransport (KEMAC) - detta kapslar in nyckeln genom att kryptera den med en fördelad hemlighet. Detta utökas med RFC 4650 för att stödja autentiserade Diffie–Hellman (DHHMAC).
  • Diffie–Hellman (DH) - detta innehåller kryptografisk information som stöder Diffie–Hellman -protokollet.
  • Envelope Data (PKE) - detta kapslar in nyckeln med kryptering av offentlig nyckel . Detta utökas med RFC 4738 och RFC 6267.
  • Sakai-Kasahara (SAKKE) - detta kapslar in nyckeln med hjälp av det identitetsbaserade Sakai-Kasahara- protokollet. Detta definieras av RFC 6509.
  • Ticket (TICKET) - tillhandahåller en kryptografisk token för att begära nyckelmaterial från en extern server (KMS). Detta definieras av RFC 6043.

Slutligen kan MIKEY-meddelandet innehålla en autentiseringsnyttolast. Dessa inkluderar:

  • Signatur (SIGN) - en signatur på MIKEY-meddelandet.
  • Verifiering (V) - en MAC som skickas av mottagaren för att verifiera mottagandet.

Se även

Hämtad från " https://en.wikipedia.org/w/index.php?title=MIKEY&oldid=1111690957 "