XADM: Hoe Secure Sockets Layer Works

Vertaalde artikelen Vertaalde artikelen
Artikel ID: 245152 - Bekijk de producten waarop dit artikel van toepassing is.
Alles uitklappen | Alles samenvouwen

Op deze pagina

Samenvatting

Dit artikel biedt een overzicht van de werking van SSL (Secure Sockets Layer).

Meer informatie

Een inleiding tot sleutelcryptografie

Openbare-sleutelcryptografie Rivest-Shamir-Adleman (RSA) wordt veel gebruikt voor verificatie en codering in de computerindustrie. Netscape heeft een licentie RSA cryptografie met openbare sleutels van RSA Data Security, Inc. voor gebruik in haar producten specifiek voor verificatie.

Codering met openbare sleutel is een techniek die een paar asymmetrische sleutels worden gebruikt voor codering en decoder ing. Elk paar sleutels bestaat uit een openbare en een persoonlijke sleutel. De openbare sleutel wordt gemaakt wanneer het publiek alom wordt gedistribueerd. De persoonlijke sleutel wordt nooit verspreid; het is altijd geheim gehouden.

Gegevens die zijn gecodeerd met de openbare sleutel, kunnen alleen met de persoonlijke sleutel worden ontsleuteld. Daarentegen kunnen gegevens die zijn gecodeerd met de persoonlijke sleutel worden ontsleuteld met de openbare sleutel. Deze asymmetrie is de eigenschap waardoor cryptografie met openbare sleutels zo handig.

Sleutelcryptografie met openbare voor verificatie gebruiken

Verificatie is het proces van de identiteit te verifiëren zodat één entiteit of de identiteit van een andere entiteit. In de volgende voorbeelden gebruiken gebruiker a en gebruiker b openbare-sleutelcryptografie gebruiker b identiteit verifiëren. De volgende notatie geeft aan dat een item is gecodeerd of gedecodeerd met behulp van cryptografie sleutel
{iets}sleutel
waarietseen beschrijving van het item dat is gecodeerd of gedecodeerd, ensleutelis de sleutel die wordt gebruikt voor het coderen of decoderen van dat item.

In het volgende voorbeeld heeft een gebruiker wil verifiëren van gebruiker b gebruiker b een paar sleutels, één openbare en één particuliere. Gebruiker b vermeldt de openbare sleutel van gebruiker A (dit wordt besproken in de sectie 'Overdracht uit openbare sleutels' van dit artikel). Gebruiker a genereert een willekeurig bericht en verzendt dit naar de gebruiker b als volgt:
A-> Brandom_message
Gebruiker b de persoonlijke sleutel wordt gebruikt om willekeurige bericht te coderen en retourneert de gecodeerde versie aan een gebruiker:
B-> A {random_message}User_B's_private_key
User a ontvangt dit bericht en wordt gedecodeerd met de openbare sleutel die gebruiker b eerder gepubliceerd. Gebruiker a vergelijken de gedecodeerde bericht het bericht dat gebruikers een oorspronkelijk verzonden naar gebruiker B; Als de berichten overeenkomen, weet gebruiker a dat later bericht afkomstig van gebruiker b is omdat iemand anders waarschijnlijk de persoonlijke sleutel van gebruiker b weet zou en dus zou niet goed coderen het willekeurig bericht verzenden naar gebruiker a.

Aanvullende overwegingen

Tenzij u precies wat u versleutelt weet, is het nooit een goed idee om iets met de persoonlijke sleutel te versleutelen en vervolgens verzenden naar iemand anders. Dit komt doordat u kunt verantwoordelijk worden gehouden voor de gecodeerde waarde (Onthoud, alleen u de codering uitvoeren kunt omdat er alleen voor de persoonlijke sleutel).

Hierdoor wordt in dit voorbeeld, in plaats van het oorspronkelijke bericht te coderen die gebruiker verzonden, een gebruiker b wordt message digest en codeert die message digest. Een distributie lijst is afgeleid van het oorspronkelijke bericht willekeurig en heeft de volgende nuttige eigenschappen:
  • De samenvatting is moeilijk om terug te draaien. Iemand die probeert te imiteren gebruiker b kan niet de samenvatting van het oorspronkelijke bericht bepalen.
  • Een impersonator heeft moeite om het zoeken naar een ander bericht dat op dezelfde samenvattings waarde berekend.
