Sphinx: Lightning ve Nym’in temelini oluşturan anonim veri biçimi

Tor’dan daha güçlü ağ düzeyinde gizlilik sağlayabilen işlevsel bir mixnet, uzun zamandır gizlilik savunucularının, araştırmacıların ve cypherpunk’ların hayali olmuştur. Mixnet’ler Tor’dan önce ortaya çıkmıştır ve bugüne kadar en etkili şekilde kullanıldıkları örnek, e-postaları anonim olarak göndermek için kullanılan bir “tip 3” yeniden yönlendirici olan Mixminion olmuştur. Mixnet’in geliştirme çalışmaları durma noktasına geldiğinden beri — Mixminion’un başlıca geliştiricilerinden ikisi olan Nick Mathewson ve Roger Dingledine, Tor’u geliştirmek üzere bu projeden ayrıldığından beri — 2003’ten bu yana açık kaynaklı çalışmalar neredeyse hiç yapılmadı ve 2011’den beri hiçbir kod güncellemesi yapılmadı.

PANORAMIX ile başlayan ve Nym ile devam eden çabalar sayesinde, mixnet’ler geri döndü.

Önceki yazımızda ayrıntılı olarak açıklandığı üzere, Nym’in mixnet ağı, birbirlerine paket aktaran mix-düğümlerinden oluşur. Node' lar, işlemlerin zamanlama meta verilerini gizlemek için zamanlama gecikmeleri ekler ve yeterli gerçek trafik olmadığında sahte trafik üretir. Dolayısıyla Nym mixnet, mesaj tabanlı trafik açısından Tor veya VPN’lere (dVPN’ler dahil) kıyasla daha üstün bir gizlilik sağlar.

Mixnet’lerin asıl gizli sırrı, hem Nym hem de Lightning Network tarafından kullanılan Sphinx paket formatıdır. Sphinx’i anlamak zordur ve Lightning Network tarafından anonimliği garanti edecek şekilde kullanılmamaktadır. Öyleyse Sphinx’i derinlemesine inceleyelim ve onun bilmecelerini çözelim!

Sphinx nedir?

Sphinx¹ bir mesajı gönderen kişiden alıcıya anonim olarak iletir. Çoklu atlama sistemlerinde gönderenin anonimliği için gerekli olan çeşitli özellikleri sağlar:

1. Bit düzeyinde bağlantısızlık: Karıştırıcıya gelen herhangi bir paket, ağı gözlemleyen bir saldırgan tarafından ikili temsiline dayalı olarak giden herhangi bir paketle ilişkilendirilemez. Başka bir deyişle, paketler anonimdir.
2. Bütünlük: Saldırganın, mesajları değiştirip yeniden sisteme enjekte ederek hedefleri veya içerikleri hakkında bilgi elde etmeye çalıştığı etiketleme ve tekrar oynatma saldırıları gibi aktif saldırılara karşı direnç.
3. Yönlendirme bilgilerinin gizlenmesi: Hiçbir karıştırma node' u, bir paketin o ana kadar kaç atlama yaptığını veya bir mesajın yolunun uzunluğunu belirleyemez. Belirli bir karıştırma node' u için yalnızca kendisinden önceki ve sonraki karıştırma node' larını bilinir.

Sphinx ile, anonim yanıt paketleri, ağda iletilen Sphinx mesajlarından ayırt edilemeyen Tek Kullanımlık Yanıt Blokları (SURB’ler) sayesinde alıcıya anonimlik sağlayabilir.

Sphinx’in özeti

Bir Sphinx paketi, iki bağımsız bölümden oluşur:

1. Mesajı kaynaktan hedefe yönlendirmek için gerekli tüm bilgileri içeren bir başlık; ve
2. Gerçek mesaj içeriğinin içinde gizlendiği bir yük.

