Craig Wright: Değişmez dosya ve veri depolama sistemi

Bu yazı Dr. Craig Wright'ın 6 Ocak, 2018 tarihinde yayınlanan "An immutable file and data store" yazısından Türkçe'ye çevrilmiştir.
Çeviren: Emre Özdemir [@twitter, @literatus]

Bitcoin'in (BSV) kullanım alanları üzerine haftalık yazılar kaleme almaya başlıyorum. BSV Bitcoin'in tüm potansiyelinin kullanılmasına ve onu kullanan bir çok sistem ve uygulamanın yaratılmasına olanak veriyor. Bu çözümlerin tümü nChain'de aldığımız patentlere dayanıyor; yani Bitcoin SV zinciri haricinde kullanılamayacaklar.

062403e77c7664ac62fbcf64ae2c30de.png

(Alice gezintiye çıktı [çn. Alice Harikalar Diyarı'ndaki Alice'e atıf])

Bu hafta güvenli dosya depolama olarak kullanılabilecek bir sistemi inceleyeceğim.

Kullanıcımız Alice'in bir ECDSA açık anahtarı var:

  • Pa(0) onun anahtarıdır (bir PKI CA aracılığıyla tescillenebilir) ve bir Bitcoin adresi olarak kullanılmaz. O, bu "kimlik" anahtarını Bitcoin adresleriyle kamuoyuna açık bir şekilde ilişkilendirmez. Bunun yerine, kullanılan bir Bitcoin adresine bağlanan bir deterministik alt anahtar yaratmak için PCT başvuru numarası PCT/IB2017/050856'deki tekniği kullanabilir. Bundan sonra buna method-42 diyeceğiz. Bu işlemde başka patentler sözkonusu fakat bu gönderi için bu yeterli.
  • Da(0) Alice'in Pa(0) ile mesajları imzalarken kullandığı Özel Anahtar'dır.
  • Pa(1) yukarıdaki yönteme dayalı bir deterministik anahtardır ve bir Bitcoin adresiyle ilişkilidir. Bu adres kullanıcı istediği sürece bir dosyayı, sözleşmeyi, faturayı ve hatta bir resim dosyasını güvenli bir şekilde tutmak için kullanılabilir.
  • F(1) ilk dosyadır. Yaygın bir hash fonksiyonu (SHA256 gibi, fakat bununla sınırlı değil) ile oluşturulmuş bir hash'i vardır.

Bu teknik kullanılarak yapılabilecek şeylerin nasıl mümkün olduğunu göstermek adına, şimdi bu tekniğin (uygulama olarak görev yapan) dijital bir cüzdandaki bir dosyayı (her çeşit olabilir fakat örnek olarak resim dosyası kullanacağız) güvenle saklamada nasıl kullanılabileceğini bir örnekle göstereceğiz.

Bu örnekte, her dosyanın ayrı bir anahtarla şifrelendiği bir durumda bir dosyaya erişmek isteyen bir kullanıcı var. Eğer kullanıcının şifreleme anahtarlarını (ve dosyaları) saklama sorumluluğu olursa; şifreleme anahtarının, kullanıcının kendisinin veya donanımın erişilmez olduğu durumlarda şifrelenen dosyanın erişilmez olması sonucunu doğuran problemler meydana gelebilir. Bunun aksine, yine, şifreleme anahtarınının bir uygulama sağlayıcı ile saklanması, bu sağlayıcıya ve onun güvenlik mekanizmalarına belli oranda güven duyulmasını gerektirir. Eğer uygulama sağlayıcısının sistemleri hacklenirse yetkisi olmayan kişiler şifreleme anahtar(lar)ına erişebileceklerdir. Bu durumda dosyalar (mesela özel resimler) çalınabilir veya ele geçirilebilir. Dolayısıyla şifreleme anahtarının yetkisi olmayan taraflarca elde edilemeyeceği fakat aynı zamanda istenildiğinde tekrar türetilebileceği bir yöntemle saklamaya ihtiyaç vardır.

Dahası sistemimizde her dosya için ayrı bir anahtar kullanılır. Genellikle bir çok dosya için tek gizli anahtar kullanılır. Standart bir AES simetrik şifrelemesi tabanlı uygulamada kullanıcı binlerce dosyayı korumak için tek bir anahtar kullanır. Önerdiğimiz sistemde her dosya için ayrı bir anahtar kullanılmasına rağmen kullanıcının bu anahtarları kaybetmekten korkmasına gerek kalmaz.

