Eski Teknolojilere Geri Dönüş, Offline İletişim Ağları ve Güvenlik – Utku Sen - Blog – computer security, programming
Internetin Fiziksel Yapısı
Network konusunda öğretilen temel bir şey vardır: OSI modeli. Bu modelde 7 adet katmandan söz edebiliriz:
1) Fiziksel katman
2) Data link (Veri bağlantısı) katmanı
3) Network (Ağ) katmanı
4) Transport (Taşıma) katmanı
5) Session (Oturum) katmanı
6) Presentation (Sunum) katmanı
7) Application (Uygulama)
Güvenlik araştırmacıları burada yer alan katmanlar özelinde uzmanlıklara sahip olabiliyor. Fakat bu katmanlardan olan “fiziksel katman”, genellikle ihmal edilir. Örneğin, bir web sitesine bir kullanıcı nasıl bağlanır hikayesini anlatırken, doğrudan kullanıcının tarayıcıya siteyi yazıp DNS’e sorgu yollamasıyla başlarız. Fakat burada es geçilen şöyle önemli bir nokta var: Türkiye’den bir kullanıcının, Amerika’daki bir sunucuya yolladığı paketler fiziksel dünyada nasıl taşınıyor? Cevap basit: Kabloyla! (Uydu aracılığıyla da taşınabilir fakat bunu şimdilik konu dışında bırakıyoruz.)
Örneğin aşağıdaki görsel Türkiye’nin internet çıkış kablolarını gösteriyor:
Peki bu kablo teknolojisinin kırılganlığı nedir? Tabi ki fiziksel hasara açık olması. Örneğin büyük bir savaş, büyük bir doğal afet durumunda Türkiye’nin dışarıya açılan ve içerisinde yer alan kabloları zarar görürse, Türk halkının çok büyük bir kısmı internetsiz kalacaktır.
Aslında tek problem fiziksel hasarlar da değil. Yurt dışına açılan her hattın aslında bir kapasitesi mevcut. 2007 yılında Rusya Estonya’ya siber saldırı yaparak, Estonya’nın dışarıya açılan hatlarının kapasitesini neredeyse doldurmuş, böylece Estonya dış dünya ile internet bağlantısı sağlayamamıştı.
Sunucu istemci yapısını hepimiz biliyoruz. Kabaca tekrar bahsetmek gerekirse: Örneğin arkakapidergi.com bir sunucu üzerinden yayın yapıyor. İçerikleri okumak isteyen kullanıcılar buraya bağlanıyor. Fakat birisi gidip de arkakapidergi.com’un bulunduğu sunucuyu ateşe verirse, buradaki içerikler tamamen ulaşılmaz hale gelecek. Günümüzde cloud gibi teknolojiler sayesinde, bu işlem bu kadar basit olmayacaktır. Fakat günün sonunda baktığımız zaman yine çoğu şey tek bir noktadan, yani centralized bir yapıda çalışıyor. Bir savaş esnasında Twitter’ın ve Whatsapp’ın sunucularının zarar görmesi, kullanıcıları bu platformdan tamamen mahrum bırakacaktır.
Sunucu-istemci yapısına alternatif olarak geliştirilen P2P (Peer-to-peer) teknolojisi bu tip problemlere çözüm sunuyor. Ancak o da internet tabanlı çalıştığı için birisinin gidip kabloyu makasla kesmesi bütün o kompleks teknolojiyi çöpe atıyor.
Offline İletişim Ağının Teorik Konsepti
Aslında iki akıllı telefonun birbiriyle iletişim kurması için internete ihtiyacımız yok. Gayet eski olan Wifi ve Bluetooth protokolleri üzerinden de mesaj ve dosya gönderimi yapabiliyoruz. Ancak tabi ki karşımızdaki kişi bizim yakınımızda yer almalı. Beşiktaş’tan Şişli’e Wifi ile dosya gönderemeyiz. Peki Beşiktaş’tan Şişli’ye kadar bizim dosyamızı Wifi üzerinden taşıyabilecek aracılar olsaydı ne olurdu? Bunu kulaktan kulağa oyunu gibi düşünebilirsiniz. Aracılar yolladığınız dosyayı Wifi üzerinden birbirine aktara aktara Şişli’deki hedefe kadar ulaştıracak. Şöyle bir çizim üzerinden gösterebiliriz (Çizimlerin hepsi proje taslak defterimden kalmadır.)
Beşiktaş-Şişli arası 4000 metre. Telefon Wifi’larının çekim alanı cihazdan cihaza değişse de, internetten edindiğim bilgilere göre ortalama 30 metreye tekabül ediyor. Bu yüzden Beşiktaş’tan Şişli’ye bir dosya aktarabilmem için 30 metre aralıklarla duran 133 kişi gereklidir. İstanbul’un çok kalabalık bir şehir olduğunu düşünürsek, aslında bu 133 sayısı gayet makul. Bunun pratikte mümkün olabileceğini anladıktan sonra gelelim teknik detaylara. Yukarıdaki çizim aslında çok gerçekçi değil ve çok detay barındırmıyor. Örneğin ya o an gece yarısı ise ve Beşiktaş Şişli arasında 133 kişi yoksa? Ya da daha önemlisi olsa bile bu insanlar mesajı kime ileteceğini nereden bilecek? Şimdi işin bu kısmında iki farklı düşüncem var:
1) Full Mesh Network
Örneğin saat gece üç ve Beşiktaş’tan Şişli’de yaşayan bir arkadaşıma mesaj göndermek istiyorum. Yapmam gereken şey mesajı ve alıcı ismini çevremdeki insanlara yayınlamak (broadcast). 30 metre çapımdaki insanlar bu broadcast mesajını görecek, fakat alıcı kendileri olmadığı için mesajı taşımak üzere kendi cihazlarında tutacaklar. Daha sonra insanlar, gün içinde bir yerlere seyahat ederken “Utku” kullanıcısından gelen bu mesajı alıcıya ulaştırmak için broadcast etmeye devam edecekler. Diğer kullanıcılar da kendileri alıcı olmadığı için yine bu mesajı taşımak üzere kendi cihazlarında tutacaklar. Gerçek alıcıya ulaşılana kadar bu mesaj bir çok insanın cihazında dolaşacak.
Avantajlar: Ekstra bir yapıya ihtiyaç duyulmadan mesajlar kullanıcılar arasında taşınabilir.
Dezavantajlar: Çok fazla var. Örneğin kullanıcı sayısı arttıkça cihazlarda depolanan ve broadcast edilen mesajlar çok yer kaplayacak. Bunun yanında geri bildirim mekanizması sorunlu olacağı için broadcastlerin sürekli devam etme durumu olacaktır. Örneğin, mesaj bir şekilde Şişli’deki kullanıcıya ulaştı ancak başka bir kullanıcı bunun farkında olmadan Avcılar’da mesajı broadcast etmeye devam edebilir.
2) Semi Mesh Network
Bu konsept’in blockchain’e benzeyen bir yapısı var. Burada broadcast işlemini kullanıcıların yanı sıra, İstanbul’un çeşitli noktalarına yerleştirilmiş node’lar yapacak. Yine aynı örnek üzerinden gidelim: Beşiktaş’tan Şişli’deki arkadaşıma mesaj göndermek istiyorum. Yapacağım ilk işlem yine mesajı ve alıcıyı broadcast etmek. 30 metre çapımdaki kullanıcılar bu isteği alacak ve alıcı kendileri olmadığı için mesajı cihazlarında tutacaklar. Fakat burada kullanıcıları sonsuz broadcast döngüsünden kurtaracak bir etmen daha var, o da node’lar. Kullanıcı, alıcıyı ya da bir node’u bulana kadar mesajı broadcast etmeye devam edecek. Eğer alıcıyı bulursa broadcast işlemini sonlandıracak. Bunun yanında bir node ile karşılaşırsa mesajı node’a iletip yine broadcast işlemini sonlandıracak. Bir çizim üzerinden açıklamak gerekirse:
Beşiktaş’taki Alice, Şişli’deki Bob’a göndereceği mesajı broadcast ediyor. Broadcast mesajı Eve1 ve Eve2 kullanıcılarına ulaşıyor. Bunlar da mesajı tekrar broadcast ediyor. Eve2 kullanıcısı bir node’a yakın olduğu için mesajı oraya aktarıyor ve broadcast işlemini bitiriyor. Node ise üzerinde bulunan Bob, Utku ve Ahmet kullanıcıları için gelen mesajları düzenli olarak broadcast etmeye devam ediyor. Diğer taraftan Eve1’in broadcast mesajını da Eve3 alıyor. Onun da broadcast’i Bob’u, yani alıcıyı bulduğu için kendi işlemini sonlandırıyor. Böylece Bob, Eve3 üzerinden mesajını almış oluyor. Peki arada Eve3 olmasa ne olacaktı? Bob mesajı ancak node’un yanına gidip alabilecekti. Bu node’ları postane olarak düşünebilirsiniz. Kullanıcılar arada sırada bunların yanına giderek bana gelen mesaj var mı diye kontrol edebilirler. Bu node’ları büyük baz istasyonları gibi düşünmeyin. Bunlar gönüllülerin bu işe adayacağı ufak bilgisayarlar da olabilir. Örneğin bir kafe işletmecisi kullanmadığı bir bilgisayarı node’a çevirebilir. Böylece bu kafeye gelen kullanıcılar bu node’da kendilerini bekleyen bir mesaj varsa alabilir.
İşlem Hızlandırıcı Postacılar
Peki ya Şile’de köyde yaşayan bir insan Beşiktaş’a bu sistem üzerinden nasıl mesaj gönderecek? Aradaki insan sayısı kısıtlı olduğu için yukarıdaki yöntemlerle mesaj alıcıya asla ulaşmayacak. Burada devreye gönüllü postacı arabaları girecek. Örneğin bir araba, köydeki bütün broadcast mesajlarını toplayıp İstanbul’a doğru yola çıkacak. Arabası ile İstanbul’u dolaşarak mesajları bir çok node’a aktaracak. Böylece köylülerin hedef kullanıcıları bu node’lara geldiklerinde mesajlarını okuyabilecekler.
Mesaj Gizliliği ve Güvenliği
Konsepti anlatırken işin güvenlik kısmına değinmedim. Bu konseptte herkes herkesin mesajını taşıyabildiği için aslında gizlilik son derece ihlal ediliyor. Bu şekliyle tabi ki mantıklı değil. Ancak mesaj güvenliğini ve gizliliğini sağlamak mümkün. Burada odaklanacağımız üç nokta var:
1) “Utku”ya gidecek bir mesaj broadcast edilirken “Ziyahan” kullanıcısı “Ben Utku’yum” diye cevap verip mesajın iletimini durduramamalı (authentication)
2) Mesajın içeriği alıcısı hariç diğer insanlar tarafından okunamamalı (end-to-end encryption)
3) Mesajın içeriği iletim sırasında değiştirilmemeli (integrity)
Detayları anlatmaya başlamadan önce şunu belirtmek istiyorum. Kriptografi, özel eğitim isteyen bir bilim dalı ve benim bu konuda yüksek bir eğitimim yok. Hobi olarak üzerinde çalışıyorum. O yüzden aşağıda anlatacağım yöntemler, en doğru yöntemler olmayabilir.
Birinci ve ikinci problemi aşmak için asimetrik ve simetrik encryption algortmalarını hidrit bir biçimde kullanabiliriz. Burada HTTPS web sitelerine bağlanırken kullanılan tarz bir handshake (el sıkışma) modeli işletilebilir.
Öncelikli olarak kullanıcılar, internet varken uygulamayı indirip kayıt olmalıdır. Kayıt oldukları zaman, uygulama sunucusu kendilerine bir açık-gizli anahtar ikilisi (public-private key pair) verir. Bunun yanında bu anahtarların kişiye özel olduğunu ispatlayan, sunucunun gizli anahtarı tarafından encrypt edilmiş dijital imza verisini de gönderir. Aynı zamanda kullanıcıların cihazlarına bu dijital imzayı doğrulayabilmeleri için sunucunun açık anahtarını da gönderir.
Şimdi diyelim ki internet bağlantısı koptu ve Bob kullanıcısı Alice kullanıcısına bir mesaj yollamak istiyor. El sıkışma şuna benzeyecek:
Bob: Alice’e gidecek bir mesajım var, sen Alice misin?
Alice: Evet ben Alice’im.
Alice: Al sana sunucunun gizli anahtarı tarafından encrypt edilmiş açık anahtarım (dijital imza)
Bob: Alice’in gönderdiği dijital imzayı, cihazında bulunan sunucu açık anahtarı ile decrypt eder. Sonuç = karşımdaki kişi gerçekten Alice ve ben Alice’in açık anahtarına sahibim.
Bob: Buyrun sana ileteceğim mesajı alabilirsin.
Burada el sıkışma sonlanır ve Alice mesajı alır. Ancak burada kafamızı karıştıran bir boşluk var.
Bob bu mesajı doğrudan Alice’e gönderen kişiyse problem yok. Zaten Alice’in açık anahtarına el sıkışma esnasında sahip oldu. Mesajını bununla encrypt edip gönderebilir (Aslında hibrit encryption kullanıp simetrik anahtarını bununla encrypt edecek fakat konunun çok dallanıp budaklanmaması için es geçiyorum) Bob eğer bu mesajı taşıyan kişiyse, bu mesajı ilk yollayan kişi Alice’in açık anahtarına nasıl sahip olup mesajı onunla encrypt edecek?
Bu durum, offline iletişim ağının en zayıf noktalarından biri. Bunun aklıma gelen bir çözümü var: Bütün kullanıcılar uygulamaya kayıt olduklarında sistemdeki herkesin açık anahtarını cihazlarına indirmeli. Yani sisteme kayıtlı bin kişi varsa cihazınızda bin adet açık anahtar bilgisi olacak. Böylece örneğin Utku kullanıcısı, Alice’e bir mesaj iletmek istediği zaman, mesajı Alice’in açık anahtarı ile encrypt edecek. Daha sonra bu mesajı broadcast edecek. Bob da bu mesajı Alice’e iletmek üzere kendine alacak. Bob, Alice’in gizli anahtarına sahip olmadığı için içeriğini göremeyecek. Bunun yanında Bob, Alice’in dijital imzasına sahip olmadığı için, Utku kullanıcısına kendisini Alice olarak tanıtamayacak. Daha sonra Bob, Alice ile el sıkışma gerçekleştirip mesajı ona iletecek. Alice de kendi gizli anahtarıyla mesajı decrypt edip okuyabilecek.
Burada dikkat ettiyseniz bu anahtar sistemi kullanıcıların uygulamayı internet varlığında indirmesine bağımlı. Peki internet gittiğinde biri bu uygulamayı bir yerden edinip kullanamayacak mı? Bu kişi, uygulama sunucusundan dijital imza alamayacağı için kendisinin gerçek kişi olduğunu asla kanıtlayamayacak. Yani özel mesaj gönderme özelliğinden faydalanamayacak. Ancak halka açık şifresiz mesajlar yayınlamaması için bir sebep yok.
Bu tip kullanıcılar için node’larda halka açık kanallar tasarlanacak. Örneğin yeni kullanıcı “Karnım acıktı” şeklinde halka açık bir mesaj broadcast ettiği zaman eğer yakınında bir node varsa, bu mesaj o node’un halka açık kanalından yayınlanacak. Eğer yakınında bir node yoksa, çevresindeki kullanıcılar bu mesajı node’a iletmek için alacak, node yakınına geldiklerinde bu mesajı oraya iletecekler.
Diğer Güvenlik Problemleri
Güvenlik problemleri, mesaj içeriğiyle sınırlı kalmıyor. Diğer bir önemli sorun da Dos (Denial of Service) saldırıları olacaktır. Burada bir kullanıcı, saniyede yüzlerce mesaj broadcast edip çevresindeki insanların kapasitelerini doldurabilir. Fakat uygulama içine konulacak kontrol mekanizmalarıyla bu bir nebze aşılabilir.
Bunun yanında jamming saldırıları da problem yaratacaktır. Yani uzun lafın kısası, bu proje hayata geçirilmeden önce üzerine kafa yorulması gereken çok sayıda problem barındırıyor diyebiliriz.
Offline olarak kullanıcıların birbirleriyle mesajlaşmasını, dosya göndermesini sağlayan projeler mevcut. Örneğin: Firechat, hypelabs.io. Bu projeleri ilk gördüğümde daha önce yapılmış diye üzülmüştüm. Fakat inceleyince fark ettim ki, bu projeler yukarıda anlattığım gibi dağıtık bir konsepti desteklemiyor. Yani çevrendeki insanlarla mesajlaşabiliyorsun fakat uzaktaki bir kullanıcıya, diğer kullanıcılar üzerinden mesaj yollayamıyorsun.
Bunun yanında Amerika’da bazı üniversitelerde denenen çalışmalara denk geldim. Fakat şehir çapında hayata geçirilebilen bir dağıtık yapıya hiç rast gelmedim.