XADM: Nasıl Güvenli Yuva Katmanı Works

Makale çevirileri Makale çevirileri
Makale numarası: 245152 - Bu makalenin geçerli olduğu ürünleri görün.
Hepsini aç | Hepsini kapa

Bu Sayfada

Özet

Bu makale, Güvenli Yuva Katmanı (SSL) çalışma şekli hakkında genel bir bakış sağlar.

Daha fazla bilgi

Anahtar şifrelemesi Giriº

Rivest-Shamir-Adleman (RSA) ortak anahtar şifrelemesini kimlik doğrulama ve şifreleme bilgisayar endüstrisindeki yaygın olarak kullanılır. Netscape, RSA ortak anahtar şifrelemesi RSA Data Security ınc.'den, ürünler, özel olarak kimlik doğrulaması kullanmak için lisans.

Ortak anahtar şifrelemesi asimetrik anahtar çifti şifrelenmesi ve şifrelerin çözülmesi için kullandığı bir tekniktir. Her anahtar çiftinin bir ortak anahtar ve özel anahtar oluşur. Ortak anahtar yapılır, ortak, yaygın olarak dağıtılabilir. Özel anahtar hiç dağıtıldığı; Bu, her zaman gizli tutulur.

Ortak anahtarla şifrelenen verileri, yalnızca özel anahtarla çözülebilecek. Tersi durumda, özel anahtarla şifrelenen verileri, yalnızca ortak anahtarla çözülebilecek. Bu ortalaması asimetri belirtir ortak anahtar şifrelemesi hale getirir böylece yararlı bir özelliktir.

Kimlik doğrulama için ortak anahtar şifrelemesi kullanma

Kimlik doğrulaması, bir varlık başka bir varlığa kimliğini emin olun, kimlik doğrulama işlemi kullanılır. Aşağıdaki örneklerde, kullanıcı A ve kullanıcı B, kullanıcı B'NIN kimliğini doğrulamak için ortak anahtar şifrelemesi kullanır. Aşağıdaki gösterimde, bir öğe olduğunu belirtir veya şifreli anahtar şifrelemesi'ni kullanarak, şifresi
{something}key
Burada something şifrelenmiş veya şifresi maddenin ve key açıklamasıdır şifrelemek veya o öğenin şifresini çözmek için kullanılan anahtardır.

Aşağıdaki örnekte, kullanıcı A isterse, kullanıcı B'nin kullanıcı B doğrulamakta anahtarlar, bir ortak ve bir özel çiftinin vardır. B kullanıcısı, kullanıcı A (Bu "Etme giden ortak anahtarları" bölümüne, bu makalenin'de açıklanan) için ortak anahtar açıklamaktadır. A kullanıcısı, rasgele bir ileti oluşturur ve kullanıcı B gibi gönderir:
a, b->random_message
B kullanıcısı rasgele bir iletiyi şifrelemek için özel anahtarı kullanır ve kullanıcı A: ile şifrelenmiş sürümü verir
b a-> {}random_message.}User_B's_private_key
A kullanıcısı, bu iletiyi alır ve kullanıcı B'ı daha önce yayımlanmış ortak anahtarını kullanarak şifresini çözer. A kullanıcısı karşılaştırır iletileri uyuyorsa, özgün kullanıcı B; gönderilen BIR kullanıcı, kullanıcı A bilebileceği sonraki iletiyi, kullanıcı B'DEN gelen kullanıcı B'NIN bir özel anahtar ve bunu bir imposter presumably bilmez, çünkü bir iletinin şifresi çözülmüş iletiyle düzgün a kullanıcıya göndermek için rasgele bir iletiyi şifrelemek veremeyebilir

Ek konuları

Tam olarak ne, şifreleme bilmiyorsanız, hiç bir şey özel anahtarınızın şifreleyip birine göndermek yerinde olur. Bunun nedeni, size şifrelenmiş değeri sorumlu tutulabilir (özel anahtarı olmadığından, şifreleme gerçekleştirebileceğiniz yalnızca unutmayın).

