State space blow-up in the verification of secure smartcard interoperability

Smartcards are used in a wide range of applications including electronic (e-) driving licenses, e-identity cards, e-payments, e-health cards, and digital signatures. Nevertheless secure smartcard interoperability has remained a significant challenge. Currently the secure operation of smartcards is certified (e.g. through the Common Criteria) for a specific and closed environment that does not comprise the presence of other smartcards and their corresponding applications. To enable secure smartcard interoperability one must, however, explicitly consider settings in which different smartcards interact with their corresponding applications, i.e. not in isolation. Consequently the interoperability problem is only insufficiently addressed in security verification processes. In an ideal scenario one should be able to certify that introducing a new type of smartcard into an environment in which several smartcards safely interoperate will have no detrimental side-effects for the security and interoperability of the existing system as well as for the new smartcard and its associated applications. In this work, strong experimental evidence is presented demonstrating that such certification cannot be provided through common model checking approaches for security verification due to state space blow-up. Furthermore it is shown how the state space blow-up can be prevented by employing a verification protocol which, by taking the results of the Common Criteria certification into account, avoids checking any transitions that occur after an illegal transition has been detected. © 2012 IEEE

Simulation based verification of concurrent processing on security devices

Despite the increased use of smartcards in many areas of everyday life the secure interoperability of these devices still remains a significant challenge. Common Criteria certification ensures the secure operation of a particular smartcard in a specific and closed environment and does not explicitly consider potential problems in more open environments where different types of smartcards and their corresponding applications are present at the same time. Since both the range of smartcard applications and the issuing manufacturers continue to grow, the interoperability of smartcards cannot be satisfactorily addressed in an isolated testing and certification environment. Ideally, one should be able to certify that adding a new type of smartcard and a new smartcard application to a such environment is safe without interoperability problems. To conduct this research, we focus on digital signature applications on Common Criteria certified smartcards. We investigated the vulnerabilities of smartcards in such open environments and possible ways to identify and eliminate those using Model Checking approaches. Here we simulate the interaction of many smartcards which interact with their applications via a common middleware. Each smartcard is assumed to execute a Straight Line Program which consists of a series of states or nodes connected by transitions (no loops). We discuss how these results can be taken into account in the design of new types of middleware which can identify and suppress anomalous transitions. These results will help to design systems that support multiple smartcards types and applications simultaneously and securely. © 2013 IEEE

Understanding and granting android permissions: A user survey

Whenever users install a new application on their smart devices with an Android KitKat or Lollipop operating system they are asked to grant the application (app) provider access to features of the device, ranging from data storage to device location and from device identity to the users personal contacts. The implications on users' privacy and security are significant and therefore the users' ability to give informed consent is highly important. Previous work has identified low rates of user attention and comprehension to permission warnings and concluded that these fail to inform the majority of users. Here we focus on how users consider, interpret and react to differences in app permission information which is provided at three different instances of the app installation cycle: 1. Before installation in the Google Play Store 2. During the installation process 3. After installation in the Application Manager. The information provided in these instances varies considerably in its granularity and detail. For this purpose, an online survey was developed in which users were asked questions regarding the installation of a mirror app whose main functionality is to use the user facing camera of the phone to mirror the users face (i.e. display an image of the face) on the phone's screen. The survey participants were shown screen shots of the app description as presented in the Google Play Store as well as of the various permission lists as they appear on the screen of the phone. The questions focused on the respondents' perceptions and their hypothetical choices with regard to the installation of this app. Results show that the various presentations of permission information in Android versions KitKat or Lollipop cause concern and irritate a majority (51.67%) of users, especially those with some basic IT expertise. We conclude that the contextualization of app features and functionalities with the corresponding permissions needs to be improved especially for users with little IT expertise. Further user permission information should be made available at different and consistent levels of granularity