موارد امنیتی در سیستم عامل اندروید

اندروید با توجه خاص به امنیت طراحی شده است. اندروید به عنوان یک پلت فرم ویژگی هایی را ارائه می دهد که داده های موجود کاربر در تلفن همراه را از طریق امنیت چند لایه محافظت می کند. پیش فرض های امنی وجود دارند که از کاربر و برخی پیشنهادات محافظت می کند و می توانند اهرمی باشند برای جامعه توسعه دهندگان تا برنامه هایی امن ایجاد کنند. موارد زیر برخی مشکلاتی هستند که به هنگام ترکیب کردن کنترل های امنیتی اندروید  باید در ذهن داشت:

  • محافظت از داده های مرتبط با کاربر
  • امن کردن منابع سیستم
  • اطمینان از اینکه یک برنامه نمی تواند به داده های برنامه ای دیگر دسترسی داشته باشد

 

Sandboxing برنامه ها

در لینوکس هر کاربر با یک شناسه منحصر به فرد (UID) مشخص می شود، در نتیجه کاربران از یکدیگر تفکیک شده و نمی توانند به داده های یکدیگر دسترسی داشته باشد . به طور مشابه، هر برنامه نیز با یک شناسه منحصر به فرد خود و با یک فرآیند مجزا اجرا می شود. همه برنامه های متعلق به یک کاربر خاص نیز با مجوزهای دسترسی آن کاربر اجرا می شوند. در نتیجه، یک sandboxing برنامه در سطح کرنل شکل می گیرد و برنامه فقط توانایی دسترسی به منابعی را دارد که مجاز است.

به عبارت دیگر، یک UID به هر برنامه اختصاص داده می شود و برنامه ها در فرآیند های مجزا اجرا می شود. ابن کار sandboxing برنامه ها در سطح کرنل را تضمین می کند. همچنین تضمین می کند که یک برنامه محدوده کاری خود را نمی شکند و فعالیت مخربی را شروع نمی کند. اگر برنامه ای تلاشی برای انجام یک فعالیت مخرب داشته باشد، برای مثال بخواهد داده های یک برنامه دیگر را بخواند، مجاز نمی باشد زیرا آن برنامه از کاربر مجوز نگرفته است. به این ترتیب سیستم عامل از دسترسی یک برنامه به داده های برنامه ای دیگر محافظت می کند. نمودار زیر تصویری از مکانیزم sandboxing اندروید را نشان می دهد :

با توجه به این نمودار، ایجاد شدن یک شناسه منحصر به فرد لینوکس (Linux UID) برای هر برنامه را مشاهده می کنیم. به ازای هر برنامه، منابع اعتبار سنجی شده و در اختیار آن برنامه قرار میگیرد و در نتیجه نوعی از کنترل دسترسی تضمین می شود.

 

inter-process communication (IPC)

در قسمت قبل بیان شد که برنامه ها به عنوان فرایندهای جداگانه با هویت های مجزای لینوکس به منظور دستیابی به sandboxing اجرا می شوند. سرویس های سیستمی نیز به همین روش اجرا می شوند با این تفاوت که آن ها مجوزهای دسترسی بالاتری دارند. بنابراین برای مدیریت و هماهنگ سازی داده و سیگنال ها بین این فرآیندها، یک فریم ورک تعامل بین فرآیندی (IPC) نیاز است. فریم ورک IPC ما را قادر می سازد تا داده ها را بین کامپاننت های یک برنامه و یا برنامه ای متفاوت به اشتراک بگذاریم. همچنین به تفکیک مجوزها از طریق ایزوله کردن داده، کمک می کند.

در اندروید، این کار با فریم ورک Binder اجرا می شود. فریم ورک Binder تعاملات بین فرآیندهای مجزا را ممکن می سازد. کامپاننت های برنامه های اندروید مانند intent و content provider ها نیز بر روی فریم ورک Binder ساخته می شوند. با استفاده ازBinder ، طیف گسترده ای از action ها مانند فراخوانی (invoke) متدهای اشیاء ریموت از طریق در نظر گرفتن آن ها به عنوان اشیاء محلی ، فراخوانی متدها به صورت همزمان (synchronously) و غیر همزمان (asynchronously) و … را می توان انجام داد.