Nakamoto’nun, düğümlerin IP adresleri ve açık anahtarlarıyla temsil edildiği bir karıştırma ağı aracılığıyla Hal Finney’e anonim olarak bir mesaj göndermek istediği bir dünyayı düşünün. Nakamoto, yoldaki her bir karıştırma düğümünün şifrelenmiş bir paketi iletmek için gerekli yönlendirme bilgilerini çözebilmesini ve aynı zamanda yolun geri kalan kısmını gizli tutabilmesini sağlayacak şekilde anahtarları dağıtmalıdır.

Sphinx’in yapısı

İlk olarak Nakamoto bir rota seçer; her bir karıştırma node' unun açık anahtarını araştırır ve her biri için bir ortak anahtar hesaplar. Sphinx başlığının anahtar Sphinx başlığının anahtar bileşeni, tek bir grup öğesi ɑ'dır; bu öğe, node' ların açık anahtarlarıyla birleştirildiğinde, Diffie-Hellman anahtar değişimi yoluyla her biri için bir paylaşımlı anahtarın hesaplanmasına olanak tanır; böylece, kullanıcı tarafından seçilen rotadaki ilk node paketi bir sonrakine iletebilir ve yalnızca o karıştırma düğümü paketi şifresini çözebilir.

Bu geçici paylaşımlı anahtar s, bir düğümün, başlıktaki bütünlük etiketi ɣ’yi kontrol ederek paket başlığının değiştirilmediğinden emin olmak için gerekli anahtarları türetmesini, ve şifrelenmiş yönlendirme bilgisi β'yi deşifre etmesini sağlar; bu bilgi, göndericiden belirlenen karıştırma node' una, karıştırma node' unun neyi nereye iletmesi gerektiğine dair bir dizi talimat içerir.

Kullanıcı bazında paket korelasyonunu önlemek amacıyla, ɑ grup elemanı her karıştırma adımında kriptografik olarak gizlenir. Gizleme faktörü b, paylaşılan anahtar s'den elde edilir; böylece hem gönderen hem de ilgili karıştırma işlemi, paketleri iletmek için gerekli tüm işlemleri gerçekleştirebilir. Sphinx paketindeki δ yükü, bir saldırganın herhangi bir noktada yükü değiştirmesi durumunda mesaj içeriğinin geri dönüşümsüz bir şekilde kaybolmasını sağlamak amacıyla geniş blok şifreleme yöntemi kullanılarak hesaplanır. Başlıkta kodlanan ɣ bütünlük etiketi, yalnızca paket başlığının da değiştirilip değiştirilmediğinin kontrol edilmesini sağlar. Tüm paketlerin her atlamada aynı uzunluğa getirilmesi gerekir.

Başlığın sabit uzunluğunu korumayı sağlamak daha karmaşıktır. Sphinx, sabit paket boyutunun en az ek yük oluşturmasını sağlamak için gelişmiş bir dolgu tekniği kullanır.

Bir Sphinx paketi oluşturma

m mesajını M₀, M₁, M₂ karışımlarından oluşan seçilen bir yol üzerinden yönlendirmek için Nakamoto, yeni bir gizli değer x üretir ve x ile karışım node' larının açık anahtarlarını kullanarak tüm grup elemanları ɑ, paylaşılan anahtarlar s ve körleme faktörleri b’yi önceden hesaplar. Başlık kodlamasına, rotadaki her bir karışım node' u için IP adresi gibi yönlendirme bilgilerini, sonuncudan ilkine doğru başlık bütünlüğü etiketiyle katmanlara ayırarak başlar.