Bu yüzden özgün iletinin, bu kullanıcı, gönderilen BIR şifreleme yerine bu örnekte, kullanıcı B bir ileti özeti oluşturur ve bu ileti özeti olarak şifreler. Bir ileti özeti, özgün rasgele iletisinden türetilen ve yararlı aşağıdaki özelliklere sahiptir:
  • Özeti ters zordur. Kullanıcı B kimliğine bürünmek için çalışan birisi, özgün özeti iletiden belirleyemiyor.
  • Bir impersonator aynı Özet değeri hesaplar farklı bir ileti bulma zorluk bulunmaktadır.
B kullanıcısı bir özeti'ni kullanarak korunmuştur. B kullanıcısı bu kullanıcı için gönderilen BIR iletinin rasgele özet hesaplar ve sonra sonucu şifreler. B kullanıcısı gönderirse, şifrelenmiş özeti yedeklemek için kullanıcı A Kullanıcı A olabilir, aynı Özet hesaplamak ve kullanıcı B, kullanıcı B'NIN iletinin şifresini çözmek ve değerleri karşılaştırarak kimlik doğrulaması.

Kaynak veri için kimlik doğrulaması

Bu makalenin "Ek konuları" bölümünde açıklanan teknik bir dijital imza olarak bilinir. Bu teknik, kullanıcı B, bu kullanıcı A oluşturulan bir iletiyi imzalamak gerektirir; bu kullanıcı a</a0> ile oluşturulan rasgele bir değer şifreleme olarak için kullanıcı B yaklaşık olarak tehlikelidir Sonuç olarak, bu <a0>Örnek</a0> kimlik doğrulama protokolü, güvenli için bir daha fazla adım gerekir; kullanıcı B gibi (veya tümünün) veri kaynağı gerekiyor:
B B BIR var sayılma->-> A olduğundan, kullanıcı B? A kullanıcısı, <a1>kullanıcı</a1> B {} bu işdigestB] [<a1>kullanıcı</a1> A, bu kullanıcı mı} User_B's_private_key
Kullanıcı B bu ?leti?im Kural?'n? kullan?r, hangi iletiyi, kullanıcı A gönderiliyor kullanıcı B biliyor ve böylece kullanıcı B iletiyi güvenle imzalayabilirsiniz. B kullanıcısı iletiyi şifresiz sürümünü ilk olarak, gönderen "Kullanıcı A, bu kullanıcı B, iş" ve kullanıcı B digested şifreli sürümünü gönderir. A kullanıcısı, kullanıcı B kullanıcı B ise ve kullanıcı B, kullanıcı b ile değiller imzalamak gereken kolayca doğrulayabilirsiniz

Ortak anahtarları teslim etme

Nasıl bir kullanıcı güvenli bir şekilde genel bir anahtar teslim? Örnek kimlik doğrulama iletişim kuralı için kullanıcı B: aşağıdadır
b b b b a->-> BİR a->-> a
<a1>Başlangıç</a1>, yüksek kullanıcı B olduğum User_B's_public_key, kullanıcı A, bu iş kanıtlar
{digest [Kullanıcı A, bu iş kullanıcı B]} B kullanıcısı User_B's_private_key
Bu protokolü kullanılırsa, kullanıcı B'nin herkes bürünebilir Bir imposter gerektiren bir ortak ve özel anahtardır. Bir imposter Kullanıcı A kalan ve imposter'ın kendi ortak anahtar yerine, kullanıcı B'NIN ortak anahtarı sağlayarak kullanıcı B temsil eder. Sonra imposter "bir şey imposter'ın özel anahtarla şifreleyerek, kullanıcı B the imposter açık ve kullanıcı A the imposter, kullanıcı B'nin olmadığını söylemek edemiyor kanıtlar"

