Belgeci.com – Bilgi Paylaştıkça Çoğalır

Internet üzerinde herbiri farklı işlemler için kullanılan çeşitli kriptografik protokoller vardır:

Protokol Amaç CyberCash Elektronik para tansferleri DNSSEC Alan adı sistemleri IPSec Paket-seviyesinde kriptolama PCT TCP/IP-seviyesinde kriptolama PGP Eposta S/MIME Eposta S-HTTP Web Secure RPC Remote Procedure Calls SET Elektronik para transferleri SSL TCP/IP-seviyesinde kriptolama SSH Uzaktan login TLS TCP-IP-seviyesinde kriptolama

Bazıları eposta ve uzaktan login gibi haberleşmenin spesifik modları için dizayn edilmiştir. Diğerleri haberleşmenin çoklu modlarına kriptografik servisler sunmak için daha geniş bir yelpaze düşünülerek dizayn edilmişlerdir.
Web üzerinde browser ile sunucu arasındaki haberleşmeleri kriptolamada SSL (Secure Sockets Layer) dominant bir protokoldür. SET (Secure Electronic Transactions) ise kredi-kartı-tabanlı transferlerde koruma sağlamayı amaçlayan bir protokoldür.

Secure Sockets Layer
SSL genel amaçlı, esnek bir kriptolama sistemidir. Netscape ve Microsoft Internet Explorer browser`ları içerisinde bulunduğu için muhtemelen, farkında olmasanız bile, kullanmışsınızdır.

SSL Tarihçesi
SSL 1994 yılında Netscape Navigator browser`ının ilk sürümü ile tanıtıldı. Navigator`un haberleşmeyi kriptolayabilmesi Netscape`in seçilmesinde ana etkendi.
Aynı yıl içerisinde CommerceNet adı verilen iş grupları koalisyonu tarafından S-HTTP adında rakip bir kriptografik protokol sunuldu. S-HTTP ve SSL tarafından kullanılan kriptografik ilkeler aynı olsa da (dijital zarflar, imzalı sertifikalar, mesaj özetleri) aralarında iki önemli fark vardı:
1) S-HTTP sadece web protokolleri ile çalışacak şekilde dizayn edilmişti. SSL çeşitli tipte ağ bağlantılarını kriptolamada kullananılabilen al-seviye bir protokoldür.
2) SSL popüler olan ücretsiz bir browser içerisinde bulunuyordu. S-HTTP ise kullanıcıların satın almak zorunda olduğu NCSA Mosaic`in modifiye edilmiş bir sürümünde bulunuyordu.
SSL kısa süre içerisinde web üzerinde baskın güvenli protokol oldu ve S-HTTP unutulmaya yüz tuttu (halen bazı browser ve sunucular tarafından destekleniyor).

SSL`in üç adet sürümü vardı. SSL 1, Netscape içerisinde dahili olarak kullanıldı ve bazı ciddi hatalar içerdiğinden piyasaya sürülmedi. SSL 2.0 Netscape 1.0 ile 2.x sürümleri içerisine dahil edildi fakat ‘man-in-the-middle’ saldırıları ile ilgili bazı zayıflıklar içeriyordu. Ek olarak iki üniversite öğrencisi Netscape`in rastgele sayı üreticisindeki bir açıktan yararlanarak SSL 2.0`ı dakikalar içerisinde kırdı.
SSL`in güvenliği konusunda oluşan endişelerden yararlanmak isteyen Microsoft 1996 yılında Internet Explorer`ın ilk sürümünde rakip protokol PCT`yi sundu. Netscape karşılık olarak 2.0 daki problemlerin giderildiği ve (Diffie-Hellman anonim anahtar değiştokuşu ve Fortezza akıllı kart desteği gibi) yeni özelliklerin eklendiği SSL v3.0`ı sundu.
Bu noktada Microsoft geri adım atarak Internet yazılımlarının tüm sürümlerinde SSL`i desteklemeye karar verdi (geriye uyumluluk için halen PCT desteği bulunuyor). SSL v3.0 Netscape Navigator 3.0 ve yukarısı sürümlerde ve Internet explorer 3.0 ve yukarısında bulunuyor.
SSL daha sonra Internet Engineering Task Force (IETF) tarafından Internet standartları aktivitelerinde odak noktası oldu. TLS, önerilen Transport Layer Security protokolü SSL v3.0 dan türetilmiştir ve farklı mesaj özeti ve kriptolama algoritmaları kullanır. IETF`nin NSA kaynaklı protokollere olan tarihsel şüpheleri sebebiyle TLS`in Fortezza`yı destekleyip desteklemeyeceği belirli değildi.

