एक रिस्टोर किए गए बैकअप में user-1842 के लिए एक एन्क्रिप्टेड JSON रिकॉर्ड होता है, फिर भी एप्लिकेशन इसे स्वीकार कर लेता है, भले ही अटैकर ने स्टोर किए गए बाइट्स को बदल दिया हो और रिकवर किया गया role बदलकर admin हो गया हो। अटैकर को एन्क्रिप्शन की (key) या API तक एक्सेस की ज़रूरत नहीं थी। उन्हें बस डेटाबेस बैकअप या उसके मेटाडेटा तक ‘राइट एक्सेस’ (लिखने की अनुमति) की ज़रूरत थी। हमारा रनिंग आर्टिफैक्ट एक पायथन मॉड्यूल है जो इस रिकॉर्ड को सुरक्षित रखता है—जिसमें id, email, role, और created_at शामिल हैं—जबकि यह क्लाइंट, API, डेटाबेस और बैकअप के बीच घूमता है। सिमेट्रिक एन्क्रिप्शन प्लेनटेक्स्ट को साइफरटेक्स्ट में बदलने और बाद में प्लेनटेक्स्ट को वापस पाने के लिए एक ही सीक्रेट की (secret key) का इस्तेमाल करता है। यह रिकॉर्ड को छिपाता है, लेकिन सिर्फ़ छिपाने से बदले हुए बाइट्स भरोसेमंद नहीं बन जाते।
इसलिए, डिफेंडर का सवाल इस बात से कहीं ज़्यादा खास है कि किस साइफर का नाम सबसे मज़बूत है। जब स्टोरेज से role=admin वापस आता है, तो API यह कैसे साबित कर सकता है कि बाइट्स और उनका रिकॉर्ड कॉन्टेक्स्ट बिल्कुल वही हैं जो मूल रूप से सुरक्षित किए गए थे? user-1842 के लिए सीमाएँ (boundaries) दिखाती हैं कि प्लेनटेक्स्ट कहाँ रुकना चाहिए, की (key) कहाँ अलग रहनी चाहिए, और अटैकर कहाँ साइफरटेक्स्ट के कंटेंट को जाने बिना उसमें बदलाव कर सकता है। आइए उन सीमाओं के पार रिकॉर्ड को ट्रेस करें:
यह डायग्राम दिखाता है कि डेटाबेस और बैकअप को सिफरटेक्स्ट, एक नॉनस (nonce) और चुने हुए मेटाडेटा की ज़रूरत होती है, लेकिन एन्क्रिप्शन की की (key) की कभी नहीं। नॉनस एक ऐसी वैल्यू है जिसका इस्तेमाल किसी खास की के साथ एक बार किया जाता है ताकि यह पक्का किया जा सके कि बार-बार होने वाले प्रोटेक्शन ऑपरेशन में एक ही क्रिप्टोग्राफिक इनपुट का दोबारा इस्तेमाल न हो। नॉनस को सिफरटेक्स्ट के साथ स्टोर किया जा सकता है; इसे गुप्त रखना इसका काम नहीं है। की को गुप्त रहना चाहिए और इसे रिकॉर्ड या बैकअप के बजाय सुरक्षित एप्लिकेशन कॉन्फ़िगरेशन से आना चाहिए।
क्योंकि अटैकर स्टोर किए गए बाइट्स को बदल सकता है, इसलिए रिकॉर्ड कॉन्ट्रैक्ट के लिए गोपनीयता और अखंडता (integrity) दोनों की ज़रूरत होती है। ऑथेंटिकेटेड एन्क्रिप्शन JSON बाइट्स को एन्क्रिप्ट करता है और यह वेरिफ़ाई करता है कि प्लेनटेक्स्ट वापस करने से पहले न तो वे बाइट्स और न ही चुना हुआ कॉन्टेक्स्ट बदला है। user-1842 के लिए, API user_id=user-1842 और schema_version=1 को एसोसिएटेड डेटा के तौर पर ऑथेंटिकेट करेगा, यानी ऐसा मेटाडेटा जिसे क्रिप्टोग्राफिक ऑपरेशन से वेरिफ़ाई तो किया जाता है लेकिन एन्क्रिप्ट नहीं किया जाता। इसके बाद कॉपी किए गए सिफरटेक्स्ट को चुपचाप किसी दूसरे यूज़र के रिकॉर्ड के तौर पर रीलेबल नहीं किया जा सकता, और वेरिफ़िकेशन फेल हुए बिना स्कीमा वैल्यू को बदला नहीं जा सकता।
प्लेनटेक्स्ट ईमेल और रोल को सीधे दिखाता है। AES-CTR और AES-CBC उन फ़ील्ड्स को छिपा सकते हैं, लेकिन उनमें से कोई भी अकेले बदलाव को रिजेक्ट नहीं करता। AES-GCM ज़रूरी ऑथेंटिकेटेड-एन्क्रिप्शन कॉन्ट्रैक्ट देता है जब इसे एक की के तहत हर एन्क्रिप्शन के लिए एक नए नॉनस के साथ इस्तेमाल किया जाता है। क्या सिर्फ़-एन्क्रिप्शन वाला मोड यह पता लगा सकता है कि API के role को पार्स करने से पहले बैकअप बाइट बदल गया था? नीचे दी गई तुलना उस ज़रूरत के हिसाब से स्टोरेज के विकल्पों को परखती है:
यह तुलना डिज़ाइन के फ़ैसले को पक्का करती है। AES-GCM बदले हुए सिफरटेक्स्ट, नॉनस (nonce), की (key) या संबंधित डेटा को ऑथेंटिकेशन फ़ेलियर के साथ रिजेक्ट कर देता है, जबकि सिर्फ़ कॉन्फ़िडेंशियलटी (गोपनीयता) वाले विकल्प एप्लिकेशन को वह सबूत नहीं देते। AES-GCM नॉनस के दोबारा इस्तेमाल (reuse) की समस्या को ठीक नहीं करता। एक ही की के साथ एक ही नॉनस को दोबारा इस्तेमाल करने से सुरक्षा कमज़ोर हो जाती है, इसलिए नॉनस जनरेशन प्रोटेक्शन पाथ के अंदर होना चाहिए, न कि कॉलर द्वारा दिया गया मेटाडेटा।
रिकॉर्ड नियम नॉनस, सिफरटेक्स्ट और संबंधित डेटा को रिकॉर्ड के साथ स्टोर करें। AES की को अलग से स्टोर करें और हर की के लिए हर नॉनस को यूनिक (अलग) रखें।
कॉन्ट्रैक्ट तय होने के बाद, मॉड्यूल user-1842 को सुरक्षित कर सकता है, बिना आंशिक रूप से वेरिफ़ाई किए गए रिकॉर्ड को उसके कॉलर के सामने लाए। JSON सीरियलाइज़र बाइट्स बनाता है क्योंकि AESGCM.encrypt बाइट्स पर काम करता है। मॉड्यूल उदाहरण के लिए 256-बिट AES की बनाता है, एक नया 12-बाइट नॉनस बनाता है, और {nonce, ciphertext, ad} जैसा पैकेज स्टोर करता है। डिप्लॉयमेंट में, की जनरेशन और कस्टडी एप्लिकेशन की मंज़ूरशुदा की-मैनेजमेंट बाउंड्री में चली जाती है, जबकि रिकॉर्ड पैकेज डेटाबेस और बैकअप में स्टोर करने के लिए सुरक्षित रहता है।
यहाँ सबसे छोटा पूरा प्रोटेक्शन और रिकवरी पाथ दिया गया है: