Smart Card Handbook phần 9 pdf

analysis design implement test maintain ideal process actual process start of development delivery end of life life cycle stage released program Figure 15.15 Data flow diagram showing th

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

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 beused to determine the commands and securemessaging used by the smart card operating system.OUTPUT: possible allowed

combinations of CLA and INS

Output the results of the command 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 thecurrently 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 drawnabout the memory card and its application from itsdata content

affirmative, the next step is to determine whether it is a memory card or a microcontrollercard Following this, for both types of card an attempt is made to configure the appropriatetransmission protocol and read data present in the memory, files or data objects Based on thisinformation, 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 determinewhich commands are supported, and thereby draw conclusions about the smart card operatingsystem 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 generallydescribed using life-cycle models, thus allowing them to be used for a variety of softwaredevelopment 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 ofthese activities, and the responsibilities and competences Incidentally, most types of softwaredevelopment life-cycle model can also be used to direct the realization of nearly all types ofcreative activities and activities involving the development of something new

In the ‘trivial’ life-cycle model for software development, the programmer sits down infront 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 theobjectionable errors have been eliminated and the customer for the software is more or lesssatisfied Surprisingly enough, this simple method can be found not only in stories of the earlydays of software development, but also in many modern-day forms, in both small and largedevelopment projects It is unquestionably possible to generate innovative and competitiveprograms with this ‘garage company’ mentality However, with this life-cycle model the resultswith 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 involvingcomplicated tasks and several developers, the resulting complexity of the project can become solarge 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 professionalsoftware development to provide a development framework, in order to make the three classicalfactors (schedule, cost and quality) as accurately predictable as possible

relative cost of

correcting an error

stage of software life cycle analysis

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 becomeincreasingly concrete from one stage to the next, with the actual product emerging from thefinal stage

These characteristics actually originate from classical mechanical engineering, but in principlethey are equally applicable to competent software engineering They form the basis for thelife-cycle models described here.

Developing software, and incidentally most other development activities as well, requiresfour 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 highlypopular subjunctive terms ‘should’, ‘could’, and ‘ought to’ are not allowed to be used inthe definition Practical experience has shown that documents generated during this activityshould contain as little prose as possible Tabular listings and diagrams are ideal, since theyleave little room for imprecision and ambiguity The document resulting from this action iscalled 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 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 singleword in the requirements specification could have large consequences for all subsequent de-velopment steps

activ-Here we can use the requirements for the UMTS mobile telecommunication system as anexample The original requirements specified the exclusive use of asymmetric cryptographicalgorithms After extensive discussion, at a relatively late point in time the letter ‘a’ was deletedfrom 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 extremeexample is intended to serve as a persuasive indication of the importance of the requirementsspecification 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 straints, while the second aspect relates to the structure and architecture of the software to bedeveloped Answering this question involves fully and unambiguously describing all of thefunctions and data of the software to be produced The principlal objectives here are to reducethe 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 forpartitioning the implementation work In professional software development, answering the

con-‘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 biguous and not leave any room for interpretation Ideally, it should be possible to give thefinished and reviewed software specification to persons who have not been involved in thedesign process and have the software be correctly generated on the basis of this documentalone, without any requests for clarification

unam-After the questions of what is to be developed, how it is to be developed and how it is to beconstructed have been answered, implementation can begin This is where software developerswith 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, theamount 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 besimply programmed module by module, with debugging being performed by the person whodoes the programming The result of this activity is the software modules, which generallyshould 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 Herepractical experience has convincingly shown that software should be documented directly inthe 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 inthe source code In general, appropriate guidelines must also be followed with regard to thestructure 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 thatpoint This is naturally called the test stage Ideally, testers should be able to perform theirtasks with the least possible amount of dependence on the programmers, and the programmersshould receive only ‘OK’ or ‘not OK’ as a result The advantage of this approach is that sincethe programmers do not know exactly what will be tested, they are compelled to debug theirprograms as completely as possible This yields a relatively good ‘four eyes’ situation, withthe result that significantly more errors are found than when programmers have a detailedknowledge of the tests their programs will be exposed to and thus ‘polish’ their code tosuccessfully 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, 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 previouslyperformed tests and inspections and thus has a purely formal character Following acceptance,the software is released and can be used

com-After the software has been delivered and while it is being used, it may be necessary to expendeffort on maintenance and updating, depending on the application This consists of eliminatingunacceptable errors and making relatively small functional modifications and upgrades to theexisting software An almost inevitable result of software maintenance is that the structure of thesoftware tends to become increasingly vague with each new revision, even if the software wasoriginally well structured In many cases, the associated documentation or underlying softwarespecification is not updated when maintenance is performed, leading to discrepancies betweenthe abstract representation in the software specification and the actual product There are tworemedies to this situation In the case of relatively small and simple programs, maintenance isperformed 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 permissiblefor relatively small programs and prototypes In the case of larger programs, extreme caremust be taken when performing maintenance, which means that all software specifications anddocuments must be suitably updated Modifications to source code must be performed equallycarefully It may even be necessary to rewrite relatively large portions of the source code inorder to ensure that the software continues to have a clearly structured structure

analysis design implement test maintain

ideal process actual process

start of

development

delivery end of life

life cycle stage

released program

Figure 15.15 Data flow diagram showing the essential activities and documents of a typical softwaredevelopment project for smart cards

15.7.1 Life-cycle models

The life-cycle models described below show all of the activities related to the developmentprocess in a uniform, graphical manner An IT-compliant notation similar to data flow diagramshas been used for this graphic representation, in order to make the life-cycle models readilyunderstandable and allow them to be easily compared with each other Only models thatrepresent pure forms are shown, rather than those representing mixed forms Pure forms havethe 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 softwarefor smart cards have been included in the selection The description of each life-cycle modelcontains enough information to allow its basic features to be understood, applied and possiblyused in certain cases

There are many other life-cycle models for software development besides the ones scribed here However, they are often mixed forms or specialized versions of the describedmodels Some clients define their own life-cycle models, particularly in areas where securityand reliability are particularly critical, such as military applications, nuclear engineering andaeronautical engineering More extensive information on this subject can be found in [Blazert98], among other sources

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 thetrivial ‘brain to keyboard’ model

