निंदनीय एमईजीए सेवा की शुरुआत के बाद, कुछ हद तक, इसकी सुरक्षा के बारे में बात थोड़ी ऊब गई और शांत हो गई। आज, सेवा अपने जीवन को जीती है और किसी ने भी इसे नहीं तोड़ा। सभी वार्तालापों में से, किसी कारण के लिए, शब्द "उपयोगकर्ता नियंत्रित एन्क्रिप्शन" (UCE, या उपयोगकर्ता नियंत्रित क्रिप्टोग्राफ़ी), जो MEGA का दावा करता है, चूक गया था। "मिस्ड" शब्द से मेरा तात्पर्य इस तथ्य से है कि हमने उन सभी संभावनाओं पर विचार नहीं किया है जो एक क्रिप्टोग्राफिक इंजन है जो क्लाइंट-साइड जावास्क्रिप्ट में चलता है।

बेशक, इसके द्वारा MEGA सेवा का अर्थ केवल यह है कि एन्क्रिप्शन कुंजियाँ सर्वर पर संग्रहीत नहीं हैं, और उनकी सभी क्रिप्टोग्राफ़ी ब्राउज़र के संदर्भ में की जाती है। उसी समय, सेवा के लॉन्च के बाद, इस तथ्य के बारे में बहुत सारी बातें हुईं कि यह अस्थिर क्रिप्टोग्राफिक एल्गोरिदम का उपयोग करता है और सामान्य तौर पर सब कुछ खराब है और हम सभी मर जाते हैं, और एफएसबी हमारी फाइलों को पढ़ता है । इसने मुझे "यूसीई" की अवधारणा का विस्तार करने और सेवा की सुरक्षा सुनिश्चित करने के लिए कुछ तंत्रों को बदलने या पूरक करने के लिए वास्तव में क्रिप्टोग्राफी का नियंत्रण लेने के लिए प्रेरित किया।

इस लेख में, मैं आंशिक रूप से मेगा मेगा कोड के दो मेगाबाइट में होने वाले जादू को हल करूँगा और दिखाऊंगा कि क्रिप्टोग्राफी और चिंता को रोकने के लिए आप कुछ तरीकों को कैसे ओवरराइड कर सकते हैं। परिणामस्वरूप, हमें दो-कारक प्रमाणीकरण और महत्वपूर्ण जानकारी के हार्डवेयर एन्क्रिप्शन के साथ क्लाउड-आधारित फ़ाइल संग्रहण सेवा मिलती है।

मेगा, यूसीई और ऑल-ऑल-ऑल

तो, आइए उन तकनीकों को देखते हुए शुरू करें, जिन पर सेवा का ग्राहक हिस्सा बनाया गया है, नए उपयोगकर्ता कैसे पंजीकृत हैं, प्रमाणित उपयोगकर्ता पंजीकृत हैं, पासवर्ड परिवर्तन और फ़ाइल अपलोड / डाउनलोड।

जावास्क्रिप्ट

जैसा कि आप पहले से ही जानते हैं, सेवा का पूरा क्लाइंट हिस्सा जावास्क्रिप्ट पर आधारित है, सभी स्क्रिप्ट और ब्राउज़र द्वारा लोड किए गए SHA-256 चेकसम मुख्य पृष्ठ कोड में लिखे गए हैं। डाउनलोड स्वयं इस प्रकार है: सभी फाइलों को चेकसम के लिए जांचा जाता है, जिसके बाद उन्हें एक बीएलओबी में संयोजित किया जाता है, जो ब्राउज़र को दिया जाता है। Js-files source कोड से पता चलता है कि वे अलग-अलग लोगों द्वारा लिखे गए थे और कभी-कभी अजीब मोती पाए जाते हैं, जैसे कि कॉपी-पेस्ट, अर्थहीन परिस्थितियों और बस अजीब चर के परिणाम।







साइट के स्रोत कोड का अध्ययन करने की प्रक्रिया में, मैंने यह भी देखा कि यह काफी सक्रिय रूप से अपडेट किया जा रहा है, डेवलपर्स छोटी त्रुटियों को ठीक करते हैं और पहले से लिखे गए कोड को अनुकूलित करते हैं, जो अच्छी खबर है। कोड स्वयं एक बहुत ही सरल और बिना अनावश्यक रैपिंग के प्रोटोटाइप के रूप में लिखा गया है: साइट तीन सौ वैश्विक चर और 8000 से अधिक कार्यों के साथ प्रबंधित करती है। साइट की वास्तुकला को समझना और उसका कोड बदलना बहुत सरल था।

तीसरे पक्ष के ढांचे में, MEGA jQuery का उपयोग करता है (अब यह इसके बिना कहीं भी नहीं है), Ext JS और SJCL । उत्तरार्द्ध एईएस एन्क्रिप्शन के साथ क्रिप्टोग्राफिक कोर को लागू करता है। SJCL भंडारण कुंजी और अन्य बाइट सरणियों के लिए एक दिलचस्प प्रारूप भी प्रदान करता है: नियमित सरणी में केवल बाइट्स का पीछा करने के बजाय, उन्हें a32 नामक एक प्रारूप में "संकुचित" किया जाता है। इसका सार यह है कि किसी भी बाइट सरणी की सामग्री को 32-बिट संख्या में पैक किया जाता है और छोटी लंबाई की एक सरणी के लिए लिखा जाता है। यही है, सरणी के हर 4 बाइट्स को एक केल इंट में बदल दिया जाता है। साइट कोड में फ़ंक्शंस होते हैं जो सभी प्रकार के रूपांतरणों को {a32 array, string, base64 string} सेट करते हैं।

मुख्य जानकारी

