SeMA: A Design Methodology for Building Secure Android Apps

by   Joydeep Mitra, et al.
Kansas State University

UX designers use storyboards to visually capture a user experience (UX) of an app. Lately, storyboarding is used by Android app development to conceptualize and design apps. Recently, security has become an integral part of Android app UX because mobile apps are used to perform critical activities such as banking, communication, etc. Therefore, it is imperative for app creators to ensure the security of their users. In this context, storyboarding tools offer limited capabilities to capture and reason about security requirements of an app. Consequently, security cannot be baked into the app at design time. This allows vulnerabilities that stem from design flaws to creep into apps. To address this concern, we propose a storyboard based design methodology that will enable specification and verification of security properties of an Android app at design time.



There are no comments yet.


page 2


SeMA: Extending and Analyzing Storyboards to Develop Secure Android Apps

As security of mobile apps is crucial to modern-day living, there is a g...

SOURCERER: Developer-Driven Security Testing Framework for Android Apps

Frequently advised secure development recommendations often fall short i...

Android Inter-App Communication Threats, Solutions, and Challenges

Researchers and commercial companies have made a lot of efforts on detec...

An Android Application Risk Evaluation Framework Based on Minimum Permission Set Identification

Android utilizes a security mechanism that requires apps to request perm...

CryptoEval: Evaluating the Risk of Cryptographic Misuses in Android Apps with Data-Flow Analysis

The misunderstanding and incorrect configurations of cryptographic primi...

Security Smells Pervade Mobile App Servers

[Background] Web communication is universal in cyberspace, and security ...

Improving the Reliability of Mobility Applications

The Android platform was introduced by Google in 2008 as an operating sy...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Why SeMA?

Android app development teams use storyboarding as part of their design process [16, 10]. A storyboard is a sequence of images or graphics that serves as a specification of the user expected or observed behavior in terms of screens and transitions between screens [17]. Storyboarding helps designers 1) identify different kinds of app users (user profiles) , 2) explore possible real world scenarios in which a user will interact with the app, and 3) develop wireframes to capture the scenarios for identified user profiles. Numerous tools such as Xcode [1], Sketch [14], and OmniGraffle [8] help designers digitally express the storyboard of an app.

In the digitally expressed storyboard shown in Figure 1, the storyboard captures various screens in an app. The lines between screens denote the possible transitions between screens. Different colored lines denote transitions in different use cases.

Figure 1: A Storyboard Example.

Storyboading is meant to be participatory because it can be used by designers to get feedback from potential users about likely user scenarios, and from developers about the technical challenges of implementing the design. However, the storyboard does not capture non-functional requirements such as security. Consequently, Android app designers and developers cannot use storyboarding to collaborate and express security requirements at the design level.

The lack of security specifications at the design stage postpones security verification to a later stage. Vulnerabilities due to flaws detected at later stages increase the cost of development as the design may have to be modified to fix the flaw. Therefore, to make security a first-class citizen in Android app design process, we propose a new methodology that storyboards with additional capabilities to allow the specification and verification of security requirements.

To understand the reasons for considering a new methodology and its benefits, we need to understand the current landscape of Android app development practices.

Today, developers consider the security requirements of an app while or after implementing the app. Existing research efforts related to Android app security have focused on developing tools and techniques to help detect vulnerabilities in an app’s implementation (as opposed to a app’s design) [15, 6]. In spite of such efforts, apps with known vulnerabilities find their way to app stores [12, 3]. This is (possibly) because existing tools are neither accurate [11] nor scalable [9] in terms of detecting known vulnerabilities. A complementary approach to help secure the Android ecosystem is to develop tools and techniques to identify malicious apps and keep them out of the ecosystem. However, the lack of such tools that accurately (i.e., low false-positives and false-negatives) identify malicious apps and the innocent-until-proven-guilty philosophy adopted by most Android app stores (e.g., Google Play) enables malicious apps to enter app stores [5, 18]. Given this landscape, we believe it is worthwhile to explore the unexplored: design methodologies to preemptively eliminate vulnerabilities by enabling developers and designers to consider security at the design stage of app development process.

Besides complementing existing curative techniques, such methodologies will help explore numerous interesting research questions such as:

  • How much effort is required to formally reason about Android apps at the design level?

  • In the context of Android app development, is secure-by-design cost effective?

  • Is verifying an app based on its design and storyboard easier than verifying it based on its code?

  • In terms of improving security, how do preventive approaches compare to curative approaches?

