Figure 8.3 – Micro-architecture extraction process.
developers will not implement security features by themselves. Rather, they use the security features provided by the framework or library to secure their applications. Moreover, Gamma et al. mentioned in their design patterns book that they observed many patterns by inspecting common frameworks and libraries [173]. They assume that these reusable software pieces provide well-established solutions because of their frequent usage and well-designed architecture. Thus, we “make patterns more specific to a particular domain” as suggested by Yoshioka et al. by analyzing frameworks and libraries [539].
Procedure
First of all, the pattern description is read and the security problems to be solved by the pattern is distilled (Figure 8.3). Based on the given information, we looked into Android programming books and searched the Internet for clues implementing the described security feature. Then the collected examples were tested and evaluated as to whether the example code solves the problem described by the selected security pattern. In the next step, essential clues within the API were identified and code examples to extract the necessary parts of using the API. These code examples consist of small code modifications that preserve the security feature of the example and represent their essentials. Based on these minimal reproducers a micro-architecture of the pattern was constructed by identifying structural properties that ensure the security feature on the tested examples.
Limitations
Our approach is limited by the chosen framework API and the collected examples of each security pattern. These limitations can be addressed in further work by considering external libraries and further examples expressing security-pattern requirements. For example, sometimes more libraries for the same issue exist. In this case, the software solutions can be compared and similar subsystems or class combinations may indicate a best practice.
8.2
Security Patterns and Android Security
As part of the discovering process, a domain has to be selected. In this thesis, the domain of Android applications was chosen. These applications are highly available
(through Google Play [190]) and have often documented security problems [352]. In the following sections, we select patterns that are interesting for the security of Android applications and collect the different variants for each selected pattern.
8.2.1
Patterns Relevant to Securing Android Apps
Since the publication of the GoF design patterns many security patterns have been published (Chapter 3). In that literature review, we identified over 190 security patterns that are related to the Software and Cryptographic application domain (Chapter 4). It is expected that not all surveyed security patterns are relevant to developing secure Android applications.
Guidelines support developers to be aware of important security and privacy issues. They can be used as a kind of checklist before an application is made available. We consider these development guidelines as a good starting point for selecting security patterns that are not strictly based on the context and suitable for Android apps. Thus, the most relevant patterns for Android security are extracted by mapping them to secure developing guidelines.
8.2.2
Collecting Security Guidelines
The development guidelines are collected by conducting an Internet search with the keywords "smartphone app/application“ "mobile application” mobile app“ combined with ”secure“, ”security“, ”privacy“, "guideline”, and “guide”.
Guideline by Main Target Platform Language
ENISA [137] privacy & security neutral English
ICO [260] privacy neutral English
Google [188] security Android English
Düsseldorfer Kreis [36] privacy neutral German
German IT Summit [258] privacy & security neutral German
Table 8.1 – Collected guidelines discussing secure (Android) application development.
In total, five guidelines dealing with mobile security were found (see Table 8.1). Two of the five guidelines are written in German and the others in English. Three guidelines are issued by governmental or similar institutions [36, 137, 260]. One of the other two guidelines is published by Google Inc. [188], and the last one is issued by a group of companies focused on evaluation and certification in collaboration with the German Federal Office for Information Security (BSI) [258].
Most of the guidelines present the security and privacy issues in purely textual form and independent of a particular software platform. Only one guideline is platform-specific and provides code snippets for the Android platform [188]. The description of each security/privacy issue is often concise and only presents one side of the problem (attack or defense view). Other interesting aspects, such as consequences or a more concrete solution, are rarely given.
8.2 – Security Patterns and Android Security
8.2.3
Relating Patterns and Guidelines
Potentially relevant security patterns for ensuring security and privacy in mobile apps are determined by reading the collected guidelines. Thereby, the security patterns are aligned to the described security problems. For instance, “you should always use encrypted connections for transmitting usernames, passwords, and particularly sensitive information . . . ” [260] matches with the Secure Pipe pattern [464].
All security patterns mentioned in the guidelines were collected. Then the total of the occurrences for each security pattern was calculated. In total, 36 security patterns were mapped to the security issues mentioned in the guidelines. The whole mapping is given in Appendix E. In the next step, the five most frequently mentioned security patterns are inspected.
8.2.4
Selected Security Patterns
The following five patterns are mentioned by all guidelines:
∙ Information Obscurity [437] ∙ Secure Channel [437]
∙ Secure Pipe [464]
∙ Secure Communication [50] ∙ Authentication Enforcer [464]
We observed that some security patterns seem to describe the same security issue. The three patterns Secure Pipe, Secure Communication, and Secure Channel depict an encrypted connection. On comparing the three patterns directly with the help of the description section alignment described in Chapter 5, we figured out that they generally describe the same security feature. Therefore, the Secure Pipe pattern was chosen as a representative for encrypted communication.
The other patterns in the selected subset are distinct. Finally, the following security patterns for the further detection process were selected:
Authentication Enforcer enforces the authentication of a subject.
Information Obscurity generates a cryptographic key that can be used for encrypted storage.
Secure Pipe establishes a secure communication between two communication parties.