Smart Card Handbook phần 9 pdf

870 Application Design OUTPUT: results of the selection attempts, access conditions and read attempts, as well as any file contents read Output the results of the selection and read attempts. // scan all data objects Attempt to read out all data objects using GET DATA OUTPUT: results of the read attempts and the contents of any data objects read It may be possible to draw conclusions about the smart card and its applications from the data objects. If the DF has a registered AID, the contents of the data objects can be interpreted using the corresponding specification (if available). // scan all commands Test all combinations of CLA and INS This method, which is described in detail in Section 8.2.4.2, ‘Attacks at the logical level’, can be used to determine the commands and secure messaging used by the smart card operating system. OUTPUT: possible allowed combinations of CLA and INS Output the results of the command analysis. STOP End of the analysis. AnalysisMemoryCard: The unknown smart card is a memory card Configure transmission protocol Try each memory card transmission protocol in turn, and as soon as correct data are received, use the currently configured transmission protocol. OUTPUT: detected transmission protocol Output the transmission protocol that has been found. Read all data from the memory card OUTPUT: data content of the memory card Under certain conditions, conclusions can be drawn about the memory card and its application from its data content. STOP End of the analysis. affirmative, the next step is to determine whether it is a memory card or a microcontroller card. Following this, for both types of card an attempt is made to configure the appropriate transmission protocol and read data present in the memory, files or data objects. Based on this information, an attempt is then made to manually determine which applications are present in the smart card. In the case of a microcontroller card, it is often possible to also determine which commands are supported, and thereby draw conclusions about the smart card operating system present in the card. 15.7 LIFE-CYCLE MODELS AND PROCESS MATURITY There are various methods that can be used to produce software. All of them can be generally described using life-cycle models, thus allowing them to be used for a variety of software development projects. Life-cycle models are also often referred to as ‘process models’. A 15.7 Life-Cycle Models and Process Maturity 871 life-cycle model describes, in general terms, the activities to be performed, the sequence of these activities, and the responsibilities and competences. Incidentally, most types of software development life-cycle model can also be used to direct the realization of nearly all types of creative activities and activities involving the development of something new. In the ‘trivial’ life-cycle model for software development, the programmer sits down in front of his or her computer, after having received brief oral instruction regarding the task to be performed, and generates a program, which he or she then modifies until most of the objectionable errors have been eliminated and the customer for the software is more or less satisfied. Surprisingly enough, this simple method can be found not only in stories of the early days of software development, but also in many modern-day forms, in both small and large development projects. It is unquestionably possible to generate innovative and competitive programs with this ‘garage company’ mentality. However, with this life-cycle model the results with regard to compliance with deadlines, development costs and software quality can only be predicted within very broad limits. In the case of software development projects involving complicated tasks and several developers, the resulting complexity of the project can become so large that either the available budget and schedule are vastly exceeded or the entire project must be cancelled before being completed. Consequently, life-cycle models are used in professional software development to provide a development framework, in order to make the three classical factors (schedule, cost and quality) as accurately predictable as possible. relative cost of correcting an error stage of software life cycle analysis 1 3-6 10 15-40 30-70 40-1000 design code test (development) test (acceptance) use 1 10 100 1000 Figure 15.13 The cost of correcting an error as a function of the life-cycle stage of the software relative to the analysis stage. This diagram is based on a publication by Boehm [Boehm 81] Industrial production processes – which naturally also include the development of software – have four characteristic features, as follows: 1. The development process is divided into stages. 2. Each development stage produces results that form the basis for the following stage. 3. The results of a particular stage are checked before the next stage is started. 4. The results of the individual stages are abstract representations of the product that become increasingly concrete from one stage to the next, with the actual product emerging from the final stage. 872 Application Design These characteristics actually originate from classical mechanical engineering, but in principle they are equally applicable to competent software engineering. They form the basis for the life-cycle models described here. Developing software, and incidentally most other development activities as well, requires four general activities. The objective of the first activity is to answer the cardinal question, ‘What has to be developed?’ This means that the objective of the development must be defined as accurately and unambiguously as possible. Here ‘unambiguously’ means that the highly popular subjunctive terms ‘should’, ‘could’, and ‘ought to’ are not allowed to be used in the definition. Practical experience has shown that documents generated during this activity should contain as little prose as possible. Tabular listings and diagrams are ideal, since they leave little room for imprecision and ambiguity. The document resulting from this action is called a requirements specification document, or sometimes a user requirements specification. The activity of generating this document is called analysis or requirements analysis. The requirements specification document forms the basis for all further development activ- ities. Completeness and clarity are thus fundamentally important attributes of this document, which is not allowed to be altered after its final review. In some cases, changing even a single word in the requirements specification could have large consequences for all subsequent de- velopment steps. Here we can use the requirements for the UMTS mobile telecommunication system as an example. The original requirements specified the exclusive use of asymmetric cryptographic algorithms. After extensive discussion, at a relatively late point in time the letter ‘a’ was deleted from the word ‘asymmetric’. As a result, specifications based on these requirements, as well as a number of already existing implementations, had to be completely revised. This extreme example is intended to serve as a persuasive indication of the importance of the requirements specification for all subsequent development steps. The second cardinal question in the development process is, ‘How is the development to be done?’ There are two aspects to this ‘how’. The first aspect relates to organizational con- straints, while the second aspect relates to the structure and architecture of the software to be developed. Answering this question involves fully and unambiguously describing all of the functions and data of the software to be produced. The principlal objectives here are to reduce the complexity of the entire development project to a manageable level, to ensure the modifia- bility and reusability of the developed components, and as necessary to make preparations for partitioning the implementation work. In professional software development, answering the ‘how’ question is the most costly component of the entire development process. This activity is called design, and the result of the design activity is called the design specification document or the software specification. In this book, this activity is consistently referred to as ‘design’, and the resulting document is referred to as the ‘software specification’. Like the requirements specification, the software specification must of course be unam- biguous and not leave any room for interpretation. Ideally, it should be possible to give the finished and reviewed software specification to persons who have not been involved in the design process and have the software be correctly generated on the basis of this document alone, without any requests for clarification. After the questions of what is to be developed, how it is to be developed and how it is to be constructed have been answered, implementation can begin. This is where software developers with a ‘garage company’ mentality actually start the whole development process. If the devel- oper can work from a complete software specification that is not subject to interpretation, the amount of effort that must be expended on implementation is significantly less than the effort 15.7 Life-Cycle Models and Process Maturity 873 required for the two previous stages. With a proper software specification, the software can be simply programmed module by module, with debugging being performed by the person who does the programming. The result of this activity is the software modules, which generally should be free of trivial errors. The developer documentation is generated in parallel with the programming. This consists of all of the documents produced by the programmers during their development activities. Here practical experience has convincingly shown that software should be documented directly in the source code, in part because this makes it significantly easier to find the documentation, but primarily because with this approach, the least amount of information is lost over time. Generating developer documentation is also supported by suitable tools, such as Javadoc, which can automatically generate adequate developer documentation from the information in the source code. In general, appropriate guidelines must also be followed with regard to the structure and documentation of the source code. Following implementation, the module that has been generated, or several modules together, are tested together with the portion of the program that has already been produced up to that point. This is naturally called the test stage. Ideally, testers should be able to perform their tasks with the least possible amount of dependence on the programmers, and the programmers should receive only ‘OK’ or ‘not OK’ as a result. The advantage of this approach is that since the programmers do not know exactly what will be tested, they are compelled to debug their programs as completely as possible. This yields a relatively good ‘four eyes’ situation, with the result that significantly more errors are found than when programmers have a detailed knowledge of the tests their programs will be exposed to and thus ‘polish’ their code to successfully pass these tests. The activities of designing and executing tests are governed by their own methodologies, which are extensively described in Chapter 9. In large systems having a variety of components and multiple component suppliers, com- patibility testing is performed after the software has successfully passed the development tests. After the compatibility tests have been successfully completed, there is usually a formal accep- tance of the software by the customer. However, this acceptance may be based on previously performed tests and inspections and thus has a purely formal character. Following acceptance, the software is released and can be used. After the software has beendelivered and whileitisbeing used, it may benecessarytoexpend effort on maintenance and updating, depending on the application. This consists of eliminating unacceptable errors and making relatively small functional modifications and upgrades to the existing software. An almostinevitable result ofsoftware maintenance isthat the structure ofthe software tends to become increasingly vague with each new revision, even if the software was originally well structured. In many cases, the associated documentation or underlying software specification is not updated when maintenance is performed, leading to discrepancies between the abstract representation in the software specification and the actual product. There are two remedies to this situation. In the case of relatively small and simple programs, maintenance is performed without expending a lot of additional effort, but it is accompanied by planning for a new, completely revised version (‘refactoring’). However, this approach is only permissible for relatively small programs and prototypes. In the case of larger programs, extreme care must be taken when performing maintenance, which means that all software specifications and documents must be suitably updated. Modifications to source code must be performed equally carefully. It may even be necessary to rewrite relatively large portions of the source code in order to ensure that the software continues to have a clearly structured structure. 874 Application Design effort analysis design implement test maintain ideal process actual process start of development delivery end of life life cycle stage of the software Figure 15.14 Comparison of development effort versus software life-cycle stage for an ideal develop- ment process and many actual development projects analysis design implementation test maintenance idea requirements specification program and documentation released program Figure 15.15 Data flow diagram showing the essential activities and documents of a typical software development project for smart cards 15.7.1 Life-cycle models The life-cycle models described below show all of the activities related to the development process in a uniform, graphical manner. An IT-compliant notation similar to data flow diagrams has been used for this graphic representation, in order to make the life-cycle models readily understandable and allow them to be easily compared with each other. Only models that represent pure forms are shown, rather than those representing mixed forms. Pure forms have the advantage that both the positive and the negative features of the model can be clearly seen. 15.7 Life-Cycle Models and Process Maturity 875 Furthermore, only those models that can reasonably be used in the development of software for smart cards have been included in the selection. The description of each life-cycle model contains enough information to allow its basic features to be understood, applied and possibly used in certain cases. There are many other life-cycle models for software development besides the ones de- scribed here. However, they are often mixed forms or specialized versions of the described models. Some clients define their own life-cycle models, particularly in areas where security and reliability are particularly critical, such as military applications, nuclear engineering and aeronautical engineering. More extensive information on this subject can be found in [Blazert 98], among other sources. percentage of total effort testing (16-37 %) implementation (68-12 %) documentation (5-33 %) management (11-18 %) total effort 1 PM 10 PM 100 PM 1 kPM 10 kPM 100 kPM 0 % 40 % 60 % 80 % 20 % Figure 15.16 Comparison of the distribution of effort in a development project as a proportion of total effort. The sum of the individual efforts is always 100 %. The abbreviation ‘PM’ stands for ‘person- month’. These data are based on a publication by C. Jones [Jones 91] 15.7.1.1 The waterfall model The principle of the waterfall model was published in 1956 by Benington, and the addition of integrated retrograde jumps was published by Royce in 1970. The name of this model, from Boehm in 1981, arises from the stepwise arrangement of the activities, which resembles a waterfall. It was the first life-cycle model, and it represents a significant advance over the trivial ‘brain to keyboard’ model. The essential features of the waterfall model are a sequential development process and a straight-line, top-down procedure. Each of the activities shown in Figure 15.17 is performed completely and in prescribed sequence, although it is also allowed regress to the previous activity. This life-cycle model is strongly document-driven, which means that specific docu- ments are generated during each activity and are used in subsequent activities on completion of the activity in which they are generated. This completion is usually marked by a review of the documentation. The waterfall model allows customer involvement only at the beginning, during the definition stage. After this, only the developers are involved in the process until the ultimate release of the software. The waterfall model is a simple life-cycle model that requires only a small amount of coor- dination effort. Using this model yields a clearly defined and readily understood development 876 Application Design idea analysis design implementation test Figure 15.17 Schematic representation of the waterfall model in a form adapted to the development of software for smart cards process. However, if the objectives are not fully defined or not fully known, the prescribed sequential process of the activities can easily lead to problems, since each activity in the sequence can only be started after the previous activity has been fully completed. The waterfall model thus has no provision for activities such as building simple prototypes or conducting simple tests in the definition or design stages, in order to explore implementation options. The fact that the customer is only involved at the beginning, during the definition phase, is a related drawback. The waterfall model is well suited to development projects that do not explore unknown technical territory and have previously been carried out at least once in a similar form. Such development projects generally donotproduce any surprises, since most ofthe general technical and organizational premises are well known at the start. An example from the realm of smart cards is porting a smart card operating system from one type of chip to another type. In this case, all that has to be done is to adapt the software to the technical specifications and features of the microcontroller in question, and to the extent that the code is programmed in assembler, recode the relevant machine instructions. In summary, it can be said that the waterfall model is primarily suitable for non-creative development activities. As soon as unexplored technical territory is entered and innovative, creative developments are necessary, the waterfall model should not be used in any form, since it is not suitable for such projects. If it is nevertheless used, it can lead to massive problems in implementation, since it does not allow critical items to be adequately studied in advance during the analysis and design stages. 15.7.1.2 The V model The V model is essentially a waterfall model with integrated quality assurance. It takes its name from the typical V-shaped diagram used to portray the required activities. Like the waterfall model, the V model has a sequential flow of activities. Each of the individual development 15.7 Life-Cycle Models and Process Maturity 877 activities (analysis, design and implementation) has a corresponding test activity. If necessary, it is possible to jump back to the previous activity. The V model was originally developed for embedded systems – which include smart card microcontrollers – and is a relatively sophisti- cated life-cycle model. The large amount of effort that it requires, particularly with regard to documentation, is balanced by the very high quality of the developed software. Consequently, the V model is primarily used in relatively large developments where high quality is required, such as smart card operating systems and military applications. A detailed presentation of the V model can be found in [Dr¨oschel 99]. idea analysis design implementation test cases test cases application scenarios module test acceptance test system test Figure 15.18 Schematic representationof the V model in a form adapted to thedevelopment of software for smart cards The V model is very suitable for developing software for smart cards when it is important to translate prescribed specifications into program code at a high level of quality. One example would be implementing a GSM 11.11 application in an existing smart card operating system. In this case, the individual commands and the file system can be programmed according to the detailed GSM 11.11 interface specification without a large amount of creative effort. In this case, the most important consideration is complete compliance with the specifications in the GSM 11.11 document. The V model should not be used for completely new developments, since like the waterfall model, it does not provide for iterative development steps or customer involvement after the analysis stage. In summary, the V model is ideal for developments that do not involve exploring unknown technical territory and in which a low level of errors and compliance with specifications have the highest priority. 15.7.1.3 The prototyping model The waterfall model and the V model both envisage a clearly demarcated series of activities following each other in a defined sequence. However, this leads to problems in many software development projects, since it leaves little room for creative solutions resulting from experi- ments. The prototyping model introduces this additional degree of freedom into the life-cycle model. 878 Application Design The purpose of a software prototype is to demonstrate only certain parts of an entire software system. In the ‘horizontal’ version, only certain layers of a software system are implemented. In the case of a smart card operating system, an example of a horizontal prototype would be a complete implementation of all of the transmission protocols, but without processing the actual commands, which would only return dummy responses. This prototype could be used to fully test communicationbetween the terminal and the card. Such a prototype might be used to exper- imentally demonstrate that a high data transmission rate can be achieved using software alone, without hardware support provided by a universal asynchronous receiver/transmitter (UART). Logically enough, the opposite of a horizontal prototype is a ‘vertical’ prototype, in which only certain parts of the software are implemented across all layers. With reference to the previous example, such a prototype could be a complete implementation of a single command, such as INTERNAL AUTHENTICATE, together with a single transmission protocol, possibly only in rudimentary form. This prototype could be used to thoroughly measure the timing behavior of smart card authentication, including all data communications. Incidentally, this approach is the only possible way to perform such a task, since accurate and reliable timing data can only be obtained by experiment, not by analysis. idea test analysis design implementation prototype 1 prototype 2 Figure 15.19 Schematic representation of the prototyping model in a form adapted to the development of software for smart cards A prototype used in software development demonstrates specific features of the software in practical use, in order to allow alternative solution options to be experimentally tested in advance of the overall implementation. Based on the results of prototype testing, the design is then completed or the prototype is further refined, so that it can be used as part of the software to be developed. Since critical requirements can be verified in advance using prototypes, the prototyping life-cycle model is well suited to development projects whose objectives are not precisely specified. Another positive feature of this life-cycle model is that the customer can review and 15.7 Life-Cycle Models and Process Maturity 879 approve the prototypes and then refine his – possibly scanty – requirements, which leads to a more harmonious relationship with the developers. The combination of prototypes that can be used for experiments and an improved relationship with the customer leads to a reduction of risks in the development process. Besides these benefits, there are also several drawbacks that should not be underestimated. Progressing experimentally from prototype to prototype is costly in terms of both time and money, since it is generally necessary to pass through several development stages a number of times while searching for the proper solution. However, the greatest hazard in software development using the prototyping model is not so much technical as organizational. There is a risk that due to schedule or cost pressure, a prototype will be declared to be a finished product and thus delivered much too early. This leads to software that lacks the required functionality and is not fully tested, which means it probably still contains a large number of errors. With software that is generated in this manner, it also frequently happens that the documentation is incomplete or, in the worst case, non-existent. As an aside, it can be noted that the prototyping model corresponds to the software devel- opment method used by many hobbyists. They start with a relatively small central program, usually without any formal definition or design, and extend it step by step while testing each extension, thus developing an increasingly larger program. Many programs, particularly those in the public domain and freeware realm, unfortunately quite clearly demonstrate the result of such a process: an ambitious core functionality has been completely programmed and tested, but the auxiliary functionality is only partially present, and in many cases the documentation is limited to the original core functions. With respect to developing software for smart cards, the prototyping model is very suitable for studies and feasibility analyses in the areas of transmission protocols, cryptographic algo- rithms and file systems. However, the resulting prototype should not be incorporated ‘as is’ into the final product. Instead, it must be brought up to the same level of quality as the rest of the developed software. It is certainly possible for large blocks of prototype source code to be incorporated into the final product, as long as they are adapted to meet the requirements of the overall implementation. Prototype development should not be limited to only the risky components of the program code in an effort to minimize development expenses and effort. In order to minimize the risk of having a prototype being declared to be a product, experienced developers generally implement only subsystems as prototypes, never complete systems. 15.7.1.4 The evolutionary and incremental models The life-cycle models described up to this point require relatively exact requirements analy- ses and specifications. However, in some cases the requirements and specifications cannot be fully defined or can only be determined in very vague terms, such as when a totally new software concept is involved. In addition, actual use of the software gives rise to new requirements and desires on the part of users. The evolutionary and incremental life-cycle models allow these types of requirements to be incorporated into the software development process. With both of these models, the full breadth and depth of the software is developed in a generational sequence, which means that both models are code-driven. After each generation is [...]... disadvantages, can be found in Chapter 5, Smart Card Operating Systems’ Smart card applications file-based applications code-based applications native program code interpreted program code markup languages (generally XML derivatives) Java (and similar) Figure 15.26 Classification of the basic options for implementing smart card applications 15 .9 Design Examples for Smart Card Applications 887 The following... See also Section 8.1.1, ‘Testing a secret number’ 15 .9 Design Examples for Smart Card Applications 895 Proposed solution The proposed solution involves storing a password that is known only to the card user in a file in the smart card This file can be read by the terminal only after it has successfully authenticated itself with respect to the smart card via a secret key After this authentication process,... necessary proof 15 .9 Design Examples for Smart Card Applications Smart card 891 Terminal User SELECT FILE (DF) SELECT FILE (EF 1) READ BINARY SELECT FILE (EF 2) READ BINARY ASK RANDOM MUTUAL AUTHENTICATE enable secure messaging   Response [ || return code]   DECREASE IF (return code = OK) THEN command successfully executed ELSE abort Output 'xx euros debited ' from the smart card' ' Figure 15.28... terminal and the smart card: – access authorization – blocking an application User identification State transition x →1 x →2 2→3 15 .9 Design Examples for Smart Card Applications 893 Table 15.15 The file tree for the ‘access control’ application File FID MF DF DE.EF 1 DE.EF 2 DE.EF 3 Structure '3F00' — — Transparent Linear fixed Linear fixed — '0001' '0002' '0003' Description and contents Smart card root directory... showing the phases of a typical smart card project Phase A: mask generation Phase B: semiconductor fabrication Phase C: module production Phase D: card body production Phase E: initialization and personalization 6 months 10 weeks 2 weeks 4 weeks 4 weeks 15 .9 DESIGN EXAMPLES FOR SMART CARD APPLICATIONS There are basically two different ways to implement applications in smart cards The first type of implementation... smart cards used in this system must have an operating system that can manage several applications and can create files (DFs and EFs) in the smart card file tree after the card has been issued, so that additional applications can be loaded as necessary after the cards have been issued The amount of EEPROM required by the current application and projected future applications will not exceed 1 kB The cards... AUTHENTICATE Key 3 MUTUAL AUTHENTICATE Key 4 Secure messaging Mutual authentication of the terminal and the smart card: – paying with the purse – blocking the purse Mutual authentication of the terminal and the smart card: – unblocking the purse – card management Mutual authentication of the terminal and the smart card: – loading the purse Protecting data transmission – authentic mode State transition x →1 x →2... manner to illicitly collect magnetic-stripe data and associated PIN codes If smart cards are used, good protection against this type of attack can be provided with a suitable application design Requirements It is necessary to design a component of a smart card application that allows the card user to recognize a counterfeit smart card terminal (but not a manipulated terminal) The user must not need any... intervals, the data so obtained are transferred by cable or a special transfer card to the administration PC, which 15 .9 Design Examples for Smart Card Applications 8 89 evaluates this information The file tree of the proposed solution is shown in Table 15.11 It requires around 100 bytes in EEPROM, depending on the smart card operating system Table 15.11 File tree of the ‘arcade games’ sample application... numerous lexicons devoted to EDP terminology, such as [Pfaffenberger 97 , Dictionary of Computing 91 ] µP card An alternate designation for → microprocessor card 0-PIN A common, known PIN used for all newly issued → smart cards, which does not allow access to the actual user functions It is thus a type of → trivial PIN The first time the card is used, the 0-PIN must be changed to a user-selected PIN using . basic options for implementing smart card applications 15 .9 Design Examples for Smart Card Applications 887 The following examples illustrate three typical smart card applications. These are mid- range. organization, began working on this model in late 198 6 and published the first version in 199 1. The currently valid version is Version 1.1, which dates from 199 3 [CMM 93 ]. Besides CMM, there is also a relatively. for developing each version of a smart card operating system. To take another example, we use the waterfall model to produce each new edition of the Smart Card Handbook. We first generate an analysis