पंजीकरण और प्रमाणीकरण प्रक्रियाओं के विवरण के लिए आगे बढ़ने से पहले, यह उस जानकारी पर विचार करने के लायक है जो एन्क्रिप्शन के अधीन है, अर्थात्:

• खाता मास्टर कुंजी , जो उपयोगकर्ता पंजीकरण के समय अनियमित रूप से बनाई गई है और इसकी लंबाई 128 बिट्स है। और सिद्धांत रूप में, सममित एन्क्रिप्शन के लिए उपयोग की जाने वाली सभी कुंजी की लंबाई 128 बिट्स है।
• RSA निजी कुंजी : माउस के मूवमेंट और कीबोर्ड इनपुट के आधार पर पंजीकरण के समय बनाई गई। इस लेख में, मैं असममित क्रिप्टोग्राफी पर ध्यान केंद्रित नहीं करूंगा, क्योंकि इसका उपयोग डाउनलोड की गई फ़ाइलों को साझा करने के लिए किया जाता है, और मेरे पास उपयोगकर्ता डेटा के प्रमाणीकरण और एन्क्रिप्शन की प्रक्रिया को बदलने का काम था।
• व्यक्तिगत फ़ाइल कुंजियाँ और फ़ाइलें स्वयं , सेवा पर अपलोड की गईं। जब फ़ाइल अपलोड की जाती है, तो कुंजी को बेतरतीब ढंग से बनाया जाता है, इस कुंजी का उपयोग फ़ाइल डेटा को एन्क्रिप्ट करने के लिए किया जाता है, और एक व्यक्तिगत फ़ाइल कुंजी के आधार पर बनाई गई कुंजी और इसके चेकसम का उपयोग विशेषताओं को एन्क्रिप्ट करने में किया जाता है।

कोड के करीब

अब मैं पंजीकरण और प्रमाणीकरण प्रक्रियाओं का विश्लेषण करने का प्रस्ताव करता हूं, देखें कि मास्टर कुंजी कैसे बनाई जाती है और इसे कैसे एन्क्रिप्ट किया जाता है।
यहाँ मैंने कागज के एक टुकड़े पर इन प्रक्रियाओं को चित्रित करने की कोशिश की और आपको पागलपन के पूरे सार को समझने के लिए मैंने यह भी बताया:

नया उपयोगकर्ता पंजीकरण

पंजीकरण प्रक्रिया स्वयं ही भ्रामक है, प्रश्नावली भरने के बाद, कार्यों का एक शक्तिशाली गुच्छा कहा जाता है, लेकिन हम api_createuser फ़ंक्शन में रुचि रखते हैं:

 //      - function api_createuser(ctx, invitecode, invitename, uh) { var i; var ssc = Array(4); // session self challenge, will be used to verify password var req, res; if (!ctx.passwordkey) { ctx.passwordkey = Array(4); for (i = 4; i--;) ctx.passwordkey[i] = rand(0x100000000); } if (!u_k) api_create_u_k(); //   - u_k for (i = 4; i--;) ssc[i] = rand(0x100000000); //     if (d) console.log("api_createuser - masterkey: " + u_k + " passwordkey: " + ctx.passwordkey); //  -         ( k) //  ts    ssc     req = { a: 'up', k: a32_to_base64(encrypt_key(new sjcl.cipher.aes(ctx.passwordkey), u_k)), ts: base64urlencode(a32_to_str(ssc) + a32_to_str(encrypt_key(new sjcl.cipher.aes(u_k), ssc))) }; if (invitecode) { req.uh = uh; req.ic = invitecode; req.name = invitename; } if (d) console.log("Storing key: " + req.k); api_req([req], ctx); } 

इस समारोह में, हम निम्नलिखित बातों में रुचि रखते हैं:

• u_k - मास्टर कुंजी ही, एक वैश्विक चर। api_create_uk द्वारा बनाई गई 4 32-बिट संख्याओं की एक सरणी
• ssc सिर्फ एक यादृच्छिक सरणी है जिसे मास्टर कुंजी पर एन्क्रिप्ट किया गया है, जिसे उसके सार्वजनिक मूल्य के साथ संक्षिप्त किया गया है और सर्वर पर भेजा गया है। बाद में इसका उपयोग प्रमाणीकरण के दौरान मास्टर कुंजी की शुद्धता को सत्यापित करने के लिए किया जाएगा।
• sjcl - AES को लागू करने वाली क्रिप्टोग्राफिक लाइब्रेरी
• rand() - स्थानीय RC4- आधारित छद्म यादृच्छिक संख्या जनरेटर कार्यान्वयन
• encrypt_key() एक सममित क्रिप्टोग्राफी सेवा की आधारशिला समारोह है। कुंजी-आरंभीकृत sjcl ऑब्जेक्ट और एन्क्रिप्ट की जाने वाली एक सरणी को स्वीकार करता है। फ़ंक्शन कोड नीचे दिया गया है और, उम्मीद है, कोई स्पष्टीकरण नहीं चाहिए।

 // encrypt/decrypt 4- or 8-element 32-bit integer array function encrypt_key(cipher, a) { if (a.length == 4) return cipher.encrypt(a); var x = []; for (var i = 0; i < a.length; i += 4) x = x.concat(cipher.encrypt([a[i], a[i + 1], a[i + 2], a[i + 3]])); return x; } 

परिणामस्वरूप, पंजीकरण के बाद, निम्नलिखित सर्वर पर भेजे जाते हैं:

• मास्टर कुंजी खाता पासवर्ड से प्राप्त एक कुंजी पर एन्क्रिप्ट की गई है
• प्रपत्र ssc||encrypt_AES-128(u_k, ssc) का एक स्ट्रिंग ssc||encrypt_AES-128(u_k, ssc)

उपयोगकर्ता लॉगिन

