1. AUDACIOUS: USER DRIVEN ACCESS CONTROL WITH UNMODIFIED OPERATING SYSTEM
By,
Talia ringer, dan grossman and Franziska roesner
PRESENTED BY: Mohammad

2. Introduction AUDACIOUS:
Android User-Driven Access Control in Only User Space
A secure library implementation whose primary goal is to provide a system for User-Driven access control in android applications without modifying the underlying operating system.

3. Goals of AUDACIOUS Goal 1: Goal 2: Unmodified Operating System Goal 3:
User-driven Access Control Access to sensitive resources is only granted when the user interacts with the corresponding ACG.
Goal 2:
Unmodified Operating System
The final implementation should not make any changes to the underlying operating system.
Goal 3:
Regulate Resource use, not just access Design should provide guarantees about the flow of resources.
Goal 4:
Permission Model Flexibility Allow applications to use alternative permission models for some functionalities.

4. Goals of AUDACIOUS(cont.)

5. Techniques used to secure ACG’s
Event flow
UI context
Resource flow
UI interaction is strictly invoked by the user
UI does not trick the user into interactions
Resources are accessed appropriately via ACGs
Defense via taint analysis
Defense via explicit Internal/External UI checking
Defense via regulating Information Flow.
Can be disrupted via event forgery.
Can be disrupted by cover attacks.
Disrupted by abusing granted permissions to perform malicious tasks.

6. Libraries ACG LIBRARY Developed in Android and is event-driven.
It works on bytecode than source code.
Invalidates view if library detects a potentially malicious or “evil” event. Application code is not executed.
Two ACG interfaces – one for temporary permissions and one for permanent permissions.
Views are wrapped so that applications cannot modify the ACG UI after creation.
We can use the library in two ways
Define it in a layout
Access it programically.

8. Libraries(cont.) SPARTA LIBRARY Information flow tool
Two stages - App store approval and Runtime approval
SPARTA operates on source code.
SPARTA compares the flows with allowable flows defined in a flow policy file.
A human verifies the output of SPARTA in the context of the policy.
SPARTA is extended by implementing an ACG type so SPARTA can distinguish ACGs from each other.

10. Summary of ACG applications

11. Fighting evil: Analysis
Evil application developed is made to bypass the library security features
Out of 57 attacks, 55 were defended
One of the missed attack was an result of Android Bug .
The other was due to limitation of android OS.

12. Performance

13. Limitation
We cannot modify events or interfere with the flow of events.
Partially obscured toast are to be invalidated but it is not and this bug has been reported to android.
OS limitations leads to flag value being never set if we construct an event by programs.
SPARTA does not ensure that correct resources are used at correct time.
If ACG library is updated, all the applications using it has to be updated to include the latest version of library.
No way to check obscured flag during a random check.

14. Criticism
Existing applications cannot be benefitted by ACG unless it is refactored by the developer again for ACG library.
If the OS prevented events from being created or modified, we would not need to run a analysis.
ACG does not protect against all type of attacks
When randomness test are done too frequently it may affect the performance of the application.

15. THANK YOU