Search

Context: Programmers frequently look for the code of previously solved problems that they can adapt for their own problem. Despite existing example code on the web, on sites like Stack Overflow, cryptographic Application Programming Interfaces (APIs) are co monly misused. There is little known about what makes examples helpful for developers in using crypto APIs. Analogical problem solving is a psychological theory that investigates how people use known solutions to solve new problems. There is evidence that the capacity to reason and solve novel problems a.k.a Fluid Intelligence (Gf ) and structurally and procedurally similar solutions support problem solving. Aim: Our goal is to understand whether similarity and Gf also have an effect in the context of using cryptographic APIs with the help of code examples. Method: We conducted a controlled experiment with 76 student participants developing with or without procedurally similar examples, one of two Java crypto libraries and measured the Gf of the participants as well as the effect on usability (effectiveness, efficiency, satisfaction) and security bugs. Results: We observed a strong effect of code examples with a high procedural similarity on all dependent variables. Fluid intelligence Gf had no effect. It also made no difference which library the participants used. Conclusions: Example code must be more highly similar to a concrete solution, not very abstract and generic to have a positive effect in a development task., Comment: 2 pages

Context: Cryptographic APIs are said to be not usable and researchers suggest to add example code to the documentation. Aim: We wanted to create a free platform for cryptographic code examples that improves the usability and security of created applications by non security experts. Method: We created the open-source web platform CryptoExamples and conducted a controlled experiment where 58 students added symmetric encryption to a Java program. We then measured the usability and security. Results: The participants who used the platform were not only significantly more effective $( +73$ %) but also their code contained significantly less possible security vulnerabilities (-66 %). Conclusions: With CryptoExamples the gap between hard to change API documentation and the need for complete and secure code examples can be closed. Still, the platform needs more code examples.

Context: Poor usability of cryptographic APIs is a severe source of vulnerabilities. Aim: We wanted to find out what kind of cryptographic libraries are present in Rust and how usable they are. Method: We explored Rust's cryptographic libraries through a systematic search, conducted an exploratory study on the major libraries and a controlled experiment on two of these libraries with 28 student participants. Results: Only half of the major libraries explicitly focus on usability and misuse resistance, which is reflected in their current APIs. We found that participants were more successful using rust-crypto which we considered less usable than ring before the experiment. Conclusion: We discuss API design insights and make recommendations for the design of crypto libraries in Rust regarding the detail and structure of the documentation, higher-level APIs as wrappers for the existing low-level libraries, and selected, good-quality example code to improve the emerging cryptographic libraries of Rust.

As Smart Devices have access to a lot of user-preferential data, they come in handy in any situation. Although such data—as well as the knowledge which can be derived from it—is highly beneficial as apps are able to adapt their services appropriate to the respective context, it also poses a privacy threat. Thus, a lot of research work is done regarding privacy. Yet, all approaches obfuscate certain attributes which has a negative impact on context recognition and thus service quality. Therefore, we introduce a novel access control mechanism called PATRON. The basic idea is to control access to information patterns. For instance, a person suffering from diabetes might not want to reveal his or her unhealthy eating habit, which can be derived from the pattern “rising blood sugar level” “adding bread units”. Such a pattern which must not be discoverable by some parties (e. g., insurance companies) is called private pattern whereas a pattern which improves an app's service quality is labeled as public pattern. PATRON employs different techniques to conceal private patterns and, in case of available alternatives, selects the one with the least negative impact on service quality, such that the recognition of public patterns is supported as good as possible.

Applications for the Internet of Things are becoming increasingly popular. Due to the large amount of available context data, such applications can be used effectively in many domains. By interlinking these data and analyzing them, it is possible to gather a lot of knowledge about a user. Therefore, these applications pose a threat to privacy. In this paper, we illustrate this threat by looking at a real-world application scenario. Current state of the art focuses on privacy mechanisms either for Smart Things or for big data processing systems. However, our studies show that for a comprehensive privacy protection a holistic view on these applications is required. Therefore, we describe how to combine two promising privacy approaches from both categories, namely AVARE and PATRON. Evaluation results confirm the thereby achieved synergy effects.

Context: System Theoretic Process Analysis for Privacy (STPA-Priv) is a novel privacy risk elicitation method using a top down approach. It has not gotten very much attention but may offer a convenient structured approach and generation of additional artifacts compared to other methods. Aim: The aim of this exploratory study is to find out what benefits the privacy risk elicitation method STPA-Priv has and to explain how the method can be used. Method: Therefore we apply STPA-Priv to a real world health scenario that involves a smart glucose measurement device used by children. Different kinds of data from the smart device including location data should be shared with the parents, physicians, and urban planners. This makes it a sociotechnical system that offers adequate and complex privacy risks to be found. Results: We find out that STPA-Priv is a structured method for privacy analysis and finds complex privacy risks. The method is supported by a tool called XSTAMPP which makes the analysis and its results more profound. Additionally, we learn that an iterative application of the steps might be necessary to find more privacy risks when more information about the system is available later. Conclusions: STPA-Priv helps to identify complex privacy risks that are derived from sociotechnical interactions in a system. It also outputs privacy constraints that are to be enforced by the system to ensure privacy., Comment: author's post-print

Due to non-experts also developing security relevant applications it is necessary to support them too. Some improvements in the current research may not reach or impact these developers. Nonetheless these developers use security libraries. There are findings that even their usage is not easily possible and applications are left vulnerable to supposedly treated threats. So it is important to improve the usability of the security libraries. This is itself is not straightforward because of a required maturing process for example. By getting together experts of different involved areas, especially cryptographic and API-usability experts, both of the problems can be tackled., Comment: ICSE 16 May 16-16 2016, Austin, TX, USA (CHASE)