Andromaly: Verifying user activity on Android-powered devices using anomaly detection

1. Andromaly Verifying user activity on Android-powered devices using anomaly detection

2. Background: Android is a software stack for mobile devices that includes an operating system, middleware and key applications. Application on Android platform are developed using Java programming language. Being a Smartphone, Android platform provides both cell phone and PC-like capabilities to the owner. When the device is stolen, these capabilities raise the need for better protection mechanisms for blocking cellular communicationand protecting personal and sensitive data.

3. Problem domain: Andromaly Feature extractor Anomaly detector Research application PC OS Android platform Lock/Auth application

4. Current situation: Currently, mobile phones has inefficient and uncomfortable protection mechanisms. Mechanism: Authentication when device is powering on using PIN number (personal identification number). Problem: What happens if the device is stolen when it is already powered on? Mechanism: Device locking when device is powered on. Authenticating the user before each action using password. Problem: Interferes with the user’s daily use of the device.

5. Vision: Protecting cellular communication and private data from being used by people other the device’s owner without interfering with the user’s daily use of the device. The problem: How can the device authenticate its user without prompting for password before each action? The answer: Authenticate the user by its behavior.

6. Proposed solution: Using an anomaly detection algorithms to detect anomalies in the user’s behavior. The system will study and recognize its rightful owner. On detecting an immoderate abnormal in behavior, the system will assume the device is no longer in possession of its rightful owner and therefore will lock the device.

7. Thesis: • Each person behaves differently when interacting with the device. • Examples to characteristics which distinct users: • Keyboard typing speed. • Screen movement speed and strength. • Dialing speed. • Out going calls and outgoing text messages. • And so on…

8. System architecture and technologies:

9. Main functional requirements: • The building block of all operations: • Extracting user behavior parameters from the Android OS.

10. Main functional requirements: (cont.) • 3 modes of operation: • Learning mode • Learning the owner’s behavior. • Building a default profile. • Monitoring mode • Monitoring current user behavior. • Alerting when an abnormal deviation in behavior in discovered. • Research mode • Continuously collecting behavioral data. • (For algorithms comparison and rating)

11. Main functional requirements: (cont.) • Modes exclusiveness : • The system will be in one of the three modes in each given time. The system will be initialized in the learning mode by default. • Modes transition: • The system will automatically step into the monitoring mode after gathering enough information about the owner’s behavior.

12. Main functional requirements: (cont.) Definitions: Behavioral vector - A list of comparable scaling values. Each value represents a behavior of a monitored characteristic. Therefore, the vector itself describes the instantaneous user behavior regarding all monitored characteristics. Default profiles - The average vectors of all behavioral vectors which were constructed in the learning mode. These vectors represent the rightful owner’s behavior when using the device regarding all monitored characteristics. There are 2 different default profiles: open keyboard profile and closed keyboard profile. This is due to differences in behavior in each case.

13. Main functional requirements: (cont.) • Building behavioral vectors: • The system will collect the accumulated data of all the characteristics and will build a behavioral vector of the instantaneous user behavior. • Building default profile: • In the learning mode, the system will continuously (every time quantum) collect the latest behavioral vector and will build the default profile from it. • Deviation calculation: • In the learning mode, the system will continuously (every time quantum) collect the latest behavioral vector, will compare it to the default profile and will calculate the distance of the deviation between these vectors.

14. Main functional requirements: (cont.) • Decision making: • The system will decide, using the anomaly detection algorithm, whether or not the current user is the rightful owner of the device. • The system will use Negative Selection algorithm.

15. Main functional requirements: (cont.) • Lock signaling: • If the system decided that the current user is not the rightful owner it should signal an external lock/authenticate application to lock the device. • Data export: • The system will be able to generate a file in a predefined format containing the default profile and the behavioral vectors which defines it in a specified time period. This file will be used for further analysis by the research application and for backup (profile migration). • Data import: • The system will be able to import profile from a file of a predefined format in order to achieve profile migration capabilities.

16. Main functional requirements: (cont.) • Research - Compare profile with vectors: • This part of the system will be implemented as separated software for PCs. • The system will be able to read 2 predefined files, each contains a profile vector and a list of the behavioral vectors that defines it. • Let the 1st file contain profile p1 and a list of vectors v1. • Let the 2nd file contain profile p2 and a list of vectors v2. • The system will calculate the distance between the pairs • <p1,v1> , <p2,v2> , <p1,v2> , <p2 , v1>. • The first two pairs should yield no alerts while the last two pairs should yield many deviation alerts.

17. Non-functional requirements: • Speed: • The generation of a behavioral vector, calculating its deviation from the default profile and signaling the alert will take less than 1 second. • The time required to detect a device theft cannot be determined in advance. It depends how the thief resembles the owner in behavior and other variables of the algorithm. • Capacity: • The above time limits must apply to a minimum 20 monitored features.