The essential features of the waterfall model are a sequential development process and astraight-line, top-down procedure Each of the activities shown in Figure 15.17 is performedcompletely and in prescribed sequence, although it is also allowed regress to the previousactivity 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 ofthe 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 theultimate release of the software

The waterfall model is a simple life-cycle model that requires only a small amount of dination effort Using this model yields a clearly defined and readily understood development

The waterfall model is well suited to development projects that do not explore unknowntechnical territory and have previously been carried out at least once in a similar form Suchdevelopment projects generally do not produce any surprises, since most of the general technicaland organizational premises are well known at the start An example from the realm of smartcards is porting a smart card operating system from one type of chip to another type In thiscase, 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-creativedevelopment 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 advanceduring 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 namefrom the typical V-shaped diagram used to portray the required activities Like the waterfallmodel, 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 forembedded 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 todocumentation, 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]

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 examplewould 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 thedetailed GSM 11.11 interface specification without a large amount of creative effort In thiscase, the most important consideration is complete compliance with the specifications in theGSM 11.11 document

The V model should not be used for completely new developments, since like the waterfallmodel, it does not provide for iterative development steps or customer involvement afterthe analysis stage In summary, the V model is ideal for developments that do not involveexploring unknown technical territory and in which a low level of errors and compliance withspecifications 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 activitiesfollowing each other in a defined sequence However, this leads to problems in many softwaredevelopment 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-cyclemodel

The purpose of a software prototype is to demonstrate only certain parts of an entire softwaresystem 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 acomplete implementation of all of the transmission protocols, but without processing the actualcommands, which would only return dummy responses This prototype could be used to fullytest communication between 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 whichonly certain parts of the software are implemented across all layers With reference to theprevious example, such a prototype could be a complete implementation of a single command,such as INTERNAL AUTHENTICATE, together with a single transmission protocol, possiblyonly in rudimentary form This prototype could be used to thoroughly measure the timingbehavior of smart card authentication, including all data communications Incidentally, thisapproach is the only possible way to perform such a task, since accurate and reliable timingdata can only be obtained by experiment, not by analysis

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 inadvance of the overall implementation Based on the results of prototype testing, the design isthen 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 prototypinglife-cycle model is well suited to development projects whose objectives are not preciselyspecified 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 amore harmonious relationship with the developers The combination of prototypes that can beused for experiments and an improved relationship with the customer leads to a reduction ofrisks 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 andmoney, 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 softwaredevelopment 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 productand thus delivered much too early This leads to software that lacks the required functionalityand is not fully tested, which means it probably still contains a large number of errors Withsoftware that is generated in this manner, it also frequently happens that the documentation isincomplete or, in the worst case, non-existent

As an aside, it can be noted that the prototyping model corresponds to the software 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 eachextension, thus developing an increasingly larger program Many programs, particularly those

devel-in the public domadevel-in and freeware realm, unfortunately quite clearly demonstrate the result ofsuch 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 suitablefor 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 ofthe developed software It is certainly possible for large blocks of prototype source code to beincorporated into the final product, as long as they are adapted to meet the requirements of theoverall implementation

Prototype development should not be limited to only the risky components of the programcode in an effort to minimize development expenses and effort In order to minimize the risk ofhaving a prototype being declared to be a product, experienced developers generally implementonly 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 ses and specifications However, in some cases the requirements and specifications cannot

analy-be fully defined or can only analy-be determined in very vague terms, such as when a totallynew software concept is involved In addition, actual use of the software gives rise to newrequirements and desires on the part of users The evolutionary and incremental life-cyclemodels allow these types of requirements to be incorporated into the software developmentprocess

With both of these models, the full breadth and depth of the software is developed in agenerational sequence, which means that both models are code-driven After each generation is

released, user experience is analyzed, and the results of this analysis enter into the development

of the following generation as general requirements The difference between the evolutionaryand incremental models is that in the evolutionary model, a complete requirements analysis isperformed for each new generation, while in the incremental model, a complete requirementsanalysis is only performed at the beginning of the overall development process Both modelsare well suited to use in development projects where some of the requirements are unknown,since the functionality of the software can be adapted to the actual requirements step by step

in the course of successive generations Both models are program-code-driven, which meansthat the product is used in actual practice between successive generations, which differs fromthe prototyping model

Both the evolutionary model and the incremental model lead to a minimization of opment risks They also allow the direction of development to be steered within certain limitsduring the development process However, these benefits come at the price of higher devel-opment costs and the risk that extensive modifications to the software architecture may benecessary in later generations, due to incomplete analysis at the beginning of the developmentprocess This problem can become particularly severe with the evolutionary model, since a newanalysis must be performed for each new generation In the incremental model, the completedevelopment is analyzed at the beginning, following which only differences with respect tothe initial analysis are generated between successive generations Consequently, changes fromone generation to the next should not have any fundamental effect on the software architecture.The evolutionary and incremental models can be used to advantage with completely newdevelopments of a research nature They allow a high degree of requirements coverage to

devel-15.7 Life-Cycle Models and Process Maturity 881

be achieved in the course of several generations, which preferably should follow each otherrelatively quickly Consequently, these two life-cycle models are usually used for implement-ing new smart card operating systems Another application area is the development of new,loosely defined smart card applications that are interactively adapted to meet their ultimaterequirements over the course of several generations

15.7.1.5 The spiral model

The spiral model is a metamodel, which means that it is a model that can incorporate any ofthe previously described life-cycle models in order to use the most suitable model for eachversion of a software product The spiral model takes its name from the spiral shape of thediagram used to represent this method, in which the area inside the spiral corresponds to thesum of the development costs

The development process is divided into four stages in the spiral model The objectivesfor the software to be developed are defined in the first stage, and in the next stage, possibleoptions for attaining these objectives are determined using risk analysis In the third stage, thesoftware is developed using the most suitable life-cycle model If the entire development is notthereby completed, the following cycle is planned in the fourth stage, based on the results of theprevious stages After this, the first stage is repeated again with the setting of new objectives.Fundamentally, the spiral model is primarily suitable for large development projects, since itrequires a relatively large amount of coordination effort due to its complex sequence However,

it has the advantage of being very flexibly adaptable to a variety of different tasks, and it ishighly suitable for developing software over the course of several generations