Bu sorunu çözmek için <a0></a0>, topluluk standartlarını sertifika olarak adlandırılan bir nesne invented. Sertifika, aşağıdaki bilgileri içerir:
  • Sertifikayı verenin adı.
  • Kendisi için sertifika (konu olarak da bilinir) verilen varlık.
  • Özne genel anahtarı.
  • Bazı zaman damgalarını.
Sertifika, sertifikayı verenin özel anahtarını kullanarak imzalanır. Herkes sertifika verenin ortak anahtarı bilen (diğer bir deyişle, sertifikayı verenin de sertifika vardır). Sertifika ortak anahtarı için bir ad bağlamak için standart bir yöntemdir.

Sertifika teknolojisi kullanılırsa, kullanıcı B'NIN everyone sınayabilir sertifikayı sahte görmek için sertifika. Kullanıcı B sıkı denetim, özel anahtarı korur ve kullanıcı B aslında, sertifikayı alır, sertifika teknolojisi güvenlidir. Bu yöntem kullanılarak değiştirilmiş iletişim kuralı şudur:
B B B B-> BIR A->-> A-> yüksek BIR var sayılma, kullanıcı B 'mUser_B's_certificate kanıtlar
Bu kullanıcı A, bu iş kullanıcı B {digest [Kullanıcı A, bu iş kullanıcı B]} User_B's_private_key
BIR kullanıcı, kullanıcı B'NIN ilk iletiyi, kullanıcı A can aldığında sertifika inceleyin (olarak bir özetini ve ortak anahtar şifre çözme kullanarak önceki örnekte,), imzayı denetlemek ve sonra konu (yani, kullanıcı B'NIN adı) denetleyin ve, aslında kullanıcı B Kullanıcı A can sonra ortak anahtarı, kullanıcı B'NIN ortak anahtarı olduğunu güven olduğunu görmek ve kullanıcı B'NIN kimlik kanıtı olarak isteyebilirler.

B kullanıcısı ile aynı işlem, önceki örnekte, bir ileti özeti tasarlama ve sonra kullanıcı A özeti imzalı bir sürümünü yanıt özetlendiği gibi gider. A kullanıcısı, kullanıcı B'NIN doğrulayabilirsiniz ortak anahtardan bir sertifika kullanarak ve sonucu denetleme, ileti özeti.

Bunu yapmak için aşağıdaki senaryoyu, güvenli iletişim (Bu örnekte, kullanıcı C) ile kesintiye istediğiniz kişi oluşturabilirsiniz:
BIR A C C->-> C C-> A-> yüksek BIR var sayılma, kullanıcı B 'mUser_B's_certificate kanıtlar
Bunu????
Ancak, kullanıcı C, kullanıcı A son iletinin gerçekleştiremiyor. <a1>Kullanıcı</a1> C, kullanıcı B'NIN özel anahtarı yok, bu yüzden, kullanıcı C Kullanıcı A kullanıcı B ' gelen düşünen bir ileti oluşturmak olamaz

Bir gizli değişimi

BIR kullanıcı, kullanıcı B doğrulanmış sonra kullanıcı A kullanıcı B yalnızca kullanıcı B gibi çözebildiği bir ileti göndermek için
a, b-> {}secret.}User_B's_public_key
Yukarıdaki iletinin kullanıcı B'NIN özel anahtarla şifresi çözülüyor tarafından secret belirlemek için tek yol olduğu. Bir gizli kod dizesi değiş tokuş ortak anahtar şifrelemesi kullanan başka bir güçlü yoludur. Kullanıcı A ve kullanıcı B arasındaki iletişimi gözlenen olsa bile, kullanıcı B ancak hiç kimse gizli bilgileri belirleyebilirsiniz.

