Blokzincir Tabanlı İmza Nedir?

Blokzincir tabanlı imza, bir belgenin imzalandığı anı ve içeriğinin değişmediğini kanıtlamak için belgenin kriptografik özetini (hash) blokzincire kaydeden doğrulama yaklaşımıdır. Genellikle klasik dijital imza ile üretilen imza ve zaman damgası, zincirde değiştirilemez bir kayıtla desteklenir; doğrulamada belge yeniden hashlenir ve kayıtla eşleştirilir. Bu sayede denetim izi güçlenir, üçüncü tarafa bağımlılık azalır ve çok taraflı sözleşmelerde akıllı sözleşme süreçleriyle otomatik kontrol yapılabilir. En kritik nokta, zincire belgeyi değil yalnızca hash bilgisini yazmak, anahtar yönetimini doğru yapmak ve kimlik doğrulamasını ayrı bir güven katmanıyla çözmektir; aksi halde sistem sağlam görünürken sessizce zayıf halka kalır.

Blokzincir tabanlı imza kavramı: “imza türü” mü, kanıt katmanı mı?

Blokzincire ne yazılır: hash, zaman damgası, olay kaydı

Blokzincir tabanlı imza çoğu uygulamada “yeni bir imza türü” olmaktan çok, mevcut imzalama sürecinin üstüne eklenen kanıt katmanı gibi çalışır. Yani amaç, belgenin kendisini zincire koymak değil; belgenin belirli bir anda var olduğunu ve sonradan değiştirilmediğini doğrulamayı kolaylaştıran, değiştirilemez bir kayıt üretmektir.

Zincire genellikle şu veriler yazılır:

• Hash (özet değer): Belgenin içeriğinden üretilen tekil bir parmak izi gibidir. Belgede tek karakter değişse hash de değişir.
• Zaman bilgisi (zaman damgası mantığı): Kayıt, belgenin en geç hangi anda oluşturulduğu veya sisteme alındığı konusunda güçlü bir ispat izi oluşturur.
• Olay kaydı (event log): “Oluşturuldu, imzalandı, gönderildi, onaylandı, sürüm güncellendi” gibi işlem adımları. Bu kayıtlar denetim ve sürüm takibi için kullanılır.

Bu yapı, özellikle birden fazla tarafın aynı doküman üzerinde çalıştığı süreçlerde “kim, ne zaman, hangi sürüm üzerinde işlem yaptı?” sorusunu netleştirir.

Blokzincire ne yazılmaz: belgenin içeriği ve gizlilik

Pratikte ve gizlilik açısından doğru yaklaşım, belgenin içeriğini blokzincire yazmamak yönündedir. Açık blokzincirlerde kayıtlar herkes tarafından görüntülenebilir. İzinli (permissioned) blokzincirlerde erişim sınırlı olsa bile, zincire yazılan veri uzun süre saklanır ve sonradan geri almak zordur.

Bu nedenle zincirde çoğunlukla sadece hash ve asgari işlem metadatası tutulur. Belgenin kendisi ise kurum içi arşiv, güvenli doküman yönetim sistemi veya şifreli saklama gibi ayrı bir katmanda kalır. Böylece blokzincir tabanlı imza, gizliliği koruyup yine de “değişiklik oldu mu, kayıt aynı mı?” doğrulamasını mümkün kılar.

Elektronik imza, dijital imza ve blokzincir kaydı farkları

Hangi senaryoda hangisi kullanılır?

Kısa karşılaştırma tablosu: teknik ve hukuki ayrımlar

Terimler günlük dilde birbirine karışır. Pratikte doğru seçim, iki soruya bağlıdır: “İmzayı kimin attığını ne kadar güçlü ispatlamalıyım?” ve “Yıllar sonra hangi kanıtla doğrulayacağım?”. Blokzincir kaydı ise çoğu zaman imzanın yerine geçmez; imzalama sürecine eklenen bir kanıt izi olarak konumlanır.

Blokzincir tabanlı imza teknik olarak nasıl çalışır?

Belgeden hash üretimi ve imza ilişkilendirme

Süreç, belgenin ikili içeriğinden (dosyanın baytları) hash üretilmesiyle başlar. Hash, belgenin “parmak izi” gibidir ve genelde SHA-256 gibi modern algoritmalar kullanılır. Burada kritik nokta şudur: Aynı içerik her seferinde aynı hash’i vermelidir. Bu yüzden bazı sistemler PDF gibi formatlarda “görünür içerik aynı olsa bile değişebilen” meta verileri ve sürüm farklarını yönetmek için normalizasyon (canonicalization) adımı uygular.

