Solidus Gizlilik ve Güvenlik

Gizlilik garantileri, güvenlik mimarisi, güvenlik açığı ifşa politikası, uyumluluk yol haritası ve veri işleme sözleşmeleri.

Gizlilik Modeli

Solidus, kapatılabilen bir özellik değil, yapısal bir özellik olarak gizlilikle tasarlanmıştır. Aşağıdaki garantiler tasarım gereği geçerlidir:

Temel Gizlilik Garantileri

1. Hiçbir biyometrik veri saklanmaz. Biyometrik veri (yüz taraması, belge görüntüleri, canlılık videosu), KYC sırasında Solidus doğrulama motoru tarafından işlenir ve kimlik bilgisi düzenlendikten hemen sonra atılır. Motor yalnızca doğrulamanın gerçekleştiğini onaylayan kriptografik bir kanıt token’ı tutar. Ham biyometrikler hiçbir zaman Solidus blok zincirine dokunmaz.

2. Seçici ifşa. Kullanıcılar, bir hizmetin istediği tam olarak iddiaları sunar — daha fazlasını değil. “Bu kullanıcı 18 yaşından büyük mü?” diye soran bir hizmet, bir doğum tarihi değil, bir ad değil, başka herhangi bir iddia değil, yalnızca evet/hayır yanıtı alır. Sıfır bilgi kanıtları, bunu güvenilir bir aracı olmadan mümkün kılar.

3. Hizmetler arasında bağlantısızlık. Farklı bir hizmete yapılan her sunum, taze bir geçici (ephemeral) anahtar kullanır. Kullanıcının açık rızası olmadan, iki hizmetin aynı kullanıcıyla etkileşime girdiklerini belirlemesi kriptografik olarak imkânsızdır.

4. Merkezi bir veri deposu yok. Kimlik verisi, kullanıcının cüzdanında (cihaz yerel) veya Solid pod’unda (kullanıcının seçtiği, kullanıcı kontrollü) yaşar. Solidus, kullanıcı kimliklerinin, kimlik bilgilerinin veya doğrulama geçmişlerinin merkezi bir veritabanını tutmaz.

5. Kimlik bilgisi minimalliği. Protokol, düzenlenen kimlik bilgilerinin yalnızca belirli doğrulama türü için gereken iddiaları içermesini zorunlu kılar. Bir KYC Seviye 1 kimlik bilgisi hiçbir canlılık verisi içermez. Bir canlılık kimlik bilgisi hiçbir belge verisi içermez. Kimlik bilgileri düzenleme sırasında aşırı kapsamlandırılamaz.

6. Kullanıcı kontrollü iptal. Bir kullanıcı, elinde tuttuğu herhangi bir kimlik bilgisini istediği zaman iptal edebilir. İptal, zincir üzerinde anında etkili olur. Kullanıcının düzenleyicinin iznini istemesine gerek yoktur.

Protokolün Bildiği Şey

Zincir üzerindeki durum şunları içerir:

Bir blok zinciri gözlemcisi, did:solidus:1:8Qx9...’un did:solidus:1:Pm3r...’a KYCLevel2Credential türünde bir kimlik bilgisi düzenlediğini görebilir. Temeldeki adı, belge numarasını, adresi veya başka herhangi bir kişisel veriyi göremezler.

Tehdit Modeli

Güvenlik Mimarisi

Kriptografik Temel

Kuantum sonrası hazırlık: Şu anki kriptografik paket kuantum sonrası güvenli değildir. NIST PQC standardizasyonu (ML-KEM, ML-DSA) izleniyor. 2028’den önce bir Çekirdek SIP olarak bir kuantum sonrası geçiş yolu önerilecektir. Geçiş, standart bir yükseltme değil, bir hard fork gerektirir.

Ağ Güvenliği

Doğrulayıcı kimlik bağlama: Her doğrulayıcının doğrulanmış bir insan kimliğine (KYC Seviye 2) sahip olması gerekir. Bu, yalnızca ekonomik stake yoluyla sybil saldırılarını önler. Stake edilen SLDS’nin %51’ini elde eden bir saldırganın, doğrulanmış insan kimliklerinin de %51’ine ihtiyacı olur — önemli ölçüde daha zor bir saldırı.

