1. AUDACIOUS User-Driven Access Control with Unmodified Operating Systems
Studied by
Talia Ringer | Dan Grossman | Franziska Roesner Presented by Ryan Tiedemann
Hi all,
Today I am here to talk to you about AUDACIOUS, as developed by Talia Ringer, Dan Grossman, and Franziska Roesner

2. What is AUDACIOUS?
AUDACIOUS stands for Android User-Driven Access Control in Only User Space. It is a secure library implementation thats primary goal is to provide a system for User-Driven access control in android applications without modifying the underlying os
It does this through the use of Access Control Gadgets, or ACGs for short. An ACG is UI element that users can interact with to grant applications access to restricted resources.
Grant access to GPS Location
Grant access to camera / microphone
Grant access to file system
First, what is AUDACIOUS?
AUDACIOUS stands for Android User-Driver Access Control in Only User Space.
That’s quite a mouth full, so what is the actual purpose of AUDACIOUS?
It is a security library that provides developers with access to Access Control Gadgets, more on that in a moment.
The basic goal is to provide user-driven access control to unmodified operating systems.
While not requiring too much extra work from the developers.
So what is an Access Control Gadget? Put simply, it is a UI element that when interacted with, grants an application access to privileged resource for the purpose it requires it for.
An example of some good uses for ACGs would be:
-A Map that required your GPS Location, the application is granted access to the GPS data only while it requires it
-A messaging application, which only requires elevated permissions when you want to send a file or record a message.
-An client, which does not require access to the filesystem unless you are specifically wanting to send or receive a file.

3. Why use User-Driver Permissions?
Under the current permissions system of most modern smartphone operating systems. An application either has unrestricted access to a resource, or no access at all.
So why does this matter?
An application that has access to your GPS when you are using it, could also be accessing your GPS when you are unaware
Currently we have no idea if the applications are secretly uploading all our GPS locations, or other private resources, to the internet without us even knowing.
So why use user driven permissions rather than what is typically in use today?
Well under the model that is currently used today, an application either has complete unrestricted access to a privileged resource. Or it is completely blocked from the resource. There is no middle ground
So why is this a problem?
Well imagine the case when a user downloads a camera application. Maybe it has some nice filters, or cool snapchat effects. But the result is that you grant the application access to the camera permissions.
Now you can use the application in its intended manner, and you seem happy.
But what if in the background, the application was actually accessing your camera to send periodic images to a remote website. Perhaps someone wanting to know where you are, based on images of your surroundings?
Currently once we have given an application access to a secured resource, we are at the mercy of the developers to not have implemented some hidden functionality

4. So what can we do about it?
So at this point I hope you are all freaking out. I know I was when I first read this. How could this system have been in place for so long, and yet we are for the most part completely unaware of the danger we are putting ourselves in.
This problem is exactly what a user driven access control system aims to solve. The main goal here is to only provide applications with access to resources when they actually need it.
So for applications like the previously discussed camera app, we don’t need to grant permission to the app until the user actually wants to take a photo, then we can revoke access until next time
So that’s the goal of AUDACIOUS, to try and implement this security model on an android based system. But with some other key requirements

5. What are AUDACIOUS goals?
User-Driven access control
Ensure that applications can access sensitive resources only when the user interacts with with the UI (through a ACG)
Unmodified OS
The final implementation should make no changes to the underlying OS.
Regulate Resource Use, not just access
Provide guarantees about the flow of sensitive resources.
Permission Model Flexibility
Allow alternative permissions models for use cases where user interaction would be inhibiting (A calendar app)
So what are the goals of AUDACIOUS?
The first goal is User Driven Access Control
Empowering the user to grant access to a resource only when the application requires it to operate.
The second is to do so on an Unmodified operating system,
This has the benefits of better backwards compatibility with older operating systems. Which According to Google Play statistics, 92.5% of android devices are running outdated versions of Android.
So if we were to implement these changes into the android operating system itself, how long would it take for the changes to actually propagate the entire market?
The third goal is to regulate resource use, not just access
In the typical permissions models of today, once an application has access to a resource. We don't know if the resource is used solely for its intended purpose or not. Say our camera application only has permission to the camera when it needed it, but what if it both saved the image to your phone and sent it to the internet? How would we know?
So the goal here is to determine how an application will use a resource, before approving it for distribution.
And finally, Flexibly Permission Models
While user-Driven access control works great for interactive applications. It’s not going to work so well for background apps that require special permissions. For instance what about a calendar application that needs access to GPS data to remind you of events?

6. So how is AUDACIOUS going to do that?
So how is AUDACIOUS going to do this?
Well the main idea here is to provide ACGs to developers, such that they can include them in their applications when they require access to a secured resource. But a big issue with that is that code defined in User Space, can be edited by the developers.
That’s why the developers have defined this set of more specific goals, that would satisfy the primary goals of the library. While ensuring that the library was not bypassed by means of altering the code or tricking the user
You can see the set of goals above,
But the main goals that I would like to draw your attention to are…..
[NEXT SLIDE]