Üretilen hash daha sonra bir imzalama eylemiyle ilişkilendirilir. Bu ilişki iki şekilde kurulabilir:

1. Hash’in, e-imza/dijital imza ile imzalanması (imza sahibi kimliği öne çıkar).
2. Hash’in sadece blokzincire yazılması (bütünlük ve zaman öne çıkar). Uygulamada en güçlü kurgu, hash + imza + imza sahibine dair doğrulama bilgisini aynı “kanıt paketi” içinde tutmaktır.

Zaman damgası ve zincire kayıt mantığı

Hash, blokzincirde bir işleme (transaction) veri olarak eklenir. İşlem, ağ tarafından doğrulanıp bir bloğa dahil edilince “kayıt altına alınmış” olur. Bu noktada iki önemli çıktı oluşur: işlem kimliği (txid/transaction hash) ve bloğun zincirdeki konumu (blok yüksekliği gibi).

Maliyet ve ölçek için sık kullanılan yaklaşım, tek tek hash yazmak yerine birçok belgenin hash’ini bir Merkle ağacında birleştirip sadece kök değeri (Merkle root) zincire “çapalamaktır”. Böylece her belge için daha sonra “bu kökün içindeydi” kanıtı üretilebilir.

Doğrulama: aynı belge mi, aynı kayıt mı?

Doğrulama iki soruyu cevaplar:

• Aynı belge mi? Sunulan belgenin hash’i yeniden hesaplanır ve kayıtlı hash ile birebir karşılaştırılır. Uyuşmuyorsa belge değişmiştir ya da farklı bir dosyadır.
• Aynı kayıt mı? Hash’in gerçekten ilgili blokzincir işleminde yer aldığı; işlem kimliği, blok bilgisi ve (varsa) Merkle kanıtı ile doğrulanır.

Eğer dijital imza da kullanıldıysa, ayrıca imzanın kriptografik doğrulaması yapılır ve sertifika zinciri, geçerlilik ve iptal durumu gibi kontroller eklenir. Bu sayede hem “bütünlük” hem de “kim attı?” sorusu daha güçlü cevaplanır.

Değiştirilemez denetim izi ve sahteciliğe karşı koruma

Kurcalama tespiti ve sürüm takibi

Blokzincir tabanlı imzada en güçlü fayda, “kurcalama”yı sonradan fark etmeyi kolaylaştırmasıdır. Belgenin hash’i zincire kaydedildiği için, aynı dosya tekrar üretildiğinde hash eşleşmiyorsa belge değişmiş demektir. Bu değişiklik bazen tek bir karakter, bazen de dosya meta verisi olabilir. Bu yüzden sürüm yönetimiyle birlikte tasarlamak önemlidir.

Doğru kurguda her sürüm için ayrı bir hash üretilir ve zincire ayrı bir olay kaydı düşülür. Böylece “son sürüm hangisiydi?” sorusu yanında “hangi tarihte hangi sürüm dolaşıma girdi?” sorusu da netleşir. Denetim sırasında tartışma genelde içerikten çok zaman çizelgesi ve sürüm bütünlüğü üzerinde çıkar.

İzlenebilirlik ve inkâr edememe (non-repudiation)

Zincirdeki kayıtlar, işlem akışını geriye dönük izlenebilir kılar. Ancak inkâr edememe (non-repudiation) otomatik gelmez. Blokzincir, “bu hash şu tarihte kaydedildi” der; “bunu kesin olarak şu kişi imzaladı” iddiası için kimlik ile işlemin bağının güçlü kurulması gerekir.

Bu bağ çoğu senaryoda güvenli e-imza, kurumsal imza süreçleri, güçlü kimlik doğrulama ve yetkilendirme kayıtlarıyla kurulur. Aksi halde bir kişi “anahtarım ele geçirilmişti” veya “bu işlem bana ait değil” gibi itirazlar ileri sürebilir ve teknik kayıt tek başına yeterince ikna edici olmayabilir.

Anahtar yönetimi ve kimlik doğrulama ilişkisi

Sistemin güvenliği, zincirden çok anahtar yönetimi ve kimlik doğrulama katmanında belirlenir. Özel anahtarın güvenli saklanması (donanımsal güvenlik modülü, akıllı kart/USB token gibi), çok faktörlü erişim, rol bazlı yetkilendirme ve kayıtların loglanması temel kontrol noktalarıdır.

