امنیت در اندروید

امنیت امروزه تبدیل به میدان رقابت کم‌نظیر میان حمله‌کنندگان سایبری شده است؛ جولانگاهی که متأسفانه کاربران، قربانیان آن هستند. این نوشته برگرفته از مطالب موجود در وب است اما نه در سطح وب. اطلاعاتی که در مورد امنیتِ اندروید در جستجوهای اولیه گوگل بدست می‌آید عمدتا سطحی و عمومی هستند. بدین ترتیب در این نوشته می‌خواهیم کمی عمیق‌تر به مسئله امنیت در اندروید بپردازیم.

سرفصل‌ها

وقتی از امنیت در یک سامانه اندرویدی صحبت می‌کنیم باید موارد ذیل را ببینیم:

• زنجیره اعتماد یا همان Root of Trust

• معماری TrustZone در پردازنده ARM

• معماری سامانه-روی-تراشه (SoC)

• معماری درایور در اندروید و ناحیه کاربری (User Space)

• منطقه امن (Trusted Zone)

همانطوری که پیداست، این نوشته به امنیت کاربری اندروید، یعنی موضوعاتی نظیر دستگاه گم‌شده، هرزنامه، بدافزارهای جاسوسی و وب‌گردی امن نمی‌پردازد.

زنجیره اعتماد یا همان Root of Trust

مفهوم زنجیره اعتماد یا همان Root of Trust، مختص تلفن همراه هوشمند نیست و در سامانه‌های دیگر هم پیاده‌سازی می‌شود که نمونه بارز آن گواهی SSL و فرایند بررسی آن در مرورگر وب است. در تلفن همراه هوشمند، این زنجیره از یک مؤلفه سخت‌افزاری آغاز می‌شود. دقت بفرمائید که نگفتیم در اندروید گفتیم در تلفن همراه هوشمند؛ یعنی چی؟ یعنی

امنیت در گوشی از اندروید آغاز نمی‌شود! واقعیت این است که چندین حلقه اول این زنجیره اصلا به اندروید که هیچ! به کرنل هم ارتباطی ندارد.

بله! این اولین نکته مهم است. چند مرحله اول شامل اعتبارسنجی ابزار فلش رام، preloader (همان بوت‌لودر مرحله اول) و بوت‌لودر-مرحله-دوم است. به طور دقیق‌تر، بوت‌رام، وظیفه تایید preloader را بر عهده دارد، preloader موظف است بوت‌لودر-مرحله-دوم و TEE را تایید نماید. پس از تایید TEE، بوت‌لودر-مرحله-دوم اجرا می‌شود. بوت‌لودر-مرحله-دوم، کرنل و دیگر ایمیج‌ها را تایید می‌کند. پس عملا تا اینجای کار ساز و کارهای امنیتی اندروید که شامل بررسی صحت (integrity) یا به اصطلاح بوت تایید شده اندروید (Android Verified Boot) است، وارد عمل نشدند. این بخش را با یک دسته‌بندی جمع‌بندی کنیم:

در یک گوشی هوشمند، دو فضا وجود دارد: فضاهای غیر اندرویدی (عمدتا یا کاملا در اختیار تولید کننده پردازنده) و فضا اندرویدی (پیاده‌سازی شده توسط گوگل یا در مواردی OEM).

معماری درایور در اندروید و ناحیه کاربری (User Space)

مفهوم و پیاده‌سازی درایورها در پلتفرم اندروید، بر خلاف سیستم‌های عامل دسکتاپ رایج مانند ویندوز یا لینوکس استاندارد، از الگوی متمایزی پیروی می‌کند. در حالی که درایورهای دسکتاپی معمولاً به عنوان یک بسته/ماژول قابل نصب ارائه می‌شوند، درایورهای اندرویدی با رابط‌ها، فایل‌های قابل پیکربندی می‌شوند و اغلب شامل فایل‌های باینری (در مقابل کد منبع) هستند که به آن لایه انتزاع سخت‌افزاری (HAL) گفته می‌شود. این رویکرد که بخشی از فلسفه طراحی معماری اندروید است، درایورها و کنترلرهای سخت‌افزاری را به‌عنوان پیاده‌سازی‌هایی از رابط‌های تعریف‌شده (HIDL یا AIDL) و مجموعه‌ای از کتابخانه‌های باینری ارائه می‌دهد که مستقیماً با هسته لینوکس پایه در تعامل هستند. دلیل این امر نه فنی که تجاری است:

این باعث می‌شود شرکت‌ها، مجبور نباشند کدهای خود را به دلیل قرارگیری در کرنل، متن‌باز کنند.

این تفاوت معماری تأثیر مستقیمی بر ساختار مؤلفه‌های سطح پایین سیستم، مانند سرویس پس‌زمینه موقعیت‌یابی شبکه (Network Location Daemon)، می‌گذارد. چنین مؤلفه‌ای یک کد ساده در کرنل قرار می‌دهد (Kernel Space) برای ارتباط با سخت‌افزار gnss، اما پیاده‌سازی منطق این مؤلفه را از کرنل بیرون کشیده و درون یک دیمن (Daemon) متن‌بسته می‌برد (User Space). البته چون دیگر اجزای سامانه می‌خواهند با این مؤلفه در ارتباط باشند، قطعا برای آن واسط‌های استانداردی توسط اندروید در نظر گرفته شده است که این دیمن پیاده‌سازی آن‌ها را نیز می‌تواند بر عهده داشته باشد. البته لازم به ذکر است امکاناتی جهت پیکربندی در قالب فایل‌های xml یا ثابت‌های تعریف شده در فایل‌های C/CC در اختیار توسعه‌دهندگان بیرونی قرار داده می‌شود.

این پراکندگی و وابستگی به اجزای اختصاصی (Proprietary)، چالش‌هایی در زمینه شفافیت، امنیت و به‌روزرسانی‌های ایجاد می‌کند

در حال کامل شدن ...