Android Q: جميع ميزات الأمان والخصوصية الجديدة القادمة إلى Android 10

في Google I/O، تعرفنا على التحسينات التي يقدمها Android Q. تتوفر ميزات وتحسينات جديدة للأمان والخصوصية في جميع أنحاء نظام التشغيل Android الجديد.

يجلب كل إصدار جديد من نظام التشغيل Android تحسينات على كل جانب تقريبًا بدءًا من التصميم والميزات وواجهات برمجة التطبيقات والمزيد. في مؤتمر Google I/O في وقت سابق من هذا الشهر، تعرفنا على كل ما يتعلق بـ التحسينات التي يقدمها Android Q سيجلب، وبطبيعة الحال، إعلانات الخصوصية والأمن الجديدة لم يتم استبعادها من المؤتمر. يعد أمان النظام الأساسي أحد أهم جوانب نظام التشغيل، خاصة بالنسبة لنظام التشغيل الذي نحمله معنا في جيوبنا في كل مكان. إذا لم يكن Android آمنًا، فلن نثق به بنصف عدد الوظائف التي نثق بها. ستكون مدفوعات NFC غير واردة، وستكون مشاركة الملفات مشكوكًا فيها في أحسن الأحوال، وسيكون الاتصال بأجهزة أخرى أمرًا جنونيًا تمامًا. على الرغم من مشكلة تجزئة الإصدار التي طال أمدها، فقد قامت Google بعمل جيد للغاية للحفاظ على عدد المشكلات الأمنية عند الحد الأدنى.

لقد تطور نظام Android ليصبح نظام تشغيل غنيًا بالميزات وآمنًا للغاية. ولكن، بالطبع، هناك دائما مجال للتحسين. هناك العديد من العوامل المساهمة في هذا الأمان، وقد تم تحسين عدد قليل منها بطريقة ما باستخدام Android Q.


التشفير

نظرًا لكونها إحدى طرق الأمان الأساسية، فمن المهم أن يدعم كل جهاز تشفيرًا قويًا. يقوم العديد من مصنعي المعدات الأصلية هذه الأيام بشحن أجهزتهم بأجهزة تشفير مخصصة. وفي حين أن هذا مفيد، فهو مكلف أيضًا. على هذا النحو، تم عادةً تقييد الأجهزة المخصصة للأجهزة ذات المستوى المتوسط ​​إلى العالي. هذا لا يعني أن الأجهزة المنخفضة لا تستطيع دعم التشفير، ولكن بدون التشفير المسرع للأجهزة، تتدهور تجربة المستخدم الإجمالية بسبب أوقات القراءة/الكتابة البطيئة. وهنا يأتي دور Adiantum.

أديانتوم

وفي فبراير، أعلنت جوجل عن Adiantum كبديل خوارزمية التشفير للهواتف المنخفضة نهاية التي لا تدعم مجموعات تعليمات AES العادية. تم تصميم Adiantum خصيصًا للتشغيل بدون أي أجهزة مخصصة. إنه بمثابة بديل أخف لتشفير AES العادي لنظام Android. معايير جوجل أخبرنا أنه في الواقع أسرع 5 مرات من AES، مع الجانب السلبي وهو أنه يضر قليلاً بالأمن. وهذا يجعله المرشح المثالي للهواتف ذات المواصفات المنخفضة، مثل تلك التي تعمل بنظام Android Go Edition. Adiantum مخصص أيضًا لمنتجات مثل الساعات الذكية ومجموعة متنوعة من أجهزة إنترنت الأشياء.

حتى الآن، كان Adiantum اختياريًا؛ يمكن للشركات المصنعة تمكينها على الأجهزة التي تعمل بنظام Android Pie، ولكنها لم تكن خوارزمية التشفير الافتراضية. الآن، تم تضمين Adiantum أصلاً كجزء من Android Q. وهذا يعني أن جميع الأجهزة التي يتم تشغيلها باستخدام Q سيُطلب منها تشفير بيانات المستخدم، دون أي استثناءات. ونتيجة لذلك، فإن الأجهزة التي يتم تشغيلها باستخدام Android Q مضمونة أن تحتوي على تشفير للتخزين، سواء كان ذلك عبر Adiantum أم لا.