En içteki katman, Finney adresi ∆, ile SURB’ler için kullanılan I tanımlayıcısının ve yol uzunluğunun yanlışlıkla açığa çıkmamasını sağlayan dolgu dizisinin birleştirilmesiyle oluşturulur. Bunlar daha sonra, paylaşılan anahtar _s_₂ ile tohumlanan bir sözde rasgele sayı üretecinin çıktısıyla XOR işlemi uygulanarak şifrelenir. Sonuç, nihayetinde ɸ adlı bir dolgu dizesiyle birleştirilir; bu dizgenin eklenmesi, şifreleme katmanları eklendiğinde veya kaldırıldığında başlık paketlerinin boyutunun sabit kalmasını sağlar. Son şifrelenmiş yönlendirme bilgisi β₂ hazır olduğunda, Nakamoto bunun HMAC’sini bütünlük etiketi ɣ₂ = HMAC(_s_₂, β₂) olarak hesaplar ve bu yönlendirme bilgisi β’yi bütünlük kontrolü ɣ ile birleştirerek şifreler. İşlem, aşağıda gösterildiği gibi β₁ ile başlar ve ardından bir sonraki β’ye yinelemeli olarak devam eder:

Bir Sphinx paketinin oluşturulması: Gri renk ne kadar koyu olursa, şifreleme o kadar fazla olur!

Nakamoto daha sonra, hesaplanan ortak anahtarları yeniden kullanarak veri yükünü katmanlı olarak şifreler. Tıpkı başlıkta olduğu gibi, yükün kapsüllenmesi de mix node' ları üzerinden geçen rotanın ters sırasına göre gerçekleştirilir. İlk δ_₂_, geniş blok şifreleme yöntemi kullanılarak, s₂ anahtarıyla, m mesajının, Finney adresi ∆ ve sıfır baytlı dolgu dizisinin birleştirilmesinden oluşur; bu, gövdenin aktarım sırasında değiştirilmediğinin doğrulanmasını sağlar — saldırgan tarafından tek bir bit bile değiştirilirse, geniş blok şifreleme algoritması yükü rastgele bitlere dönüştürür.

Finney'in, ek olarak bilinen dizili sıfır bayt dolgu kullanılarak mesajın geçerli bir mesaj mı yoksa rastgele bir şifreli metin mi olduğunu ayırt edebilmesi gerekmektedir. δ_₂_ hazır olduğunda, Nakamoto bunu s₁ ve s₀ kullanarak tek tek yeniden şifreler.

Bir Sphinx paketinin işlenmesi

1. Bir paket aldığında, karıştırma düğümü başlıktan ɑ grup elemanını çıkarır ve paylaşılan anahtar s’yi türetmek amacıyla bunu kendi gizli anahtarıyla birleştirir.
2. s kullanılarak, karışım şifrelenmiş yönlendirme bilgilerinin anahtarlı hash değerini HMAC(s, β) olarak hesaplar ve bunu paket başlığına eklenmiş ɣ bütünlük etiketiyle karşılaştırır. Başlıkta tahrifat yapıldığı için bütünlük denetimi başarısız olursa, paket atılır. Aksi takdirde, karıştırma node' u 3. adıma geçer.
3. Mix düğümü artık ekli β dosyasının şifresini çözmeye hazırdır. Yönlendirme talimatlarını çıkarmak için, karıştırma düğümü öncelikle β’nin sonuna sıfır baytlık bir dolgu ekler ve s kullanılarak üretilen sözde rastgele bayt akışıyla XOR işlemi uygulayarak, doldurulmuş yönlendirme bilgisi bloğu B’nin şifresini çözer. β’ye eklenen sıfır bayt dolgu miktarı, uzunluk değişmezliğini korumak için karıştırma düğümünün ayıklaması gereken yönlendirme talimatlarının uzunluğuna eşittir. Dolgu, bütünlük etiketi ɣ içinde karma işleme tabi tutulduğundan, Nakamoto tarafından önceden oluşturulmuş dolgu ile tamamen aynı olması gerektiğine dikkat edin.
4. Karıştırma düğümü, bir sonraki karıştırma düğümünün adresini (veya son atlama noktası durumunda, hedef adresi ∆ ve tanımlayıcı I’yi) elde etmek amacıyla B’den gelen yönlendirme talimatlarını çözümler; ayrıca bir sonraki atlama noktasına iletilmesi gereken yeni bütünlük etiketleri ɣ’ ve β’yi de elde eder.
5. Karıştırma düğümü ayrıca δ'nin geniş blok şifresini çözerek δ’yi elde eder; bu değer bir sonraki durağa iletilir.
6. Karıştırma düğümü, paylaşılan anahtar s’den türetilen bir gizleme faktörü kullanarak alınan ɑ değerini gizler ve böylece yeni bir grup elemanı ɑ’ elde eder.