BFT güvenliği: Konsensüs protokolü, f < n/3 kötü niyetli doğrulayıcıya kadar (%33 hata toleransı) Bizans Hata Toleranslıdır. Kötü niyetli doğrulayıcıların bir alt kümesi geçersiz blokları kesinleştiremez, yalnızca ağı durdurabilir. Geçersiz durumu kesinleştirmeden durdurmak, doğruluğu korur.

Eclipse saldırısı direnci: Eşler, çeşitli IP aralıklarından ve özerk sistemlerden seçilir. Bir düğümün eş bağlantılarının %20’sinden fazlası tek bir /24 alt ağından gelemez. Bu, eclipse saldırılarını (bir düğümü kötü niyetli eşlerle çevrelemek) önemli ölçüde zorlaştırır.

Stake ağırlıklı mesaj doğrulama: Tüm P2P mesajları imzalanır. Doğrulayıcılardan gelen mesajlar itibar puanlarına göre ağırlıklandırılır — taze bir kayda ve minimum stake’e sahip bir düğüm, yüksek itibara sahip uzun süredir çalışan bir düğümden daha düşük başlangıç güveni alır.

Akıllı Sözleşme Güvenliği

Solidus L1, bugün genel amaçlı bir sözleşme sanal makinesi sunmuyor — durum geçişleri, bir Sparse Merkle Tree üzerinde yerel, tipli Rust işleyicileridir (transfer, DID, kimlik bilgisi, stake etme), bu yüzden konsensüs yolunda güvenilmeyen bayt kodu yoktur. Genel amaçlı programlanabilirlik, L1 doğrulayıcı kümesini paylaşan bir EVM subnet’i (REVM) olarak yol haritasında gelir. Aşağıdaki güvenlik uygulamaları bu yol haritası sözleşme yüzeyine uygulanır:

Biçimsel doğrulama (v1.1 için planlandı): Çekirdek kimlik bilgisi düzenleme ve iptal sözleşmeleri, mainnet lansmanından önce K Framework kullanılarak biçimsel doğrulamadan geçirilecektir.

Denetim gereksinimi: Tüm akıllı sözleşme dağıtımları, mainnet dağıtımından önce şu firmalardan en az birinden bir güvenlik denetiminden geçmelidir: Trail of Bits, NCC Group, Sigma Prime, ChainSecurity veya eşdeğer itibara sahip bir firma.

Yükseltme kısıtlaması: Akıllı sözleşmeler varsayılan olarak yükseltilemez. Yükseltmeler, bir Çekirdek SIP artı Güvenlik Konseyinden ayrı bir multisig onayı gerektirir. 90 günlük etkinleştirme süre tanıma dönemi sözleşme yükseltmelerine uygulanır.

Yeniden giriş (reentrancy) koruması: Tüm durum değiştiren sözleşme fonksiyonları check-effects-interactions desenini izler. Dış çağrılar yalnızca tüm durum değişiklikleri onaylandıktan sonra yapılır.

Anahtar Yönetimi

Doğrulayıcı anahtarları: Subnet ve Çekirdek doğrulayıcılar için donanım güvenlik modülü (HSM) depolaması şiddetle önerilir. Düğüm, desteklenen HSM’lerle (YubiHSM 2, AWS CloudHSM, Google Cloud HSM) PKCS#11 entegrasyonunu destekler.

Kullanıcı anahtarları: Kullanıcı özel anahtarları hiçbir zaman bir sunucuya iletilmez. Cihaz üzerinde (Solidus cüzdanında veya tarayıcı uzantısında) üretilir ve saklanır. Biyometrik istem, bir sunucu kimlik doğrulaması değil, yerel bir cihaz kilidi açmadır.

Kurtarma: Kullanıcılar DID’lerini şu yollarla kurtarabilir:

1. Tohum ifadesi (BIP-39, 24 kelime) — birincil kurtarma yöntemi
2. Sosyal kurtarma (Shamir paylarını tutan güvenilir kişiler)
3. Donanım yedeği (şifrelenmiş anahtarı donanım cüzdanına aktarma)