For example, a card operating system can be developed using the spiral model as follows.First, versions 1, 2 and 3 of the operating system are developed using the evolutionary model.This produces three research versions that are used for studies and experimental purposes,during which the operating system is incrementally refined and adapted to meet the necessaryrequirements The next version (version 4) is then developed as a deliverable customer versionusing the V model The V model is chosen here because one of its characteristics is very highsoftware quality Customer versions of smart card software are sometimes formally evaluated(using ITSEC or CC), and most of the documents required for this purpose must be generated

if the V model is used properly In our example, the next software development task is portingthe operating system to a different microcontroller Since this involves only very small risksand has only a small creative element, it is preferably performed using the waterfall model.This example clearly shows how the spiral model can be used as a metamodel in which suitablelife-cycle models can be used to best advantage for developing each version of a smart cardoperating 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 (the outline), which defines which topics

must be revised or expanded and which completely new chapters are to be produced Next,

in collaboration with the publisher we decide how the changes and additions are to be mented This is followed by a period in which the text is written, the illustrations are generatedand the book is laid out After this, the publisher’s proofreaders and production staff checkwhether everything has been done properly The individual editions of the book are in turnembedded in an evolutionary process, since a complete analysis is performed for each newedition

imple-15.7.2 Process maturity

Several different methods are used within organizations to assess the quality of softwaredevelopment processes Presently, the best-known method involves assessing process maturityusing the Capability Maturity Model (CMM) The Software Engineering Institute (SEI), anAmerican organization, began working on this model in late 1986 and published the firstversion in 1991 The currently valid version is Version 1.1, which dates from 1993 [CMM 93].Besides CMM, there is also a relatively new method for assessing process maturity based onthe ISO 15 504 standard, but up to now it has not been widely used in practice Consequently,here we provide a general summary of this subject based on the CMM

There are five levels of process maturity in the CMM scheme, with level 1 corresponding

to the lowest process quality and level 5 corresponding to the highest process quality At thefirst level, which is called the ‘initial level’, the person or organization doing the development

is assigned a task and ultimately produces a product, using a process characterized by poorlypredictable expenditures of time, uncertain costs and equally unpredictable quality The indi-vidual steps in the development processes are not defined, and the developers behave more likeartists than skilled or industrial workers The product to be developed is sometimes producedjust within the allowable limits of effort, schedule and quality, thanks to the heroic efforts of in-dividual persons, using a development process that can unquestionably be described as chaotic

At leve1 2, the ‘repeatable’ level, individual activities are defined within a specific work, such as analysis, design, implementation and testing The details of what happens within

frame-15.7 Life-Cycle Models and Process Maturity 883

Figure 15.22 Schematic representation of the five CMM levels of process maturity The blocks marked

‘C’ represent control processes

the contexts of these general activities are not specified At the next level, the ‘defined’ level,the details of the individual activities are indeed defined At this level, there is a sufficientdegree of agreement on the content of the activities in the development process that they can

be repeated or reconstructed at any time As a result, the quality of the development process issignificantly higher, and the range of variance in compliance with schedule and cost parametersduring the development project is smaller than at the previous levels At level 3, the process

is also characterized by being independent of specific individuals, since all of the requiredactivities are defined By contrast, there is a high degree of dependence on individual persons

at levels 1 and 2 At level 3, the quality of the developed software is still not predictable,since the process is rigidly defined in advance and cannot be flexibly adapted to the variousrequirements of the development process

Level 4, which is called the ‘managed’ level, incorporates control loops within the individualactivities, thus allowing the development process to be adapted to the varying requirements

of development projects The individual process stages are controlled using measured dataacquired during the development process on the basis of software metrics

The highest quality level is level 5, the ‘optimizing’ level It involves applying controlsnot only to individual activities, but also across several activities These activities can also bereplaced as necessary by new, improved activities, allowing the overall development process

to be constantly adapted to optimally satisfy varying requirements Compliance with the threecardinal criteria – schedule, cost and quality – can be achieved within suitable limits by usingprocess parameters recorded during the development process

subproblem 1

very high risk high risk

medium risk low risk

problem analysis conducted?

problem analysis conducted?

With its five levels of maturity, the CMM is naturally a highly abstract representation ofdevelopment processes An existing process is assessed by having the persons involved inthe process anonymously answer a list of approximately 100 yes/no questions The objective

of this is to obtain truthful responses, and thus an objective assessment of the developmentprocess within an organization

In most companies, process quality is at level 1 or 2 Only a handful of companies throughoutthe world, most of which are active in typical high-end software areas such as aerospace, nucleartechnology and military technology, can boast level 5 quality for all of their developmentactivities

Of course, the quality of software does not depend on process quality alone, and it is tainly possible for software produced using a poor-quality development process to be highlyinnovative and extremely successful commercially However, the likelihood of meeting targetsfor cost, quality and completion deadlines decreases as the quality of the development process

cer-15.8 The Course of a Smart Card Project 885

drops In the worst case, it may be necessary to prematurely terminate a development projectbecause the development budget has been exhausted, the completion date is no longer accept-able or the majority of the software will never function in a satisfactory manner, due to itshigh level of complexity These risks decrease as the quality level in the development processincreases

reality

time & effort

Figure 15.24 Comparison of the actual (measured) course of software development and the course ofthe development process as subjectively experienced by the software developer This diagram assumes aconstant total development effort

15.8 THE COURSE OF A SMART CARD PROJECT

The course of a smart card project is shown in Figure 15.25 Currently, card manufacturersalso develop the associated microcontroller software This means that the first phase (A)and last phase (E) of the project are performed by the same company Phases B and C areperformed by a semiconductor manufacturer The dice can be built into the modules eitherdirectly by the semiconductor manufacturer or by the card manufacturer Phase E, whichincludes initialization, personalization and related activities, is always fully performed by thecard manufacturer The card manufacturer also usually manages the smart card project, withthe rest of companies more or less acting as subcontractors

This brief description says very little about the time required for the individual productionprocesses However, this should not be underestimated, since several different companies worktogether to produce smart cards, and the elapsed time for some processes can be many weeks.Typical times for the completion time of the most important production steps are also shown

in Figure 15.25 This example is based on the following assumptions:

r50,000 cards are to be produced

ra new operating system must be generated, based largely on existing libraries