Hem başlık hem de veri yükü şifrelendikten ve grup öğesi gizlendikten sonra, karıştırma node' u ((ɑ’, β’, ɣ’), δ’) şeklinde yeni bir paket oluşturabilir ve bunu bir sonraki adrese iletebilir.

Sphinx paket formatının orijinal şeması, Danezis ve Goldberg (2014)

Nym, Sphinx’e yönelik saldırıları nasıl engelliyor?

Sphinx’in en önemli özelliklerinden biri, kanıtlanabilir şekilde güvenli olmasıdır — orijinal makale, varsaydığı özelliklerin güvenlik kanıtını sunmaktadır. Genel olarak, bir tasarımın gerçekten de bir dizi matematiksel varsayımdan mantıksal olarak kanıtlanabilen bir dizi özelliğe sahip olduğunu göstermek için, kriptografların genellikle elle gerçekleştirdiği güvenlik kanıtlarına ihtiyaç duyarız. Gizlilik özelliklerini kanıtlamak çok daha zordur; bu süreç genellikle simülasyon gerektirir.

Kriptograflar güvenlik kanıtlarını elle hazırlarken, hatalar yapabilirler ya da kanıtlamak istedikleri hususların bazı yönlerini gözden kaçırabilirler. Kuhn ve ark.² tarafından yapılan çalışma, Camenisch ve Lysyanskaya³ tarafından soğan yönlendirmesine dayalı sistemler için tanımlanan biçimsel özelliklerin yetersiz olması nedeniyle, Danezis ve Goldberg tarafından sunulan güvenlik kanıtında Sphinx paketinin orijinal tasarımındaki önemli bir kusurun tespit edilemediğini göstermektedir. Bu güvenlik açığı giderilmezse, Sphinx’i kullanan sistemlerdeki kullanıcıların gizliliğine ciddi zarar verebilir.

Orijinal Sphinx tasarımında sıfır baytlık dolgu kullanılması önerilmişti; ancak bu dolgu, yalnızca bir dizi sıfırdan oluşuyordu. Zira bu dolgu, yoldaki son karıştırma node' unun yolun uzunluğu hakkında bilgi edinmesine olanak tanıyarak Sphinx’in vaat ettiği güvenlik özelliklerinden birini bozuyor ve muhtemelen rota hakkında önemli bilgiler, hatta nihai varış noktası hakkında bile bilgi edinilmesine yol açıyordu.

Daha önce açıklandığı gibi, rotadaki son karışım node' u, alıcı adresinin (∆), bir tanımlayıcının (I) ve sıfır baytlık bir dolgu olarak şifrelenmesiyle oluşturulan ve dolgu dizesi ɸ ile birleştirilen şifrelenmiş yönlendirme bilgisinin en iç katmanını β alır.

Sphinx makalesinde kullanılan gösterime göre, en içteki β şu şekilde oluşturulur:

burada |ɸ| = 2(v-1)κ olup, κ ve r sırasıyla güvenlik parametresi ve maksimum yol uzunluğudur; v ise paketin izlediği yolun uzunluğudur. Alınan β değerinin karışım node' u tarafından işlenmesi şu şekilde gerçekleştirilir:

Peki, son karışım node' u bu sihirli matematik işleminden yol uzunluğuna dair nasıl bir bilgiye ulaşır?

Bu saldırının nasıl işlediğini açıklamak için basit bir örnek vereceğiz. Öncelikle, x = a⊕b değeri verildiğinde, hem x hem de a ve b’nin uzunluklarının aynı olduğunu hatırlayalım; x ile b’yi XOR işlemiyle birleştirirsek x⊕b sonucunu elde ederiz = a⊕b⊕b = a sonucunu elde ederiz. Örneğimiz için, v-1 düğümünün paylaşılan anahtarını girdi olarak alan PRNG’nin çıktısının 10101010101010101010… olduğunu varsayalım.