Gebruiker b wordt beveiligd door een samenvatting. Gebruiker b berekent de samenvatting van het bericht willekeurige gebruiker a verzonden en wordt het resultaat vervolgens gecodeerd. Gebruiker b stuurt gecodeerde digest terug naar gebruiker a gebruiker a kan dezelfde digest berekenen en verifiëren van gebruiker b door gebruiker b berichten decoderen en de waarden te vergelijken.

Gegevens oorsprong verificatie

De techniek die wordt beschreven in de sectie ''Aanvullende overwegingen' in dit artikel wordt een digitale handtekening genoemd. Deze techniek vereist dat gebruiker b ondertekenen een bericht dat gebruikers een gegenereerd; Dit is bijna als gevaarlijk voor de gebruiker b als het coderen van een willekeurige waarde die afkomstig van gebruiker a zijn. Dus moet dit voorbeeld verificatieprotocol één stap veilig; Gebruiker b moet afkomstig zijn van sommige (of alle) van de gegevens als volgt:
A-> B B-> een Hallo, bent u gebruiker B? Gebruiker a gebruiker B {Is ditSamenvatting[Gebruiker A Is gebruiker B]}User_B's_private_key
Wanneer dit protocol wordt gebruikt door gebruiker B, gebruiker b weet welk bericht wordt verzonden naar een gebruiker en zo gebruiker b het bericht veilig kunt ondertekenen. Gebruiker b verzendt de niet gecodeerde versie van het bericht eerst "gebruiker A Is gebruiker B ' en gebruiker b verzendt vervolgens de versie ontsloten gecodeerd. Gebruiker a kan gemakkelijk controleren dat gebruiker b gebruiker b wordt en gebruiker b niet hoeft ondertekenen niets die niet van oorsprong met 'Gebruiker b.

Openbare sleutels uitdelen.

Hoe kan een gebruiker uitdelen een openbare sleutel op een veilige manier? Het volgende is een voorbeeld van verificatieprotocol voor gebruiker b:
A-> B B-> EEN A-> B B-> A
Hi, Hallo ik gebruiker bUser_B's_public_keybewijzen dat deze gebruiker A, deze
Gebruiker B {Samenvatting[Gebruiker A Is gebruiker B]}User_B's_private_key
Als dit protocol wordt gebruikt, kan iedereen imiteren gebruiker b. Alle iemand anders is moet een openbare en persoonlijke sleutel. Iemand anders kan liggen aan een gebruiker en gebruiker b imiteren door iemand anders in eigen openbare sleutel in plaats van de openbare sleutel van gebruiker B. Vervolgens bewijst het iemand anders"" gebruiker b de iemand anders is door iets te coderen met behulp van de persoonlijke sleutel van de iemand anders, en een gebruiker kan niet zien de iemand anders wordt gebruiker b.

U lost dit probleem, heeft de communautaire normen uitgevonden een object een certificaat genoemd. Een certificaat bevat de volgende informatie:
  • De naam van de uitgever van het certificaat.
  • De dienst waarvoor het certificaat wordt uitgegeven (ook bekend als het onderwerp).
  • De openbare sleutel van de certificaat houder.
  • Sommige tijds tempels.
Het certificaat wordt ondertekend met de persoonlijke sleutel van de uitgever van het certificaat. Iedereen weet dat de openbare sleutel van de uitgever van het certificaat (dat wil zeggen, de uitgever van het certificaat heeft ook een certificaat). Certificaten zijn een standaard methode voor een openbare sleutel bindt aan een naam.

Als certificaat technologie wordt gebruikt, kan iedereen van gebruiker b onderzoeken certificaat als het certificaat is vervalst. Als gebruiker b strakke controle over de persoonlijke sleutel blijft en gebruiker b daadwerkelijk de certificaat verkrijgt, is de technologie van het certificaat is beveiligd. Dit is het gewijzigde protocol met deze techniek:
A-> B B-> een A-> B B-> een hello Hi, ik ben gebruiker bUser_B's_certificatebewijzen
Deze gebruiker A, dit wordt gebruiker B {Samenvatting[Gebruiker A Is gebruiker B]}User_B's_private_key
Wanneer gebruiker a gebruiker b eerste bericht ontvangt, kan gebruiker a controleert u het certificaat, controleert de handtekening (zoals in het vorige voorbeeld, met een samenvatting en openbare sleutel decoderen), en controleer het onderwerp (gebruiker b naam) en ziet dat dit inderdaad gebruiker b gebruiker a kan klik vertrouwen dat de openbare sleutel van gebruiker b publiek sleutel en gebruiker b identiteits bewijs kunnen vragen.