rall companies involved have mid-range production capacities

reach production process can start immediately after the necessary parts are received

Figure 15.25 Gantt chart showing the phases of a typical smart card project

Phase A: mask generation 6 months

Phase B: semiconductor fabrication 10 weeks

Phase C: module production 2 weeks

Phase D: card body production 4 weeks

Phase E: initialization and personalization 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 is based on files with defined access conditions With such an tion, the necessary commands generally comply with the usual smart card standards, such asISO/IEC 7816-4 The other type of implementation is based on program code executed in thesmart card There are several different variants of this type of implementation The programcode can be directly executed by the processor in the smart card (native code), or it can beinterpreted In the case of interpreted code, a distinction can be made between microbrowsers(such as XML derivatives) and virtual machines (such as Java) Detailed descriptions of thevarious options, including their advantages and disadvantages, can be found in Chapter 5,

implementa-‘Smart Card Operating Systems’

Smart card applications

Figure 15.26 Classification of the 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 range electronic data-processing applications that do not require elaborate system designs.They might typically be used by medium-sized companies The background system employedcould be a PC located a secure environment, which means that the acquisition and operatingcosts would both be at the low end of the scale

mid-These simple examples clearly illustrate how a typical smart card application is constructed.The construction is explained step by step, gradually building up to the finished application inthe smart card In each case, we give only cursory attention to the terminals and the backgroundsystem, but these aspects of the system can be deduced from the provided information.All of these examples are based on the principle of distributing data among many indi-vidual, separate systems This contrasts with commonly used centralized mainframe solu-tions, in which all of the information is stored in one place If such an approach is translatedinto a smart card application, the result is that the card is only a sort of proof of identifica-tion, with all of the information being held in an omniscient background system Whenever

an application constructed this way must be extended, a regularly observed consequence isthat the all-powerful background system must undergo an expensive and time-consumingupgrade

Here we have attempted to take a different approach The background system is onlyresponsible for the management and consistency of the overall system All other information

is held locally in the cards A global database is of course necessary for system administration,

so that lost or faulty cards can be reproduced from data on hand However, the information inthis database should not be necessary for normal operation of the system

A distributed smart card system may be thought of as a large tree with many branches, whichlike all trees draws its energy from photosynthesis in its many leaves Energy production

is distributed among the leaves, and it occurs in many places simultaneously Figurativelyspeaking, an effective and well-designed smart card application behaves in the same way Theinformation is stored in decentralized cards and is thus protected against every form of attack.The large mass of information also does not burden the background system, which only has

to deal with the centralized management tasks The actual system processes are decentralized,just like the process of photosynthesis in the leaves of a tree, and they take place in parallel

in localized terminals and smart cards This makes it very easy to extend the overall system

by adding more terminals and cards, without needing to worry about any major impact on thebackground computer system

The opposite approach to the system just outlined is to concentrate all of the necessaryactivities in a central background system In our analogy, this would amount to moving pho-tosynthesis from the tree’s leaves to its trunk, which would result in a huge trunk The overallsystem would not only be very large and expensive, it would also be extremely vulnerable todisturbances in the background system This should be avoided as much as possible

In their ignorance of the characteristics of smart cards, many novice system operators makethe mistake of designing the entire system from the top down When it comes to the parts ofthe system that are most critical in terms of security, namely the terminals and smart cards, inmany cases they simply stipulate that these components can be made secure in some more orless unknown manner

By contrast, the designs described here represent a bottom-up approach, in which the systemand its required features are defined by starting with the lowest-level object (the smart card)and working upwards The risk of security gaps can be very effectively minimized using thisapproach, since the system is constructed securely from the smallest entity all the way to the top

15.9.1 An electronic purse system for arcade games

Situation and objectives

This smart card application is intended to provide functions that allow small amounts of money

to be paid into arcade game machines Smart cards are to replace the coins conventionally usedwith such machines, in order to reduce operating costs

There are two types of terminals The first type is a loading terminal, which has a coinslot with a coin tester and can load electronic ‘currency’ into smart cards The second type is

a debiting terminal, which operates largely autonomously and debits the electronic currencyfrom the smart card

Requirements

The entire system should be anonymous, while still allowing all money flows to be monitored

If there is a suspicion of fraud, it must be possible to identify individual cards and selectivelyblock them

Since this is a payment system application, and considering that the equipment used is fullyautomatic and operates without human supervision, the design should aim for a medium level

of security

Proposed solution

The solution is based on a simple closed purse system that is specifically designed to meet therequirements of this application Naturally, it could easily be used for similar applications bymaking small modifications to the files and procedures We have avoided using an electronicpurse system that is compliant with the CEN EN 1546 standard, since such a solution would

be more expensive for the application provider than the proposed solution In addition, ourobjective is to demonstrate the principles of a simple closed purse system

In a central location, there is an automated machine that can accept both coins and banknotesand load the equivalent amount of electronic currency into a smart card Neither a PIN norany other user input is necessary, as the electronic purse is anonymous The only accountingperformed for the amounts loaded into the cards is based on individual card numbers, each ofwhich is unique within the system

A PC administers all of the data and the money flows The PC also contains a database thatholds general information for all issued cards A daily or weekly balance calculation can beused to check that the money flows in the system remain closed

At a payment (debit) terminal, the monetary units loaded into the smart card are debitedfrom the electronic purse A display on this terminal shows the user the amount that has beendebited To keep the cost of the terminals as low as possible, data transfers are protected bysecure messaging instead of a shutter Each terminal has a security module to store the secretkey and keep track of the amounts paid, sorted by card number At regular 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 889

evaluates this information The file tree of the proposed solution is shown in Table 15.11 Itrequires around 100 bytes in EEPROM, depending on the smart card operating system

Table 15.11 File tree of the ‘arcade games’ sample application

File FID Structure Description

MF '3F00' — Smart card root directory

DF — — Directory for the ‘arcade games’ applicationDF.EF 1 '0001' Transparent Date of issue and card number

DF.EF 2 '0002' Cyclic Amount

DF.EF 3 '0003' Linear fixed Key 1

Key 2Key 3Key 4