अब आप आसानी से प्रमाणीकरण प्रक्रिया पर जा सकते हैं। संक्षेप में, यह इस तरह किया जाता है:

1. उपयोगकर्ता लॉगिन / पासवर्ड दर्ज करता है
2. यदि पहले प्रमाणीकरण कदम पारित किया जाता है, तो एन्क्रिप्टेड मास्टर कुंजी और पंजीकरण के दौरान बनाए गए प्रमाणीकरण अनुक्रम ( ssc ) सर्वर से आते हैं
3. उपयोगकर्ता द्वारा दर्ज किए गए पासवर्ड पर मास्टर कुंजी को डिक्रिप्ट किया गया है
4. प्रमाणीकरण अनुक्रम को मास्टर कुंजी पर डिक्रिप्ट किया जाता है और इसकी सार्वजनिक मूल्य के साथ तुलना की जाती है - यह मास्टर कुंजी और पासवर्ड की शुद्धता की जांच करता है।

उपरोक्त सभी के लिए, कॉलबैक फ़ंक्शन api_getsid2 :

 //  -      function api_getsid2(res, ctx) { var t, k; var r = false; if (typeof res == 'object') { //  sjcl-aes    var aes = new sjcl.cipher.aes(ctx.passwordkey); //       -... if (typeof res[0].k == 'string') { k = base64_to_a32(res[0].k); if (k.length == 4) { // ...    k = decrypt_key(aes, k); //  - sjcl-aes,  - aes = new sjcl.cipher.aes(k); //    ssc    if (typeof res[0].tsid == 'string') { t = base64urldecode(res[0].tsid); //           //    - ,          if (a32_to_str(encrypt_key(aes, str_to_a32(t.substr(0, 16)))) == t.substr(-16)) r = [k, res[0].tsid]; } //     RSA-,      else if (typeof res[0].csid == 'string') { var t = mpi2b(base64urldecode(res[0].csid)); var privk = a32_to_str(decrypt_key(aes, base64_to_a32(res[0].privk))); var rsa_privk = Array(4); // decompose private key for (var i = 0; i < 4; i++) { var l = ((privk.charCodeAt(0) * 256 + privk.charCodeAt(1) + 7) >> 3) + 2; rsa_privk[i] = mpi2b(privk.substr(0, l)); if (typeof rsa_privk[i] == 'number') break; privk = privk.substr(l); } // check format if (i == 4 && privk.length < 16) { // TODO: check remaining padding for added early wrong password detection likelihood r = [k, base64urlencode(crypto_rsadecrypt(t, rsa_privk).substr(0, 43)), rsa_privk]; } } } } } ctx.result(ctx, r); } 

पंजीकरण / प्रमाणीकरण के लिए एक बोनस के रूप में, आप पासवर्ड बदलने की प्रक्रिया पर एक नज़र डाल सकते हैं।

 //    function changepw(currentpw, newpw, ctx) { var pw_aes = new sjcl.cipher.aes(prepare_key_pw(newpw)); api_req([{ a: 'up', currk: a32_to_base64(encrypt_key(new sjcl.cipher.aes(prepare_key_pw(currentpw)), u_k)), k: a32_to_base64(encrypt_key(pw_aes, u_k)), uh: stringhash(u_attr['email'].toLowerCase(), pw_aes) }], ctx); } 

इस फ़ंक्शन का कोड स्वयं के लिए बोलता है: हम पुराने और नए पासवर्ड से प्राप्त दो कुंजी पर मास्टर कुंजी को एन्क्रिप्ट करते हैं, और फिर इन मूल्यों को सर्वर पर भेजते हैं। यदि वर्तमान पासवर्ड ने संपर्क किया है, तो इसे एक नए के साथ बदल दिया जाता है। यहां मैं prepare_key_pw फंक्शन पर अधिक ध्यान देना चाहता था, जो कि पिछले सभी ऑपरेशनों में निहित था। इसका कार्य स्ट्रिंग पासवर्ड को a32 ऐरे में बदलना है, और फिर कुंजी व्युत्पत्ति ऑपरेशन निम्नानुसार करना है:

 // convert user-supplied password array function prepare_key(a) { var i, j, r; var aes = []; var pkey = [0x93C467E3, 0x7DB0C7A4, 0xD1BE3F81, 0x0152CB56]; for (j = 0; j < a.length; j += 4) { key = [0, 0, 0, 0]; for (i = 0; i < 4; i++) if (i + j < a.length) key[i] = a[i + j]; aes.push(new sjcl.cipher.aes(key)); } for (r = 65536; r--;) for (j = 0; j < aes.length; j++) pkey = aes[j].encrypt(pkey); return pkey; } 

इस फ़ंक्शन ने बहुत सारी शिकायतें पैदा कीं, क्योंकि यह एक होमग्रोन एल्गोरिथम पर आधारित है। लेख के लेखन के दौरान, सेवा के निर्माता अपने कोड को थोड़ा बदलने में कामयाब रहे, लेकिन मैंने यहां कोई महत्वपूर्ण बदलाव नहीं देखा। इसका सार यह है कि एक यादृच्छिक कुंजी से एक अविभाज्य कुंजी प्राप्त करने के लिए एक निरंतर कुंजी पर प्रेषित पासवर्ड 65536 बार एन्क्रिप्ट किया गया है। सेवा के रचनाकारों ने मौजूदा एल्गोरिदम का उपयोग क्यों नहीं किया (उदाहरण के लिए, PBKDF2) एक रहस्य बना हुआ है।

फ़ाइलों को डाउनलोड और एन्क्रिप्ट करें

संक्षेप में, इस पूरी प्रक्रिया को निम्नानुसार दर्शाया जा सकता है:

मैं आपको चेतावनी देता हूं, इस छवि की लंबी समझ मस्तिष्क के लिए खतरनाक है, इसलिए नीचे मैं आपको बताऊंगा कि यह सब कैसे होता है।

जैसा कि मैंने पहले ही कहा था, अपलोड के दौरान, प्रत्येक फ़ाइल के लिए 6 32-बिट नंबरों से अपना रैंडम की-एरे बनाया जाता है। इस सरणी के पहले चार तत्वों का उपयोग फ़ाइल की सामग्री को एन्क्रिप्ट करने के लिए किया जाता है, और अंतिम दो - काउंटर के प्रारंभिक मूल्यों के रूप में, जिसके साथ फ़ाइल के चेकसम की गणना की जाती है। यह सरणी ul_key वैश्विक चर में संग्रहीत है। इसकी सामग्री JSON-serialized string ul_KeyNonce में दर्ज की गई है।

एन्क्रिप्शन स्वयं वेब वर्कर (यदि ब्राउज़र इस तकनीक का समर्थन करता है) या केवल पृष्ठ के मुख्य कोड के अंदर होता है। जब फ़ाइल भेजने के लिए तैयार है, तो अपनी विशेषताओं को एन्क्रिप्ट करने के लिए (फिलहाल, विशेषताओं का मतलब केवल फ़ाइल का नाम है), ul_key और फ़ाइल चेकसम के आधार पर एक नया ul_key बनाया जाता है। यह कुंजी तब मास्टर कुंजी पर एन्क्रिप्ट की जाती है और फ़ाइल विशेषताओं के साथ सर्वर पर भेजी जाती है। इन सभी क्रियाओं के लिए initupload3 और api_completeupload2 फ़ंक्शन ज़िम्मेदार हैं। ul_chunkcomplete कुंजी ul_chunkcomplete फ़ंक्शन में filekey है, नीचे मैं इसका एक हिस्सा दूंगा।

 //   :         function initupload3() { // ...  =) //      // ul_key    , // ul_keyNonce   Web Worker    //         ul_key = Array(6); for (i = 6; i--;) ul_key[i] = rand(0x100000000); ul_keyNonce = JSON.stringify(ul_key); ul_macs = []; // ...     ,     ... //  sjcl-aes     ul_key ul_aes = new sjcl.cipher.aes([ul_key[0], ul_key[1], ul_key[2], ul_key[3]]); // ... //    : //    ,    onUploadStart(ul_queue_num); ul_dispatch_chain(); } //       function ul_chunkcomplete(slot,pos,response) { // ... var t = []; // ul_macs -     ,   worker' for (p in ul_macs) t.push(p); //     ,      -   t.sort(function(a,b) { return parseInt(a)-parseInt(b) }); for (var i = 0; i < t.length; i++) t[i] = ul_macs[t[i]]; //  condenseMacs   //  ""       4  var mac = condenseMacs(t,ul_key); ul_settimeout(-1); //             //           var filekey = [ul_key[0]^ul_key[4],ul_key[1]^ul_key[5],ul_key[2]^mac[0]^mac[1],ul_key[3]^mac[2]^mac[3],ul_key[4],ul_key[5],mac[0]^mac[1],mac[2]^mac[3]]; // ... } //   :           function api_completeupload2(ctx, ut) { var p; if (ctx.path && ctx.path != ctx.n && (p = ctx.path.indexOf('/')) > 0) { var pc = ctx.path.substr(0, p); ctx.path = ctx.path.substr(p + 1); fm_requestfolderid(ut, pc, ctx); } else { //     ,   ul_key    // ctx.k == filekey a = { n: ctx.n }; if (d) console.log(ctx.k); var ea = enc_attr(a, ctx.k); if (d) console.log(ea); //      -   var req = { a: 'p', t: ut, n: [{ h: ctx.t, t: 0, a: ab_to_base64(ea[0]), //  k: a32_to_base64(encrypt_key(u_k_aes, ctx.k)), // == AES_encrypt(u_k, filekey) fa: ctx.fa }] }; if (ut) { // a target has been supplied: encrypt to all relevant shares var sn = fm_getsharenodes(ut); if (sn.length) { req.cr = crypto_makecr([ctx.k], sn, false); req.cr[1][0] = ctx.t; } } api_req([req], ctx.ctx); } } 

फ़ाइलों को डाउनलोड और डिक्रिप्ट करें

जाहिर है, इन प्रक्रियाओं को बस एन्क्रिप्शन फाइल करने के लिए उलटा होना चाहिए। केवल एक चीज जो ब्याज की हो सकती है वह सर्वर से आए एन्क्रिप्टेड ul_key से ul_key कुंजी ul_key प्राप्त कर रही है।

फ़ाइल डाउनलोड करने के समय, ब्राउज़र संदर्भ में पहले से ही एक ऑब्जेक्ट होता है जो डिक्रिप्ट की गई फ़ाइल कुंजियों को संग्रहीत करता है। इसलिए, पहली बार यह उपयोगकर्ता प्रमाणीकरण के तुरंत बाद होने वाली प्रक्रिया पर विचार करने के लिए समझ में आता है, अर्थात्, फ़ाइल प्रबंधक को डाउनलोड करना। उपयोगकर्ता को सेवा में जाने की अनुमति देने के बाद, वह स्वाभाविक रूप से अपनी फ़ाइलों का उपयोग करना चाहता है (मान लीजिए कि उसके पास पहले से ही वहां था)। ऐसा करने के लिए, हमें पहले फ़ाइल कुंजियों को डिक्रिप्ट करना होगा, और फिर उनकी विशेषताओं को। फ़ंक्शंस का अगला बंडल इससे संबंधित है, जिनमें से loadfm_callback और process_f_f हमारे लिए रुचि के हैं।

