Cases analysed General interest

19

Planning an e-passport system

Defining requirements engineering at a national level
by Dr Michael Jahnich
to be met. As a consequence, they set their sights on ensuring that the e-passport is ICAO compliant. Because the ICAO requirements primarily relate to the e-passport rather than the underlying system, meeting them is not necessarily enough, even for e-passports. There are many national requirements that also have to be considered. These are based on existing infrastructures, processes, policies, legislation, culture and history, to name but a few. Given their (inter)national visibility, e-passport projects tend to be considered more important than other IT projects. In Europe, the public discussion has very much focused on three issues: data protection concerns, security and price. It should be borne in mind that in less developed countries the e-passport is also a means of national identification and national prestige. Many countries have made significant investments in existing systems (eg, civil registers, fingerprint identification systems, blacklist databases, and the like), which have since acquired the status of legacy systems. The introduction of an e-passport requires registration offices to be equipped with biometric equipment. It also involves new workflows and new border crossing processes, which must be integrated with the existing IT mainframes and national databases. At a strategic level, the e-passport must form an integral part of a superior e-government strategy. Needless to say, existing processes and systems must be considered when establishing an e-passport project. Hopefully, these are well-documented and based on modern technology. The next step is to manage the supply of new technology, including the logistics. To give an example, electronic components like the passport chip must be covered by a 5-10 year warranty. Should a passport fail, it is also important to know the type of chip and the software version it uses. Likewise, the issuance of microcontrollers with systematic or even worse, stochastic failures should be avoided, particularly if one considers that passports housing such controllers are valid for several years, and cannot be updated. As modern microcontrollers have a rather short product life-cycle, passport production and personalization must be flexible, allowing diverse and proprietary microprocessors (and alternative sources) to be accommodated.

The issuance of e-passports presents many issuing authorities with a considerable challenge, particularly those of less developed countries. While most countries have issued travel documents for decades, the use of contactless microcontrollers and biometrics in travel documents may necessitate fundamental changes to the underlying issuance systems and processes. Unlike many other IT projects, the deployment of an e-passport system attracts considerable public attention. The risk of failure highlights the need for sound project planning at all project stages and levels. This article reviews several important issues to consider when planning an e-passport project. It focuses on the underlying system and discusses aspects that lie beyond global interoperability.

In todays world, the e-passport should be viewed as a token that forms part of an open-ended and heterogeneous IT system. Many independent industrial companies and government organizations contribute to this IT system (by, for example, providing components). While border control systems must be capable of reading and authenticating foreign passports, individual countries must be able to exchange certificates with others. Before the e-passport can be delivered to its holder, the biometric enrolment systems used by the national passport offices must be integrated with the civil registers and passport personalization offices. As such, the introduction of biometrics has changed the work flow considerably. Indeed, most requirements of an e-passport project are not related to the e-passport itself, but to the system. Interoperability appears to be a peripheral issue. As explained below, the deployment of an e-passport system starts with planning.

Dr Michael Jahnich is technical director and chief requirements engineer at HJP Consulting GmbH. With more than 11 years of experience in smart card technology, he has advised (and partnered) several passport manufacturers and issuing authorities in Europe and Africa on the technical aspects of their e-passport programmes. Michael co-edited the latest ICAO test standards for e-passports. He is also a member of the DIN committee for the standardisation of machine readable travel documents and contactless technologies.

Experience gained with e-passport projects

We have frequently found that issuing authorities refer to DOC 9303 as the only set of requirements that need

Keesing Journal of Documents & Identity, issue 24, 2007

20

Cases analysed
Figure 1 The five critical stages to the success of an epassport project.

An e-passport project may also be dogged by other, non-technical issues. The planning team may, for example, be understaffed. Experience has shown that there appears to be an imbalance between the resources allocated to the e-passport project team on the one hand and the system integrator team on the other. Situations can and do arise when the entire project is manned by a handful of people, even as its scope is broadened. In practice, the need to ensure that project staff are sourced from a range of disciplines can cause the team to be dominated by contractors. In such instances, decisions that directly impact passport functionality may be accepted simply because there is insufficient proprietary expertise.

Guidelines for managing an e-ID project