SSL karakteristikleri
SSL protokolü NNTP (habergrupları) HTTP (web) ve SMTP (eposta) gibi uygulamalara özgü protokollerin bir seviye altında TCP/IP transport katmanında çalışır. Bu özellik SSL`e esneklik ve protokol bağımsızlığı sağlamaktadır. TCP kullanan herhangi bir programın güvenli SSL bağlantıları kullanabilmesi için kaynağında birkaç değişiklik yeterlidir. SSL desteği olan web browser`lara ve sunuculara ek olarak SSL kullanan telnet programları, habergrupları okuyucuları ve eposta transfer programları da vardır.
SSL`in transport katmanında bulunmasının ana sebeplerinden biri spesifik olarak HTTP protokolü için yapılmamış olmasıdır. Ufak sınırlamalardan biri SSL bağlantısının dedike/özel bir TCP/IP soketi kullanması gerektiğidir. Bir web sunucusu SSL modunda çalıştığında kriptolanmış haberleşmeler için ayrı bir ağ portu (genelde port 443) kullanır.
SSL`in önemli özelliklerinden biri simetrik kriptolama algoritması, mesaj özeti fonksiyonu ve kimlik tanılama metodları seçimindeki esnekliğidir. SSL simetrik kriptolama için DES (CBC-cipher block chaining modunda), triple-DES, RC2 veya RC4 kullanabilir. Mesaj özetleri için MD5 veya SHA hash algoritmalarını kullanabilir. Kimlik tanılaması için RSA açık anahtarları ve sertifikalarını kullanabilir veya Diffie-Hellman anahtar değiştokuş algoritması kullanarak anonim modda çalışabilir. Kriptolama algoritmaları için çeşitli anahtar uzunlukları kullanılabilir. Simetrik kriptolama algoritması, mesaj özeti metodu ve kimlik tanılamanın kullanılmasındaki kombinasyonlar ‘şifreleme takımı’ olarak bilinir. Aşağıdaki liste SSL tarafından desteklenen şifreleme takımlarını listelemektedir:

Takım Gücü SSL Sürümü Tanımı DES-CBC3-MD5 Çok Yüksek v2.0, v3.0 CBC modunda 3DES, MD5 hash, 168-bit oturum anahtarı DES-CBC3-SHA Çok Yüksek v2.0, v3.0 CBC modunda 3DES, SHA hash, 168-bit oturum anahtarı RC4-MD5 Yüksek v2.0, v3.0 RC4, MD5 hash, 128-bit anahtar RC4-SHA Yüksek v3.0 RC4, SHA hash, 128-bit anahtar RC2-CBC-MD5 Yüksek v2.0, v3.0 CBC modunda RC2, MD5 hash, 128-bit anahtar DES-CBC-MD5 Orta v2.0, v3.0 CBC modunda DES, MD5 hash, 56-bit anahtar DES-CBC-SHA Orta v2.0, v3.0 CBC modunda DES, SHA hash, 56-bit anahtar EXP-DES-CBC-SHA Düşük v3.0 CBC modunda DES, SHA hash, 40-bit anahtar EXP-RC4-MD5 Düşük v2.0, v3.0 Export seviyesi RC4, MD5 hash, 40-bit anahtar EXP-RC2-CBC-MD5 Düşük v2.0, v3.0 Export seviyesi RC4, MD5 hash, 40-bit anahtar EXP-RC2-CBC-MD5 Düşük v2.0, v3.0 CBC modunda export seviyesi RC2, MD5 hash, 40-bit anahtar NULL-MD5 – v2.0, v3.0 Kriptolama yok, MD5 hash, sadece kimlik tanılama NULL-SHA – v3.0 Kriptolama yok, SHA hash, sadece kimlik tanılama

Bir SSL istemcisi sunucu ile ilk bağlantı kurduğunda ikisi bir şifreleme takımı üzerinde anlaşırlar. Genel olarak, ikisininde sahip olduğu en güçlü kriptolama metodunu seçerler. Eğer sadece 40-bit oturum anahtarlarını destekleyebilen export-sürümü bir browser bu tip bir sınırlaması olmayan bir sunucuya bağlanmaya kalkarsa, sunucuda 40-bit ile haberleşecektir. Benzer olarak, yine bu tip bir sınırlaması olan istemci ile haberleşirken 1024-bit anahtarından 512-bit RSA açık anahtarı türetecektir. Bazı web sunucuları yöneticinin görüşme işlemini ayarlayabilmesine izin verir. Örneğin bir webmaster sadece güçlü kriptografiyi destekleyen istemcilerin bir dizine erişebilmesine izin verilecek şekilde ayar yapabilir.

