基于SE Android結合遠程控制提升移動系統安全性

楊中皇, 董倫銘

(高雄師范大學 軟件工程與管理學系， 臺灣 高雄 82444)

?

基于SE Android結合遠程控制提升移動系統安全性

楊中皇, 董倫銘

(高雄師范大學 軟件工程與管理學系， 臺灣 高雄 82444)

修改Google公司和美國國家安全局合作發布的SE Android原始碼，修改seadmin功能，結合遠程控制設備應用程序權限，支持移動設備管理(MDM)功能，整合出適合企業使用的安卓(Android)設備控管系統。以控制設備應用程序權限的方式，可確保安卓設備運作，防止惡意攻擊者竊取重要數據，維護移動設備安全。

移動設備；移動設備管理；權限管理；安全加強Linux；SE Android；系統安全

移動設備越來越普及，使用者經常將隱私數據儲存至其中，故其系統安全性應被重視。根據IDC的調查結果[1]，2015年第一季度全球智慧型手機的出貨量為3.344億臺，較2014年第一季度的2.883億臺成長了16%，其中搭載Android系統的智慧型手機占比78%。又根據市場研究機構Global WebIndex的調查報告[2]，從2012年開始，全球搭載Android系統的移動設備已從數量上超越搭載iOS系統的移動設備的，在全球被使用的移動設備中，2012年搭載Android系統的占比31%，搭載iOS系統的占比10%，而到2015年成長為Android系統占比54%和iOS系統占比18%。以上數據顯示，Android系統最為普遍。然而，從移動安全方面考察，根據國際研究暨顧問機構Gartner的調查報告[3]，移動設備經常包含使用者的敏感信息，因此，應該加以保護。

在解決應用程序濫用移動設備敏感信息的相關研究中，Gilbert等人[4]發現，移動設備的第三方應用軟件(third -party apps)可能濫用或不正當處理使用者的隱私信息，因此，提出了自動化安全驗證系統AppInspector，該系統對移動設備的應用程序進行分析，并產生潛在的安全和隱私行為報告。Yang等人[5]建議，使用應用程序的Context來分析移動設備軟件的惡意行為，因為，他們發現，移動設備的惡意軟件可能通過模仿一般應用軟件安全取用隱私或敏感信息的行為(如發送短信)，來逃避應用軟件安全性分析檢測，并控制惡意行為只發生在特定的時刻(如夜間)，這是由于，一般分析惡意軟件的應用程序不太可能24小時運作。

以前兩項工作為例，大部分相關研究都以分析應用程序惡意取用移動設備權限的行為來解決移動設備隱私數據的保護，使用者都需經過分析才能適時給予應對。另外，使用特定方法來檢測惡意行為，雖然能檢測出確定為惡意行為的機率已經很高，卻并非全面。

為了解決惡意軟件借由取得某些權限來獲取使用者隱私信息的問題，不妨摒除對惡意軟件分析的想法，直接提供使用者控管移動設備軟件是否可以取得權限的方法，從而限制移動設備上個別軟件取用的權限，或為所有軟件限定一個是否可以取用的權限，來確保使用者隱私數據的安全，并結合遠程控制，形成類似MDM的管理模式，以供管理域內移動設備或保護重要隱私數據者參考使用[6-7]。

使用由美國國家安全局(National Security Agency，NSA)以及Google發行的Android Open Source Project(AOSP)[8]，合作產生SE Android[9-12]的開放原始碼，導出其特定的應用程序SE Admin，并分離出權限管理應用程序appops，之后，以eclipse程序編輯器新增一鍵管理所有設備上應用程序特定權限的功能。設備應用程序權限控管實現的過程并不經由SE Linux的MAC機制，但會受到MAC的限制，以確保實現過程不會受到刻意行為修改。此外，結合新增SSL/TLS安全通信協定的androRAT程序，可以達到遠程控制的效果。由此，通過管理應用程序的權限，即可達到保護使用者隱私信息的目的。

開發Android智慧型行動設備控管系統，包含在設備上管理應用程序權限、遠程管理設備應用程序權限、遠程監控設備位置信息、遠程發送警告信息、遠程獲取設備當前信息以及遠程監控設備檔案目錄等功能，行動設備控管系統使用Java為主要之開發語言，并且系統使用圖形化界面顯示，使用者只需選擇需要控管的界面并點擊相關的功能按鈕，即可執行各項功能。

1　SE Android與移動設備管理

1.1SE Android作業系統概述

1.1.1Android Open Source Project