Regular data exchanges between the debiting terminals and the administration computercan be used to maintain a blacklist of blocked cards in the terminals If a terminal determinesthat an inserted card is on the blacklist, it blocks the EF2 file containing the electronic money.After this, the card can no longer be used to make payments The user must have the cardunblocked at the administration terminal, and when this is done, a check can be made to seewhy the card was put on the blacklist

The keys needed for this application are listed in Table 15.12 In the interest of having asimple overall system, we have not used derived keys or card-specific keys

Table 15.12 Keys required for the ‘arcade games’ sample application

Key Used for Function State transition

Key 1 MUTUAL Mutual authentication of the x→ 1

AUTHENTICATE terminal and the smart card:

– paying with the purse– blocking the purseKey 2 MUTUAL Mutual authentication of the x→ 2

AUTHENTICATE terminal and the smart card:

– unblocking the purse– card managementKey 3 MUTUAL Mutual authentication of the x→ 3

AUTHENTICATE terminal and the smart card:

– loading the purseKey 4 Secure messaging Protecting data transmission —

– authentic mode

The proposed solution is very suitable for paying for services received from automaticequipment Human supervision is unnecessary However, it is not essential to use a specialmachine to automatically load ‘money’ into the cards Cards could also be loaded manu-ally at a service counter, in exchange for a cash payment equal to the amount to be loaded

Table 15.13 Access conditions for the ‘arcade games’ application

(≥ 0: always, < 0: never, SM: secure messaging)

File Read Write Block Unblock Increase Decrease

SELECT FILE (EF 1) ''Insert money''

READ BINARYSELECT FILE (EF 2)READ BINARYASK RANDOMMUTUAL AUTHENTICATE

enable secure messaging

  INCREASE

Response [ ||   IF (return code= OK) Output

return code] THEN command successfully executed ''xx euros loaded in

ELSE abort the smart card''

Figure 15.27 Basic command sequence for loading electronic monetary units into the purse in the

‘arcade games’ application

15.9.2 Access control system

Situation and objectives

The objective of this application is to create a smart card based, graduated access control systemfor a number of rooms and computer systems This means that certain doors and computerswill be fitted with terminals that will allow people to pass through the associated door or use theassociated computer after communication with a smart card It is important to be able to definevarious security levels, for which access can be limited to specific groups of users Access will

be granted after successful authentication and identification of the user The necessary proof

15.9 Design Examples for Smart Card Applications 891

SELECT FILE (DF)SELECT FILE (EF 1)READ BINARYSELECT FILE (EF 2)READ BINARYASK RANDOMMUTUAL AUTHENTICATE

enable secure messaging

  DECREASE

Response [ ||   IF (return code= OK) Output

return code] THEN command successfully executed ''xx euros debited

ELSE abort from the smart card''

Figure 15.28 Basic command sequence for making a payment from the purse in the ‘arcade games’application

will be possession of a genuine card and knowledge of its associated PIN If both of thesecriteria are satisfied, access will be granted The terminals must be able to maintain simpleblacklists, so that ‘lost’ cards cannot be used for access, and such cards can be permanentlyblocked if necessary

Requirements

In order to maximize user acceptance of the solution, the time required for any communicationprocess between the terminal and the smart card, together with the subsequent granting ofaccess, must not significantly exceed one second A longer interval will sooner or later sig-nificantly impede user acceptance of the system and encourage users to use various tricks tocircumvent security measures, such as propping open doors Users must be able to select theirown PIN codes so that they do not resort to writing their PIN codes on the cards

The system should be designed for a moderately low level of security, as it is fairly unlikely

to be subjected to elaborate attacks or analysis The acquisition and operating costs of thesystem must not exceed those of a good conventional key–lock system, since the latter wouldotherwise represent a more economical alternative

The system and smart card must be designed to allow timecard and canteen billing functions

to be incorporated into the system at a later date

Proposed solution

Simple terminals with 10-digit numeric keypads will be firmly attached to the appropriate doorsand computers These terminals can work autonomously, and they are fitted with economical,

exchangeable security modules (such as smart cards in plug-in format) They can grant rized persons access to the associated doors or computers Any terminal at a critical or sensitivelocation can if necessary independently establish a link to the PC that serves as the centralsystem computer, via a two-wire cable This simple architecture satisfies the requirement forlow operating costs.

autho-The central computer has a simple multitasking operating system to allow it to executeseveral tasks in parallel It is connected to a supplementary terminal that is responsible foradministering the entire system

The smart cards used in this system must have an operating system that can manage severalapplications and can create files (DFs and EFs) in the smart card file tree after the card hasbeen issued, so that additional applications can be loaded as necessary after the cards havebeen issued The amount of EEPROM required by the current application and projected futureapplications will not exceed 1 kB The cards will be purchased from a card manufacturercomplete with the operating system, and then configured appropriately using the administrationcomputer

All cards will initially have a standard and easily remembered PIN The simplest option inthis case is''0000'' This eliminates the cost of generating PINs and preparing PIN letters Uponreceipt of the card, each user must change the standard PIN to some other number using theadministration terminal, since all terminals will reject a PIN entry of''0000''

If the user forgets the PIN or the retry counter reaches its limit, the system terminal can beused to enter a new PIN and reset the retry counter after an authentication

Since the system is required to have an intermediate level of security, and system agement should not be too costly, a severely limited key management scheme is appropriate.Neither derived keys nor multiple generations of keys are used in this system The keys onlyneed to be separated by function, which leads to the arrangement shown in Table 15.14 Thefile tree that must be present in the smart card is described in Table 15.15, and the file accessconditions are listed in Table 15.16

man-File EF2, which contains the authorization data for access to rooms and computers, has

a record-oriented structure All records have the same length (linear fixed) Each record has

an entry that indicates which rooms the cardholder is allowed to enter It is also possible todefine security levels, so that it is not necessary to explicitly list each room Access can then

be globally restricted to certain areas

Table 15.14 The keys needed for the ‘access control’ application

Key Used for Function State transition

C 1 MUTUAL Application management: x→ 1

AUTHENTICATE – creating new files

– writing to files– unblocking an application

V 2 MUTUAL Mutual authentication of the x→ 2

AUTHENTICATE terminal and the smart card:

– access authorization– blocking an applicationPIN VERIFY CHV User identification 2→ 3

15.9 Design Examples for Smart Card Applications 893 Table 15.15 The file tree for the ‘access control’ application