SSL veri sıkıştırmayı dahili olarak desteklemektedir. Bu da bir mesaj kriptolandıktan sonra sıkıştırılamayacağı için önemli bir özelliktir (Sıkıştırma veri akışlarındaki yaygın pattern`leri bulup fazlalıkları çıkartarak gerçekleştirilir, Kriptolama veriden tüm pattern`leri çıkartarak yapılır ve bu sebeple sıkıştırılamaz hale gelir).
Bir SSL bağlantısı kurulduğunda aşağıdakiler dahil tüm browser`dan-sunucuya ve sunucudan-browser`a yapılan haberleşme kriptolanır:

• İstek yapılan dokümanın URL`si
  
• İstek yapılan dokümanın içeriği
  
• Doldurulup gönderilen form`ların içeriği
  
• Browser`dan sunucuya gönderilen çerezler (cookie).
  
• Sunucudan browser`a gönderilen çerezler.
  
• HTTP başlığının içeriği

SSL işlemleri
SSL protokolünün teknik detayları için yazının sonundaki adreslere bakabilirsiniz. Protokolün amacı sunucunun kimliğini tanılamak (seçime bağlı olarak, istemcinin kimlik tanılamasının yapılması) ve hem istemci hemde sunucunun kriptolanmış mesajlar gönderebilmede kullanabilmesi için gizli simetrik anahtar belirlemesidir.
İşlemin adımları kısaca şöyledir:
1. İstemci (örnekte browser) sunucu portuna bir bağlantı açarak ‘ClientHello’ mesajı gönderir. ‘ClientHello’ istemcinin kullandığı SSL sürümü, desteklediği şifreleme takımı ve desteklediği veri sıkıştırma metodları gibi bilgileri içerir.
2. Sunucu ‘ServerHello’ mesajı ile cevap verir. Sunucu seçtiği şifreleme takımı ve veri sıkıştırma metodunu içeren ve bağlantıyı tanımlayan oturum ID`sini içeren bir mesaj gönderir. Şifreleme takımı ve sıkıştırma metodlarının seçiminden sunucu sorumludur. Eğer istemci ve sunucu arasında seçimlerde bir uyum sağlanamazsa sunucu ‘handshake failure’ mesajı gönderip bağlantıyı kapatır.
3. Sunucu sertifikasını gönderir. Eğer sunucu sertifika-tabanlı kimlik tanılaması kullanıyorsa (ki genelde durum hep öyledir) sunucu imzalı X.509v3 site sertifikasını gönderir. Eğer sertifika root olmayan bir sertifika otoritesi tarafından imzalanmışsa, sunucu ana sertifika otoritesine kadar olan imzalı sertifikalar zincirini de gönderir.
4. Sunucu istemci sertifikası isteği gönderir (seçime bağlı). Eğer istemci kimlik tanılaması için istemci sertifikaları kullanılıyorsa sunucu istemciye sertifika isteği mesajı gönderir.
5. İstemci sertifikasını gönderir (seçime bağlı). Eğer sunucu istek yaptıysa, istemci imzalı X.509v3 istemci sertifikasını gönderir. Eğer istemcinin sertifikası yoksa ‘no certificate’ alarmını gönderir. Sunucu bu noktada ‘handshake failure’ ile bağlantıyı iptal edebilir yada devam edebilir.
6. İstemci ‘ClientKeyExchange’ mesajı gönderir. Burda simetrik oturum anahtarı seçilir. Detaylar seçilen şifreleme takımına göre değişir fakat tipik bir durumda istemci iyi bir rastgele-sayı üreteci ile ‘pre-master secret’ yaratır. Bu anahtar her iki tarafta da oturum anahtarı olarak kullanılacak gerçek anahtarı yaratmada kullanılır (farklı simetrik şifreler farklı anahtar uzunlukları kullandığından oturum anahtarı direk olarak yaratılmaz). Browser dijital zarf yaratmak için bu anahtarı sunucunun (sertifikasından aldığı) RSA açık anahtarı ile kriptolar. Sonrasında zarf sunucuya gönderilir.
7. İstemci ‘CertificateVerify’ mesajı gönderir (seçime bağlı). Eğer istemci kimlik tanılaması kullanılıyorsa, istemci doğru RSA özel anahtarını bildiğini göstererek sunucuya kimlik tanılamasını gerçekleştirmesi gerekir. ‘CertificateVerify’ mesajı (aradaki konuşmayı dinleyen birisinin müdahele etmesini zorlaştıracak şekilde çeşitli yollarla değiştirilen) 6. adımda yaratılan premaster anahtarı içerir. Anahtar istemcinin RSA özel anahtarı ile imzalanır ve sunucuya gönderilir. Sunucu istemcinin sertifikası ile bunu kontrol eder. Burda sunucunun kimliğini tanılaması gerekmediğine dikkat edilmeli. İstemci premaster anahtarını sunucunun açık anahtarını kullanarak gönderdiği için sadece sunucunun sertifikasının sahibi bunu dekriptolayıp kullanabilir.
8. Hem istemci hemde sunucu ‘ChangeCipherSpec’ mesajı gönderir. Bu mesaj istemci ve sunucunun kararlaştırılan simetrik şifre ve oturum anahtarı ile haberleşmeye başlayabileceklerini onaylayan basit bir mesajdır.
9. Hem istemci hemde sunucu ‘finished’ mesajı gönderir. Bu mesajlar o ana kadarki tüm konuşmanın tam olarak alındığı ve yolda değiştirilmediğini onaylamada kullanılacak olan MD5 ve SHA hash`lerini içerir.