Bu teknik, başka bir anahtar olarak gizli kod dizesini kullanarak ınternet güvenliği strengthens, ancak bu durumda, bir veri şifreleme standardı (DES), RC4 veya FIKIR gibi bir simetrik şifreleme algoritması anahtarıdır. A kullanıcısı, kullanıcı B özel anahtarı olan ve kullanıcı A'ın iletinin şifresini çözebilecekler kullanıcı b kullanıcı B göndermeden parolayı biliyor önce kullanıcı A gizli üretmediğinden gizli bilir. Kullanıcı A hem de kullanıcı B parolayı bilmek için bunlar hem bir simetrik şifreleme algoritması'nı başlatmak ve simetrik şifreleme algoritması ile şifrelenmiş iletileri gönderin. Bu tekniği kullanan gözden geçirilmiş bir iletişim kuralı şudur:
B B-> A, B B B B, yüksek BIR var sayılma->-> BIR A->-> BIR A->, kullanıcı B 'mUser_B's_certificate
Bu, kullanıcı A, bu iş kullanıcı B {digest [Kullanıcı A, bu iş kullanıcı B]} kanıtlar User_B's_private_key
Tamam kullanıcı B, bir gizli kod dizesi {secret} işte User_B's_public_keysecret_key {some_message.}
Yalnızca secret_key tanımlanmakta kadar kuralıdır hesaplamak için kullanılan yöntem, ancak secret_key gizli bir kopyası olabilir.

Güvenlik girişim

Kullanılan tüm önceki teknikleri olsa bile, güvenli iletişim (kullanıcı C) işlemlerini isteyen bir kişi bunun mümkün olabilir. Kullanıcı C, kullanıcı A ve kullanıcı B değiştirilen bir gizli kod dizesi bulamaz olsa da, kullanıcı C ile konuşma re-arranging göre engelleyebilir (veya garbling) gizli bilgi. Örneğin, kullanıcı C, kullanıcı A ve kullanıcı B arasında doğrudan, kullanıcı C ve geriye değiştirmeden bilgilerin çoğunu geçmesi, ancak (Bu kullanıcı için C kullanıcı C iletişim kuralı, kullanıcı A bilir ve iletişim kurmak için kullanarak kullanıcı B yapmak kolaydır), belirli iletileri garble:
BİR c c, b b <a1>c</a1> c->-> BİR BİR c c, b b <a1>c</a1> c->-> BİR BİR c c, b b <a1>c</a1> c->-> BİR->->->->->->
<a1>Başlangıç</a1> yüksek Merhaba, kullanıcı B olduğum User_B's_certificate yüksek, kullanıcı B 'm
User_B's_certificateBunu kanıtlar, BIR kullanıcı, bu kullanıcı {digest [Kullanıcı A, B iş kanıtlar.
Bu iş kullanıcı B]} User_B's_private_key Kullanıcı A, bu iş kullanıcı B {digest [Kullanıcı A, bu iş
B kullanıcısı]} User_B's_private_key kullanıcı B ok, bir gizli kod dizesi {secret} işte User_B's_public_key
Tamam kullanıcı B, bir gizli kod dizesi {secret} işte User_B's_public_keysecret_key {some_message.}
[{some_message} secret_key] garble
<a1>Kullanıcı</a1> C, kullanıcı A ve kullanıcı B bir gizli paylaşım kadar değişiklik yapılmaksızın veri geçirir. Sonra kullanıcı C, kullanıcı B'NIN iletiye kullanıcı a garbles Bu noktada, kullanıcı A güvenleri kullanıcı B, böylece kullanıcı A, bozuk ileti inanıyorsanız ve üzerinde çalışmak deneyin. Not kullanıcı C parolayı biliyor; tüm kullanıcı C yapmak için gizli anahtarla şifrelenen verileri zarar görmüş olduğu. Iletişim kuralı, bağlı kullanıcı C geçerli iletiye neden olabilir, ancak kullanıcı C şanslı almak ve geçerli bir ileti oluşturur.