مكتبة Jetpack الأمنية

Jetpack عبارة عن مجموعة من مكتبات دعم Android و واحدة من أحدث الإضافات موجود في ألفا: مكتبة أمان Jetpack. تعمل المكتبة على تبسيط عملية تأمين التطبيق الخاص بك عن طريق التعامل مع أشياء مثل إدارة مخازن المفاتيح المدعومة بالأجهزة وإنشاء المفاتيح والتحقق من صحتها.

تلس 1.3

ومع ذلك، فإن التخزين ليس هو المجال الوحيد الذي تم تحسين التشفير فيه. لقد تم تحسين التواصل مع الأجهزة الأخرى بشكل كبير، مع إدخال دعم TLS 1.3 بشكل افتراضي. TLS 1.3 هو أحدث معيار لتشفير الشبكة، تم الانتهاء منه بواسطة IETF في أغسطس 2018. يوفر TLS 1.3 المزيد من الخصوصية لتبادل البيانات عن طريق تشفير المزيد من مصافحات التفاوض. علاوة على ذلك، فهو أسرع من TLS 1.2 بسبب اقتطاع رحلة الذهاب والإياب بالكامل من مصافحة إنشاء الاتصال. إلى جانب الخوارزميات الحديثة الأكثر كفاءة، يؤدي هذا إلى زيادة في السرعة بنسبة تصل إلى 40%.

TLS 1.3 في جوجل كروم. المصدر: جوجل.

أصبح TLS الآن قابلاً للتحديث مباشرة من Google Play لأنه جزء من مكون "Conscrypt". يمكنك قراءة المزيد عن ذلك وعن Project Mainline هنا.

نظرًا لأننا نثق في العديد من المعاملات الحساسة التي تتم على أجهزتنا يوميًا، فإن ترقية طبقة النقل الآمنة (TLS) أصبحت أكثر أهمية من أي وقت مضى. تخزين أمثال بطاقات الصعود إلى الطائرة - وحتى رخص القيادة الرقمية في مرحلة ما في المستقبل - يعني نظام Android أنه يجب على جميع الأجهزة تشفير بيانات المستخدم بأفضل ما يمكن. سوف يمهد Adiantum والتشفير القسري الطريق حتى لتخزين البيانات الأكثر حساسية على أرخص الأجهزة. لكن التشفير ليس هو الطريقة الوحيدة التي تعمل بها Google على زيادة أمان Android في إصدار Q.


تغييرات الأذونات والخصوصية في Android Q

تخزين النطاق

يعد Scoped Storage بمثابة ضمانة جديدة يتم استخدامها لتقييد التطبيقات من قراءة/كتابة الملفات في وحدة التخزين الخارجية غير الموجودة في الدليل الخاص بالتطبيقات المعزولة الخاصة بها. يتمثل هدف Google في ثلاثة جوانب: إسناد أفضل للتطبيقات التي تتحكم في الملفات، وحماية بيانات التطبيق، وحماية بيانات المستخدم.

تعمل Google على مضاعفة استخدام MediaStore API لمحتوى الصوت والفيديو والصور المشترك. افتراضيًا، يمكن لجميع التطبيقات إدراج ملفاتها الخاصة أو تعديلها أو حذفها إلى MediaStore. الصور، متجر الوسائط. الفيديو ومتجر الوسائط. مجموعات الصوت دون الحاجة إلى أي أذونات. يضيف Android Q أيضًا ميزة جديدة متجر الوسائط. التحميلات مجموعة لتخزين المحتوى الذي تم تنزيله بواسطة المستخدم، والذي يمكن لجميع التطبيقات التي تستخدم MediaStore API المساهمة فيه. بينما يتم حذف الملفات المخزنة في الدلائل الخاصة بالتطبيقات المعزولة عند إلغاء التثبيت، فإن جميع الملفات التي تم المساهمة بها في مجموعات MediaStore تظل قائمة بعد إلغاء التثبيت.