File FID Structure Description and contents

MF '3F00' — Smart card root directory

DF — — Directory for the ‘access control’ applicationDE.EF 1 '0001' Transparent Last name, first name, department

DE.EF 2 '0002' Linear fixed Authorization level

DE.EF 3 '0003' Linear fixed Key 1; key 2; PIN

Table 15.16 File access conditions for the ‘access control’ application

Only standard commands provided by commercially available ISO-compliant or compliant operating systems are used for the smart cards This means that nothing has to beprogrammed in the smart cards, which considerably reduces acquisition costs The followingcommands are needed:

of the card for access control can be prohibited by using the INVALIDATE command to blockall EFs If necessary, the application can be reactivated at the administration terminal usingREACTIVATE, following mutual authentication

If the system operator decides to also use the smart cards for canteen billing, a new plication with its own DF and EFs must be generated There are two ways to do this Eitherall employees must bring their cards to the administration terminal, or the necessary files can

ap-be automatically downloaded during access checks The second approach is certainly lessexpensive and more user-friendly, since it does not require any extra administrative effort

Smart card Terminal User

  Reset

THEN continueELSE abort

''Please enter PIN''

VERIFY CHVSELECT FILE (EF 2)READ RECORD

evaluate file contents

IF (permission= yes)THEN actuate door opener Output

''Please enter''

Figure 15.29 Access control command sequence for the ‘access control’ application

The required control of access to computer systems is completely analogous to the processjust described The only difference is that instead of a door release mechanism being activated,

a signal is sent to the computer to tell it to grant access to the user

15.9.3 Testing the genuineness of a terminal

Situation and objectives

There are situations in which it should be possible for a card user to verify the authenticity of

a terminal One example is a terminal in a supermarket, in which the user must enter a PINafter inserting the card A counterfeit terminal could be used to spy out secret PIN codes.8Ifthe card is subsequently stolen by a person who already knows the PIN, the thief could use thecard to make purchases or obtain money from a cash dispenser

In the summer of 1997, a counterfeit cash dispenser at the Marienplatz in Munich was used

in a comparable manner to illicitly collect magnetic-stripe data and associated PIN codes Ifsmart cards are used, good protection against this type of attack can be provided with a suitableapplication design

Requirements

It is necessary to design a component of a smart card application that allows the card user torecognize a counterfeit smart card terminal (but not a manipulated terminal) The user mustnot need any additional technical aids or equipment to check the terminal

8 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 inthe smart card This file can be read by the terminal only after it has successfully authenticateditself with respect to the smart card via a secret key

After this authentication process, the terminal is allowed to read the password from thefile and show it on its display As soon as the card user sees the password and verifies that it

is correct, he or she can assume that the terminal is genuine, since only the user knows thepassword Only after he or she has verified the password will the user enter the PIN that makesthe rest of the transaction possible

The procedure just described is recommended in the DIN specification for German signaturecards, for example, in order to allow card users to determine whether public signature terminalsare genuine.9

An important limitation of the solution must be mentioned This is that it allows a counterfeitterminal to be recognized, but not a manipulated terminal If the terminal software could bemodified without losing the secret key in the process, it would be possible for a manipulatedterminal to correctly authenticate itself with respect to the smart card and then display the pass-word This limitation should be taken into account in any application in which this technique

is used However, this is basically not a critical issue, since a terminal that can be manipulated

to this extent will allow significantly more extensive forms of attack than just spying out PINcodes

The proposed solution, which is presented in the form of specific files and access conditions

in Tables 15.17 and 15.18, is not a complete smart card application Instead, it is a sort of designtemplate that can be merged into any desired application Consequently, the FIDs and statetransitions, as well as the procedure illustrated in Figure 15.30, can be modified as necessary

to use different values or command sequences This example is primarily intended to conveythe basic idea of how the genuineness of a terminal can be tested, rather than to serve as aconcrete application

Table 15.17 Keys needed for testing the genuineness of a terminal

Key Used for Function State transition

key 1 EXTERNAL Authentication of the x→ 1

AUTHENTICATE terminal by the smart cardPIN VERIFY CHV Identification of the user 1→ 2

Table 15.18 File tree and access conditions for testing the genuineness of a

terminal (≥0: always, <0: never)

File FIC Structure Read Write File contents

EF 1 '0001' transparent = 1 = 2 password

EF 2 '0002' linear fixed < 0 < 0 key 1, PIN

9 See also Section 14.4, ‘Digital Signatures’

Smart card Terminal User

  Reset

THEN continueELSE abortEXTERNAL AUTHENTICATE(with key 1)

IF (authentication is successful)THEN continue

ELSE abortSELECT FILE (EF 1)READ BINARY Output the content of

the password file

IF (password correct)THEN terminal isgenuine

ELSE abort

''Please enter PIN''

Figure 15.30 Command sequence for verifying the genuineness of a terminal

the term (set in italics) is explained.

Larger collections of general terms used in informatics can be found in the DIN 44 300standard and 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 the usual mechanisms (usually CHANGECHV), with the value of the 0-PIN not being an allowed value for the new PIN The purpose of

a 0-PIN is to allow the user to unambiguously determine whether the card is still in its originalissued state when he or she receives it or has been illicitly used while underway The term

‘0-PIN’ comes from the fact that the value “0000” is often used for this type of PIN

Smart Card Handbook, Third Edition W Rankl and W Effing

2004 John Wiley & Sons, Ltd ISBN: 0-470-85668-8

1-µµm/0.8-µµm/ technology

In the fabrication of semiconductor chips, the performance of the technology used is ally expressed in terms of the dimension of the smallest possible transistor structure on thesemiconductor material This is usually the width of the gate oxide strip of a transistor Cur-rently, the smallest possible structure widths are approximately 0.25µm and 0.13 µm Naturally,

tradition-it is always possible to make structures on the chip that are larger than the minimum dimension

1K/2K/4K/ /nK-chip

The designation ‘nK-chip’ (where n is a positive integer) is frequently used as a simplified type

designation for a→ microcontroller with a certain size of → EEPROM in kilobytes A

32K-chip is thus a smart card microcontroller with 32 kB of EEPROM Specifying the size of theEEPROM is sufficient for rough comparisons of commonly used smart card microcontrollers

1G (first generation)