2 What is SeMA?

Motivated by the aforementioned reasons, we propose a design methodology based on storyboarding to specify Android app behavior and its security requirements, and verify if these requirements are satisfied by the app’s design.

Realizations of this methodology will require a specification language in which the behavior of apps (including security properties) can be specified. Since the proposed methodology is based on storyboarding, the specification language will have a visual aspect, i.e., to specify the UI elements. In the domain of Android app development, a visual specification language can have numerous advantages over textual specification languages. First, a visual specification based on storyboards is closer to the mental model that designers and developers have of an app as an Android app is conceptualized as a bunch of screens. Second, a visual specification language will preserve the participatory nature of storyboarding, i.e., designers and developers can participate in the specification of the app on a common substrate – storyboard. Third, pictures are more expressive than words. Research has suggested that graphical representation of complex algorithms are sometimes easier to comprehend than textual representations [13]. Similarly, representing security requirements visually might help developers understand app security better which will (hopefully) result in building secure apps.

While existing storyboarding techniques enable an app designer to specify the screens of an app and the transitions between the screens, they do not enable the specification of more detailed behavior, e.g., in a storyboard, it is not possible to say a background service will send an SMS message when user clicks the Send button. In other words, a key challenge with visual specification language is to ensure the ability to specify what the app should do is as easy and intuitive as the ability to specify UI elements of an app.

2.1 An Illustrative Example

We now present the idea of the proposed methodology through an example.

Consider the development of an app that sends a message to a set of pre-identified contacts at the push of a button.

2.1.1 App Specification

Figure 2: Storyboard of the Emergency App. The clouds are not part of the storyboard; they provide information about the different grahical elements in the figure.

Figure 2 shows the storyboard of our example app along with brief description of various concepts captured in the storyboard. Initially, the required screens, transitions between the screens, and the user actions that enable a transition are specified. This is similar to how storyboards are used in designing apps today. The following describes the initial snapshot of the UI view in Figure 2:

  • Messenger screen is the Launcher screen, i.e., the screen shown when the user starts the app for the first time. When Add button is pressed, the app transitions to the Contacts screen.

  • Contacts screen has a text field named Phone and a button named Save. When Save button is pressed, the app transitions to the SaveStatus screen.

  • When SendMsg button is pressed, the app transitions to the MsgStatus screen.

Next, the designer refines the storyboard with additional behavior. For example, the designer adds a constraint (marked in green) to the transition from the Contacts screen. Other transitions in the app are also enriched with constraints.

Most of the constraints rely on operations provided by resources in the device. These resources are pre-defined. Apps can specify the view of a resource they will use.

The resource view of the app is shown in Figure 2. The description of the resources and the semantics of the operations available in the view is as follows:

  • EXT_STORE denotes the external storage on Android devices that can be accessed by all apps installed on the device. It offers many capabilities, the app uses 2 of those capabilities which are as follows:

    • write(f,p): The semantics of the write operation is the value p is written into file f. It returns true if the write succeeds; false, otherwise.

    • read(f): The semantics of the read operation is to read a value from file f.

  • SMS denotes a resource to send a SMS message m from the device to the list of phone numbers p via its send(m, p) operation, which returns true if the message was sent successfully; false, otherwise.

The final storyboard with all the behavior and resource operations specified will look like Figure 2. To give an example of how the constraints in a transition should be interpreted, consider the transition from Messenger screen to MsgStatus screen. This transition is taken when the SendMsg button is pressed, and an SMS message is successfully sent to the phone numbers in the file named MyContacts.txt.

2.1.2 Analysis

We envision the methodology will initially support the checking of pre-defined security properties that are based on classes of known vulnerabilities that plague Android apps [7].

In this example, suppose the developers are interested in the violation of the following property:

  • malicious input should not influence data flow in the app.

Based on the semantics of EXT_STORE, all apps can access data in EXT_STORE. Hence, EXT_STORE can possibly contain malicious inputs as malicious apps can modify the contacts stored by the example app. Since the data from EXT_STORE is used in SMS.send(…) constraint, a violation of the property is detected by analyzing the data flow through the storyboard in accordance with the semantics of resources used by the app.

This vulnerability can be fixed by storing the phone numbers in a more secure way. For example, MyContacts.txt file can be stored in the app’s internal storage that is accessible only by the app. This intention can be expressed in the storyboard by using a resource that denotes the internal storage. This fix can be suggested by the tooling support.