للوصول إلى أي ملفات تم إنشاؤها بواسطة تطبيق آخر - سواء كان الملف موجودًا في إحدى مجموعات MediaStore أو خارجها - يجب أن يستخدم التطبيق إطار عمل الوصول إلى التخزين. علاوة على ذلك، يتم تنقيح بيانات EXIF ​​الوصفية للصور ما لم يحصل تطبيقك على إذن ACCESS_MEDIA_LOCATION الجديد الممنوح. في Android Q، يمكن للتطبيقات أيضًا التحكم في جهاز التخزين الذي سيتم نقل الوسائط إليه عن طريق الاستعلام عن اسم وحدة التخزين الخاصة به باستخدام getExternalVolume().

فرضت Google في البداية قيودًا على Scoped Storage على جميع التطبيقات في Android Q بغض النظر عن مستويات واجهة برمجة التطبيقات المستهدفة، ولكن بعد التعليقات، قامت الشركة بذلك إعطاء المطورين المزيد من الوقت لإجراء التعديلات. يمكن العثور على التفاصيل الكاملة حول تغييرات التخزين ذات النطاق على هذه الصفحة، ويمكنك معرفة المزيد حول توصيات Google بشأن أفضل الممارسات للتخزين المشترك من خلال مشاهدة مؤتمر Google I/O هذا يتحدث.

تحذيرات للتطبيقات التي تستهدف مستوى واجهة برمجة التطبيقات (API) < 23

ومع ذلك، فإن قيود الأذونات لا تنتهي عند هذا الحد. سيؤدي تثبيت تطبيق يستهدف مستوى واجهة برمجة التطبيقات (API) أقل من 23 (Android Lollipop أو أقدم) إلى قيام نظام التشغيل بعرض تحذير للمستخدم إذا طلب التطبيق المذكور أذونات حساسة عند التثبيت. قبل التثبيت، ستتاح للمستخدمين الفرصة لتحديد الأذونات التي يريدون منحها للتطبيق يدويًا قبل المتابعة. وبالتالي، لم يعد Android Q يسمح للتطبيقات بالالتفاف على أذونات وقت التشغيل.

مثل CopperheadOS، يتيح نظام Android Q الآن للمستخدم تعطيل جميع الأذونات الخطيرة المطلوبة قبل تشغيل التطبيق لأول مرة. ينطبق هذا فقط على التطبيقات التي تستهدف مستوى واجهة برمجة التطبيقات (API) 22 أو أقل، أي قبل تقديم أذونات وقت التشغيل (في Android Marshmallow).

في نهاية المطاف SYSTEM_ALERT_DEPRECATION لصالح Bubbles API

فقاعات API في العمل. المصدر: جوجل.

لم يعد من الممكن منح إذن التراكب (SYSTEM_ALERT_WINDOW) للتطبيقات التي تعمل على Android Q (Go Edition). بالنسبة للأجهزة التي لا تحتوي على إصدار Go، تدفع Google المطورين نحو واجهة برمجة التطبيقات Bubbles API الجديدة. Bubbles API هي ميزة تم تقديمها في أندرويد كيو بيتا 2 والذي يسمح بوظائف تشبه رؤوس الدردشة في Facebook Messenger. تظهر الإشعارات الواردة من التطبيقات على شكل فقاعات صغيرة على حواف الشاشة، والتي تتوسع عند النقر عليها من قبل المستخدم. داخل الفقاعة، يمكن للتطبيق عرض نشاط ما.

كان هذا التغيير ضروريًا لأن السماح للتطبيقات برسم تراكبات فوق التطبيقات الأخرى بحرية يشكل مخاطر أمنية واضحة. المشهور "عباءة وخنجر"استغل استغلال نقطة الضعف هذه على نطاق واسع. لقد تم تقييد وظائف واجهة برمجة التطبيقات (Overlay API) منذ إصدار Android Oreo، ولكن الآن قام إصدار Go من Android Q بإزالة الوصول إلى واجهة برمجة التطبيقات (API) بالكامل باستخدام الإصدار المستقبلي لإهمالها بالكامل.

قيود إطلاق النشاط في الخلفية

