सरल Sqlite DB एन्क्रिप्शन

ऐसा हुआ कि मैं वास्तव में SQLite DBMS का उपयोग करना पसंद करता हूं।

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

SQLite एक पूरी तरह से अलग मामला है। सबसे पहले, यह छोटा है - केवल कुछ सौ किलोबाइट, कॉम्पैक्ट असेंबलर कार्यक्रमों के लिए एक बढ़िया अतिरिक्त। दूसरे, यह एक अल्ट्रा-विश्वसनीय डेटा स्टोरेज सिस्टम है। उसे किसी विशेष सेटिंग और सेटिंग्स की आवश्यकता नहीं है। खैर, प्रदर्शन के लिए - अंतिम नहीं।

उदाहरण के लिए, मैंने अपने AsmBB फोरम इंजन में SQLite का उपयोग किया, जिसके बारे में मैंने पहले ही Habré पर लिखा था। (वैसे, उसके बाद वह नहीं गिरा )।

उस समय से, परियोजना धीरे-धीरे लेकिन निश्चित रूप से विकसित हो रही है। नई सुविधाएँ दिखाई दी हैं, सुरक्षा और प्रदर्शन में वृद्धि हुई है।

और फिर एक दिन मैंने सोचा कि परियोजना की पहले से ही अच्छी सुरक्षा कैसे बढ़ाई जाए। और मैंने तुरंत सोचा कि फोरम डेटाबेस को एन्क्रिप्ट करना अच्छा होगा। वास्तव में, भले ही डेटाबेस लीक हो, किसी को भी उपयोगकर्ताओं के व्यक्तिगत डेटा तक पहुंच नहीं मिलेगी।

इंटरनेट पर एक त्वरित खोज से पता चला कि डेटाबेस एन्क्रिप्शन के लिए कई SQLite एक्सटेंशन हैं। दुर्भाग्य से, आधिकारिक एसईई एक्सटेंशन मुफ्त नहीं है और आम तौर पर पैसे के लिए बेचा जाता है।

लेकिन, ज़ाहिर है, एक पवित्र स्थान कभी खाली नहीं होता है और मैं तुरंत SQLeet एक्सटेंशन पर ठोकर खाई। और इसमें मुझे सचमुच सब कुछ पसंद आया।

SQLeet डेटाबेस को एन्क्रिप्ट करने के लिए ChaCha20 एल्गोरिथ्म का उपयोग करता है। एन्क्रिप्शन कुंजी 16-बाइट नमक और 12345 हैश पुनरावृत्तियों का उपयोग करके PBKDF2-HMAC-SHA256 के माध्यम से गणना की जाती है। प्रमाणीकरण के लिए, Poly1305 का उपयोग किया जाता है।

SQLeet और SQLite दोनों सार्वजनिक डोमेन (सार्वजनिक डोमेन) के तहत वितरित किए जाते हैं। यह सुविधाजनक है क्योंकि यह परियोजना में लाइसेंसिंग अराजकता में वृद्धि नहीं करता है।

फिर भी SQLeet बहुत कॉम्पैक्ट है। सभी कोड केवल सी में लगभग डेढ़ हजार लाइनें लेते हैं और उनकी कोई बाहरी निर्भरता नहीं है।

परियोजना सक्रिय रूप से समर्थित है और लेखक तुरंत सवालों के जवाब देता है और बग को ठीक करता है, यदि कोई हो।

SQLeet को उसी तरह से वितरित किया जाता है जैसे कि SQLite - एक एकल C स्रोत फ़ाइल के रूप में जिसे आप बस उसी तरह संकलित कर सकते हैं जिस तरह से SQLite संकलित करता है।

इसके अलावा, चूंकि एक्सटेंशन किसी भी तरह से SQLite कोड को नहीं बदलता है, इसलिए मुख्य DBMS को अपडेट करना बहुत ही सरलता से किया जा सकता है - sqlite3.c फ़ाइल की जगह और संयुक्त स्रोत को फिर से बनाने के द्वारा।

चूंकि मैं AsmBB में काफी मानक संकलन का उपयोग नहीं करता हूं (AsmBB में SQLite को MUSL libc के माध्यम से संकलित किया गया है), और मैं C प्रोग्रामर नहीं हूं, मेरे लिए संकलन की सादगी बहुत महत्वपूर्ण है।

उदाहरण के लिए, यहाँ bash कोड है जो मैं SQLeet का नवीनतम संस्करण डाउनलोड करने और स्रोत बनाने और बनाने के लिए उपयोग करता हूं:

 wget -q -O - https://github.com/resilar/sqleet/archive/master.tar.gz | tar -xz cd ./sqleet-master script/amalgamate.sh < ./sqleet.c > ../sqlite3.c cd .. rm -rf ./sqleet-master/ 

परिणाम एक sqlite3.c फ़ाइल है जिसे सम्मिलित किया जा सकता है जहां मूल SQLite फ़ाइल को पहले डाला गया था और उसी तरह उपयोग किया गया था।