संक्षेप में, फ़ाइल विशेषताओं को प्राप्त करने की प्रक्रिया को निम्न एल्गोरिथम द्वारा वर्णित किया जा सकता है:

1. फ़ाइल प्रबंधक को लोड करने के लिए प्रतीक्षा करें ( loadfm_callback ), जहां JSON को सभी डाउनलोड की गई फ़ाइलों के विवरण के साथ प्राप्त करना है
2. एक सरणी सरणी बनाएँ जिसमें फ़ाइल जानकारी के साथ एक सरणी रखें
3. चलाएँ (पुनरावर्ती) प्रत्येक फ़ाइल के लिए process_f_f फ़ंक्शन
4. कुंजी वाली प्रत्येक फ़ाइल के लिए, इस कुंजी और विशेषताओं को डिक्रिप्ट करें ( crypto_processkey फ़ंक्शन) और उन्हें फ़ाइल फ़ाइल सरणी में वापस सहेजें
5. उसके बाद, process_f_f चर के लिए डिक्रिप्ट किए गए मानों को सहेजें (प्रक्रिया में पुनरावृत्ति का process_f_f )

नीचे मैं इस एल्गोरिथ्म को दर्शाने वाले कोड अंश प्रदान करूंगा

 // callback  - function loadfm_callback(json, res) { // ... //  JSON     json = json[0]; if (d) console.log(json); if (d) console.log(json); if (json.u) process_u(json.u, false); if (json.ok) process_ok(json.ok); if (json.s) { for (i in json.s) { if (u_sharekeys[json.s[i].h]) { sharingData.push({ id: json.s[i].h + '_' + json.s[i].u, userid: json.s[i].u, folderid: json.s[i].h, rights: json.s[i].r, date: json.s[i].ts }); sharednodes[json.s[i].h] = true; } } } // ...   ... //          farray[fi] = new Object; farray[fi].f = json.f; //   , callback    //        process_f(fi, false, callback); fi++; } //  ,         //   process_f function process_f_f(fid) { //    -       farray if (!farray[fid].f[farray[fid].i]) { if (farray[fid].ap) FileStore.suspendEvents(); //    FileStore FileStore.loadData(farray[fid].mdata, true); if (farray[fid].ap) FileStore.resumeEvents(); if (d) console.log('call reqmissingkeys:'); crypto_reqmissingkeys(); if (farray[fid].callback) farray[fid].callback.fn(farray[fid].callback); return false; } var f = farray[fid].f[farray[fid].i]; f.attrs = fa; if (f.sk) u_sharekeys[fh] = crypto_process_sharekey(fh, f.sk); //        ,    if ((ft !== 2) && (ft !== 3) && (ft !== 4) && (fk)) { crypto_processkey(u_handle, u_k_aes, f); //     u_nodekeys[fh] = f.key; if ((typeof f.name !== 'undefined') && (fp == InboxID)) InboxCount++; } else { if (fa) { if (!missingkeys[fh]) { missingkeys[fh] = true; newmissingkeys = true; } } fk = ''; f.name = ''; } if (ft == 2) RootID = fh; else if (ft == 3) InboxID = fh; else if (ft == 4) TrashbinID = fh; else if ((ft < 2) || (ft == 5)) { //      } else { //      FileStore farray[fid].mdata.push({ id: fhreplace(/[^az^AZ^0-9^_^-]/g, ""), name: f.name, size: fs, type: filetype(f.name, ft), icon: fileicon(f.name, icontype), parentid: fp, folder: ft, owner: fu, date: f.ts, attrs: f.attrs, key: f.key, r: fr, su: f.su, fa: f.fa, }); if (fp == TrashbinID) trashbinfull = true; if (((ft) && (farray[fid].ap)) || (fp == InboxID)) refreshtree = true; } farray[fid].i++; //   (,   -    ) timeoutcount++; if (!(timeoutcount & 63)) { //     63  -     setTimeout("process_f_f(" + fid + ")", 1); timeoutcount2++; } //  -     else process_f_f(fid); } //       function crypto_processkey(me, master_aes, file) { var id, key, k, n; if (!file.k) { if (!keycache[file.h]) return; file.k = keycache[file.h]; } id = me; // do I own the file? (user key is guaranteed to be first in .k) //     "<file handle>:<key>/<share key>" var p = file.k.indexOf(id + ':'); //  ,      if (p) { // I don't - do I have a suitable sharekey? for (id in u_sharekeys) { p = file.k.indexOf(id + ':'); if (p >= 0 && (!p || file.k.charAt(p - 1) == '/')) break; p = -1; } } //        if (p >= 0) { delete keycache[file.h]; //  -    var pp = file.k.indexOf('/', p); if (pp < 0) pp = file.k.length; p += id.length + 1; key = file.k.substr(p, pp - p); // we have found a suitable key: decrypt! if (key.length < 46) { // short keys: AES k = base64_to_a32(key); // check for permitted key lengths (4 == folder, 8 == file) if (k.length == 4 || k.length == 8) { //     -,      k = decrypt_key(id == me ? master_aes : new sjcl.cipher.aes(u_sharekeys[id]), k); } else { if (d) console.log("Received invalid key length (" + k.length + "): " + file.h); return; } } else { // long keys: RSA if (u_privk) { var t = mpi2b(base64urldecode(key)); if (t) k = str_to_a32(crypto_rsadecrypt(t, u_privk).substr(0, file.t ? 16 : 32)); else { if (d) console.log("Corrupt key for node " + file.h); return; } } else { if (d) console.log("Received RSA key, but have no public key published: " + file.h); return; } } //    var ab = base64_to_ab(file.a); //          var o = dec_attr(ab, k); if (typeof o == 'object') { if (typeof on == 'string') { if (file.h) { u_nodekeys[file.h] = k; if (key.length >= 46) rsa2aes[file.h] = a32_to_str(encrypt_key(u_k_aes, k)); } //        -      file.key = k; file.name = on; } } } else { if (d) console.log("Received no suitable key: " + file.h); if (!missingkeys[file.h]) { newmissingkeys = true; missingkeys[file.h] = true; } keycache[file.h] = file.k; } } 