لم يعد بإمكان التطبيقات الموجودة في الخلفية تشغيل نشاط ما تلقائيًا أثناء إلغاء قفل الهاتف، بغض النظر عن مستوى واجهة برمجة التطبيقات (API) المستهدف. هناك قائمة كاملة من الشروط التي يمكن للتطبيقات بموجبها الآن تشغيل الأنشطة، والتي يمكنك قراءتها هنا. تطبيقات الخلفية التي لا تستوفي هذه الشروط وترغب في بدء نشاط ما بشكل عاجل سيتعين عليها الآن إخبار المستخدم عبر إشعار. إذا تم إنشاء الإشعار بهدف ملء الشاشة المعلق، فسيتم تشغيل الهدف على الفور إذا كانت الشاشة متوقفة عن العمل - وهو أمر مفيد للإنذارات أو المكالمات الواردة.

تقييد الوصول إلى الحافظة الخلفية

الوصول إلى الحافظة الخلفية هو لم يعد ممكن. لن يتمكن أي تطبيق ليس في المقدمة أو تم تعيينه كطريقة إدخال افتراضية من قراءة الحافظة الخاصة بك بأي شكل من الأشكال. وهذا يؤثر بشدة على التطبيقات مثل مديري الحافظة. تقول Google إن هذا التغيير يؤثر فقط على التطبيقات التي تستهدف Android Q حصريًا، لكن اختباراتنا تشير إلى أن التقييد لا يميز؛ أي تطبيق جربناه لم يتمكن من رؤية الحافظة.

وهذا التغيير منطقي بطبيعة الحال. غالبًا ما نقوم بنسخ معلومات حساسة إلى الحافظة - أشياء مثل كلمات المرور وتفاصيل بطاقة الائتمان - ولكن لا يزال من المؤسف أن نرى مديري الحافظة يضيعون هباءً.

الوصول إلى الموقع فقط أثناء استخدام التطبيق

خيارات إذن الموقع الجديدة

يسمح الإعداد الجديد الذي يتيحه المستخدم للتطبيقات بالوصول إلى موقعك فقط أثناء استخدام التطبيق. أضاف الإصدار التجريبي الأحدث من Android Q أيضًا إشعارًا يذكرك إذا منحت أحد التطبيقات إمكانية الوصول الدائم إلى الموقع.

الأدوار

الأدوار

تمت إضافة واجهة برمجة تطبيقات "الأدوار" جديدة. الأدوار هي في الأساس المجموعات التي تتمتع بأذونات الوصول المحددة مسبقًا. على سبيل المثال، قد تتمكن التطبيقات التي لها دور المعرض من الوصول إلى مجلدات الوسائط الخاصة بك، بينما قد تتمكن التطبيقات التي لها دور المتصل من التعامل مع المكالمات. يجب أن تحتوي التطبيقات التي يمنحها المستخدم دورًا معينًا على المكونات المطلوبة أيضًا. على سبيل المثال، يجب أن تحتوي التطبيقات التي لها دور المعرض على مرشح هدف الإجراء ذكري المظهر.نية.فعل.رئيسي ومرشح غرض الفئة android.intent.category. APP_GALLERY لتظهر كتطبيق معرض في الإعدادات.

أجهزة الاستشعار معطلة لوحة الإعدادات السريعة

مربع الإعدادات السريعة لأجهزة الاستشعار

يوجد مربع إعدادات سريعة جديد "إيقاف تشغيل أجهزة الاستشعار" والذي يقوم بإيقاف تشغيل القراءات الجميع أجهزة الاستشعار (مقياس التسارع، الجيروسكوب، وما إلى ذلك) الموجودة على جهازك للحصول على خصوصية حقيقية. يتم إخفاء مربع الإعدادات السريعة هذا بشكل افتراضي ولكن يمكن تمكينه بالانتقال إلى "مربعات مطور الإعدادات السريعة" في خيارات المطور.

القيود على /proc/net

لم تعد التطبيقات قادرة على ذلك الوصول إلى بروك/نت، مما يجعل الخدمات مثل netstat لم تعد قابلة للتطبيق. وهذا يحمي المستخدمين من التطبيقات الضارة التي تراقب مواقع الويب والخدمات التي يتصلون بها. تحتاج التطبيقات التي تحتاج إلى وصول مستمر، مثل شبكات VPN، إلى استخدام مدير إحصائيات الشبكة و مدير الاتصال الطبقات.

عناوين MAC العشوائية