فرض کنید که برنامه در فرآیند A می خواهد از سرویسی که فرآیند B ارائه می دهد، استفاده کند. بنابراین فرآیند A به عنوان کلاینت سرویس را از فرآیند B که سرور محسوب می شود، درخواست می کند. در این مدل تعامل از  Binder استفاده می شود که در بخش بعدی بررسی می شود.

 

فرآیند Binder

در IPC که از Binder استفاده می شود، از طریق کرنل اصلاح شده اندروید از طریق درایور موجود در /dev/binder  فعال می شود. به صورت پیش فرض، این درایورهای دستگاه، اجازه خواندن و نوشتن را که به صورت globally تنظیم شده، را دارند. به این معنی که هر برنامه ای می تواند از آن ها بخواند و یا بر روی آن ها بنویسد.هر سرویس Binder یک توکن 32 بیتی منحصر به فرد دارد که به هنگام استفاده از مکانیزم Binder اختصاص داده می شود. این توکن در میان تمام فرآیندهای سیستم منحصر به فرد باقی می ماند. یک کلاینت بعد از تشخیص مقدار توکن Binder می تواند با سرویس تعامل داشته باشد.

یک کلاینت و یک سرور نمی توانند مستقیما با یکدیگر در Binder تعامل داشه باشند. تمام ارتباطات سمت کلاینت از طریق proxy ها و ارتباطات سمت سرور از طریق stub ها انجام می شود. این پراکسی ها و stub ها مسئولیت تبادل داده و دستوراتی که از طریق Binder Driver ارسال می شوند، را به عهده دارند.

اگر فرآیند A درخواست استفاده از سرویس مورد استفاده در فرآیند B را داشته باشد، درایور Binder مقادیر UID و PID فرآیند B را برای هر تراکنش اضافه می کند. در نهایت، فرآیند A می تواند مقادیر به دست آمده را بررسی کند و تصمیم بگیرد آیا تراکنش باید انجام شود یا خیر. توکن Binder به عنوان یک توکن امنیتی برای ارتباطات و تعاملات عمل می کند و به این ترتیب امنیت اجرا می شود.

 

امضا کردن برنامه ها

امضا (sign) شدن برنامه ها به صورت دیجیتالی اجباری است. بانک های برنامه های اندرویدی برای دستیابی هویت توسعه دهنده برنامه و تأیید منشا داده ها از گواهی نامه های دیجیتال استفاده می کنند. معمولا گواهی نامه های self-signed برای امضای یک برنامه قبل از نصب استفاده می شود.

توسعه دهندگان فقط زمانی می توانند برنامه شان را در گوگل پلی قرار دهند که آن را امضا کرده باشند و کلید خصوصی ای که برنامه با آن امضا می شود توسط توسعه دهنده نگاه داشته می شود. با استفاده از این کلید، توسعه دهندگان می تواند برنامه هایشان را آپدیت کنند، بین برنامه ها داده به اشتراک بگذارند و کارهایی از این دست انجام دهند. در زمان توسعه، یک برنامه با کلیدی به عنوان debug key (که بر روی پلت فرمی که برای توسعه استفاده می شود، وجود دارد) امضا می شود ولی برای انتشار برنامه به صورت تجاری، باید برنامه با کلید اختصاصی توسعه دهنده امضا شود. نمودار زیر لیست مراحل انجام شده پس از توسعه برنامه را نشان می دهد :

 

Security-Enhanced Linux

Security-Enhanced Linux (SELinux) ویژگی جدیدی است که در اندروید 4.3 معرفی شد و به طور کامل در اندروید 5.0 اجرا شد. تا اندروید نسخه 4.3، امنیت اندروید بر اساس کنترل دسترسی اختیاری (DAC) بود که برنامه ها می توانستند اجازه هایی را درخواست کنند، و کاربران می توانستند بپذیرند و یا رد کنند. بدین ترتیب بدافزار می توانست با به دست آوردن این مجوزها بر روی تلفن های همراه کارهای مخرب انجام دهد. SE Android از کنترل دسترسی اجباری (MAC) استفاده می کند و تضمین می کند که برنامه ها در محیطی ایزوله شده فعالیت می کنند. بدین ترتیب اگر کاربر یک برنامه بدافزار را نصب کند، بدافزار نمی تواند به سیستم عامل دسترسی پیدا کند و عملکرد دستگاه را به مخاطره بیاندازد.