Şimdi, “last mix” tarafından alınan aşağıdaki β değerini ele alalım

Şimdi, (2)’ye göre, β’yi şifresini çözmek ve ayrıştırmak için çıkış karışım node' unun yapacağı işlemlerin aynısını gerçekleştiriyoruz

Tasarım gereği, yoldaki son karıştırma node' u, beklenen β’nin toplam uzunluğunu (örneğimizde 9 bit idi) bilir ve hedef adresin (∆) ile tanımlayıcı (I)’nin birleştirilmesinin ardından sırasıyla sıfırla doldurma ve dolgu dizisinin sözde rastgele bitlerinin geldiğini bilir. ∆ ve I uzunluklarının tam olarak bilindiği durumda, dürüst ama meraklı son karıştırma node' u, dolgu dizesinin orada ya da daha önce başladığını bildiği için, tanımlayıcının ardından ilk 1 bitinin nerede olduğunu arar. Tanımlayıcının ardından gelen ilk 1 bitin hangi konumda olduğu bilgisi, son karıştırma işleminin dolgu dizesinin uzunluğunun alt sınırını belirlemesine olanak tanır. ɸ'nin toplam uzunluğu, tasarım gereği rota uzunluğunun iki katı ile güvenlik parametresi κ'nin çarpımı olarak tanımlandığından, dolgu dizesinin uzunluğunun alt sınırı, kullanılan yolun uzunluğunun alt sınırı hakkındaki bilgiyi sızdırır.

Yolun uzunluğunu bilmek neden zararlıdır?

Araştırmaların da gösterdiği gibi,⁴ kısıtlı veya seyrek topolojiler kullanan ağlarda (örneğin Lightning), yol uzunluğunun bilinmesi, gönderenin gizlenebileceği anonimlik kümesini daraltır. Aşağıdaki şekildeki örnek, yol uzunluğunun alt sınırının bilinmesinin göndericinin anonimliğini nasıl azaltabileceğini göstermektedir. D, bir çıkış karışım node' u olarak işlev görür ve bir paketi Timmy’ye iletirse, yolun uzunluğu bilinmediği için A, B, C, E, G veya F node' larından herhangi biri gönderen olabilir. Ancak, D yol uzunluğunun en az 3 olduğunu çıkarabilirse, ağ grafiğine bakarak gönderenin yalnızca A ya da B olabileceği sonucuna varırız; dolayısıyla potansiyel gönderenlerin kümesi önemli ölçüde azalır.

Bu saldırıyı önlemek oldukça basittir. (1)’de, sıfırla doldurma yerine β’yi oluşturduğumuzda, rastgele bitlerle doldurma yöntemini kullanmamız yeterlidir. Aslında, George Danezis’in Python uygulaması bu kusuru zaten tespit ediyor.

Şekil 1

Ancak bu saldırı Nym’i etkilemiyor

1. Nym, anonimliği en üst düzeye çıkarmak amacıyla tabakalı bir topoloji kullanır; bu sayede tüm yollar eşit uzunluktadır ve her bir karıştırma node' u, yol içindeki konumunu bilir. Lightning’de durum böyle değildir. Değişken uzunlukta yollar kullandığı için, Sphinx'in orijinal uygulaması bu saldırıya karşı savunmasızdı; ancak bu sorun artık düzeltilmiştir.
2. Sphinx şifrelemesinin son katmanı, (Tor’da olduğu gibi) çıkış karışımı tarafından değil, uygulamanın kendisi tarafından kaldırılır. Bununla birlikte, Nym’in Rust dilinde yazılmış Sphinx uygulaması bu saldırıya karşı dayanıklıdır (rastgele dolgu kullanır) ve bu nedenle Sphinx tabanlı herhangi bir tasarımda güvenle yeniden kullanılabilir.

