Scientific and technical bulletin of the St. Petersburg State University of Information Technologies, Mechanics and Optics. Issue 53. Automatic programming. 2008, с In this case, the code is generated from a high-level description based on the technology of automatic programming. An additional advantage of this approach is the ability to generate a formal application specification. The conformity of the source or byte code to the specification can be checked by various verifiers or by means of dynamic or static checking. Introduction A smart card [1] is a plastic card in which a chip and memory are embedded, allowing to store and process information. In fact, smart cards are tamper-proof computers the size of a credit card. In addition to being protected, these cards have such advantages as mobility and ease of use. They provide information storage, authentication, are used in payment systems, mobile communications, etc. Java Card technology [1] adapts the Java platform for use on smart cards. In addition to the advantages inherent in Java technology (security, reliability, support for the principles of object-oriented programming, cross-platform, etc.), when using the technology in question, firstly, The development process is greatly simplified (the Java Card platform allows the programmer to abstract from the internal features of cards of each specific manufacturer), and, secondly, a mechanism for launching several applications on one card is introduced. The Java Card API is a "superset of a subset" of the Java API. This means that Java Card lacks support for multithreading, strings, multidimensional arrays, garbage collection, and so on due to limited card resources. However, the Java Card API has been extended with additional functionality necessary to solve the problems that arise when using smart cards. This extension includes sending and receiving (APDU) commands, working with PIN codes, cryptographic algorithms, and so on. Note that Java Card applications are commonly referred to as applets. To maintain logical integrity, some aspects of the Java Card technology will be described in more detail in those parts of the work where it is necessary for understanding. Formal methods are mathematically rigorous methods and tools for the specification, design and verification of software [2]. Similar to automata programming [3], their application in software engineering is based on the popular idea of using reliable and proven technologies from other engineering disciplines. The general purpose of using formal methods is to create robust software. There are a number of reasons [4] why Java Card technology is interesting for researchers in the field of formal methods. Firstly, Java Card applications are very security and reliability critical.
Which is explained by the specifics of the fields of application of smart cards, in which the cost of an error is very high. Secondly, Java Card is the most widely used Java platform in the world, as smart cards are issued in huge numbers. Therefore, unlike software for personal computers, updating or fixing applications on already issued cards can be quite time consuming and economically unprofitable. And finally, the limited resources and less functionality of the Java Card compared to Java technology ensures that programs do not have too complex behavior and a large number of control states [3]. Java Card applications can be a good training ground for a variety of formal methods. On the one hand, the programs in this case are quite simple, on the other hand, they are of specific practical interest, and are not artificially created "toy" code. Thus, the task of applying formal methods for designing and verifying Java Card applications seems to be relevant and realizable. The purpose of this work is to expand the technology of automata programming to create correct Java Card programs. At the same time, it is necessary to solve a number of problems related to the implementation of the possibility of generating the skeleton of the source code of Java Card applications and their subsequent verification at the level of the source and byte codes. Analysis of existing works It follows from the above that the analysis of existing works can be carried out in two directions, one of which is the generation of Java Card-code from high-level specifications, and the second is the verification of automatic programs. Generating Java Card Code from High-Level Specifications There are two research projects aimed at generating Java Card code from high-level specifications. The first of them [5] is based on the domain-specific language SmartSlang, which allows you to describe programs using high-level constructs typical for smart cards. However, it does not use an automaton approach, and therefore the project has little to do with the real work. The second project is considered in works [6, 7]. In these studies, the code is generated based on the state machine describing the applet. In [6], a verifier is used as an editor for finite state machines, and in [7], UML is used to describe automata. This work has several advantages over these studies. First, the technology of automatic programming is applied, which assumes the description of behavior by a hierarchical system of automata, and not just one automaton, as in [6, 7]. In [6], there remains an open question about modeling the host application itself and its interaction with a smart card. Distinguishing the host application as a separate event provider within the automaton approach largely solves this issue. The notation used in automata programming technology hides the low-level features of the Java Card language, which facilitates the process of developing programs and increases their reliability. Indeed, the programmer is offered to operate not with byte arrays, but with short identifiers, for which a textual description is always available. Second, the proposed approach generates a more complete and not just one automaton, as in [6, 7]. In [6], there remains an open question about modeling the host application itself and its interaction with a smart card. Distinguishing the host application as a separate event provider within the automaton approach largely solves this issue. The notation used in automata programming technology hides the low-level features of the Java Card language, which facilitates the process of developing programs and increases their reliability. Indeed, the programmer is offered to operate not with byte arrays, but with short identifiers, for which a textual description is always available. Second, the proposed approach generates a more complete and not just one automaton, as in [6, 7]. In [6], there remains an open question about modeling the host application itself and its interaction with a smart card. Distinguishing the host application as a separate event provider within the automaton approach largely solves this issue. The notation used in automata programming technology hides the low-level features of the Java Card language, which facilitates the process of developing programs and increases their reliability. Indeed, the programmer is offered to operate not with byte arrays, but with short identifiers, for which a textual description is always available. Second, the proposed approach generates a more complete Distinguishing the host application as a separate event provider within the automaton approach largely solves this issue. The notation used in automata programming technology hides the low-level features of the Java Card language, which facilitates the process of developing programs and increases their reliability. Indeed, the programmer is offered to operate not with byte arrays, but with short identifiers, for which a textual description is always available. Second, the proposed approach generates a more complete Distinguishing the host application as a separate event provider within the automaton approach largely solves this issue. The notation used in automata programming technology hides the low-level features of the Java Card language, which facilitates the process of developing programs and increases their reliability. Indeed, the programmer is offered to operate not with byte arrays, but with short identifiers, for which a textual description is always available. Second, the proposed approach generates a more complete the programmer is offered to operate not with byte arrays, but with short identifiers, for which a textual description is always available. Second, the proposed approach generates a more complete the programmer is offered to operate not with byte arrays, but with short identifiers, for which a textual description is always available. Second, the proposed approach generates a more complete
Specification. In particular, under certain restrictions, it is possible to generate preconditions for methods that are called upon entering a state. In [6], this question is also referred to as open. Finally, for the UniMod tool [8], a number of plug-ins have been developed that allow verification of the automaton model [9]. Note that in [6] the verifier is used exclusively as a graphical editor for creating automata, and its use for its intended purpose is mentioned only in the section describing further studies. However, in a later work [7], model verification is not mentioned at all. Moreover, the issue of code generation is considered secondary, and extracting an automaton model from the source code is considered an attractive task, which is the opposite of the goal of this work. Approaches to Verification of Automata-Based Programs Approaches to verification of programs can be divided into static and dynamic. The most typical example of dynamic verification is testing. The essence of this method is to test the functionality of the program using some examples. Despite the widespread prevalence of this approach, it has a significant drawback of dependence on a specific scenario. It is well known (E. Dijkstra) that testing cannot prove the absence of errors in a program. In this paper, the issue of verifying applications is largely considered as a matter of static verification, which includes Model Checking technologies [10] and theorem proving [11]. When using the automaton approach, the Model Checking technology plays a key role [10, 12, 13]. It allows you to automatically check whether a given requirement, expressed in the language of temporal logic, is fulfilled on the behavior model of a system with a finite number of states. Roughly speaking, the check is carried out using a search over the entire set of states, and the finiteness of the model ensures that the search will eventually complete. It is obvious that for general programs the use of this technology is very problematic, since the model has to be built heuristically. This raises the question of how adequate the resulting model is to the original program and how long the verification will take. However, this technology is ideally suited for the verification of automatic programs. Indeed, Model Checking assumes the formal construction of a model according to the program, which is a special kind of state machine. Therefore, the process of constructing a model from an automaton program can be automated, and, as a consequence, errors caused by the discrepancy between the model and the program will disappear. The writing of formal requirements for automaton programs is traditionally also simplified in comparison with constructed ones, since for this class of programs the semantic gap between the requirements for the program and the requirements for the model is practically eliminated in the course of constructing the automata. If an error occurs, a counterexample is issued, the transfer of which to an automaton program can also be performed automatically. The disadvantage of Model Checking technology as applied to automatic programming is that it covers only the logical part of the program. For the present work, another technology of verification, the method of proving theorems, is also important. Within the framework of this technology, the system itself, and the requirements for it are expressed using formulas of mathematical logic. The logic is set by the set
Axioms and rules of inference, and the verification process consists in proving a necessary requirement in a given logic. Unlike Model Checking technology, theorem proving can be performed in the case of an infinite-dimensional state space. The disadvantage of theorem proving technology is the presence of messages about non-existent errors, often indicating a problem in the proof system, and not in the program itself. Model Checking technology does not have this disadvantage. It is logical to pose the question of the possibility of combining these technologies in such a way as to compensate for the shortcomings of each of them. Possible solutions to this issue are presented in a number of works. In work [14], devoted to the current state and prospects of formal methods, there is a remark that for the description and analysis of complex systems, most likely, it will not be enough to use just one formal method. Therefore, the question of their combination becomes important. The main focus in this area is considered to be a combination of model checking and theorem proving technologies. Two approaches are proposed, firstly, using Model Checking as a decision-making tool for proving theorems, and secondly, using theorem proving systems to obtain models in the form of finite state machines and apply model checking to them. This work uses a different approach, which will be described in detail below. Its essence lies in the fact that at different stages of the development and implementation of the application, it is proposed to apply various verification methods that are relevant for the current stage. In this case, it is possible to combine model verification with verification of its implementation, including verification of the byte code. Note that that in [12] it is also stated that verification by the theorem-proving method is applicable to automatic programs. However, according to the authors of this article, such an approach is very time consuming and useless for testing the logic of a program, and can only be used to test the input and output actions. In this work, an attempt is made to refute the first part of the statement (the second part is fully confirmed). Firstly, a method for checking the program logic is described, and, secondly, an overview of the tools (already existing and created within the framework of this work) that implement this verification with a high degree of automation is given. Methods and technologies used Before presenting the main part of the work, let us describe some of the methods and technologies on which it is based. Contract design methodology [15, 16] is used to develop reliable software. It proposes to consider the constituent parts of software as an implementation of some formal specification, and not just as executable code. The main idea of this methodology is that the class and its clients enter into a "contract" between themselves. The client must ensure that certain conditions are met before calling the class. For this, the class undertakes to fulfill other conditions upon completion of its work. The main advantage of the described methodology is the enforceability of contracts, the compiler translates them along with the source code. Therefore, any breach of contract during program execution can be detected immediately. Java Modeling Language (JML) [17] is a language for specifying Java modules (interfaces and classes), describing both behavior and signature.
Models. The key elements of any specification are requires, ensures, and invariant. In the JML language there is an expression \ old (e) borrowed from Eiffel (a programming language developed by B. Meyer to support design technology by contract [15]), which is equivalent to the value of expression E at the moment of entering the method body. Changes to the value of a variable can be constrained using the constraint keyword, \ old () expression, and logical constructs such as implication or equivalence. BOMs are written between or after. Thus, the standard Java compiler treats them as comments and simply ignores them. They are processed by specially developed means. To support JML, a large number of tools have been developed with different functionality [18]. The simplest way to check for code compliance with a specification is a runtime check, the JML compiler (jmlc) runs the annotated Java code and dynamically checks for type conformance and specification violations. Static verification tools (ESC / Java2) and formal verification tools (KeY, Loop, JACK) do not require launching the application and are able to solve much more complex problems, but only with the help of the user and at the cost of some assumptions. Although JML can be used to annotate arbitrary Java applications, it is currently considered to be the main use for the Java Card [18]. Problem statement and scheme of the proposed solution Solving the problem of creating correct Java Card programs within the framework of using the automata approach requires solving a number of subproblems: 1. Extend existing code generation technologies to create the skeleton of Java Card applications from their automatic descriptions. 2. Develop a method that allows you to generate a formal specification for the code, covering the largest number of model properties. 3. Explore existing tools for working with JML in order to identify suitable for solving problems associated with code verification. The general scheme of the proposed approach is shown in Fig. 1.
UniMod application description Generation stage (1) Java Card skeleton (with implemented logic) JML specification Manual implementation of input and output methods and JML annotation addition Verification stage (2) Verifier or static check tool Fig. 1. Scheme of the proposed approach The problem is proposed to be solved in several stages. On the first of them, a skeleton of the source code is generated from the automaton model, which describes the application logic with stubs for methods that implement input and output actions (solution of subproblem 1). In addition, a formal specification of the application in the JML language is generated (solution of subproblem 2). Further, the methods of input and output actions are manually implemented and, possibly, the application specification is supplemented. Finally, using special tools, the compliance of the source code or the byte code with the specification is checked (solution of subproblem 3). In this case, warnings about possible errors are issued to the user. Error messages are handled manually. Automated approach for creating and verifying applications for smart cards In [19], it is proposed to divide systems into transforming and reactive systems. The transforming system processes the input information and issues a response based on it. The reactive system must respond to incoming influences. Moreover, it does not have to calculate any specific function, but provides interaction with the environment. The reactive system stores its current internal state, and its response to the environment and state change are completely dependent on the input action and the current state. In the present work, to solve the problem described above, the automata programming proposed in [3, 20] is used. It is a kind of synchronous programming [21], which is considered one of the main approaches for creating applications for embedded and reactive systems. According to the automaton programming paradigm [22], the program is considered as a system of automated control objects. When using this paradigm, when designing a program, event providers, a control system, generally consisting of interacting finite state machines, and control objects are distinguished. Consider the features of the Java Card platform as a reactive system [19]. Interaction with a smart card is carried out using card readers [1].
The computer or terminal on which the host application is installed. The communication channel is half-duplex and uses the master-slave model. The smart card is always the slave and the host application is always the master. This means that the smartcard always waits for a command from the host application. The sequence of commands comes from the host application through the card reader in the Java Card Runtime Environment (JCRE). The commands are then passed to the selected applet. It processes the command and sends a response in the opposite direction. Thus, the interaction between the host application and the smart card can be interpreted as event-driven. Since the event providers of the host application and the smart card control object can be allocated, automata programming can be effectively used to create robust Java Card programs (Figure 2). Event providers host application APDU command Hierarchical system of state machines Control object smart card Feedback APDU response Fig. 2. Interpretation of the automaton approach for the Java Card platform Application of the automaton approach does not free the programmer from writing code, since only that part of the functionality that implements the system logic is generated. This assumes manual creation of the code that implements the input and output actions. The problem lies in the lack of means for checking the compliance of the code with its model and checking the methods that implement the input and output actions. The suggested way out of this situation is the use of contracts. Contracts also describe how different parts of a program interact, but they do so at a lower level of abstraction. If, along with automating the creation of the source code, a specification isomorphic to the model is generated, then, despite the lowering of the level of abstraction, the possibility of verification will remain. Therefore, the use of JML allows us to bridge the semantic gap between model and implementation. Thus, it is possible to avoid the situation when the boundedness of the model is the cause of unexpected errors in the program, or vice versa, errors in a poorly constructed model will signal non-existent errors in the program. In the case of verifying applications using JML, there is no need to build a formal model, the annotated source code itself is fed to the input of the verifiers. As noted above, Model Checking is limited to only checking application logic, which is its main drawback. The generated code specification allows you to solve similar problems. However, if you add them manually, you can check a much larger amount of program properties, such as, for example, the behavior of methods that implement input and output actions, their interconnection, common programming errors, such as an array index out of range, accessing a nonexistent place in memory and much more.
Code and Specification Generation (Practical Implementation) All Java Card applets have a standard structure, they must override the methods of the base Applet class. To clarify the code generation process, we briefly describe [1] each of these methods in the order in which they are called by the JCRE. The install method is called to instantiate the applet. It is similar to the main method in standard Java applications. By default, the specified method always returns true. This means that the applet is ready to go. When the selected applet receives a command, it is passed for processing to the process method, which will be described later. To deactivate the applet, JCRE calls the deselect method. This method is empty by default. Using standard implementations of the listed methods (with the exception of the process method), they can be defined in the template as static content, and, if necessary, modified after generation to meet the requirements of a specific task. In the proposed approach, the entire logic of the process method is described by a hierarchical system of finite state machines, from which the skeleton of the code that implements this logic is generated. Automatic programming is supported by Switch technology [23]. Therefore, the process method can, for example, be implemented by two nested switch statements, the outer one is used to iterate over states, and the inner one is used to iterate over commands. If the command received is valid for the current state, then the appropriate helper method is called; otherwise, an exception is raised that does not change the state of the applet. For helper methods, only stub methods are generated. According to the technology of automatic programming, transitions between states are marked with Boolean expressions formed from input actions. Provided that these expressions have no side effects, they can be preconditions for methods that are called upon entering a state. The structure of the transition graph can be specified using the constraint keyword and the \ old () expression. This specification is a disjunction of implications that describe the inbound and outbound transitions for each state. Moreover, it is possible to ensure that the applet is always in one of the predefined states (using a class invariant). The UniMod tool allows you to save the description of an automaton model in XML format. To generate the code, a converter program developed during this work is used, which uses templates (also developed as part of this work) and Apache Velocity technology. Methodology for creating correct Java Card-applications Based on the above, we can describe the methodology for creating correct Java Card-applications using the automatic approach: 1. Using the specification and terms of reference for the project, go to the UniMod description of the application. In this case, the host application is used as event providers, and a smart card is used as a control object. 2. Verify the resulting model using the Model Checking method using verifiers such as Spin or Bogor. 3. Export the UniMod-description of the application into XML-format using standard UniMod tools. Methodology for creating correct Java Card-applications Based on the above, we can describe the methodology for creating correct Java Card-applications using the automatic approach: 1. Using the specification and terms of reference for the project, go to the UniMod description of the application. In this case, the host application is used as event providers, and a smart card is used as a control object. 2. Verify the resulting model using the Model Checking method using verifiers such as Spin or Bogor. 3. Export the UniMod-description of the application into XML-format using standard UniMod tools. Methodology for creating correct Java Card-applications Based on the above, we can describe the methodology for creating correct Java Card-applications using the automatic approach: 1. Using the specification and terms of reference for the project, go to the UniMod description of the application. In this case, the host application is used as event providers, and a smart card is used as a control object. 2. Verify the resulting model using the Model Checking method using verifiers such as Spin or Bogor. 3. Export the UniMod-description of the application into XML-format using standard UniMod tools. In this case, the host application is used as event providers, and a smart card is used as a control object. 2. Verify the resulting model using the Model Checking method using verifiers such as Spin or Bogor. 3. Export the UniMod-description of the application into XML-format using standard UniMod tools. In this case, the host application is used as event providers, and a smart card is used as a control object. 2. Verify the resulting model using the Model Checking method using verifiers such as Spin or Bogor. 3. Export the UniMod-description of the application into XML-format using standard UniMod tools.
Submit the XML-description of the application and the templates created in the framework of this work to the input of the converter program developed by the authors for generating Java Card-code with JML-annotations. 5. Refine the manually generated code and JML specification in the following directions: a. Implement methods of input and output actions (a standard step in the framework of the automaton approach). b. Supplement JML annotations (mainly for input and output methods). 6. Verification can be carried out using the source code (7) or byte-code (8). 7. Depending on the problem being solved, submit the annotated code as input to one of the existing tools for checking the source code: a. Runtime check jmlc. b. Static check ESC / Java2. c. Verification of KeY, LOOP, JACK. 8. Compile the code, translate the specification into byte-code and check it using appropriate tools. 9. Manually handle error messages. Example Here is an example of a Java Card applet that illustrates the proposed approach. The application connection diagram is shown in Fig. 3, a (method item 1). The event providers and the control object are connected to each other using a state machine, the transition graph of which is shown in Fig. 3, b. These diagrams were built using the UniMod tool. a) b) Fig. 3. Example. a) connection diagram, b) transition graph The event providers and the control object are connected to each other using a state machine, the transition graph of which is shown in Fig. 3, b. These diagrams were built using the UniMod tool. a) b) Fig. 3. Example. a) connection diagram, b) transition graph The event providers and the control object are interconnected using a state machine, the transition graph of which is shown in Fig. 3, b. These diagrams were built using the UniMod tool. a) b) Fig. 3. Example. a) connection diagram, b) transition graph
The applet functions as follows. After the initialization stage (the Applet initialization state and the output action o1.z1), it is necessary to check the PIN-code (event e1), passing to the corresponding state. If the code is correct in this state (event e3), then the applet goes into the Do something state, in which the counter of unsuccessful attempts (input variable x1) for checking the PIN code is reset (output action o1.z3) and some action is performed (output action o1.z4). If the code is incorrect (event e2) and the number of unsuccessful verification attempts does not exceed three (boolean expression o1.x1 <= 3), then the state of the machine does not change, but the counter of attempts is increased (output action o1.z2). Finally, if the code is incorrect (event e2) and the number of unsuccessful attempts exceeds three (boolean o1.x1> 3), then the machine goes into the SIM card is locked state by sending a message about this to the host application (output action o1.z5). A number of simplifications have been adopted in this example. First, the verification of the PIN is actually much more difficult, and secondly, the content of the application is not described, it is assumed that it is executed in the Do something state. However, this example can be used in any application since PIN verification is key. Consider a fragment of the process method (Listing 1) and a formal application specification (Java Card with JML annotations), obtained using a converter program (method step 4). Let the integer variable state correspond to the state of the machine at the current moment. Then the state invariant (Listing 2) allows us to guarantee that that the applet will always be in one of the state transitions predefined by the graph. Listing 1. Process method (snippet) // ... static final byte APPLET_INITIALIZATION = 0; static final byte PIN_CODE_VERIFICATION = 1; static final byte DO_SOMETHING = 2; static final byte SIM_CARD_IS_LOCKED = 3; // ... public void process (apdu apdu) throws ISOException {byte ins = apdu.getbuffer () [iso7816.offset_ins]; switch (state) {case APPLET_INITIALIZATION: switch (ins) {// ... default: ISOException.throwIt (ISO7816.SW_CONDITIONS_NOT_SATISFIED)} break; // ... default: ISOException.throwIt (ISO7816.SW_CONDITIONS_NOT_SATISFIED)} static final byte SIM_CARD_IS_LOCKED = 3; // ... public void process (apdu apdu) throws ISOException {byte ins = apdu.getbuffer () [iso7816.offset_ins]; switch (state) {case APPLET_INITIALIZATION: switch (ins) {// ... default: ISOException.throwIt (ISO7816.SW_CONDITIONS_NOT_SATISFIED)} break; // ... default: ISOException.throwIt (ISO7816.SW_CONDITIONS_NOT_SATISFIED)} static final byte SIM_CARD_IS_LOCKED = 3; // ... public void process (apdu apdu) throws ISOException {byte ins = apdu.getbuffer () [iso7816.offset_ins]; switch (state) {case APPLET_INITIALIZATION: switch (ins) {// ... default: ISOException.throwIt (ISO7816.SW_CONDITIONS_NOT_SATISFIED)} break; // ... default: ISOException.throwIt (ISO7816.SW_CONDITIONS_NOT_SATISFIED)}
The invariant of states (state == (state == (state == (state ==) The description of the transition graph of the automaton, in the form of a constraint on possible transitions between states, is given in Listing 3. Listing 3. Constraints on possible transitions between states constraint ((state == APPLET_INITIALIZATION) ==> (\ old (state) == APPLET_INITIALIZATION)) && ((state == PIN_CODE_VERIFICATION) ==> ((\ old (state) == APPLET_INITIALIZATION) (\ old (state) = = PIN_CODE_VERIFICATION))) && ((state == DO_SOMETHING) ==> ((\ old (state) == PIN_CODE_VERIFICATION) (\ old (state) == DO_SOMETHING))) && ((state == SIM_CARDS_IS_LOCKED) ==> ((\ old (state) == PIN_CODE_VERIFICATION) (\ old (state) == SIM_CARDS_IS_LOCKED))) && ((\ old (state) == APPLET_INITIALIZATION) ==> ((state == PIN_CODE_VERIFICATION) (state == APPLET_INITIALIZATION ))) && ((\ old (state) == PIN_CODE_VERIFICATION) ==> ((state == PIN_CODE_VERIFICATION) (state == DO_SOMETHING) (state == SIM_CARDS_IS_LOCKED))) && ((\ old (state) == DO_SOMETHING) == > (state == DO_SOMETHING)) && ((\ old (state) == SIM_CARDS_IS_LOCKED) ==> (state == Consider some issues of verification of the received application (method item 6). Since the generated code does not have full functionality, the message about The error can be traced by creating it artificially, for example, by adding an invalid value to the state variable in the applet constructor (Listing 4).((\ old (state) == SIM_CARDS_IS_LOCKED) ==> (state == Let's consider some issues of verification of the received application (method item 6). Since the generated code does not have full functionality, the error message can be traced by creating it artificially, for example by adding an invalid value to the state variable in the applet constructor (Listing 4).((\ old (state) == SIM_CARDS_IS_LOCKED) ==> (state == Let's consider some issues of verification of the received application (method item 6). Since the generated code does not have full functionality, the error message can be traced by creating it artificially, for example by adding an invalid value to the state variable in the applet constructor (Listing 4).
An artificially created error in the program public PINApplet () {state = (byte) 5; } In this case, it is enough to use the simplest dynamic check tool (methodology item 7, a). Let's run the jmlc tool (Listing 5) and make sure it finds this error (Method # 9). Listing 5. Message from jmlc tool (snippet) parsing .. \ .. \ .. \ pinapplet.java parsing .. \ specs \ javacard \ framework \ apdu.jml parsing .. \ specs \ javacard \ framework \ applet.jml parsing. . \ specs \ javacard \ framework \ iso7816.jml parsing .. \ specs \ javacard \ framework \ isoexception.jml ... typechecking .. \ .. \ .. \ pinapplet.java ... Exception in thread main org.jmlspecs .jmlrac.runtime.jmlinvarianterror: by method PinApplet.java, line 70, character 17> ... Done Conclusion Automata programming technology provides an approach for developing correct embedded and reactive applications. In this paper, we propose its extension for creating Java Card applications. An additional guarantee of the correctness of the created programs is the use of design by contract. In contrast to the already existing research on verification of automata programs, in this work it is proposed to combine various approaches to apply verification of the source or byte code, and not only the Model Checking technology. At the same time, it is proposed to start the verification of the application with the verification of the model using the Model Checking technology. By transferring the model isomorphically to the source code level and complementing the specification with a description of the behavior of input and output actions, it is possible to guarantee that the code corresponds to the already checked model and, in addition, the correctness of other methods, which was impossible to check using the Model Checking technology. If necessary, a similar check can be carried out at the byte-code level. Therefore, verification can be carried out at all stages of application development. List of sources 1. Chen J. Technology Java Card for smart cards. Architecture and Programmer's Guide. Moscow: Technosphere, 2008.
NASA LaRC Formal Methods Program: What is Formal Methods? 3. Shalyto AA Algorithmization and programming for logical control systems and "reactive" systems // Automation and telemechanics, with Poll E., van den Berg J., Jacobs B. Specification of the JavaCard API in JML / Proc. Fourth Smart Card Research and Advanced Application Conference, pp Coglio A. An Approach to the Generation of High-Assurance Java Card Applets / Proc. 2nd NSA Conf. on High Confidence Software and Systems (HCSS 02). 2002, pp Hubbers E., Oostdijk M., Poll E. From finite state machines to provably correct Java Card applets / Proc. 18th IFIP Inform. Security Conf. 2003, pp Hubbers E., Oostdijk M. Generating JML specifications from UML state diagrams / Proc. Forum on specification and Design Languages (FDL 03). 2003, pp Gurov V.S., Mazin M.A., Shalyto A.A. UniMod tool for automata programming // Scientific and technical bulletin. Issue 30. Fundamental and applied research of information systems and technology. SPbSU ITMO. 2006, p. Development of verification technology for control programs with complex behavior, built on the basis of an automaton approach. Interim report on stage II. SPbSU ITMO, Velder S.E., Shalyto A.A. An introduction to the verification of automata programs based on the Model checking method. // Scientific and technical bulletin. Issue 42. Fundamental and applied research of information systems and technologies. SPbSU ITMO. 2007, p. Nepomnyashchy V. A., Ryakin O. M. Applied methods of program verification. M .: Radio and communication, Kuzmin E. V., Sokolov V. A. On the verification of "automatic" programs / Actual problems of mathematics and informatics. Collection of articles for the 20th anniversary of the Faculty of ICT, YarSU named after P.G.Demidova, Yaroslavl: YarSU. 2006, p. Korneev G. A., Parfenov V. G., Shalyto A. A. Verification of automatic programs / Abstracts of the International Scientific Conference dedicated to the memory of Professor A. M. Bogomolov. "Computer Science and Technology". Saratov: SSU. 2007, with Clarke EM, Wing JM Formal methods: State of the Art and Future Directions // ACM Computing Surveys Vol. 4, pp Meyer B. Object-oriented design of software systems. Moscow: Russian edition, Leavens GT, Cheon Y. Design by Contract with JML Leavens GT, Baker AL, Ruby C. Preliminary design of JML: A behavioral interface specification language for Java. Iowa State Univ., Dept. of Comput. Sci. Tech. Rep u, Burdy L., et. al. An overview of JML tools and applications // Int. J. on Software Tools for Technology Transfer (STTT). 7 (3). 2005, pp Harel D., Pnueli A. On the Development of Reactive Systems. In Logic and Models of Concurrent Systems / NATO Advanced Study Institute on Logic and Models for Verification and Specification of Concurrent Systems. 1985, pp
Shalyto A. A. Automatic program design. Algorithmization and programming of logical control problems // Izvestiya RAN. Theory and control systems. 2000, 6, with Shopyrin D. G., Shalyto A. A. Synchronous programming // Information control systems, with Shalyto A. A. Paradigm of automatic programming / International scientific and technical multiconference "Problems of information technologies and mechatronics". Materials of the International Scientific and Technical Conference "Multiprocessor Computing and Control Systems". Taganrog: NIIVMS vol. 1, with A. A. Shalyto, N. I. Tukkel
Which is explained by the specifics of the fields of application of smart cards, in which the cost of an error is very high. Secondly, Java Card is the most widely used Java platform in the world, as smart cards are issued in huge numbers. Therefore, unlike software for personal computers, updating or fixing applications on already issued cards can be quite time consuming and economically unprofitable. And finally, the limited resources and less functionality of the Java Card compared to Java technology ensures that programs do not have too complex behavior and a large number of control states [3]. Java Card applications can be a good training ground for a variety of formal methods. On the one hand, the programs in this case are quite simple, on the other hand, they are of specific practical interest, and are not artificially created "toy" code. Thus, the task of applying formal methods for designing and verifying Java Card applications seems to be relevant and realizable. The purpose of this work is to expand the technology of automata programming to create correct Java Card programs. At the same time, it is necessary to solve a number of problems related to the implementation of the possibility of generating the skeleton of the source code of Java Card applications and their subsequent verification at the level of the source and byte codes. Analysis of existing works It follows from the above that the analysis of existing works can be carried out in two directions, one of which is the generation of Java Card-code from high-level specifications, and the second is the verification of automatic programs. Generating Java Card Code from High-Level Specifications There are two research projects aimed at generating Java Card code from high-level specifications. The first of them [5] is based on the domain-specific language SmartSlang, which allows you to describe programs using high-level constructs typical for smart cards. However, it does not use an automaton approach, and therefore the project has little to do with the real work. The second project is considered in works [6, 7]. In these studies, the code is generated based on the state machine describing the applet. In [6], a verifier is used as an editor for finite state machines, and in [7], UML is used to describe automata. This work has several advantages over these studies. First, the technology of automatic programming is applied, which assumes the description of behavior by a hierarchical system of automata, and not just one automaton, as in [6, 7]. In [6], there remains an open question about modeling the host application itself and its interaction with a smart card. Distinguishing the host application as a separate event provider within the automaton approach largely solves this issue. The notation used in automata programming technology hides the low-level features of the Java Card language, which facilitates the process of developing programs and increases their reliability. Indeed, the programmer is offered to operate not with byte arrays, but with short identifiers, for which a textual description is always available. Second, the proposed approach generates a more complete and not just one automaton, as in [6, 7]. In [6], there remains an open question about modeling the host application itself and its interaction with a smart card. Distinguishing the host application as a separate event provider within the automaton approach largely solves this issue. The notation used in automata programming technology hides the low-level features of the Java Card language, which facilitates the process of developing programs and increases their reliability. Indeed, the programmer is offered to operate not with byte arrays, but with short identifiers, for which a textual description is always available. Second, the proposed approach generates a more complete and not just one automaton, as in [6, 7]. In [6], there remains an open question about modeling the host application itself and its interaction with a smart card. Distinguishing the host application as a separate event provider within the automaton approach largely solves this issue. The notation used in automata programming technology hides the low-level features of the Java Card language, which facilitates the process of developing programs and increases their reliability. Indeed, the programmer is offered to operate not with byte arrays, but with short identifiers, for which a textual description is always available. Second, the proposed approach generates a more complete Distinguishing the host application as a separate event provider within the automaton approach largely solves this issue. The notation used in automata programming technology hides the low-level features of the Java Card language, which facilitates the process of developing programs and increases their reliability. Indeed, the programmer is offered to operate not with byte arrays, but with short identifiers, for which a textual description is always available. Second, the proposed approach generates a more complete Distinguishing the host application as a separate event provider within the automaton approach largely solves this issue. The notation used in automata programming technology hides the low-level features of the Java Card language, which facilitates the process of developing programs and increases their reliability. Indeed, the programmer is offered to operate not with byte arrays, but with short identifiers, for which a textual description is always available. Second, the proposed approach generates a more complete the programmer is offered to operate not with byte arrays, but with short identifiers, for which a textual description is always available. Second, the proposed approach generates a more complete the programmer is offered to operate not with byte arrays, but with short identifiers, for which a textual description is always available. Second, the proposed approach generates a more complete
Specification. In particular, under certain restrictions, it is possible to generate preconditions for methods that are called upon entering a state. In [6], this question is also referred to as open. Finally, for the UniMod tool [8], a number of plug-ins have been developed that allow verification of the automaton model [9]. Note that in [6] the verifier is used exclusively as a graphical editor for creating automata, and its use for its intended purpose is mentioned only in the section describing further studies. However, in a later work [7], model verification is not mentioned at all. Moreover, the issue of code generation is considered secondary, and extracting an automaton model from the source code is considered an attractive task, which is the opposite of the goal of this work. Approaches to Verification of Automata-Based Programs Approaches to verification of programs can be divided into static and dynamic. The most typical example of dynamic verification is testing. The essence of this method is to test the functionality of the program using some examples. Despite the widespread prevalence of this approach, it has a significant drawback of dependence on a specific scenario. It is well known (E. Dijkstra) that testing cannot prove the absence of errors in a program. In this paper, the issue of verifying applications is largely considered as a matter of static verification, which includes Model Checking technologies [10] and theorem proving [11]. When using the automaton approach, the Model Checking technology plays a key role [10, 12, 13]. It allows you to automatically check whether a given requirement, expressed in the language of temporal logic, is fulfilled on the behavior model of a system with a finite number of states. Roughly speaking, the check is carried out using a search over the entire set of states, and the finiteness of the model ensures that the search will eventually complete. It is obvious that for general programs the use of this technology is very problematic, since the model has to be built heuristically. This raises the question of how adequate the resulting model is to the original program and how long the verification will take. However, this technology is ideally suited for the verification of automatic programs. Indeed, Model Checking assumes the formal construction of a model according to the program, which is a special kind of state machine. Therefore, the process of constructing a model from an automaton program can be automated, and, as a consequence, errors caused by the discrepancy between the model and the program will disappear. The writing of formal requirements for automaton programs is traditionally also simplified in comparison with constructed ones, since for this class of programs the semantic gap between the requirements for the program and the requirements for the model is practically eliminated in the course of constructing the automata. If an error occurs, a counterexample is issued, the transfer of which to an automaton program can also be performed automatically. The disadvantage of Model Checking technology as applied to automatic programming is that it covers only the logical part of the program. For the present work, another technology of verification, the method of proving theorems, is also important. Within the framework of this technology, the system itself, and the requirements for it are expressed using formulas of mathematical logic. The logic is set by the set
Axioms and rules of inference, and the verification process consists in proving a necessary requirement in a given logic. Unlike Model Checking technology, theorem proving can be performed in the case of an infinite-dimensional state space. The disadvantage of theorem proving technology is the presence of messages about non-existent errors, often indicating a problem in the proof system, and not in the program itself. Model Checking technology does not have this disadvantage. It is logical to pose the question of the possibility of combining these technologies in such a way as to compensate for the shortcomings of each of them. Possible solutions to this issue are presented in a number of works. In work [14], devoted to the current state and prospects of formal methods, there is a remark that for the description and analysis of complex systems, most likely, it will not be enough to use just one formal method. Therefore, the question of their combination becomes important. The main focus in this area is considered to be a combination of model checking and theorem proving technologies. Two approaches are proposed, firstly, using Model Checking as a decision-making tool for proving theorems, and secondly, using theorem proving systems to obtain models in the form of finite state machines and apply model checking to them. This work uses a different approach, which will be described in detail below. Its essence lies in the fact that at different stages of the development and implementation of the application, it is proposed to apply various verification methods that are relevant for the current stage. In this case, it is possible to combine model verification with verification of its implementation, including verification of the byte code. Note that that in [12] it is also stated that verification by the theorem-proving method is applicable to automatic programs. However, according to the authors of this article, such an approach is very time consuming and useless for testing the logic of a program, and can only be used to test the input and output actions. In this work, an attempt is made to refute the first part of the statement (the second part is fully confirmed). Firstly, a method for checking the program logic is described, and, secondly, an overview of the tools (already existing and created within the framework of this work) that implement this verification with a high degree of automation is given. Methods and technologies used Before presenting the main part of the work, let us describe some of the methods and technologies on which it is based. Contract design methodology [15, 16] is used to develop reliable software. It proposes to consider the constituent parts of software as an implementation of some formal specification, and not just as executable code. The main idea of this methodology is that the class and its clients enter into a "contract" between themselves. The client must ensure that certain conditions are met before calling the class. For this, the class undertakes to fulfill other conditions upon completion of its work. The main advantage of the described methodology is the enforceability of contracts, the compiler translates them along with the source code. Therefore, any breach of contract during program execution can be detected immediately. Java Modeling Language (JML) [17] is a language for specifying Java modules (interfaces and classes), describing both behavior and signature.
Models. The key elements of any specification are requires, ensures, and invariant. In the JML language there is an expression \ old (e) borrowed from Eiffel (a programming language developed by B. Meyer to support design technology by contract [15]), which is equivalent to the value of expression E at the moment of entering the method body. Changes to the value of a variable can be constrained using the constraint keyword, \ old () expression, and logical constructs such as implication or equivalence. BOMs are written between or after. Thus, the standard Java compiler treats them as comments and simply ignores them. They are processed by specially developed means. To support JML, a large number of tools have been developed with different functionality [18]. The simplest way to check for code compliance with a specification is a runtime check, the JML compiler (jmlc) runs the annotated Java code and dynamically checks for type conformance and specification violations. Static verification tools (ESC / Java2) and formal verification tools (KeY, Loop, JACK) do not require launching the application and are able to solve much more complex problems, but only with the help of the user and at the cost of some assumptions. Although JML can be used to annotate arbitrary Java applications, it is currently considered to be the main use for the Java Card [18]. Problem statement and scheme of the proposed solution Solving the problem of creating correct Java Card programs within the framework of using the automata approach requires solving a number of subproblems: 1. Extend existing code generation technologies to create the skeleton of Java Card applications from their automatic descriptions. 2. Develop a method that allows you to generate a formal specification for the code, covering the largest number of model properties. 3. Explore existing tools for working with JML in order to identify suitable for solving problems associated with code verification. The general scheme of the proposed approach is shown in Fig. 1.
UniMod application description Generation stage (1) Java Card skeleton (with implemented logic) JML specification Manual implementation of input and output methods and JML annotation addition Verification stage (2) Verifier or static check tool Fig. 1. Scheme of the proposed approach The problem is proposed to be solved in several stages. On the first of them, a skeleton of the source code is generated from the automaton model, which describes the application logic with stubs for methods that implement input and output actions (solution of subproblem 1). In addition, a formal specification of the application in the JML language is generated (solution of subproblem 2). Further, the methods of input and output actions are manually implemented and, possibly, the application specification is supplemented. Finally, using special tools, the compliance of the source code or the byte code with the specification is checked (solution of subproblem 3). In this case, warnings about possible errors are issued to the user. Error messages are handled manually. Automated approach for creating and verifying applications for smart cards In [19], it is proposed to divide systems into transforming and reactive systems. The transforming system processes the input information and issues a response based on it. The reactive system must respond to incoming influences. Moreover, it does not have to calculate any specific function, but provides interaction with the environment. The reactive system stores its current internal state, and its response to the environment and state change are completely dependent on the input action and the current state. In the present work, to solve the problem described above, the automata programming proposed in [3, 20] is used. It is a kind of synchronous programming [21], which is considered one of the main approaches for creating applications for embedded and reactive systems. According to the automaton programming paradigm [22], the program is considered as a system of automated control objects. When using this paradigm, when designing a program, event providers, a control system, generally consisting of interacting finite state machines, and control objects are distinguished. Consider the features of the Java Card platform as a reactive system [19]. Interaction with a smart card is carried out using card readers [1].
The computer or terminal on which the host application is installed. The communication channel is half-duplex and uses the master-slave model. The smart card is always the slave and the host application is always the master. This means that the smartcard always waits for a command from the host application. The sequence of commands comes from the host application through the card reader in the Java Card Runtime Environment (JCRE). The commands are then passed to the selected applet. It processes the command and sends a response in the opposite direction. Thus, the interaction between the host application and the smart card can be interpreted as event-driven. Since the event providers of the host application and the smart card control object can be allocated, automata programming can be effectively used to create robust Java Card programs (Figure 2). Event providers host application APDU command Hierarchical system of state machines Control object smart card Feedback APDU response Fig. 2. Interpretation of the automaton approach for the Java Card platform Application of the automaton approach does not free the programmer from writing code, since only that part of the functionality that implements the system logic is generated. This assumes manual creation of the code that implements the input and output actions. The problem lies in the lack of means for checking the compliance of the code with its model and checking the methods that implement the input and output actions. The suggested way out of this situation is the use of contracts. Contracts also describe how different parts of a program interact, but they do so at a lower level of abstraction. If, along with automating the creation of the source code, a specification isomorphic to the model is generated, then, despite the lowering of the level of abstraction, the possibility of verification will remain. Therefore, the use of JML allows us to bridge the semantic gap between model and implementation. Thus, it is possible to avoid the situation when the boundedness of the model is the cause of unexpected errors in the program, or vice versa, errors in a poorly constructed model will signal non-existent errors in the program. In the case of verifying applications using JML, there is no need to build a formal model, the annotated source code itself is fed to the input of the verifiers. As noted above, Model Checking is limited to only checking application logic, which is its main drawback. The generated code specification allows you to solve similar problems. However, if you add them manually, you can check a much larger amount of program properties, such as, for example, the behavior of methods that implement input and output actions, their interconnection, common programming errors, such as an array index out of range, accessing a nonexistent place in memory and much more.
Code and Specification Generation (Practical Implementation) All Java Card applets have a standard structure, they must override the methods of the base Applet class. To clarify the code generation process, we briefly describe [1] each of these methods in the order in which they are called by the JCRE. The install method is called to instantiate the applet. It is similar to the main method in standard Java applications. By default, the specified method always returns true. This means that the applet is ready to go. When the selected applet receives a command, it is passed for processing to the process method, which will be described later. To deactivate the applet, JCRE calls the deselect method. This method is empty by default. Using standard implementations of the listed methods (with the exception of the process method), they can be defined in the template as static content, and, if necessary, modified after generation to meet the requirements of a specific task. In the proposed approach, the entire logic of the process method is described by a hierarchical system of finite state machines, from which the skeleton of the code that implements this logic is generated. Automatic programming is supported by Switch technology [23]. Therefore, the process method can, for example, be implemented by two nested switch statements, the outer one is used to iterate over states, and the inner one is used to iterate over commands. If the command received is valid for the current state, then the appropriate helper method is called; otherwise, an exception is raised that does not change the state of the applet. For helper methods, only stub methods are generated. According to the technology of automatic programming, transitions between states are marked with Boolean expressions formed from input actions. Provided that these expressions have no side effects, they can be preconditions for methods that are called upon entering a state. The structure of the transition graph can be specified using the constraint keyword and the \ old () expression. This specification is a disjunction of implications that describe the inbound and outbound transitions for each state. Moreover, it is possible to ensure that the applet is always in one of the predefined states (using a class invariant). The UniMod tool allows you to save the description of an automaton model in XML format. To generate the code, a converter program developed during this work is used, which uses templates (also developed as part of this work) and Apache Velocity technology. Methodology for creating correct Java Card-applications Based on the above, we can describe the methodology for creating correct Java Card-applications using the automatic approach: 1. Using the specification and terms of reference for the project, go to the UniMod description of the application. In this case, the host application is used as event providers, and a smart card is used as a control object. 2. Verify the resulting model using the Model Checking method using verifiers such as Spin or Bogor. 3. Export the UniMod-description of the application into XML-format using standard UniMod tools. Methodology for creating correct Java Card-applications Based on the above, we can describe the methodology for creating correct Java Card-applications using the automatic approach: 1. Using the specification and terms of reference for the project, go to the UniMod description of the application. In this case, the host application is used as event providers, and a smart card is used as a control object. 2. Verify the resulting model using the Model Checking method using verifiers such as Spin or Bogor. 3. Export the UniMod-description of the application into XML-format using standard UniMod tools. Methodology for creating correct Java Card-applications Based on the above, we can describe the methodology for creating correct Java Card-applications using the automatic approach: 1. Using the specification and terms of reference for the project, go to the UniMod description of the application. In this case, the host application is used as event providers, and a smart card is used as a control object. 2. Verify the resulting model using the Model Checking method using verifiers such as Spin or Bogor. 3. Export the UniMod-description of the application into XML-format using standard UniMod tools. In this case, the host application is used as event providers, and a smart card is used as a control object. 2. Verify the resulting model using the Model Checking method using verifiers such as Spin or Bogor. 3. Export the UniMod-description of the application into XML-format using standard UniMod tools. In this case, the host application is used as event providers, and a smart card is used as a control object. 2. Verify the resulting model using the Model Checking method using verifiers such as Spin or Bogor. 3. Export the UniMod-description of the application into XML-format using standard UniMod tools.
Submit the XML-description of the application and the templates created in the framework of this work to the input of the converter program developed by the authors for generating Java Card-code with JML-annotations. 5. Refine the manually generated code and JML specification in the following directions: a. Implement methods of input and output actions (a standard step in the framework of the automaton approach). b. Supplement JML annotations (mainly for input and output methods). 6. Verification can be carried out using the source code (7) or byte-code (8). 7. Depending on the problem being solved, submit the annotated code as input to one of the existing tools for checking the source code: a. Runtime check jmlc. b. Static check ESC / Java2. c. Verification of KeY, LOOP, JACK. 8. Compile the code, translate the specification into byte-code and check it using appropriate tools. 9. Manually handle error messages. Example Here is an example of a Java Card applet that illustrates the proposed approach. The application connection diagram is shown in Fig. 3, a (method item 1). The event providers and the control object are connected to each other using a state machine, the transition graph of which is shown in Fig. 3, b. These diagrams were built using the UniMod tool. a) b) Fig. 3. Example. a) connection diagram, b) transition graph The event providers and the control object are connected to each other using a state machine, the transition graph of which is shown in Fig. 3, b. These diagrams were built using the UniMod tool. a) b) Fig. 3. Example. a) connection diagram, b) transition graph The event providers and the control object are interconnected using a state machine, the transition graph of which is shown in Fig. 3, b. These diagrams were built using the UniMod tool. a) b) Fig. 3. Example. a) connection diagram, b) transition graph
The applet functions as follows. After the initialization stage (the Applet initialization state and the output action o1.z1), it is necessary to check the PIN-code (event e1), passing to the corresponding state. If the code is correct in this state (event e3), then the applet goes into the Do something state, in which the counter of unsuccessful attempts (input variable x1) for checking the PIN code is reset (output action o1.z3) and some action is performed (output action o1.z4). If the code is incorrect (event e2) and the number of unsuccessful verification attempts does not exceed three (boolean expression o1.x1 <= 3), then the state of the machine does not change, but the counter of attempts is increased (output action o1.z2). Finally, if the code is incorrect (event e2) and the number of unsuccessful attempts exceeds three (boolean o1.x1> 3), then the machine goes into the SIM card is locked state by sending a message about this to the host application (output action o1.z5). A number of simplifications have been adopted in this example. First, the verification of the PIN is actually much more difficult, and secondly, the content of the application is not described, it is assumed that it is executed in the Do something state. However, this example can be used in any application since PIN verification is key. Consider a fragment of the process method (Listing 1) and a formal application specification (Java Card with JML annotations), obtained using a converter program (method step 4). Let the integer variable state correspond to the state of the machine at the current moment. Then the state invariant (Listing 2) allows us to guarantee that that the applet will always be in one of the state transitions predefined by the graph. Listing 1. Process method (snippet) // ... static final byte APPLET_INITIALIZATION = 0; static final byte PIN_CODE_VERIFICATION = 1; static final byte DO_SOMETHING = 2; static final byte SIM_CARD_IS_LOCKED = 3; // ... public void process (apdu apdu) throws ISOException {byte ins = apdu.getbuffer () [iso7816.offset_ins]; switch (state) {case APPLET_INITIALIZATION: switch (ins) {// ... default: ISOException.throwIt (ISO7816.SW_CONDITIONS_NOT_SATISFIED)} break; // ... default: ISOException.throwIt (ISO7816.SW_CONDITIONS_NOT_SATISFIED)} static final byte SIM_CARD_IS_LOCKED = 3; // ... public void process (apdu apdu) throws ISOException {byte ins = apdu.getbuffer () [iso7816.offset_ins]; switch (state) {case APPLET_INITIALIZATION: switch (ins) {// ... default: ISOException.throwIt (ISO7816.SW_CONDITIONS_NOT_SATISFIED)} break; // ... default: ISOException.throwIt (ISO7816.SW_CONDITIONS_NOT_SATISFIED)} static final byte SIM_CARD_IS_LOCKED = 3; // ... public void process (apdu apdu) throws ISOException {byte ins = apdu.getbuffer () [iso7816.offset_ins]; switch (state) {case APPLET_INITIALIZATION: switch (ins) {// ... default: ISOException.throwIt (ISO7816.SW_CONDITIONS_NOT_SATISFIED)} break; // ... default: ISOException.throwIt (ISO7816.SW_CONDITIONS_NOT_SATISFIED)}
The invariant of states (state == (state == (state == (state ==) The description of the transition graph of the automaton, in the form of a constraint on possible transitions between states, is given in Listing 3. Listing 3. Constraints on possible transitions between states constraint ((state == APPLET_INITIALIZATION) ==> (\ old (state) == APPLET_INITIALIZATION)) && ((state == PIN_CODE_VERIFICATION) ==> ((\ old (state) == APPLET_INITIALIZATION) (\ old (state) = = PIN_CODE_VERIFICATION))) && ((state == DO_SOMETHING) ==> ((\ old (state) == PIN_CODE_VERIFICATION) (\ old (state) == DO_SOMETHING))) && ((state == SIM_CARDS_IS_LOCKED) ==> ((\ old (state) == PIN_CODE_VERIFICATION) (\ old (state) == SIM_CARDS_IS_LOCKED))) && ((\ old (state) == APPLET_INITIALIZATION) ==> ((state == PIN_CODE_VERIFICATION) (state == APPLET_INITIALIZATION ))) && ((\ old (state) == PIN_CODE_VERIFICATION) ==> ((state == PIN_CODE_VERIFICATION) (state == DO_SOMETHING) (state == SIM_CARDS_IS_LOCKED))) && ((\ old (state) == DO_SOMETHING) == > (state == DO_SOMETHING)) && ((\ old (state) == SIM_CARDS_IS_LOCKED) ==> (state == Consider some issues of verification of the received application (method item 6). Since the generated code does not have full functionality, the message about The error can be traced by creating it artificially, for example, by adding an invalid value to the state variable in the applet constructor (Listing 4).((\ old (state) == SIM_CARDS_IS_LOCKED) ==> (state == Let's consider some issues of verification of the received application (method item 6). Since the generated code does not have full functionality, the error message can be traced by creating it artificially, for example by adding an invalid value to the state variable in the applet constructor (Listing 4).((\ old (state) == SIM_CARDS_IS_LOCKED) ==> (state == Let's consider some issues of verification of the received application (method item 6). Since the generated code does not have full functionality, the error message can be traced by creating it artificially, for example by adding an invalid value to the state variable in the applet constructor (Listing 4).
An artificially created error in the program public PINApplet () {state = (byte) 5; } In this case, it is enough to use the simplest dynamic check tool (methodology item 7, a). Let's run the jmlc tool (Listing 5) and make sure it finds this error (Method # 9). Listing 5. Message from jmlc tool (snippet) parsing .. \ .. \ .. \ pinapplet.java parsing .. \ specs \ javacard \ framework \ apdu.jml parsing .. \ specs \ javacard \ framework \ applet.jml parsing. . \ specs \ javacard \ framework \ iso7816.jml parsing .. \ specs \ javacard \ framework \ isoexception.jml ... typechecking .. \ .. \ .. \ pinapplet.java ... Exception in thread main org.jmlspecs .jmlrac.runtime.jmlinvarianterror: by method PinApplet.java, line 70, character 17> ... Done Conclusion Automata programming technology provides an approach for developing correct embedded and reactive applications. In this paper, we propose its extension for creating Java Card applications. An additional guarantee of the correctness of the created programs is the use of design by contract. In contrast to the already existing research on verification of automata programs, in this work it is proposed to combine various approaches to apply verification of the source or byte code, and not only the Model Checking technology. At the same time, it is proposed to start the verification of the application with the verification of the model using the Model Checking technology. By transferring the model isomorphically to the source code level and complementing the specification with a description of the behavior of input and output actions, it is possible to guarantee that the code corresponds to the already checked model and, in addition, the correctness of other methods, which was impossible to check using the Model Checking technology. If necessary, a similar check can be carried out at the byte-code level. Therefore, verification can be carried out at all stages of application development. List of sources 1. Chen J. Technology Java Card for smart cards. Architecture and Programmer's Guide. Moscow: Technosphere, 2008.
NASA LaRC Formal Methods Program: What is Formal Methods? 3. Shalyto AA Algorithmization and programming for logical control systems and "reactive" systems // Automation and telemechanics, with Poll E., van den Berg J., Jacobs B. Specification of the JavaCard API in JML / Proc. Fourth Smart Card Research and Advanced Application Conference, pp Coglio A. An Approach to the Generation of High-Assurance Java Card Applets / Proc. 2nd NSA Conf. on High Confidence Software and Systems (HCSS 02). 2002, pp Hubbers E., Oostdijk M., Poll E. From finite state machines to provably correct Java Card applets / Proc. 18th IFIP Inform. Security Conf. 2003, pp Hubbers E., Oostdijk M. Generating JML specifications from UML state diagrams / Proc. Forum on specification and Design Languages (FDL 03). 2003, pp Gurov V.S., Mazin M.A., Shalyto A.A. UniMod tool for automata programming // Scientific and technical bulletin. Issue 30. Fundamental and applied research of information systems and technology. SPbSU ITMO. 2006, p. Development of verification technology for control programs with complex behavior, built on the basis of an automaton approach. Interim report on stage II. SPbSU ITMO, Velder S.E., Shalyto A.A. An introduction to the verification of automata programs based on the Model checking method. // Scientific and technical bulletin. Issue 42. Fundamental and applied research of information systems and technologies. SPbSU ITMO. 2007, p. Nepomnyashchy V. A., Ryakin O. M. Applied methods of program verification. M .: Radio and communication, Kuzmin E. V., Sokolov V. A. On the verification of "automatic" programs / Actual problems of mathematics and informatics. Collection of articles for the 20th anniversary of the Faculty of ICT, YarSU named after P.G.Demidova, Yaroslavl: YarSU. 2006, p. Korneev G. A., Parfenov V. G., Shalyto A. A. Verification of automatic programs / Abstracts of the International Scientific Conference dedicated to the memory of Professor A. M. Bogomolov. "Computer Science and Technology". Saratov: SSU. 2007, with Clarke EM, Wing JM Formal methods: State of the Art and Future Directions // ACM Computing Surveys Vol. 4, pp Meyer B. Object-oriented design of software systems. Moscow: Russian edition, Leavens GT, Cheon Y. Design by Contract with JML Leavens GT, Baker AL, Ruby C. Preliminary design of JML: A behavioral interface specification language for Java. Iowa State Univ., Dept. of Comput. Sci. Tech. Rep u, Burdy L., et. al. An overview of JML tools and applications // Int. J. on Software Tools for Technology Transfer (STTT). 7 (3). 2005, pp Harel D., Pnueli A. On the Development of Reactive Systems. In Logic and Models of Concurrent Systems / NATO Advanced Study Institute on Logic and Models for Verification and Specification of Concurrent Systems. 1985, pp
Shalyto A. A. Automatic program design. Algorithmization and programming of logical control problems // Izvestiya RAN. Theory and control systems. 2000, 6, with Shopyrin D. G., Shalyto A. A. Synchronous programming // Information control systems, with Shalyto A. A. Paradigm of automatic programming / International scientific and technical multiconference "Problems of information technologies and mechatronics". Materials of the International Scientific and Technical Conference "Multiprocessor Computing and Control Systems". Taganrog: NIIVMS vol. 1, with A. A. Shalyto, N. I. Tukkel