SELinux استفاده می شودتا استفاده از MAC بر روی همه ی فرآیندهای اعمال شود، حتی فرآیندهایی که با سطح دسترسی root اجرا می شوند. SELinux بر اساس اصل default denial عمل می کند، به این صورت که چیزی که صریحا مجاز نشده باشد، انکار یا منع (denied) می شود.

SELinux  می تواند در یکی از دو حالت جهانی عمل کند: حالت مجاز یا آسان گیر (permissive mode)، که در آن منع اجازه ها log شده اما اجرا نشده است، و مد اجرایی (enforcing mode) ، که در آن منع ها هم log شده و هم به اجرا گذاشته می شوند.

 

رمزنگاری کامل دیسک

رمزنگاری فرآیندی است که در آن تمام داده های کاربر در یک دستگاه اندرویدی با استفاده از کلیدهای رمزنگاری متقارن رمز می شود.  هنگامی که یک دستگاه رمزنگاری می شود، تمام داده های ایجاد شده توسط کاربر به طور خودکار قبل از اعمال آن به دیسک رمزنگاری می شوند و همه آنها قبل از بازگشت به فرایند فراخوانی داده ها، آن ها را رمزگشایی می کنند. رمزنگاری تضمین می کند که حتی اگر یک شخص غیر مجاز سعی در دسترسی به داده ها داشته باشد، قادر به خواندن آن نخواهد بود.

اندروید دارای دو روش برای رمزنگاری دستگاه است: رمزنگاری کامل دیسک (Full disk encryption) و رمزنگاری مبتنی بر فایل (file-based encryption).

اندروید 5.0 و بالاتر از رمزنگاری کامل دیسک پشتیبانی می کند. رمزنگاری کامل دیسک از یک کلید که به وسیله رمزعبور دستگاه کاربر محافظت می شود، استفاده می کند و از تمام پارتیشن داده های کاربر در دستگاه محافظت می کند. در هنگام بوت شدن دستگاه، کاربران باید رمزعبور خود را قبل از دسترسی به دیسک وارد کنند. این برای امنیت عالی است، اما این به این معنی است که اکثر قابلیت های اصلی گوشی در زمانیکه کاربران دستگاه خود را راه اندازی مجدد می کنند بلافاصله در دسترس نیستند. از آنجایی که دسترسی به داده های آنها در پشت رمزعبور کاربر محافظت می شود، ویژگی هایی مانند آلارم ها نمی توانند کار کنند، سرویس هایaccessibility  غیرقابل دسترس هستند و تلفن ها نمی توانند تماس ها را دریافت کنند.

اندروید 7.0 و بالاتر از رمزنگاری مبتنی بر فایل پشتیبانی می کند. رمزنگاری مبتنی بر فایل اجازه می دهد فایل های مختلف با کلیدهای مختلف رمز شوند و هر کدام به صورت مستقل رمزگشایی شوند. دستگاه هایی که از رمزنگاری مبتنی بر فایل پشتیبانی می کنند می توانند از ویژگی جدیدی به نام Direct Boot که اجازه می دهد دستگاه های رمز شده مستقیما به صفحه قفل بوت شوند نیز پشتیبانی کنند. بنابراین می توان به ویژگی ها و قابلیت های مهم دستگاه مانند سرویس های accessibility و زنگ های هشداردسترسی سریع داشت.

 

مترجم و گردآورنده : مریم مکاریان خراسانی

 

منبع :

 

  • Practical Mobile Forensics,Second Edition,Copyright © 2016,Heather Mahalik and Rohit Tamma and Satish Bommisetty,Published by Packt Publishing Ltd.
  • Mobile Application Penetration Testing,Copyright © 2016,Vijay Kumar Velu,Published by Packt Publishing Ltd.
  • Android Security Internals,Copyright © 2015, Nikolay Elenkov, Published by no starch press Inc.
  • https://source.android.com/security/encryption
  • https://sokanacademy.com/courses/linux/1633/