PCT/IB2017/050856'nin göze batan faydası şudur ki bu tekniğin kullanımı her bir düğüm için bir özel ana anahtar [çn. master private key] temelinde, birden çok güvenli özel anahtara karşılık gelen birden çok ortak sırrın (common secret) üretilmesine izin vermesidir. Şimdi, düğümleri dosyaların saklanacağı uygulama "kutu"ları olarak düşünürsek, onu her dosya için yeni bir anahtar oluşturmak için kullanabilir ve sonra bu dosyanın Bitcoin blockchain'i üzerinde güvenli, gizli [çn. privately] ve kalıcı olarak saklanmasını sağlayabiliriz.

Bu amaca, uygulama fonksiyonları arasında önceden kararlaştırılan bir süreç temelinde, bir dizi ardışık deterministik anahtar belirleyerek erişiyoruz. Bu çok sayıda özel anahtar, sonuç olarak, her bir partide yalnızca bir özel anahtarı güvenli bir şekilde saklama gereksinimine rağmen, güvenli tutulur.

Daha da önemlisi, bu anahtar ve ilişkili Bitcoin adresi blockchain'deki bir dosya adresini hesaplamak için kullanıldığında dosya sahipliği psödonim olarak kalacaktır. Alice Pa(0) ile hiç bir ilişkisi bulunmayan bir Bitcoin cüzdanı ve anahtar kullanarak dosyanın deterministik adrese gönderilmesini fonlayabilir.

Bu anahtara ve ilişkili adrese Pf(0) yani fonlama adresi diyeceğiz. Alice'in kimliğiyle hiç bir ilişkisi olmayan Pf(0)'de bitcoinleri olabilir ve yine de güvenli ve gizli bir şekilde Pa(1)'ya gönderebilir.

