R o g e r M. N e e d h a m a n d M i c h a e l D. S c h r o e d e r X e r o x P a l o A l t o R e s e a r c h C e n t e r Användning av kryptering för att uppnå autentiserad kommunikation i datornätverk diskuteras. Exempel protokoll presenteras för upprättande av autentiserade anslutningar, för hantering av autentiserad post, och för signaturverifikation och dokumentintegritet garanti. Både konventionella och allmänna krypteringsalgoritmer betraktas som grunden för protokoll. Nyckelord och fraser: kryptering, säkerhet, autentisering, nätverk, protokoll, kryptosystem med öppen nyckel, datakrypteringsstandard CR Kategorier: 3.81, 4.31, 4.35 I samband med säker datorkommunikation innebär autentisering att de kommunicerande principernas identitet verifieras till varandra. Ett nätverk i vilket ett stort antal datorer kommunicerar får inte ha någon central maskin eller något system som innehåller upphovsmanBefogenhet att utan avgift kopiera allt eller en del av detta material, förutsatt att kopiorna inte görs eller distribueras för direkt kommersiell fördel, att meddelandet om upphovsrätt till ACM och titeln på publikationen och dess datum visas, och att det meddelas att kopiering sker genom tillstånd från Föreningen för datormaskiner. För att kopiera på annat sätt, eller för att återpublicera, krävs en avgift och/eller ett särskilt tillstånd.  itativa beskrivningar av de anslutna datorerna, av de ändamål för vilka de används eller av de personer som använder dem. Vi presenterar protokoll för decentraliserad autentisering i ett sådant nätverk som är integrerat med det allierade ämnet namngivning. Det finns ett minimalt beroende av nätverksomfattande tjänster; i synnerhet finns det inget beroende av en enda nätverksklocka eller en enda förvaltningsmyndighet för nätnamn. Tre funktioner diskuteras: (1) Etablering av autentiserad interaktiv kommunikation mellan två huvudmän på olika maskiner. Med interaktiv kommunikation menar vi en serie meddelanden i båda riktningarna, vanligtvis var och en som svar på en tidigare. (2) Autentiserad enkelriktad kommunikation, t.ex. i postsystem, där det är omöjligt att kräva protokollutbyte mellan avsändaren och mottagaren när en vara skickas, eftersom det inte kan finnas någon garanti för att avsändaren och mottagaren är samtidigt tillgängliga. (3) Undertecknad kommunikation, där ett meddelandes ursprung och innehållets integritet kan bestyrkas för en tredje part. Säker kommunikation i fysiskt utsatta nätverk beror på kryptering av material som passerar mellan maskiner. Vi antar att det är möjligt för varje dator i nätverket att kryptera och dekryptera material effektivt med godtyckliga nycklar, och att dessa nycklar inte är lätt att upptäcka genom uttömmande sökning eller kryptoanalys. Vi betraktar både konventionella krypteringsalgoritmer och allmänna krypteringsalgoritmer som en grund för de protokoll som presenteras. Vi antar att en inkräktare kan koppla in en dator i alla kommunikationsvägar, och därmed kan ändra eller kopiera delar av meddelanden, spela upp meddelanden, eller avge falskt material. Även om detta kan tyckas vara en extrem vy, är det den enda säkra när man utformar autentiseringsprotokoll. Vi antar också att varje huvudansvarig har en säker miljö att beräkna i, såsom tillhandahålls av en persondator eller skulle vara av ett säkert delat operativsystem. Vår syn hela tiden är att tillhandahålla autentiseringstjänster till uppdragsgivare som väljer att kommunicera säkert. Vi har inte övervägt de extra problem som uppstår när vi försöker tvinga all kommunikation att ske på ett säkert sätt eller när vi försöker förhindra kommunikation mellan särskilda uppdragsgivare för att genomdriva begränsningar av informationsflödet. Våra protokoll bör ses som exempel som avslöjar autentiseringsproblemen i stora nätverk snarare än som fullt konstruerade lösningar på de övergripande säkerhetsproblemen i en viss applikation. Samtidigt som vi tillhandahåller en lämplig lösning på de autentiseringsproblem som anges och uppfyller de vanligaste säkerhetsmålen, skulle våra protokoll behöva utarbetas för att uppfylla andra säkerhetsmål som att förhindra trafikanalys, undanhålla alla matchande cleartext-chiffertext par från en avlyssning- December 1978 av volym 21 ACM nummer 12 per, och säkerställa omedelbar upptäckt av manipulering, och även för att maximera effektiviteten i vissa nätverk. Det är möjligt att utarbeta andra protokoll som liknar dem som presenteras och som också uppfyller de fastställda målen. Det finns en blygsam mängd litteratur om vårt ämne, och metoder har föreslagits för flera av de enskilda funktioner som vi beskriver [1, 3, 5, 6], även om inget arbete rapporteras som integrerar dessa tekniker och tillämpar dem i en decentraliserad miljö, eller som ger funktionellt likvärdiga protokoll baserade på både konventionell och öppen kryptering. Den viktiga skillnaden mellan konventionella och allmänna krypteringsalgoritmer är hur nycklar används. Med en konventionell krypteringsalgoritm, såsom NBS Data Encryption Standard [7], används samma nyckel för både kryptering och dekryptering. Autentisering beror på att de två deltagarna i ett samtal är de enda två huvudmän (förutom möjligen betrodda servrar) som känner till nyckeln som används för att kryptera det överförda materialet. Med en öppen krypteringsalgoritm, ett koncept som härrör från Diffie och Hellman [3], är två nycklar nödvändiga: en som används i omvandlingen av cleartext till chiffertext, och en annan som används i omvandlingen av chiffertext till cleartext. Dessutom ger kunskap om en nyckel ingen hjälp att hitta den andra, och de två nycklarna kommer att fungera som inverser för varandra. Eleganta system kan utformas där varje huvudansvarig har en offentlig nyckel och en hemlig nyckel. Vem som helst kan kryptera en kommunikation för A med hjälp av sin öppna nyckel, men bara A kan dekryptera resultatet med hjälp av sin hemliga nyckel. Likaså kan endast A kryptera meddelanden som kommer att dekryptera förnuftigt med A: s öppna nyckel. Det första exemplet på en krypteringsalgoritm med öppen nyckel utformades av Rivest et al. [9], och andra är säkra på att följa. Med båda typerna av kryptering är grunden för autentiserad kommunikation en hemlig nyckel som tillhör varje huvudman som använder nätverket, och det finns behov av en auktoritativ informationskälla om dessa nycklar. Vi använder termen autentiseringsserver för en server som kan leverera identifierande information som beräknas från en begärd huvudansvarigs hemliga nyckel. Eftersom huvuddatabasen för en autentiseringsserver indexeras med namn, är hanteringen av autentiseringsservrar relaterad till hanteringen av namn. I ett utvidgat nätverk är det olämpligt att ha en enda central namnregistreringsmyndighet, så vi antar att det finns flera namngivningsmyndigheter, som vart och ett tilldelar och annullerar namn som det vill. Med denna organisation har rektorerna namn på blanketten "NamingAuthority.SimpleName". Associerad med varje 994 namngivningsmyndighet är en eller flera namnlookup-servrar och en eller flera autentiseringsservrar. 1 En namnlookup server är beredd att ge olika nätverksadresser i samband med ett givet SimpleName, till exempel adressen till den huvudansvariges e-postsystem buffert. En eller flera instanser av en huvudnamn uppslagningsserver kommer att tillhandahålla nätverksadresser för lämpliga namn uppslagnings- och autentiseringsservrar när de ges en namngivande myndighets namn. Autentiseringsservrar utför slående liknande funktioner för de två klasserna av krypteringsalgoritmer; skillnaderna kommer att tas fram när de uppstår. En viktig fråga inom detta studieområde är var krypteringen och dekrypteringen görs. Branstad [2] föreslår att dessa åtgärder sker i en dators nätverksgränssnitt. Det är ett krav i några av våra protokoll att krypteringen görs någon annanstans, eftersom det är nödvändigt att förbereda ett krypterat meddelande utan att faktiskt skicka det ännu eller för att ta emot ett krypterat meddelande utan att veta i nätverksgränssnittet vad nyckeln är. Följaktligen har vi antagit att alla hårdvarukryptering hjälp finns så att man kan säga och fortfarande har X i handen, eller säga Om en konventionell algoritm används då varje huvudansvarig har en hemlig nyckel som är känd endast för sig själv och dess autentisering server, vars innehåll är följaktligen hemliga. Det viktigaste steget för att skapa en säker kommunikation mellan A och B är att initiativtagaren, till exempel A, skapar ett budskap med två egenskaper: a) Det måste vara begripligt endast för B, dvs. Låt endast B använda innehållet för att identifiera sig själv till A. b) Det måste vara uppenbart för B att den har sitt ursprung i A. Användningen av kryptering för att uppnå dessa egenskaper beskrevs först av Feistel [4] och applicerades på ett nätverkskontext av Branstad [1]. Namngivningsmyndigheterna är oberoende av nättopologin; de behöver inte ha något att göra med undernätverk eller med särskilda datorer på nätverket. Flera identiska namnlookup servrar och autentisering servrar för en enda namngivning myndighet kan användas för att se till att dessa tjänster är topologiskt "nära" för dem som behöver använda dem, och för att öka tillförlitligheten. Våra flera autentiseringsservrar måste noga skiljas från de som föreslås av Diffie och Hellman [3], som utför den helt andra funktionen att kontrollera varandra. I så fall registreras varje användare hos varje autentiserare, vars syfte är att försvara sig mot korruption hos vissa autentiker. December 1978 av Volym 21 ACM nummer 12 Förutsatt att A och B är i siktet av samma autentiseringsserver AS, vi nu skissera ett protokoll. Den notation som används kommer att följas i hela: kryptering indikeras av hängslen som är överskripterade med nyckeln som används. Protokollet öppnas med A kommunicera i klartext till A S hans egen påstådda identitet och identiteten på den önskade korrespondenten, B, tillsammans med A: s nonce identifierare för denna transaktion, slapp. ("Nunce" betyder "används endast en gång.") Här måste nonce-identifieraren vara annorlunda än andra som används av A i tidigare meddelanden av samma typ. Det första meddelandet i protokollet är: A, B, lal När du tar emot meddelandet (1.1), AS tittar upp hemligheten, identifierar nycklar för båda parter och beräknar också en ny nyckel CK som kommer att vara nyckeln till samtalet om allt går bra. 2 Nästa transaktion är ett ganska komplicerat meddelande från A S till A: ( 1.2) där KA och KB är A: s och B: s hemlighet, identifiera nycklar. Eftersom (1.2) är krypterad med A:s hemliga nyckel, kan endast A dekryptera den och upptäcka konversationsnyckeln CK. Efter dekryptering kontrollerar A förekomsten av den avsedda mottagarens namn, B, och rätt identifierare, IA, för att verifiera att meddelandet verkligen är ett svar från AS på den aktuella förfrågan. Både namnet på den avsedda mottagaren och transaktionsidentifieraren ska anges i meddelandet (1.2). Om mottagarens namn utelämnas, kan en inkräktare ändra det namnet i meddelandet (1.1), säg till X, innan A S tar emot det, med det efterföljande resultatet att A omedvetet skulle kommunicera med X istället för B. Om identifieraren utelämnas kan en inkräktare ersätta ett tidigare registrerat meddelande (1.2) (från A S till A om B) och tvinga A att återanvända en tidigare konversationsnyckel? En minns CK och skickar delen krypterad med KB till B: Den verkliga B, men ingen annan, kommer att kunna dekryptera meddelandet (1.3) och komma fram med konversationsnyckeln CK, samma som A har. B känner också till den tänkta kontaktpersonens identitet, som autentiserad av A S. Det är värt att i detta skede se över de båda parternas kunskapstillstånd. En nu vet att all kommunikation han tar emot krypterad med CK måste ha sitt ursprung med B, och även att all kommunikation han avger med CK kryptering kommer att förstås endast av B. Båda är kända eftersom de enda meddelanden som innehåller CK som någonsin har skickats är knutna till A: s och B: s hemliga z Den nya nyckeln måste vara oförutsägbar och skulle aldrig ha använts tidigare. 3 Observera också att meddelanden (1.1) och (1.2) tillsammans, och andra i våra protokoll, gör tillgänglig känd klartext krypterad med en huvudansvarigs identifierande nyckel. Om det finns oro för kryptoanalytisk attack baserad på känd klartext som används för att exponera en identifierande nyckel, då en ytterligare tillfällig nyckel TK kan användas där det är lämpligt i hela, så att {X} ra blir {TK}KA{x} TM. Nycklarna. B är i ett liknande tillstånd, i tillämpliga delar. Det är dock viktigt att vara säker på att ingen del av protokollet utbyte eller efterföljande konversation spelas upp av en inkräktare från en inspelning av en tidigare konversation mellan A och B. I samband med denna fråga skiljer sig A:s och B:s ståndpunkter åt. A är medveten om att han inte har använt nyckeln CK tidigare och har därför ingen anledning att frukta att material som krypterats med det är annat än de legitima svaren från B. B: s position är inte så bra; om han inte kommer ihåg obestämd tid nycklar som tidigare används av A för att kontrollera att CK är ny, han är oklart att meddelandet (1.3) och de efterföljande meddelanden som antas från A inte spelas upp igen. För att vara på sin vakt mot denna möjlighet genererar B en nonce identifierare för transaktionen, IB, och skickar den till A under CK: förväntar sig ett relaterat svar, säger en mindre: (Is -1} cK (1.5) Om detta svar tas emot på ett tillfredsställande sätt, då det ömsesidiga förtroendet är tillräckligt för att möjliggöra materiell kommunikation, krypterad med CK, att börja. Det finns fem meddelanden i protokoll 1. Antalet kan minskas till tre av A: s hålla, för regelbundna interaktionspartners, en cache av objekt i formulär B: CK, (CK, A) KB härledd från meddelande (1.2), vilket eliminerar meddelanden (1.1) och (1.2). Observera dock att om sådana autentiker är cachad, krävs ändringar i protokollet. Med caching används samma CK om och om igen, så konversationsidentifierare handslag måste vara tvåvägs, till exempel genom att ersätta steg (1.3) och (1.4) med: {CK, A} KB, {IA2) CK Förändringen ökar inte antalet protokollmeddelanden utan ändrar innehållet något. I praktiken skulle meddelanden (1.3)-(1.5) användas för att starta en dubbelriktad seriation för att säkerställa integriteten i den efterföljande konversationen. Metoder för att säkerställa integritet efter inledande kontakt har studerats av Kent [5]. Vi använder nyckeletiketter som PKA for A's public key och SKA för hans hemliga. Utbytet inleds med att A konsulterar autentiseringsservern i klartext för att hitta B:s öppna nyckel. A, B (2.1) A S svarar med: (PKB, B) SKAS (2.2) där SKA S är autentiseringsserverns hemliga nyckel. A antas känna till larmsystemets öppna nyckel, PKAS, som används för att dekryptera meddelandet. Ett måste skaffa och lagra PKAS på ett tillförlitligt sätt, så han är säker på att det är korrekt. Om en Det finns alltså sju steg i detta protokoll som mot fem med protokoll 1, men fyra av dem (2.1, 2.2, 2.4 och 2.5) kan tas bort av A och B båda har lokala caches av allmänt använda allmänna nycklar. De resulterande tre protokollstegen har mycket liknande syften som de tre återstående efter caching i protokoll 1. Observera att eftersom allmänna nycklar inte är hemliga, dubbel kryptering, d.v.s. ( {meddelande)Sra) eKn, eller någon motsvarande krävs under den efterföljande interaktionen. Om uppgifterna helt enkelt var krypterade med mottagarens allmänna nyckel, då kunde vem som helst annan injicera material i strömmen. Ett likvärdigt skydd är att använda ett godtyckligt tal från ett stort utrymme som bas för seriation av krypteringsblock. Detta nummer kan initieras som la eller 1B enligt riktning. En inkräktare skulle inte ha något sätt att veta vad som var rätt serie att infoga i ett förfalskat paket, även om han hade räknat tidigare paket, eftersom han inte kunde veta rätt bas. Ju fler bitar som ägnas åt denna redundanta seriation desto färre bra databitar får vi per enhet dekryptering ansträngning. Begränsningar är inte nödvändiga, och vi tar nu bort dem. När vi utökar protokollen måste vi komma ihåg att även om en autentiseringsserver måste betraktas som den slutliga auktoriteten för sina kunder, måste den inte ha någon effekt på gott eller ont på kommunikationen mellan kunder på andra autentiseringsservrar. Då kommer vårt system inte att bli helt upprört av uppförandet av en shoddy autentiserare. Naturligtvis kommer utomstående att visa försiktighet på mänsklig nivå i sina kontakter med en shoddy autentiserares klienter. Effekterna på protokollen från flera autentiseringsservrar skiljer sig något mellan de två krypteringsteknikerna. Tänk först på fallet med konventionell kryptering. Kravet är fortfarande att producera en post i formuläret { CK, A } K/~ för A att använda när han gör sin första inställning till B (se steg (1.3)). För att producera denna mängd är båda autentiseringsservrarna (som kommer att kallas A SA och A SB) involverade, eftersom endast A SB kan producera objekt krypterade med KB och endast A SA kan producera objekt krypterade med KA. Vi böjde ytterligare två steg mellan (1.1) och (1.2), som utgör ett utbyte mellan de två servrarna. Vi antar att separata åtgärder har vidtagits för att säkerställa säker kommunikation mellan servrarna - till exempel, deras hemliga nycklar hålls av en huvudserver, och de vanliga servrarna upprätta säkra länkar (genom protokoll 1 redan anges) när de kommer i drift. Vi antar också att namnen vid behov alltid är fullständiga "NamingAuthority.SimpleName", så att rätt autentiseringsserver kan hittas. Som förklarats ovan leder kunskapen om en namngivande myndighets namn till nätverksadressen för den tillhörande autentiseringsservern. (1.11) (1.12) (Ial överförs för att undvika att tillståndet bibehålls i ASa mellan meddelanden (1.11) och (1.12). Efter (1.12) A SA är i stånd att slutföra protokollet. I öppen nyckel lätthet, eftersom inga hemliga nycklar flyttas runt, är det möjligt för A att närma sig ASB direkt ifA vet att serverns öppna nyckel. Vi antar att A redan har denna kunskap, även om det i ett strikt fall av total okunnighet skulle finnas viktiga uppslagssteg, till exempel korrespondens med en master autentiseringsserver, före (2.1). Med kunskap om PKA SB motsvarar A direkt A SB i steg (2.1) och (2.2). Likaså, med kunskap om PKA SA, B motsvarar direkt A Sa i (2.4) och (2.5). I båda fallen kan caching förväntas minska antalet protokollmeddelanden till tre. Implementering Authentication Servers I protokollen just med tanke på att vi antog att A och B var kunder av samma autentiseringsserver. Detta Det finns skillnader i genomförandet av autentiseringsservrar för de två varianterna av kryptering. I det konventionella fallet innehållet i databasen, poster i formulär A:KA, måste hållas hemligt (som kan göras genom att kryptera den med hemligheten, identifiera nyckeln på servern). En säker transaktion sker varje gång servern används: i steg (1.2) måste nycklarna till båda kunderna extraheras för att kunna konstruera meddelandets innehåll. I det allmänna nyckelfallet behöver däremot inte innehållet i databasen vara hemligt, och ingen säker transaktion behöver ske när servern används om serverns databas är inställd för att innehålla objekt i formulär A: {PKA, A} sKAs som krävs i steg (2.2). (Om servern innehöll de allmänna nycklarna direkt, skulle det fortfarande finnas en säker operation vid varje användning, av de skäl som nämns i diskussionen om steg (2.2).) Med autentiseringsservern med öppen nyckel finns det fortfarande ett krav på en säker beräkning, som skapar {PKA, A} sras, men endast när en ny öppen nyckel är registrerad, och denna operation kan göras utanför autentiseringsservern och resultatet läggs till i databasen på ett icke säkert sätt. I praktiken misstänker vi dock att genomförandet av autentiseringsservrar inte skulle skilja sig så mycket som vi har antytt, av skäl som behovet av att förhindra korruption av autentiseringsserverns data för öppna nycklar, vilket skulle kunna förhindra kommunikation även om det inte kommer att leda till felaktig autentisering. Observera att kommunikation med servrar kan ske med båda krypteringsteknikerna utan formaliteterna att fastställa vad som vanligtvis kallas en "anslutning". Servern behöver aldrig behålla information om en pågående transaktion från ett meddelande till nästa, så att upprepning eller förlust av protokollpaket inte spelar någon roll. Endast i steg (1.11) behöver något speciellt göras för att säkerställa avsaknaden av anslutningstillstånd. Om denna enkelhet gick förlorad skulle den totala kostnaden för protokollutbyten bli högre. I ett datoriserat postsystem är det omöjligt att vara beroende av interaktion mellan avsändaren och mottagaren under varje leverans. Posten sätts i händerna på en transportmekanism och kan levereras senare när avsändaren inte längre är tillgänglig. Å andra sidan är dubbelriktad autentisering av avsändare och mottagare lika önskvärd för post som för interaktiv kommunikation. En bra utformning av ett postsystem skulle tyda på att posttransportmekanismen inte är en del av säkerhetssystemet, och förslagen här uppfyller detta mål. Vi antar att de efterföljande enskilda blocken av posten är säkert servad på, till exempel, sättet av Kent. Själva förseningen gör det emellertid nödvändigt att vidta särskilda åtgärder för att säkerställa postens tidsmässiga integritet, dvs. att den inte har registrerats av en inkräktare från en tidigare sändning och upprepats. Vi har undvikit att föreslå användning av tidsstampar på annat håll, eftersom det förutsätter en nätomfattande tillförlitlig tidskälla. Här verkar det inte finnas något alternativ till att använda tidsstampar, men det är möjligt att använda dem här utan att kräva en universell klocka. En lämplig teknik är följande. Varje meddelande har i sin kropp en tidsstämpel som anger tidpunkten för att skicka. (En sådan tidsstämpel är en normal del av de flesta brev ändå.) Resolutionen måste vara tillräckligt fri för att inga två meddelanden från samma källa ska ha samma stämpel. Alla mottagare, säger B, har ett register där en post i formuläret {källa, tidsstämpel} lagras för varje post som tas emot. Ett tidsintervall T är associerat med B. T tas som en övre gräns på klockan asynkrony i nätverket och intervallet mellan tiden som posten skickades och tiden för dess ankomst inom B: s säkerhetskontroll, varefter posten inte kan omdirigeras. Ett postobjekt avvisas om antingen dess {källa, tidsstämpel} finns i registret eller dess tidsstämpel föregår nuvarande tid med mer än T. Registret hålls litet genom att kasta poster äldre än T. T kan variera beroende på B:s verksamhet om ett meddelande endast kan komma i hans säkerhetskontroll när han är närvarande. Metoderna för att säkerställa tidsintegritet är identiska i detta fall och kommer inte att upprepas. Vi har två alternativa kurser. Med den första en rubrik skickas som identifierar A till B utan att använda ett handslag: {.4, L {B}S~} pKB Här betecknar A avsändaren och {B} srA möjliggör autentisering av B av avsändarens identitet med hjälp av protokolltransaktioner som på (2.4) och (2.5) (som naturligtvis kan kortklippas genom caching). Jag är en nonce identifierare som används för att ansluta huvudet med den efterföljande meddelandetext som skickas under skydd av PKB, med en tidsstämpel som ovan och med en säker seriation som diskuterats tidigare. Anslutningen mellan rubrik och meddelande som uttryckligen tillhandahålls av I i detta protokoll tillhandahålls implicit av CK när det gäller en konventionell krypteringsalgoritm. Det andra sättet att hantera e-post med hjälp av den öppna nyckelsystemet uppnår den ytterligare funktionen av signatur och beskrivs i nästa avsnitt. Betrakta ett meddelande som används i ett tidigare protokoll: {CK, A} Kn Det här meddelandet har egenskapen att om det sätts i huvudet på e- post krypterad med CK, då hela är selfautenticating både som mottagare och upphovsman även om B spelade ingen roll alls i inställningsprotokollet. De tidigare protokollen är utformade för att autentisera varje kommuniké till den andra. Det är ibland nödvändigt att lägga fram bevis för en tredje part för att ett visst meddelande är exakt det som mottas från en viss avsändare. Detta krav uppfylls genom underskrifter på pappersdokument. Ett vanligt exempel är instruktioner från en överordnad att göra något; mottagaren måste behålla dem som bevis för att hans handlingar var korrekta. För att framställa analogen av undertecknade dokument med meddelanden, är det neo, ~ssary att mottagaren inte kunde ändra en signerad text oupptäckt och att avsändaren inte på ett trovärdigt sätt förneka det. Förmågan att tillhandahålla digitala signaturer beror på att det finns något som upphovsmannen kan göra som mottagaren inte kan. En metod använder en karakteristisk funktion av klartextmeddelandet som ska signeras. Den karakteristiska funktionen måste ha egenskapen att det, med tanke på klartextmeddelandet, funktionen och det resulterande karakteristiska värdet, är svårt att hitta ett annat förnuftigt klartextmeddelande som ger samma karakteristiska värde. Det är också användbart om det karakteristiska värdet är märkbart mindre än klartextmeddelandet. Svårt att invertera transformationer av det slag som används för att skydda lösenord [8] är en funktionsklass med de egenskaper som krävs. När du skickar texten, säg med hjälp av de interaktiva eller post protokoll som beskrivs tidigare, En beräknar det karakteristiska värdet CS. Han begär sedan ett signaturblock från autentiseringsservern: som servern tillhandahåller: Meddelande 3.2 krypteras med A S:s nyckel och är därför endast tillgängligt för A S. Observera att A inte kan validera meddelandet, men om det har störts, kommer B senare inte att kunna validera signaturen, vilket han sannolikt kommer att göra ändå innan han agerar på meddelandet om den innehåller instruktioner som är värda att signeras. A skickar signaturblocket till B efter den text som ska undertecknas. Vid mottagandet dekrypterar B först texten och beräknar dess karakteristiska värde, CSC. B kommunicerar sedan signaturblocket till autentiseringsservern för dekryptering: B, {A, CS} rAs Servern dekrypterar signaturblocket och returnerar dess innehåll till B: {A, CS} KB (3.4) Om den returnerade CS matchar CSC, är huvudmannen som namnges i (3.4) avsändaren av den undertecknade texten. CSC som inte matchar CS kan innebära att någon av stegen (3.1)-(3.3) eller kopplingen mellan signaturblocket och den undertecknade texten har störts. Tidigare upptäckt av vissa typer av störningar är möjlig genom att använda nonce-identifierare i transaktioner (3.1)-(3.2) och (3.3)-(3.4). Om B vill behålla texten som bevis behöver han bara behålla textblocket 998 och själva texten. Som svar på en utmaning skulle B skapa texten och signaturblocket för en skiljedomare som skulle gå igenom kommunikationen av steg (3.3) och (3.4). Förlängningen av protokoll 3 till fallet med flera autentiseringsservrar är enkel. Det är möjligt att tillhandahålla signerad text med ett offentligt nyckelsystem med hjälp av en karakteristisk funktion enligt ovan. Det allmänna nyckelsystemet ger dock en annan, mer elegant metod som först beskrevs av Diffie och Hellman. De första stegen är för A att t'md ut B: s öppna nyckel från cache eller server, som tidigare. De på varandra följande textblocken, raderade för tidsintegritet, är dubbelt krypterade: { {text- block}SKA} PrB B kan utföra den första dekrypteringen på grund av att du känner SKB, och den andra på grund av att du kan ta reda på PKA genom protokollutbyte eller från en cache. Det finns ett behov av att huvudinformationen på ett säkert sätt förmedlar upphovsmannens identitet så att PKA kan sökas på rätt sätt. B är inte i stånd att ändra innehållet, eftersom SKA inte är tillgänglig för honom. När den utmanas utför B helt enkelt den yttre dekrypteringen på hela texten och skickar resultatet till skiljedomaren som kan använda PKA för att avsluta jobbet. Lägg märke till att en skiljedomares förmåga att utföra sin funktion tycks bero på att A inte ändrar sitt nyckelpar. Eftersom sådana ändringar måste tillåtas som det enda svaret på en nyckel som äventyras, är det nödvändigt att autentiseringsservern behåller en post av de gamla allmänna nycklarna till sina huvudansvariga och tidpunkten för ändringen, och att undertecknade texter innehåller den tid de undertecknades. En fördel med signaturprotokollet för konventionella krypteringsalgoritmer är att en autentiseringsserver bara behöver behålla ett register över ändringar av sin egen nyckel för att garantera korrekt framtida skiljeförfarande. Vi drar slutsatsen från denna studie att protokoll som använder publika kryptosystem och använder konventionella krypteringsalgoritmer är slående lika. Antalet protokollmeddelanden som utbyts är mycket jämförbart, och systemet med allmänna nycklar har en märkbar fördel endast när det gäller undertecknade meddelanden. Liksom i många nätverksapplikationer för datorer är caching viktigt för att minska transaktioner med uppslagsservrar; detta gäller i synnerhet systemet med allmänna nycklar. I det systemet märkte vi också att det fanns ett krav på kryptering av offentliga data (autentiseringsserverns databas) för att säkerställa dess integritet. En konsekvens av likheten mellan protokoll är att alla användbara tricks för det konventionella systemet har analoger i det offentliga nyckelsystemet, även om de kanske inte behövs. På grund av detta kan det finnas utrymme för hybridsystem där en öppen metod från december 1978 av volym 21 ACM nummer 12 kan användas för att fastställa en autentiserad anslutning som ska användas konventionellt. De inneboende säkerhetskraven för en autentiseringsserver med öppen nyckel är lättare att uppfylla än de för en konventionell server, men en fullständig utvärdering av systemproblemen vid genomförandet av en sådan server i ett verkligt system, och behovet av att behålla ett säkert register över gamla offentliga nycklar för att garantera framtida korrekt skiljedom av gamla signaturer kan minimera denna fördel. Vi drar slutsatsen att valet av teknik bör baseras på själva krypteringsteknikens ekonomi och kryptografiska styrka, snarare än på dess effekter på protokollets komplexitet. Slutligen, protokoll som de som utvecklats här är benägna att extremt subtila fel som sannolikt inte kommer att upptäckas i normal drift. Behovet av teknik för att kontrollera att sådana protokoll är korrekta är stort, och vi uppmuntrar dem som är intresserade av sådana problem att överväga detta område. Erkännanden. Vi står i tacksamhetsskuld till ett antal människor som har läst utkast till denna uppsats och gjort noggranna och hjälpsamma kommentarer, särskilt: Peter Denning, Stockton Gaines, Jim Gray, Steve Kent, Gerry Popek, Ron Rivest, Jerry Saltzer och Robin Walker.  Jayadev Misra En ny algoritm presenteras för att hitta aH primes mellan 2 och n. Algoritmen utförs i tid proportionell till n (förutsatt att multiplikation av heltal inte större än n kan utföras i enhetstid). Metoden har samma aritmetiska komplexitet som algoritmen som presenterades av Mairson [6], men vår version är kanske enklare och mer elegant. Det är också lätt utökad för att hitta den främsta factorizationen av a / / / heltal mellan 2 och n i tid proportionellt till n.
Till exempel presenterade REF ett allmänt använt protokoll för att autentisera och initiera kommunikation mellan två maskiner.
Using encryption for authentication in large networks of computers
{'venue': 'CACM', 'journal': None, 'mag_field_of_study': ['Computer Science']}