उसके बाद, हम ब्राउज़र संदर्भ से ul_key स्रोत कुंजी का मूल्य निम्नानुसार प्राप्त कर सकते हैं:

 dl_keyNonce = JSON.stringify([dl_key[0]^dl_key[4],dl_key[1]^dl_key[5],dl_key[2]^dl_key[6],dl_key[3]^dl_key[7],dl_key[4],dl_key[5]]); 

यह रूपांतरण startdownload फ़ंक्शन में होता है। यदि हम समझते हैं कि dl_key == filekey ul_chunkcomplete फ़ंक्शन से है और कुछ सरल मॉडुलो संचालन करते हैं, तो हम ध्यान देते हैं कि dl_keyNonce चर, फ़ाइल अपलोड होने पर उत्पन्न ul_key मान को संग्रहीत करेगा। फ़ाइलों को डाउनलोड करने पर अनुभाग की शुरुआत में फोटो में ब्लैकबोर्ड के निचले बाएं कोने में यह चित्रण देखा जा सकता है।

क्रिप्टोग्राफ़िक संचालन का "अधिभार"

इस तथ्य के बावजूद कि फ़ाइलों और कुंजियों की सुरक्षा के उपरोक्त सिद्धांत बहुत सुरक्षित हैं, किसी को यह पसंद नहीं हो सकता है कि हम अभी भी सेवा प्रदान करने वाले एल्गोरिदम के कार्यान्वयन पर निर्भर हैं। इस मामले में, हम ब्राउज़र के लिए अपना स्वयं का एक्सटेंशन विकसित कर सकते हैं, जो सेवा के कुछ कार्यों को ओवरराइड करेगा, उनमें अतिरिक्त एन्क्रिप्शन लागू करेगा। अर्थात्, मैंने GOST 28147-89 एल्गोरिथ्म के अनुसार गैर-पुनर्प्राप्ति योग्य कुंजी पर हार्डवेयर एन्क्रिप्शन का उपयोग करके महत्वपूर्ण जानकारी (मास्टर कुंजी और फ़ाइल कुंजी) के संरक्षण को लागू करने का निर्णय लिया। इस पर एक बोनस भी सेवा पर दो-कारक प्रमाणीकरण का समावेश होगा।
तो, इस उपयोग-मामले पर विचार करें:

• उपयोगकर्ता सेवा पर पंजीकृत है
• फिर यह एक्सटेंशन इंस्टॉल करता है
• इसकी मदद से, मास्टर कुंजी का हार्डवेयर एन्क्रिप्शन एक कुंजी पर किया जाता है जिसे टोकन से नहीं निकाला जा सकता है
• इस तरह से एन्क्रिप्ट की गई मास्टर कुंजी सर्वर पर अपलोड की जाती है

उसके बाद, टोकन और उसके पिन कोड के बिना मास्टर कुंजी का मूल्य प्राप्त करना असंभव होगा। यह देगा:

1. सेवा पर दो-कारक प्रमाणीकरण (सही ढंग से डिक्रिप्ट किए हुए मास्टर कुंजी के बिना, api_getsid2 फ़ंक्शन "विफल" होगा)
2. टोकन के बिना, चालू खाता पासवर्ड बदलना भी असंभव होगा

अगला कदम फ़ाइल एन्क्रिप्शन कुंजी (उर्फ ul_key ) और फ़ाइल विशेषता कुंजी ( ul_key ) को टोकन के साथ एन्क्रिप्ट करना है, जो कि सर्वर पर संग्रहीत है। इस प्रकार, हम प्राप्त करते हैं कि प्रत्येक फ़ाइल को एक कुंजी पर एन्क्रिप्ट किया जाएगा जो कभी भी सर्वर को नहीं मिलती है, जहां api_completeupload2 फ़ंक्शन से हमारे द्वारा एन्क्रिप्ट किया गया api_completeupload2 जाएगा। फ़ाइल विशेषताएँ खुले फ़ाइल मान के साथ एन्क्रिप्ट की जाएंगी। स्पष्टता के लिए, मैंने एक फ़ाइल डाउनलोड करने की प्रक्रिया को दर्शाते हुए निम्नलिखित चित्र को स्केच किया:



मैं यह नोट करना चाहता हूं कि यहां मैंने एक बहुत ही मुश्किल तरीका लागू किया। इस मामले में, हमारे लिए यह महत्वपूर्ण है कि हमलावर फ़ाइल को डिक्रिप्ट नहीं कर सकता है, भले ही वह सर्वर से आई फ़ाइल कुंजी को स्वीकार करता हो और उपयोगकर्ता की मास्टर कुंजी जानता हो। इसलिए, यहां आप सेवा वास्तुकला की सुविधाओं पर खेल सकते हैं और फ़ाइलों के एन्क्रिप्शन के लिए ul_key (या dl_key) कुंजी टोकन को एन्क्रिप्ट करके प्राप्त ul_keyNonce कुंजी मान (समान dl_keyNonce) का उपयोग कर सकते हैं।

प्रयुक्त प्रौद्योगिकियाँ