Nym için bundan sonra ne olacak?

Nym’in gönderdiği ilk anonim Sphinx paketi, sonuncusu olmayacak. Nym ağı, zamanla her türlü internet uygulaması için kullanılabilecek istikrarlı ve genel amaçlı bir mixnet’e dönüşecektir. Test ağımız halihazırda çalışır durumda ve 2020’nin sonuna kadar üretim ortamına geçmesi bekleniyor.

Ama zaten kim ağ düzeyinde gizliliğe ihtiyaç duyar ki? Görünüşe göre neredeyse herkes.

Lightning Network halihazırda Sphinx paketlerini kullanmaktadır; ancak Claudia Diaz’ın Kasım 2019’da düzenlenen Lightning Konferansı’nda gösterdiği gibi, bu kullanım şekli işlemlerin gizliliğini sağlama özelliğini ihlal etmektedir. Bazı değişikliklerle Lightning’in gizlilik özellikleri geliştirilebilir; zira Lightning, Sphinx gibi birçok altyapı bileşenini halihazırda Nym ile paylaşıyor. Nym ve Lightning’in birleşimi, Bitcoin’i gizli hale getirmek için en uygulanabilir yol olabilir.

(iframe src="https://www.youtube.com/embed/g55kMhggIBY?feature=oembed" width="700" height="393")(/iframe)

Claudia Diaz, Sphinx’in Lightning’in gizliliğine neden yardımcı olmadığını ve bunun nasıl düzeltilebileceğini anlatıyor.

Gizlilik özellikleri güçlendirilmiş kripto para birimleri ve herhangi bir kripto para biriminin yan zincirleri de ağ düzeyinde anonimlik kullanmalıdır; aksi takdirde saldırganlar zamanlama verilerini kullanarak paketlerin anonimliğini ortadan kaldırabilir ve hatta zkSNARKS gibi zincir içi gizlilik tekniklerine yönelik saldırılara yol açabilir. Şu anda çeşitli topluluklarla iletişim kuruyoruz ve yakında bu konuda daha fazla bilgi paylaşacağız.

Brave ve diğerlerinin merkezi olmayan VPN’lere gösterdiği ilgiyi de unutmayalım. Sphinx paketleri ne kadar hızlı iletilebilir? Sphinx, bağlantı kurulamazlığı sağlamak için çok sayıda asimetrik kriptografi ve sıra dışı geniş blok şifreleme algoritmaları kullanıyor; ancak belki de bu tür kullanım senaryolarını gerçeğe dönüştürecek hızlara ulaşmak üzere yeniden tasarlanabilir.

Sphinx, sıradan internet paketlerine anonimlik gücü kazandırır — ancak büyük güç, büyük sorumluluk da beraberinde getirir. Bu sorumluluğu üstlenecek ve Nym üzerine yeni hizmetler ve uygulamaların nasıl gelişeceğini merakla bekliyoruz!

Kaynaklar

¹ George Danezis ve Ian Goldberg. Sphinx: Kompakt ve güvenliği kanıtlanmış bir karıştırma biçimi. IEEE Güvenlik ve Gizlilik Sempozyumu’nda, s. 269–282. IEEE, 2009.

² Christiane Kuhn, Martin Beck, and Thorsten Strufe. Kanıtlanabilir şekilde güvenli soğan yönlendirmesinin kırılması ve (kısmen) düzeltilmesi. arXiv preprint arXiv:1910.13772, 2019.

³ Jan Camenisch and Anna Lysyanskaya. Soğan yönlendirmesinin resmi bir ele alınışı. Yıllık Uluslararası Kriptoloji Konferansı’nda, s. 169–187. Springer, 2005.

⁴ George Danezis. Kısıtlı rotalara sahip karışık ağlar. “Gizliliği Artırıcı Teknolojiler Üzerine Uluslararası Çalıştay”, s. 1–17. Springer, 2003.