Gözetimli anahtar seçeneği yok: Solidus, gözetimli (custodial) anahtar depolama sunmaz. Tohum ifadesini ve tüm kurtarma seçeneklerini kaybeden kullanıcılar, DID’lerine erişimlerini kalıcı olarak kaybederler. Bu kasıtlı bir tasarım tercihidir — gerçek öz-egemenlik, kullanıcının gözetim sorumluluğunu üstlenmesini gerektirir.

Güvenlik Açığı İfşası

Sorumlu İfşa Politikası

Solidus koordineli ifşayı izler. Güvenlik açığı bulan güvenlik araştırmacıları, herhangi bir kamuya açık ifşadan önce bunları özel olarak bildirmelidir. Şunları taahhüt ediyoruz:

• Onay: Raporun 24 saati içinde
• İlk değerlendirme: 72 saat içinde
• Durum güncellemesi: Çözülene kadar her 7 günde bir
• Çözüm: Ciddiyete bağlı olarak mümkün olduğunca hızlı
• İfşa: Yama dağıtıldıktan ve kullanıcıların güncelleme yapmaya zamanı olduktan sonra

Bildirim adresi: [email protected] PGP anahtarı: Henüz bir /.well-known/security.txt yolunda yayınlanmadı — geçerli anahtarı [email protected]’e e-posta göndererek isteyin

Lütfen tüm güvenlik açığı raporlarını PGP açık anahtarımızla şifreleyin. Koordineli ifşa penceresi kapanana kadar güvenlik açığını herkese açık kanallarda (Discord, GitHub, Twitter) tartışmayın.

Ciddiyet Sınıflandırması

Hata Ödülü Programı

Solidus sürekli bir hata ödülü programı işletir. Ödüller SLDS olarak ödenir.

Kapsam dahilinde:

• Solidus Protokol akıllı sözleşmeleri (mainnet ve testnet’te)
• Düğüm yazılımı (solidus-node)
• Auth SDK (@solidus-network/auth)
• Verify ürünü (verify.solidus.network)

Kapsam dışında:

• Üçüncü taraf entegrasyonlar ve köprüler
• Ekip üyelerine karşı sosyal mühendislik saldırıları
• Altyapıya karşı hizmet reddi saldırıları (yeni bir istismar olmadan)
• Kullanıcı cihazlarına fiziksel erişim gerektiren sorunlar

Ayrıntılı hata ödülü kuralları henüz özel bir URL’de yayınlanmadı — [email protected] ile iletişime geçin.

Güvenlik Denetimi Geçmişi

Güvenlik denetimi raporları, düzeltme döneminden sonra tam olarak yayınlanacaktır (URL henüz canlı değil). Solidus, denetim bulgularını gizli tutmaz.

Uyumluluk Yol Haritası

Uyumluluk bölge bölge sağlanır. Bu planlanan sıradır:

Aşama 1 (1-6. Aylar): Hukuki Temel

• Kripto dostu bir yargı bölgesinde tüzel kişilik kurma (İsviçre, Singapur, BAE değerlendiriliyor)
• GDPR ön değerlendirmesi için veri koruma danışmanı görevlendirme
• Gizlilik politikası, hizmet şartları ve veri işleme sözleşmelerini taslak haline getirme
• Biyometrik KYC akışları için Veri Koruma Etki Değerlendirmesi (DPIA) yürütme
• Hedef lansman yargı bölgelerinde token sınıflandırması konusunda hukuki görüş alma

Aşama 2 (7-12. Aylar): Ürün Uyumluluğu

• AB kullanıcıları için GDPR uyumluluğu:
  • Tasarım gereği veri minimizasyonu (doğrulandı — biyometrikler saklanmıyor)
  • Silme hakkı (DID devre dışı bırakma, kişisel veri bağlantısını keser; zincir üzerindeki kayıtlar takma addır)
  • İşleme için meşru menfaat veya rıza hukuki dayanağı
  • Tüm doğrulama olayları için veri işleme kayıtları