Refers to the first generation of mobile telecommunication networks, which have a cellulararchitecture and use analog technology Typical examples of 1G systems are AMPS and theGerman C-Netz

2G (second generation)

Refers to the second generation of mobile telecommunication networks, which have a cellulararchitecture and use digital technology Typical examples of 2G systems are→ GSM and → CDMA.

in turn is a member of the→ IMT-2000 family.

3GPP (Third Generation Partnership Project) [3GPP]

The task of the Third Generation Partnership Project, which was founded by the five standardsinstitutes ANSI T1 (USA), ARIB (Japan), ETSI (Europe), TTA (Korea) and TTC (Japan), is

16.1 Glossary 899

to generate internationally usable technical specifications for third-generation (→ 3G)

mo-bile telecommunications systems based on an enhanced GSM core system (→ GSM) The

participating standards bodies will then translate these specifications into corresponding dards 3GPP was founded in Copenhagen by the leading international standards organizations

stan-in the field of telecommunications The Third Generation Partnership Project 2 (3GPPP2) hassimilar responsibilities, although the latter project focuses on further development of non-GSMsystems (such as CDMA systems) in the direction of the third generation

3GPP2

→ 3GPP

4G (fourth generation)

Refers to the fourth generation of mobile telecommunication networks, which is currently only

in the conceptual stage

8-bit/16-bit/32-bit CPU

An important characteristic with regard to the processing power of a→ microprocessor is the

width of the register for data to be processed in the processing unit It is expressed in terms ofthe number of bits

A2C (administration to customer)

Public administration and end users

A3 (algorithm 3)

Designation for a cryptographic algorithm used in→ GSM for the authentication of the SIM

by the background system using a challenge–response procedure A3 is chosen by the networkoperator and is thus not the same for the entire GSM system

A5 (algorithm 5)

Designation for a cryptographic algorithm used in→ GSM for encrypting data on the air

interface between the mobile station and the base station or background system A5 is thesame for the entire GSM system

A8 (algorithm 8)

Designation for a cryptographic algorithm used in→ GSM for generating session keys (Kc)

used for encrypting speech data on the air interface A8 is chosen by the network operator and

is thus not the same for the entire GSM system

Access conditions (AC)

In connection with the file system of a smart card, a finite number of conditions that must

be satisfied prior to accessing the associated file using one of the various types of accesssupported by the operating system (e.g., read, write, delete) Access conditions are usuallyspecified independently for each type of access

Acquirer

An entity that establishes and manages data links and data exchanges between the operator of

a payment system and individual service providers An acquirer may consolidate individualtransactions that it receives, so that the system operator receives only collective certificates

Administrative data

Data that are used only for managing→ user data and no other particular significance with

respect to an→ application.

AES (Advanced Encryption Standard)

A symmetric→ cryptographic algorithm, originally developed by Joan Daemen and Vincent

Rijmen and published as the Rijndael algorithm Following a public competition and evaluationprocess, the→ NIST selected this algorithm as the successor to the DES in 2000 and published

it as a US standard (FIPS 197) in 2001.1

AFNOR (Association Fran¸caise de Normalisation)

A French standards organization based in Paris

AID (application identifier)

An AID identifies an→ application in a → smart card, as specified in ISO/IEC 7816-5 Part

of the AID may be registered nationally or internationally, in which case it is reserved for the

1 See also Section 4.7.1, ‘Symmetric cryptographic algorithms’

16.1 Glossary 901

registered application and is unique in the entire world An AID consists of two data elements:

a registered identifier (RID) and a proprietary identifier (PIX).2

AMPS (Advanced Mobile Phone System)

A cellular mobile telephone standard, predominantly used in the USA, Latin America, Australiaand parts of Asia It employs analog technology and operates in the 800-MHz band AMPSmobile telephones do not have→ smart cards and are often successfully attacked, in part for

this reason The upgraded version of AMPS is D-AMPS, a digital system that also operates inthe 800-MHz band

ANSI (American National Standards Institute) [ANSI]

An American standards organization based in New York

Anticollision method

A method that permits access to multiple contactless cards without interference

APDU (application protocol data unit)

A software data container used to package data for an→ application for exchange between

a→ smart card and a → terminal The APDU is converted into a transmission protocol

data unit (TPDU) by the transmission protocol and then sent by the smart card or terminal

2 See also Section 5.6.1, ‘File types’

via the serial interface APDUs can be classified into→ command APDUs and → response APDUs.3

API (application programming interface)

A software interface, specified in detail, that provides access to specific functions of a program

Application

All of the data, files,→ commands, processes, states, mechanisms, algorithms and programs in

a→ smart card that allow it to be used in a particular system An application and its associated

data are usually located in a dedicated DF directly below the MF Such an application isoften called an ‘oncard application’ The opposite to this is an ‘offcard application’, whichencompasses all of the programs and data not present in the smart card that are necessary forusing the oncard application in the smart card

Application operator

An entity that operates an→ application using → smart cards The application operator is

usually the same as the application provider

Applet

A program written in the Java programming language and executed by the virtual machine of

a computer For reasons of security, the functionality of an applet is restricted to a previouslydefined program environment In the realm of→ smart cards, applets are sometimes called

‘cardlets’ An applet usually corresponds to a smart card→ application.

ASN.1 (Abstract Syntax Notation 1)

A description language (syntax and grammar) for data that allows data and data types to beunambiguously defined and represented independent of the type of computer system used The

3 See also Section 6.5, ‘Message Structure: APDUs’

A program that translates assembly-language programs into machine language, which can

be executed by a processor After the assembly process, it is usually necessary to link theresulting code using a linker program ‘Assembler’ is also often used as a short form for

‘assembly-language program code’

Asymmetric cryptographic algorithm

→cryptographic algorithm

Asynchronous data transmission

Data transmission in which the data are transmitted independent of any prescribed timingreference (→ synchronous data transmission)

Atomic operation

One or more operations in a program that are executed either entirely or not at all In→ smart cards, atomic operations are frequently used in connection with EEPROM write routines, in

order to ensure that the data content is consistent at all times.5

ATR (answer to reset)

A sequence of bytes sent by a→ smart card in response to a (hardware) reset The ATR

includes various parameters relating to the transmission protocol for the smart card.6