Bu noktada hem istemci hemde sunucu her iki tarafa doğru olan trafiği oturum anahtarı kullanarak simetrik olarak kriptolamak için kriptolama moduna geçerler.
Yukarda belirtilen 9 adıma ek olarak SSL 3.0 sunucular için ek bir işlem vardır. 3. adımda sertifikasını göndermek yerine sunucu ‘ServerKeyExchange’ mesajı gönderir. Bu sunucunun bir sertifika göndermeden bir oturum anahtarı belirlemek için kullanılır. Bu aşağıdaki durumlardan herhangi birinde gerçekleşebilir:
1. Sunucu anonim Diffie-Hellman anahtar değiştokuşu protokolünü kullanıyorsa
2. Sunucu Fortezza akıllı kart kriptolama takımını kullanıyorsa
3. Sunucunun sadece imza için özel anahtarı varsa (mesela bir DSS anahtarı)
Bu senaryoların en ilginci Diffie-Hellman anahtar değiştokuşu algoritması kullanımıdır. Bu durumda istemci ve sunucu bibirlerini tanımadan paylaşılan oturum anahtarı belirler. Sertifika değiştokuşu olmadığından etkileşim tamamen anonimdir. Bu aynı zamanda işlemin man-in-the-middle saldırısından etkilenebileceği anlamına da gelir.

SET ve diğer dijital ödeme sistemleri
SET Nedir?
SET (Secure Electronic Transactions-Güvenli Elektronik İşlemler) Visa, Mastercard, Netscape ve Microsoft`un birlikte geliştirdiği bir kriptografik protokoldür. Haberleşmeleri kriptolama için kullanılan genel amaçlı SSL`den farklı olarak SET sadece müşteri ile tüccar arasındaki kredi ve ‘debit’ kartları işlemlerini güvenli hale getirmede kullanılır.
Alt seviyede, SET protokolü aşağıdaki ana servisleri sağlar:

• Kimlik Tanılama – Kredi kartı işlemlerindeki tarafların kimlik tanılaması dijital imzalar ile gerçekleştirilir. Buna müşteri, tüccar, müşterinin kredi kartını sağlayan banka ve tüccarın kontrol hesabı ile ilgilenen banka dahildir.
  
• Gizlilik – İşlemler kriptolandığı için gizlice dinlenemez.
  
• Mesaj bütünlüğü – İşlemler kötü amaçlı bireyler tarafından hesap numarasında veya tutarda değişiklik yapılacak şekilde değiştirilemez.
  
• Linkleme – SET bir tarafa gönderilen eki sadece diğer tarafın okuyabilmesini sağlar. Linkleme ilk tarafın ekin içeriğini okumasına gerek kalmadan ekin doğru olduğunu kontrol edebilmesini sağlar.

Yüksek seviyede, SET protokolü aşağıdakiler dahil olmak üzere şu anki kredi kart sistemlerindeki tüm özellikleri destekler:

• Kartsahibi kayıtı
  
• Tüccar kayıtı
  
• Satın alma istekleri
  
• Ödeme yetkileri
  
• Ödeme alma (fon transferi)
  
• Geri-ödemeler
  
• Krediler
  
• Kredi geridönüşleri
  
• Debit kart (çek kart) işlemleri