There are many well-defined methodologies for managing IT projects, and this article has no intention of adding to the existing supply. However, as indicated above, the management of projects involving epassports and e-ID cards calls for specific skills. With this in mind, time spent planning an e-passport project is time well spent, not least because it reduces the risk of failure. From the perspective of an issuing authority, the following five stages are critical to the success of the e-passport project (see figure 1): 1. Analysis of status 2. Definition of requirements 3. Gaining approval 4. Ensuring operations 5. Running the project This article will cover the first three stages, which primarily focus on the technical planning aspects. As shown in figure 2, most e-passport projects follow standard project methodologies that can be subdivided into several phases. The first stage, planning, starts as soon as a strategic decision has been made at a political level (this process is not discussed here). The planning phase involves analysing the current status and formulating the requirements that will form the basis of the tender. Once the planning phase has been completed, the project will be put out to tender this is known as the procurement phase. All proposals will be evaluated from a technical and commercial perspective. During the production phase, which is initiated once the main contractor has been decided, all project deliverables are produced by the various suppliers. These deliverables are subsequently accepted or rejected during the approval phase. Clearly a project can be much more complicated than described here, and include several sub-projects and other dependencies. However, as far as issuing authorities are concerned, these stages are common to e-passport projects.
Keesing Journal of Documents & Identity, issue 24, 2007

In our project model, we have introduced three different roles, including corresponding responsibilities. The model helps to make distinguish between suppliers and customers.

Requirements at a national level

The first step of the planning phase is to analyse the existing e-passport systems and processes. The analysis includes a review of the people currently operating the systems, who cannot simply be forgotten when a new e-passport is introduced. Existing processes are often based on prevailing laws and data protection regulations. The status analysis should therefore cover at least the following aspects: the current stakeholders, the current employees (including their skills and level of education), the technology, the existing infrastructure, the databases, security, organisational and logistics-related issues, jurisdiction, and culture. Last but not least, existing passports also have to be considered. While this may appear trivial, it could take some time to establish the different types of passport in circulation (including details of any exceptions, dependencies and issuers). In itself, this is not a straightforward task. The information thus obtained is used as a basis for the new e-passport system. Within this context, we have found RM-ODP the reference model for open distributed processing according to ISO/IEC 10746 to be a very useful tool, also at the requirements level (see figure 3). Collecting system requirements is not easy. It is a task that should be performed by the issuing authority rather than supplier, as is often the case. This is because the supplier frequently lacks the necessary expertise. Requirements engineering is responsible for collecting a complete, unambiguous, consistent and traceable set of requirements (please refer to the international software requirement specification standard IEEE 830 for a definition of good requirements). These should form the basis for

Cases analysed

21

all further procurement activities, also on a contractual basis. They are additionally used to test and approve the overall system (as implemented). In order to derive system requirements, modelling techniques can be applied using the five different RM-ODP perspectives. These are described below. The enterprise perspective The purpose and scope of the e-passport project should be defined first. It is of the utmost importance to define the boundaries of the project (ie, the deliverables that are included or excluded). This is where the problem starts. The integration of a microprocessor in a travel document may entice authorities to include health cards and other social security applications. In turn, this would require them to set up a common backend system that is capable of handling these different cards and applications. Although a modern card and application management system is able to accommodate these requirements, it makes the overall system more complicated. Here too, thorough planning is essential. The enterprise perspective also covers other, non-technical requirements such as policies, regulations and service levels. The computational perspective The next important step is to conduct an initial logical analysis of the e-passport system, which must take account of the existing arrangement. This analysis is often reflected in computational objects (enrolment, personalization, card management, issuance and manufacturing) as well as the token itself. The analysis can, of course, be much more detailed. Next, the functional and non-functional requirements of these computational objects must be defined, requiring
Figure 2 Most e-passport projects follow standard project methodologies that can be subdivided into several phases.