Bu tür bir hasarı önlemek için <a0></a0>, <a1>kullanıcı</a1> A ve kullanıcı B bir ileti doğrulama kodu içinde bir iletişim kuralı neden olabilir. Bir ileti doğrulama kodu, gizli ve bazı aktarılan veri kullanılarak hesaplanan veri bir parçasıdır. Yukarıda açıklanan özeti algoritması yalnızca kullanıcı C: karşı savunmak bir ileti kimlik doğrulama kodu işlevi oluşturmak için doğru özelliklere sahiptir...
message_authentication_code: digest [some_message, secret] =
Kullanıcı C parolayı bilmek için kullanıcı C özeti doğru değeri hesaplanamaz. Kullanıcı C, rasgele iletileri garbles olsa bile, büyük miktarda bir Özet veri ise başarı şansını küçüktür. Örneğin, MD5 kullanarak (RSA tarafından invented bir iyi şifreleme özeti algoritması), kullanıcı A ve kullanıcı B 128-bit ileti kimlik doğrulama kodu değerleri, iletiler gönderebilirsiniz. Odds kullanıcı doğru ileti doğrulama kodu tahmin C, yaklaşık 1, 18,446,744,073,709,551,616 ' dir. Tüm pratik amaçlarla, doğru ileti doğrulama kodu kullanıcı C tahmin edemiyor.

Bu yöntemi kullanmak üzere yeniden düzenlendi örnek protokol şudur:
B B B B-> BIR A->-> A-> yüksek BIR var sayılma, kullanıcı B 'mUser_B's_certificate kanıtlar
Bu, BIR kullanıcı bu iş kullanıcı B {digest [Kullanıcı A, bu iş kullanıcı B]} User_B's_private_key Tamam
Kullanıcı B, bir gizli kod dizesi {secret} işte User_B's_public_key {some_message, message_authentication_code} secret_key
<a1>Kullanıcı</a1> C iletileri garble deneyebilirsiniz, ancak iletileri, kullanıcı B'nin Kullanıcı A gelmiyor veya kullanıcı B hatalı ileti kimlik doğrulama kodu değeri bulmak ve iletişim'i durdurmak, ileti kimlik doğrulama kodu hesaplamaları göster. Artık kullanıcı B C kullanıcı kimliğine bürünebilir

Özellikler

Makale numarası: 245152 - Last Review: 28 Ekim 2006 Cumartesi - Gözden geçirme: 3.3
Bu makaledeki bilginin uygulandığı durum:
  • Microsoft Exchange Server 4.0 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
  • Microsoft Exchange Server 5.5 Standard Edition
Anahtar Kelimeler: 
kbmt kbinfo KB245152 KbMttr
Machine-translated Article
ÖNEMLİ: Bu makale, bir kişi tarafından çevrilmek yerine, Microsoft makine-çevirisi yazılımı ile çevrilmiştir. Microsoft size hem kişiler tarafından çevrilmiş, hem de makine-çevrisi ile çevrilmiş makaleler sunar. Böylelikle, bilgi bankamızdaki tüm makalelere, kendi dilinizde ulaşmış olursunuz. Bununla birlikte, makine tarafından çevrilmiş makaleler mükemmel değildir. Bir yabancının sizin dilinizde konuşurken yapabileceği hatalar gibi, makale; kelime dağarcığı, söz dizim kuralları veya dil bilgisi açısından yanlışlar içerebilir. Microsoft, içeriğin yanlış çevrimi veya onun müşteri tarafından kullanımından doğan; kusur, hata veya zarardan sorumlu değildir. Microsoft ayrıca makine çevirisi yazılımını sıkça güncellemektedir.
Makalenin İngilizcesi aşağıdaki gibidir:245152
Kullanım Dışı Bilgi Bankası İçeriği Yasal Uyarı
Bu makale, Microsoft'un artık destek sağlamadığı ürünler ile ilgili olarak yazılmıştır. Bu nedenle, bu makale "olduğu gibi" sağlanmıştır ve bundan sonra güncelleştirilmeyecektir.

Geri Bildirim Ver

 

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