Gebruiker b doorlopen hetzelfde proces zoals beschreven in het vorige voorbeeld door een bericht overzicht ontwerpen en vervolgens reageren op een gebruiker met een ondertekende versie van de samenvatting. Gebruiker a gebruiker b kunt controleren met behulp van de openbare sleutel van het certificaat en het resultaat controleren message digest.

Een persoon die willen verstoren beveiligde communicatie (in dit voorbeeld wordt een gebruiker C) kunt maken in het volgende scenario om te proberen te doen:
A-> C C-> een A-> C C-> een hello Hi, ik ben gebruiker bUser_B's_certificatebewijzen
het????
Echter gebruiker c niet voldoen aan een gebruiker in het laatste bericht. Gebruiker c geen gebruiker b persoonlijke sleutel, zodat de gebruiker c geen maken om een bericht dat gebruikers een zal geloven afkomstig is van gebruiker b.

Een geheim uitwisselen

Nadat de gebruiker een geverifieerde gebruiker B, gebruiker a gebruiker b een bericht kunt verzenden dat alleen gebruiker b als volgt kunnen decoderen
A-> B {geheim}User_B's_public_key
waar de enige manier om vast te stellen degeheimis het bovenstaande bericht decoderen met de persoonlijke sleutel van gebruiker B. Uitwisselen van een geheim is een andere krachtige manier gebruik van cryptografie met openbare sleutels. Zelfs als de communicatie tussen een gebruiker en gebruiker b waar genomen wordt, kan niemand maar gebruiker b de geheime gegevens bepalen.

Deze techniek internetbeveiliging versterkt door het geheim als een andere toets, maar in dit geval is een sleutel voor een symmetrische cryptografische algoritme, zoals Data Encryption Standard (DES), RC4 of IDEE. Gebruiker a kent het geheim, omdat een gebruiker het geheim gegenereerd voordat het geheim verzenden naar gebruiker b gebruiker b weet omdat gebruiker b de persoonlijke sleutel en de gebruiker van een bericht kan decoderen. Omdat zowel gebruiker a gebruiker b het geheim weet, kan beginnen een symmetrische cipher algoritme en verzend de berichten die zijn gecodeerd met de symmetrische cipher algoritme. Het volgende is een herziene protocol dat deze techniek gebruikt:
A-> B B-> een A-> B B-> een A-> B B-> een hello Hi, ik ben gebruiker bUser_B's_certificate
Deze gebruiker A, dit wordt gebruiker B {bewijzenSamenvatting[Gebruiker A Is gebruiker B]}User_B's_private_key
OK hier is een geheime {gebruiker bgeheim}User_B's_public_key{some_message}secret_key
De methode die wordt gebruikt om te berekenensecret_keyis het protocol dat wordt gedefinieerd, maarsecret_keyDit kan gewoon een kopie van het geheim.

Storings beveiliging

Zelfs als alle voorgaande technieken worden gebruikt, mogelijk een persoon die wil verstoren beveiligde communicatie (gebruiker C) kunnen doen. Hoewel gebruikers c kan niet het geheim dat gebruiker a en gebruiker b hebben uitgewisseld ontdekken, gebruiker c kan verstoren hun conversatie door nieuwe ordening (of garbling) de geheime informatie. Bijvoorbeeld als gebruiker c is zit tussen gebruiker a en b van de gebruiker, kunt gebruiker c de meeste gegevens heen en ongewijzigd worden doorgegeven, maar garble bepaalde berichten (dit is gemakkelijk voor gebruikers c te doen, omdat de gebruiker c weet het protocol die gebruiker a en b van de gebruiker gebruikt om te communiceren):
A-> C C-> B B-> C C-> EEN A-> C C-> B B-> C C EEN A-> C C-> B B C C->-> A->
Hallo Hallo Hi, ik ben gebruiker bUser_B's_certificateHallo, ben ik gebruiker b
User_B's_certificateaantonen dat deze gebruiker a aantonen, Is dit de gebruiker B {Samenvatting[Gebruiker A
Dit Is gebruiker B]}User_B's_private_keyGebruiker a gebruiker B {Is ditSamenvatting[Gebruiker A, Is dit
Gebruiker B]}User_B's_private_keyOK hier is een geheime {gebruiker bgeheim}User_B's_public_key
OK hier is een geheime {gebruiker bgeheim}User_B's_public_key{some_message}secret_key
Garble [{some_message}secret_key]
Gebruiker c geeft de gegevens ongewijzigd totdat gebruiker a en b gebruikers een geheim delen. Vervolgens garbles gebruiker c gebruiker b bericht aan gebruiker a. Gebruiker a vertrouwens relaties dat gebruiker a gebruiker b kunnen op dit moment denkt de vervormde bericht en probeer te ondernemen. Houd er rekening mee dat gebruikers c niet weet het geheim wat; C alle gebruikers kunnen doen schade zijn de gegevens die zijn gecodeerd met de geheime sleutel. Afhankelijk van het protocol, gebruiker c produceert een geldig bericht niet, maar gebruikers c kan krijgen geluk en produceren een geldig bericht.

