Android, उपयोगकर्ता के डेटा को सुरक्षित रखता है. इसमें क्रेडेंशियल-एन्क्रिप्ट (सुरक्षित) किया गया स्टोरेज और पुष्टि से जुड़ी Keystore कुंजियां शामिल हैं. ये कुंजियां, उपयोगकर्ता के कॉन्फ़िगर किए गए लॉकस्क्रीन नॉलेज फ़ैक्टर (एलएसकेएफ़) से जुड़ी होती हैं. जैसे, पिन, पैटर्न, और पासवर्ड. एलएसकेएफ़ आम तौर पर कम एंट्रॉपी वाली वैल्यू होती हैं. जैसे, चार या छह अंकों वाले पिन. इसलिए, ब्रूट-फ़ोर्स हमलों से सुरक्षा ज़रूरी है.
Android, ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) या सिक्योर एलिमेंट (एसई) रेट-लिमिटर का इस्तेमाल करता है. इससे एलएसकेएफ़ पर ब्रूट-फ़ोर्स अटैक करने वाले हमलावरों की गतिविधि को धीमा किया जा सकता है. साथ ही, अगर हमलावर कई बार ऐसा करने की कोशिश करते हैं, तो उन्हें ब्लॉक किया जा सकता है. सीडीडी 9.11 में, एलएसकेएफ़ रेट-लिमिटर के लिए सुरक्षा से जुड़ी ज़रूरी शर्तों और सुझावों के बारे में बताया गया है. Android 16 QPR2 और इसके बाद के वर्शन में, Android के पुराने वर्शन की तुलना में, दर सीमित करने की नीतियां ज़्यादा बेहतर तरीके से लागू की जाती हैं. ज़्यादा जानकारी के लिए, Android 16 QPR2 और इसके बाद के वर्शन में, डिफ़ॉल्ट रूप से दर सीमित करने की बेहतर नीति लेख पढ़ें.
एलएसकेएफ़ की मदद से, सुरक्षित किए गए उपयोगकर्ता के डेटा को अनलॉक करना
LockSettingsService
यह कुकी, LSKF को सेव करने और उनकी पुष्टि करने का काम करती है. एक समय में, किसी उपयोगकर्ता के पास सिर्फ़ एक चालू LSKF होता है. नया LSKF असाइन करने से, पिछला LSKF अमान्य हो जाता है. साथ ही, दर सीमित करने की नीति शुरू से लागू होती है.
टीईई या एसई में मौजूद प्राइमरी रेट-लिमिटर, Gatekeeper या Weaver में से कोई एक होता है. यह चालू एलएसकेएफ़ के लिए रेट-लिमिटिंग लागू करता है. LockSettingsService अगर कोई तरीका उपलब्ध है, तो Weaver को प्राथमिकता देता है.
सुरक्षित किए गए उपयोगकर्ता डेटा को सिर्फ़ तब अनलॉक किया जाता है, जब प्राइमरी रेट-लिमिटर को सही LSKF दिया जाता है. अगर एलएसकेएफ़ गलत है, तो रेट-लिमिटर, गड़बड़ी काउंटर को बढ़ाता है. साथ ही, गड़बड़ियों की संख्या बढ़ने पर टाइम आउट लागू करता है. टाइम आउट के दौरान, यह सभी अनुमानों को अस्वीकार कर देता है और टाइम आउट की बची हुई अवधि दिखाता है.
Android 16 QPR2 और इसके बाद के वर्शन में, डिफ़ॉल्ट रूप से बेहतर रेट-लिमिटिंग नीति
सीडीडी 9.11 के लिए, Android 6 और इसके बाद के वर्शन में LSKF के लिए दर सीमित करना ज़रूरी है. पहले, दर सीमित करने से जुड़ी नीति का पालन न करने पर, ज़्यादा सख्ती नहीं की जाती थी. उदाहरण के लिए, Android 16 की ज़रूरी शर्तों को पूरा करने वाले किसी डिवाइस पर, पहले मिनट में ज़्यादा से ज़्यादा 10 बार, 6 मिनट में 20 बार, 25 मिनट में 50 बार, 24 घंटे में 110 बार, और 5 साल में 1800 बार अनुमान लगाया जा सकता है.
यह नीति, रैंडम तरीके से चुने गए एलएसकेएफ़ के लिए काफ़ी सुरक्षित है. हालांकि, असल में उपयोगकर्ता एलएसकेएफ़ को रैंडम तरीके से नहीं चुनते. कुछ एलएसकेएफ़, दूसरों की तुलना में ज़्यादा बार होते हैं. हमलावर, एलएसकेएफ़ को उनकी फ़्रीक्वेंसी के घटते क्रम में आज़माकर, काफ़ी हद तक सफलता पा सकते हैं.
उदाहरण के लिए, इस पिन का आसानी से अनुमान लगाया जा सकता है स्टडी में यह पाया गया कि 100 बार अनुमान लगाने के बाद, असल दुनिया में इस्तेमाल किए जाने वाले पिन का सही अनुमान लगाने की दर 16.2% थी. वहीं, पैटर्न का सही अनुमान लगाने की दर 35.5% थी. हमलावर, उपयोगकर्ता की निजी जानकारी जैसे कि जन्मदिन का इस्तेमाल करके, ज़्यादा लोगों को निशाना बना सकते हैं.
इसलिए, Android 16 QPR2 और इसके बाद के वर्शन में, डिफ़ॉल्ट रूप से एलएसकेएफ़ के लिए दर सीमित करने की बेहतर नीति उपलब्ध है. इस नीति के तहत, पहले मिनट में छह, छह मिनट में सात, 25 मिनट में आठ, 24 घंटे में 12, और पांच साल में 19 बार अनुमान लगाया जा सकता है. 20 बार गलत अनुमान लगाने के बाद, अनुमान लगाने की सुविधा का इस्तेमाल नहीं किया जा सकता. टाइम आउट का पूरा शेड्यूल, यहां दी गई टेबल में दिखाया गया है. आने वाले समय में, Android के नए वर्शन में यह सुविधा बदल सकती है.
| गलत अनुमानों की संख्या | गलत अनुमान लगाने के बाद टाइम आउट होना |
|---|---|
| 0 | लागू नहीं |
| 1-4 | 0 सेकंड |
| 5 | 1 मिनट |
| 6 | 5 मिनट |
| 7 | 15 मिनट |
| 8 | 30 मिनट |
| 9 | 90 मिनट |
| 10 | 4 घंटे |
| 11 | 12 घंटे |
| 12 | 36 घंटे |
| 13 | 4 दिन |
| 14 | 13 दिन |
| 15 | 41 दिन |
| 16 | 123 दिन |
| 17 | 1 साल |
| 18 | तीन साल |
| 19 | 9 साल |
| 20+ | अब और अनुमान नहीं लगाए जा सकते |
रेट-लिमिटर अपडेट किए गए
Android 16 QPR2 और इसके बाद के वर्शन में, Gatekeeper और Weaver के अपडेट किए गए वर्शन शामिल हैं. ये वर्शन, टेबल में दी गई दर सीमित करने की नीति को लागू करते हैं.
सॉफ़्टवेयर रेट-लिमिटर
Android 16 QPR2 और इसके बाद के वर्शन में, एक वैकल्पिक सेकंडरी रेट-लिमिटर SoftwareRateLimiter. शामिल है
इसे सिस्टम सर्वर में लागू किया जाता है. इससे डिवाइसों को, टीईई या एसई को अपडेट न किए जा सकने पर, रेट-लिमिटिंग की बेहतर नीति लागू करने की सुविधा मिलती है.
config_softwareLskfRateLimiterEnforcing कॉन्फ़िगरेशन वैल्यू की मदद से, एनफ़ोर्सिंग मोड में SoftwareRateLimiter को कॉन्फ़िगर करें. एनफ़ोर्सिंग मोड में, SoftwareRateLimiter, दर को सीमित करने से जुड़ी अपनी नीति को, दर को सीमित करने वाले प्राइमरी टूल के साथ-साथ लागू करता है. गलत अनुमानों की दी गई संख्या के लिए, टाइम आउट की अवधि, मुख्य रेट-लिमिटर और SoftwareRateLimiter के लिए ज़रूरी अवधि में से ज़्यादा होती है.
नीति लागू न करने वाले मोड में, SoftwareRateLimiter पुष्टि करने के सभी अनुरोधों को प्राइमरी रेट-लिमिटर को भेजता है. ऐसा, रेट लिमिट करने की सेकंडरी नीति लागू किए बिना किया जाता है.
डुप्लीकेट अनुमान का पता लगाना
इस्तेमाल में आसानी और दर सीमित करने की बेहतर नीति का इस्तेमाल करने के लिए, Android 16 QPR2 और इसके बाद के वर्शन में, डुप्लीकेट अनुमान का पता लगाने की सुविधा काम करती है. इस सेटिंग के चालू होने पर, उपयोगकर्ताओं को एक ही गलत एलएसकेएफ़ कई बार डालने पर जुर्माना नहीं देना पड़ता.
कभी-कभी, असली उपयोगकर्ता एक ही गलत एलएसकेएफ़ को कई बार डाल देते हैं. अगर इसे कई बार अनुमान लगाने के तौर पर गिना जाता है, तो इससे बेवजह टाइमआउट हो सकता है. हमलावर, किसी एलएसकेएफ़ को एक से ज़्यादा बार इस्तेमाल नहीं करते. ऐसी नीति जो डुप्लीकेट अनुमानों को नहीं गिनती है, वह असली उपयोगकर्ताओं के लिए एलएसकेएफ़ एंट्री को बेहतर बनाती है. साथ ही, इससे हमलावरों के लिए एलएसकेएफ़ का अनुमान लगाना आसान नहीं होता. इससे दर को सीमित करने वाली नीतियों को ज़्यादा बेहतर तरीके से लागू किया जा सकता है. असली उपयोगकर्ताओं को टाइमआउट की समस्या का सामना कम ही करना पड़ता है. ऐसा इसलिए, क्योंकि उपयोगकर्ता को डुप्लीकेट के बजाय, पांच अलग-अलग गलत अनुमान डालने होते हैं.
Android 16 QPR2 और इसके बाद के वर्शन वाले डिवाइसों पर, वीवर को लागू किया जाता है. साथ ही, SoftwareRateLimiter को एनफ़ोर्सिंग मोड में कॉन्फ़िगर किया जाता है. ऐसे में, वीवर को पास किए जाने से पहले ही, डुप्लीकेट अनुमानों का पता लगा लिया जाता है और उन्हें अस्वीकार कर दिया जाता है. इस तरह के अनुरोध अस्वीकार होने से, गलत अनुमानों की संख्या नहीं बढ़ती. मेमोरी में, ज़्यादा से ज़्यादा पांच बार गलत अनुमान लगाने की जानकारी सेव की जाती है. अगर ट्रैकर में जगह नहीं है, तो सबसे पुराने ट्रैकर को हटा दिया जाता है, ताकि नए ट्रैकर को जोड़ा जा सके. ट्रैक किए गए सभी अनुमानों को, ट्रैक न किए गए आखिरी गलत अनुमान के पांच मिनट बाद खारिज कर दिया जाता है.
Gatekeeper, गलत अनुमानों को पुष्टि से जुड़ी अन्य गड़बड़ियों से अलग नहीं करता. इसलिए, SoftwareRateLimiter, Gatekeeper के मुख्य दर-सीमा तय करने वाले सिस्टम के तौर पर काम करने पर, डुप्लीकेट अनुमानों का पता लगाने की सुविधा काम नहीं करती.
Weaver लागू करने वाले लोग, Weaver लागू करने के दौरान डुप्लीकेट अनुमान का पता लगाने की सुविधा को चालू कर सकते हैं.