Kiểm tra ứng dụng trên điện thoại di động android bằng kiểm tra mô hình

ĐẠI HỌC QUỐC GIA TP HCM TRƯỜNG ĐẠI HỌC BÁCH KHOA NGUYỄN THANH HỒNG KIỂM TRA ỨNG DỤNG TRÊN ĐIỆN THOẠI DI ĐỘNG ANDROID BẰNG KIỂM TRA MƠ HÌNH Chuyên ngành: KHOA HỌC MÁY TÍNH Mã số: 60.48.01 LUẬN VĂN THẠC SĨ TP HỒ CHÍ MINH, tháng 06 năm 2013 CƠNG TRÌNH ĐƯỢC HỒN THÀNH TẠI TRƯỜNG ĐẠI HỌC BÁCH KHOA ĐẠI HỌC QUỐC GIA TP HỒ CHÍ MINH Cán hướng dẫn khoa học: PGS.TS QUẢN THÀNH THƠ Cán chấm nhận xét 1: …TS NGUYỄN CHÁNH THÀNH Cán chấm nhận xét 2: …TS BÙI HOÀI THẮNG Luận văn thạc sĩ bảo vệ trường Đại Học Bách Khoa, ĐHQG Tp HCM ngày 24 tháng 07 năm 2013 Thành phần Hội đồng đánh giá luận văn thạc sĩ gồm: 1…TS HUỲNH TƯỜNG NGUYÊN ……… 2…TS NGUYỄN ĐỨC THÁI ……….……… 3…TS NGUYỄN CHÁNH THÀNH….……… 4…TS BÙI HOÀI THẮNG ………….……… 5…TS NGUYỄN THỊ MINH TUYỀN.……… Xác nhận Chủ tịch Hội đồng đánh giá Luận Văn Trưởng Khoa quản lý chuyên ngành sau luận văn sửa chữa (nếu có) CHỦ TỊCH HỘI ĐỒNG TRƯỞNG KHOA………… ĐẠI HỌC QUỐC GIA TP.HCM TRƯỜNG ĐẠI HỌC BÁCH KHOA CỘNG HÒA Xà HỘI CHỦ NGHĨA VIỆT NAM Độc lập - Tự - Hạnh phúc NHIỆM VỤ LUẬN VĂN THẠC SĨ Họ tên học viên: NGUYỄN THANH HỒNG MSHV:09070438 Ngày, tháng, năm sinh: 20/11/1982 Nơi sinh: TP HCM Chuyên ngành: KHOA HỌC MÁY TÍNH Mã số : 60.48.01 I TÊN ĐỀ TÀI: KIỂM TRA ỨNG DỤNG TRÊN ĐIỆN THOẠI ANDROID BẰNG KIỂM TRA MƠ HÌNH II NHIỆM VỤ VÀ NỘI DUNG: 1) Hiện thực module kiểm tra vài tính chất chương trình Android phương pháp kiểm tra mơ hình cơng cụ PAT 2) So sánh hiệu hai kĩ thuật on-the-fly khơng on-the-fly thực kiểm tra mơ hình III NGÀY GIAO NHIỆM VỤ : 21/01/2013 IV NGÀY HOÀN THÀNH NHIỆM VỤ: 21/06/2013 V CÁN BỘ HƯỚNG DẪN : PGS.TS QUẢN THÀNH THƠ Tp HCM, ngày 21 tháng 06 năm 2013 CÁN BỘ HƯỚNG DẪN CHỦ NHIỆM BỘ MÔN ĐÀO TẠO (Họ tên chữ ký) (Họ tên chữ ký) TRƯỞNG KHOA….……… (Họ tên chữ ký) i LỜI CẢM ƠN Tôi xin gửi lời cảm ơn chân thành đến PGS TS Quản Thành Thơ, người thầy hướng dẫn cho tơi hồn thành luận văn người giảng dạy cho tơi q trình học Cao Học Tơi xin gửi lời cảm ơn đến TS Bùi Hồi Thắng, bạn Hà Xuân Lĩnh, Lê Đình Thuận, Nguyễn Hữu Vũ, Châu Vĩnh Tuân, người hỗ trợ tích cực cho tơi q trình làm luận văn Tôi xin gửi lời cảm ơn đến đồng nghiệp cơng ty Tường Minh gia đình tơi, người ủng hộ tạo điều kiện để tơi hồn thành luận văn ii TĨM TẮT LUẬN VĂN Các ứng dụng Android có nhiều lỗi bảo mật Những rắc rối cho người dùng thông tin cá nhân họ bị chuyển cho nhà quảng cáo, gọi bị nghe lén, điện thoại tự động gửi nhiều tin nhắn dẫn đến thiệt hại tài cho người dùng,… vấn đề phổ biến Một nguyên nhân lỗi bảo mật cho người phát triển ứng dụng không áp dụng chế bảo mật dựa phân quyền hệ điều hành Android cách đầy đủ xác Đề tài nhằm kiểm tra lỗi rò rỉ chức (capability leaks) ứng dụng, cách áp dụng phương pháp kiểm tra mơ hình Chúng tơi thử nghiệm nhận thấy kết thực kiểm tra mơ hình phương pháp on-the-fly tốt phương pháp kiểm tra mơ hình thơng thường iii ABSTRACT Android applications have been found to contain many kinds of security holes, which may be serious to leave smartphone users at risks of various attacks, such as privacy loss (user’s information is passed to adversories), eavesdropping, financial loss (SMS messages are sent out uncontrolledly which financially impacts to users) Among various root causes of these attacks, that Android security mechanism is not correctly enforced and results in some kinds of leaks in the application, is supposed to be one of the basic root causes Our thesis proposes the on-the-fly LTL model checking approach to verify capability leaks in Android application We also performed experiments and found that on-the-fly approach results in better performance than normal approaches iv LỜI CAM ĐOAN Tôi cam đoan rằng, ngoại trừ kết tham khảo từ cơng trình khác ghi rõ luận văn, cơng việc trình bày luận văn tơi thực chưa có phần nội dung luận văn nộp để lấy cấp trường trường khác Ngày….21….tháng…06…năm…2013… Nguyễn Thanh Hồng v MỤC LỤC NHIỆM VỤ LUẬN VĂN THẠC SĨ i LỜI CẢM ƠN ii TÓM TẮT LUẬN VĂN iii ABSTRACT iv LỜI CAM ĐOAN v MỤC LỤC vi DANH MỤC HÌNH ix DANH MỤC BẢNG x Chương 1: Phát biểu vấn đề 1.1 Những vấn đề bảo mật điện thoại Android 1.2 Các phương pháp giải 1.3 Mục tiêu luận văn 1.4 Đóng góp luận văn 1.5 Cấu trúc luận văn Chương 2: Những sở lý thuyết tảng 2.1 Tổng quan Android 2.1.1 Cấu trúc hệ điều hành Android 2.1.2 Android Security Framework 2.2 LTL - Propositional Linear time Temporal Logic 2.2.1 Kripke structure 2.2.2 Cú pháp biểu thức LTL 2.2.3 Ngữ nghĩa biểu thức LTL 2.3 Tổng quan On-the-fly LTL Model Checking 10 2.3.1 Nguyên lí Model Checking 10 2.3.2 On-the-fly LTL Model Checking 11 2.4 Kiểm tra mơ hình với cơng cụ PAT 12 Chương 3: Tổng thuật cơng trình liên quan 14 3.1 Các hướng nghiên cứu 14 3.1.1 ScanDroid 14 3.1.2 WoodPecker 15 vi 3.1.3 Android Model – Type and Effect System 16 3.1.4 Sorbet 17 3.1.5 Stowaway 18 3.1.6 XmainDroid 19 3.1.7 Crowdroid 20 3.1.8 Taintdroid 21 3.1.9 Scandal 23 3.1.10 ComDroid 23 3.1.11 AndroidLeaks 24 3.1.12 Các hướng khác 25 3.2 Thảo luận hướng nghiên cứu 25 3.2.1 Tóm tắt hướng 25 3.2.2 Giới thiệu cách tiếp cận On-the-fly LTL Model Checking 27 Chương 4: Phương pháp giải vấn đề hệ thống ứng dụng 28 4.1 Đặt vấn đề 28 4.2 Giải vấn đề 29 4.2.1 Framework tổng quát 29 4.2.2 Đặc tả thành phần Android Model Checker 30 4.2.3 Cấu trúc input file toàn module 31 4.2.4 Đặc tả phần chương trình trừu tượng 32 4.2.5 Đặc tả phần assertions 44 4.2.6 Cách thức xử lí kiểm tra mơ hình 45 Chương 5: Thực nghiệm 46 5.1 Thực nghiệm 1: kiểm tra lỗi bảo mật ứng dụng Android 46 5.1.1 Phát lỗi rò rỉ tường minh (explicit leak) 46 5.1.2 Phát implicit leak 53 5.2 Thực nghiệm 2: kiểm tra độ hiệu phương pháp on-the-fly 61 5.2.1 Nội dung cách thức thực nghiệm 61 5.2.2 Kết thực nghiệm 62 5.2.3 Phân tích kết thực nghiệm 63 vii Chương 6: Kết luận 65 6.1 Tổng kết 65 6.2 Hướng phát triển 66 Tài liệu tham khảo 67 PHỤ LỤC A: BẢNG ĐỐI CHIẾU THUẬT NGỮ ANH - VIỆT PHỤ LỤC B: LÝ LỊCH TRÍCH NGANG viii Trong chương trình thực tế, giá trị trạng thái in cụ thể: Hình 26 Kết kiểm tra lỗi rị rỉ ẩn tàng (1) Kiểm tra thuộc tính 2  - Thuộc tính có vế trái “system” nên model checker kiểm tra tòan hệ thống (bao gồm ứng dụng A ứng dụng B) Tồn q trình kiểm tra tóm tắt sau: Hình 27 Q trình kiểm tra lỗi rị rỉ ẩn tàng (2) 57 - Bước 1: Trạng thái ban đầu (trạng thái 0), model checker chưa bắt đầu duyệt qua lệnh Trong nhớ trạng thái 0, ứng dụng ứng dụng chứa thuộc tính sau: ¾ Trạng thái 0: — Ứng dụng (ứng dụng B) AppB.Permissions.Count=1 AppB.IntentBindings.Count=1 AppB.ProjectB.IntentPermission=0 — Ứng dụng (ứng dụng A) AppA.Permissions.Count=0 AppA.IntentBindings.Count=1 AppA.ProjectA.IntentPermission=0 Trạng thái khơng thỏa mãn thuộc tính đích khơng chứa biến “AppA.ProjectA.SystemCall.Success” Vì trạng thái khơng trạng thái kết thái kết thúc trạng thái đưa vào stack để lưu vết - Bước 2: Model checker yêu cầu sinh trạng thái trạng thái Từ trạng thái 0, có khả chạy: ứng dụng (ứng dụng B) chạy trước ứng dụng (ứng dụng A) chạy trước Vì có trạng thái tiếp theo: ¾ Trạng thái 1: ứng dụng B chạy bước ứng dụng A trì trạng thái cũ Khi ứng dụng B chạy bước đầu tiên, ứng dụng B có khai báo sharedUserId nên có thao tác thực hiện: — Tìm ứng dụng có sharedUserId với ứng dụng B để lấy đặc quyền ứng dụng Vì hệ thống, ứng dụng cịn lại ứng dụng A, vốn khơng có đặc quyền hết, nên kết thúc trình này, tập đặc quyền ứng dụng B không đổi — Cho ứng dụng B chạy bước Khi ứng dụng B chạy bước, lệnh “SystemCall (READ, ContactsContract_Contacts_CONTENT_URI, READ_CONTACTS);” xử lí Vì nhớ trạng thái trở thành „ Ứng dụng (ứng dụng B) AppB.Permissions.Count=1 AppB.IntentBindings.Count=1 AppB.ProjectB.IntentPermission=0 AppB.ProjectB.SystemCall=1 AppB.ProjectB.SystemCall.Success=1 58 „ Ứng dụng (ứng dụng A) AppA.Permissions.Count=0 AppA.IntentBindings.Count=1 AppA.ProjectA.IntentPermission=0 ¾ Trạng thái 2: ứng dụng B trì trạng thái cũ ứng dụng A chạy bước Tương tự sinh trạng thái 1, ứng dụng A chạy bước, có thao tác: — Tìm ứng dụng có sharedUserId với ứng dụng A để lấy đặc quyền ứng dụng Vì hệ thống, ứng dụng cịn lại ứng dụng B, vốn có đặc quyền READ_CONTACTS, nên kết thúc q trình này, ứng dụng A có thêm đặc quyền READ_CONTACTS — Cho ứng dụng A chạy bước lần Khi ứng dụng A chạy bước, lệnh “SystemCall (READ, ContactsContract_Contacts_CONTENT_URI, READ_CONTACTS);” xử lí Vì nhớ trạng thái trở thành „ Ứng dụng (ứng dụng B) AppB.Permissions.Count=1 AppB.IntentBindings.Count=1 AppB.ProjectB.IntentPermission=0 „ Ứng dụng (ứng dụng A) AppA.Permissions.Count=0 AppA.IntentBindings.Count=1 AppA.ProjectA.IntentPermission=0 AppA.ProjectA.SystemCall=1 AppA.ProjectA.SystemCall.Success=1 Model Checker kiểm tra thuộc tính đích (goal property) trạng thái trạng thái ¾ Trạng thái thỏa mãn thuộc tính đích trở thành trạng thái kết thúc cho đường thực thi Trạng thái xóa khỏi stack làm việc ¾ Trạng thái khơng thỏa mãn khơng chứa biến “AppA.ProjectA.SystemAccess.Success”, model checker tiếp tục yêu cầu sinh trạng thái trạng thái - Bước 3: Model checker yêu cầu sinh trạng thái cho trạng thái Ở trạng thái 1, ứng dụng B kết thúc, ứng dụng A trạng thái bắt đầu Vì vậy, cịn khả chạy cho ứng dụng A Tương tự sinh trạng thái 2, ứng dụng A thực thao tác nhận đặc quyền từ ứng dụng B Như trạng thái tiếp theo, trạng thái trở thành: 59 ¾ Trạng thái 3: — Ứng dụng (ứng dụng B) AppB.Permissions.Count=1 AppB.IntentBindings.Count=1 AppB.ProjectB.IntentPermission=0 AppB.ProjectB.SystemCall=1 AppB.ProjectB.SystemCall.Success=1 — Ứng dụng (ứng dụng A) AppA.Permissions.Count=0 AppA.IntentBindings.Count=1 AppA.ProjectA.IntentPermission=0 AppA.ProjectA.SystemCall=1 AppA.ProjectA.SystemCall.Success=1 Ở trạng thái 3, biểu thức thuộc tính đích (AppA.ProjectA.SystemCall.Success=1) thỏa, trạng thái trạng thái kết thúc đường thực thi theo hướng kết thúc Bước 4: Khơng cịn trạng thái cần xử lí, model checker kết thúc kiểm tra với kết valid Như vậy, thuộc tính cần kiểm tra thỏa mãn, có nghĩa hệ thống có lỗi rị rỉ ẩn tàng ứng dụng A ứng dụng B Kết chạy thực tế sau: Hình 28 Kết kiểm tra lỗi rị rỉ ẩn tang (2) 60 5.2 Thực nghiệm 2: kiểm tra độ hiệu phương pháp onthe-fly 5.2.1 Nội dung cách thức thực nghiệm - Để kiểm tra độ hiệu phương pháp on-the-fly so với phương pháp không on-thefly, tạo Android model checker khác, không áp dụng kĩ thuật on-thefly, chạy model checker tập liệu - Các xử lí model checker khơng áp dụng on-the-fly: Mỗi bắt đầu kiểm tra, toàn trạng thái hệ thống (chương trình Android) tạo ra, lưu trữ nhớ Khi thực kiểm tra, áp dụng giải thuật on-the-fly model checker luận văn Nhưng lần giải thuật gọi hệ thống sinh trạng thái mới, model checker tìm tập trạng thái sinh sẵn, trạng thái trạng thái trả cho giải thuật xử lí tiếp - Về mặt liệu, tạo chương trình có số lượng lệnh (trạng thái) từ đến nhiều kết hợp chương trình lại với để tạo trường hợp có độ phức tạp khác Các trường hợp kiểm tra : Hệ thống có ứng dụng Hệ thống có nhiều ứng dụng Mỗi ứng dụng có lệnh đơn (SystemCall, ECast, ICast ) Mỗi ứng dụng có nhiều lệnh đơn - Về property dùng để kiểm tra, dùng property sau: Khi kiểm tra cho ứng dụng App|= SystemAccess Khi kiểm tra cho nhiều ứng dụng: system |= (AppA_icast_AppB && AppB_SystemAccess && AppB_NotApiRequirePermission); - - Về cách thức đo lường, công cụ PAT hỗ trợ xuất thông tin thời gian chạy, dung lượng nhớ sử dụng, số trạng thái xử lí, số transition (trên automat verification property) Chúng tạo thêm thông tin tổng số trạng thái hệ thống (chương trình Android) để dùng cho việc so sánh độ hiệu Tuy nhiên, chúng tơi tính tổng số trạng thái trường hợp nonon-the-fly model checker sinh tồn trạng thái Trường hợp model checker bị out-of-memory, tạm thời khơng có thơng tin tổng số trạng thái Cấu hình máy: CPU: Intel Core Duo 2.5GHz, RAM : 3.5GB, 1.5 GHz 61 5.2.2 Kết thực nghiệm No Số ứng dụng hệ thống Số trạng thái cho ứng dụng Tổng số trạng thái toàn hệ thống Tổng số trạng thái duyệt qua (visited states) Tổng số transition 3 2 1 5 12 12 7/7 Thời gian chạy bình thường (non-onthe-fly) Bộ nhơ chạy onthe-fly 0.0073322 0.0083505 8.561712 8.555748 0.0076364 0.0086457 8.600456 8.564116 2 0.0069193 0.0096878 8.561996 8.5695 3431 18 33 0.0137023 0.3232282 9.1881 18.05847 8/7 6434 19 35 0.0097308 0.4913076 9.240936 28.08841 8/8 12869 21 39 0.0141165 1.0342272 9.324964 46.10464 9/8 24309 22 41 0.0113402 2.034575 9.37196 77.07186 9/9 48619 24 45 0.0140677 4.2251205 9.469652 145.1968 10/9 92377 25 47 0.0143336 8.0527863 9.526756 268.8605 10/10 184755 27 51 0.014468 16.270301 9.622856 537.4789 10 11/10 352715 34 65 0.0143283 31.503055 9.679652 1028.632 11 11/11 Memory 0.0146353 Memory 9.78058 Memory 12 3/3/3 271 13 27 0.0137551 0.0374933 9.223572 9.655364 13 4/3/3 650 16 34 0.014052 0.073886 9.408736 10.93252 14 4/4/3 1749 21 46 0.014924 0.187585 9.722932 17.95477 15 4/4/4 5248 34 80 0.012622 0.558177 10.61734 26.61128 16 5/4/4 13299 37 89 0.013645 1.537497 10.99394 50.97054 17 5/5/4 36750 47 114 0.018806 4.278662 11.5595 124.4609 18 5/5/5 110251 65 163 0.019273 12.57559 9.895056 351.2329 19 6/5/5 289002 72 182 0.0261427 34.766775 10.49162 930.3398 20 6/6/5 Memory 0.0280566 Memory 14.37518 Memory 21 4/4/4/3 276924 0.0336752 46.39418 9.88676 1115.067 22 4/4/4/4 Memory 0.0484148 Memory 11.717404 Memory 23 3/3/3/3/3 Memory 0.0259627 Memory 12.954404 Memory 24 10/10/10/10/10 Memory 72.448369 Memory 15.576412 Memory 74 213 Thời gian chạy onthe-fly Bộ nhớ chạy bình thường (non-onthe-fly) Bảng Kết thử nghiệm Chú thích: Mỗi lệnh đơn (SystemCall, ECast, ICast, ) tạo trạng thái (init, S, end) Out of memory >= 1400MB 62 5.2.3 Phân tích kết thực nghiệm - Về khả xử lí hệ thống phức tạp, phương pháp on-the-fly có khả xử lí hệ thống lớn gấp nhiều lần hệ thống mà phương pháp khơng on-the-fly xử lí Phương pháp khơng on-the-fly có khả xử lý hạn chế Phương pháp xử lí cho hệ thống có tối đa 352715 trạng thái (xem dịng 10 bảng số liệu), tương đương hệ thống gồm ứng dụng Android, ứng dụng có lệnh đơn ứng dụng cịn lại có lệnh đơn, hệ thống có ứng dụng với ứng dụng có lệnh đơn ứng dụng cịn lại ứng dụng có lệnh đơn Phương pháp on-the-fly ngược lại, có khả xử lý cho ứng dụng có kích thước lớn nhiều Hiện chúng tơi thử hệ thống có ứng dụng (xem dòng 24 bảng số liệu), ứng dụng có 10 lệnh đơn nhận thấy thời gian chạy khoảng 72 giây Như khả xử lý cho hệ thống phức tạp lớn - Về mức độ sử dụng nhớ, chương trình chạy phương pháp on-the-fly tiết kiệm nhớ phương pháp không on-the-fly Khi hệ thống phức tạp (số lượng trạng thái lớn), dung lượng nhớ cần dùng phương pháp on-the-fly tăng đột biến, phương pháp on-the-fly thay đổi nhẹ Phương pháp khơng on-the-fly phải sinh hết tất trạng thái hệ thống từ đầu, nên hệ thống lớn, số lượng trạng thái phải tạo lưu trữ lớn, nên nhanh chóng dẫn đến tình trạng hết nhớ Phương pháp on-the-fly sinh trạng thái cách từ từ, trạng thái xử lí bi xóa đi, tiêu thụ nhớ 1200 400000 350000 1000 300000 800 250000 600 200000 Tổng số trạng  thái trên toàn hệ  thống Bộ nhớ khi chạy  on‐the‐fly (MB) 150000 400 100000 200 50000 Bộ nhớ khi chạy  không‐on‐the‐fly   (MB) 10 11 12 13 14 15 16 17 18 Hình 29 So sánh mức độ sử dụng nhớ 63 - Về thời gian xử lí, phương pháp khơng on-the-fly có thời gian xử lí tăng đột biến độ phức tạp chương trình tăng, phương pháp on-the-fly có thời gian xử lí ổn định Phương pháp on-the-fly có thời gian xử lí tăng đột biến phải tạo tồn trạng thái cho hệ thống Hệ thống phức tạp, số lượng trạng thái lớn, thời gian xử lí dài Phương pháp khơng on-the-fly có thời gian xử lí khơng tăng độ phức tạp chương trình thay đổi nhẹ Tuy nhiên, độ phức tạp chương trình tăng cao (xem dịng 23 24 bảng số liệu), tùy theo thuộc tính cần kiểm tra (verification property) mà thời gian xử lí dài số lượng trạng thái trạng thái tăng dẫn đến số lượng đường thực thi tăng 50 400000 45 350000 40 300000 35 30 250000 25 200000 20 150000 15 100000 10 50000 Tổng số trạng  thái trên tồn  hệ thống Thời gian khi  chạy on‐the‐fly  (s) Thời gian khi  chạy khơng‐ on‐the‐fly (s) 0 10 11 12 13 14 15 16 17 18 Hình 30 So sánh thời gian chạy - Tóm lại, phương pháp on-the-fly cho hiệu cao phương pháp không on-the-fly Về thời gian chạy, tùy theo thuộc tính cần kiểm tra độ phức tạp chương trình mà thời gian chạy hai phương pháp ngang Nhưng nhìn chung, phương pháp on-the-fly có khả xử lí chương trình lớn, phức tạp phương pháp không on-the-fly nhờ việc sinh trạng thái cho hệ thống cách từ từ 64 Chương 6: Kết luận Chương tổng kết việc làm hướng mở rộng cho nghiên cứu sau 6.1 Tổng kết - Chúng xây dựng phần cho Android module PAT để kiểm tra ứng dụng Android đơn giản có vi phạm lỗi rò rỉ chức (capability leak) Module nhận input chương trình abstract chương trình Android LTL property, áp dụng kĩ thuật on-the-fly model checker PAT để kiểm tra xem chương trình Android có thỏa mãn LTL property hay khơng - Module kiểm tra lỗi rò rỉ chức dây chuyền qua nhiều ứng dụng - Chúng thử nghiệm thấy việc áp dụng kĩ thuật kiểm tra mô hình kiểu on-the-fly cho hiệu cao nhiều so với kiểm tra mơ hình kiểu khơng on-the-fly - Hiện module xử lí cho trường hợp lỗi rò rỉ chức ứng dụng A gọi đến ứng dụng B có API cho phép truy cập hệ thống không ràng buộc quyền Tuy nhiên, module chưa xử lí đến mức chi tiết trường hợp phân biệt xác ứng dụng A gọi đến API ứng dụng B (thí dụ ứng dụng B có component thực nhiều hành động khác ACTION_VIEW, ACTION_LIST, …), kiểm tra xem ứng dụng B có ràng buộc quyền cho API chưa ràng buộc đầy đủ,…Để kiểm tra chi tiết vậy, cần mở rộng chương trình, bổ sung thêm nhiều biến trạng thái cho lệnh - Module chưa hỗ trợ kiểm tra giá trị biến resource - Trong q trình kiểm tra, module cần thơng tin đặc quyền cần thiết cho API hệ thống Hiện tại, giả định thông tin xác định tay, dựa tài liệu Android, dịch từ chương trình Android sang chương trình trừu tượng xác định cung cấp sẵn câu lệnh “SystemCall” Tuy nhiên việc xác định thơng tin cách đầy đủ xác điều khơng dễ dàng Các cơng trình phải dùng đến kĩ thuật testing để xác định bảng map tương đối - Trong phần thí nghiệm so sánh độ hiệu phương pháp on-the-fly không onthe-fly, tự giả lập chương trình cho phương pháp khơng on-the-fly nên độ xác kết thí nghiệm cịn hạn chế 65 6.2 Hướng phát triển - Công việc mở rộng khả xử lý cho trường hợp xử lý khác ứng dụng Android cách mở rộng cú pháp chương trình abstract, bổ sung thêm lệnh lại loại component lại - Để tăng độ xác q trình kiểm tra xử lí cho nhiều loại lỗi bảo mật khác, phân loại SystemCall thành nhiều lệnh cụ thể khác thêm thông số để phân biệt loại system call (truy cập liệu cá nhân, gửi sms, truy cập internet ) Thí dụ để phát lỗi Man-in-the-Middle, cần phân tích thêm malicious app nhận liệu truyền - Hiện tại, mức độ demo, module hỗ trợ người dùng kiểm tra thuộc tính mà người dùng tự định nghĩa (thí dụ : #assert system |= (AppA_ecast_AppB && AppB_SystemAccess && AppB_NotApiRequirePermission) ) Sau này, module phát triển đầy đủ, cải thiện phần cách đặt ngôn ngữ cấp cao hơn, gần với người dùng (khi người dùng cần viết #assert system |= explicit_leak) - Ngòai ra, để cải tiến khả xử lí cho ứng dụng kích thước lớn, ngồi việc cải tiến xử lí chương trình, xem xét khả áp dụng module cho công cụ model checker khác - Để kiểm tra độ hiệu thực phương pháp on-the-fly so với phương pháp không on-the-fly, tìm source code cơng trình trước tập dự liệu họ dùng cho thực nghiệm, so sánh thời gian chạy phương pháp tập liệu 66 Tài liệu tham khảo [1] Alessandro Armando, Gabriele Costa, and Alessio Merlo , (2012), “Formal modeling and reasoning about Android Security Framework” In proceedings of TGC 2012, Newcastle upon Tyne, UK, 2012 http://www.ai-lab.it/merlo/publications/ AndroidModel.pdf [2] Michael Grace, Yajin Zhou, Zhi Wang, Xuxian Jiang, (2012), “Systematic Detection of Capability Leaks in Stock Android Smartphones” In proceedings of the 19th Network and Distributed System Security Symposium (NDSS 2012), San Diego, CA, February 2012 [3] Adam P Fuchs, Avik Chaudhuri, and Jeffrey S Foster, (2009), “SCanDroid: Automated Security Certification of Android Applications” University of Maryland Department of Computer Science Technical Report CS-TR-4991, November 2009 [4] Elli Fragkaki, Lụo Bauer, Limin Jia, and David Swasey, (2012), “Modeling and Enhancing Android's Permission System” In Computer Security ESORICS 2012: 17th European Symposium on Research in Computer Security, Sept 2012 Technical Report http://www.andrew.cmu.edu/user/liminjia/research/papers/android- esorics12.pdf [5] Adrienne Porter Felt, Erika Chin, Steve Hanna, Dawn Song, David Wagner, (2011), “Android Permissions Demystified” 18th ACM Conference on Computer and Communications Security (CCS), 2011 [6] Sven Bugiel, Lucas Davi, Alexandra Dmitrienko,Thomas Fischer, Ahmad-Reza Sadeghi, (2011),"XManDroid: A New Android Evolution to Mitigate Privilege Escalation Attacks" Technische Universitat Darmstadt, Center for Advanced Security Research Darmstadt (CASED) Technical Report TR-2011-04 67 [7] Iker Burguera, Urko Zurutuza, Simin Nadjm-Tehrani, (2011), "Crowdroid: BehaviorBased Malware Detection System for Android" In Proceedings of the 1st ACM workshop on Security and privacy in smartphones and mobile devices, SPSM '11 [8] William Enck, Peter Gilbert, Byung-Gon Chun, Landon P Cox, Jaeyeon Jung, Patrick McDaniel, Anmol N Sheth, (2010), "TaintDroid: An Information-Flow Tracking System for Realtime Privacy Monitoring on Smartphones" Proceedings of the 9th USENIX Symposium on Operating Systems Design and Implementation (OSDI), October, 2010 Vancouver, BC [9] Jinyung Kim, Yongho Yoon, Kwangkeun Yi, Junbum Shin, (2012), "SCANDAL: Static Analyzer for Detecting Privacy Leaks in Android Applications" In Mobile Security Technologies (MoST) 2012 (part of the IEEE Computer Society Security and Privacy Workshops, in conjunction with the IEEE Symposium on Security and Privacy) [10] Erika Chin, Adrienne Porter Felt, Kate Greenwood, David Wagner,(2011), "Analyzing Inter-Application Communication in Android" 9th Annual Intl Conference on Mobile Systems, Applications, and Services (MobiSys), 2011 [11] Clint Gibler, Jonathan Crussell, Jeremy Erickson, Hao Chen, (2011), "AndroidLeaks: Detecting Privacy Leaks In Android Applications" International Conference on Trust and Trustworthy Computing (TRUST) 2012 [12] William Enck, Damien Octeau, Patrick McDaniel, Swarat Chaudhuri, (2011), "A Study of Android Application Security" In Proceedings of the 20th USENIX Security Symposium, San Francisco, Ca, August 2011 [13] Paper summery for 06/20/2011 [Focused on Static Analysis of Android Apps] http://sta2838.wordpress.com/2012/06/19/paper-summery-for-06202011-focused-onstatic-analysis-of-android-apps/ [14] Static Analysis of Android Applications http://tthtlc.wordpress.com/2011/09/01/staticanalysis-of-android-applications/ [15] Anders Morten Mikkelsen, (Spring 2001), “On-The-Fly L TL Model Checking in Design/CPN” M.Sc Thesis 68 [16] Dimitra Giannakopoulou, (1999), “Model Checking for Concurrent Software Architectures” Thesis [17] Liu Yang, (2009), “Model checking concurrent and real-time system: The PAT approach” Thesis [18] Bui Hoai Thang, “Model Checking – Automata-Theoretic MC” Lecture [19] Android Market http://market.android.com [20] Android API Guides http://developer.android.com/guide/components/index.html [21] Android Security Overview http://source.android.com/tech/security/ [22] William Enck, Machigar Ongtang, Patrick McDaniel,(2008), “Mitigating Android Software Misuse Before It Happens” [23] Machigar Ongtang, Stephen McLaughlin, William Enck, Patrick McDaniel, (2009), “Semantically Rich Application-Centric Security in Android” [24] Michael Dietz, Shashi Shekhar, Yuliy Pisetsky, Anhei Shu, Dan S Wallach, (2011), “Quire: Lightweight Provenance for Smart Phone Operating Systems” [25] Mobile Phone Security http://siis.cse.psu.edu/phones.html [26] Jinseong Jeon, Kristopher K Micinski, Jerey S Foster, (2012), “SymDroid: Symbolic Execution for Dalvik Bytecode” [27] Étienne Payet, Fausto Spoto, (2011), "Static Analysis of Android Programs" [28] PAT: Process Analysis Toolkit.http://www.comp.nus.edu.sg/~pat/OnlineHelp/index.htm [29] Android System Permission http://developer.android.com/reference/android/Manifest.permission.html 69 PHỤ LỤC A: BẢNG ĐỐI CHIẾU THUẬT NGỮ ANH - VIỆT Thuật ngữ tiếng Anh Thuật ngữ tiếng Việt Transition system Automata Hệ thống chuyển trạng thái Máy trạng thái Resource Permission Propositional Linear time Temporal Logic Tài nguyên Đặc quyền Luận lý thời gian tuyến tính Process Analysis Toolkit Reasoning Concurrent System Model Checker Model Checking Verification Property Execution path Model Model Checking Verification Machine learning Explicit Capability Leak Implicit Capability Leak On-the-fly Abstract program Assertion Component Viết tắt LTL PAT Suy diễn Hệ thống chạy đồng thời Công cụ kiểm tra mô hình Kiểm tra mơ hình Thuộc tính để kiểm tra mơ hình Đường thực thi Mơ hình Kiểm tra mơ hình Kiểm định Học máy Rị rỉ chức tường minh Rò rỉ chức tiềm tàng Dần dần, theo nhu cầu Chường trình trừu tượng, chương trình giản lược Xác đề Thành phần Manifest file File khai báo đặc quyền, thành phần, chức thành phần chương trình Android Counterexample Dẫn chứng trường hợp lỗi A1 PHỤ LỤC B: LÝ LỊCH TRÍCH NGANG Họ tên: NGUYỄN THANH HỒNG Ngày, tháng, năm sinh: 20/11/1982 Nơi sinh: TP.Hồ Chí Minh Địa liên lạc: 12/6 Ấp Trung Đông, Xã Thới Tam Thôn, Huyện Hốc Mơn Tp Hồ Chí Minh Email: nthong82@gmail.com Q TRÌNH ĐÀO TẠO Năm 2000 – 2005: Sinh viên Đại học trường ĐH Bách Khoa Tp HCM, Khoa Công Nghệ Thông Tin Năm 2009 – nay: Học viên Cao học trường ĐH Bách Khoa Tp HCM, Khoa Khoa Học Máy Tính QUÁ TRÌNH CƠNG TÁC 2005 – Nay: Kỹ sư tin học Doanh Nghiệp Tư Nhân Dich Vụ Tường Minh A2 ... phát bất thường ứng dụng trình sử dụng điện thoại (kiểm tra động) , kiểm tra ứng dụng có phải malware, kiểm tra khả xảy rị rỉ thơng tin cá nhân người dùng ứng dụng chạy thực tế (kiểm tra tĩnh), -... KIỂM TRA ỨNG DỤNG TRÊN ĐIỆN THOẠI ANDROID BẰNG KIỂM TRA MƠ HÌNH II NHIỆM VỤ VÀ NỘI DUNG: 1) Hiện thực module kiểm tra vài tính chất chương trình Android phương... nằm nhóm kiểm tra tĩnh, chưa đề cập công trình khơng phần hiệu quả, ? ?kiểm tra mơ hình? ?? - Phương pháp kiểm tra mơ hình ngày thường áp dụng với kĩ thuật kiểm tra onthe-fly Đó cách kiểm tra mà khơng