Kurumsal kullanımda ayrıca imzalama yetkisinin doğru tanımlanması, ayrık görev (onaylayan ile yayınlayan farklı olsun) ve anahtar yenileme/iptal süreçleri önemlidir. Blokzincir kaydı bu kontrolleri “kanıtlanabilir” hale getirir; ama kontrolün kendisini tek başına sağlamaz.

Blokzincir tabanlı imzanın sağladığı başlıca faydalar

Çok taraflı imzalamada güven ve şeffaflık

Çok taraflı sözleşmelerde asıl sorun, tarafların aynı “son sürüm” üzerinde uzlaşması ve sürecin sonradan tartışmaya açık olmamasıdır. Blokzincir tabanlı imza, her tarafın aynı hash değerini ve aynı kayıt zamanını referans almasını sağlar. Böylece “bu belge ne zaman paylaşıldı, hangi sürüm imzalandı, süreçte sonra ne oldu?” gibi sorular daha az yoruma açık hale gelir.

Bu yaklaşım, özellikle tedarik zinciri, ortak proje dokümanları, mutabakat metinleri ve çoklu onay akışlarında iş görür. Taraflar birbirine tam güvenmese bile, denetim izi ortak bir zeminde tutulur. Yine de kimlik doğrulama ve yetki yönetimi iyi kurgulanmadıysa şeffaflık tek başına yeterli olmaz.

Denetim ve uyum süreçlerinde kanıtlanabilirlik

Denetimlerde çoğu zaman asıl ihtiyaç, belgenin içeriğinden çok zaman çizelgesinin ve bütünlüğün ispatıdır. Hash kaydı, “belge bu tarihten sonra değişmedi” kontrolünü teknik olarak kolaylaştırır. Ayrıca sürüm takibi düzenli yapılıyorsa, eski versiyonlar ile imza kayıtları arasındaki bağ daha net kurulur.

Uyum tarafında da pratik bir avantaj vardır: Zincire belge içeriği yazılmadığı için, kişisel veri ve ticari sırların gereksiz ifşası azaltılabilir. Bu, KVKK açısından da daha kontrollü bir veri minimizasyonu yaklaşımıyla uyumludur.

Süreç otomasyonu: akıllı sözleşmelerle ilişki

Blokzincir tabanlı imza, bazı iş akışlarında smart contract mantığıyla birlikte çalıştırılır. Örneğin belirli tarafların onayı tamamlanınca “imza tamamlandı” olayı otomatik kayda düşebilir, belirli bir tarihten sonra yeni sürüm oluşturulması engellenebilir veya teslimat-adım eşleşmesi tetiklenebilir.

Burada dikkat edilmesi gereken nokta, otomasyonun hukuki metnin yerini almadığıdır. Kod, süreç kuralını uygular. Metin, tarafların iradesini ve uyuşmazlık halinde yorum çerçevesini belirler. En sağlıklı kurgu, ikisini birbirini doğrulayan iki katman gibi tasarlamaktır.

Hukuki geçerlilik: Türkiye’de 5070, güvenli e-imza ve KVKK ilişkisi

Hangi durumlarda tek başına yeterli değildir?

Blokzincir tabanlı imza, Türkiye’de çoğu durumda “imzanın hukuki karşılığı” olarak değil, belgenin bütünlüğü ve zamanına dair ek kanıt olarak değerlendirilir. Çünkü 5070 sayılı Elektronik İmza Kanunu’nun “elle atılan imza ile aynı sonucu” bağladığı yapı, blokzincir kaydı değil güvenli elektronik imzadır. Güvenli e-imza da nitelikli elektronik sertifika ile, kimliği doğrulayacak şekilde kurulur. Bu çerçeveye dair temel özet için BTK’nın elektronik imza genel bilgisi sayfasındaki açıklamalar yol göstericidir.

Bu yüzden “sadece zincire hash yazdım, imza yerine geçer” yaklaşımı genelde zayıf kalır. Pratikte, tarafların kimliğini güçlü ispatlamanız gereken sözleşmelerde blokzincir kaydı, güvenli e-imzanın yerine değil yanına konur.

Ayrıca 5070, bazı hukuki işlemlerde güvenli e-imzanın kullanımını da sınırlar. Kanun, resmî şekle veya özel merasime tabi işlemler ile teminat sözleşmelerinin bir kısmında güvenli e-imza ile işlem yapılmasına izin vermez. Bu tür sınırlar varken, blokzincir kaydının tek başına “tam geçerlilik” sağlaması zaten beklenmemelidir.