• Kaliforniya kullanıcıları için CCPA uyumluluğu:
  • Toplama sırasında gizlilik bildirimi
  • Bilme, silme ve satıştan çıkma hakkı (hiçbir satış gerçekleşmez)
  • CCPA kapsamında biyometrik veri, hassas kişisel bilgi olarak ele alınır
• BIPA ön değerlendirmesi (Illinois Biyometrik Bilgi Gizliliği Yasası)
  • Biyometrik veri toplamadan önce yazılı rıza
  • Biyometrik veri için imha programı (yazılı olarak belirtilmelidir)
  • Biyometrik veriden kâr elde edilmemesi

Aşama 3 (Yıl 2): Sertifikasyon Hedefleri

• SOC 2 Type II denetimi (güvenlik, kullanılabilirlik, gizlilik)
  • Yıllık 50 bin $‘dan fazla kurumsal sözleşmeler için gereklidir
  • Beklenen zaman çizelgesi: 12 aylık gözlem dönemi + 3 aylık denetim
• ISO 27001 sertifikasyonu
  • Bilgi güvenliği yönetim sistemi
  • Devlet ve finansal kurum sözleşmeleri için gereklidir
• eIDAS 2.0 uyumluluğu (AB)
  • “Solidus ile Giriş Yap”ın bir AB dijital kimliği olarak kabul edilmesi için ilgilidir
  • Onaylanmış bir kuruluş tarafından uygunluk değerlendirmesi gerektirir

Aşama 4 (Yıl 3+): Gelişmiş Sertifikasyonlar

• FedRAMP (ABD devlet sözleşmeleri hedefleniyorsa)
• PCI DSS (ödeme işleme geliri 5 milyon $‘ı aşarsa)
• HIPAA (sağlık kimlik bilgisi kullanım durumları hedefleniyorsa)
• DORA uyumluluğu (AB Dijital Operasyonel Dayanıklılık Yasası) finansal hizmetler için

Veri İşleme Sözleşmeleri (DPA’lar)

DPA’lar, GDPR veya diğer veri koruma yasası uyumluluğu için bunlara ihtiyaç duyan kurumsal müşteriler için mevcuttur.

Standart DPA Şartları

Veri denetleyicisi / işleyicisi ilişkisi: Çoğu dağıtımda, uygulamanız veri denetleyicisidir ve Solidus veri işleyicisidir. Solidus, kimlik verisini yalnızca doğrulama hizmetini yerine getirmek için gereken ölçüde işler.

İşlenen veri kategorileri:

Alt işleyiciler: Solidus, devlet kimliklerini ve biyometrikleri kendi doğrulama motoru aracılığıyla yerel olarak işler. Hiçbir üçüncü taraf KYC sağlayıcısı kullanılmaz. Altyapı alt işleyicilerinin (barındırma, e-posta, izleme) güncel bir listesi henüz özel bir URL’de yayınlanmadı — [email protected]’ten talep edin. Kurumsal müşteriler, herhangi bir alt işleyici değişikliğinden 30 gün önce bilgilendirilir.

Uluslararası transferler: AB kullanıcıları için işlenen veriler, kullanıcı açıkça AB dışı bir subnet seçmedikçe AB içinde (AB coğrafi subnet’i) saklanır ve işlenir. Standart Sözleşme Hükümleri (SCC’ler), AB dışına gerekli her türlü transferi kapsar.

Kurumsal DPA Talebi: Şunlarla birlikte [email protected]’e gönderin:

• Şirket adı, yargı bölgesi ve DPA irtibat kişisi
• Beklenen aylık doğrulama hacmi
• Belirli veri kategorileri ve kullanım durumları

Standart DPA teslim süresi: Yeni müşteriler için 5 iş günü. Kurumsal kademe müşterileri için özel DPA müzakereleri mevcuttur.

Güvenlik İletişim Bilgileri

Veri Koruma Görevlisi (DPO): Özel kategori veri (biyometrikler) işleyen kuruluşlar için GDPR kapsamında gereklidir. AB lansmanından önce atanır.

PGP Parmak İzi: Henüz bir /.well-known/security.txt yolunda yayınlanmadı — geçerli parmak izini [email protected]’ten talep edin