18. Non-functional requirements: (cont.) • Safety & security: • All user data (vectors, profiles and configurations) must be protected by the system and be inaccessible to other users. The user will not be able to close the application without authentication. This will prevent a thief from avoiding detection. • Portability: • The implementation of the research application software must be platform independent. • The Andromaly application will run only on top of the Android platform and will not require any portability.

19. Non-functional requirements: (cont.) • Reliability: • Algorithm failures - Not all anomaly detections are suited to match this type of behavioral detection. The research application will help to find the best suited algorithm to problem. • Behavioral failures - All behavioral sequences has random anomaly points. We cannot signal an alert based on 1 anomaly point. We will smooth the behavioral anomalies by using a moving average. In this way the system will alert only after detecting a continuously abnormal behavior. • Memory failure - The android platform memory management allows the OS to close the system to free more memory if needed. In this case, the OS closes the system and executes it immediately after the memory can be reallocated. For this, the system must support data recovery and save its state at all time in order to be able to recover after being closed.

20. Non-functional requirements: (cont.) • Usability: • The user has little interaction with the system. Accept for configuring a few predefined system features, the system entirely runs in the background and has no interaction with the user. Therefore, the user will have no difficult learning to use the system. • Availability: • The system will be available 95% of the time. This depends on the OS memory management. The system can help increase its availability by keeping minimal memory consumption.

21. Non-functional requirements: (cont.) • Platform constraints: • Java code constraint - The Android platform runs Java applications and therefore forces the system to be written in Java. • C code constraint - If needed, parts of the system will be written in C/C++ in order to retrieve low-level data from the Android platform. This will happen in case the platform will not allow the programmers to retrieve sufficient data by using only Java code. • IDE constraint - The only fully usable plugin for the Android platform is for the Eclipse IDE. This forces the programmers to develop the system this IDE.

22. Use cases: Extracting data and building behavioral vector Primary actor: Feature extractor. Brief description: When a monitored characteristic has changed, its data is extracted, accumulated and stored in the behavioral vector. Trigger: Monitored behavior action event. Preconditions: Postconditions: The instantaneous behavioral vector is updated. Sequence diagram:

23. Use cases: (cont.) Building default profile Primary actor: Anomaly detector. Brief description: In the learning mode, every predefined time quantum (on time trigger) the instantaneous behavioral vector is read, stored and accumulated into the default profile vector. Trigger: Time trigger / read vector event. Preconditions: The System is in the learning mode. Postconditions: The default profile vector is updated. Sequence diagram:

24. Use cases: (cont.) Calculating deviation of instantaneous behavioral vectors Primary actor: Anomaly detector. Brief description: In the monitoring mode, every predefined time quantum (on time trigger) the instantaneous behavioural vector is read and compared to the default profile using the anomaly detection algorithm. Trigger: Time trigger / read vector event. Preconditions: The System is in the monitoring mode. Postconditions: A decision is made whether to signal an alert or not. Sequence diagram:

25. Use cases: (cont.) Signaling an abnormal deviation Primary actor: Anomaly detector. Brief description: When the system has decided that device is no longer in the hands of its rightful owner, it signals the lock/authenticate application to lock the device. Trigger: Alert event. Preconditions: The System is in the monitoring mode. Postconditions: The device is locked. Sequence diagram:

26. Use cases: (cont.) Switching to monitoring mode Primary actor: Anomaly detector. Brief description: When the system decides that the default profile has sufficient information to describe the user behavior it automatically switches from the learning mode to the monitoring mode. Trigger: Default profile is ready event. Preconditions: The system is in the learning mode. Postconditions: The system is in the monitoring mode. Sequence diagram:

27. Use cases: (cont.) Changing system configurations Primary actor: Anomaly detector. Brief description: The user can change predefined configurations of the system. Trigger: User. Preconditions: Postconditions: System configuration has changed. Sequence diagram:

28. Use cases: (cont.) Observing system status Primary actor: Anomaly detector. Brief description: The user can ask the system to display predefined info regarding the system’s status. Trigger: User. Preconditions: Postconditions: System status is displayed to the user. Sequence diagram:

29. Risk management: Difficulty in extracting various characteristics variables. Cause: The level of details and correctness of the information the Android platform exposes to the programmer. Solution: Finding a large number of characteristics which can define a user behavior. In this way, the system will be able to build a user profile even if a few characteristics from this list will not be exposed by the Android platform. From first experience with the Android platform, it seems possible to read many characteristics in a detailed form. In some cases, it is possible retrieve more low level information by executing C code applications.

30. Risk management: (cont.) Problems with the algorithm accuracy. Cause: Not all anomaly detections are suited to match this type of behavioral detection. Solution: building a generic mechanism which allows the programmer to experience with different algorithms with ease and with no changes in code. The research application will help to find the best suited algorithm to problem.

31. Thanks for listening…