Veri işleme ve saklama yükümlülükleri

Blokzincir mimarisi KVKK açısından iki noktada kritikleşir: veri minimizasyonu ve silme-imha. Zincire belge içeriği yazmak, özellikle açık blokzincirlerde, kişisel verilerin kontrolsüz yayılması riskini artırır. Bu yüzden iyi uygulama, zincirde yalnızca hash ve asgari işlem kaydı tutmak; belgeyi ve kimlik eşlemesini ayrı, erişim kontrollü bir sistemde saklamaktır.

Hash her zaman “kişisel veri değildir” demek de doğru olmaz. Hash bir kişiyle ilişkilendirilebiliyorsa veya bir kayıt sistemi içinde belirli bir kişiye bağlanıyorsa KVKK bakımından kişisel veri tartışması doğabilir. Bu noktada veri sorumlusu; aydınlatma, hukuki sebep, erişim yetkileri, saklama süresi ve güvenlik tedbirlerini baştan tasarlamalıdır.

KVKK ayrıca, işleme sebebi ortadan kalktığında verinin silinmesi, yok edilmesi veya anonim hale getirilmesi yükümlülüğünü düzenler. Uygulama yaklaşımı ve yöntemler için KVKK’nın silme, yok etme ve anonim hale getirme açıklamaları pratik bir çerçeve sunar. Zincir kayıtları geri alınamadığı için, kişisel veriyi zincire hiç yazmamak ve silme taleplerini zincir dışı katmanda karşılayacak bir tasarım kurmak çoğu senaryoda daha güvenlidir.

Sık sorulan sorular: zincire belge mi yazılır, yıllar sonra doğrulanır mı?

İmza sonrası belge değişirse ne olur?

Belge imzalandıktan sonra tek bir karakter bile değişse, yeniden hesaplanan hash farklı çıkar. Bu da “aynı dosya değil” sonucunu verir. Blokzincir kaydı silinmediği için eski hash, eski sürümü işaret etmeye devam eder. Yani sistem “değiştirilemez” değil, değişikliği görünür kılar.

Doğru uygulamada bu bir sorun değil, sürüm yönetimidir: Belge güncellenecekse yeni sürüm için yeni hash üretilir ve yeni bir kayıt oluşturulur. Böylece hangi tarihte hangi sürümün geçerli olduğu denetim iziyle takip edilir. Uyuşmazlıkta da genelde kritik soru şudur: “Taraflar hangi sürüm üzerinde irade beyan etti?”

Açık zincir mi izinli zincir mi daha uygun?

Tek bir “doğru” yok. Seçim; gizlilik, maliyet, performans, yönetişim ve uzun vadeli erişim beklentisine göre yapılır.

• Açık (public) zincir: Kayıtlar daha geniş bir ağda tutulduğu için uzun vadeli erişim ve bağımsız doğrulama avantajı olabilir. Ancak işlem ücretleri, ölçek ve kamuya açık görünürlük nedeniyle zincire yazılan veri çok dikkatli seçilmelidir.
• İzinli (permissioned) zincir: Erişim kontrolü ve kurum içi entegrasyonlar daha yönetilebilir olur. Buna karşılık “uzun yıllar sonra doğrulama” için ağın sürdürülebilirliği, düğüm sayısı, yedekleme ve yönetişim sözleşmeleri net olmalıdır.

Bazı modellerde izinli zincirdeki kayıtlar periyodik olarak açık zincire “çapalanır”. Bu, hem kontrol hem de dış doğrulama dengesini güçlendirebilir.

Hangi durumlarda gereksiz veya yanlış tercih olabilir?

Blokzincir tabanlı imza, her imzalama ihtiyacını çözmez. Şu durumlarda gereksiz veya riskli hale gelebilir:

• Kimlik ispatı kritikse ama güvenli e-imza veya güçlü kimlik doğrulama yoksa (zincir kaydı “kim imzaladı?” sorusunu tek başına çözmez).
• Belge sayısı çok yüksekse ve zincire her olayın yazılması maliyet ve performans sorununa dönüşüyorsa.
• Zincire yanlışlıkla kişisel veri veya ticari sır yazılacak bir tasarım yapıldıysa (geri alma pratikte mümkün değildir).
• Taraflar arasında zaten tek bir güvenilir kayıt sistemi ve sağlam denetim izi varken, blokzincir ek karmaşıklık yaratıyorsa.