7. Event Flow - Events must be Authentic
How do we ensure that the input event came from the user?
Direct Event Forgery
Indirect Event Forgery
Defense: Taint Analysis
Monitor events from their source to sink.
If event travels through application code, then it is tainted
Firstly Event forgery
Events must be authentic, we need to be sure that the interaction with the ACG came from the user, and not from the application. This can be done via taint analysis. The basic idea here is to monitor the path of input events from its source to the ACG. If the input event has to pass through the applications code, then we consider the input tainted and untrustworthy. We call this monitoring of the Event Flow.

8. UI Context - the UI must not be ‘tricksy’
UI does not deceive the user
User has enough time to perceive the valid UI
Defense: Dynamic bitmap checks, compare the applications output with the expected output. This can be done at given time intervals, or randomly within a predefined time period
The next items of significance are that the “UI does not deceive the user” and the “User has enough time to perceive the valid UI”. What is meant by this, is that the application cannot attempt to trick the user into granting it access. Some methods for doing this are discussed in more detail in the paper, but in essence the application cannot attempt to switch out the buttons are you are about to press them, we would call this a bait and switch attack. And the application cannot attempt to place ACG’s underneath other UI elements, in order to get the user to click on them without knowing.
AUDACIOUS protects against these forms of attacks by performing dynamic bitmap checks, that is to say that it compares the displayed application image against the expected output, and detects any differences as attacks against the ACGs.

9. Resource Flow - Resources used only as expected
The application must use the resources only how the user expects it to
Defense: Track the flow of resource information through the application before approving it for distribution THIS IS done with SPARTA!
“Resources, once accessed, are used only as expected” The idea here is to track the flow of information through the application, to ensure that it is not doing any unintended actions with it. For instance sending it out across the internet. This is done by finding all “sources” of data, for instance the camera, and tracking its path to any “sinks”. Sinks are final destinations for the information, and could be places such as the device storage or the internet.

10. How would AUDACIOUS look in a release environment?
Developers submit their app alongside:
Annotated Code
ACG Library
SPARTA Library
Flow Policy
Other Libraries
The first stage of deployment is for the developers to package their application along side some other supporting resources.
Specifically, the developer needs to first annotate their code for SPARTA to analyse the resource flow.
Secondly the developer needs to package their application with the ACG, SPARTA libraries, and anything else that they require
The developer also needs to include a Flow Policy document, which outlines the allowable resource flows within the application.

11. How would AUDACIOUS look in a release environment?
The code is then automatically analyzed
SPARTA Analysis,
Detects where the resources end up
Event Analysis
Check that user input is never tainted
The second stage is an automated stage of SPARTA and event analysis. At this stage the system attempts to find illegal resource usage or find situations where the developer has attempted to taint the user's input

12. How would AUDACIOUS look in a release environment?
A human verify approves / denies application
A Human verifier will look at the output from the automated phase
Based on the results, the verifier will make a decision to approve or deny
Thirdly the output of the automatic stage is verified by a human. This stage can vary vastly based on the complexity of the application. If no errors are reported by the previous stage, then the verification process will be rather quick. However, if many warnings are produced it could take verifiers a long time to go though and ensure the application is not malicious

13. How would AUDACIOUS look in a release environment?
Once an application has gone through the approval stages, it is still subjected to runtime checks that ensure the application is operating as expected
Dynamic bitmap checks
The UI is consistent with the event
The event is deceptive
The UI is deceptive
Only scenario A is acceptable to AUDACIOUS
Once the application has passed all the prior approval stages, it is still subjects to runtime checks.
Specifically the system will run Dynamic bitmap checks at runtime, to ensure that the input events correspond to the UI that the user expected to interact with
It is trying to protect the user from the above cases, B and C. Where the developer tries to alter a user input event, and the developer tries to trick the user respectively.

14. Does it actually work?
AUDACIOUS developers implemented the library into the above open source applications.
Listed are the ACGs that the developers implemented into each application
Well this is really what it's all about isn't it, does the library actually work?
To test this the developers of AUDACIOUS implemented their library into a number of open source applications, as you can see listed on the screen above.
They have also categorised the applications by the complexity, the resources it requires to operate, and the ACG’s that were implemented to allow access to these resources.

15. Findings
In cases where ACG like buttons already exists, swapping them out for ACGs actually reduced code size
In cases where it was not, it only added minimal extra code to implement an ACG
Event Analysis only takes at most 24 seconds to complete
During the testing performed by the AUDACIOUS developers, only 1 of the 5 applications tested reported false positives
SPARTA takes at most 96 seconds to analyse the applications.
Annotating code for SPARTA is fast for small applications, but a burden for poorly coded large applications. However tools to automatically annotate the code can help significantly
So what did the developers find?
They found that the AUDACIOUS library actually reduced the code size in most cases, for instance if an application has buttons that can be replaced by ACGs, doing so results in a small code size. Of course this is traded with the fact that the AUDACIOUS library is packaged alongside the application code.
They found in cases where there were no ACG like controls to replace, implementing ACGs required very little extra code
Teh found that for the 5 applications they tested with, the most time taken to complete event analysis was 24 seconds.
Meanwhile the event analysis stage posed 1 false positive, for the WikiJourney application which had rather complex input events due to the application rotating a map on screen.
This false positive was quickly dismissed through human verification.
For SPARTA analysis they found that it took at most 96 seconds to analyses the applications, however they found a number of false positives in 2 of the applications. These false positives were triggered from bluetooth information being leaked through a toString() method. But this was easily verified by a human verifier to be a false positive and ignored.
However, it was found that annotating the source code for SPARTA analysis was rather time consuming for more complex applications. While tools were able to automate a lot of the process, the result of having to annotate the code can be quite a burden for developers who attempt to implement the annotations after development, rather than during development

