ISSN 1598-0170 (Print) ISSN 2287-1136 (Online) http://www.jksii.or.kr 모바일앱최소권한사전검증에관한연구 - 금융, 안드로이드운영체제중심으로 - A Study of Security Checks for Android Least Privilege - focusing on mobile financial services - 조병철 1 최진영 1* Byung-chul Cho Jin-young Choi 요 약 안드로이드운영체제의보안체계는샌드박스와권한모델을적용하고있다. 특히권한모델은설치시점확인과 all-or-nothing 정책을운영하고있기때문에안드로이드는앱을설치할때필요한권한에대해사용자동의를요구하고있다. 하지만안드로이드권한에대한사용자의인식은부족한상황이다. 따라서본논문에서는실제모바일앱을대상으로권한요구실태를조사하고금융회사를중심으로모바일서비스제공자가모바일앱의최소권한정책에위배되는사항을자체점검하고자할때활용가능한중점점검항목과방법을제시하고그유용성에대해알아보고자한다. 주제어 : 모바일보안, 안드로이드보안, 퍼미션, 최소권한 ABSTRACT A security system in Android OS adopts sandbox and an permission model. In particular, the permission model operates the confirmation of installation time and all-or-nothing policy. Accordingly, the Android OS requires a user agreement for permission when installing an application, however there is very low level of user awareness for the permission. In this paper, the current status of permission requirement within mobile apps will be discovered, and the key inspection list with an appropriate method, when a mobile service provider autonomously inspects the violation of least privilege around financial companies, and its usefulness will be explored. keyword : mobile security, android security, permissions, least privilege 1. 서론 시장조사전문기관인 IDC 발표자료에따르면 2015 년 2분기에안드로이드 OS는세계스마트폰 OS 시장에서 82.8% 의점유율을차지하였다 [1]. 또한 2014년 1분기에는새로운보안위협 (277개) 가운데 99% 이상이안드로이드플랫폼에서발생했을정도로안드로이드에대한보안위협은지속되고있는상황이다 [2]. 한편안드로이드는다양한보안위협에대응하기위해샌드박스, 권한모델등의보안정책을운영하고있다 [3]. 특히권한모델은설치시점확인과 all-or-nothing 정책을적용하고있기때문에자원접근에필요한권한에대 1 CIST(Center for Information Security Technologies), Korea University, Seoul, 136-713, Korea * Corresponding author (choi@formal.korea.ac.kr) [Received 7 November 2015, Reviewed 16 Novemver 2015, Accepted 3 December 2015] 해사용자동의를요구하고있다. 하지만 Felt 등 [4] 은온라인 (308명) 과오프라인 (25명) 실험을통해서안드로이드권한 (permission) 에대한사용자들의인식이부족하다는사실을보여주었다. 방송통신위원회도이와같은문제점을인지하고스마트폰앱개인정보보호가이드라인을통해앱이이용자의스마트폰정보에접근할수있는권한의범위를서비스에필요한범위내로최소화하도록요구하였고 [5] 금융감독원은금융회사에게개발단계부터스마트폰앱에접근권한이불필요한항목이포함되지않도록개발하여배포하고운영중인앱에대해서도일제히점검하여불필요한접근권한을즉시삭제하도록요구하였다 [6]. 그러나감독당국의요구대로모바일서비스제공자가최소권한 (least privilege) 원칙을준수하기위한현실적인대안은마땅하지않은것이현실이다. 이에따라본연구에서는안드로이드권한시스템에관한몇가지의문점을가지고실태를조사하였다. Journal of Internet Computing and Services(JICS) 2016. Feb.: 17(1): 91-99 91 http://dx.doi.org/10.7472/jksii.2016.17.1.91
사용자에게동의를요구하는권한은주로어떠한것들인가? 금융회사업종에따라요구하는권한별특징이분류되는가? 금융회사등모바일서비스제공자가최소권한원칙준수여부를자체점검하고자할때활용할수있는중점점검권한도출이가능한가? 자체점검시활용가능한도구는유용한가? 이를위해 3장에서는리버싱기법을통한권한요구현황분석방법을소개하고 4장에서는실제구글플레이에등록된금융분야모바일앱을대상으로분석을실시하고자한다. 이를통해향후모바일서비스제공자가자율점검수행시활용가능한중점점검항목을도출하여도구를통한점검방법의효과성에대해알아보고 5~6장에서는최소권한원칙준수를위한개선방안과관련연구및향후계획에대해서술하고자한다. 2.2 안드로이드권한안드로이드는단말의자원에접근이필요한모든권한을 AndroidManifest.xml 파일에정의해야한다. 사용자는앱을설치할때요청된권한목록을확인하고동의하는절차를거치게되며앱이삭제되기전까지요청된모든권한은유지된다. 다만, 의도한기능이필요하지않을때에도자원에접근이허용된다는단점을가진다 [3]. 안드로이드는 2009년 API레벨1의플랫폼버전 1.0을시작으로현재 API레벨23의 6.0까지출시되었으며그림 1에서보는바와같이 API레벨3의권한은 103개였던것이가장최근버전인 API레벨23에서는 309개까지증가하였다 [8]. 안드로이드권한은 Protection Level과 Permission Group으로구성된다. 2. 연구배경 2.1 안드로이드보안체계 안드로이드는대표적으로다음과같은보안기능을제 공한다 [3]. 1. 샌드박스 * : 안드로이드에설치된응용프로그램은기본적으로일반사용자권한으로실행된다. 각앱은고유의사용자아이디와그룹아이디를부여받으며앱간의접근은기본적으로불가하다. 만약다른앱과데이터공유가필요하다면명시적인정의가필요하다. 2. 권한모델 : 안드로이드는권한에따라단말기자원에대한접근을제한하도록하고있으며이러한제약은사용자나시스템에대해위험도가높은것으로한정된다. 앱의권한들은안드로이드에이미내장되어있으나개발자가새로운권한을설정할수도있다. 개발자가사용할수있는권한들은안드로이드공식개발자사이트에서확인할수있다 [7]. 3. 서명 : 서명되지않은앱은안드로이드기기에설치되지못하도록통제하고안드로이드마켓에업로드할때반드시개발자개인키 (private key) 로서명하도록강제한다. * 샌드박스 : 외부로부터들어온프로그램이보호된영역에서동작해시스템이부정하게조작되는것을막는보안형태이다. ( 그림 1) API 레벨의권한수 (Figure 1) Number of permissions for API level 2.1.1 Protection Level 각각의권한들은위험도에따라 Normal, Dangerous, Signature, SinatureOrSystem의 4단계로구분된다 [3]. 1. Normal : 위험이낮은권한으로사용자의승인없이도자동적으로권한이허용되며사용자는허용된권한에대해확인이가능하다. 2. Dangerous : 위험이높은권한으로사용자의승인을득한경우에만권한이허용된다. 3. Signature : 가장높은단계의권한으로단말기제조사의인증서로서명이필요하며사용자에게별도 92 2016. 2
안내없이설치된다. 4. SignatureOrSystem : 시스템이미지에있거나시스템이미지에있는동일서명이필요하며사용자에게별도안내없이설치된다. 2.1.2 Permission Group 안드로이드시스템의모든 dangerous 권한은반드시어느하나의권한그룹과연결되며그룹분류는표1과같다 [9]. 만약앱에서 dangerous 권한이필요한데이미동일그룹에속해있는권한에대해사용자동의를받았다면별도사용자동의를요구하지않고권한을허용해준다. 만약 READ_CONTACTS 권한이이미허용된상태라면 WRITE_CONTACTS 권한요청도같이허용된다. ( 표 1) 안드로이드권한그룹 (Table 1) Android Permission Group Permission Group Description CALENDAR Used for runtime permissions related to user's calendar. Used for permissions that are CAMERA associated with accessing camera or capturing images/video from the device. CONTACTS Used for runtime permissions related to user's contacts and profile. LOCATION Used for permissions that allow accessing the device location. Used for permissions that are MICROPHONE associated with accessing microphone audio from the device. PHONE Used for permissions that are associated telephony features. Used for permissions that are SENSORS associated with accessing camera or capturing images/video from the device. SMS Used for runtime permissions related to user's SMS messages. STORAGE Used for runtime permissions related to the shared external storage. 2.3 관련연구 구하는권한과실제앱에서사용되는 API가요구하는권한을비교한결과 940의앱중 1/3이상의앱이필요이상의권한을요구한다는사실을확인하였고 [16] 앱에서불필요한권한을요구하는지를점검하는 Stowaway 도구를통해안드로이드 API와권한간의연관정보를조사하였으나더이상해당도구는현재의앱들을제대로분석해내지못한다 [17]. Enck 등 [18] 은앱이설치될때해당앱이요구하는권한과권한규칙을비교하여앱의보안을평가하는시스템인 Kirin을제안하였다. 사용자가앱을설치할때간단하게 9가지샘플규칙을통해악의적인것으로의심되는권한정보를제시하였으나금융앱에서는오탐에해당하는것이많았다. Vidas 등 [19] 은안드로이드문서를검사하여권한명세에대해조사하고개발자가필요한권한과불필요한권한을알수있도록플러그인형태의개발자지원도구를제시하였지만아직개념검증용으로실제활용은제한적이었다. Wei 등 [20] 은안드로이드권한시스템의발전과사용에대한조사를통해보호수준이 dangerous인앱이증가하고있으며그것이불필요한권한을요구하는앱과연관성이있음을확인하고개발자에게해당보호수준을사용할때에는더욱주의해야한다고강조하였다. 앞서살펴본바와같이안드로이드권한을중심으로다양한연구는계속되고있으나실제업무에활용가능한안드로이드최소권한사전검증방안에대한연구는확인되지않았다. 따라서본논문에서는모바일서비스제공자가서비스시작이전에최소권한원칙준수여부를자율적으로점검하기위한방안에대해금융회사업종에따른특징분류관점에서연구하고자한다. 3. 권한요구현황분석방법 3.1 개요본연구에서는실제모바일앱에서요구하고있는권한들에대한현황을파악하기위해개발자가앱에명시적으로정의한권한정보와실제프로그램의소스코드에서사용되는권한정보들을리버싱도구를활용하여분석을수행하였다. 안드로이드권한과관련한기존연구는다음과같다. Felt 등은모바일앱을분석하여앱이사용자동의를요 한국인터넷정보학회 (17 권 1 호 ) 93
3.2 개발자가정의한권한정보추출앱실행시요구되는개발자정의권한정보를추출하기위해서는 AndroidManifest.xml 파일을확인해야한다. 먼저 APK의압축을해제하면 AndroidManifest.xml 파일을추출할수있으나이는컴파일된형태이기때문에다시변환작업을수행해야한다. 이러한일련의작업은 apktool[10] 을활용하여자동화된방법으로 AndroidManifest.xml 파일을추출할수있다. 또한 androaxml[11] 도 AndroidManifest.xml 파일의내용을바로화면에출력해주는기능을제공하며 aapt[12] 는 AndroidManifest.xml에정의된정보이외에도패키지정보, 권한정보등을화면상에함께출력해준다. 그림2는 Androaxml를이용하여앱에서요구하고있는권한을추출한결과이다. 본논문에서는 Androguard를이용하여 APK 파일로부터권한정보를추출하였다. 그림3은 Androlyze를이용하여 API와권한정보를추출한결과이다. ( 그림 3) Androlyze 를이용한권한조회 (Figure 3) Extracting permission from api using Androlyze 참고로 Androlyze는그림4와같이 API와권한정보에대한연관관계를별도파일로관리하기때문에오탐에대한수정및보완이가능하다. 미탐으로확인된 API 에대한권한정보를해당파일에등록하게되면추후점검시에는점검결과에포함되어출력된다. ( 그림 2) Androaxml 를이용한권한조회 (Figure 2) Extracting permission from Androidmanifest using Androaxml 3.3 프로그램에서사용되는권한정보추출 실제앱에서사용되는권한정보를추출하기위해서는소스코드의 API를추출하고각권한과 API간의연관관계를알아야한다. 소스코드의 API는 dex2jar[13] 를통해 APK 파일을자바클래스파일로변환하고 jad[14] 를통해다시자바파일로디컴파일하여문자열검색등을통해확인할수있다. 또한 API에서요구하는권한은 pscout[15] 에제시된 mapping 자료를통해확인이가능하다. ( 그림 4) API 와권한연결정보 (Figure 4) Mapping between api and permission 94 2016. 2
3.4 개발자정의권한과실제사용권한비교개발자가정의한권한정보와프로그램에서사용되는권한정보를비교하기위해그림5와같이점검결과형식을정규식을통해표준화하고문자열비교도구인 diff를사용하여권한을비교하였다. 라이브러리가아닌자체적으로개발한코드라면해당코드에대한제거를검토해볼수있다. ( 그림 6) 정의된권한 vs 사용권한 (Figure 6) Comparing permission between predefined and program required ( 그림 5) 권한비교프로토타입 (Figure 5) Prototype about comparing permissions 4. 실험및평가 그림6은개발자정의권한과프로그램사용권한에대한비교결과이다. 먼저좌우측에서공통적으로확인된권한으로 ACCESS_NETWORK_STATE, ACCESS_WIF I_STATE, INTERNET, READ_CONTACTS, READ_P HONE_STATE, RESTART_PACKAGES는개발자가정의한권한이실제프로그램에서사용되는것으로올바른권한정의에해당한다. 즉사용자동의를요청한모든권한이실제프로그램사용시필요한권한임을나타낸다. 한편 CALL_PHONE, CHANGE_NETWORK_STATE, MODIFY_PHONE_STATE, READ_EXTERNAL_STOR AGE, WRITE_EXTERNAL_STORAGE 등과같이좌측에서만보이는권한들은프로그램에서사용되지않으나사용자동의를요구하는것으로불필요권한일가능성이존재하는것들이다. 반대로 ACCESS_FINE_LOCATION, CAMERA, FAC TORY_TEST, NFC, READ_LOGS, RECORD_AUDIO, VIBRATE, WAKE_LOCK와같이우측에서만보이는권한들은프로그램소스에는존재하지만실제프로그램동작시에는사용되지않는권한들로보안적인이슈를떠나향후에도계속사용되지않는코드에해당하고서드파티 4.1 실험데이터실험은구글플레이의금융범주에등록된인기앱가운데 448개를대상으로선정하여분석을진행하였다. 실험대상에는스마트폰뱅킹등전자금융거래를위한앱부터가계부와같은일반앱까지다양하게포함되어있다. 4.2 실험평가 4.2.1. RQ1 : 사용자동의를요구하는권한안드로이드는보호수준이 dangerous에해당하는경우사용자로부터해당권한에대한승인을요구한다. 표2는사용자동의를요구하는권한중상위 20개를나열한것으로 70% 이상의앱이 INTERNET( 인터넷등네트워크접속허용 ), WRITE_EXTERNAL_STORAGE( 외부저장장치쓰기허용 ), READ_PHONE_STATE( 폰상태읽기허용, IMEI, IMSI, 폰번호, 통화중상태등 ) 권한을요구하고있었다. 이외에도전화걸기, 위치정보접근, SMS 읽기 / 보내기, 카메라, 연락처읽기등다양한개인정보관련권한들이 10% 이상의앱에서요구되는것으로나타났다. 한국인터넷정보학회 (17 권 1 호 ) 95
( 표 2) 사용자동의요구권한상위 20 개 (Table 2) The top 20 most frequent dangerous permissions Permissions Usage(%) INTERNET 98.4 WRITE_EXTERNAL_STORAGE 82.4 READ_PHONE_STATE 72.5 GET_TASKS 50.4 CALL_PHONE 37.5 CHANGE_WIFI_STATE 34.2 ACCESS_FINE_LOCATION 29.0 RECEIVE_SMS 26.6 CAMERA 24.6 ACCESS_COARSE_LOCATION 23.4 READ_CONTACTS 13.4 DISABLE_KEYGUARD 11.6 READ_SMS 10.9 SYSTEM_ALERT_WINDOW 9.8 SEND_SMS 9.4 USE_CREDENTIALS 8.9 NFC 7.8 ACCESS_MOCK_LOCATION 7.4 READ_CALL_LOG 6.3 RECORD_AUDIO 5.4 4.2.2. RQ2 : 금융회사업종별요구권한특징 사용자동의를요구하는권한을대상으로금융회사업종별에따라분류해본결과그림7과같이보호수준이 dangerous인권한에대해앱별평균개수는은행이 8.5 개로가장많았고카드, 캐피탈, 증권, 새마을금고, 증권, 보험순이었다. 이에반해보호수준전체를대상으로할경우에는카드가 18개로가장많았고증권, 은행, 새마을금고, 캐피탈, 저축은행, 보험순으로확인되었다. 표3은사용자동의를요구하는권한의세부항목전체를대상으로금융회사주요업종중심으로살펴보았다. 은행이 31개로가장많은유형의권한을요구하였고그다음으로는카드, 보험, 증권순이었다. 특히증권은 READ_SMS, READ_CONTACTS, WRITE_CONTACTS 등을요구하지않고타업종에비해요구하는권한유형이상대적으로적었으며카드는연락처쓰기 (WRITE_C ONTACTS) 를허용하지않았다. 보험은일정읽기 / 쓰기 (READ_CALENDAR / WRITE_CALENDAR) 를허용하지않는것으로확인되었다. ( 그림 7) 금융업종별요구권한앱별평균개수 (Figure 7) The average number of permissions by financial sector 4.2.3. RQ3 : 자체점검시중점점검권한목록 표3을통해금융회사업종별로차이가있음을확인하였고이에따라은행과카드는 31개, 보험은 28개, 증권은 19개의요구권한목록을도출할수있었다. 금융회사등모바일서비스제공자는해당업종별요구권한목록을기준으로중점점검권한체크리스트를작성하고이를토대로향후자체점검을수행하고자할때최소권한의여부에대해화이트리스트방식으로효율적인점검을수행할수있다. 4.2.4. RQ4 : 자체점검도구및방법 3장에서소개된방법에따라도구를활용한자체점검을수행하여개발자가정의한권한정보와프로그램에서요구하는권한정보를비교한결과그림8과같이저축은행이 47% 로가장많은감소효과가있었고새마을금고, 은행, 증권, 카드, 캐피탈, 보험순으로효과가확인되었다. 업종에상관없이 448개전체앱을대상으로평균적으로는 43.1% 의점검대상권한목록을줄이는효과가있었다. 100% 감소효과를나타난앱은 14개였고 50% 이상은 195개였다. 점검대상권한의감소효과와불필요권한검출에대한점검도구의효과성을확인하기위해사례연구로생명보험사인 A사를대상으로추가적인검토를진행하였다. 앞서살펴본바와같이그림6은 A사의모바일앱을대상으로불필요권한에대한점검을수행한결과이다. 96 2016. 2
( 그림 8) 금융업종별점검대상감소율 (Figure 8) Reduction ratio of permissions for audit by financial sector 점검결과에서좌우측에서공통적으로확인된 INTER NET 등 6개권한은실제앱에서사용되는필요권한으로 AndroidManifest.xml에정의된 18개권한중해당권한에대해서는점검대상권한목록에서제외처리하였다. 이를통해 A사의경우점검대상이 18개에서 12개로 33% 감소효과가있었다. 또한나머지 12개권한중점검대상권한을보호수준이 dangerous 인것으로한정하여다시점검대상의범위가 4개로축소되었다. 최종적으로불필요권한으로의심되는 CALL_PHONE 등 4개의권한에대해서개발자와인터뷰를진행한결과 CALL_PHONE의경우앱에서실제고객센터안내번호를클릭하면사용자가전화번호를별도로누르지않고바로전화를연결하기위해필요하였고 WRITE_EXTER NAL_STORAGE의경우상품안내장 PDF 파일을내려받는기능에서사용하기위해필요하였다. GET_TASKS와 USE_CREDENTIALS 은서드파티에서사용하는기능으로확인되었다. A사의경우는 4개가모두필요한권한으로확인되었고도구를통한점검결과는오탐으로확인되었다. ( 표 3) 금융앱에서요구되는권한 (Table 3) Permissions requested by financial sector Permissions Bank Card Insu rance Secu rities INTERNET 57 34 36 45 WRITE_EXTERNAL_STORAGE 57 32 27 42 READ_PHONE_STATE 55 34 26 42 Permissions Bank Card Insu rance Secu rities GET_TASKS 48 21 20 39 CHANGE_WIFI_STATE 30 15 17 28 ACCESS_FINE_LOCATION 25 12 19 19 CALL_PHONE 35 23 22 15 ACCESS_COARSE_LOCATION 16 11 17 15 DISABLE_KEYGUARD 5 9 1 12 SYSTEM_ALERT_WINDOW 7 5 2 11 ACCESS_MOCK_LOCATION 5 1 7 10 SEND_SMS 7 3 3 9 RECEIVE_SMS 21 17 11 7 CAMERA 33 13 11 4 READ_CALENDAR 2 1 3 WRITE_CALENDAR 2 1 3 USE_CREDENTIALS 3 8 4 2 BLUETOOTH 4 6 2 2 RECORD_AUDIO 2 4 2 2 READ_CONTACTS 16 2 4 WRITE_CONTACTS 5 3 BLUETOOTH_ADMIN 3 6 2 NFC 8 11 1 READ_SMS 10 2 1 PROCESS_OUTGOING_CALLS 3 2 1 CHANGE_WIFI_MULTICAST_ STATE 2 2 1 MANAGE_ACCOUNTS 1 1 AUTHENTICATE_ACCOUNTS 1 1 READ_CALL_LOG 12 1 ACESS_MOCK_LOCATION 1 BATTERY_STATS 2 1 SMARTCARD 1 READ_PROFILE 1 SET_ANIMATION_SCALE 1 WRITE_CALL_LOG 4 WRITE_SMS 2 RECEIVE_MMS 1 합계 31 31 28 19 5. 개선방안 모바일서비스제공자는개발단계부터모바일앱에불필요한접근권한항목이포함되지않도록하고운영중인앱에대해서도불필요한접근권한을즉시삭제하도록해야한다. 이를위해 4장에서제시한업종별중점점검권한목록을참조하여해당회사에적합한권한체크리스트를작 한국인터넷정보학회 (17 권 1 호 ) 97
성하고자체보안성검토등모바일앱에대한자체점검시이를활용하여점검을수행해야한다. 또한서비스가신규로개발되거나변경될때권한체크리스트에해당사항을반영하여지속적으로현행화해야한다. 둘째, 모바일앱에대한자체점검은통제부서뿐만아니라개발자도 3장에서제시한방법과도구를활용하여사용자동의를요구하는권한과프로그램에서실제사용되는권한에대한가시성을확보해야한다. 이를통해점검대상이되는권한의범위를축소하여점검작업의효율성을제고할수있다. 셋째, 모의해킹점검시점검체크리스트에안드로이드권한에대한검토활동을추가하여주기적인검토가수행될수있도록절차화해야한다. 6. 결론 본논문에서는실제구글플레이에등록된안드로이드앱을대상으로사용자승인을요구하는권한에대한현황을금융회사업종에따른요구권한특징분류관점에서조사하였다. 그리고금융회사등모바일서비스제공자가앱의최소권한원칙을준수하는지자체점검수행시활용가능한권한점검항목을제시하였다. 또한실제구글플레이에등록된금융관련앱을대상으로오픈소스도구를통한자체점검방법을수행한결과점검대상권한목록이평균적으로 43.1% 감소된것으로나타나최소권한여부를효율적으로점검하는데있어보조도구로서의유용성을확인하였다. 그러나 A사의사례에서살펴본바와같이 3장에서소개한점검도구를불필요권한을검출하기위한용도로활용하기에는오탐등으로인해아직은어려움이있는것으로확인되었다. 향후에는 Androguard 도구등을통한자체점검시점검대상범위효율성제고를목표로하여특히금융분야모바일에서보편적으로사용되는다양한서드파티 (3 rd party) 라이브러리를중심으로안드로이드 API와권한간의연결정보에대해연구하고자한다. 참고문헌 (Reference) [1] IDC, Smartphone OS Market Share, 2015 Q2, http://www.idc.com/prodserv/smartphone-os-market-sha re.jsp, 2015. [2] Q1 2014 MobileThreatReport, http://www.f-secure.com/weblog/archives/00002699.ht ml, 2014 [3] KISA, Analysis of Android Mobile Platform Security Model, Aug. 2010. [4] Adrienne Porter Felt, Elizabeth Hay, Serge Egelman, Ariel Haney, Erika Chin, and David Wagner. "Android permissions: User attention, comprehension, and behavior," In Proceedings of Symposium on Usable Privacy and Security, 2012. [5] Korea Communication Commission, Guidelines for privacy protection on smart phone application, Aug. 2015. [6] Financial Supervisory Service, Required implementation of privacy information leak prevention for smartphone app, Aug. 2015. [7] Google Android Developers Official Site, http://developer.android.com/reference/android/manifest.permission.html, 2015. [8] Android Full Source Android Manifest File, https://android.googlesource.com/platform/frameworks/ base/+/.../core/res/androidmanifest.xml, 2015. [9] Android-defined Permission Category, http://developer.android.com/reference/android/manifest.permission_group.html, 2015 [10] A tool for reverse engineering Android apk files, http://ibotpeaches.github.io/apktool [11] Reverse engineering, Malware and goodware analysis of Android applications, https://code.google.com/p/androguard/wiki/re#permissi ons [12] Android Asset Packaging Tool, http://elinux.org/android_aapt [13] Tools to work with android.dex and java.class files, http://sourceforge.net/projects/dex2jar [14] Jad Decompiler, http://www.javadecompilers.com/jad [15] K. W. Y. Au, Y. F. Zhou, Z. Huang, and D. Lie, Pscout: analyzing the android permission specification, In Proceedings of the 2012 ACM conference on Computer and communications security, pp 217-228. Oct. 2012. [16] A. P. Felt, K. Greenwood, and D. Wagner. The effectiveness of application permissions, in Proceedings ofthe USENIX Conference on Web Application Development, 2011. 98 2016. 2
[17] A. P. Felt, E. Chin, S. Hanna, D. Song, and D. Wagner. Android permissions demystified, In Proceedings of the18th ACM conference on Computer andcommunications security, pages 627 638. ACM, 2011. [18] W. Enck, M. Ongtang, and P. McDaniel. On lightweight mobile phone application certification, in Proceedings of the 16th ACM conference on Computer and communications security, 2009. [19] T. Vidas, N. Christin, and L. Cranor. Curbing androidpermission creep, In Proceedings of the Web, volume 2, 2011. [20] Xuetao Wei, Lorenzo Gomez, Lulian Neamtiu, Michalis Faloutsos, Permission Evolution in the Android Ecosystem, Dec, 2012. 저자소개 조병철 (Byung-chul Cho) 2005 년숭실대학교컴퓨터학부 ( 학사 ) 2014~ 현재고려대학교정보보호대학원금융보안학과석사과정관심분야 : 전자금융보안, 정보보호정책, SW 개발보안, 금융 IT 감리, etc. E-mail : jokun@naver.com 최진영 (Jin-young Choi) 1982 년서울대학교컴퓨터학과 ( 학사 ) 1986 년 Drexel University Dept. of Mathematics and Computer( 석사 ) 1993 년 University of Pennsylvania Dept. of Computer and Information Science( 박사 ) 1993~1996 년 : Research Associate. University of Pennsylvania 1996~1999 년 : 고려대학교컴퓨터학과조교수 1999~2004 년 : 고려대학교컴퓨터학과부교수 2004~ 현재 : 고려대학교컴퓨터 전파통신공학부교수관심분야 : 정형기법, 임베디드실시간시스템, 프로그래밍언어, 프로세스대수, 소프트웨어공학, etc. E-mail : choi@formal.korea.ac.kr 한국인터넷정보학회 (17 권 1 호 ) 99