يعد عنوان MAC الخاص بك معرفًا فريدًا تستخدمه الشبكات لتذكر الجهاز الذي تنتمي إليه. في Android Q، في كل مرة تتصل فيها بشبكة جديدة، سيستخدم جهازك عنوان MAC عشوائيًا جديدًا. نتيجة ل، لا تستطيع الشبكات تتبع موقعك عن طريق مطابقة شبكات WiFi التي تتصل بها مع عنوان MAC الخاص بهاتفك. لا يزال من الممكن الحصول على عنوان MAC الفعلي الخاص بالجهاز عن طريق التطبيقات عبر الحصول علىWifiMacAddress() يأمر.


تصلب النظام الأساسي في Android Q

لا يعني وجود خطأ واحد في Android أن المهاجمين أصبح لديهم الآن حق الوصول الكامل إلى نظام التشغيل أو أنه يمكنهم تجاوز أي أنظمة أمان. ويرجع ذلك جزئيًا إلى عدد من الإجراءات الوقائية مثل عزل العملية، وتقليل سطح الهجوم، والتحلل المعماري، وعمليات تخفيف الاستغلال. تجعل هذه الضمانات استغلال الثغرات الأمنية أكثر صعوبة أو حتى مستحيلة. ونتيجة لذلك، يحتاج المهاجمون عادةً إلى العديد من نقاط الضعف قبل أن يتمكنوا من تحقيق أهدافهم. لقد شهدنا هجمات في الماضي مثل درامر التي تعمل عن طريق ربط عمليات استغلال متعددة معًا.

يأخذ Android Q مثل هذه الإجراءات الوقائية ويطبقها على المناطق الأكثر حساسية مثل الوسائط ومكونات Bluetooth بالإضافة إلى kernel أيضًا. وهذا يجلب بعض التحسينات الملحوظة.

  • صندوق حماية مقيد لبرامج الترميز.
  • زيادة استخدام المطهرات في الإنتاج للتخفيف من فئات كاملة من نقاط الضعف في المكونات التي تعالج المحتوى غير الموثوق به.
  • Shadow Call Stack، الذي يوفر تكامل تدفق التحكم في الحافة الخلفية (CFI) ويكمل حماية الحافة الأمامية التي توفرها LLVM’s CFI.
  • حماية التوزيع العشوائي لتخطيط مساحة العنوان (ASLR) ضد التسريبات باستخدام ذاكرة التنفيذ فقط (XOM).
  • مقدمة لمخصص Scudo المقوى الذي يجعل استغلال عدد من الثغرات الأمنية ذات الصلة بالكومة أكثر صعوبة.

هذا كثير من المصطلحات البرمجية. جوهر الأمر هو أنه أولاً، تعمل برامج الترميز البرمجية الآن في صناديق الحماية التي تتمتع بامتيازات أقل، مما يعني أنها من غير المرجح أن تتمكن البرامج الضارة من تشغيل أوامر يمكن أن تلحق الضرر بجهازك، كما هو الحال في هذه الحالة ل رهبة المسرح طريق العودة في عام 2015.

صندوق حماية مقيد لبرامج الترميز. المصدر: جوجل.

ثانيًا، يتحقق Android الآن من الوصول إلى المصفوفة خارج الحدود في أماكن أكثر، بالإضافة إلى التجاوزات. يؤدي منع التجاوزات وتوجيه العمليات للفشل بشكل آمن إلى تقليل نسبة الثغرات الأمنية في مساحة المستخدم بشكل كبير. ما يعنيه هذا هو أنه إذا حاول برنامج ضار التسبب في تعطل شيء ما عن طريق محاولته عمدًا للوصول إلى البيانات غير الموجودة، سيتعرف Android الآن على ذلك ويخرج من البرنامج، بدلاً من ذلك تحطمها.

ثالثًا، يحمي Shadow Call Stack عناوين الإرجاع عن طريق تخزينها في حزمة ظل منفصلة، ​​مما يجعل الوصول إليها غير ممكن للبرامج العادية. عادةً ما تكون عناوين الإرجاع مؤشرات للوظائف، لذا فإن حماية هذه العناوين مهمة للتأكد من عدم تمكن المهاجمين من الوصول إلى الوظائف التي لا ينبغي لهم الوصول إليها.