एक्सटेंशन का उपयोग करना भी SQLite का उपयोग करने से अलग नहीं है। अंतर केवल इतना है कि यदि डेटाबेस एन्क्रिप्ट किया गया है, तो खोलने के तुरंत बाद sqlite3_key () फ़ंक्शन को कॉल करना आवश्यक है, जिसमें आप एन्क्रिप्शन पासवर्ड निर्दिष्ट करते हैं। ठीक है, या इससे भी बेहतर, बस SQL pragma key='%%' निष्पादित करें। (यह बेहतर है क्योंकि SQLite API नहीं बदलता है और
आप हमेशा SQLeet को SQLite और इसके विपरीत) से बदल सकते हैं।

प्रारंभिक डेटाबेस एन्क्रिप्शन, साथ ही साथ पासवर्ड रिप्लेसमेंट, sqlite3_rekey() फ़ंक्शन या pragma rekey='%NEW_PASSWORD%' ।

और यहाँ मेरा ऐसा सवाल था। पासवर्ड कहाँ से आता है? आखिरकार, यदि पासवर्ड किसी फ़ाइल में सर्वर पर संग्रहीत किया जाता है, तो संभावित हैकर इसे पढ़ सकेगा।

इसलिए मैंने इसे अलग तरीके से करने का फैसला किया। तथ्य यह है कि AsmBB एक लंबे समय तक चलने वाला FastCGI एप्लिकेशन है। एक बार एक सर्वर पर लॉन्च होने के बाद, यह रिबूट की आवश्यकता के बिना महीनों और वर्षों तक चलता है।

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

दिए गए पासवर्ड से, SQLeet PBKDF2-HMAC-SHA256 के माध्यम से एक एन्क्रिप्शन कुंजी उत्पन्न करता है, और यह कुंजी भी केवल रैम में संग्रहीत होती है।

बेशक, इस तरह का निर्णय अपूर्ण है। अगर हमलावर के पास प्रशासक का अधिकार है, तो AsmBB के निष्पादन के दौरान, रैम की मेमोरी में एन्क्रिप्शन कुंजी पाई जा सकती है।

लेकिन फिर भी, सिस्टम एन्क्रिप्शन के बिना अभी भी बहुत सुरक्षित है। उदाहरण के लिए, अब डेटाबेस बैकअप को हर जगह संग्रहीत किया जा सकता है और डेटा रिसाव के डर के बिना खुले चैनलों पर भेजा जा सकता है।

वैसे, एक रेक है जिसे आप SQLeet (या अन्य SQLite क्रिप्टोग्राफ़िक एक्सटेंशन) का उपयोग करके आगे बढ़ा सकते हैं। और मैं, निश्चित रूप से, उन पर कदम रखा।

समस्या डेटाबेस पृष्ठ के आकार की है। 3.12.0 (मार्च 2016) की तुलना में पहले SQLite के संस्करणों में, डिफ़ॉल्ट पृष्ठ का आकार 1024 बाइट्स था। V3.12.0 में, 4096 बाइट्स ने इसे बनाया। यह आकार, डेटाबेस उपयोगकर्ता प्रदर्शन कारणों से बदल सकता है, और पृष्ठ आकार डेटाबेस में ही लिखा गया है।

लेकिन अगर डेटाबेस एन्क्रिप्ट किया गया है, तो पृष्ठ का आकार पढ़ा नहीं जा सकता है, और डिक्रिप्शन के लिए इस आकार की आवश्यकता है, क्योंकि प्रत्येक ब्लॉक अलग से एन्क्रिप्ट किया गया है।

इसलिए, यदि आप एक गैर-मानक पृष्ठ आकार (SQLeet के लिए, मानक 4096 बाइट्स के साथ) को एन्क्रिप्ट करते हैं, तो आप सही पासवर्ड सेट करने पर भी इसे डिक्रिप्ट नहीं कर पाएंगे।

यह केवल तय किया गया है - sqlite3_key() या pragma key='%%' माध्यम से पासवर्ड सेट करने से पहले, आपको pragma page_size=%% माध्यम से सही पृष्ठ आकार सेट करने की आवश्यकता है।

एक अन्य संभावित समस्या यह है कि एन्क्रिप्शन के बाद, OS अब यह नहीं पहचान पाएगा कि फ़ाइल एक SQLite डेटाबेस है। यह (जहां तक ​​मैं पढ़ता हूं) कभी-कभी कुछ समस्याओं की ओर जाता है, विशेष रूप से आईओएस में। इस समस्या का एक समाधान है, बस फ़ाइल के पहले 32 बाइट्स को एन्क्रिप्ट न करें, लेकिन मैं विवरण में नहीं गया।

और अंत में, प्रदर्शन के बारे में। SQLeet बहुत तेज है। एन्क्रिप्शन के बाद, मैंने वीपीएस प्रदर्शन में सामान्य उतार-चढ़ाव की पृष्ठभूमि के खिलाफ प्रणाली में कोई मंदी नहीं देखी। सटीक माप किसी प्रकार की मंदी दिखा सकते हैं, लेकिन यह संभवतः एक अनएन्क्रिप्टेड डेटाबेस की गति के 10% से कम होगा।

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

लेकिन, दूसरी ओर, SQLcipher अधिक पुराना है और इसलिए (संभवतः) अधिक स्थिर है। कोई काम आ सकता है।