Google對于Android的發展留有一個管道進行持續升級，但AOSP[8]還是要依系統的硬件性能作為判斷依據。在AOSP中，Nexus作為標準點代表原生設備。大部分原始設備制造商(Original Equipment Manufacturer，OEM)借由AOSP開發屬于自己的行動設備系統，如SONY、HTC、ASUS、Samsung，等等。另外，也有些公司借由修改AOSP來提升Android系統性能或安全性，并編譯出ROM，放在網路上供他人下載使用，如CyanogenMod。

1.1.2Android安全增強內容

Android 4.3開始支持SE Android[12]的系統功能。SE Android將系統核心由原先的Linux核心修改為SE Linux核心，讓原本的Android系統多了SE Linux的安全性機制，如強制存取機制。SE Android的最大特點在于，應用程序利用user或是root身份取用系統資源時，會先經由SELinux安全機制中制定的policy做篩選動作，若不通過即會被拒絕取用。SE Android系統架構[8]如圖1所示，其中粗體所示為SE Android的修改內容，例如：系統應用新增了SE Admin應用，Settings應用中新增了支持SE Android的設定項目；另外，API以及JNI中也新增了支持SE Android的方法與指令；最后，將Linux修改為SE Linux kernel。

圖1　SE Android系統架構

SE Android以AOSP原始碼為例所做的修改內容如表1所示。AOSP/external/目錄下新增修改了政策內容，AOSP/packages/apps/目錄下有SEAdmin和Settings兩項應用修改，AOSP/bionic /、AOSP/bootable/recovery/和AOSP/build/三項目錄修改系統運行基礎，最后，AOSP/ frameworks/base/以及AOSP/system/目錄下的core/修改Android系統底層。

表1　SE Android修改的屬性

1.1.3Recovery模式與OTA更新

Recovery模式[13]是一個較Android系統小的操作系統，一般用來執行不能直接在Android系統執行的命令，如系統OTA更新(包含只處理應用程序)或恢復出廠設置等功能。Recovery分區實現了Google公告的Android兼容性定義文檔(CDD)要求關于操作系統升級的基本功能和使用的更新機制必須支持在不清除用戶數據的情況下的升級。升級過程首先在主操作系統中下載一般為ZIP之壓縮過的更新檔案，然后，經由Recovery系統使用更新檔案進行更新。另外，它還支持tethered更新，即用戶將更新檔案下載至臺式機，再使用adb sideload OTAupdate.zip命令，將更新檔案推送到設備的Recovery系統中進行更新。

一般來說，OTA[13]更新檔案中包含操作系統開發者或開發商Google的簽章文件，在更新過程中會驗證此簽章文件以確保目前使用的OTA更新檔案是經由同一個開發者或開發商提供，如果驗證不通過，更新將會失敗。另外，在Android操作系統中，為了確保應用程序更新時也是由相同的開發者提供，Android操作系統在應用程序更新時也會驗證在應用程序安裝文件(.apk)中的簽章文件，這也包含系統應用程序。但是，為了確保操作系統在運行過程中不會因為用戶更改了system分區的內容使得操作系統出現錯誤，Android操作系統在運行過程中system分區處于read-only狀態。由于Client端應用引用的API要求系統應用的權限，為了將Client端應用安裝至system分區中，須經由Recovery系統推送，又因Recovery系統推送檔案時必須驗證開發者簽章，所以，可考慮使用第三方開源的Recover系統TWRP，將Client端應用推送至操作系統system分區中。