SET gerçek-zamanlı işlemleri, toplu işlemleri, kurulum ödemelerini destekler.
Bu dokümanın hazırlandığı tarihte (Mayıs 1997) son SET spesifikasyonu yayınlandı. Pek çok üretici firma protokolü destekleyeceğini duyursada sadece Verifone Corporation bir SET ürünü çıkardı. Müşteriler için vWallet uygulaması ve Microsoft Merchant Web sunucusu için vPOS uzantıları ilk SET spesifikasyonunu kullanır. Web browser`lar protokolü yazılımda içererek veya bir ActiveX kontrolü, Java applet`i veya plug-in`i indirerek SET`i direk olarak destekleyecekler.

Niye sadece SSL kullanılmasınki?
SET`i detaylı incelemeye başlamadan önce akla gelebilecek bir soru: Niye özel-amaçlı protokol gerekli? Neden Kredi kartı bilgilerini form doldurup SSL kullanarak göndermeyelim?
Kredi kartı ödemelerinde kesinlikle SSL kullanılabilir. Bu günümüzde en çok kullanılan yol ve Netscape, Microsoft Open Market ve diğerleri tarafından satılan ‘ticaret sistemlerinin’ ana özelliği. Fakat bu amaç için sadece SSL kullanmanın bazı dezavantajları var.
Birincisi, SSL müşteriden tüccara kredi kartı numarasının güvenli olarak gönderilmesini sağlasa da, işlemin sonrasında bir yararı olmuyor: numaranın doğruluğunun kontrolü, müşterinin bu numarayı kullanmaya yetkili olup olmadığının kontrolü, tüketicinin bankası ile işlemi yetkilendirme ve transferi işleme. Basit bir sistemde, kredi kartının yazım hataları bir CGI script ile kontrol edilebilir ve numarayı bir dosya yada veritabanına daha sonra manuel olarak kontrol için kaydedilebilir. Fakat çoğu uygulama için online olarak kredi kartı yetkilendirmesi bir ihtiyaçtır. Gelişmiş ticaret sistemleri kredi kart yetkili servisi tarafından çalıştırılan bir sunucuya SSL veya uygun bir protokolle bağlanarak siparişleri anında onaylarlar. Bu tip sistemler ayrıca geri ödemeleri, işlem kaydı tutma, alışveriş kartlarını, online katalogları da yönetebilirler. Tam fonksiyonel bir kredi kartı işleme sistemi ya çok sayıda özel programlama yada pahalı bir paket çözümdür.

SSL-tabanlı şemalardaki diğer bir problemde sunucu-tarafı güvenliktir. Kredi kartı numarası tüccarın Web sunucusuna gönderildiği için bu bilgi bir dosya veya veritabanında tutulabilir. Eğer birisi tüccarın web sunucusuna girmeyi başarırsa tüm kredi kartı numaralarını da ele geçirebilir. Aslında, bu 1994`de Netcom Internet servis sağlayıcısının başına gelen bir olay. Ek olarak bazıları tüccarın kredi kartı bilgilerini mesaj listeleri ve pazarlama bilgisi derlemede kullanabileceği konusunda endişeleniyor.

Kredi kartı işlemlerinde SSL kullanmada diğer bir problem de kredi kartı tahmin programlarının zayıf yazılmış sistemlerde kullanılabilmesi. Uzaktaki kullanıcı önce denemelik kredi kartı numaraları yaratır. Hepsi basit checksum kontrolünü geçecektir fakat hangisinin gerçek bir hesaba ait olduğunu bilmemektedir. Daha sonra bu numaraları bir scripte ekleyerek bir web sunucusundan sahte satın almalar yapmaya çalışır. Eğer kart geçerli değilse sunucu bir hata döner ve script numarayı atar. Eğer kart tanılaması doğru olarak gerçekleşirse sunucu kabul eder ve script satın almayı iptal edip numarayı kaydeder. Bu tip bir sistem kısa zamanda yüzlerce geçerli kredi kartı numarası bulabilir. SET bu problemleri kart yetki kontrolü ve satışın sonlandırılmasına kadar tüm işlemi kontrol eden entegre bir sistem sağlayarak giderir. Kredi kartı numarasının çalınmasını engellemek için protokol hiçbir zaman tüccarın kart numarasına direk erişimine izin vermez, bunun yerine satın almanın onaylanıp onaylanmadığı konusunda bilgilendirilir.
Son olarak Amerikan ihracat kısıtlamaları konusu var. Güçlü kriptografi kullanan sistemlerin, SSL kullananlar dahil, ihraç edilmesi yasaktır. Fakat kanun sadece parasal işlemlerde kullanılan sistemleri hariç tuttuğu için güçlü kriptografi kullanan SET ürünleri Amerika dışına çıkabilir ki bu genel-amaçlı SSL ürünleri için mümkün değildir.

belgesi-317