楊中皇, 董倫銘

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

?

基于SE Android結合遠程控制提升移動系統(tǒng)安全性

楊中皇, 董倫銘

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

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

移動設備；移動設備管理；權限管理；安全加強Linux；SE Android；系統(tǒng)安全

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

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

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

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

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

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

1　SE Android與移動設備管理

1.1SE Android作業(yè)系統(tǒng)概述

1.1.1Android Open Source Project

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

1.1.2Android安全增強內容

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

圖1　SE Android系統(tǒng)架構

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

表1　SE Android修改的屬性

1.1.3Recovery模式與OTA更新

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

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

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

1.2Android SSL/TLS安全通信協(xié)定

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

1.2.1SSL/TLS安全通信基礎

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

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

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

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

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

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

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

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

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

(9) 服務器計算已交互的握手信息的Hash值，利用協(xié)商好的密鑰和加密套件處理Hash值，并發(fā)送給客戶端?？蛻舳死猛瑯拥姆绞接嬎阋呀换サ奈帐中畔⒌腍ash值，并與服務器傳送過來的信息解密后比較，如果兩者相同，且MAC值驗證成功，則證明密鑰和加密套件協(xié)商成功。

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

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

1.2.2SSL/TLS安全疑慮

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

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

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

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

1.3移動設備管理概述

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

2　系統(tǒng)架構與開發(fā)

2.1系統(tǒng)架構

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

圖3　遠程設備控管系統(tǒng)架構

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

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

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

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

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

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

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

2.2系統(tǒng)開發(fā)

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

表2　系統(tǒng)開發(fā)與測試環(huán)境

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

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

表3　AppOpsManager權限對照

續(xù)表3　AppOpsManager權限對照

3　系統(tǒng)測試與結果

3.1Android 6.0權限管理與新系統(tǒng)

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

圖4　Client系統(tǒng)流程

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

表4　Android 6.0權限管理應用與新系統(tǒng)功能對比

3.2Client端執(zhí)行結果

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

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

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

圖6　模式選擇畫面

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

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

3.3Server端執(zhí)行結果

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

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

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

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

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

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

圖9　設備管理的主畫面

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

4　結語

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

設計開發(fā)的新系統(tǒng)已能在由美國國家安全局建議與開發(fā)的SE Android系統(tǒng)中運作。新系統(tǒng)以遠程權限控管為主軸開發(fā)，比市面上的移動設備管理系統(tǒng)呈現(xiàn)出新的功能，但對于完整的保護、監(jiān)控與集成還需要完善。此外，新系統(tǒng)以新增安全傳輸協(xié)定來認證Server身份，并能使信息以加密狀態(tài)傳輸，但由于未能讓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-)，男，碩士研究生，研究方向為網(wǎng)絡信息安全。E-mail: k49918135@gmail.com

10.13682/j.issn.2095-6533.2016.05.001

TP309

A

2095-6533(2016)05-0001-10