Semantically Rich Application-Centric Security in Android

1. Semantically Rich Application-Centric Security in Android Machigar Ongtang, Stephen McLaughlin, William Enck and Patrick McDaniel Annual Computer Seurity Application Conference '09 Speaker：Kuo

2. Outline • Introduction • Smartphone application security • Android Security • Application policies • Saint Policy • Saint Architecture • Conclusion

3. Outline • Introduction • Smartphone application security • Android Security • Application policies • Saint Policy • Saint Architecture • Conclusion

4. application A application B <permission 付帳功能/> Callee <uses-permission 付帳功能/> Caller Introduction • Android permission

5. application A application B <permission 付帳功能/> Callee <uses-permission 付帳功能/> Caller • inter-component communication (ICC).

6. application A <permission 付帳功能/> application D application B application C <uses-permission 付帳功能/> <uses-permission 付帳功能/> <uses-permission 付帳功能/>

7. Outline • Introduction • Smartphone application security • Android Security • Application policies • Saint Policy • Saint Architecture • Conclusion

8. Smartphone application security

9. PersonalShopper should only use trusted payment services. • PersonalShopper may only want to restrict the use of the service to only trusted networks under safe conditions. • PersonalShopper may require certain versions of service software be used. • PersonalShopper may wish to ensure transaction information is not leaked by the phone’s ledger application.

10. Outline • Introduction • Smartphone application security • Android Security • Application policies • Saint Policy • Saint Architecture • Conclusion

11. Android Security • Component Type • Activity components • Service components • Content provider components • Broadcast receiver components • Component Interaction

12. Component Type • Activity components • define anapplication’s user interface • Service components • Perform background processing.

13. Component Type • Content provider components • Store and share data using a relational database interface • Broadcast receiver components • act as mailboxes for messages from other applications.

14. Component Interaction • Developers assign applications collections of permission labels. • if the target component’s access permission label is in that collection:allows ICC establishment to proceed. • If the label isn’t in the collection, establishment is denied

15. Outline • Introduction • Smartphone application security • Android Security • Application policies • Saint Policy • Saint Architecture • Conclusion

16. application A <permission 付帳功能/> Callee Permission • Permission <permission android:description="string resource" android:icon="drawable resource" android:label="string resource" android:name="string" android:permissionGroup="string" android:protectionLevel=["normal" | "dangerous" | "signature" | "signatureOrSystem"] />

17. Permission • Permission Protection Levels : four protection levels • Normal : are granted to any application that requests them in its manifes • Dangerous : are granted only after user confirmation • Signature : are granted only to applications signed by the same developer key • signature or system: act like signature permissions but exist for legacy compatibility with the older system permission type.

18. application A application A application A application B application B application B <permission 付帳功能 Level: normal /> Callee <permission 付帳功能 Level: dangerous/> Callee <permission 付帳功能 Level: signature /> Callee <uses-permission 付帳功能/> Caller <uses-permission 付帳功能/> Caller <uses-permission 付帳功能/> Caller user confirmation Signature of A

19. Application policies • permission-granting policy(install-time) • regulates permission assignment. • interaction policy(run-time) • regulates runtime interaction between an application and its opponent.

20. Application policies • permission-granting policy (install-time) 1.1 Android’s protection level-based policy 1.2 signature-based policy • the policy grants (or denies) the permission by default with an exception list that denies (grants) the applications signed by the listed keys 1.3 configuration-based policy • Control permission assignment based on the configuration parameters of the requesting application • Ex: application version

21. application B <uses-permission 付帳功能/> Caller application A <permission 付帳功能/> <Set of signature : 2233e 9988w> Callee 2233e allow

22. Application policies • interaction policy (run-time) 2.1 permission-based access control policy 2.2 signature-based policy • restrict the set of the opponent applications based on their signatures 2.3 configuration-based policy • the applications can define the desirable configurations of the opponent applications • Ex: application version 2.4 phone context-based policy • governs runtime interactions based on context such as location, time…etc

23. Outline • Introduction • Smartphone application security • Android Security • Application policies • Saint Policy • Saint Architecture • Conclusion

24. SAINT policy • Install-Time Policy Enforcement • Run-Time Policy Enforcement • Administrative Policy

26. Use pay permission from A Pay permission policy from B

27. Install-Time Policy Enforcement • the Saint-enhanced Android installer retrieves the requested permissions from the manifest file • For each permission, it queries the AppPolicy provider • The AppPolicy provider consults its policy database,and returns a decision based on matching rules

28. Saint install-time policy consists of • a permission label • an owner • is always the application declaring the permission. • a set of conditions • are a collection of checks on the properties of the application requesting for it.

30. Run-Time Policy Enforcement • The caller initiates the IPC through the middleware framework • Saint queries the AppPolicy provider for policies • The AppPolicy provider checks the policy conditions satisfied, and returns the result pay Pay permission policy from B Pay permission policy from A

31. the conditions are satisfied, the IPC is directed to the existing Android permission check enforcement software • Android will then allow the IPC to continue based on traditional Android policy.

32. Saint enforces two types of runtime policies: • access policies • identify the caller’s security requirements on the IPC, and requirements on the IPC • expose policies • identify the callee’s security requirements on the IPC.

34. Administrative Policy • Goal: how policy itself can be changed • administrative models allowing the updater to modify, add, or delete policy • If the SaintOverride compile flag is set, Saint allows user override to application policy. • Saint XML policy schema includes the Override flag for each policy rule defined by the application.

35. Outline • Introduction • Smartphone application security • Android Security • Application policies • Saint Policy • Saint Architecture • Conclusion

36. Saint Architecture • Saint Installer • Saint Mediator • AppPolicy Provider

37. Outline • Introduction • Smartphone application security • Android Security • Application policies • Saint Policy • Saint Architecture • Conclusion

38. Conclusion • Saint addresses the current limitations of Android security through install-time permission granting policies and runtime inter-application communication policies

39. Thanks!