16. Performance Impacts
AUDACIOUS performs random bitmap checks at runtime, these can take some time based on when they are performed.
More checks = slower average performance
Checking at the same time as a user interacts with the UI results in much longer delays
Because AUDACIOUS also has a runtime component, we need to have a look at the results of AUDACIOUS on interaction performance.
The following results are from a test where the developers toggled the LocationACG 30 times in quick succession.
The finding are that when a check occurs at the same time as the user is trying to interact with the UI, then the delay can be quite significantly longer. However, in other instances the impact on performance is negligible.
Because of this finding, it can be said that having more frequent random checks results in a higher likelihood of the check occurring at the same time as a user is interaction with the UI. So naturally, increasing the frequency of checks results in a slower overall performance.

17. Attack prevention
A Evil Application was developed that attempted to bypass the library security features.
57 attacks
55 successfully defended
1 of the missed attacks was a result of an Android Bug, where half obscured UI elements are not flagged as obscured.
The second missed attack was due to a limitation in the Android OS, where there is no way to detect if a UI element is obscured by a Toast Element
How does AUDACIOUS stand up to attempted attacks on its implementation?
Overall the developers ran 57 attacks on the library, and found that 55 of them were defended against correctly.
One of the missed attacks was the result of an Android Bug which the developers have reported.
The other missed attack was due to android not reporting if a ACG was obscured by a Toast. Something which cannot be avoided without alterations to the OS.

18. Summary
Brings User-Driven Access Control to the current ecosystem of devices
Implements checks that ensure developers cannot bypass the security features put into place
Due to no OS requirements, this secure library can be ported to numerous different platforms with relative ease
Has minimal impact on performance and application size.
AUDACIOUS sets out to implement a great security model in a way that allows quick deployment to the vast diversity of devices on the market today.
It has implemented checks to ensure that developers cannot circumvent these security models. And it does all of this with minimal impact to performance and application size.
However as we will discuss now, this does give rise to some other issues.

19. Issues More items to trust (ACG Library, SPARTA, Event analysis, etc)
AUDACIOUS library updates require application updates
ACGs cannot override internal operating system permissions. As such an application on the Android application, will still ask the user for permissions. Which could be confusing for the user
Extra work for the developers.
Human verification process could have high costs, long processing times, and the possibility of mistakes
SPARTA runs on source code, so developers will have to release it to the verifiers.
So what are some issues that the AUDACIOUS library brings to the table?
Well first of all we have the issue that there are more components that the system has to put its trust in. We have to trust that the library is truely secure, and that the verification tools are all correct. This makes more places for errors, and vulnerabilities to seep through
Secondly, because AUDACIOUS is a library in the user space, if an update is released for the library. All the applications that implement that library have to release updates themselves. This is a high workload for developers and requires thousands if not millions of developers all working on application updates at the same time.
Another issue is that the ACG’s are implemented in user space, therefore they are not able to override underlying os permissions. That is to say that in a typical android application, you are still going to get alerts to the end user to grant permission to the application.
This library also brings in alot of extra work for the developers, especially in complex applications. In certain scenarios the AUDACIOUS library requires that developers annotate alot of their code, which can be time consuming and introduce new issues in the debugging procedures.
And lastly, human verification is a very costly endeavour. It requires management, hiring procedures, policies, payrolls. All of this ontop of lengthy checks that are prone to human error. Overall involving humans into any project results in alot of overhead.

20. Improvements
Redesign bitmap comparison such that it can be done statically before application deployment
More customisation to ACGs appearance
Implement ACG type security gadgets for other forms of input, such as voice commands, gestures or motion
Some suggestions for the AUDACIOUS library
It would be great to reduce runtime performance requirements by redesigning the need for dynamic bitmap checks. If the system was able to statically infer the possible changes that could happen to the UI at runtime, and check all of these. That would reduce performance overhead.
Also due to the fact that there are dynamic bitmap checks, the appearance of the ACG is not able to be altered significantly to align with the application design.
It would also be great to see ACGs implemented for other input methods, as the current implementation only accounts for pointer interaction. Be that either finger or mouse. Allowing for ACG’s to be triggered for voice commands, gestures or even motion sensors would allow ACGs to be deployed more universally

21. Questions?
Any Questions?

22. End of Slides