FC-GUARD, geleneksel itibari paranın kripto paraya dönüştürüldüğü işlemlerde kullanıcının gerçek kimliği, banka hesabı ve kripto para adresinin tek bir işlem kaydı üzerinden ilişkilendirilmesini önlemeyi amaçlayan, doğrulanabilir kimlik bilgileri (Verifiable Credentials, VC), doğrulanabilir sunumlar (Verifiable Presentations, VP) ve sıfır bilgi ispatları (Zero-Knowledge Proofs, ZKP) kullanan bir gizlilik korumalı değişim sistemi tasarımıdır. Shaoyu Li, Hexuan Yu, Md Mohaimin Al Barat, Yang Xiao, Y. Thomas Hou ve Wenjing Lou tarafından geliştirilen çalışma, anonimlik ile Müşterini Tanı (Know Your Customer, KYC) ve vergi denetimi gerekliliklerini aynı işlem altyapısında birleştirmeyi hedeflemektedir.

Araştırmanın çıkış noktası, geleneksel kripto para alım platformlarının kullanıcıya ait kişisel kimlik bilgilerini (Personally Identifiable Information, PII), banka hesaplarını ve kripto para adreslerini birbirleriyle ilişkilendirilebilir biçimde saklayabilmesidir. Böyle bir veri deposunun ele geçirilmesi yalnız isim veya hesap numarası sızıntısına neden olmaz; kamuya açık blokzincir kayıtlarından kullanıcının işlem geçmişinin gerçek kimliğiyle eşleştirilmesi riskini de doğurur. FC-GUARD bu ilişkiyi işlem sırasında sınırlandırmak amacıyla hassas bilgilerin doğrudan açıklanması yerine kriptografik doğrulama mekanizmaları kullanmaktadır.

Önerilen sistem üç ana aşamadan oluşmaktadır: kullanıcı kimliğinin bir kez doğrulanarak kimlik bilgisinin düzenlenmesi, sonraki itibari para–kripto para dönüşümlerinin anonim kimlik doğrulamasıyla gerçekleştirilmesi ve gerektiğinde yetkili makamın şifreli kimlik üzerinden denetim yapabilmesi. İlk kayıt aşaması anonim değildir; kullanıcı PII bilgilerini platforma sunar. Gizlilik koruması, kayıt sonrasında gerçekleştirilen değişim işlemleri için tasarlanmıştır. Bu ayrım sistemin güvenlik iddiasının doğru anlaşılması bakımından önemlidir.

Araştırmacılar FC-GUARD prototipini masaüstü ve Android ortamlarında gerçekleştirmiştir. Sunucularda Amazon EC2 c5.large örnekleri, istemci tarafında Intel Xeon tabanlı iş istasyonu ve Google Pixel 8a kullanılmış; kriptografik işlemler Hyperledger AnonCreds, Hyperledger Indy ve 2048 bit ElGamal şifrelemesiyle desteklenmiştir. Kripto para transferleri yerel Bitcoin test ağında değerlendirilmiştir.

Kaynak sonuçlarına göre masaüstünde bir defalık kullanıcı kaydı FC-GUARD ile 156,95 ms, temel karşılaştırma sisteminde 5,11 ms sürmüştür. Değişim işleminde kimlik doğrulama aşaması masaüstü FC-GUARD için 464,87 ms, mobil uygulamada 3,40 saniye olarak raporlanmıştır. Banka etkileşiminde masaüstü FC-GUARD 363,27 ms, mobil sürüm 298,32 ms ölçülmüştür. Denetim işleminin toplam süresi temel sistemde 2,65 ms iken FC-GUARD'da 362,52 ms olarak bildirilmiştir.

Bu ölçümler ek kriptografik işlemlerin belirgin maliyet oluşturduğunu, fakat araştırmanın test ortamında masaüstü ve mobil uygulamaların gerçekleştirilebildiğini göstermektedir. Bununla birlikte çalışma gerçek bir finans kuruluşunda geniş ölçekli üretim dağıtımını, bütün ülke mevzuatlarına uyumu veya kötü niyetli tüm taraf birleşimlerine karşı güvenliği doğrulamamaktadır. Türkiye gibi farklı bankacılık ve kimlik doğrulama altyapılarına sahip ülkelerde uygulama için ayrıca teknik, hukuki ve operasyonel uyarlama gerekir.

İtibari para ile kripto para arasındaki geçişte temel gizlilik sorunu

İtibari para (fiat currency), değeri devletin ve para sisteminin kabulüne dayanan geleneksel para birimidir. ABD doları gibi itibari paralar bankacılık sisteminde hesap bakiyeleri ve elektronik transferlerle kullanılabilir. Kripto paralar ise dağıtık defter veya blokzincir üzerinde temsil edilen dijital varlıklardır. Bu iki finansal alan arasında para dönüşümü gerçekleştiren platformlar, kullanıcının bankadaki parasını alıp karşılığında belirlenen kripto para adresine dijital varlık gönderebilir.

Geleneksel işlemde platform çoğunlukla kullanıcının gerçek kimliğini, banka hesap bilgilerini, platform hesabını ve kripto para adresini öğrenir. Bunun bir bölümü kimlik doğrulama, sahtekârlık önleme ve mevzuat yükümlülüklerinden kaynaklanmaktadır. Ancak bütün bu bilgilerin aynı kuruluşta birlikte bulunması ciddi bir gizlilik sorunu yaratır.

Blokzincir adresleri doğrudan bir kişinin adını içermese de pek çok kamusal blokzincirde işlemler herkes tarafından incelenebilir. Gerçek kimlikle kripto para adresi arasındaki bağlantı bir defa ortaya çıktığında, aynı adresle ilişkili geçmiş ve gelecek hareketlerin kullanıcıyla ilişkilendirilmesi mümkün hale gelebilir. Kaynak, bu sorunu geri döndürülmesi güç kimlik çözülmesi veya anonimliğin kaybedilmesi olarak tartışmaktadır.