हार्डवेयर एन्क्रिप्शन को लागू करने के लिए, यूएसबी टोकन रॉटोकन ईडीएस (रुतोकन वेब भी उपयुक्त है) ब्राउज़र प्लग-इन "रूतोकन वेब पीकेआई संस्करण" के साथ एक साथ उपयोग किया जाएगा। हमने पहले ही लेख में प्लगइन का विस्तृत विवरण दिया है Rutoken WEB PKI संस्करण और RBS सिस्टम में शील्ड और तलवार। लागू समाधान ।

इन लेखों के लिखने के बाद से, GOST 28147-89 एल्गोरिथ्म के अनुसार हार्डवेयर एन्क्रिप्शन की संभावना हमारे उत्पाद में जुड़ गई है। GOST 28147-89 एल्गोरिथ्म के अनुसार हार्डवेयर एन्क्रिप्शन कार्यक्षमता के साथ प्लगइन का बीटा संस्करण यहां डाउनलोड किया जा सकता है । प्लगइन के इस संस्करण को अभी तक पूरी तरह से परीक्षण नहीं किया गया है, इसलिए मैं आपको चेतावनी देता हूं कि उस स्थान पर त्रुटियां हो सकती हैं जिसके बारे में मैं आपको पीएम को सूचित करने के लिए कहता हूं।
प्लगइन इंटरफ़ेस में, सममित एन्क्रिप्शन को एन्क्रिप्ट फ़ंक्शन द्वारा कार्यान्वित किया जाता है, जिसमें निम्न सिंटैक्स होता है:

 encrypt(deviceId, keyLabel, data, resultCallback, errorCallback) → {string} 

इनपुट के रूप में, फ़ंक्शन लेता है:

• डिवाइस आईडी number
• एन्क्रिप्शन, number लिए कुंजी लेबल (यदि ऐसी कोई कुंजी नहीं है, तो यह उत्पन्न हो जाएगा)
• एनक्रिप्टेड डेटा, string (एक स्ट्रिंग जिसमें "ए "aa:bb:cc:dd" बाइट सरणी होता है)
• एक एन्क्रिप्शन ऑपरेशन को सफलतापूर्वक और असफल रूप से पूरा करने के लिए कॉलबैक फ़ंक्शन

डिक्रिप्शन फ़ंक्शन का उपयोग करके decrypt समान रूप से किया जाता है
कुंजी लेबल पर विशेष ध्यान दिया जाना चाहिए, क्योंकि यह निर्धारित करता है कि किस कुंजी के लिए डेटा (डिक्रिप्ट) के लिए एन्क्रिप्ट किया जाएगा। लेबल एक मनमाना स्ट्रिंग है और मुख्य रूप से सुविधाजनक कुंजी पहचान के लिए उपयोग किया जाता है।इस मामले में, मैं दो मुख्य जोड़े का उपयोग करता हूं: एक मास्टर कुंजी को एन्क्रिप्ट करने के लिए, और दूसरा व्यक्तिगत फ़ाइल कुंजियों को एन्क्रिप्ट करने के लिए। जिस कुंजी पर मास्टर कुंजी एन्क्रिप्ट की गई है, उसमें उपयोगकर्ता के पासवर्ड के बराबर एक लेबल है (अब मेरे पास स्ट्रिंग से हैश का उपयोग करने का विचार था e-mail||, निकट भविष्य में मैं इसे ठीक कर दूंगा)। डाउनलोड की गई फ़ाइलों की कुंजी को एन्क्रिप्ट करने के लिए, मास्टर कुंजी के स्ट्रिंग प्रतिनिधित्व के बराबर एक लेबल के साथ एक कुंजी का उपयोग करें (यहां यह मास्टर कुंजी से एक हैश का उपयोग करने के लायक भी है)।

प्रत्यक्ष विकास

बस मेरे स्रोत कोड के बारे में एक टिप्पणी करना चाहते हैं: यह, वास्तव में, अल्फा संस्करण में है, हालांकि यह ऊपर वर्णित कार्यक्षमता को लागू करता है। मैंने यह नहीं जांचा कि सेवा के अन्य कार्यों के साथ मेरी पुनरावृत्ति कितनी संगत है, इसलिए मैंने जीथूब पर सभी स्रोतों को पोस्ट किया और मुझे इस प्रणाली को अंतिम रूप देने में किसी भी मदद की खुशी होगी। इसलिए, मैं बड़ी लिस्टिंग के साथ लेख को आगे नहीं रोकूंगा, लेकिन केवल विस्तार की सामान्य योजना का वर्णन करूंगा।

समाप्त एक्सटेंशन यहां डाउनलोड किया जा सकता है । यह क्रॉसराइड सेवा का उपयोग करके विकसित किया गया था , जो तीन ब्राउज़रों (क्रोम, फ़ायरफ़ॉक्स और IE) के लिए एक्सटेंशन प्रदान करता है, लेकिन क्रोम या फ़ायरफ़ॉक्स में इसके संचालन की जांच करना बेहतर है, और पहले में यह बहुत अधिक स्थिर काम करता है।

भोज के लिए विस्तार कोड सरल है: यह जाँचता है कि क्या हम सेवा पृष्ठ पर हैं और यदि हां, तो यह अतिरिक्त स्क्रिप्ट को लोड करता है। ये स्क्रिप्ट कुछ संवाद जोड़कर पृष्ठ कोड को संशोधित करती हैं और निम्नलिखित सेवा कार्यों को ओवरराइड करती हैं:

• changepw : पासवर्ड बदलने के लिए जिम्मेदार
• api_getsid2 : लॉगिन कॉलबैक में से एक
• api_completeupload2 : कॉलबैक फ़ाइल अपलोड पूर्ण
• loadfm_callback : कॉलबैक फ़ाइल प्रबंधक डाउनलोड
• processpacket : एक और कॉलबैक, जिसमें बस डाउनलोड की गई फ़ाइल की विशेषताओं को डिकोड किया गया है
• parsepage : अतिरिक्त संवाद खींचने के लिए जिम्मेदार
• dologin : प्रमाणीकरण क्षमताओं का विस्तार करता है
• initupload3 : फ़ाइल एन्क्रिप्शन कुंजी बनाने के लिए जिम्मेदार है
• startdownload : एक फ़ाइल कुंजी रिवर्स पार्सिंग और एक डाउनलोड को इनिशियलाइज़ करना

एक बार फिर, मैं आपको चेतावनी देना चाहता हूं कि आपको किसी कार्यशील खाते में विस्तार नहीं करना चाहिए (यदि कोई भी इस सेवा का उपयोग कर रहा है), लेकिन एक परीक्षण प्राप्त करना बेहतर है। इसे स्थापित करने के बाद एक्सटेंशन का उपयोग करने के लिए, आपको इसकी आवश्यकता होगी:

1. आरंभ करने के लिए, रुतोकन ईडीएस (या रुटोकन वेब) प्राप्त करना और ब्राउज़र प्लगइन स्थापित करना अच्छा है
2. एक्सटेंशन स्थापित करें
3. एक्सटेंशन अक्षम के साथ सेवा में प्रवेश करें
4. ब्राउज़र एक्सटेंशन सक्षम करें
5. अकाउंट पेज पर जाएं
6. "लिंक टोकन" बटन पर क्लिक करें
7. वर्तमान पासवर्ड दर्ज करें और यह ऑपरेशन करें

एक्सटेंशन के बजाय, आप निम्नलिखित बुकमार्कलेट (क्रोम, सफारी, फ़ायरफ़ॉक्स में परीक्षण) का उपयोग कर सकते हैं:

 javascript:(function(){if(document.getElementById('cryptorutokenjs')){alert('  ');return}function loadRemoteScript(url){var script=document.createElement('script');script.type="text/javascript";script.src=url;document.head.appendChild(script)}function loadRemoteStyle(url){var style=document.createElement('link');style.rel='stylesheet';style.type="text/css";style.href=url;document.head.appendChild(style)}loadRemoteStyle("https://mega-crypto.googlecode.com/git/mega.css");loadRemoteScript("https://mega-crypto.googlecode.com/git/util.js");loadRemoteScript("https://mega-crypto.googlecode.com/git/rutoken-extra.js");loadRemoteScript("https://mega-crypto.googlecode.com/git/rutoken-crypto.js");loadRemoteScript("https://mega-crypto.googlecode.com/git/mega.js")})(); 

कार्य प्रदर्शन

सबसे पहले, हमारे निर्माण को साइट से कनेक्ट करें। ऐसा करने के लिए:

1. सेवा में प्रवेश करें और फ़ाइल प्रबंधक पृष्ठ खोलें

   
   
   

2. हम एक्सटेंशन या बुकमार्कलेट कनेक्ट करते हैं, जिसके बाद हमें टोकन पिन दर्ज करना होगा

   
   
   

3. हम खाते के पृष्ठ पर जाते हैं और खाते में टोकन बांधते हैं

   
   
   

तब आप सेवा से बाहर निकल सकते हैं और दो-कारक प्रमाणीकरण का उपयोग करके फिर से लॉग इन करने का प्रयास कर सकते हैं:

1. उपयोगकर्ता नाम पासवर्ड दर्ज करें

2. पिन दर्ज करें

   
   
   

3. ...

4. लाभ!

इस मामले में प्रमाणीकरण निम्न योजना के अनुसार होता है:

1. सर्वर पर लॉगिन-पासवर्ड जोड़ी की जाँच करना
2. यदि उपयोगकर्ता नाम और पासवर्ड सही हैं, तो सर्वर से एक एन्क्रिप्टेड मास्टर कुंजी आती है
3. प्लगइन का उपयोग करते हुए, टोकन के लिए एक पिन का अनुरोध किया जाता है
4. यदि पिन सही तरीके से दर्ज किया गया है, तो मास्टर कुंजी को टोकन से कुंजी पर डिक्रिप्ट किया जाता है

एक निष्कर्ष के बजाय

यहां मैं "जारी रखने के लिए ..." लिखना चाहूंगा, क्योंकि मैंने विस्तार बनाने और अतुल्यकालिक एन्क्रिप्शन फ़ंक्शंस को खराब करने की दिलचस्पता को एक ऐसी सेवा में शामिल नहीं किया था जिसमें ज्यादातर मामलों में सिंक्रोनस कॉल का उपयोग होता है। इस लेख को समाप्त करने के लिए, मैं एक बार फिर से क्लाइंट-साइड क्रिप्टोग्राफी को लागू करने के विचार की ओर मुड़ना चाहूंगा।
ग्राहक पक्ष पर अतिरिक्त क्रिप्टोग्राफ़िक कार्यों के कार्यान्वयन के दृष्टिकोण को किसी भी वेब सेवा पर लागू किया जा सकता है जो परवाह नहीं करता है कि उसके सर्वर पर क्या संग्रहीत किया जाए: क्या यह फ़ाइल भंडारण, मेल या सरल चैट है। उदाहरण के लिए, VKO GOST R 34.10-2001 एल्गोरिथ्म का उपयोग करके CMS प्रारूप और कुंजी विनिमय तंत्र में संदेश एन्क्रिप्शन का उपयोग करके किसी भी मेल सेवा के आधार पर सुरक्षित मेल को लागू करना संभव है।
आपके ध्यान के लिए धन्यवाद, आपके प्रश्नों और टिप्पणियों की प्रतीक्षा है।

पुनश्च: हम पहले पांच लोगों को (मास्को से) टोकन द्वारा प्लगइन का परीक्षण करने के लिए दे सकते हैं - एक व्यक्तिगत में लिखें।