Özünde, bu teknik, gelişmiş güvenli iletişim ve dosya depolama ve hatta güvenli (ve hatta watermark'lı) dosyaların oluşturulmasını ve bir ağdaki bir çift düğüm veya taraf arasında alışveriş yapılmasını sağlar. Kullanıcı Bitcoin blockchain'i üzerinde örneğin bir resim dosyası gibi bir dosya kaydedebileceğini ve bunun on yıllar sonra erişilebilir olacağını bilir. Bu, daha sonraki gönderilerde tartışacağım diğer tekniklerle, bir kullanıcının sahip olduğu tüm dosyaları ve verileri hiçbir kayıp veya ödün verme korkusu olmadan güvenli bir şekilde kaydetmesini sağlar.

Yöntem:

Alice, ECDSA ana anahtarıyla başlar (bunun kendisi bir alt anahtar olabilir, fakat zaten karışık bir konuyu daha da karıştırmayacağım).

  • Alice'in bir dosyası vardır. Uygulamanın bölümleri, çözümümüzde, bir ağ üzerindeki bir düğüm çifti gibi hareket eder ve uygulama veya cihaz içerisinde bilgi alışverişi [çn. exchange] yapar (yani, partiler). Uygulama her dosya için bir anahtar hesaplayabilir ve her dosyanın kendi özel ve açık anahtarını sürdürmesine, özel anahtarlarını gizli tutarken kendi açık anahtarlarını değiştokuş etmelerine izin verebilir.
  • Uygulama kendi fonksiyonel bileşenleri arasında bir mesajı alışverişinde bulunur.
  • Uygulama bir mesaja dayalı bir deterministik anahtar üzerinde "uzlaşabilir". Bu anahtar, aynı anahtarın anahtar üretme algoritmasının birden çok işletilmesi ile tekrar-üretilebilir oluşu anlamında "deterministik"tir.
  • Alice şunlara sahiptir: ana anahtar, Pa(0) ve bu açık anahtara yani Pf(0)'a bağlı tek seferlik Bitcoin ödeme adresi. Alice için güvenli dosyayı fonladıktan sonra bu adresin ve anahtarın tutulmasının bir önemi yoktur. Doğrusu, bu adresi tek bir ödeme (ve dosya yükleme) için kullanması ve bir kenara atması daha iyidir. Bitcoin Whitepaper'ında kullanılan gizlilik metodu budur.
  • Kamuya açık blockchain üzerinde hiç bir zaman kullanılmamış Pa(0)'ı sadece Alice bilmektedir.
  • Alice, method-42'deki işlemi kullanarak dosyalarını koruması için madencilere ödeme yapacağı anahtar ile ana anahtarı arasında bir anahtar oluşturur, s(af.0).
  • Alice şimdi daha sonra rahatlıkla belirleyebileceği bir adres hesaplar ve bu uygulama tarafından deterministik bir işlem ile hesaplanabilir:

s(file.1) = H[ Da(0) | H(file) | INDEX ]

Pf(1) = s(file.1) X G — > bu bir elliptic curve işlemi.

  • Index değeri bir çok şekilde belirlenebilir. Basitliği belli bir seviyede tutmak adına bu gönderide incelenmedi.
  • Index şu kadar basit olabilir:

INDEX= Hash(index); burada index dosya numarası ya da daha da basit kriptografik olmayan bir hash veya basit bir dosya özetidir [çn. bkz. checksum].

  • Pa(0) işlem boyunca gizli [çn. private] kalmaya devam eder. Doğrusu, Pa(0) WO2017145010A1'deki gibi bir treshold-based key bile olabilir.

e2e561bcfc15fcea30661fabc6fe0120.png

İşlem şimdi Alice'e aşağıdaki yöntemle hesaplanan Pa(1) ile ilişkili Bitcoin adresinden bir dosya göndermesine imkan verir:

  • Pa(1) = Pf(1) + Pa(0) = [ s(file.1) + Da(0) ] X G

Alice şimdi blockchain'e kaydetmek istediği dosyayı içeren bir gönderi [çn. transaction] kullanarak bir dosya gönderebilir. Küçük dosyalar, kalıcı veya budanabilir [çn. bkz. pruning] olma ihtiyacına göre OP_RETURN veya OP_PUSHDATA kullanılarak gönderilebilir.

  • OP_PUSHDATA1 / {DATA} / OP_DROP

6517ae568739a28301f2b7fe3df3cb14.png

OP_PUSHDATA4, işlem sırasına [çn. stack] 4.3 GB sürmeye izin verir.

Dosya ECDSA kullanılarak imzalanmıştır ve bu nedenle doğrulanır. Bunu şifrelerken (simetrik şifreleme algoritması olarak AES ve diğerleri kullanılabilir), kamuoyuna açık bilgileri ve Pa(0)'ı kullanarak deşifrelemede kullanılacak bir sır hesaplayabileceğinden , artık Pf (0) için özel anahtara sahip olmasa da, bunun kendi dosyası olduğunu bilir.

Gönderi içerisindeki dosya yöntem-42'deki süreç ile şifrelenir.

  • Pf(0) = Df(0) X G
  • Pa(0) = Da(0) X G
  • s.f(1) = Da(0) X Df(0) X G = Df(0) X Pa(0) = Da(0) X Pf(0)

Alice Pa(1)'i bildiği ve Pf(0)'ın Pa(1)'e bir dosya göndermek kullanıldığını görebildiği için, açık anahtar Pf(0)'ı da görebilir. Sonuç olarak, Da(0)'ı bildiği için s.f(1)'i de hesaplayabilir.

Böylece Alice kullanılan anahtarları ve dosya konumunu hesaplayabilir. Bu dosya simetrik anahtar s.f(1) kullanılarak şifrelenmiştir. Dolayısıyla hiç bir harici unsur, dosyayı göremediklerinden ötürü hash'ini de saptayamaz.

Alice şimdi hashtable tabanlı bir sistem kullanarak bir çok dosyayı eşleştirebilir [çn. to map]. Küçük bir sayesinde Alice her yerden ve her sistemden dosyalarına güvenle erişebilir. Konunun bu yönünü bu ay tekrar inceleyeceğim.

Unix dosyaları birbirine bağlar ve klasör oluşturmak için basit bir dizin kullanır. Alice de benzerini yapabilir. Sadece bir anahtar indeksiyle artık her yerden dosyalarına erişmeye başlayabilir.

Daha da önemlisi, dosyaların varlığını sadece Alice bilmektedir. Pa(1)'a, Pa(0)'dan deterministik bir yolla ulaşılmış olmasına rağmen, Pa(1)'in blockchain üzerindeki varlığı yine de harici unsurlara Pa(1) gönderisi içerisindeki dosyaların Alice ile olan bağlantısını ya da Pa(0) ilişkisini kuracak bir yol vermemektedir.

Sonuç olarak Alice dosyalarına erişimi tamamlamıştır. Sadece şu an için değil, erişmek istediği sürece. Dosyalarını çocukluğundan itibaren saklayabilir ve geri gelip 50 sene sonra hepsini bulabilir. Görüntüleri kaydeden bir sistem, her görüntüyü bir kez (ve yalnızca bir kez) kaydedebilir, çünkü hashleri eşleştirme yeteneği, Alice'in bir dosyanın kopyasını kaydetmiş olup olmadığını daima bileceği anlamına gelir. Yalnızca ve yalnızca kendisinin erişebileceği ve psödonim ilişkilendirme temelinde tüm gizliliğini sürdürebileceği sürücü depoları yaratabilir.

Aynı zamanda güvenlik duvarları ve bölümlendirmeler [çn. partition] oluşturabilir. method-42 sürecini kullanarak, Alice şimdi her dosyayı ayrı ayrı şifreleyebilir ve bu sayede her dosyayı (tamamını veya bir parçasını) paylaşıma açabilir ve hatta dosyalara olan erişimi satabilir. Daha da önemlisi, her dosyanın tek bir anahtarla şifrelendiği bir sürücü şifreleme sisteminde olduğundan farklı olarak Alice tüm dosyalar için ayrı bir anahtara sahiptir. Eğer bir anahtar paylaşılır veya ele geçirilirse bu durum diğer dosyaların güvenliğini ve gizliliğini tehlikeye atmaz.

Pa(1) ve dosyadaki değerleri bir tek Alice bildiğinden, tümüyle psödonim, yüksek erişilebilirliğe sahip, dağıtık bir dosya paylaşımına sahiptir. Gizli, şifreli ve takip edilebilir. Hatta zaman içinde dosya üzerinde yapılan değişiklikleri haritalandırmak için GIT benzeri bir sistem bile kullanabilir. Her dosyanın (her yerden erişilebilir) tek bir kopyasına sahip olduğu için umduğunuzdan çok daha az bir depolama alanı kullanacaktır.

Bunu Özet-tabanlı mesaj doğrulama kodlarını [bkz. HMAC] ve Alice'in daha fazla güvenliğe ve gizliliğe sahip olduğu diğer şemaları kullanarak daha da güvenli hale getirebilir fakat bu bugünkü gönderinin kapsamının dışında.

XOR ve OTP (tek kullanımlık şifre)'ler

Hatta AES ve yavaş şifreleme metotlarından bile vazgeçebiliriz. Şifrelemenin en üst düzeyi OTP'dir (veya tek kullanımlık şifre). Hızlı ve tek kullanımlık bir şifreleme sistemi yaratmak için XOR ve bir Zeta fonksiyonuyla birlikte kullanılabilir.

Bu mekanizmaları bu gönderide incelemeyeceğim, fakat bunlar bu sene yayınlayacağımız diğer patentlerle bağlantılı.

İki-parti sistemi

Şimdi Bob'u ekliyoruz.

Bu teknik ayrıca, ortak sır saklanmasına gerek kalmadan taraflar arasında güvenli iletişimi mümkün kılar, çünkü ortak sır, her bir taraf tarafından paylaşılan mesaj temelinde gerektiği şekilde ayrı ayrı belirlenebilir.

Önemli olarak, iletinin özel anahtarlarla aynı derecede güvenlikle saklanması gerekmez ve bazı durumlarda herkes tarafından erişilebilir olabilir.

Kullanıcımız Bob'un bir ECDSA açık anahtarı vardır:

  • Pb(0), Bob'un açık anahtarıdır (PKI CA ile tescillenebilir) ve Bitcoin adresi olarak kullanılmaz. Bu "kimlik" anahtarını herkese açık bir şekilde kendi Bitcoin adresiyle ilişkilendirmez. Bunun yerine, PCT başvurusu numara PCT/IB2017/050856'da bulunan teknik ile deterministik bir alt anahtar yaratıp Bitcoin adresiyle ilişkilendirebilir.
  • Db(0), Bob'un Pb(0) ile iletileri imzaladığı Gizli Anahtarı'dır.
  • Pb(1) yukarıda bahsedilen metotta tarif edilen deterministik anahtardır ve bir Bitcoin adresiyle ilişkilidir. Kullanıcı istediği sürece güvenli bir şekilde bir dosyayı, kontratı, faturayı veya hatta bir resim dosyasını tutan bir adres.

Her bir düğüm [ç.n. parti] şunları belirler:

  • mevcut özel anahtarına ve deterministik anahtarına bağlı olan, özel anahtarının güncellenmiş bir versiyonunu; ve
  • diğer düğümün mevcut açık anahtarına ve deterministik anahtarına bağlı olan, açık anahtarının güncellenmiş versiyonunu.

Mevcut özel anahtara ve deterministik anahtara bir matematiksel işlem uygulanarak güncellenmiş determinasyon sağlanabilir.

  • Sonra her bir düğüm kendi güncellenmiş özel anahtarına ve diğer düğümün güncellenmiş açık anahtarına bağlı olarak yeni bir ortak sır belirleyebilir. Deterministik anahtar paylaşılan iletiye bağlı olduğundan, ve iki düğüm için de erişilebilir olduğundan, aynı ortak sır iki düğüm tarafından da belirlenebilir; fakat güncellenmiş farklı özel ve açık anahtarların bir kombinasyonu şeklinde.

Temel olarak, yukarıda anlatılan işlemin modifiye edilmiş bir versiyonunu kullanabilir ve Alice ve Bob arasındaki bir işleme veri dahil edebiliriz.

Böyle bir durumda, Alice ve Bob birbirlerinin sırrını bilir, ve birbirlerinin dosyalarına erişebilir ve bunun diğer taraftan geldiğini ispat edebilir. Aynı zamanda, dosya herkes tarafından erişilebilir olsa bile deşifre edilemez.

Hatta, Alice ve Bob bir işlemin ön-imzalı nLocktime-tabanlı zamanaşımına izin verebilir, böylece iki taraf da dosyanın zamanaşımına uğramasına ve budanmasına [ç.n. pruned] izin veren, zamanaşımına uğrayan UTXO işlemini (bu zincirde tutulmaz) göndermeyi seçebilir. Yine, açıklayacak çok fazla şey var. Fakat bugün ele alınan yönler bile ortaya bir kaç yeni şirket çıkarmak için yeterli (bunun için üzgünüm Dropbox, OneDrive ve Google Drive...).

Sonuç olarak

PCT/IB2017/050856 için uygulamalar oldukça fazla ve çeşitli, ve Bitcoin ve blockchain ortamları ile sınırlı değiller. Özünde, bu buluşlar hassas veri, iletişim ve kaykakların güvene alınmasının gerektiği her durumda önemli güvenlik avantajları sunuyor.

Dolayısıyla bulut depolama, dijital komünikasyonun yeni yolları ve IoT cihazlarının öngörülen büyümesi geliştikçe/arttıkça, bunların sayısız potansiyel kullanım alanları olacaktır.

6fbdcb6d1cafd6ac10f6246ef805c6b3.jpeg

Metanet'e hoş geldiniz. Sistem, hayal edebileceğiniz tüm tavşan deliklerinden [ç.n rabbit hole] daha derin.

Artık tümünü açıklamaya başlıyorum.

30f8134129d9f9c5a350c0b8dbdc6c24.jpeg

Referanslar:

  1. Determining a common secret for the secure exchange of information and hierarchical, deterministic cryptographic keys.https://patentimages.storage.googleapis.com/e9/d4/1a/644d344019a178/EP3268914B1.pdf
  2. Secure multiparty loss-resistant storage and transfer of cryptographic keys for blockchain-based systems in conjunction with a wallet management system https://patentimages.storage.googleapis.com/38/81/de/27b37646a28b52/WO2017145010A1.pdf
Yazar Bitcoin Çevirileri
Yayınlandı Feb 19, 2019
Paylaşıldı
 
{"currency":[{"name":"US Dollar","abbr":"usd","symbol":"$","type":"fiat","priceBtc":100.79036303700001}],"appuser":null}