the project stakeholders to come up with a precise definition of their requirements. The best way to define these requirements is to model use cases (using UML) which can subsequently be used to extract system requirements (see figure 4). Use cases can often be defined in more detail using activity diagrams, which are ideal for describing work flows or processes. Special attention should be paid to the definition of use cases during enrolment and inspection, at which times the user/bearer interacts with the system. Even though there are standard products in the markets, these must be completely adapted to reflect national policies and culture. The information perspective The information perspective encompasses data and information that is in one way or another generated and stored by the system. It defines information semantics and information processing. Figure 5 shows a data model used for enrolment. An e-passport system typically processes more information than is actually stored on the biographical data page or the electronic chip. Moreover, depending on the architecture of the new system and the existing infrastructure, information is stored in different locations. While passport-related information is invariably stored and processed in a card management system, other personal data may be kept in fingerprint identification systems, civil registers, or other centralized as well as local databases. The engineering perspective The engineering perspective covers networks, infrastructures and the distribution of components. Although it is primarily used in the design phase, it

Keesing Journal of Documents & Identity, issue 24, 2007

22

Cases analysed
Figure 3 RM-ODP, the reference model for open distributed processing, according to ISO/IEC 10746.

is worth spending some time on this perspective, also because it allows additional requirements to be defined. The stakeholders occasionally insist on central or local personalization on account of security concerns (or simply because documents have traditionally been personalised at central, state-owned office). This requirement clearly has a significant impact on the solution that the system integrator is expected to deliver. Other engineering requirements may arise from (i) the number and distribution of enrolment systems at registration offices and (ii) the distribution of border control systems. The requirements defined from an engineering perspective should give the supplier a

certain degree of freedom to develop a system solution that fits with his own product strategy. The technology perspective The aim of the technology perspective is to define the actual implementation requirements. Here, the focus is on technical standards, conformance testing, hardware, software and architectural requirements. Again, the existing system and infrastructure may be used to define technology requirements. Think, for example, of integrating the solution with an existing card management system based on the Global Platform standard. The e-passport itself must meet a diversity of
Figure 4 The functional and nonfunctional requirements of computational objects can be best defined by modelling use cases.

Keesing Journal of Documents & Identity, issue 24, 2007

Cases analysed ICAO

Figure 5 Data model for enrolment.

23

technology requirements on the basis of DOC 9303 (eg, compliance with the ISO 14443 contactless interface standard). As a rule, system flexibility will increase in line with the requirement for and introduction of open standards for components. In turn, this will facilitate non-functional requirements such as reusability, extendibility and scalability. However, insisting on the use of specific system architectures, such as clientserver solutions, is not advisable as it may discourage system integrators from implementing their proven technology solutions. Gaining final approval The system integrator will develop the system architecture and component specifications in accordance with the project owners domestic requirements (see figure 2). Compliance with these requirements will subsequently need to be tested. Assuming all internal tests are successfully concluded, the contractor will ask the project owner to sign a final acceptance notice, whereupon project ownership is often transferred to the project owner (the issuing authority). This entails an element of risk, not least because the project owner may not have the expertise needed to verify that the solution meets the requirements. We therefore recommend that approval is sought rather than granted. This transfers to onus for proving compliance to the supplier. To this end, a supplier may, for example, provide a test certificate based on an internationally accepted test programme. The German Federal Office for Information Security (BSI) issues a complete set of e-passport certificates for security (Common Criteria) as well as functional conformance (ICAO test standards). As no international test is available for the system itself, we

recommend having the system evaluated or certified by an independent third party. Alternatively, tests can be conducted by the contractor and audited either by an independent third party or by the project owner. Whichever approach is chosen, it is imperative that all requirements are at least tested once (using an appropriate test). It makes sense to establish an acceptance test plan at the project outset at the same time as the requirements are collected.

Conclusion
The likelihood of an e-passport or other e-ID project being successfully implemented increases in line with the amount of time and resources allocated to planning. The advantages for the issuing authorities are self-evident. The project team will, for example, obtain a comprehensive overview of the system at the outset, while simultaneously gaining important know-how. This avoids far-reaching change requests being issued at a later stage, which could delay the project or result in a budget overrun. Good planning also helps the contractor by providing a clear overview of the customer requirements (making it easier to submit an accurate proposal). To reiterate, most demands made of an e-passport system are not based on ICAO requirements but on national requirements. The global interoperability of e-passports remains an important objective. While highly visible, it is an objective that cannot be achieved without the support of an excellent IT system. Which calls for planning.

Keesing Journal of Documents & Identity, issue 24, 2007