FC-GUARD'ın temel yaklaşımı, platformu tüm bilgileri görebilen merkezî bir veri deposu olmaktan uzaklaştırmaktır. Platform işlemin geçerli olduğunu doğrulamalı ve kripto para gönderebilmelidir; ancak bunu yapmak için kullanıcının açık banka hesap numarasını veya işlem sırasında gerçek kimliğini öğrenmesi zorunlu olmamalıdır.

Geleneksel sistem ile FC-GUARD arasındaki fark

Geleneksel süreçte platformun bir kullanıcı hesabını banka hesabı ve kripto para adresiyle eşleştirebilmesi mümkünken, FC-GUARD'ın işlem mesajında kullanıcı gerçek kimliği yerine anonim bir kimlik ispatı, bankanın çözebileceği şifreli hesap bilgisi ve kripto para adresi bulunur.

Bu tasarım bankanın müşteriyi ve hesabını bilmesini engellemez. Banka, itibari para transferini gerçekleştirmek için gerçek hesabı öğrenmek zorundadır. Aynı şekilde platformun kripto para transferi için hedef adresi bilmesi gerekir. Amaç herkesin bütün bilgileri bilmemesi ve tek bir tarafın kimlik ile kripto işlem geçmişini bağımsız olarak eşleştirememesidir.

FC-GUARD Anonimliği Kimlik Doğrulamasını Kaldırmadan Nasıl Sağlar?

FC-GUARD, kullanıcıyı ilk kayıt sırasında gerçek kimliğiyle doğrulayıp daha sonra bu doğrulamadan türetilen, birbiriyle ilişkilendirilememesi amaçlanan doğrulanabilir sunumlar kullanır. Platform böylece işlemi yapan kişinin geçerli bir kimlik bilgisine sahip olduğunu kontrol edebilir; ancak değişim aşamasında hangi kayıtlı kişinin işlem yaptığını doğrudan öğrenmek zorunda kalmaz.

Sistemin beş tarafı

Araştırmanın tehdit ve işlem modelinde beş temel taraf bulunmaktadır:

Buradaki SSA, ABD Sosyal Güvenlik İdaresini (Social Security Administration), SSN ise Sosyal Güvenlik Numarasını (Social Security Number) ifade eder. Bunlar çalışmanın ABD merkezli kimlik doğrulama senaryosuna özgü bileşenlerdir. Başka ülkelerde bunların doğrudan aynı kurum ve numaralarla karşılanacağı varsayılamaz.

Doğrulanabilir kimlik bilgisi nedir?

Verifiable Credential (VC), bir düzenleyici tarafından belirli niteliklerin doğruluğunun kriptografik olarak onaylandığı dijital kimlik bilgisidir. Düzenleyici (issuer), kullanıcıya ait nitelikleri imzalar. Kullanıcı (holder) bu bilgiyi saklar ve gerektiğinde doğrulayıcıya (verifier) niteliklerin geçerli olduğuna ilişkin kanıt sunar.

Örneğin FC-GUARD'da platformun düzenlediği kimlik bilgisinde ad, doğum tarihi ve SSN yer alırken bankanın düzenlediği bilgi bankanın adı, hesap numarası ve SSN ile ilişkilidir. Her iki bilgi farklı kurumlar tarafından imzalanmış olabilir. Kullanıcı bunların belirli bölümlerini açıklamadan doğrulanmasını sağlayan bir sunum üretebilir.

VC ile VP arasındaki fark

VC temel kimlik belgesinin kriptografik karşılığıdır. Verifiable Presentation (VP) ise bu belgeden belirli bir doğrulama için hazırlanmış sunumdur. Bir VC uzun süre geçerli kalabilirken farklı işlemlerde farklı VP çıktıları oluşturulabilir. Böylece aynı kimlik bilgisi kullanılsa bile platformun sunumları doğrudan birbirine bağlamaması hedeflenir.

Kaynak bu özelliğin imza rastgeleleştirmesi ve sıfır bilgi ispatlarıyla desteklendiğini anlatmaktadır. Bir sunumun doğrulanabilmesi, kullanıcının gerçek adının veya SSN değerinin doğrulayıcıya gösterilmesini zorunlu kılmaz.

Sıfır bilgi ispatı nedir?

Zero-Knowledge Proof (ZKP), bir tarafın belirli bir bilgiyi bildiğini veya belirli bir koşulun doğru olduğunu, ilgili gizli bilgiyi açıklamadan kanıtlamasını sağlayan kriptografik yöntemler ailesidir.

FC-GUARD'da bu yaklaşım birden fazla yerde kullanılmaktadır. Kullanıcı geçerli bir VC'ye sahip olduğunu, banka hesabıyla ilişkili gizli kimlik niteliğinin platform kimlik bilgisiyle uyuştuğunu veya şifrelenmiş hesabın doğrulanan bilgiyle ilişkili olduğunu kanıtlayabilir. Platform bu ispatı denetler; fakat ispatın doğruladığı gizli değeri açık metin olarak almak zorunda değildir.

Bu mekanizma ispatın kendisinin rastgele tahmin edilen bir sayı olduğu anlamına gelmez. İspat geçerli bir kimlik bilgisi, imza ve ilgili gizli nitelikler arasındaki matematiksel ilişkileri doğrular. Yöntemin güvenliği kullanılan kriptografik yapıların varsayımlarına bağlıdır.

Seçici açıklama ve yaş doğrulaması

Kaynak, kimlik bilgilerinin yalnız istenen niteliklerini açığa çıkarabilen doğrulanabilir sunumları tartışır. Örneğin kullanıcı doğum tarihini doğrudan paylaşmadan yaşının belirli bir \(x\) eşik değerinden büyük olduğunu bir aralık ispatıyla gösterebilir.

Bu kullanımda doğrulayıcının öğrenmesi gereken şey bütün doğum tarihi değil, gerekli yaş koşulunun karşılanıp karşılanmadığıdır. Kaynakta yaş doğrulaması örnek bir ek kimlik koşulu olarak verilmiştir; FC-GUARD performans ölçümlerinde bütün işlemlerin belirli bir yaş eşiği kullandığı belirtilmemektedir.

Bir defalık kayıt neden anonim değil?