Attribute

In the sense of → object-oriented programming, a data container holding an → object

(in the procedural sense, the variables) Attribute values can be read or modified using→

methods.

4 See also Section 4.1, ‘Structuring Data’

5 See also Section 5.10, ‘Atomic Operations’

6 See also Section 6.2, ‘Answer to Reset (ATR)’

The process of verifying the genuineness of an entity (such as a smart card) using a tographic procedure Put simply, authentication amounts to using a prescribed procedure todetermine whether someone is actually the person he or she claims to be

Auto-eject reader

A terminal that can automatically eject an inserted card in response to an electrical or ical signal

mechan-B2A (business to administration)

Designates the handling of→ e-commerce business between enterprises and public

Designates the bearer service used to transport data to a terminal device For example, SMS is

a possible bearer for WAP

Bellcore attack

→differential fault analysis

BER (Basic Encoding Rules)

The BER, which are defined in→ ASN.1, allow data to be coded in the form of data objects.

A BER-coded data object has a tag, a length and a value (the actual data component), andoptionally an end marker, and is thus also referred to as TLV-coded data The BER format alsopermits chained data objects The Distinguished Encoding Rules (DER), which are a subset

of the BER, indicate among other things how the length parameter of the data object is to becoded (1, 2 or 3 bytes).7

Big-endian

→endianness

Binary-compatible program code

A program that can be executed directly by a → microprocessor without using auxiliary

programs or the like (→ program code)

7 See also Section 4.1, ‘Structuring Data’

A wireless network technology intended to be used for short-range communications (<100 m)

in the 2.4 GHz band, with a maximum gross data transmission rate of around 1 Mbit/s Ericsson,

as the initiator of this technology, chose the name in memory of the Danish king Harald II, wholived approximately 1000 years ago and was nicknamed ‘Bluetooth’ His major achievementwas merging many separate regions into a unified kingdom

Bond-out chip

A microcontroller mounted in a multi-pin ceramic package providing free access to all ofthe memory busses internal to the chip, thus allowing the commonly used mask-programmed

→ROM to be replaced by memory external to the chip A bond-out chip is used to allow

software to be tested in the target hardware without using a→ ROM mask.

Boot loader

A small, simple program whose only purpose is to load other, larger programs into memory,for example via a serial interface, and run them from memory (→ loader) A boot loader istypically used to load the actual program code into a new chip or a new piece of electronicequipment In many cases, the boot loading process can be performed only once

BPSK (binary phase shift keying)

180-degree phase shift keying, yielding two phase states

16.1 Glossary 907

software of the mobile telephone (e.g., WAP browsers) The functionality of browsers can beextended using downloadable software components called browser plug-ins

Brute-force attack

An attack on a cryptographic system based on computing all possible values of a key

BSI (Bundesamt for Sicherheit in der Informationstechnik) [BSI]

The German Bundesamt for Sicherheit in der Informationstechnik (BSI) was founded in 1991

as the successor to the Zentralstelle f¨ur das Chiffrierwissen The functions of the BSI include

investigating the security risks of IT applications, testing and evaluating the security of ITsystems, formally approving IT systems for government agencies and assisting criminal in-vestigation agencies and agencies charged with the protection of the German constitution Italso advises manufacturers, operators and users with regard to IT security, and in this regard

it often specifies the general conditions for using cryptography in Germany

Buffering

A typical type of attack on magnetic-stripe cards involving first reading and storing (buffering)the data on the magnetic stripe After the data have been modified using a terminal (e.g.,changing the state of the retry counter), the original data are written back to the magneticstripe

Bug fix

In software development, supplementary→program code used to remedy a known error (bug).

In contrast to a→work-around, a bug fix eliminates the actual error.

Burst

→signal burst

Bytecode

This term has several different meanings and can only be correctly interpreted in the context

in which it is used One widely used meaning is related to the Java system, in which bytecode

is the name given to the intermediate code produced (compiled) from the source code by aJava compiler This bytecode is standardized by the Sun Corporation and is interpreted bythe Java virtual machine The term ‘bytecode’ is also used in the context of microbrowsers(→browser), where it is understood to mean the translated code produced from a hypertextdocument by the bytecode converter The result of this translation is the bytecode, which isthen interpreted by the microbrowser

CAD (card acceptance device)

In the realm of electronic payment systems, the designation CAD is frequently used to refer

to a smart card terminal, in place of the ISO abbreviation→ IFD (interface device).

CAMEL (Customized Applications for Mobile Enhanced Logic)

Supplementary possible feature of→GSM for supporting the functionality of intelligent

net-works (IN) With CAMEL, for example, it is possible to modify a dialing number during callsetup on the network This allows applications such as international→roaming using prepaid

cards and internationally available standard service numbers to be implemented in a simplemanner

CAP file (card application file)

A data format used to exchange data between the Java Offcard Virtual Machine and the JavaOncard Virtual Machine

Card

General term used to refer to a thin rectangular piece of material with rounded corners whosephysical dimensions comply with an international standard A card can have various cardcomponents, including a semiconductor chip (→chip card, →smart card)

Card accepter

An entity with which cards can be used for a particular type of transaction (such as payment)

A typical example is a merchant who accepts credit cards for making payments

A supplementary functional unit of a→card, such as a →signature panel, →embossing, a

→magnetic stripe, a chip (→memory card, →microprocessor card) or a keypad (→system

on card).

16.1 Glossary 909

Card issuer

An entity responsible for issuing cards In the case of mono-application cards, the card issuer

is usually also the application provider, but this is not necessarily the case

Card manufacturer

An entity that produces card bodies in which it embeds modules

Card Modeling Language (CML)

An abstract, operating-system independent description language for defining smart card

→applications.

Card owner

A natural or legal person having legal control over a card who can do whatever he wishes withthe card In the case of a credit or debit card, the bank issuing the card is often the card owner,and the customer who uses the card is only the→cardholder.

Card reader

A device having a relatively simple electrical and mechanical construction used to accept

→ smart cards and make electrical contact with them Unlike a terminal, a card reader does

not have a display or a keypad Despite the name, a card reader can usually also be used towrite data to a card

Cardholder verification method (CVM)

A method for the→identification of persons This usually consists of PIN testing, but biometric

user identification may be used in more sophisticated systems