Heartbleed’den sonra OpenSSL’ye sorulan bazı ciddi sorular oldu. İnternet güvenliği için bu kadar temel olan bir şeyin eski koddan çalıştırılmasına nasıl izin verilir? İnternette güvenmek için bu kadar önemli olan bir kütüphane sadece birkaç yarı zamanlı kişi tarafından nasıl korunabilir? Şifrelememizi Bulut tabanlı anahtar yönetimine nasıl bağlayabiliriz?
OpenSSL’nin Mirası
OpenSSL, Linux tabanlı sunucular tarafından SSL/TLS bağlantısını uygulamak için yaygın olarak kullanılır ve hatalar yaygındır. Sıfır gün ve kritik hatalar geçmişte olduğu kadar yaygın olmasa da yakın zamanda iki tanesi yayınlandı.
OpenSSL, Aralık 1998’de OpenSSL’nin (SSL eay — SSL E ric AY oung) ilk sürümünü oluşturan Eric A Young ve Tim Hudson ile başlatıldı. Bu, Sürüm 0.9.1 oldu. Eric araştırmasını bitirdi ve Cryptsoft’a gitmek ve ardından şu anda Seçkin Mühendis olduğu RSA Security’ye katılmak üzere ayrıldı. Eric ayrıldıktan sonra, OpenSSL Software Foundation (OSF) aracılığıyla geliştirmeye devam etmek Steve Marquess (ABD’den) ve Stephen Henson’a (İngiltere’den) bırakıldı.
Kod, 14 Mart 2012’de 1.0.1a’ya eklenen TLS desteğiyle büyümeye devam etti. Ne yazık ki, 1 Ocak 2012’de Heartbeat protokolünü uygulayan ve sonunda Heartbleed ile sonuçlanan bir hata ortaya çıktı. Hata aslında RFC’yi yazan aynı kişi tarafından tanıtıldı. Alman bir geliştirici olan Robin Seggleman.
Her önemli güvenlik açığı bir CVE numarası alır. Bazen Heartbleed ( CVE-2014–0160 ), BEAST ( CVE-2011–3389 ), FREAK ( CVE-2015–0204 ) vb. gibi yaygın bir adla ilişkilendirilirler , ancak bazıları, örneğin CVE-2016– 2017, sadece ortak bir adı yok. OpenSSL 1.0.1 ve 1.0.2 ile ilgili ve bir saldırganın AES şifrelemesinde MITM (Ortadaki Adam) saldırısı gerçekleştirebileceği Heartbleed hatası.
O sırada OpenSSL koduna bakan herkes, kod entegrasyonuna tutarlı bir yaklaşım oluşturmaya gerçekten odaklanmadığını ve özellikle mobil cihazlara odaklanan bir dünyada yeniden tasarıma ihtiyaç duyduğunu görebilirdi. Ve böylece Google başlangıçta OpenSSL kodunu BoringSSL ile çatalladı, ancak daha sonra resmi olarak Google Tink’i yayınladı .
Google Tink
Google, Tink Sürüm 1.2.0’ı Ağustos 2018’de çok dilli (Java, C++ ve Objective C), platformlar arası şifreleme kitaplığı olarak resmi olarak yayımladı. Ana odak noktası, OpenSSL’yi değiştirmek ve karmaşık bağlamaların olduğu ve genellikle Windows sistemlerindeki DLL’ler gibi belirli sistemlere odaklanan yerlerdir. Google, Tink’i oluştururken açık kaynaklıdır ve kriptografi işlevleri için basit API’ler oluşturmayı amaçlar ve bu da altyapıyı daha taşınabilir, güvenli ve kararlı hale getirir.
Tink için – BoringSSL tabanlı ve şimdi Sürüm 1.7.0’da benimseme iyi oldu ve şimdiden AdMob, Google Pay, Google Asistan ve Firebase’e entegre edildi. Ayrıca AEAD (İlişkili Verilerle Doğrulanmış Şifreleme) yöntemlerini entegre eder ve şifreleme anahtarlarını, bir karma işlevini ve bir mesaj kimlik doğrulama kodunu (MAC) entegre eder. Google da birçok kriptografi zayıflığını analiz etmiş ve bu sorunların çoğuna hitap eden kodlar oluşturmuştur. Tink ayrıca Amazon KMS, Google Cloud KMS, Android Keystore ve iOS Keychain gibi modern bulut tabanlı anahtar yönetim sistemleriyle de entegre olur.
AEAD için minimum standartlar şunları içerir:
- Düz metin ve ilişkili veriler herhangi bir uzunluğa sahip olabilir (0 ila 2³² bayt).
- 80 bit kimlik doğrulamayı destekler.
- CCA2 güvenliği (uyarlanabilir seçilmiş şifreli metin saldırısı).
Google Tink: Simetrik anahtar
AES simetrik bir anahtar yöntemidir ve burada Bob ve Alice aynı şifreleme anahtarına sahiptir. Aşağıda, Bob ve Alice bir şifreleme anahtarını paylaşırlar ve burada Bob kendi düz metnini şifreli metne dönüştürür ve ardından Alice, paylaşılan bir gizli anahtar kullanarak şifreli metni tekrar düz metne dönüştürür.
Bu kurulumdaki sorun, aynı düz metnin her zaman aynı şifreli metinle sonuçlanmasıdır, bu nedenle şifreleme sürecine genellikle tuz ekleriz. Ayrıca Bob ve Alice’in aynı gizli anahtarı üretmesi için bir yola ihtiyacımız var. Bu, tipik olarak bir anahtar değişim yöntemi (Diffie-Hellman yöntemi gibi) veya bir KDF (Anahtar Türetme İşlevi) aracılığıyla yapılır. En popüler KDF’lerden biri PBKDF2’dir ve bir parolanın tanımlanmış boyutta bir şifreleme anahtarına dönüştürülmesine izin verir.
Diğer bir şifreleme modu, AEAD (Ek Verilerle Doğrulanmış Şifreleme) olarak tanımlanır ve burada şifreleme işlemine bazı düz metin kimlik doğrulama verileri ekleyebiliriz. Şifre çözme işlemi için aynı kimlik doğrulama verilerine ihtiyaç duyduğumuz yerlerde.
Anahtarın boyutu tipik olarak 128 bit veya 256 bittir. AES (Gelişmiş Şifreleme Standardı) üç modda uygulanabilir:
- Blok şifresi . Bu, bir blok şifre uygulayan CBC (Cipher Block Chaining) ile uygulanabilir. AES durumunda, blok boyutu 16 bayt olacaktır ve dolayısıyla şifreli metin, blok boyutunun katları olacaktır. Bir blok şifre kullandığımız için, şifre işlemi için verileri doldurmamız ve ardından şifresi çözülmüş verileri açmamız gerekir. En yaygın yöntem PKCS7’dir ve dolgu baytlarının sayısına eşit olan değerle doldurulur.
- AEAD (Ek Verilerle Kimliği Doğrulanmış Şifreleme) . Bu, GCM (Galois Sayaç Modu) ile uygulanabilir ve ek verilerin eklenmesiyle bir akış şifresi ile uygulanır. Bu ek veriler, oturum kimliği veya TCP bağlantı noktası gibi şifreli metinle ilgili bir şeyi içerebilir. Düz metin metni için dolgu gerekmez ve bu nedenle şifreli metin, düz metin ile aynı uzunluğa sahip olacaktır. AEAD’yi kullanmak için bir alternatif olarak, kimlik doğrulama için HMAC’ı kullanabiliriz ve bu bir imzalama anahtarı içerir.
- Akış şifresi . Bu, bir akış şifresi uygulayan CFB (Cipher FeedBack) ile uygulanabilir. Bir akış şifresi kullandığımız için, verileri doldurmamıza gerek yoktur ve burada şifreli metin boyutu, düz metin ile aynı olacaktır. Genel olarak, düz metin akışı ile bir anahtar akışı (ana şifreleme anahtarından türetilen) arasında basit bir XOR işlemi kullanıyoruz. Şifre çözme, şifreli metin akışını aynı anahtar akışıyla yalnızca XOR’layarak gerçekleştirilir.
Ek verileri kullanmak yerine (AEAD’de olduğu gibi) mesajın kimlik doğrulamasını sağlamak için HMAC kullanıyoruz. Bir örnek çalışma süreci kanıtlar.
Google Tink: MAC
Kriptografide kullandığımız standart yöntemlerden biri de mesaj imzalamaktır . Bunun için, bir dizi mesaj için gizli tutulan bir imzalama anahtarı oluşturuyoruz. Bu, Bob ve Alice arasındaki tek bir konuşmayla veya aralarındaki uzun vadeli iletişimlerle ilgili olabilir.
HMAC, bir mesajın bütünlüğünü ve kimlik doğrulamasını doğrulamak için kullanılabilen bir mesaj doğrulama kodudur (MAC). Mesajın gizli bir anahtarla hash edilmesini içerir ve bu nedenle tamamen tek yönlü bir işlev olan standart hashing işleminden farklıdır. Herhangi bir MAC’de olduğu gibi, MD5 veya SHA-1 gibi standart bir hash işleviyle kullanılabilir, bu da HMAC-MD5 veya HMAC-SHA-1 gibi yöntemlerle sonuçlanır. Ayrıca, herhangi bir karma işlevinde olduğu gibi, güç, karma işlevinin kalitesine ve sonuç olarak elde edilen karma kod biti sayısına bağlıdır. Bununla birlikte gizli anahtardaki bit sayısı da hash’in gücünde bir etkendir.
Aşağıdaki şekil, gönderilecek mesajın gizli bir anahtar ve hashing fonksiyonu ile bir HMAC koduna dönüştürüldüğü işlemi özetlemektedir. Bu daha sonra mesajla birlikte gönderilir. Alındıktan sonra alıcı, aynı gizli anahtardan ve mesajdan HMAC kodunu yeniden hesaplar ve alınan sürümle karşılaştırarak kontrol eder. Eşleşirlerse, hem göndereni hem de mesajı doğrular.
Şimdi Google Tink’in MAC kodlarını nasıl ürettiğine bakalım. Bunun için, MacFactory için getPrimitive yöntemiyle yeni bir MAC anahtarı oluşturuyoruz ve ardından aşağıdakileri kontrol etmek için oluşturmak ve Mac doğrulamak için compute Mac’i kullanıyoruz.
Google Tink: Dijital İmzalar
Kriptografide kullandığımız standart yöntemlerden biri, bir mesajı özel anahtarla imzalamak ve imzayı halkla kanıtlamaktır. Bu nedenle, Bob’un bir anahtar çifti varsa, mesajı imzalamak için kendi özel anahtarını kullanır ve ardından Alice, Bob’un genel anahtarını kullanarak Bob’un imzaladığını kanıtlayacaktır. Ayrıca mesajın Havva tarafından değiştirilmediğini de kanıtlayacaktır. Bu durumda, Bob, mesajın özetini imzalamak için kullandığı özel bir anahtara (sk) sahiptir ve ardından Alice, imzayı kanıtlamak için genel anahtarını (pk) kullanır.
Bu yöntemi kullandığımız birçok uygulama var. Bir örnek, Bitcoin transferlerinde ve Bob’un Alice’e belirli sayıda bitcoin ödemek için bir işlemi imzaladığı yerdir. Bu işlemi (cüzdanında bulunan) özel anahtarıyla imzalar ve ardından genel anahtarıyla blok zincirine ekler. Transferi kontrol etmek isteyen herkes Bob’un açık anahtarıyla imzayı kontrol edecek.
Ancak ECDSA, dağıtılmış bir şekilde ölçeklendirmek için mücadele edebilir ve zayıf bir şekilde oluşturulmuş sıfır değerlere (k) karşı savunmasız olabilir. Bu durumda, bir mesaj için Ed25519 imzasını bulacaksınız ve burada imzalamak için özel bir anahtar ve imzayı kanıtlamak için bir genel anahtar kullanıyoruz.
Sonuç olarak;
OpenSSL, siber güvenliğin İsviçre Çakısıdır, ancak kusurları vardır, özellikle de çok fazla eski kod taşır. Tink iyi bir alternatiftir ve modern uygulamalarımız için tasarlanmıştır: