KeY is a tool that provides facilities for formal specification and verification of programs within a commercial platform for UML based software development. Using the KeY tool, formal methods and object-oriented development techniques are applied in an integrated manner. Formal specification is performed using the Object Constraint Language (OCL), which is part of the UML standard. KeY provides support for the authoring and formal analysis of OCL constraints. The target language of KeY based development is Java Card DL, a proper subset of Java for smart card applications and embedded systems. KeY uses a dynamic logic for Java Card DL to express proof obligations, and provides a state-of-the-art theorem prover for interactive and automated verification. Apart from its integration into UML based software development, a characteristic feature of KeY is that formal specification and verification can be introduced incrementally.

Abstract. When it comes to security, an interesting difference between Java Card and regular Java is the absence of an on-card bytecode verifier on most Java Cards. In principle this opens up the possibility of malicious, ill-typed code as an avenue of attack, though the Java Card platform offers some protection against this, notably by code signing.This paper gives an extensive overview of vulnerabilities and possible runtime countermeasures against ill-typed code, and describes results of experiments with attacking actual Java Cards currently on the market with malicious code. OverviewA huge security advantage of type safe language such as Java is that the low level memory vulnerabilities, which plague C/C++ code in the form of buffer overflows, are in principle ruled out. Also, it allows us to make guarantees about the behaviour of one piece of code, without reviewing or even knowing all the other pieces of code that may be running on the same machine.However, on Java Card smartcards [9] an on-card bytecode verifier (BCV) is only optional, and indeed most cards do not include one. This means that malicious, ill-typed code is a possible avenue of attack.Of course, the Java Card platform offers measures to protect against this, most notably by restricting installation of applets by means of digital signaturesor disabling it completely. Still, even if most Java Card smartcards that are deployed rely on these measures to avoid malicious code, it remains an interesting question how vulnerable Java Card applications are to malicious code. Firstly, the question is highly relevant for security evaluations of code: can we evaluate the code of one applet without looking at other applets that are on the card? Secondly, the defence mechanisms of the Java Card platform are not so easy to understand; for instance, there is the firewall as an extra line of defence, but does that offer any additional protection against ill-typed code, and can it compensate for the lack of BCV? And given the choice between cards with and without BCV, are there good reasons to choose for one over the other? (As we will show, cards with on-card BCV may still be vulnerable to ill-typed code!)In this paper we take a serious look at the vulnerability of the Java Card platform against malicious, ill-typed code. We consider the various ways to get G. Grimaud and F.-X. Standaert (Eds.): CARDIS

Summary. In this paper we discuss an efficient implementation of anonymous credentials on smart cards. In general, privacy-preserving protocols are computationally intensive and require the use of advanced cryptography. Implementing such protocols for smart cards involves a trade-off between the requirements of the protocol and the capabilities of the smart card. In this context we concentrate on the implementation of Microsoft's U-Prove technology on the MULTOS smart card platform. Our implementation aims at making the smart card independent of any other resources, either computational or storage. In contrast, Microsoft suggests an alternative approach based on device-protected tokens which only uses the smart card as a security add-on. Given our very good performance results we argue that our approach should be considered in favour of Microsoft's one. Furthermore we provide a brief comparison between Java Card and MULTOS which illustrates our choice to implement this technology on the latter more flexible and low-level platform rather than the former.

No abstract

Abstract. This paper reports on the experiences with the program verification competition held during the FoVeOOS conference in October 2011. There were 6 teams participating in this competition. We discuss the three different challenges that were posed and the solutions developed by the teams. We conclude with a discussion about the value of such competitions and lessons that can be learned from them.