3 Class of vulnerabilities that can be eliminated with SeMA

SEMA is envisioned to be a design methodology to prevent vulnerabilities that stem from design flaws. This raises two questions arise: 1) relevance – how many vulnerabilities in Android apps arise due to design flaws? and 2) effectiveness – how many of these vulnerabilities can be prevented by such a methodology?

Answering this question requires a classification of the known vulnerabilities that plague Android apps. Existing efforts have identified known vulnerabilities that plague Android apps and have developed benchmarks to capture them [7, 2]. Ghera [7]

is one such benchmark suite that captures 56 known vulnerabilities in Android apps. Most of the vulnerabilities captured in Ghera can be classified as follows:

  1. Reliance on Data from Potentially Malicious Sources: An Android app X can interact with other apps locally, i.e., apps in the device or remotely (e.g., web apps). Consequently, other apps can request app X to perform an action on its behalf. If app X blindly trusts an input from an external source (a component not in X) and uses it to manipulate data or make a critical decision, then app X is vulnerable to exploitation.

  2. Disclosure of Sensitive Information: An app can accidentally expose sensitive information. For example, suppose an app needs device ID to track the devices it is installed on. For this purpose, it accesses device ID (after asking permission from the user) and saves it accidentally in external storage. Since external storage can be accessed by all apps in the device, a malicious app will be able to access the device ID without having appropriate permissions.

  3. Exposure of Privileged Resources: In Android apps can access privileged resources only if the apps are granted required permission by the user or Android system. An app with access to privileged resources can accidentally enable privilege escalation. For example, suppose app X has been granted permission to read the user’s messages. If app X is designed with a component that reads user messages and can be accessed by other apps, then a malicious app can retrieve user messages even without having required permissions.

All of the above classes of vulnerabilities stem from design oversight. SeMA aims to eliminate the vulnerabilities due to these reasons.

However, there are vulnerabilities that stem from implementation errors, e.g., using the HTTP protocol to communicate with a remote server as opposed to using HTTPS. While such vulnerabilities cannot be eliminated by design verification, they can be eliminated by using appropriate code generation schemes. The code generation can make appropriate changes and inform the user about those changes.

4 Challenges