Om te voorkomen dat dit soort schade, introduceren gebruiker a en b van de gebruiker een bericht verificatie code in hun protocol. Bericht verificatie code is een blok gegevens dat wordt berekend met behulp van een geheime en sommige verzonden gegevens. De hierboven beschreven digest-algoritme is de juiste eigenschappen voor het bouwen van een bericht verificatie code functie die verdedigen tegen gebruiker c kan:
message_authentication_code:=Samenvatting[some_message,geheim]
Omdat het geheim gebruiker c niet kent, kan de juiste waarde voor de samenvatting gebruiker c niet berekenen. Zelfs als gebruiker c garbles willekeurig berichten, is de kans van slagen als er een grote hoeveelheid gegevens samenvatting klein. Bijvoorbeeld met behulp van MD5 (een goede cryptografische digest-algoritme uitgevonden door RSA), gebruiker a en gebruiker B 128-bits bericht verificatie code waarden met hun berichten kunt verzenden. De kans dat de juiste message authentication code raden gebruikers c zijn 1 in 18,446,744,073,709,551,616. Voor alle praktische doeleinden, kan geen gebruiker c raden het juiste bericht verificatie code.

Dit is het voorbeeld-protocol opnieuw herzien om deze techniek te gebruiken:
A-> B B-> een A-> B B-> een hello Hi, ik ben gebruiker bUser_B's_certificatebewijzen
Deze gebruiker A, dit wordt gebruiker B {Samenvatting[Gebruiker A Is gebruiker B]}User_B's_private_keyOK
Hier is een geheime {gebruiker bgeheim}User_B's_public_key{some_message,message_authentication_code}secret_key
Gebruiker c kan worden garble berichten, maar de bericht verificatie code berekeningen blijkt dat de berichten niet afkomstig van gebruiker b gebruiker a of gebruiker b kunt ontdekken de waarde onjuist bericht verificatie code en communicatie te stoppen. C gebruiker imiteren langer gebruiker b.

Eigenschappen

Artikel ID: 245152 - Laatste beoordeling: dinsdag 1 maart 2011 - Wijziging: 2.0
De informatie in dit artikel is van toepassing op:
  • Microsoft Exchange Server 4.0 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
  • Microsoft Exchange Server 5.5 Standard Edition
Trefwoorden: 
kbinfo kbmt KB245152 KbMtnl
Automatisch vertaald artikel
BELANGRIJK: Dit artikel is vertaald door de vertaalmachine software van Microsoft in plaats van door een professionele vertaler. Microsoft biedt u professioneel vertaalde artikelen en artikelen vertaald door de vertaalmachine, zodat u toegang heeft tot al onze knowledge base artikelen in uw eigen taal. Artikelen vertaald door de vertaalmachine zijn niet altijd perfect vertaald. Deze artikelen kunnen fouten bevatten in de vocabulaire, zinsopbouw en grammatica en kunnen lijken op hoe een anderstalige de taal spreekt en schrijft. Microsoft is niet verantwoordelijk voor onnauwkeurigheden, fouten en schade ontstaan door een incorrecte vertaling van de content of het gebruik ervan door onze klanten. Microsoft past continue de kwaliteit van de vertaalmachine software aan door deze te updaten.
De Engelstalige versie van dit artikel is de volgende:245152
Vrijwaring inhoud KB-artikelen over niet langer ondersteunde producten
Dit artikel heeft betrekking op producten waarvoor Microsoft geen ondersteuning meer biedt. Daarom wordt dit artikel alleen in de huidige vorm aangeboden en wordt het niet meer bijgewerkt.

Geef ons feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com