رابعًا، ASLR هي طريقة حماية تعمل على تحديد مكان تخزين البرامج في الذاكرة بشكل عشوائي، مما يجعلها من الصعب معرفة مكان تخزين البرامج في الذاكرة بناءً على موقع البرامج الأخرى البرامج. تعمل ذاكرة التنفيذ فقط على تقوية ذلك عن طريق جعل التعليمات البرمجية غير قابلة للقراءة.

أخيرًا، Scudo هو مُخصص كومة الذاكرة المؤقتة الديناميكي الذي يدير الذاكرة بشكل استباقي بطريقة تجعل استغلال الثغرات الأمنية القائمة على الكومة أكثر صعوبة. يمكنك قراءة المزيد عنها هنا.


المصادقة

تحديثات BiometricPrompt في Android Q

طرحت Google واجهة برمجة تطبيقات BiometricPrompt الجديدة منذ أكثر من عام، في معاينة مطور Android P 2. كان المقصود منه أن يكون موجهًا عامًا لنظام Android لطرق إلغاء القفل البيومترية. الفكرة هي أن الأجهزة التي تدعم أكثر من مجرد مسح بصمات الأصابع، على سبيل المثال. سيكون بإمكان مسح القزحية على خط Galaxy S من سامسونج استخدام هذه الطرق عندما تطلب التطبيقات التحقق.

يضيف Android Q دعمًا قويًا للتحقق من الوجه وبصمات الأصابع، بالإضافة إلى توسيع واجهة برمجة التطبيقات لدعم المصادقة الضمنية. تتطلب المصادقة الصريحة أن يقوم المستخدم بالمصادقة بطريقة ما قبل المتابعة، بينما لا تحتاج المصادقة الضمنية إلى مزيد من تفاعل المستخدم.

BiometricPrompt API التدفق الضمني والصريح. المصدر: جوجل.

علاوة على ذلك، يمكن للتطبيقات الآن التحقق مما إذا كان الجهاز يدعم المصادقة البيومترية عبر عملية بسيطة استدعاء الوظيفة، مما يسمح لهم بعدم إضاعة الوقت في استدعاء BiometricPrompt على الأجهزة التي لا تفعل ذلك ادعمه. سيكون الاستخدام المثالي لذلك هو إذا كانت التطبيقات ترغب في توفير إعداد "تمكين تسجيل الدخول البيومتري" استنادًا إلى ما إذا كان الجهاز يدعم المصادقة البيومترية أم لا.

اللبنات الأساسية لدعم الهوية الإلكترونية

في وقت سابق من هذا العام، اكتشفنا دليلاً على أن جوجل كذلك العمل على دعم المعرفات الإلكترونية في الروبوت. في مؤتمر I/O، أطلعتنا Google على التقدم المحرز في هذه الميزة. تقول Google إنها تعمل مع ISO لتوحيد تنفيذ رخص القيادة المتنقلة، مع جوازات السفر الإلكترونية قيد التنفيذ. بالنسبة للمطورين، ستوفر Google مكتبة Jetpack حتى يمكن البدء في إنشاء تطبيقات الهوية.


مشروع الخط الرئيسي في Android Q

يعد Project Mainline مشروعًا رئيسيًا من جانب Google لتقليل تجزئة وحدات وتطبيقات نظام معينة. ستتحكم Google في التحديثات لحوالي 12 مكونًا للنظام عبر متجر Play. لقد تحدثنا عن مشروع Mainline بتعمق في مقال سابق إذا كنت مهتمًا بقراءة المزيد.


خاتمة

لقد كان الأمان دائمًا جزءًا أساسيًا من تطوير Android. لقد قامت Google بعمل رائع في إبقاء نظام Android محدثًا بأحدث ميزات الأمان، بالإضافة إلى تقديم بعض الابتكارات الخاصة بها. إنهم يواصلون عملية التطوير هذه باستخدام Android Q، حيث يملؤه بميزات الأمان المصممة للتأكد من أن بياناتك أكثر أمانًا من أي وقت مضى.


المصدر 1: الجديد في Android Q Security [Google]

المصدر 2: الأمان على Android: ما التالي [Google]

المصدر 3: قائمة الانتظار لتحسينات التصلب [Google]

مع مدخلات من مشعل الرحمن وآدم كونواي.