The development of SeMA offers some interesting challenges which need to be addressed for realizing the methodology. The following points identify a few of these challenges:

  1. Context aware analysis: Android apps do not run in isolation. They communicate with remote servers, other apps on the device, the underlying Android framework, etc. Therefore, the security of an app depends on the context in which it is operating. Security analysis of app storyboards will have to be aware of such contexts; otherwise, the analysis will be imprecise. To appreciate this issue, consider the example in Figure 3. In this example, sensitive information111By sensitive information, we mean that the information is private to the entity owning the information. Hence, it can only be accessed by that entity or by an authorized entity. and non-sensitive information arrive at widget W via the red and green colored transitions, respectively, while information that might be sensitive propagates from W to a remote server R via the blue colored channel. Now, should a security analysis flag this example as disclosing sensitive information? That depends on the context – is the disclosed information sensitive? and is the entity receiving the information trustworthy222An entity is trustworthy if it can be trusted to keep the information secure? An accurate analysis should not only consider the answers to these questions but also the feasible combinations of these answers. This aspect can make the analysis challenging even on abstract models such as storyboards.

    Figure 3: Example of a storyboard where information in widget W is propagated to a remote server R.
  2. Scalability of analysis: To be accurate and effective, security analysis of Android apps will have to consider various contexts and rich features of the Java (or Kotlin) programming language used to implement the apps. Such analysis are neither scalable [9] nor accurate [11] as they are plagued by the challenges faced by non-trivial source code analysis [6]. However, similar analysis can be performed easily at design time on abstract models such as storyboards that involve finite number of screens and transitions and possibly smaller value domains. However, even such design-time analysis can face scalability issues as the richness of both the security properties to be checked and the app behavior captured in storyboards increases.

  3. Reactive nature of Android apps: Android apps interact with the underlying platform via platform-defined application lifecycle methods to handle the numerous system and user events. These events could trigger the execution of an app from different unrelated entry points. Also, apps have the ability to persist information across different executions. This allows for different executions of an app that start at different entry points to be implicitly related by persisted data. Considering this possibility to accurately reconstruct the behavior of an app for the purpose of security reasoning can be a challenge.

  4. Storyboards extensions to capture non-UI behavior: Today, storyboards of Android apps capture only the UI components of an app and behavior triggered by user actions, e.g., user action triggered transitions between screens. However, Android apps also exhibit behavior not related to UI of an app, e.g., few of the transitions in the earlier illustrative example are associated with non-UI related constraints. Therefore, existing storyboards will have to be extended with features to capture behavior that stem from non-UI elements while not disrupting the workflow and the mental model associated with storyboarding. From the perspective of language design, developing a rich and intuitive specification language that captures both visual and non-visual aspects of Android app behavior can be a challenge.

  5. Evaluation of SeMA: Evaluating the effectiveness of SeMA will involve conducting a usability study. Designing an effective usability study has numerous challenges [4] such as getting users to use the methodology, selecting a representative group of users, developing the metrics to measure usability etc.


  • [1] Apple. Storyboards in Xcode., 2019. Accessed: 05-Feb-2019.
  • [2] Erika Chin. Helping Developers Construct Secure Mobile Applications. PhD thesis, University of California, Berkeley, USA, 2013. Available at
  • [3] Maria Gomez, Romain Rouvoy, Martin Monperrus, and Lionel Seinturier. A Recommender System of Buggy App Checkers for App Store Moderators, 2014. Available at Online Tech Report.
  • [4] Kasper Hornbaek. Current practice in measuring usability: Challenges to usability studies and research. International Journal of Human-Computer Studies, pages 79 – 102, 2006.
  • [5] Yosuke Kikuchi, Hiroshi Mori, Hiroki Nakano, Katsunari Yoshioka, Tsutomu Matsumoto, and Michel van Eeten. Evaluating malware mitigation by Android market operators. In 9th Workshop on Cyber Security Experimentation and Test (CSET 16). USENIX Association, 2016.
  • [6] Li Li, Tegawendé F. Bissyandé, Mike Papadakis, Siegfried Rasthofer, Alexandre Bartel, Damien Octeau, Jacques Klein, and Le Traon. Static analysis of android apps: A systematic literature review. Information and Software Technology, pages 67 – 95, 2017.
  • [7] Joydeep Mitra and Venkatesh-Prasad Ranganath. Ghera: A repository of android app vulnerability benchmarks. In Proceedings of the 13th International Conference on Predictive Models and Data Analytics in Software Engineering, pages 43–52. ACM, 2017.
  • [8] OmniGraffle. Sketch designs with OmniGraffle., 2019. Accessed: 05-Feb-2019.
  • [9] Felix Pauck, Eric Bodden, and Heike Wehrheim. Do android taint analysis tools keep their promises? In Proceedings of the 2018 26th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, ESEC/FSE 2018, pages 331–341. ACM, 2018.
  • [10] Dmitry Prudnikov. UX design techniques for mobile apps., 2019. Accessed: 05-Feb-2019.
  • [11] Venkatesh-Prasad Ranganath and Joydeep Mitra. Are free android app security analysis tools effective in detecting known vulnerabilities? CoRR, 2018.
  • [12] Alireza Sadeghi, Naeem Esfahani, and Sam Malek. Mining the categorized software repositories to improve the analysis of security vulnerabilities. In International Conference on Fundamental Approaches to Software Engineering, pages 155–169. Springer, 2014.
  • [13] David A. Scanlan. Structured flowcharts outperform pseudocode: An experimental comparison. IEEE Softw., pages 28–36, 1989.
  • [14] Sketch. Sketch Design ToolKit., 2019. Accessed: 05-Feb-2019.
  • [15] Sufatrio, Darell J. J. Tan, Tong-Wei Chua, and Vrizlynn L. L. Thing. Securing Android: A survey, taxonomy, and challenges. ACM Comput. Surv., 47(4):58:1–58:45, 2015.
  • [16] Marcus Trapp and René Yasmin. Addressing animated transitions already in mobile app storyboards. In Aaron Marcus, editor, Design, User Experience, and Usability. Web, Mobile, and Product Design, pages 723–732. Springer Berlin Heidelberg, 2013.
  • [17] Wikipedia. Storyboard., 2019. Accessed: 05-Feb-2019.
  • [18] Yajin Zhou, Zhi Wang, Wu Zhou, and Xuxian Jiang. Hey, you, get off of my market: Detecting malicious apps in official and alternative Android markets. In 19th Annual Network and Distributed System Security Symposium, NDSS 2012, San Diego, California, USA, February 5-8, 2012, 2012.