İlk kayıt sırasında platformun gerçek kimlik doğrulaması yapması gerekir. Kullanıcı PII bilgilerini sunar; platform SSA doğrulamasını gerçekleştirir ve başarılı olursa kullanıcıya imzalı VC düzenler. Kullanıcı bu kimlik bilgisini kendi gizli cüzdanında saklar.

Bu nedenle “FC-GUARD hiçbir aşamada PII toplamaz” ifadesi yanlış olur. Çalışma ilk kayıt ile sonraki değişim işlemlerini birbirinden ayırmaktadır. Gizlilik kazanımı, kayıtlı kullanıcı ile yeni kripto işlemleri arasındaki doğrudan bağlantının işlem sırasında kurulmasını önlemeye yöneliktir.

Kimlik bilgisi oluşturma sisteminin matematiği

Kaynak, doğrulanabilir kimlik bilgilerinin kriptografik temelini açıklarken Camenisch–Lysyanskaya (CL) imza yapısına ilişkin bir anahtar oluşturma anlatımı vermektedir. Bu yapıda başlangıç olarak yaklaşık 1536 bitlik iki asal sayı \(p'\) ve \(q'\) seçilir; ardından aşağıdaki ilişkilerle \(p\) ve \(q\) oluşturulur:

\[ p=2p'+1,\qquad q=2q'+1 \]

Kaynak bu yeni sayıların da asal olmasını şart koşar. Ardından:

\[ n=pq \]

hesaplanır. Buradaki \(n\), daha sonraki modüler aritmetik işlemlerinde kullanılan bileşik modüldür. İki büyük asalın çarpımı kullanıldığı için sistemin matematiksel yapısı sıradan küçük tam sayı hesabından farklıdır.

Kaynak, modül \(n\) altında rastgele bir kuadratik kalıntı \(S\) seçildiğini ve aşağıdaki üsler üretildiğini belirtir:

\[ x_Z,x_{R_1},\ldots,x_{R_l}\in[2,p'q'-1] \]

Ardından hesaplanan değerler:

\[ Z=S^{x_Z}\pmod n \]

\[ R_i=S^{x_{R_i}}\pmod n \qquad (1\le i\le l) \]

şeklindedir. \(\pmod n\) gösterimi, üs alma işleminin sonucunun \(n\) modülüne göre değerlendirildiğini belirtir. \(l\), kimlik bilgisi şemasındaki ilgili niteliklerin sayısal indeks yapısını temsil eder.

Kaynakta bu anlatımın sonunda açık anahtar:

\[ pk=(n,S,Z,\{R_i\}_{1\le i\le l}) \]

ve özel anahtar:

\[ sk=(p,q) \]

olarak gösterilir.

Önemli yöntem notu: Bu denklemler kaynakta sunulan kimlik bilgisi altyapısının matematiksel arka planını temsil eder. Kaynak daha sonraki bölümde NIZK için BBS+ imza temelli ispatlardan ve uygulamada Hyperledger AnonCreds kullanımından söz etmektedir. Farklı imza yapıları kaynakta tek bir ayrıntılı ortak ispat algoritmasına indirgenmediği için, CL anahtar denklemleri bütün FC-GUARD ispatlarının eksiksiz üretim algoritmasıymış gibi sunulmamalıdır.

Kimlik bilgisinin düzenlenme sırası

Kaynak Şekil 3'te düzenleyici, açık kayıt defteri, kimlik bilgisi sahibi ve doğrulayıcı arasındaki işlemleri göstermektedir. Temel süreçte kimlik şeması ve tanımı yayımlanır, kullanıcı şema bilgilerini alır, güvenli iletişim kanalı açılır, kimlik bilgisi talep edilir, düzenleyici bu talebi inceler ve imzalı kimlik bilgisi kullanıcıya ulaştırılır. Doğrulama sırasında kullanıcı kimlik bilgisinden bir VP üretir; doğrulayıcı ise sunumu ve gerekli ispatları denetler.

Kaynakta kimlik bilgisi sahibinin bir gizli bağlantı sırrı oluşturduğu ve bu sırrın körlenmiş biçiminin kimlik bilgisi talebinde kullanıldığı da anlatılmaktadır. Bu mekanizma birden fazla kimlik bilgisinin sahibine bağlanmasını desteklerken ilgili gizli değerin doğrudan açıklanmasını önlemeyi hedefler.

Platformun oluşturduğu VC ve bankanın oluşturduğu VC

Çalışmada iki farklı kurum tarafından düzenlenen kimlik bilgileri kullanılmaktadır. Platformun verdiği kimlik bilgisi, kullanıcının gerçek kimliğinin doğrulandığını temsil eder. Bankanın verdiği kimlik bilgisi ise bankanın adı, kullanıcı hesabı ve ilgili kimlik niteliği arasında doğrulanabilir bir ilişki kurar.

Kaynakta bankanın düzenlediği bilgi aşağıdaki biçimde gösterilmektedir:

\[ VC_{bu}=(name_b,AccNum_{bu},SSN_u,\sigma_{bu}) \]

\(name_b\) banka adını, \(AccNum_{bu}\) kullanıcının banka hesap numarasını, \(SSN_u\) kullanıcının SSN değerini, \(\sigma_{bu}\) ise kimlik bilgisi imzasını temsil eder.

Platform tarafından düzenlenen bilgi ise:

\[ VC_{pu}=(name,birthday,SSN_u,\sigma_{pu}) \]

şeklindedir. Kullanıcının adı, doğum tarihi ve SSN bilgisi platformun imzasıyla doğrulanabilir hale getirilir. Bu bilgilerin iki farklı kurumda bulunması, sonraki anonim değişim aşamasında kimlik ve banka hesabının uygunluğunu ayrı ayrı doğrulama olanağı sağlar.

Kripto para değişim işleminin birinci aşaması: platform doğrulaması

Kullanıcı dönüştürmek istediği itibari para miktarı, kripto para türü ve hedef kripto adresi için bir değişim isteği başlatır. Platform kullanıcının açık gerçek kimliğini istemek yerine platform VC'sinden oluşturulmuş bir doğrulanabilir sunumu kontrol eder.

Kaynak sunumu şu biçimde gösterir:

\[ VP_{pu}=(name',birthday',SSN'_u,Proof_{pu}) \]

Üstteki kesme işaretleri gizlenen nitelikleri temsil eder; bu gösterim kullanıcı adının veya doğum tarihinin yeni bir değere dönüştürüldüğü anlamına gelmez. \(Proof_{pu}\) ise kullanıcının geçerli bir platform kimlik bilgisine sahip olduğunu doğrulayan sıfır bilgi ispatıdır.

Platform doğrulama başarılı olduğunda işlem kimliği (Order ID) ve gerekli itibari para tutarını içeren bir emir oluşturur. Kullanıcı daha sonra banka tarafındaki işlemler için bankanın verdiği kimlik bilgisinden ayrı bir VP üretir.

İkinci aşama: banka hesabını açıklamadan doğrulama

Banka doğrulamasının amacı, kullanıcının gerçekten geçerli bir banka hesabına sahip olduğunu göstermek, ancak hesap numarasını platforma açık metin halinde göndermemektir. Kullanıcı hesap numarasını bankanın açık anahtarıyla şifreler:

\[ Enc_{pk_b}(AccNum_{bu}) \]

Buradaki \(Enc\) şifreleme işlemini, \(pk_b\) bankanın açık anahtarını ve \(AccNum_{bu}\) kullanıcının banka hesap numarasını temsil eder.

Şifreli bilgi platform üzerinden bankaya aktarılabilir. Platform şifreli veriyi taşır ama bankanın özel anahtarına sahip olmadığı için hesap numarasını doğrudan çözmesi beklenmez. Banka ise kendi özel anahtarıyla hesabı geri elde eder:

\[ AccNum_{bu}=Dec_{sk_b}(Enc_{pk_b}(AccNum_{bu})) \]

\(Dec\) şifre çözmeyi, \(sk_b\) bankaya ait özel anahtarı temsil eder. Bu denklemde şifrelemenin bankanın açık anahtarıyla, çözmenin ise ilgili özel anahtarla gerçekleştirildiği görülür.

Banka VP'si ve gizli kimlik eşitliği

Kaynak banka doğrulanabilir sunumunu şu biçimde verir:

\[ VP_{bu}=(name_b,AccNum'_{bu},SSN'_u,Proof_{bu}) \]

Bu sunumda banka adı açıklanırken hesap numarası ve SSN gizli tutulur. \(Proof_{bu}\), banka kimlik bilgisinin geçerliliğine ve şifreli hesapla ilişkili gerekli koşullara ilişkin ispatı temsil eder.

Araştırma ayrıca platform kimlik bilgisindeki gizli SSN niteliği ile banka kimlik bilgisindeki gizli SSN niteliğinin aynı kişiye karşılık geldiğinin gösterilmesi için bir eşitlik ispatı tanımlar:

\[ Proof_{eq}(SSN'_u\text{ in }VP_{pu}=SSN'_u\text{ in }VP_{bu}) \]

Bu gösterimin amacı SSN değerinin herkese açıklanması değil, iki ayrı doğrulanabilir sunumda gizlenen kimlik niteliğinin tutarlı olduğunun kanıtlanmasıdır. Platform iki sunumun aynı uygun kullanıcıya ait olmasını doğrularken gerçek SSN değerini işlem aşamasında öğrenmek zorunda kalmaz.

Üçüncü aşama: itibari para ve kripto para transferi

Platform banka adını kullanarak ilgili bankayla iletişim kurar ve kendi hesap bilgileriyle kullanıcının şifreli hesap bilgisini bankaya iletir. Banka hesap bilgisini çözer, doğrulama işlemlerini yürütür ve para transferini gerçekleştirir. Kaynak, dolandırıcılık riskine karşı bankanın SMS ile tek kullanımlık kod gibi çok faktörlü doğrulama yöntemlerinden yararlanabileceğini de belirtir.

Başarılı itibari para transferinden sonra banka, kullanıcıya ve platforma işlem durumunu bildirir. Platform daha sonra kendi kripto para adresinden kullanıcının belirlediği kripto para adresine dijital varlığı gönderir.

Bu sıralama mevcut banka ve kripto para dönüşüm iş akışını tamamen değiştirmeden gizlilik katmanı ekleme amacını taşır. Bununla birlikte kaynak, tarafların öngörülen protokolü izlediğini ve işlemi zamanından önce sonlandırmadığını varsaymaktadır; dolayısıyla bütün olası operasyonel başarısızlık senaryoları için yeni bir atomiklik protokolü kanıtlandığı sonucu çıkarılamaz.

Olasılıksal şifreleme neden önemlidir?

Aynı banka hesap numarası her işlemde aynı şifreli çıktıyı üretseydi, platform düz metni bilmese bile aynı şifreli değerin tekrar kullanıldığını görebilirdi. Böyle bir tekrar, farklı işlemleri aynı kullanıcıyla ilişkilendirmek için iz oluşturabilirdi.

Çalışma bu riski azaltmak amacıyla olasılıksal açık anahtarlı şifreleme kullanmayı tartışır. ElGamal ve Paillier gibi yöntemlerde rastgelelik kullanılarak aynı açık veri farklı işlemlerde farklı şifreli çıktılara dönüştürülebilir. Böylece aynı banka hesabının tekrar kullanılması, platformun karşısına zorunlu olarak aynı bayt dizisi şeklinde çıkmaz.

Ancak şifreli çıktının değişmesi tek başına bütün meta veri bağlantılarını ortadan kaldırmaz. IP adresi, işlem zamanı, tutar benzerliği veya blokzincir hareketleri gibi farklı bilgi kaynakları ayrı bağlantı riskleri yaratabilir. Kaynak bu risklerden bazılarını ek operasyonel önlemlerle ele almakta, ağ ve yazılım katmanındaki kimlik çözülmesini ise kapsam dışında tutmaktadır.

Blokzincirde adres ilişkilendirmesi neden ayrıca ele alınıyor?

Bankanın kullanıcı kimliğini ve itibari para transferinin zamanını bilmesi, kripto para adresini doğrudan almasa bile kamusal blokzincir üzerindeki olaylarla işlem ilişkilendirmesine yönelik dolaylı risk oluşturabilir. Araştırmacılar bu nedenle platformun birden fazla kripto para adresi kullanması ve adresleri belirli aralıklarla değiştirmesi gibi önlemleri tartışmaktadır.

Kaynakta ayrıca kullanıcıların farklı değişim işlemleri için farklı alıcı adresleri kullanması ve işlemlere rastgele zaman gecikmeleri eklenmesi önerilmektedir. Bu önlemler doğrudan adres eşleştirme riskini azaltma amacı taşır; fakat verilen PDF'de bu önlemlerin her birinin anonimlik üzerindeki nicel katkısı ayrı deneyle ölçülmemiştir.

FC-GUARD'da Denetim Makamı Kullanıcının Kimliğini Nasıl Belirleyebilir?

FC-GUARD her işlemde kullanıcıya ait SSN bilgisinin denetim makamının açık anahtarıyla şifrelenmiş sürümünü ve bu şifreli kimliğin doğrulanabilir kimlik bilgisiyle tutarlı olduğunu gösteren ispatı oluşturur. Platform şifreli kimliği işlem kaydıyla birlikte denetim makamına iletir. Kullanıcı vergi yükümlülüklerine ilişkin gerekli bildirimi yapmadığında denetim makamı kendi özel anahtarını kullanarak kimliği çözebilir; bu özellik anonimlik ile hesap verebilirliği aynı protokolde birleştirmeyi hedefler.

Denetim için şifreli SSN

Kaynak kullanıcının kimliğini denetim makamına yönelik şu biçimde şifrelediğini belirtir:

\[ Enc_{pk_{aa}}(SSN_u) \]

Buradaki \(pk_{aa}\), denetim makamının açık anahtarı; \(SSN_u\) ise kullanıcıya ait kimlik niteliğidir. Kullanıcı buna ek olarak şifreli SSN değerinin platform VC'sinde gizlenen SSN ile tutarlı olduğunu gösteren bir ispat üretir.

Platform bu ispatı doğrular ve şifreli SSN bilgisini işlem kaydına ekler. Böylece platformun gerçek SSN değerini öğrenmeden işlemin denetime konu olabilecek geçerli bir kimlikle ilişkili olduğunu kontrol etmesi amaçlanır.

Denetimde kimlik çözme denklemi

Denetim makamı gerektiğinde kendi özel anahtarıyla kimliği çözer:

\[ SSN_u=Dec_{sk_{aa}}(Enc_{pk_{aa}}(SSN_u)) \]

\(sk_{aa}\), denetim makamının özel anahtarını temsil eder. Bu mekanizma sayesinde platformun işlemler sırasında açık SSN saklamasına ihtiyaç duyulmadan yetkili makamın belirli işlemler için kimlik tespiti yapması amaçlanır.

Kimlik çözme yetkisinin önemli sınırı

Çalışmada kimlik çözmenin vergi bildiriminde uygunsuzluk olduğunda gerçekleştirilmesi tasarlanmaktadır. Ancak denetim makamı kendi özel anahtarına sahip olduğu için, gerekli şifreli kayda erişebildiğinde kimliği kriptografik olarak çözme yeteneği vardır.

Bu nedenle “denetim makamı teknik olarak yalnız suçlu kullanıcıların kimliğini çözebilir” şeklinde mutlak bir ifade doğru değildir. Kaynak modelinde denetim makamı güvenilir kabul edilmekte ve bu yetkinin belirlenen denetim koşullarında kullanılacağı varsayılmaktadır. Bu, kriptografik yetenek ile hukuki veya kurumsal yetkilendirme arasındaki ayrımdır.

Denetim kayıtları neden kripto adresinden ayrılıyor?

Kaynağa göre platform, denetim makamına göndereceği işlem kaydında kullanıcı kripto para adresini ve kripto transferinin ayrıntılarını gizlemekte veya ayırmaktadır. Bunun amacı, denetim makamının kimlik denetimi yaparken otomatik olarak kullanıcının bütün blokzincir faaliyetlerine erişmesini önlemektir.

Denetim makamı kendisine iletilen işlem bilgisi ve kullanıcının beyanını karşılaştırabilir. Kaynak senaryosunda bildirim yapılmaması veya yanlış beyanın tespit edilmesi kimlik çözmeye gerekçe oluşturmaktadır. Sistemin gerçek bir ülkede bu şekilde kullanılması ise ilgili ülkenin veri koruma, mali raporlama ve denetim yetkisi mevzuatına bağlıdır.

Sistemin güvenlik hedefleri

Tehdit modeli hangi taraflara güveniyor?

Araştırmacılar platform ile bankayı honest-but-curious, yani protokolü izleyen fakat erişebildikleri bilgilerden ek sonuç çıkarmaya çalışabilen taraflar olarak modellemektedir. Bu tarafların işlemleri doğru yürüttüğü, protokolü keyfî biçimde değiştirmediği ve zamanından önce sonlandırmadığı varsayılır.

SSA ve denetim makamı güvenilir kabul edilmektedir. Platform ile bankanın birlikte hareket ederek bilgi birleştirdiği saldırı senaryoları çalışma kapsamı dışındadır. Tüm taraflar arasındaki iletişim kanallarının TLS ile güvenli olduğu varsayılır.

Kaynak ayrıca ağ katmanı ve yazılım katmanından kaynaklanabilecek kimlik çözülmesini kapsam dışı tutmaktadır. Dolayısıyla FC-GUARD'ın anonimlik iddiası kullanıcı IP adresi, cihaz parmak izi, kötü amaçlı uygulama, işletim sistemi sızıntısı veya bütün meta veri korelasyonlarına karşı koşulsuz anonimlik olarak okunamaz.

Mevcut gizlilik sistemlerinden farkı

Çalışmanın literatür karşılaştırmasında Chaumian e-cash, Zcash, Zether, Anonymous Zether, Bolt, PriBank, LDSP, TumbleBit, coin mixing yaklaşımları, Pisces ve CBDC odaklı sistemler ele alınmaktadır. Kaynak bu çalışmaların önemli bir bölümünün kripto para içi transfer gizliliğine veya kripto-yerel ödeme düzenine odaklandığını, FC-GUARD'ın ise banka hesabındaki itibari paranın kullanıcı kontrolündeki kripto para adresine dönüştürülmesiyle ilgili kimlik–banka–adres bağlantısını hedeflediğini belirtmektedir.

Örneğin Pisces anonim ve düzenlemelere uyumlu kripto-kripto değişim yaklaşımı olarak tartışılmaktadır. FC-GUARD ise bankanın açık hesap bilgisine ihtiyaç duyduğu fiat-to-cryptocurrency iş akışını temel problem olarak ele alır. Bu ayrım, çalışmanın katkısının bütün kripto gizlilik sistemlerinin yerini almak değil, mevcut banka bağlantılı dönüşüm modelindeki belirli veri bağlantısı sorununa çözüm tasarlamak olduğunu gösterir.

Ülkelere göre uyarlanabilirlik sınırı

Çalışma ABD'deki SSA temelli kimlik doğrulaması ve platform tarafından yönlendirilen banka transferi modeline dayanır. Araştırmacılar, farklı ülkelerin banka transferi yöntemlerinin değişebileceğini ve protokolde uyarlama gerekeceğini açıkça belirtmektedir.

Türkiye açısından sistemin temel fikri —kimliği ilk aşamada doğrulayıp işlem sırasında açıklamadan geçerli olduğunu kanıtlama— teknik bir araştırma konusu olabilir. Ancak Türkiye'deki kimlik doğrulama sistemleri, bankaların para transferi süreçleri, müşteri tanıma gereklilikleri, kişisel veri yükümlülükleri ve kripto varlık hizmet sağlayıcılarına ilişkin kurallar ABD ile aynı değildir. Bu PDF, Türkiye mevzuatına uygun hazır bir FC-GUARD uygulamasının doğrulandığını göstermemektedir.

Çalışmanın Yöntemi ve Bulguları

Deneysel araştırmanın tasarımı

FC-GUARD yalnız kavramsal mimari olarak sunulmamıştır. Araştırma kapsamında masaüstü ve mobil istemcileri kapsayan bir prototip gerçekleştirilmiş, ayrıca gizlilik koruması eklenmemiş geleneksel iş akışını temsil eden temel bir karşılaştırma sistemi hazırlanmıştır.

Karşılaştırmanın amacı, FC-GUARD'daki VC, VP, ZKP, şifreleme ve çözme işlemlerinin kayıt, banka etkileşimi, değişim ve denetim gecikmelerine getirdiği maliyeti değerlendirmektir. Kaynakta Bitcoin transferleri yerel test ağında yürütülmüş ve bazı banka işlemleri benzetim koşullarında ölçülmüştür.

Test ortamı ve yazılım bileşenleri

Kaynakta işlem ortamının ayrıntılı performans analizi bulunmakla birlikte gerçek bankacılık kurumları ve canlı Bitcoin ana ağı üzerinde geniş ölçekli üretim denemesi raporlanmamaktadır. Bu nedenle deney sonuçları belirtilen prototip ve test koşullarının performansını temsil eder.

Kayıt aşamasının sonuçları

Bir defalık kullanıcı kayıt süresinde temel sistem 5,11 ms, FC-GUARD 156,95 ms olarak raporlanmıştır. Mobil istemcide kayıt 3,35 saniye sürmüştür. Mobil kayıt sırasında ortalama CPU kullanımı %65,2 ve bellek kullanımı 11,45 MB olarak verilmiştir.

Bu farkın nedeni FC-GUARD'da yalnız düz metin kimlik kontrolü yapılmaması; doğrulanabilir kimlik bilgisi hazırlanması ve ilgili kriptografik işlemlerin gerçekleştirilmesidir. Kaynak, kayıt işleminin her değişim sırasında yeniden yapılmadığını ve bu nedenle ilk kayıt maliyetinin doğrudan her alışverişin gecikmesine eklenmediğini belirtmektedir.

Ölçüm kapsamında şema ve kimlik bilgisi tanımının oluşturulması ve bunların açık kayıt defterine yüklenmesi gibi tek defalık başlangıç işlemleri kayıt süresine dahil edilmemiştir. Dolayısıyla 156,95 ms değeri bütün sistem kurulumunun tamamlanma süresi değildir.

İşlem aşamalarının süreleri

Kaynakta temel sistemin kimlik doğrulaması açık hesap bilgisinin kontrolünü, banka etkileşimi ise doğrudan veri iletimini kapsamaktadır. FC-GUARD'da aynı aşamalar ek VP/ZKP işlemleri ile şifreli verinin çözülmesi ve doğrulanması gibi maliyetler içerir.

Banka transferi süreleri gerçek banka ağında uçtan uca ödeme kesinleşmesi değildir. Kaynak bunları VISA benzeri gecikmenin simüle edildiği bir koşulla değerlendirir. Bitcoin transfer süresi ise işlemin oluşturulmasından test ağındaki eşler tarafından ilk alınmasına kadar ölçülmüştür; bu süreyi blok onayı veya geri döndürülemez kesinleşme süresiyle eşitlemek doğru değildir.

Masaüstü ve mobil sonuçlar nasıl yorumlanmalı?

Masaüstü FC-GUARD kimlik doğrulaması 464,87 ms iken mobil sürümde 3,40 saniye olarak bildirilmiştir. Bu sonuç mobil cihazda kriptografik kimlik işlemlerinin daha fazla zaman alabildiğini göstermektedir. Ancak mobil banka etkileşimi 298,32 ms ile masaüstünde raporlanan 363,27 ms değerinden düşüktür. Bu nedenle araştırma sonuçları her işlemin mobil cihazda mutlaka daha yavaş olduğu şeklinde genellenmemelidir.

Mobil değişim aşamasında kaynak ortalama CPU kullanımını %80, bellek tüketimini 97 MB olarak verir. VP ve ZKP oluşturmanın süresi 2,50 saniye olarak belirtilmiştir. Bu ölçümler mobil istemcinin ek kriptografik hesaplama maliyetinin önemli bölümünü taşıdığını göstermektedir.

Denetim maliyeti

Temel sistemde denetim toplam süresi 2,65 ms olarak ölçülmüştür. FC-GUARD denetiminde kullanıcı şifreli kimlik ve ispat üretir, platform bunları kontrol edip iletir, denetim makamı gerekli durumda şifreli kimliği çözer. Kaynak bu sürecin toplam süresini 362,52 ms olarak raporlamaktadır.

Denetim tarafındaki gecikme artışı, gizlilik ve hesap verebilirlik için eklenen şifreleme ve ispat işlemlerinin maliyetidir. Ancak denetim işleminin her kullanıcı değişiminde mutlaka aynı şekilde kimlik açma işlemi gerektirdiği söylenemez; kaynakta anonimlik varsayılan, kimlik çözme ise denetim gerekçesine bağlı işlem olarak tasarlanmıştır.

Görsel performans karşılaştırması

Mobil ölçümlerin görsel kaynağı

Kaynak Şekil 6, Google Pixel 8a üzerinde kayıt ve değişim aşamalarına ilişkin mobil uygulama ekran görüntülerini içerir. Görsellerde uygulamanın mesaj çıktıları ve ölçüm kayıtları görülmektedir. Kaynak metni kayıt için 3,35 saniye, %65,2 CPU ve 11,45 MB bellek; değişim için yaklaşık %80 CPU ve 97 MB bellek değerlerini aktarmaktadır.

Şekil 6 açıklamasında “baseline” kelimesi yer almakla birlikte onu çevreleyen ölçüm metni FC-GUARD mobil istemcisini anlatmaktadır. Bu nedenle burada sayısal veriler kaynak anlatımıyla birlikte korunmuş, şekil açıklamasındaki kelime otomatik olarak ayrı bir temel sistem mobil deneyinin kanıtı kabul edilmemiştir.

Performans sonuçlarının kapsamı

Çalışmanın sonuçları FC-GUARD'ın ek kriptografik işlemlere rağmen belirtilen prototip ortamında çalışabildiğini göstermektedir. Buna karşılık yüksek kullanıcı yükü altında eşzamanlı işlem kapasitesi, geniş ölçekli dağıtım, farklı banka sistemlerinde gerçek zamanlı transferler, şiddetli ağ gecikmeleri ve bütün kötü niyetli taraf kombinasyonları açısından aynı performans ve güvenlik sonuçlarının geçerli olduğu kanıtlanmamıştır.

Kaynak, daha kapsamlı mevzuat gereklilikleri ve farklı ülke ödeme altyapılarına uyum için protokolün geliştirilmesinin gerekebileceğini de kabul etmektedir.

Çalışmanın desteklediği temel sonuçlar

• VC ve ZKP kullanılarak itibari para–kripto para değişiminde kullanıcı kimliğini işlem sırasında doğrudan açıklamadan uygunluk doğrulaması tasarlanabilir.
• Banka hesap bilgileri bankanın açık anahtarıyla şifrelenerek platformun açık hesap numarasına erişmesi sınırlandırılabilir.
• Farklı işlemlerde rastgeleleştirilmiş sunumlar ve şifreli değerler kullanılması ilişkilendirilemezliği destekleyebilir.
• Denetim makamına yönelik ayrı şifreli kimlik mekanizmasıyla hesap verebilirlik için kimlik açma olanağı tasarlanabilir.
• Prototip masaüstü ve Android ortamında gerçekleştirilmiş ve kaynakta verilen gecikme ölçümleriyle değerlendirilmiştir.
• Gizlilik mekanizmaları temel sisteme göre ek işlem maliyeti getirmiştir; buna rağmen kaynak deneyleri gerçekleştirilebilirliği desteklemektedir.

Çalışmanın desteklemediği genellemeler

• FC-GUARD bütün aşamalarda kimlik bilgisinin hiçbir kuruma açıklanmadığını göstermez.
• Denetim makamının kimliği teknik olarak çözme yeteneğinin kriptografik olarak yalnız belirli kullanıcılarla sınırlandığı sonucunu desteklemez.
• Platform ile bankanın iş birliği yaptığı saldırılara karşı tam güvenlik kanıtı sunmaz.
• Ağ katmanı ve yazılım katmanı anonimliğinin garanti edildiğini göstermez.
• Gerçek banka ve ana ağ ortamında aynı gecikmelerin sağlanacağını kanıtlamaz.
• Ölçülen Bitcoin test ağı gecikmesini zincir onayı veya kesinleşme süresi olarak yorumlamayı desteklemez.
• Bütün ülkelerin KYC, vergi ve kişisel veri mevzuatına otomatik uyum iddiasını desteklemez.
• Bütün kriptografik mekanizmalar için kaynakta ayrı, eksiksiz ve biçimsel bir güvenlik kanıtı bulunduğu varsayılamaz.

Araştırmanın genel sonucu

FC-GUARD araştırması, kripto para kullanımında gizlilik ile finansal düzenleyici uyumluluğun mutlaka birbirini dışlaması gerekmediğini göstermeyi amaçlayan bir sistem tasarımı sunmaktadır. Yaklaşımın yeniliği, bankacılık altyapısını tamamen kaldırmadan, doğrulanabilir kimlik bilgileri ve sıfır bilgi ispatlarını kullanıcı–platform–banka–denetim makamı ilişkisine yerleştirmesidir.

Kaynağın ortaya koyduğu uygulama sonuçları, bu yaklaşımın test edilmiş masaüstü ve mobil prototiplerde hesaplanabilir olduğunu desteklemektedir. Bununla birlikte gerçek bir finansal sisteme geçişte teknik performansın yanında güven modeli, denetim yetkileri, veri koruma koşulları, taraflar arası iş birliği riskleri ve ülkeye özgü mevzuatın ayrıca değerlendirilmesi gerekir.

Kaynak ve Yöntem Notu

Özgün çalışma: FC-GUARD: Enabling Anonymous yet Compliant Fiat-to-Cryptocurrency Exchanges

Yazarlar: Shaoyu Li; Hexuan Yu; Md Mohaimin Al Barat; Yang Xiao; Y. Thomas Hou; Wenjing Lou.

Yazar sırası: Özgün kaynakta verildiği biçimde korunmuştur.

Afiliasyonlar: Virginia Tech, Virginia, ABD (Shaoyu Li, Hexuan Yu, Md Mohaimin Al Barat, Y. Thomas Hou, Wenjing Lou); University of Kentucky, Kentucky, ABD (Yang Xiao).

Eş katkı: Kaynak PDF'de ayrı bir eş katkı bildirimi tespit edilmemiştir.

Sorumlu yazar: PDF'de ayrıca belirlenmiş bir corresponding author işareti tespit edilmemiştir.

Kaynak sürümü: arXiv:2601.16298v1.

ArXiv gönderim tarihi: 22 Ocak 2026.

ArXiv alanı: Computer Science – Cryptography and Security (cs.CR).

ArXiv DOI: 10.48550/arXiv.2601.16298.

ArXiv resmî bağlantısı: https://arxiv.org/abs/2601.16298

Yayımlanmış çalışma: IEEE INFOCOM 2026 – IEEE Conference on Computer Communications.

Konferans: Tokyo, Japonya, 18–21 Mayıs 2026.

Yayımlanmış sürüm DOI: 10.1109/INFOCOM59046.2026.11571719.

Yayıncı: IEEE.

Yayın yılı: 2026.

Hakemlik: IEEE INFOCOM 2026 kaydı hakemli konferans katkısıdır. Yüklenen PDF üzerinde arXiv v1 ibaresi bulunmaktadır; bu sürüm doğrudan hakemlik tamamlanmış nihai IEEE metni olarak değerlendirilmemiştir.

Lisans: ArXiv kaydı non-exclusive license to distribute koşulunu göstermektedir. Bu lisans üçüncü tarafların korunan metin ve şekilleri serbestçe uyarlamasına yönelik genel Creative Commons izni değildir. Yayımlanmış IEEE sürümünün telif koşulları ayrı değerlendirilmelidir.

Kaynak türü: Bilgisayar güvenliği ve uygulamalı kriptografi alanında sistem/protokol tasarımı ve deneysel prototip değerlendirmesi.

Araştırma konusu: Anonimlik, ilişkilendirilemezlik, banka hesabı gizliliği, anonim KYC, itibari para–kripto para dönüşümü ve seçici denetim.

Temel yöntemler: Verifiable Credentials, Verifiable Presentations, Zero-Knowledge Proofs, Non-Interactive Zero-Knowledge Proofs, probabilistic public-key encryption, ElGamal, Hyperledger AnonCreds ve Hyperledger Indy.

Deneysel altyapı: Amazon EC2 c5.large, Ubuntu 22.04, Intel Xeon iş istasyonu, Google Pixel 8a, Android 14, Python ve yerel Bitcoin test ağı.

Temel performans verisi: Kayıt temel sistem 5,11 ms, FC-GUARD masaüstü 156,95 ms; işlem kimlik doğrulaması temel sistem 2,63 ms, FC-GUARD masaüstü 464,87 ms ve mobil 3,40 s; denetim temel sistem 2,65 ms ve FC-GUARD 362,52 ms.

Güvenlik varsayımları: Platform ve banka honest-but-curious olarak modellenmiştir. SSA ve denetim makamı güvenilir kabul edilmiştir. Platform–banka iş birliği, ağ katmanı ve yazılım katmanı kimlik çözülmesi çalışmanın güvenlik kapsamı dışındadır.

Kriptografik yorum sınırı: Kaynak CL tipi kimlik bilgisi altyapısına ilişkin denklemleri, BBS+ temelli NIZK açıklamasını ve Hyperledger AnonCreds uygulamasını içermektedir. Bu açıklamalar tek bir yeni kriptografik primitive'in eksiksiz ispatı olarak birleştirilmemiştir.

Yöntemsel sınırlılık: Banka gecikmesi ve Bitcoin test ağı ölçümleri canlı üretim ortamındaki kesinleşme sürelerini doğrudan temsil etmez. Gerçek finansal düzenleyici uyumluluk ve saldırı dayanıklılığı için ek değerlendirmeler gerekmektedir.

Görsel kaynağı: Kaynak Şekil 1 geleneksel ve FC-GUARD değişim akışını; Şekil 2 mimariyi; Şekil 3 kimlik bilgisi düzenleme/doğrulamayı; Şekil 4 kayıt sürecini; Şekil 5 değişim sürecini; Şekil 6 mobil uygulama ölçümlerini göstermektedir. Verianla içindeki şemalar bilimsel ilişkilerden bağımsız olarak oluşturulmuştur.

Şekil 6 notu: Şekil açıklamasında kullanılan “baseline” ifadesi, çevresindeki FC-GUARD mobil sonuç anlatımıyla tam uyumlu değildir. Verianla sayısal sonuçları ilgili kaynak paragrafıyla ilişkili biçimde aktarmıştır.

Finansman: Çalışma ABD National Science Foundation tarafından 2154929, 2247560, 2247561, 2331936, 2433904 ve 2433905 numaralı destekler ve Virginia Commonwealth Cyber Initiative (CCI) tarafından kısmen desteklenmiştir.

Çıkar çatışması: Kaynak PDF'de ayrı ve açık bir çıkar çatışması beyanı tespit edilmemiştir.

Veri ve kod erişilebilirliği: PDF, kullanılan altyapı ve yazılım araçlarını tanımlamaktadır; ancak FC-GUARD prototipinin tüm kaynak kodunu ve deney tekrarına ait ham ölçümleri içeren ayrı bir resmî veri/kod deposu bağlantısı tespit edilmemiştir.

CRediT / yazar katkısı: Ayrı bir ayrıntılı CRediT katkı matrisi tespit edilmemiştir; yazarların katkı düzeyleri varsayımla dağıtılmamıştır.

Bilimsel sonuç sınırı: FC-GUARD'ın gizlilik ve uyumluluk hedeflerini birleştiren tasarımının prototip ortamında gerçekleştirilebilir olduğu raporlanmaktadır. Sonuçlar her koşulda mutlak anonimlik, bütün saldırılara dayanıklılık veya her düzenleyici çerçeveye otomatik uyumluluk garantisi oluşturmaz.