TWRP是一個自定義recovery mode的開源項目(https://twrp.me/FAQ/)，一開始由4個人開發而成，后由類似于開發者論壇的模式，讓許多人除錯、更新和提出意見演化至今。自定義的recovery可以讓開發者安裝自定義的應用軟件，甚至可以安裝完整的ROM來更新或是修改Android設備的操作系統。

1.2Android SSL/TLS安全通信協定

使用SSLSocket[14]實現Server端與Client端之間信息的安全傳輸，其實是對Socket通信的的拓展，在socket通信的基礎上添加了一層安全性保護，提供了更高的安全性，包括身份驗證、數據加密以及完整性驗證。其中，身份驗證用于數字憑證的發放和應用；數據加密可以防止消息傳遞過程中被別人監聽而造成的損失，即使第三方監聽到傳遞的消息，但是由于沒有正確的密鑰，其仍然無法得到正確的消息完整性驗證，以防止消息在傳遞過程中被別人修改。

1.2.1SSL/TLS安全通信基礎

SSL/TLS通信握手基礎的9個步驟如圖2所示。

(1) 將客戶端支持的SSL版本和加密算法等信息發送給服務器。

(2) 服務器確定本次通信采用的SSL版本和加密套件后，回復信息給客戶端。

(3) 服務器將包含本身公鑰的數字證書傳送給客戶端。

(4) 服務器發送初始完成信息，通知客戶端SSL版本和加密套件協商結束，并開始進行密鑰交換。

(5) 當客戶端驗證SSL服務器的證書合法后，利用服務器的證書中之公鑰加密客戶端隨機生成的隨機數(這是一個用在對稱加密密鑰的亂數)，并將消息發送給服務器。

(6) 客戶端通知服務器后續傳輸信息時，將采用協商好的密鑰和加密套件進行加密傳輸。

(7) 客戶端計算已交互的握手信息的Hash值，利用協商好的密鑰和加密算法處理Hash值，并發送給服務器。服務器利用同樣的計算方式計算已交互的握手信息的Hash值，并與客戶端傳送過來的信息解密后比較，如果兩者相同，則證明密鑰和加密套件協商成功。

(8) 服務器通知客戶端后續傳輸信息時，將采用協商好的密鑰和加密套件進行加密傳輸。

(9) 服務器計算已交互的握手信息的Hash值，利用協商好的密鑰和加密套件處理Hash值，并發送給客戶端。客戶端利用同樣的方式計算已交互的握手信息的Hash值，并與服務器傳送過來的信息解密后比較，如果兩者相同，且MAC值驗證成功，則證明密鑰和加密套件協商成功。

圖2　SSL安全傳輸機制握手基礎

在客戶端接收到服務器發送的Hash后，如果解密驗證成功，則可以判斷服務器是數字證書的擁有者，即服務器身份驗證成功。這是因為,只有擁有私鑰的服務器才能從Client Key Exchange消息中解密得到Premaster Secret，從而實現客戶端對服務器的身份驗證。

1.2.2SSL/TLS安全疑慮

2016年3月發布的DROWN(Decrypting RSA with Obsolete and Weakened eNcryption，CVE-2016-0800)漏洞[14]，是利用過時、較弱的一種RSA加密算法來破解取得TLS協議中被該算法加密的溝通密鑰。SSL v2發表于1995年2月，美國政府的管制條例使得SSLv2不得不采用弱化的加密算法。雖然，SSL v2只發表一年就被SSL v3取代，但許多私人服務器端并沒有隨著SSL的更新去改變配置，這導致直至現在依然存在許多支持SSL v2的服務器，當然也包含存在的漏洞。另外，RSA公鑰原始算法利用的是余數計算，如c=memodN，其中(e，N)是算法之公鑰，m是客戶端要發送給服務器端的明文信息，為了確保明文的安全性，客戶端用服務器端的公鑰加密明文m為密文c，只有服務器端的私鑰才能將c解密還原成明文m。但是，像這樣原始的RSA算法的密文，可以被任意篡改且服務器端無法得知。比如，某中間人取得密文c，將其乘以某被公鑰處理過的分數S(S=(1/5)emodN)得到c′，由于c′=Sc=(m/5)emodN，因此服務器用私鑰解密得到的明文m將不是m，而是m除以5。

為改善此情況，SSL v2使用PKCS#1 v1.5規定的padding格式，以試圖讓服務器端可借由在明文中添加驗證字節確保明文的完整性，在服務器端用私鑰解密密文時，就算該密文已被修改過，服務器端也可比對添加的驗證字節來得知明文是否被篡改，若確定已被篡改則被服務器拒絕并回復信息。但是，只是讓服務器端得知是否被篡改，仍無法改變明文已被篡改的事實，并且，這樣的方式依然存在一定的機率，在篡改攔截的密文時不會更動到驗證字節，導致服務器端對密文完整性判斷出現錯誤，誤以為已被篡改的密文沒被篡改。因此，攻擊者利用此現象，通過對服務器發送大量的偽造密文，并根據服務器的大量回復(Yes or No)，即可在大量交互過程中獲得解密信息。

1994年，Bellare-Rogaway提出了RSA Optimal Asymmetric Encryption Padding(OAEP)padding格式。OAEP采用由Shannon提出的對稱式加密算法Substitution-Permutation Network(SP-Network)構造，徹底破壞了原始RSA算法密文與明文之間的乘法相關構造，服務器可以從解密結果明確得知解密的明文是來自于真正的加密者，而非來自于攻擊者；使用OAEP算法，如果服務器判定正確，攻擊者也無法得知發送的偽造密文究竟是Yes還是No，反之服務器如判定解密無效，即可安全終止協議，使攻擊者無法借助大量嘗試取得明文信息。使用RSA OAEP padding后，所有利用乘法相關問題的攻擊技巧全都失效。1998年10月，RSA PKCS#1 v2 padding采用的即是RSA OAEP padding。

Android最初于2007年推出系統第一版，并不會有因為支持較舊的SSL版本而產生的漏洞，而且，Android操作系統還提供SSL/TLS安全傳輸協定的API，支持開發者指定在通信協定使用的算法padding格式，同時也包含OAEP padding格式。如此，開發者可借由對安全傳輸協定指定OAEP padding格式來確保安全傳輸協定密文之完整性，而不會因為前述漏洞的存在導致明文被攻擊者取得。

1.3移動設備管理概述

移動設備管理 (Mobile Device Management, MDM)[6,15]指在公司行政業務范圍內對移動設備，如智慧型手機、平板電腦和筆記型電腦，進行部署、保護、監測、集成和管理。MDM的意圖是優化企業內部移動設備的安全性，確保企業重要信息即使放在員工自行攜帶的移動設備中也能受到適時監控，使企業資訊不會外泄，以提升安全性。

2　系統架構與開發

2.1系統架構

系統由安裝于移動設備上的應用程序Client端以及電腦上的遠程控制Server端所組成，如圖3所示。

圖3　遠程設備控管系統架構

Client端主要進行移動設備的權限管理與連接設定，使用者可以由此部分得知設備上每個應用程序要求的權限，并管理特定應用要求的權限，或以權限名稱為主，管理所有應用程序的特定權限，并可設定待連接Server的信息以實現遠程控制功能。

遠程控制Server端則提供4個操作界面：

(1) “取得信息控制界面”可以顯示移動設備的信息，如Wifi狀態、3G/4G網絡狀態、系統版本和電池狀態，同時可對設備發出警告信息與震動；

(2) “取得位址控制界面”可以借由設備的GPS芯片或行動網絡取得設備所在位址，并利用簡易的地圖顯示出來；

(3) “取得目錄控制界面”可以取得移動設備的檔案系統目錄結構，并可下載設備上的檔案；

(4) “應用權限控制界面”可以遠程管理移動設備某一特定權限，讓設備上所有應用無法取用以確保隱私數據的泄漏。

移動設備第三方應用程序的惡意行為可能取得使用者的隱私數據[16]，但應用程序如需要取得設備上的數據，就必須具有相應權限，故系統借由管理權限來保護設備的隱私信息，并經實測確定可以限制應用程序要求的權限不被取用。

2.2系統開發

系統由跨平臺程序語言Java設計,并針對Android的第三方遠程控制開源軟件AndroRAT(Remote Administration Tool，RAT)修改而成，如表2所示。因為是由Java開發，server平臺只要有支持安裝Java的電腦環境皆可運行；APP端在Eclipse上使用Java結合Android開發工具(Android Developer Tools，ADT)與Google Android APIs開發而成。API中又以AppOpsManager和SSLSocket最為重要。

表2　系統開發與測試環境

AppOpsManager包含Android設備權限管理的所有方法，如表3所示。由于AppOpsManager僅支持SE Android系統環境,僅提供系統應程序取用，故新系統APP端必須運行在Android 4.3以后的版本，利用第三方開源recovery系統備份還原軟件TWRP，將APP端打包成支持Recovery Mode的OTA更新文件格式(*.zip)，安裝至系統應用的目錄下。為了在不修改原始系統的前提下運行TWRP，使用SDK工具包的fastboot指令讓TWRP的鏡像可借由外部儲存區在設備上開啟。然而，在此過程中，設備必須解鎖Bootloader，故只有將其列為研究限制。

SSLSocket API的重要性來源于遠程控制應用程序開源碼在傳送信息時的安全性。將原來僅使用一般傳輸協定Socket修改為附加上SSl安全協定的SSlSocket，使得傳送信息時必須包含密鑰認證，從而可識別Client和Server端的身份，達到預防網絡傳輸時可能發生的中間人攻擊。另外，密鑰可借由Ubuntu操作系統預載工具Keytool，產生長度預設為1 024位的密鑰，若想改變生成密鑰長度，可以借由指令設定。

表3　AppOpsManager權限對照

續表3　AppOpsManager權限對照

3　系統測試與結果

3.1Android 6.0權限管理與新系統

所開發系統能以簡潔的GUI和簡易的操作方法，提供使用者在APP Client端快速管理設備應用程序的權限，也可利用遠程聯機方式，在Server端監控與管理設備的信息與權限。使用者在Android設備上完成APP的OTA安裝后，即可開始使用此系統。相關流程如圖4所示。

圖4　Client系統流程

2015年10月發布的Android 6.0，在系統設定的應用中新增了權限管理功能，其與所開發的新系統的差別如表4所示。

表4　Android 6.0權限管理應用與新系統功能對比

3.2Client端執行結果

APP開始執行時，會出現如圖5(a)所示的執行畫面；使用者只需滑動頁面，選擇被取用的權限類別，分別為LOCATION、PERSONAL、MESSAGING、MEDIA和DEVICE，選擇其中一個應用管理其權限，如圖5(b)所示。

圖5　單一應用權限管理畫面

如果使用者想切換模式,可以點擊主畫面右上的MENU鍵,如圖6所示，主要功能選項分別為PermmissionManager以及RemoteSet兩者。

圖6　模式選擇畫面

當使用者選擇“PermissionManager”選項時，即可進入一次管理所有應用程序特定權限的畫面，或使用者選擇『RemoteSet』選項時，即可設定與遠程server的聯機IP以及Port，如圖7所示。

圖7　應用權限與遠程設定畫面

3.3Server端執行結果

使用者在APP端設定完聯機后，即可在Server端看到聯機的設備以及設備的基本信息,如圖8所示。此時，點擊設備信息的圖標，進入設備管理畫面。管理畫面分別有Home，Permission manager，Map，以及File tree。

進入設備管理畫面,首先會看到Home畫面,如圖9所示。這里顯示當前設備的詳細信息，如Android系統信息、網路連線信息以及設備信息。另外，在這里可以遠程對設備發出警告信息以及震動，當設備遺失時可對拾獲設備的人提出警示信息。

Permission manager畫面顯示了43項行動設備應用程序權限，如圖10所示，以提供管理者對聯機設備上所有應用的特定權限控管。新系統僅提供以權限為主體對設備上所有應用的權限管理，是因為系統Server端可以連接多個設備，且其上的應用也是未知數，如實作針對單一應用的權限管理，可能造成管理者控管權限的困難。

Map畫面和File tree畫面延用原AndroRAT的畫面。Map可以獲取設備由網絡或GPS取得的位址信息，并在畫面的左邊顯示地圖，以方便管理者監控受到控管的行動設備。File tree可以獲取聯機設備的檔案目錄以及下載指定的檔案至設定好的路徑位址，也就是在畫面右下方的文字輸入方塊輸入路徑位址即可。

綜上可見新系統的設計意圖，就是使管理者能保護受到管制的行動設備里的內部資料不被惡意修改，從而提升行動安全。

圖8　遠程Server選擇連接設備畫面

圖9　設備管理的主畫面

圖10　遠程應用權限管理畫面

4　結語

以移動設備管理為基礎，對照Google Android API AppOpsManager所提供的權限項目，開發出一套監控及權限管理系統，可以限制第三方應用可能對設備上隱私數據的竊取或不正當使用；借由修改AndroRAT原始碼的傳輸協定，能使其在傳送信息時確保信息安全，改善系統遠程設備控管的安全性。

設計開發的新系統已能在由美國國家安全局建議與開發的SE Android系統中運作。新系統以遠程權限控管為主軸開發，比市面上的移動設備管理系統呈現出新的功能，但對于完整的保護、監控與集成還需要完善。此外，新系統以新增安全傳輸協定來認證Server身份，并能使信息以加密狀態傳輸，但由于未能讓Server針對Client身份做驗證，可能無法防止攻擊者使用類似拒絕服務(Denial of Service，DoS)攻擊，惡意新增過多的Client會導致Server崩潰。

[1]IDC. Smartphone OS Market Share, 2015 Q2[EB/OL]. [2016-04-03]. http://www.idc.com/prodserv/smartphone-os-market-share.jsp.

[2]GLOBALWEBINDEX. Android mobile now has huge lead over iOS[EB/OL]. [2016-04-03]. http://www.globalwebindex.net/blog/android-mobile-now-has-huge-lead-over-ios.

[3]GARTNER. Mobile Device Security: A Comparison of Platforms[EB/OL].[2016-04-03].https://www.gartner.com/doc/2988420.

[4]GILBERT P, CHUN B G, COX L P, et al. Automated Security Validation of Mobile Apps at App Markets[C/OL]//MCS '11 Proceedings of the second international workshop on Mobile cloud computing and services. New York: ACM, 2011:21-26[2016-04-05].http://dx.doi.org/10.1145/1999732.1999740.

[5]YANG W, XIAO X S, ANDOW B, et al. AppContext: Differentiating Malicious and Benign Mobile App Behaviors Using Context[C/OL〗//2015 IEEE/ACM 37th IEEE International Conference on Software Engineering (Volume:1). Florence: IEEE, 2015:303-313[2016-04-06].http://dx.doi.org/10.1109/ICSE.2015.50.

[6]RHEE K, JEON W, WON D. Security Requirements of a Mobile Device Management System[J/OL]. International Journal of Security and Its Applications, 2012,6(2):353-358[2016-05-01].http://sersc.org/journals/IJSIA/vol6_no2_2012/49.pdf.

[7]LIU L, MOULIC R, SHEA D. Cloud Service Portal for Mobile Device Management[C/OL]//2010 IEEE 7th International Conference on e-Business Engineering (ICEBE).Shanghai:IEEE, 2010, 474-478[2016-05-01].http://dx.doi.org/10.1109/ICEBE.2010.102.

[8]YAGHMOUR K, Embedded Android[M/OL]. Sebastopol: O’Reilly Media, 2013:79-105[2016-05-20].http://www.gbv.de/dms/tib-ub-hannover/684154994.pdf.

[9]VERMEULEN S. SELinux System Administration[M/OL]. Mumbai: Packt Publishing, 2013：7-24[2016-05-05].http://dl.acm.org/citation.cfm?id=2566830.

[10] HAINES R. The SELinux Notebook(4th Edition)[M/OL].[2016-05-05〗. http://freecomputerbooks.com/books/The_SELinux_Notebook-4th_Edition.pdf.

[11] NATIONAL SECURITY AGENCY. SELinux Frequently Asked Questions (FAQ)[EB/OL]. [2016-05-05].https://www.nsa.gov/research/selinux/faqs.shtml.

[12] SMALLEY S, CRAIG R. Security Enhanced (SE) Android: Bringing Flexible MAC to Android[C/OL〗.[2016-05-05]. http://www.internetsociety.org/sites/default/files/02_4.pdf.

[13] ELENKOV N. Android Security Internals[M]. San Francisco: Oreilly & Associates Inc, 2015:349-376.

[14] AVIRAM N, SCHINZEL S, SOMOROVSKY J, et al. DROWN: Breaking TLS using SSLv2[EB/OL]. [2016-06-20]. https://drownattack.com/drown-attack-paper.pdf.

[15] MILLER K W, VOAS J, HURLBURT G F. BYOD: Security and Privacy Considerations[J/OL]. IT Professional, 2012,14(5):53-55[2016-06-06].http://dx.doi.org/10.1109/MITP.2012.93.

[16] BACKES M, BUQIEL S, GERLING S, et al. Android Security Framework: extensible multi-layered access control on Android[C/OL]//ACSAC’14 Proceedings of the 30th Annual Computer Security Applications Conference. New York: ACM, 2014, 46-55[2016-06-06]. http://dx.doi.org/10.1145/2664243.2664265.

[責任編輯:陳文學]

A remote control system for improves the mobile device security based on SE Android

YANG Chunghuang,TUNG Lunming

(Department of Software Engineering and Management, National Kaohsiung Normal University, Kaohsiung 82444, Taiwan)

In order to manage permission systems of mobile devices to protect privacy information from malicious attacks, the Android Open Source Project (AOSP), extensible security framework “SE Android”, is introduced, which is developed by Google and National Security Agency (NSA) together. SE Android provides a security application that supports Android systems of permission management. the seadmin application combined with remote service is modified to form remote control software that provides additional security features as a mobile device management (MDM) system.

mobile devices, mobile device management, permission management, SE Linux, SE Android, system security

2016-07-01

(臺灣)“科技部”資助項目(MOST 102-2221-E-017-003-MY3)

楊中皇 (1958-)，男，博士，教授，從事移動終端安全研究。E-mail: chyang@nknu.edu.tw

董倫銘(1990-)，男，碩士研究生，研究方向為網絡信息安全。E-mail: k49918135@gmail.com

10.13682/j.issn.2095-6533.2016.05.001

TP309

A

2095-6533(2016)05-0001-10