European Commission - CIRCABC · European Commission ... a project has been launched to study technical, feasibility and business impacts ... validation, and printing steps,

European Commission Directorate General for Health and Consumers Unit A4, Office B232 01/115

Technical, feasibility and impact study for the introduction of electronic certification in the TRACES system

Study Report (awarded through tender n° SANCO/2010/A4/R10-029)

Submitted by Dictao

Final version – 02/11/2011

TRACES

http://www.google.fr/imgres?imgurl=http://www4.ac-lille.fr/~dinahderycke/IMG/jpg/commission-europeenne.jpg&imgrefurl=http://www4.ac-lille.fr/~dinahderycke/spip.php?rubrique61&usg=__yXASHYuC2ocRhHZhRL3Mei6sPjA=&h=301&w=443&sz=15&hl=fr&start=5&um=1&itbs=1&tbnid=oAkqPsHZl-XdCM:&tbnh=86&tbnw=127&prev=/images?q=commission+europ%C3%A9enne&um=1&hl=fr&sa=

Technical, feasibility and impact study for the introduction of electronic certification in the TRACES system Study Report – DG SANCO

Final version – November 2011 2/144

TRACES



TABLE OF CONTENTS

0. INTRODUCTION ........................................................................................................................................... 9

1. PHASE 1: BUSINESS CONTEXT ANALYSIS ................................................................................................10

1.1 Business processes analysis .................................................................................................................10

1.1.1 Proposed approach ............................................................................................................................10

1.1.2 TRACES stakeholders and users......................................................................................................11

1.1.3 TRACES business processes ...........................................................................................................13

1.2 Feedback on visits and interviews .........................................................................................................20

1.2.1 Proposed approach ............................................................................................................................20

1.2.2 Interview guide ...................................................................................................................................21

1.2.3 Interview planning ..............................................................................................................................21

1.2.4 Interview analysis ...............................................................................................................................23

1.3 Conclusion ...............................................................................................................................................25

1.3.1 Main challenges .................................................................................................................................25

1.3.2 Proposed approach for deployment strategy....................................................................................25

2. PHASE 2: TECHNOLOGICAL STUDY ..........................................................................................................27

2.1 Preamble .................................................................................................................................................27

2.2 Digital Signature ......................................................................................................................................28

2.2.1 Digital signature basics ......................................................................................................................28

2.2.2 Digital signature methods ..................................................................................................................30

2.3 eSignature vendors study .......................................................................................................................32

2.3.1 Market analysis...................................................................................................................................32

2.3.2 Selection criteria .................................................................................................................................36

2.3.3 Benchmarking of selected companies ..............................................................................................38

2.4 eSignature Architectures ........................................................................................................................41

2.4.1 Proposition of architectures ...............................................................................................................41

2.4.2 Deployment issues .............................................................................................................................43

2.5 eDocument technologies study ..............................................................................................................44

2.5.1 Overview of technological trends ......................................................................................................44

2.5.2 Paperless technologies .....................................................................................................................44

2.5.3 Automatic identification and data capture technologies...................................................................44

2.5.4 Technological benchmarking .............................................................................................................46

2.6 Conclusion ...............................................................................................................................................46

3. PHASE 3: DEPLOYMENT STRATEGY .........................................................................................................48

3.1 Overview..................................................................................................................................................48

3.1.1 Logical architecture ............................................................................................................................48

3.1.2 Sequence examples...........................................................................................................................49

TRACES



3.2 End-user point of view ............................................................................................................................54

3.2.1 Prerequisites for digital certificate .....................................................................................................54

3.2.2 Prerequisites for digital signature ......................................................................................................56

3.2.3 Prerequisites for paperless use .........................................................................................................58

3.2.4 Conclusion ..........................................................................................................................................58

3.3 EC point of view ......................................................................................................................................59

3.3.1 Preamble.............................................................................................................................................59

3.3.2 Main trust functions ............................................................................................................................59

3.3.3 Trust platform challenges ..................................................................................................................62

3.4 Project plan .............................................................................................................................................63

3.4.1 Project specifications .........................................................................................................................63

3.4.2 Integration ...........................................................................................................................................64

3.4.3 Deployment.........................................................................................................................................66

3.5 Conclusion ...............................................................................................................................................66

4. PHASE 4: COSTS / BENEFITS ANALYSIS ...................................................................................................67

4.1 Challenges and issues ...........................................................................................................................67

4.1.1 Analysis criteria ..................................................................................................................................67

4.1.2 Legal aspect .......................................................................................................................................67

4.2 Analysis ...................................................................................................................................................68

4.2.1 Overall impact .....................................................................................................................................68

4.2.2 Achieved security level ......................................................................................................................70

4.2.3 Technology maturity and acceptability ..............................................................................................72

4.2.4 Deployment approach ........................................................................................................................74

4.2.5 Cost analysis ......................................................................................................................................75

4.3 Return on investment..............................................................................................................................76

4.3.1 ROI factors ..........................................................................................................................................77

4.3.2 ROI areas............................................................................................................................................77

5. CONCLUSION ............................................................................................................................................80

6. APPENDIXES .............................................................................................................................................82

6.1 Appendix 1 – Interview guide .................................................................................................................82

6.2 Appendix 2 – Interview minutes .............................................................................................................83

6.2.1 Belgium ...............................................................................................................................................84

6.2.2 France .................................................................................................................................................93

6.2.3 Germany .......................................................................................................................................... 114

6.2.4 Italy ................................................................................................................................................... 121

6.2.5 Slovenia ........................................................................................................................................... 134

6.3 Appendix 3 – Certificate authorities .................................................................................................... 139

6.4 Appendix 4 – Signature component : an example ............................................................................. 140

6.5 Appendix 5 – Trust platform : an example.......................................................................................... 141

6.5.1 DTP functionalities .......................................................................................................................... 141

TRACES



6.5.2 Technical characteristics of DTP .................................................................................................... 143

6.5.3 Integration of DTP in an IS ............................................................................................................. 143

6.5.4 DTP technical architecture.............................................................................................................. 143

TRACES



TRACES



ABSTRACT

DG SANCO (Health and Consumer Protection Directorate General of the European Commission) has created and is maintaining the TRACES (TRAde Control and Expert System) system. TRACES is a trans-European web-based application which allows to notify, certify and monitor imports, exports and intra-European trade in animals and products of animal origin. It manages the veterinary certificates that are legally required for transporting animals and products of animal origin.

Veterinary certificates entered into the TRACES system are currently represented as files that need to be printed by the various actors involved, belonging either to the public or private sectors. Thus, TRACES certificates can be defined as paper certificates stored, in a structured manner, in a central database and accessible via a web application.

The EU Animal Health Strategy for 2007 - 2013 (EUAHS) foresees TRACES as one of its pillars, thanks to its ability to act as a single portal for all veterinary matters. One of the foreseen actions for 2007 – 2013 is to develop electronic certification to replace paper certification for movements and imports of live animals and products of animal origin.

eCertification is a dematerialisation project : its final objective is to replace paper but it has to be reached thanks to an appropriate deployment strategy allowing to keep the same level of security and trust towards the TRACES system.

If paperless processes adoption depends on changes in the usage patterns and technological evolutions, first step of dematerialisation only involves electronic document validation and use. It can be easily reached thanks to digital signature.

This study focuses on the most appropriate way to deploy digital signature within the TRACES system, as it involves more than a technical solution. Business needs and user habits have been taken into account, as well as regulatory framework, technological maturity and Europe Digital Agenda conformity.

The study proposes a logical and technical solution that fits identified constraints. It then declines a deployment strategy for both DG SANCO and TRACES users and stakeholders.

TRACES



TRACES



0. INTRODUCTION

DG SANCO (Health and Consumer Protection Directorate General of the European Commission) has created and is maintaining the TRACES (TRAde Control and Expert System) system. TRACES is a trans-European web-based application which allows to notify, certify and monitor imports, exports and intra-European trade in animals and products of animal origin. It manages the veterinary certificates that are legally required for transporting animals and products of animal origin.

Veterinary certificates entered into the TRACES system are currently represented as files that need to be printed by the various actors involved, belonging either to the public or private sectors. Thus, TRACES certificates can be defined as paper certificates stored, in a structured manner, in a central database and accessible via a web application.

The TRACES system is considered a critical system, has a large and expanding user base, is available on a 24/7 basis, and is used by private as well as public actors in all the EU Member States, as well as in an increasing number of non-EU countries.

The EU Animal Health Strategy for 2007 - 2013 (EUAHS) foresees TRACES as one of its pillars, thanks to its ability to act as a single portal for all veterinary matters. One of the foreseen actions for 2007 - 2013 is expressed as follows.

"Electronic certification to replace paper certification for movements and imports of live animals and products of animal origin"

In this context, a project has been launched to study technical, feasibility and business impacts of electronic certification.

This document summarizes the research report concluding this project, and synthesizes the factors learnt and analysed during the completion of this study. The objective was to find a pertinent and adapted solution to the various constraints of the TRACES application ecosystem. The study integrates technical, ergonomic, functional and financial criteria, in the hopes of creating a value-added solution.

Note:

Throughout this document, the electronic certification represents the project to replace paper certificates with electronic documents. The notion of the digital certificate represents the technical purpose (certificate in the standard X509 format), which is necessary for cryptographic and security operations, like, for example, the digital signature.

TRACES



1. PHASE 1: BUSINESS CONTEXT ANALYSIS

The objective of the initial phase of the study was to analyse the daily usage of TRACES by different user-groups, and to implement the system throughout the entire business process.

This initial first step is necessary in order to master the system and acquire a thorough comprehension of its functionalities. Furthermore, this step allowed us to gain a clear understanding of the main and sub processes, which would be impacted by the introduction of electronic certification.

This recognition of usage contexts and user constraints also allowed for the definition of several requirements that the technical solutions must respect, like for instance, a constraint related to system usage areas or distinctive features of member states.

This first chapter is organized as follows:

The description of business processes supported by the TRACES application, highlighting the signature, validation, and printing steps,

The assessment of meetings and interviews with diverse system users,

The analysis of the principal challenges facing electronic certification.

1.1 Business processes analysis

1.1.1 Proposed approach

The approach chosen to conduct this business context analysis was organized in two phases in order to create an exhaustive and realistic list of TRACES system usage.

The first step consisted of a comprehensive study of TRACES and its ecosystem. Based on documentary analysis, this step permitted a familiarization with the legal and regulatory frameworks in order to understand the obligations of various actors implicated in the TRACES ecosystem. These different elements were then presented according to all of the system functionalities offered to users.

This first portion of analysis focused on the ‘abstract’ life cycle of the different documents generated by the system. The results of this analysis answered questions such as:

What is the life cycle of the different certificates (Intra, Import, Common Veterinary Entry document (CVED)?

What signatures are necessary?

Who are the designated signers?

The second step was carried out at a ‘local’ level, for example, at the scale of a member state. This step is based on a collection of interviews and field visits, with the objective of comparing the abstract vision established in the previous step with the everyday practices of veterinarians and economic operators (EO).

This second phase was essential to acquiring a concrete idea of the system usage. During the introduction of dematerialization, which almost always causes business process modifications, it is imperative to have a solid vision of the daily activities of users, especially concerning questions such as:

TRACES



How are certificates used?

Who signs and prints the certificates?

Are there any daily practices that respond to local habits, rather than regulatory obligations in general?

In addition to discovering and understanding the profession of TRACES users, the objectives of this analysis were the following:

Identify all actors concerned with the business processes carried out by TRACES,

Understand the signature and signature validation steps,

Analyse the printing and archiving practices.

1.1.2 TRACES stakeholders and users

The veterinary and health certification process involves a diverse group of actors, from the economic operators to veterinarians and officers of the relevant agencies. It must be noted that not every party involved in the process is a TRACES system user. In addition, certain groups such as customs officers or roadside check officials (the police, for instance) can be in charge of requesting and inspecting a certificate, but they are very rarely considered to be application users.

The census of the different users and stakeholders of the business process is therefore necessary in order to define an electronic certification solution covering all possible usage cases, as well as the entire life cycle of various documents. Should the electronic version of the document prevail, the official in charge of an inspection must be able to connect to the system in order to validate a document, even if only a paper copy is received.

The various actors revolving around the TRACES system are thus either users or unconnected stakeholders, as is illustrated in the following image.

The top half of the diagram represents the actors associated with administrative and / or inspection organisations, while the bottom part illustrates the economic operators, and therefore the groups commercially interested in the exchanged goods.

The central circle includes the system users, while the outer layer indicates the groups that are not subscribed to the system.

TRACES



Figure 1 – TRACES: users and stakeholders

The different actors and users are explained in detail in the following table, which provides a short description of the populations, as well as a list of the main actions completed for and with the certificates.

Name Description Actions

CONSIGNOR Economic operator sending the shipment

Produces, signs first page of certificate documents, and presents it to administration (BIP or LVU)

CONSIGNEE Economic operator to whom the shipment is to be delivered

Receives and checks the certificate document

TRANSITAIR A specific kind of consignor : an economic operator dedicated to the organisation of shipments for individuals or other companies, that may also act as a carrier

Produces, signs first page of certificate documents and presents it to BIP; also interacts with Customs services

BIP Veterinary services at the origin of the shipment, located at a point of entry within the EU

Signs the second page of the certificate document after performing controls; may connect to local systems (for billing, customs, e.g.)

LVU 1 Veterinary services at the origin of the shipment

Signs the second page of the certificate document after performing controls; may connect to local systems (for billing, e.g.)

LVU 2 Veterinary services on transport of the shipment

Check the certificate document, and possibly perform controls

LVU 3 Veterinary services at the destination of the shipment

Check the certificate documents, and possibly perform controls

CUSTOMS Public service in charge of customs clearance

No direct action with TRACES, but may require certificates

TRACES USERS

TRANSITAIRCONSIGNOR

BIP

CUSTOMS

LVU 1

CONSIGNEE

LVU 2

GLOBAL TRACES

STAKEHOLDERS

Central

Administration

LVU 3

POLICE

TRACES



Central Administration

Official organization in charge of the management of veterinary services, food and public safety

No direct action, connects to TRACES and to DataWareHouse for statistics and analysis (May have to create certificates in exceptional cases)

Banks & Ports / airports authorities

Organisations in charge of checking economic liability of EO involved in a shipment (in the case they may be charged for a control or the destruction of the goods)

Can sometimes retrieve information regarding a EO or a shipment in order to perform checks

Police authority Need to check TRACES certificates as part of roadside controls of animal transports.

This terminology is used hereafter to describe the processes carried out by the system.

1.1.3 TRACES business processes

Among the main functionalities offered by the TRACES system (certification, notification, decision support and inspection tracking), only the functionalities linked to certification are accounted for in this study.

Indeed, the business process studies are the four processes linked to the certification, corresponding to the four different types of certificates that can be generated by the system:

INTRA certificate,

A health certificate necessary in the framework of exchanges within communities (exchanges of animals, semen, embryos, and certain animal products from one EU, EFTA, or EEA country or another EU, EFTA, or EEA country),

CVED certificate,

Common Veterinary Entry Document, necessary to allow or refuse the free circulation of goods or animals on the European market,

IMPORT certificate,

Veterinary certificate necessary for the exchange of animals or products of animal origin from a non-EU country to an EU country,

EXPORT certificate,

Veterinary certificate necessary for the exchange of animals or products of animal origin from an EU country to a non-EU country,

CED certificate (Common Entry Document)

A new certificate designed for vegetable products and vegetables certification. Not included in this study as it has been implemented just at the end.

For each of these certificates, the following information is provided:

The workflow describing each step of the document life cycle,

TRACES



Whether the operation was completed with the TRACES system or not,

The various steps of signing, printing and archiving,

Some regulatory and practical comments, observed in particular during field visits.

TRACES



1.1.3.1 The INTRA Certificate

This certificate applies to movements within the European Union, primarily of live animals but in principle also products of animal origin, and does not involve economic operators such as forwarding agents. One particularity to consider for the electronic signature is the location of the certificate generation. According to the country and the organization model, the consignor might need to travel to the local veterinary unit (LVU), or the veterinarian (LVU1) might need to travel to the consignor (in order to verify the condition of the animals prior to departure).

This could involve the use of a computer belonging to actor A by actor B for a signature operation, for example. This configuration may need to be considered when accounting for security and deployment constraints of the solution.

CONSIGNOR LVU 1

“Origin” LVU 2

“On transport” LVU 3

“At destination” CONSIGNEE

Workflow Prepare part I of

certificate Complete with part II to validate or reject certificate

Check certificate along the route (by filling in part III)

Check certificate at destination (by filling in part III)

Get certificate with consignment

Use of TRACES

As often as possible As often as possible Never Rarely Rarely

Signature Sign part I Check part I Sign part II

Check part I & II Sign part III


Check part I - III

Print Yes Yes Check printed document Check printed document Obtain printed document Archive Store for 3 years None None May store

Law C Commission Regulation (EC) No 599/2004 of March 30, 2004 Comments FRANCE : new veterinary model (with “certifier veterinary”) would allow certification (finalisation of part II) at the Consignor place

and could reduce printed versions

TRACES



GERMANY : Niedersachsen police get TRACES connection from their car

1.1.3.1 The CVED certificate

This certificate marks the crossing point mandatory to enter the European Union. It is generated at entry points, such as border inspection points (BIP), and often involves economic operators, such as forwarding agents (aka "transitairs”), whose commercial activity consists of managing these documents as well as the other administrative procedures related to the entry of animals or animal products into the EU. These actors are more inclined to adapt to evolutions necessary for the electronic certificate.

During the preparation (phase 1) and the signature (phase 2) steps, supporting documents (invoices, Air waybill, etc.) are often attached to the certificate. In addition, in some countries, this usage context is accompanied by the process of customs clearance, which can sometimes be electronic or involve a digital signature. These elements can eventually influence the implementation of the electronic certification.

TRANSITAIR BIP CUSTOMS LVU 2

“On transport” LVU 3



certificate (from scratch or by cloning)

Complete with part II to validate or reject certificate

Check certificate for customs clearance

Check certificate along the route (by filling in part III)

Check certificate at destination (by filling in part III)

Obtain certificate with consignment

Use of TRACES

Always Always Never or Via interface

Never Rarely Rarely


Check part I & II Check part I & II Sign part III


Check part I - III

Print Yes, for pre-notification

Yes, 3 copies

Archive 1 copy 1 copy No No No 1 copy

TRACES



Law Commission Regulation (EC) No 136 & 282/2004 – 156/2009 – 01/2005 Comments LVU checks only CVED-A, never CVED-P, after passing the BIP, products are in free circulation inside EU

1.1.3.1 The IMPORT certificate

This certificate is used for the exchange of animals or products of animal origin from a non-EU country to an EU country and represents the bilateral agreement related to imports from a third country to the EU. Thus, it represents the validation of the consignment by the third country Competent Authority. The appropriate authorities and the economic operators can create the first part of an IMPORT certificate, which concerns the information relevant to the dispatched lot. Only the relevant authorities have access to the second part (health information) and are authorized to validate an import.

The import certificate concerns the movement before entering the EU and is not mandatory to provide in TRACES, but the relevant IMPORT paper certificate must always accompany the consignment, either on paper only, or on paper and in TRACES. Entering the IMPORT certificate in TRACES allows for faster handling at the border. When the consignment arrives at the border, the information inside the Import is downloaded into a new certificate: the Common Veterinary Entry Document (CVED), this electronic operation is called "cloning".

At this stage, only a limited number of non-EU countries use the TRACES system to generate documents. Among these countries, the level of the technical equipment varies greatly. The introduction of electronic certificates could require specific guidance and an adapted schedule

CONSIGNOR Third country LVU

“Origin” BIP / TRANSITAIR

Workflow Prepare part I of ‘TRACES’ certificate or

Prepare local sanitary certificate Complete (with ‘TRACES’ part II or local) to validate or reject certificate

Prepare part I of CVED certificate (from scratch or by cloning)

Use of TRACES

A few countries A few countries Always

Signature Sign part I or local Check part I or local Sign part II or local

Sign CVED part I

Print Print only if local Check printed document Get printed document

TRACES



Archive Copy signed by LVU

Law Commission Decision 2007/240/EC: certificates "IMPORT" Comments n/a

TRACES



1.1.3.1 The EXPORT certificate

This certificate is employed for exchanges from a European Union country to a non-European Union country, for certificate models defined in the TRACES system. The certificate creation mechanism is identical to that of intra-community certificates. There are no EU rules for Export certificates meaning that member state are dealing with third countries on bilateral agreements and the certificate models currently n TRACES only cover a small part of the possible certificates.

Export certificates may see a considerable growth in the future in terms of volumes and importance, as TRACES can accommodate such certificates, subject to EU MS harmonisation of export certificates.

CONSIGNOR

LVU 1 “Origin”

TRANSITAIR Border veterinary

control point “At destination”

Local veterinary control point



certificate Complete with part II to validate or reject certificate

Prepare local import certificate

Use of TRACES

Often Often Never Never


Sign local import certificate

Sign local import certificate, then destination’s actors have to sign local certificates by local regulations

Print Yes Yes Archive 1 copy signed by

LVU 1 copy signed by

LVU 1 copy 1 copy

Law Depending on non-European Union countries Comments In addition, INTRA certificate is mandatory when animals transit via others EC countries

TRACES



1.1.3.2 Synthesis

The analysis of certificate life cycles emphasizes certain key points that must be considered before the introduction of electronic certificates. The following factors can lead to constraints or precautions that the solution will need to consider.

The documents are generated and used in various locations, by different user groups, as is the case, for instance, with a veterinarian who signs a CVED in an airport veterinary inspection centre.

This implies the need to be able to sign on a work station other than that of the signer. The operation needs to be completed in an adequately secure environment.

The documents, in paper format, are handled by the parties in charge of the inspection. These parties complete the visual control of the document, in particular concerning the signature.

It therefore must be possible to verify the quality of a document, even if only the electronic version exists as proof.

The same document is often composed of several phases, such as the signatures completed by various actors (part one signed by the economic operator, part two signed by the veterinarian).

It must be possible to co-sign an electronic document.

This initial synthesis must be completed and challenged through comparison with the use of the TRACES system in the field.

1.2 Feedback on visits and interviews

1.2.1 Proposed approach

The goal of these visits was to gain an understanding of how the TRACES system is used day to day by various groups of end users. The field visits present a great opportunity to evaluate how the previously identified business processes are implemented, and to gain a clear view of the challenges related to electronic certification.

In order to draw up a realistic and exhaustive overview of usage contexts, the visits and interviews were organized according to the following criteria:

Visit several different countries, including countries with and without information systems capable of completing all or part of the functionalities offered by TRACES,

Meet varied user groups, from economic operators to veterinarians to officials,

Choose different usage locations, like for instance different types of border inspection posts (air, naval, road).

From an operational point of view, the member countries and the corresponding contact points have been identified by the European Commission (DG SANCO). Dictao organized these visits and interviews in accordance with this information.

TRACES



The interviews were divided into two separate parts. The initial part was an informal exchange during which the users described their usage of the TRACES system and the application of business processes related to the certification. The second part of the interview was more formal in nature and was based on the interview guide presented in the following section.

In some cases, such as the BIP visit, the interviews were completed during a visit by an inspection centre. This allowed, on one hand, to better understand the profession of the people encountered, and on the other hand, to determine the effective use of the TRACES system and associated documentation.

1.2.2 Interview guide

Interviews were directed by a dedicated guide, helping the team to organise the meeting and respect the schedule. Apart from explaining the context of the study and conducting the interviews, the team also explained some underlying concepts of electronic digital signature to the parties concerned.

The guide was divided into 4 sections, so that interviews were useful for the first phase of the study (in order to get the “big picture”) but would also to aid in the following phases (to prepare deployment and impact studies).

Section Objectives

Usage of the TRACES System Identify the user, his implementation of business processes, and the document life cycles

Point of View Concerning Dematerialization

Appreciate the “acceptance” of eCertification

Technical Environment Get an initial overview of technical background and technological possibilities

Your organisation and potential evolutions

Get an initial overview of deployment needs

The conclusions drawn during the interviews are available in annex 5.1.

1.2.3 Interview planning

The interviews were organized according to the visits listed in the table below. Depending on the country, the duration of the visit, and the people met, the visits could either be dedicated to a single type of actor (CCA, BIP, LVU, etc.), or they could be shared in as many meetings as there were user groups.

Date Country City Type

16/02/2011 France Paris CCA

22/02/2011 France Paris LVU lead

23/02/2011 France Roissy BIP

24/02/2011 France Le Havre BIP

07/03/2011 Italy Roma, Pisa, Livorno CCA, BIP

24/03/2011 Germany Hamburg BIP

28/03/2011 Slovenia Obrezje BIP

01/04/2011 Belgium Brussels, Zaventem CCA, BIP

TRACES



The countries visited are represented on the following map.

Figure 2 – Map of visited countries

The detailed interview list is found in the following table.

Date Country City Profile Organisation Contact name


Service d'inscription vétérinaire et phytosanitaire aux frontières (SIVEP)

Bruno SAIMOUR


Bureau de l'Identification et du Contrôle des Mouvements des Animaux (BICMA)

Régis RAFFIN

23/02/2011 France Roissy BIP Roissy BIP Selim KHODJA

23/02/2011 France Roissy BIP Roissy BIP Michel POLI

24/02/2011 France Le Havre BIP Le Havre BIP Régis CHENAL

08/03/2011 Italy Roma CCA

Ministry of Labour, Health and Social Affairs, Health Sector - Directorate General of Information System

Dott.ssa Claudia Biffoli

08/03/2011 Italy Roma CCA

Ministry of Labour, Health and Social Affairs, Health Sector - BIP and UVAC Coordinator

Donato Angelo

08/03/2011 Italy Roma CCA TRACES IT team Greco Giorgio

08/03/2011 Italy Roma CCA TRACES IT team Apicella Claudio

08/03/2011 Italy Livorno BIP Direttore UVAC Toscana e PIF Livorno/Pisa

Dr.ssa Grazia Tasselli

TRACES



08/03/2011 Italy Livorno EO Spediliv Srl Rita Billi

08/03/2011 Italy Pisa LVU Azienda USL 5 di Pisa Riccardo Rossetti

08/03/2011 Italy Pisa LVU Azienda USL 5 di Pisa Maurizio Calabrò

28/03/2011 Slovenia Obrezje BIP Veterinary Administration of the Republic of Slovenia

Bozo Zakrajsek

28/03/2011 Slovenia Obrezje BIP Obrezje and Dobova BIP

Simeon Zilevski

28/03/2011 Slovenia Obrezje CCA Veterinary Administration of the Republic of Slovenia

Tina Kos

01/04/2011 Belgium Brussels BIP Zaventem BIP n/a 01/04/2011 Belgium Brussels EO Adelantex Transitair André ROELS

01/04/2011 Belgium Brussels CCA

AFSCA Agence fédérale pour la Sécurité de la Chaîne alimentaire (AFSCA)

Alain Leroy

24/03/2011 Germany Rotenburg LVU Veterinary Administration in Landkreis Rotenburg

Dr. Joachim Wiedner

24/03/2011 Germany Rotenburg LVU Veterinary in Landkreis Rotenburg

Dr. Susanne Jungnitz

24/03/2011 Germany Rotenburg CCA

Friedrich-Loeffler-Institut, German Institute for animal health

Andreas Micklich

24/03/2011 Germany Hamburg BIP Hamburg BIP Peter Mielmann

24/03/2011 Germany Hamburg BIP Hamburg BIP Dr. Ute Gramm

24/03/2011 Germany Hamburg CCA

Friedrich-Loeffler-Institut, German Institute for animal health

Andreas Micklich

1.2.4 Interview analysis

Through the interviews, new information was collected which brings additional clarity to the abstract analysis. This information is of a great value to the rest of the study. The synthesis of these interviews is organized around the main phases of the interview guide.

Usage of the TRACES System

The users questioned are all generally satisfied with the system. Whether they were economic operators or inspectors, these users emphasized that the system is very useful, and that it has rapidly become a benchmark tool for countries that do not have an equivalent national system.

While this subject was not the topic of the interviews, certain users made comments and spoke of their expectations concerning the system. In principal, these statements are detached from the issues of electronic certification, though, in certain cases, they can represent solutions for easing the introduction of electronic documents.

The main functionalities expected are the following:

be able to access to old data and extract statistics from the data warehouse,

integrate other document types (phytosanitary certificates, third party documents such as invoices or AWB),

be able to interconnect TRACES with national systems.

TRACES



These factors bring a complete vision of the user assessment of the TRACES system, which allows for an evaluation of support needs and the potential for eventual resistance to change. The second phase of the analysis brought the most insight to the strict framework of the study.


The people questioned have a positive opinion of the dematerialization of electronic certification, and believe there to be more advantages than disadvantages.

The first cited advantage concerns the savings related to the elimination of paper. This economic motive was sited before an eventual gain in productivity (consecutive time gains linked to the suppression of printing documents and physically manipulating paper). The foreseen advantages are the following:

enhance security and document integrity,

reduce error rate and increase document acceptance by third party systems,

improve transit/clearance efficiency.

Another positive point is the fact that users do not cite any major obstruction or congestion points. Rather, the users expressed some constraints that the electronic certification solution must respect, such as the following:

must be simple to use (limited impact on process organization),

enable fall-back solutions (print, sign later…),

offer service support in the event of a problem (with the signature, certificate).

It is worth noting that users do not foresee an immediate switch to 100% electronic processes. In numerous usage cases, the usage of paper is still necessary. The foremost example is the need to print a document before proceeding to an inspection not taking place in an office, but rather in a merchandise control location.

Technical Environment

The overview of technical environments varies according to the country and the organization. In general, some main trends are apparent.

The operational actors (BIP, LVU, EO) use standard computers and lack technology (tablets, PDAs) that facilitates ‘on-the-go’ use.

The quality and modernity of hardware is clearly better in organizations with larger budgets, especially in inspection organisations that receive a percentage of the fees from economic operators to complete certificates and associated inspections.

Conversely, inspection organizations that depend purely on public funding often have restricted budgets, and have to cope with the materials at their disposal.

Countries that have initiated a national electronic ID or agent card are better adapted to implement electronic certification (existence of card readers, developed technology habits, etc.).

This allows the drawing of the following fundamental conclusions:

TRACES



The presence of digital certificates cannot be assumed, but will be a prerequisite for electronic certification,

A completely electronic process cannot be expected right away, since it requires the changing of habits and technological equipment.


According to the profiles of the parties involved (private sphere of economic operators or the public sphere of inspectors), the general attitude of the users interviewed concerning evolutions can be synthesized as follows:

For economic operators, the use of TRACES is seen as an obligation, and they are therefore willing to meet the requirements for implementing electronic certification. This is especially true for the forwarding agents, who highlighted that the usage of the TRACES system was a principal part of their commercial activity.

The LVU and BIP inspectors emphasized the fact that central services (CCA or the equivalent) made the decision for them. They insist on the need for a user-friendly solution that does not complicate their daily activities.

The central administration (CCA) is the most critical concerning the eventual necessary investments: ideally, the costs are supported by the European administration and the evolutions should be a part of national scale projects.

1.3 Conclusion

1.3.1 Main challenges

As a first step, the analysis of the business context allows us to conclude what main challenges will affect electronic certification. These are detailed in the table below, which draws on the factors cited by users interviewed during the first phase.

Interview verbatim Challenges

“Signature must not make it complicated”

Deploy an ergonomic and user-friendly solution

“I need to present other documents with my CVED”

Maintain printing capabilities and plan attached documents handling

“We are asked to check old certificate documents”

Avoid printing when possible by proposing efficient archive and search functionalities

“We are building our own system to extend TRACES”

Extend interoperability and interconnection with third-party systems

“I used TRACES but I have to fill my own record file”

Enhance statistics and plan to allow form customization

1.3.2 Proposed approach for deployment strategy

Based on the business analysis and the identification of challenges, it is now possible to formulate a strategy to identify which solution to implement for electronic certification.

TRACES



The solution target should eliminate paper processes, meaning that only documents in electronic form should be produced and exchanged. Therefore, electronic documents must have a value that will be greater than that of paper documents, and also make sure that parties no longer have to print certificates.

It has been demonstrated that the elimination of paper is not a realistic objective for the mid-term, considering the need of inspectors to manipulate paper documents.

A two-stage process can be defined:

Implementation of a solution which gives electronic documents a benchmark value,

Deployment of a solution which will replace the use of paper.

From an operational standpoint, these steps will materialize as follows:

Study and propose an electronic signature solution, in order to give legally-binding value to the electronic version of the certificate,

Study the ‘electronic document’ technologies in order to define a viable plan of action and deployment scenario.

The elements identified during this business analysis (cf. 1.1.3.2) represent constraints and expectations that the studied solution must respect.

TRACES



2. PHASE 2: TECHNOLOGICAL STUDY

The business context analysis allowed us to gain an understanding of the fields concerned with the TRACES system, as well as a realistic and concrete overview of use cases. The second phase of this analysis is dedicated to the study of technical solutions for the implementation of electronic certification. Since the market is relatively young, and technologies depend on the normative and cultural context of the electronic signature, it is necessary to choose the products, and thus the underlying technologies, with great care. Once a solution is chosen, it will be possible to define in detail the implementation principles to respect, as well as the possible impacts and prerequisites for the various stakeholders in the TRACES system. This will bring us to the third part of the study, dedicated to the deployment preparation.

The initially adopted approach for the study of technological solutions is to study the market and the various benchmark editors, then, to consider the implementation of the chosen products in the TRACES system context.

To go into greater detail, this second part is broken down into three phases:

The first step concerns electronic signature solutions : the goal is to identify the most relevant supplier in order to implement the electronic signature in the TRACES system ;

This subsequent step proposes an architecture to deploy an eSignature solution and to prepare phase 3 ;

The last concerns eDocument technological analysis: it aims to understand market trends and define the best approach.

2.1 Preamble

The process analysis allowed for the identification of the principal needs in terms of functionality. The definition of the main processes in the use cases highlighted certain actions that many user groups complete during the validation and certificate control steps, and which need be transformed into a paperless information flow.

The first function identified is the signature, which allows an actor to attest to the quality and authenticity of a document. In information technology contexts, the electronic signature is a personal digital signature, which replaces the traditional handwritten signature.

The second function corresponds to the implied gesture that occurs during the manipulation of a signed document by an individual in charge of the signed paper document control. This includes the operation during which the signature is examined to verify its quality. In information technology contexts, the operation is not directly transformed into a single technical operation. We proceed in two stages. Firstly, the signature verification is a technical operation that can be completed by a computer without any human intervention. The signature is controlled based on a pre-defined calculation or algorithm that is linked to the signature format. This is referred to as the ‘validation‘. In order to represent the visual verification step, a process can be implemented where the system user submits a document, and then receives a validation status (either OK or not) indicating a valid or invalid signature. This is a user-friendly signature validation.

It is interesting to note that the validation operation is in fact less secure in the process that involves handwritten signatures. In the electronic process, it is possible to verify ‘unknown’ signatures, while with paper documents, a signature that is simply observed can seem credible, but in fact, be fraudulent.

Finally, it is necessary to integrate a complementary function to secure the process and bring a trust level that is at least the equivalent of that in the paper world. This involves a solution that will assign a reference of time and of quality to documents. In this step also, the security level is heightened in respect to paper documents, since it is possible to modify the date of a simple

TRACES



date stamp. Timestamping allows for the reliable indication of the time of transactions, while also providing a reference value.

The logical architecture (figure 3) gives an overview of needed trust services.

Figure 3 – Trace system logical architecture overview

2.2 Digital Signature

2.2.1 Digital signature basics

2.2.1.1 Digital signature principles

The digital signature is a mechanism that guarantees the integrity of an electronic document, and authenticates the author. The digital signature holds the same value as a handwritten signature on a paper document. Digital signature mechanisms should have the following properties:

They should allow the reader of the document to identify the individual or organization that signed the document.

They should guarantee that the document has not been altered between the period of the initial signing by the author and when the document is read or consulted.

To accomplish this, the following conditions must be met:

Authentic: The signer’s identity must be established.

Non-falsifiable: The signature cannot be forged. Each party must be securely identified.

Non-reusable: The signature can only be used one time. It is incorporated into the signed document and cannot be placed on a different document.

Unalterable: Once signed, a document cannot be modified.

Irrevocable: The signer cannot deny having signed.

The digital signature is possible through the use of asymmetric encryption, which associates a public key with a private key.

It is different from manual signatures because it is not visual, but rather corresponds to a sequence of numbers.

Signing a document is done according to the process depicted below.

TRACES PORTAL

TRUST SERVICES Technical Validation

Timestamp Personal

signature Validation

TRACES



2.2.1.2 Signature validation

Once a document has been digitally signed, the recipient(s) must be able to ensure the validity of the signature.

Several things must be checked:

The electronic signature certificate

o The identification of the certificate authority

o The technical format of the certificate

o The validity of the certificate at the time of signing

o The authorization of the certificate to complete signatures

o And optional checks depending on the trust policy (keyUsages of the certificate, certification path, e.g.)

The validity of the signature in relation to the document according to the following process:

TRACES



2.2.2 Digital signature methods

2.2.2.1 Electronic certificate

What is a certificate?

An electronic certificate is a digital identity card, whose purpose is to identify an entity, physical or not. The digital or electronic certificate is a link between the physical entity and the digital entity (Virtual). The certification authority acts as a trusted third party which confirms the relation between the physical and digital identities.

Each digital certificate is associated with both a public and private key (the private key stays in the user’s possession). These keys assure, through asymmetric encryption operations, the signature functions.

Certificate format

The digital certificate used for the signature operation should be in the X509 v3 format. The International Telecommunication Union created this norm in 1988.

In the X.509 system, a certification authority (CA) grants a certificate that links a public key with a Distinguished Name (DN), to an electronic address or a DNS registration.

A digital certificate contains a certain amount of data. The most important information is:

Version

Serial number

TRACES



Certificate signature algorithm

Certification authority DN

Certificate validity

Certificate holder DN

Public key information

o Public key algorithm

o The public key itself

Extensions list

Signature of the information below by the certification authority

In order to complete a digital signature, the certificate must contain the ‘Signature + Non repudiation’ usage extensions.

2.2.2.2 Certificate support

Digital certificates are available as either:

Software

Hardware (on a smartcard or on a USB token)

A software certificate is an information file that is installed on a workstation. Delivered by a certification organization, it offers the standard certificate functions.

Unlike a certificate stored on a hardware device (smartcard, USB token…), it does not guarantee the identity of the certificate user. It is ideal for businesses whose employees have sufficiently secure access to their workstation or for transactions that engage the entire organization.

For sensitive data, the use of a certificate that is stored on a secured device presents many benefits:

Security: the device can only be used by an authorized party, meaning that the confidential data stored on the chip are only accessible by the given user. In addition, as with a bankcard, the smartcard or the USB token can be automatically blocked in the event several incorrect PIN codes are entered.

Mobility: storing the certificate on the secured device allows the owner to use the certificate from any workstation that is equipped with a card reader or USB port.

Reliability: certificates that are stored on hardware devices cannot be duplicated.

TRACES



An example of a USB token containing one or several certificates

An example of a smartcard and its reader

2.3 eSignature vendors study

The eSignature vendors study starts with a market analysis, which focuses on:

The sufficiency of sources and vendors, at least at a European scale,

The suitability of adapting the solutions to the context of TRACES and its specific characteristics, especially in terms of signature formats and supported functionalities.

The study began with a comprehensive market analysis, organized as a general market study, in order to choose vendors considered relevant to the market. The method for choosing vendors is described the following section.

Next, an analysis matrix was defined. This matrix combined economic, technical and functional factors, while taking into account security level of the solution and some vendor-specific added value (ability to provide “SaaS”, ergonomic interface for example). This process allowed for the retention of three suitable vendors, which were then studied in greater detail and compared to each other.

2.3.1 Market analysis

An initial list of publishers was prepared (see table 1), independent of the specificities of the TRACES system, with the goal of establishing a list of the most competitive players in the market. These vendors are considered to be key market players, who can potentially supply all or part of the solution necessary to the TRACES system.

This list is composed with various sources of information, such as:

Publications from firms specialized in IT market analysis and research, for example the Gartner Group,

Web sites for large government projects (eID in various countries, PEPPOL, etc.) and other relevant parties (control and accreditation organizations, standards groups, etc.),

Technically or financially specialized web sites,

Expertise from Dictao Consulting practices.

The companies on this list are for the most part young (founded less than twelve years ago), small & medium business. Most of the selected companies were created during the Internet bubble or after it burst.

TRACES



Companies selected are young. This is the reason why turnover is quite low: mostly between 1 and 25 million.

In our panel, we privileged enterprises specializing in digital signature, rather than companies that were more or less general. We also examined some companies that have profiles identical to Dictao, in order to avoid distorting the comparison. These companies are of smaller size.

Two-thirds of the companies have less than 500 employees.

TRACES



In order to establish a list of actors present at the European and worldwide scale, we listed the functionalities that their products will need to provide:

Personal signatures, which link the identity of one or several individuals to a document. They also allow users to know who verified the document, thanks to the fact that the electronic signature is generated in the terminal of the user,

Signature servers, which produce an electronic signature via the Internet, instead of through the use of a specific software,

Validation servers, which verify the identity of the signer,

Web portals, which allow all users to be able to verify digital signatures (also available in an externalised SaaS mode).

Any qualifications or certifications can reinforce these functionalities. In addition, the enterprises that exemplify most of these characteristics will be selected as benchmarks.

The following list of companies was established on the following page.

TRACES



Company Size Founded Revenue Personal signature

Signature server

Validation Server

Integrated portal

Pure SaaS Qualification Comments

Actalis 10-50 2001 10-25M$

Adobe 1000-10 000 1982 >1B$ PDF file only

Alpha Trust <10 1994 <1M$

AssureSign 50-100 2004 10-25M$

Authentidate 50-100 1985 5-10M$ “US” electronic signature

Bremen 100-500 1999 - X

CertEurope 10-50 2001 <1M$ X

C.I.C 10-50 1981 1-5M$

Comped <10 1987 1-5M$ X

Dictao 50-100 2000 10-25M$ X

DigitalTrust n/a 1995 n/a Website not updated anymore

DocuSign 50-100 2003 1-5M$ “US” electronic signature

EchoSign 10-50 2005 10-25M$

Infocert 100-500 2007 25-50M$ X

Intarsys 10-50 1996 10-25M$ X Website not updated anymore

Itella >10 000 1638 >1B$ Finland postal services

Keynectis 50-100 2004 10-25M$ X

Primekey 10-50 2002 1-5M$

SafeLayer 10-50 1999 <1M$ X

Secrypt 10-50 2002 <1M$ eDocument solutions

Sertifi 50-100 2005 10-25M$ “US” electronic signature

OpenLimit/SignCubes 50-100 2005 1-5M$ X

Silanis <10 1992 <1M$ “US” electronic signature

Trustweaver 50-100 2001 X

Vasco Data Security 100-500 1997 50-200M$ Signature tokens

xyzmo SIGNificant 50-100 2004 10-25M$

TRACES



2.3.2 Selection criteria

Given the sensitivity of the TRACES system, as well as its pan European and international nature, and its increasing importance in the European Commission ‘EU Animal Health Strategy for 2007 – 2013’, the chosen supplier will need to satisfy the following criteria:

Financially solid and stable,

Compliant with European practices and regulations,

Capacity to deliver an industrialized solution that is proven and sturdy.

All the vendors have been the subject of a detailed analysis, based on the following criteria.

Functional conformity criteria

The publisher should offer personal signature feature (to allow a TRACES user to sign its certificates) and also signature validation functionality (to allow TRACES system to check user signature). More over timestamping is needed to secure time reference used define the date the signature was created.

In addition, the solution could offer an integrated platform, available in ‘license’ mode. A solution that is only available in SaaS mode will not be favoured as it restricts the choice for EU.

Security and conformity criteria

As the signature will be used to create an official document, its security must have a high level of security. This level should be proved by certifications, such as Common Criteria conformity (at least EAL3+).

Certifications can be completed by member-state conformity check by IT security national agency (ANSSI in France, Bundesnetzagentur in Germany). Products that have been certified in several EU countries would hereby demonstrate their ability to secure the solution and to secure it regarding member-state official security standards.

Signature criteria

It is worth noting that the concept of ‘electronic signatures’ has a variety of meanings in terms of technical complexity and the proof of the signer’s commitment. The European view is stricter than that of The United States.

Directive 1999/93/CE of the European Parliament and of the Council of 13 December 1999 describes the Advanced digital signatures which are uniquely linked to the signatory, and created using means that the signatory can maintain under his sole control: it is capable of identifying the signatory and is linked to the related data in such a manner than any subsequent changes are detectable.

For the US, in Uniform Electronic Transactions Act Section 2, electronic signature means ‘an electronic sound, symbol, or process attached to or logically associated with a record, and executed or adopted by a person with the intent to sign the record.’

TRACES



It is not possible to account for signatures completed by a simple ‘click’ or through the affixing of an image to a document (meaning signatures not based on electronic certificates and the associated cryptographic mechanisms).

This constraint led to the elimination of all market actors.

In the following table, the ‘personal signature’ category conforms to the advanced view of the European Directive.

Respect for generally accepted norms and standards

In addition to the methods of quality and secure design, the support of XAdES format signatures is necessary to use advanced digital signatures described in directive 1999/93/CE.

Publisher credentials and references

The last analysis criteria is the size and number of projects the solutions have been used for. It provides real life example of the abilities of the solution and also of the economic situation of the publisher. Regarding TRACES context, references have been sorted in three ranges: privates companies, public organisations and EU projects or workgroups.

TRACES



2.3.3 Benchmarking of selected companies

2.3.3.1 OpenLimit

OpenLimit products have been audited against the Common Criteria framework and are also proven to be compliant with the German legal framework. Products have a high level of security (EAL 4+) and have been used with German eID cards.

http://www.openlimit.com/

Solutions Products

Personal signature OpenLimit CC Sign

Signature server OpenLimit SignatureService

Validation server OpenLimit Batch Verifier

Integrated portal -

Certifications & Qualifications

Common Criteria Certifications

German legislation compliance

Common PKI

Private references Public references EC references

Allianz German Federal Plant Variety

Office Stork

Europcar Federal State of Brandenburg,

Sixt Swiss Federal Administration

Authority

Siemens

Swiss Gazette of Commerce

TRACES



2.3.3.2 InfoCert

InfoCert proposes a range of eSignature products and is also a PKI specialist, with millions of digital certificates already deployed. InfoCert mainly addresses Italian market.

http://www.inforcert.it/

Solutions Products

Personal signature Dike LegalCert Family

Signature server LegalCert Digital Sign Server

Validation server -

Integrated portal LegalCert Remote Sign


Italian Legislation Compliance


Danone FIPAV SPOCS

DeLonghi ANUSCA

Coop

Simegenia

Dike is a software program that allows users to digitally sign one or several electronic documents, to verify the validity of a document, and to complete other operations, such as timestamping and signature verifications, by using a remote server.

Digital Server Sign Legalcert completes these same operations, and is integrated in the Web applications. This means that it is not necessary that the operator has a work station that is specially equipped for digitally signing online contracts, documents, and enrolment forms.

2.3.3.3 Dictao

TRACES



Dictao proposes a “Trust Suite” that has been proven on large-scale environments and that is compliant with two legal frameworks in Europe.

http://www.dictao.com/

Solutions Products

Personal signature Dictao AdSigner

Signature server Dictao Signature Server

Validation server Dictao Validation Server

Integrated portal Dictao Trust Platform


Common Criteria Certifications

French legislation compliance

German legislation compliance

Visa & MasterCard Certified


Total French Ministry of Finances OPOCE

PSA French Ministry of Defence

Société Générale French Ministry of Interior

BNP Paribas CREDOC

BPCE French National Bank

Dictao Trust Platform proposes an integrated platform, in order to smoothly deploy eSignatures into business applications

Dictao Trust Platform ensures all trust functions:

Delivery of short-term or permanent certificates

Personal signature completed on the client station or server (Dictao AdSigner)

Entity signature completed on server (Dictao Signature Server)

Validation and constitution of proof (Dictao Validation Server)

Timestamping (Dictao Time Stamp Server)

TRACES



Dictao AdSigner allows users to sign Web forms and data flows from their workstation. The program’s reliability, robustness, and conformity with the strictest regulatory frameworks are regularly attested to by the French Network and Information Security Agency. In addition to conformity with the law of March 2000, which states that electronic signatures can legally replace handwritten signatures, Dictao AdSigner allows users to create secured electronic signatures, as defined by the European decrees.

Dictao Signature Server allows for the signing of documents on behalf of an entity (an organization or enterprise) or an individual. Dictao Validation Server is a signature validation server product, while Dictao TimeStamp Server timestamps exchanges and documents, using a reliable time source.

2.4 eSignature Architectures

2.4.1 Proposition of architectures

In order to plan the deployment of eSignature, three propositions of architecture have been reviewed:

Offline signature architecture

Online signature architecture with multi-components

Online signature architecture within a platform

They can be used as a complement in order to select a vendor.

2.4.1.1 Offline signature architecture

When a personal signature component is not an “online thin client” (in the case of Infocert or Openlimits e.g.), the process has to be separated into multiple steps:

1. The user completes the form in TRACES

2. The user downloads the completed form to his or her computer

3. The user signs

4. The user uploads the form to TRACES

5. TRACES validates the signature

We have identified several inconveniences related to the adoption of this approach:

TRACES



Need to manage only the OS, and not the browser

Requires the installation of a thick client on the computer

Less user-friendly

Complex integration for TRACES (manage download & upload),

Supplementary development on the TRACES portal to handle download & upload

Risk of viruses (higher than other solutions as the user directly handles on its PC the certificate file that will be uploaded onto the TRACES portal)

2.4.1.2 Online signature architecture with multiple components

This architecture is based on the use of multiple components, and especially an “online digital signature client,” which will automatically deploy signatures to the client. This scenario relies on the advantage of packaged products, that can be delivered by one or more vendors (although the choice of one only vendor reduces the integration risks).

1. The user completes the form online in TRACES

2. The user signs the form online


This scenario relies on the advantage of packaged products, that can be delivered by one or more vendors (although the choice of one only vendor reduces the risks during integration).

This has several advantages in comparison with the previous approach:

No installation on the computer Compatibility with all browsers

Improved ergonomic (browser only, no third-party software)

Easy integration

TRACES



2.4.1.3 Online signature architecture within a platform

This architecture uses a “trust platform”, an integrated packaged platform in charge of the orchestration of all trust services.

This solution reduces the costs of integration. Moreover, depending on the vendor, the trust platform can interact with a PKI in order to deliver digital certificates to users not having access to an eID or smartcard. This is the preferred approach of Dictao.

1. The user completes the form online in TRACES

2. The user signs the form online


This solution significantly reduces the costs of integration. Moreover, depending on the vendor, the trust platform can interact with a PKI in order to deliver digital certificates to users without eID or smartcard. This is Dictao’s approach.

This approach offers the most advantages.

No installation on the computer Compatible with all browsers

Improved ergonomic (browser only, no third-party software)

Separation of functions between the business portal (TRACES) and the signature portal (signature platform)

Easy integration

2.4.2 Deployment issues

Among the three approaches, the third and last option seems to offer the greatest number of advantages. It facilitates the integration and reinforces the user-friendliness of the processes.

The user sees the signature as the final step in the creation of a document, just as in the paper process in which the signature signals the completion of the form.

For the TRACES system manager, the signature (in a general sense, and including the signature validation and timestamping steps) is seen as an independent part that still easily interacts with the organization system.

TRACES



This third option will be chosen for the third phase of the study.

2.5 eDocument technologies study

After eSignature, the next move towards electronic certification is the removal of paper. This would mean that every veterinary certificate would be in electronic form: after eSignature would come eDocument. The term ‘eDocument’ is used for a document that does not need to be printed. The need of paper is still confirmed by people using the TRACES system on a daily basis. Moreover the TCO of eDocument shows that this kind of solution could be premature. The study will hence focus on technologies rather than solutions and established vendors.

2.5.1 Overview of technological trends

Our context is at the crossroads of many technological fields.

On one hand it comes from the Paperless Office domain, which aims at reducing the use of paper in everyday life.

On the other hand, it is linked with the Automatic Identification and Data Capture (AIDC) domain, from the traceability domain. It refers to the methods of automatically identifying objects, collecting data about them, and entering that data directly into IT systems.

2.5.2 Paperless technologies

Underlying technologies can be ‘electronic Documents’ (electronic files or HTML forms e.g.) or ‘electronic paper’: the paper is not used anymore, but is replaced by a specific device (a reader or another, more advanced device). An electronic document is any electronic media content that is intended to be used either in an electronic form or as printed output.

Electronic paper and electronic ink are a range of display technologies, which are designed to mimic the appearance of ordinary ink on paper. ePaper involves a specific kind of devices that have been created mainly for viewing document and not editing it. eDocument is the use of portable devices able to handle major functionalities of a typical computer.

Benefits

Allow access to documents anywhere and in one place (unless the device is lost…). The saving of documents on several supports is recommended.

Low energy consumption for ePaper.

Use cases

One common use case is package delivery (UPS, Fedex, Posts, etc.) : packaged tracking possible on a device (PDA, dedicated eReader) that sometimes allows recipient signatures

Banking industry is working on eDocuments to modernize contracting processes.

Sizing figures

eReader Device : from 100 €

eDocument Device from 200 €

2.5.3 Automatic identification and data capture technologies

The principal goal of underlying technologies is not to replacing paper, although a reduction of the use of paper, by offering a simple link to an electronic document or a database, is accomplished.

TRACES



“Barcodes are the dominant trace technology. They are used throughout most industries because of low costs. RFID is a successor, a complementary solution that provides additional functionalities, but is more expensive. RFID growth is going to exceed barcode growth so that in some sectors (Commercial services, Government), it will be the usual AIDC technology” [VDC Research Group]

2.5.3.1 Barcode technology

A barcode is an optical machine-readable representation of data about the object to which it is attached. Originally, barcodes were referred to as data represented in a linear fashion by varying the widths and spaces of parallel lines storing 10 characters. Later, they evolved into geometric patterns of various heights, storing more than 200 characters. Barcodes can be scanned by optical mechanisms, or interpretive software on desktop printers, smartphones or tablets. They can be used to store the document ‘ID’ and would need a computer for the filling and signing processes.

Benefits

Barcode costs are very low, and they can be read with daily communication tools (e.g. smartphones). They are based on an international code norm.

Barcodes are now fully incorporated into everyday commercial practices.

They can be printed by any printer.

Use cases

In the present context, a bovine eartag has an embedded barcode.

Sizing figures

Barcode unit cost : 0,005 €

Dedicated optical device : from 50 €

2.5.3.2 RFID technology

Radio-frequency identification (RFID) is a technology that uses radio waves in order to transfer data between a reader and an electronic tag attached to an object, with the purpose of identification and tracking. RFID readers scan all tags that pass near to them. RFID readers can be mobile and tags be fixed. As for the barcodes, they would only store a document ID.

Benefits

The reader can read tags either in a stationary position (fixed RFID) or in a mobile fashion (mobile RFID).

It allows for rapid tag merchandise scanning

Use cases

In the event of movement between Member States, pets have to be identified by RFID, in order to ensure a clear link with the animal health certificate (EU-passport).

http://ec.europa.eu/food/animal/identification/pets/index_en.htm Animal tracking is one of the first applications Texas Instruments deployed for its RFID technology, after more than 16 years of experience.

Sizing figures

Usually, RFID unit costs are between 0,07 and 0,30 €

RFID scanner : from 1000 €

TRACES

http://ec.europa.eu/food/animal/identification/pets/index_en.htm



2.5.4 Technological benchmarking

The following table presents a comparative analysis of the possible technologies.

Costs Integration Usability Signature-readiness

Barcode Low unit cost

Average device cost

Medium complexity (printing is easy)

Fair No signature ability

RFID High unit cost

High device cost

High complexity (both printing and reading)

Remote tracking can simplify control process

No signature ability

eReader 0 unit cost

High device cost

Almost no impact Can be as usable as paper

Can integrate digital certificate or allow handwritten signature

Figure 4 – Technological benchmarking

Increasingly convenient

The RFID and the barcode do not have the same functional scope as the eReader, which can cover a document’s entire processing chain, from the document’s initial production and signature until its reading and validation. The RFID and the barcode do not print the document, but rather provide the user with a link to the document, in order to reduce the usage of paper in the process.

It seems as though the RFID presents several issues which could cause problems in the process. The main problem is related to the functioning of this technology. It is unlikely that an economic operator will use a device that is costly to register the identifiers in a RFID tag.

In addition, the eReader / ePaper domain is not completely mature at this point in time – the devices are oriented towards reading, and do not include the capacity to write and sign.

Based on this, barcode technology has been chosen for the rest of the study, due to its ease of access and its cost. It is not very expensive, and it is technologically simple to add a function for the generation of barcodes, which can be integrated in a document during printing, to the TRACES portal. In addition, numerous actors in the field already have a scanning device (for cattle identification, and commercial and logistical aspects of the industry, etc.).

2.6 Conclusion

The technical analysis phase highlights the feasibility of implementing electronic certification, and the introduction of digital signatures in the TRACES portal. The market offers solutions that cover the needs identified during the first phase, all while respecting the security, conformity, and sustainability constraints that a solution have to encompass.

The following phase focuses on the prerequisites related to the deployment, in order to evaluate all of the projects that will need to be implemented in TRACES, as well as the information and devices that users must possess in order to benefit from electronic certification functions.

TRACES



Phase 3 will now focus on the deployment of an eSignature solution.

We propose two major tasks within this phase:

Deployment impacts for end-users

o Definition of acceptable certificate authorities and certificate deployment strategy

o Technical prerequisites

Deployment impacts for DG SANCO

o Detailed usage cases

o Functional needs (signature policy, e.g.)

o Technical impacts on TRACES system architecture

TRACES



3. PHASE 3: DEPLOYMENT STRATEGY

The purpose of phase 3 is to define and understand prerequisites for the deployment of electronic certification in TRACES. Prerequisites have to be seen from both sides.

From the point of view of a TRACES end-user: users will have to comply with prerequisites in order to be able to sign and to user trust and security features.

From an EC point of view: TRACES owner will have to deploy the trust platform software needed to implement digital signature.

Deployment strategy will use phase 1 and phase 2 conclusions. Business and functional needs identified during phase 1 (business analysis) are used as inputs of deployment strategy to define expected features of the solutions. Technical analysis of phase 2 is a way to check the feasibility of such features. This way phase 3 will clearly define the solution from both users and EC point of views.

Facing business needs (“what we should do?”) and technical constraints (“what we can do?”) allows us to define a practical and realistic approach for deployment.

3.1 Overview

Before defining detailed prerequisites, an overview of eCertification platform and processes is presented in order to exemplify the deployment strategy analysis.

3.1.1 Logical architecture

The logical architecture is illustrated on the following diagram. TRACES users only seen the usual portal but TRACES system will interact with a trust platform. This platform is an integrated security services component that will be in charge of the whole digital signature processing for the TRACES portal.

TRACES



3.1.2 Sequence examples

3.1.2.1 Electronic signature on the declarer station sequence

This sequence is a simplified presentation of the declarer’s signature on the workstation. This process can easily apply for other users of the process.

Part B: enrollment

Part A: eligibility

Declarer TRACES portal Eligibility Service Trust Platform

TRACES portal

authenticationAccess authorized

Enter data on the formPreparation of the

document to sign

Call to TP

Call eligibility platform

to detect the presence

of a recognized

certificate

Deployment of the

detection tool on the

user station

Detection of the client

configuration Eligibility analysis

Station eligible : the

signature will be

completed on the client

station

Signature request

Display of the signature

page

Reading of the

document

Signature with personal

certificate Signature validation

Loading of the

configuration

Return to TRACES

Display of an end page

Sending of the

document

Receiving of the

document

Legend:

Call to the TP platform

Call to the eligibility platform

Response: OK

TRACES



3.1.2.2 Electronic “server side” signature

Part B: enrollment

Part A: eligibility

Declarer TRACES portal Eligibility Service Trust Platform

TRACES portal


Enter data on the formPreparation of the

document to sign

Call to TP

Call eligibility platform

to detect the presence

of a recognized

certificate

Deployment of the

detection tool on the

user station

Detection of the client

configuration Eligibility analysis

Station not eligible : the

signature will be

proceed on the server

Signature request

Display of the signature

page

Reading of the

document

Clic on the « Sign »

button

Server Signature

Signature validation

Loading of the

configuration

Return to TRACES

Display of an end page

Sending of the

document

Receiving of the

document

Legend:

Call to the TP platform

Call to the eligibility platform

Response: KO

TRACES



3.1.2.3 Electronic signature validation by a veterinarian sequence (Web)

The purpose of this sequence is to present to validation of a signature by a veterinarian (for example) by using the TRACES portal.

Once signed, each individual or group that consults the document must be able to validate the digital signature. This means ensuring that:

The signature associated with the document was completed by the certificate holder

The certificate used was valid at the time of the signature, and authorized to complete this signature

The certificate was issued by a recognized certification authority

Therefore, it must be possible, through the TRACES reference for example, to view the original document and guarantee the validity of the signature(s).

A web interface (which can be integrated in the TRACES portal) should enable:

Entering the document reference

Displaying the original document

Displaying the signatures as well as the associated information

Showing, in a clear manner, that the signatures are valid

Declarer TRACES portal Trust Platform

TRACES portal


Enter or scan the

document barcode

Document search

Signature recuperation Signature validation

Validation proofValidation recuperationDisplay of results

TRACES



Example of the signature validation portal

3.1.2.4 Electronic signature validation by the Competent Authority (mobile terminal)

The purpose of this sequence is to use an application on a portable terminal (an iPhone or Android, for example) in order to validate the signature(s) on a document.

TRACES



Declarer TRACES portal Trust Platform

Running of the

application on the

terminal

Access authorized

Scan document

barcode

Document search

Signature recuperation Signature validation

Validation proofValidation recuperationDisplay of results

Example of a smartphone application for signature validations

TRACES



3.2 End-user point of view

3.2.1 Prerequisites for digital certificate

3.2.1.1 Preamble

Digital certificate is used in the process of digital signature. As explained in 2.2.1, it is necessary to create a link between a user (or a server) and a signature. If the act of signing is writing down your name on a sheet of paper, the digital certificate is the pen of the signer. Digital certificates can be software- or hardware-based, they can be delivered by the signature portal or by a professional dedicated certificates provider, they can be personally stored or remotely and securely stored. But eventually, every TRACES user that must validate a document needs a digital certificate.

How to obtain a certificate?

Digital certificates can be purchased through a certificate authority, for a specific use and period of validity.

On its website, the European Commission publishes and regularly updates a list of trusted certificate authorities that issue certificates that are qualified in all EU countries

1. The certificates

issued by these authorities have a level of trust and security that is adapted to the electronic signature and its recognition in all EU countries.

In case of third-party countries (non EU), this trusted list is not available. A certificate authority (CA) selection process can be defined. Some CAs are well known at a worldwide level and can be trusted and integrated within the trust circle, as soon as all security and legal requirements are met and checked. For instance, the list of CA integrated within popular browsers can be used.

In the Microsoft Windows ® world, Microsoft defined a “Windows Root Certificate program” to list all the trust CA that are automatically integrated within Microsoft products. The list can be found online

2. The list counts 321 certificate providers, in 49 different countries, as explained in

the Appendix 6.3.

Then when a user wants a certificate from a local vendor, TRACES administration must check the security and quality of the local CA to ensure it can be used. This process can be done by checking security certifications of the CA or by validation of local information security agency.

Last, if a user already has a certificate, he must have a way to check the usability of the certificate. This case would happen in countries where eID or professional smart cards have been deployed. So TRACES could integrate an ergonomic page proposing a small test tool: the user uses his certificate for a signature test and the site can validate or no the use of this certificate for electronic certification within the TRACES portal.

This portal could look like the following example from a project created for online banking to ensure users can easily test their signature certificate and their computer configuration: http://www.dictao.com/3skey/prehome.do?request_locale=en

How much does a certificate cost?

1 http://ec.europa.eu/information_society/policy/esignature/eu_legislation/trusted_lists/index_en.htm

2 http://social.technet.microsoft.com/wiki/contents/articles/2592.aspx

TRACES

http://www.dictao.com/3skey/prehome.do?request_locale=en

http://ec.europa.eu/information_society/policy/esignature/eu_legislation/trusted_lists/index_en.htm

http://social.technet.microsoft.com/wiki/contents/articles/2592.aspx



These prices serve only as a reference, and are only indicative of the prices for the Certificate Authorities in France.

A hardware certificate costs around 80 € without taxes per year, to which the cost of the USB token reader must be added (around 50 € without taxes),

A software certificate costs around 60 € without taxes per year when bought from an external PKI,

Digital certificate and server-side signature

The process of personal signature can be “server-side”: this means that the signature of a veterinary certificate is made on the server (and not on the computer of the signer) with a one-shot personal digital certificate (generated by the system and dedicated to this signature and document).

In that case, the user does not need to have its own certificate. It will be automatically generated for the transaction. So it is a 0 € cost for the end user.

This solution clearly optimises financial cost of the eCertification. Moreover it avoids any deployment issue related to personal signature component. But such an option has some security weaknesses. When the signature digital certificate is server-side created and used, authentication must be enforced in order to be sure the right user will use its certificate (otherwise anyone could sign a document using just a login and password). So it is to be seen as a temporary bypass, while waiting for public administration bodies to deploy smartcards or eID.

3.2.1.2 Prerequisites

Prerequisite summary

The electronic certificate used for the signature operation must respect the X509 v3 format. The International Telecommunication Union created this norm in 1988.

In order to complete a digital signature, the certificate must contain the ‘Signature + Non repudiation’ usage extensions.

Software certificate

In order to use a software certificate to complete a signature, it is necessary that the certificate be installed in the Web browser certificate store.

The minimum configuration for a workstation is Windows XP SP3. This version of Windows is the first to be capable of using the Hash SHA-256 algorithm. This algorithm manages the fabrication of a fixed-size imprint on a document to sign. The previous version of this algorithm (SHA-1) is no longer considered to have a sufficient level of security.

Hardware certificate

In order to be able to use a hardware certificate for the completion of a signature, it is necessary that software (a type of middleware) provided at the time of purchase be installed. This software will interface between the smartcard or token and the Web browser. In this configuration, the middleware will support the SHA-256 algorithm.

TRACES



3.2.2 Prerequisites for digital signature

3.2.2.1 Preamble

In the framework of electronic signatures, it is important to understand the legal aspects of the recognition of digital signatures within the European Union. This was the purpose of a European Commission project for the European Directive on the Electronic Signature (Directive (EC) 1999/93)

3.

This directive seeks to develop electronic exchanges and sets up a legal framework for the digital signature, which will be uniform in all EU countries. It is accomplished by defining the conditions in which a digital signature can hold the same legal value as a handwritten signature in all EU countries. To ensure a digital signature has the same value as a handwritten one, the solution must be based on a qualified digital certificate and a secured personal signature component.

The main challenge is the fact that qualification and security level are defined at a member state level, even though the directive is EU wide. As it has been underlined in phase two, there is no signature software that is qualified in every member state.

So this level of conformity is the highest one but can be the most expensive one (especially because of certificates deployment costs). In many cases, especially when the use of the digital signature is clearly defined, as in the “trust sphere” composed by all TRACES users and related authorities, such a digital signature is not totally needed. It is possible to define the way the digital signature will be created and used through some sort of a “trust policy”. Stakeholders will then validate this policy, defining this way a local framework for digital signature.

This kind of approach can be adapted to the context of TRACES. The technical conditions of digital signature (from the way user signature is created to the way digital signature and digital proof are managed and stored) must be defined and share with TRACES stakeholders. After that, a two-step approach is proposed to create this trust sphere.

First, every member state must recognise the legal value of digital veterinary / sanitary certificates: when an authority receives a document that has been digitally signed, it must not be rejected to the motive of the nature of signature. Digital documents will this way be accepted and used at the same time as paper documents.

Then, digital signature will be the only way to create a valid certificate. Every veterinary / sanitary certificate will have to be produced by the TRACES portal and to be digitally signed: a document that could not be found within the TRACES system could not be accepted as legal. This requires adapting the legislation, imposing the direct use of TRACES in real-time.

Prerequisites for the end-user are part of the technical conditions of the digital signature.

3.2.2.2 Signature component

It has been seen that a certificate is needed. But in order to complete signature operations, the client workstation must have software that is capable of employing the user’s certificate to sign a document. This software is referred to as a ‘signature component’.

This component must respect the following constraints:

3 http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2000:013:0012:0020:FR:PDF

TRACES

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2000:013:0012:0020:FR:PDF



Support of certificates (both software and stored on hardware devices)

Certificate filtering, to point out which certificate to use according to the context

Display of the document to sign (WYSIWYS : What You See Is What You Sign)

Support of the main signature formats available on the market (XAdES, PAdES, etc.)

Support for detached, enveloped and enveloping signatures

From a technical point of view, the component must be easy to deploy. A Java applet can be an appropriated solution. This allows a transparent deployment on the workstation, without user interaction or needs for specified privileges.

Because of the diverse range of configurations that can be encountered throughout the EU, the component must be as flexible as possible. Currently, the solution must support:

Windows XP 32bits SP2 or higher (SP3 for software certificates)

Windows Vista (32 or 64 bits)

Windows 7 (32 or 64 bits)

Mac OS X 10.4 or higher

Linux

The signature component must support the following browsers:

Internet Explorer 6 or higher

Firefox 1.5 or higher

Google Chrome 6 or higher

Safari 3 or higher

In the case of a Java applet, the two following prerequisites must be respected:

The Java plug-in must be installed as a browser plug-in, in order to run the applet components

JavaScript must be authorized to run in the browser

Prerequisites summary

Software

The client must have a Java machine in order to run the applet:

- Java Sun 1.4.2 or higher

- Apple JAVA on MAC OS X

The signature component will support almost every workstation configuration supported by TRACES portal. Moreover it will give the user a way to download supported browsers and plugins in the case the user has a deprecated one.

Hardware

TRACES



The client station needs to have a free USB port, to connect the USB token or the smartcard reader in case of a hardware certificate.

3.2.3 Prerequisites for paperless use

3.2.3.1 Using barcodes and a reader

In order to simplify the validation and signature processes, it is possible to attach a barcode to documents. This will facilitate their reading.

The barcode can be in the ‘Code 128’ format, which permits the encryption of 103 character of the ASCII table. This code is very flexible for encoding information, and is readable by the majority of barcode readers.

Example of a barcode in the ‘Code 128’ format

3.2.3.2 Prerequisites

Prerequisite summary

It is necessary to have a reader that is compatible with the type of code used in order to be able to use the barcode printed on the document. The installation of a driver on the client station is not necessary – the barcode reader acts as a keyboard.

From a cost point of view, nowadays, barcode readers can be bought for between 50 and 100€.

3.2.4 Conclusion

Certificate costs underline the need of a deployment strategy than can reduce the investment for TRACES users, especially for public organisations. The objective is to have a free solution for administrative authorities. We can reach this goal by using existing certificates when available or delivering a certificate for users whose organisation doesn’t use a PKI.

In order to support such a solution, we propose the following approach, based on the following hypothesis:

Economic operators can buy a hardware certificate from a trusted provider,

Public authorities can use their smartcard when available,

TRACES will not become certificate providers but will use a server-side signature with on-the-fly certificate for public authorities that need certificates.

This strategy allows an easy deployment but is, in theory, supposed to be time-bound. We can believe that more and more public administrations will deploy smartcards or allow their agents to use their eID.

TRACES



This certificate deployment strategy can be summed up in the following diagram.

3.3 EC point of view

3.3.1 Preamble

The purpose of this chapter is to review the essential elements in choosing a trust platform for the introduction of the electronic signature in the TRACES system.

The implementation of the electronic signature should be based on a unified trust platform with a set of features including:

A set of trust functions to achieve the signature process, timestamp, validation, proof management and archive

An integrated approach to simplify the process of signing and the integration to the TRACES portal

An ability to respect the key principles of implementation, such a high security, performance and reliability.

3.3.2 Main trust functions

3.3.2.1 Electronic Signature

A trust platform must offer a set of functions to ensure certificate signature:

eligibility of the user workstation,

entity signature on behalf of TRACES,

Economic operator

Administration agent

Uses his own certificate

Uses his own certificate

Server-side signature

Buy a new certificate

TRACES



server-side signature on the behalf of the user,

signature on the user workstation,

on-the-fly digital certificate generation.

With each signature, the platform combines a signature policy with a set of parameters such as trusted Certificate Authorities, use of software certificates or not for instance.

Eligibility

The eligibility is designed to perform detection of the user workstation configurations and retrieve certain information such as:

the operating system

the browser

the Adobe PDF plugin

the Java Virtual Machine

the available signature certificates

Depending on the choices made during the specification phase, this information is used to:

check the technical capacity of the workstation to make a local signature

check the presence of a certificate issued by a trusted CA

If the answer is negative in the previous paragraphs, authorize or not the server signature according to defined criteria (country, user, context, e.g.)

Entity Signature

The document is signed by the server on behalf of TRACES with a TRACES certificate. This will certify that the document has been issued by the TRACES portal when the user signs the document in turn.

Server Signature

The purpose is to delegate to the trust platform the signature of the document on behalf of the user. This is useful if the user does not have a compatible workstation for the hardware certificate signature or if he does not have a hardware certificate.

The trust platform will then ask a PKI to instantly generate a limited lifetime certificate to perform the signature. When the signature is completed, the certificate's private key is destroyed.

In this case, the digital signature does not increase confidence in the identity of the signing party compared to login-password as authentication process is not hardened. It does however provide the same guarantees concerning document integrity as a client-side signature.

Workstation Client Signature

If the user has both a compatible workstation and a supported hardware certificate, the signature is made directly on the desktop, providing a higher signature quality.

A signing applet can both interact with the browser, the browser certificate store, the user workstation, etc. by providing the following functions:

presentation of the document to the user

filtering and identification of necessary certificates

collection of user consent

TRACES



signature with a hardware certificate

Public Key Infrastructure

The PKI is needed to instantly issue temporary certificates to sign documents on the server on behalf of the user.

3.3.2.2 Signature validation

The validation step for electronic signatures verifies the quality of the user signature regarding to the signature policy.

Verification of cryptographic signatures and certificates is carried out (validity of the issuing CA, LCR control...), and once the validation is completed, the proof of validation will be created.

3.3.2.3 Timestamping

The quality of the electronic signature implies the presence of time and date of signature (timestamp).

A trust platform must conform to the international standard RFC 3161, and must allow timestamp signatures and evidence generated during the signing process.

The platform must use a reliable time source. It may be time synchronized by GPS or NTP protocol.

3.3.2.4 Proof

The trust platform must create a comprehensive proof of the signature process with information on all the stages completed. It then sent the proof for storage in a digital safe.

The following data can be inserted into the proof:

the signed document or its hash (if the document is stored in document management system)

proof of document validation generated by the validation server

proof of user authentication

audit trails of transactions generated by the trust platform that lists all the steps of the process

The business metadata that can be added to proof

These signed and timestamped proofs are available in the event of a dispute, and 'replay' and check each step of signature and to find the elements that made it possible to carry out checks throughout the cinematic.

3.3.2.5 Electronic Safe

Once the proof is created, it must be archived in a digital safe guaranteeing its availability during the desired retention period.

The electronic safe is an infrastructure solution to securely store data requiring access control and traceability.

TRACES



The functions of security and trust provided by an e-safe are:

integrity of archived documents, thanks to the safe signature functions

confidentiality of these documents, by data encryption

traceability of actions performed (deposits, refunds, requests for copies ...)

sustainability of the data (proof, documents) with the periodic re-signing, which ensures a long term proof of quality

fine grained access control to digital documents

3.3.3 Trust platform challenges

3.3.3.1 Reliability and performance

These address the need for critical applications assuming high performance and high availability. The trust platform should be able to easily evolve in terms of:

scalability to support an increasing number of transactions

availability (Redundant architecture, load balancing, etc.)

settings

o Multiple policy (signatures, validation, archiving)

o Multiple applications

o Separation of users

o Managing Certification Authorities

o Algorithms signatures and hash

3.3.3.2 High security

Because the electronic signature is such a critical part of the TRACES system once digital document becomes the reference, it is necessary that the trust platform have a very high level of security and conformity

To ensure this security level, we must take into account the qualifications and certifications of the platform and its components such as:

EAL 3 + Common Criteria certification

National security agency validation (ANSSI in France, Bundesnetzagentur in Germany, e.g.)

Other national and international certifications

The platform must be continuously audited for such certifications, and also must be able to evolve quickly to address any detected security problems.

3.3.3.3 Ergonomics and flexibility administration

It should also ensure that the trust platform is easy to install, configure and operate. The ease of integration and the need not to disrupt the user experience are major issues for the success of such projects.

TRACES



3.3.3.4 Mutualisation

In view of long-term investment, the solution must be able to address all the needs of current and future dematerialisation processes.

It must evolve to serve more trust processes for diverse applications or future evolutions of the TRACES portal (plan control and certification e.g.).

3.4 Project plan

Deployment of eCertification requires a dedicated project to design signature process and to implement the technical platform. The following project plan identifies major tasks that are to be executed in order to deploy the solution.

3.4.1 Project specifications

This phase is focused on the conception of the signature platform, from both a functional and business point of view.

Set-up

Goal Structure the project

Tasks - Define project scope, organisation and management

Architecture design

Goal Define the functional and technical architecture

Tasks - Documents signature and validation processes

- Define integration methods between the trust platform and the TRACES portal

- Design technical infrastructure in which the trust platform will be installed (in terms of networks, servers, databases, security components…)

- Define deployment effort to secure solution deployment

Signature specifications

Goal Define the way signature will be implemented within the TRACES portal

Tasks - Define under what form the data needing a signature must be organized: for example, a file can be in text, XML, PDF or other formats

- Choose signature format (XAdES, PAdES, etc.) and type (simple signature, advanced, with timestamping, revocation lists included, detached, enveloping, enveloped, etc.)

- Define signature process within the usual webflow of the TRACES portal

- Define archiving process to ensure secure storage of signed documents and related signatures

- Design process to link users and certificates in order to be sure a given user use his certificate when he owns one

Certificates strategy

Goal Define the list of trusted certificate authorities and its update process

TRACES



Define the specifications of the internal PKI used for server-side signature

Tasks - Write down criteria a given certificate authority must respect in order to be trusted within the TRACES eCertification system (based on EU trusted list, best practices, international standards, etc.)

- Define internal PKI specifications for server-side signature

Trust policies

Goal Write down security documents needed for conformity

Tasks - Document signature policy, signature validation policy, timestamp policy

The purpose of a validation policy is to define the configurations for signature validation:

Certificate validation (verification of the certification steps, uses, extensions...)

Proof content (creation and archiving)

Response to the business portal

User roles

The purpose of a timestamping policy is to define the timestamp token configurations, which will be employed to certify the exact time of a signature validation or creation.

Eligibility matrix

Goal Define acceptable user workstation configuration

Tasks - Create the list of all operating systems, browsers, and plugins that will be supported

Once each of these aspects is chosen, the client station eligibility service can be configured. This service defines in which conditions the signature can be completed on the post. In case of a compatibly issue, the user is helped to solve this problem by himself.

Signature pages layout

Goal Design pages involving digital signature creation or validation or visualisation

Tasks - Design signature page layout (does it display the name and id of the document? a PDF view? etc.)

- Design signature validation page layout (what information are returned? Only the result or technical information?...)

- Define the way signature will be represented within the portal (a small green tick for a validated and signed document, a red exclamation mark when not signed or not validated e.g.)

3.4.2 Integration

This phase involves the implementation of the platform, its testing, and its go-live.

TRACES



Infrastructure configuration

Goal Install and configure physical infrastructure

Tasks - Install physical or virtual servers on which trust platform will be deployed

- Prepare network, database and system configurations

- Define monitoring processes

- Review high availability strategy

Trust platform setup

Goal Install and configure logical infrastructure (trust platform)

Tasks - Install trust platform software

- Creation and installation of technical certificates

- Configure software, roles, policies…

- Define application monitoring processes

- Setup and configure hardware security modules if needed

TRACES integration

Goal Implement the link between TRACES portal and trust platform Update TRACES pages that are impacted by digital signature

Tasks - Implement and configure technical integration of signature within TRACES portal

This integration phase will allow the TRACES portal to exchange with the trust platform. Depending on the solution, this interface will have a given technical formalism that TRACES system will have to respect.

For example, a trust platform can present a set of web services to the portal in order to exchange documents and signed document.

The usual flow involves a first call of the portal to the trust platform (in order to transfer the document to be signed) and a second and last call from the trust platform to the portal (in order to give the return of the transaction, which can the signed document or a flag with the return code of the signature operation).

From a user point of view this flow is transparent but involves a redirection from the portal to the signature page of the trust platform. The “URL redirect” is usually handled by the portal with standard technical requests such as HTTP 302 request.

- Code and deploy updated web pages (signature page, validation page, signature representation pages, etc.)

- Implement barcode library that will allow barcode generation when printing an electronic certificate

- Code and deploy user administration page that will allow to link one user and its certificate

TRACES



3.4.3 Deployment

In this phase, the service is launched for users (both internal and external), who are guided through the usage of the digital signature.

Deployment kit

Goal Prepare documentation for users and TRACES local administrators

Tasks - Document signature deployment help kit for users

- Document prerequisites checks and certificate validation process

- Prepare trainers support

- Update online help pages and user manual

Technical documentation

Goal Prepare technical documentation for TRACES EU administrators and operators

Tasks - Document trust platform management and operations

- Train administration and helpdesk team

- Document FAQ or helpdesk toolkit

3.5 Conclusion

The analysis of the operations and requirements necessary for the deployment of electronic certification highlight a number of positive elements concerning the implementation of this process. It is believed that these benefits will carry over to both the users and operators of the TRACES system.

For users, the solution can support the majority of workstations, with the simple addition of a Java component for example. About this technology, statistical analysis shows that the Java penetration rate on workstations is more than 77%.

In addition, concerning the signature method (electronic certificate), the prerequisites are not very restrictive. Any client signature certificate can be used. The step that requires the most time is the determination of a list of ‘trusted’ suppliers. To accomplish this, we recommend using the trusted list as established and updated by the European Union (DG INFSO - Directorate General Information Society).

Moreover, for public organisation, server-side personal signature would allow a free deployment for users who are not equipped with digital certificates.

For DG SANCO, the deployment is facilitated by a solution that integrates all of the security services. It is based on a project in itself, where the prerequisites are partially defined, but also relatively accessible. The required hardware infrastructure represents a limited investment. In addition, the technological choices for interfacing do not greatly affect the TRACES portal, meaning that it is possible to deploy a solution without changing the technical composition of TRACES. It is also possible to depend on the same technical foundation to streamline the infrastructure and the operational practices.

Finally, the preparation, conception and integration projects have been defined and can be completed by DG SANCO, or by a service provider that completes all of part of the tasks.

TRACES



4. PHASE 4: COSTS / BENEFITS ANALYSIS

It has been shown that eCertification must meet some business constraints that technological solutions can deal with and whom deployment will require to respect identified prerequisites. Last phase of the study aims at gathering and highlighting critical decision-making criteria to deploy eCertification within the TRACES system. These criteria are to be analysed through a costs / benefits analysis in order to establish a big picture of eCertification measured with usual indicators such as total cost of ownership and return on investment. This will give most of the needed information to reach the decision point.

4.1 Challenges and issues

This costs / benefits analysis will allow an informed decision if it identifies the most important challenges the eCertification must address. For instance, technical specifications of the solution have a role in the quality of the solution. But if the solution requires a disproportionate investment or if it is not ergonomic, technical side will eventually be less critical.

That is why analysis criteria have been defined to structure this last phase of the study.

4.1.1 Analysis criteria

The following criteria have been identified to answer any major questions EU and state-members may have when dealing with the deployment of eCertification.

Criteria Challenges & issues

Overall impact

- What are impacts for TRACES users and for EU administration, from the setup to the every-day use of eCertification? - How could it change the business of TRACES users? - What is the financial impact for both EU and users?

Achieved security level

- What is the security level of the solution regarding state-of-the-art? - Can it enhance veterinary certification chain integrity and reliability?

Technology maturity and acceptability

- Are technologies mature and normalised? - Are technologies compliant with EU strategic orientations?

Deployment approach

- Should eCertification deployment be progressive or big bang? - What is the critical path to a successful deployment?

4.1.2 Legal aspect

The legal aspects are crucial for the conformity of the eCertification system, as well as for acceptance among the users and the member states. However the adjustment of the reference texts for the authorization of eCertification falls under the European Union, and is not included in the range of this study.

Nevertheless it is important that this study defines the best approach for carrying out the legal aspects. This approach is based on the elements and information gathered during the completion of this study. The ultimate goal is to eliminate the use of paper, and to exchange electronic documents through the TRACES system. The steps to reach this goal must be

TRACES



progressive, and must, in particular, recognize the need to conserve paper documents in the daily activities of the certification chain actors.

Step 1: Acknowledge value of electronic documents

The first step is to recognize the value of the electronic document, in the case that the document is entirely created in the TRACES portal. The users must validate this approach and trust in the document production and validation system.

This involves imposing legal recognition on the digital signature, but not imposing systematic digital signature of every document.

This first step is critical for the general implementation of the eCertification: it is here that value is given to a document produced electronically, and that it has an electronic original version (meaning that the paper version is only a copy), and that will be validated through the TRACES portal (to validate the digital signature).

Step 2: Extend and generalise the use of the digital signature

The second step could be to complete the document signature using the TRACES system. In this process, only the electronic documents would act as proof, and the only way to legally validate a document would be to digitally sign it in the TRACES system.

Step 3: Remove paper versions of certificates

The third and final step would be the elimination of the paper document, thanks to various exchange and dematerialization techniques. This step relies on technological advances, but can also be partially based on the use of barcodes. This solution can be quickly integrated in the TRACES portal, and offers a reduction in the amount of paper employed.

As they are dependent on users habits evolution (when will they be ready to go “paperless” ?), steps 2 and 3 will need more time than step 1. After some years, users will be ready to go paperless and then technological solutions (tablets and smartphones for instance) will be more and more used in the everyday office life.

4.2 Analysis

4.2.1 Overall impact

There are two types of impacts to consider: one kind affects the users of the TRACES portal, while the other the European administration. For each of these types, the impacts are divided between impacts that relate to the preparation and collection of prerequisites, and the 'daily' impacts occurring once the solution is implemented and operational.

4.2.1.1 Impacts on DG SANCO

For DG SANCO, the implementation and the maintenance of the trust platform will be impacted. The aspects related to the implementation are detailed in 3.4, are also the subject of a project plan.

TRACES



The daily impacts concern the platform maintenance. Beyond the administration and operational technical phase, there is also an organizational part, which revolves mainly around two activities:

management of the digital certificates,

management of the helpdesk.

The management of the digital certificates requires the following activities:

Manage the internal PKI that is used for server-side personal signature (function handled by the trust platform, does not generate any specific costs for the administration),

Maintaining the trusted Certificate Authority identification and validation processes for the delivery of signature certificates to the TRACES users.

This second part consumes more time than the first part. It involves monitoring the various possibilities available on the international market, since the users stretch beyond the European Union. To structure this activity, the following process can be used:

The first task involves using the list defined by the European Administration (cf. 3.2.1.1). This can be done automatically on the trust platform.

The second task involves managing the certification authorities that are not on the list, but that can be contacted by users coming from third parties. To do this, and to avoid costs related to systematic analysis of certificate providers in the market, it is possible to define an analysis process for candidates recommended by users. Users send DG SANCO a given CA references and then the Administration validates, or not, the possibility of relying on the CA to generate a signature certificate.

The helpdesk management can constitute a cost for DG SANCO. During deployment, user requests will potentially increase, since the solution is new and users are not yet familiar with it. But eventually, the helpdesk should not be modified by the eCertification, since this will not have an impact on the daily activities of users.

It can be necessary to reinforce the helpdesk for several months during deployment, or to foresee training sessions and communications in order to avoid helpdesk requests.

Impacts for the European Administration are recognized, and generally mastered. Beyond the impact and the costs of the solution implementation, the maintenance over time requires very little effort. Moreover this effort should reduce as time passes.

4.2.1.2 Impacts on users

For users of the TRACES system, the impacts related to the prerequisites will depend on the chosen approach for the digital signature certificate. Based on the strategy outlines in 3.2.4, the impacts are as follows:

For economic operators, it is necessary to have an digital certificate that is compatible, as well as the associated smartcard reader. It could also be useful to have a barcode scanner.

For governmental officials, they will either already have a valid digital certificate, or they will user server-side personal signature. It is therefore unnecessary to invest in the two cases.

In addition, for all users, their workstation must be compatible with the configurations matrix supported by TRACES and the signature platform. This matrix must be as large as possible to include the majority of situations.

TRACES



Based on an estimation over 4 years, the following table illustrates the costs for an economic operator.

Prerequisites Annual fees Total over 4 years

TOTAL 150 € 100 € 550 €

Digital certificate - 100 € 400 €

Smartcard reader 100 € - 100 €

Barcode reader 50 € - 50 €

The daily impacts on the users are reduced because the digital signature solution is not intrusive as far as the business is concerned. First, users are already familiar with online applications since they use the portal on a daily basis. Then, the digital signature software will not greatly change the use of the portal.

The first daily impact for users is having a digital signature certificate. This is a question of habit for users that have never before implemented this kind of practice. It is probable that the use of smartcards will become more and more widespread.

The second impact concerns the users that manipulate documents, and want to verify their validity. For electronic documents, the validation is completed through the TRACES portal. It is therefore necessary that the users can access the Internet and the portal.

Note for users before acquiring certificates

Before economic operators or organizations purchase digital certificates, they will have to manage the digital certificate life cycle. Certificate management involves the risk that the certificate is expired when the user needs it. However this risk is reduced by certificate providers messages informing that the expiration date is coming. In addition, it is possible to integrate an alert in the TRACES portal when the expiration date is near.

The user impacts are therefore controlled and fairly reduced. The prerequisites are easily accessible, for both economic operators and governmental officials. Once the signature device (the digital certificate) is acquired, the daily usage of the TRACES portal will be barely impacted, since there is already a final page for signature and validation in the portal workflow.

4.2.2 Achieved security level

The issues of the eCertification security must be studied according to two separate aspects. The first concerns the security level of the solution itself. This solution must provide a high level of security, combining conformity (to regulatory frameworks and EU recommendations) and protection (against the most current attacks).

The second issue concerns not the solution protection methods, but rather the contributions that the solution provides for the business. Based on the nature of the digital signature, eCertification can be a method for improving the reliability of the entire veterinary certification chain, and in particular for increasing integrity of documents produced by the TRACES system.

In summary, the digital signature implemented with a qualified trust platform natively provides the benefits sought. The cost / benefit analysis is very positive, since the costs are only those of the solution: the security does not implicate any extra costs to fulfil the business needs.

To supply more details, the following table highlights the various benefits and the possible residual costs.

Benefits & Added value Costs & Prerequisites

Information Security

TRACES



Conformity with the regulatory framework for digital signatures in the EU

No supplementary cost beyond the solution. It is possible to deploy a solution for a legally valid signature, using a signature format that respects recommendations, by employing software certified by the 'Common Criteria'

Respect the recommendations of the Information Society

High level security thanks to the solution certification

Protection against attacks, and the ability to react in the event of an incident

Respect organizational procedures The digital signature, thanks to cryptographic mechanisms, natively supports a high level of security. There are nonetheless residual risks that require organizational protection.

Reliability of the certification chain

Reinforcement of document integrity No extra cost The digital signature natively supports protection thanks to cryptographic mechanisms that calculate imprints. These allow the detection of electronic document modifications.

Error reduction No extra cost The widespread use of electronic documents will help avoid interpretation problems for handwritten documents.

Fight against fraud Respect organizational procedures It is extremely complicated to forge a false electronic document or false digital signature. The digital signature is very reliable, and facilitates the signature validation operation.

The digital signature offers a high level of security and reliability. No known attack exists that jeopardizes the underlying cryptographic mechanisms, and that could permit the completion of a false signature.

Some risks do remain, such as those related to the chosen signature method (digital certificates) or to various technologies that are embedded in the technical solution. There are protection methods to mitigate these risks.

Risks Solution

Identity and certificate theft Increase user awareness concerning the importance of the digital certificate Use of certificates that are protected by a PIN code

Non-revocation of certificates Verification of the certificate validity and monitoring of the list of revoked certificates (CRL)

Use of signature keys that are too short, or that do not respect the recommendations

Expert guidance for the configuration of the technical solution

Security vulnerability in the client signature component that impacts a user work station

Monitoring and updating of technical prerequisites for user work stations Securing of work stations by either the users or the IT service

TRACES



4.2.3 Technology maturity and acceptability

The nature of the TRACES project implicitly defines constraints that the solution must fulfil on a technical point of view. The solution is meant to be used by a large number of users in numerous countries. In addition, the solution is implemented by the European Administration, and therefore will have to respect the strategic orientation as defined by different work groups, notably the Digital Agenda.

The technology must:

Be accepted by the various normalization instances,

Have been used with success in major projects,

Be future-proof,

Not require additional costs because of intellectual property.

Normalisation of technology

The technical solution will most likely depend on three key concepts: the digital certificate, the digital signature, and barcodes. These elements are all based on accepted technologies.

The digital certificates are defined in the ITU (International Telecommunications Union), which is in charge of the regulation and planning of telecommunications in the world. The format of the digital signature is defined by the ETSI (European Telecommunications Standards Institute), the European regulation organization in the telecommunications domain.

Technologies Standards and reference texts

Digital certificate x509

4 standard established by the International Union of

Telecommunications (certificate formats, organization of Certification Authorities, verification of certification paths)

Digital signature TS 101 903

5 Standard of the ETSI for XAdES signature

formats

Barcodes Barcode format defined by the GS16

Acceptance and conformity with European orientations

In addition to texts that are relative purely for standard organizations, technology linked to the digital signature is perfectly harmonious with the European Administration orientation.

Technologies Standards and reference texts

Digital certificate The 1999/93/EC

7 Directive on a Community framework

for electronic signatures (defining some constraints digital certificate must respect)

Digital signature

Directive 1999/93/EC on a Community framework for electronic signatures (defining the 'European' signature as opposed to the 'US' signature, cf. 2.3.2 – signature criteria) Commission Decision 2011/130/EU

8 establishing

4 http://www.itu.int/rec/T-REC-X.509

5 http://www.etsi.org/WebSite/Technologies/ElectronicSignature.aspx

6 http://www.gs1.org/barcodes

7 http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31999L0093:EN:NOT

TRACES

http://www.itu.int/rec/T-REC-X.509

http://www.etsi.org/WebSite/Technologies/ElectronicSignature.aspx

http://www.gs1.org/barcodes

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31999L0093:EN:NOT



minimum requirements for the cross-border processing of documents signed electronically by competent authorities

This perfectly matches the digital strategy priorities adopted by the EU institutions (The electronic signature – 7

th lever of the single market 2012 – Act for the Single Market of April 13,

2011).

In addition, cryptographic mechanisms and recognition by normalization instances demonstrate the sustainability of this kind of solution. Cryptography natively embeds mechanisms that ensure the value of the signature over time and reinforce signature and protection mechanisms should the algorithm become weakened (augmentation of the key size). In addition, the normalisation instances in question are supranational, international, or European authorities. Their projects can be used as a reliable reference.

There is no intellectual property issue links to these technologies. The solution has no related cost; the use of the technology is free. It should also be noted that, for example, the ETSI is a non-profit organization, and that the ITU is an agency that depends directly on the UN.

Successful deployments

These technologies are accepted by various user populations, and in different usage cases (public and private sphere, Europe, member states, etc.). For information, different examples are offered according to the usage context.

The following member states have been chosen to illustrate the use of digital certificates and digital signatures in the European Union:

Belgium,

Spain,

Estonia,

France,

Italy,

The Netherlands,

The United Kingdom.

The list is not exhaustive considering the growing number of projects and initiatives in this area.

Country Projects

Belgium Belgium.be : federal official portal (list of e-services) Tax-on-web : Online tax services

Spain Sede electronica : National initiative for e-gov services Agencia Tributaria : Online services for taxes and customs Ministerio de Justicia : Online birth certificate

Estonia Vabariigi Valimiskomisjon : Online voting Ettevõtjaportaal : Online business creation (with European eID validation)

France Banque de France : Compliance reporting for banks

Italy Progetto Carta Nazionale dei Servizi : Digital civil servant ID DigitPA : National agency for e-government

8 http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32011D0130:EN:NOT

TRACES

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32011D0130:EN:NOT



Netherlands

Digid.nl : National initiative for e-gov services Stichting Pensioenregister : online pension status service Ministerie van Landbouw, Natuur en Voedselkwaliteit : agriculture and farming

United Kingdom

CRC Registry : Environment agency e-services about carbon footprint HM Revenue & Customs : Online services for taxes and customs

In addition there are initiatives coming directly from the European Administration, such as the project of the European Publications Office for the signature of official European Community Journals, the SPOC project for a single point of contact for European procedures, and the STORK project for an interoperability platform for European eIDs.

In conclusion, the technology solution does not pose any particular risk. It does offer, among other things, the advantage of following the same direction as the EU initiatives and fulfilling the normalization and outline projects.

4.2.4 Deployment approach

The deployment is an important issue for TRACES, and reflects the traditional issues that face dematerialization projects. Dematerialization goes along with changes that impact the nature of the veterinary and economic operators business to varying degrees.

In addition, dematerialization depends on technical tools, which can be new for the users, and therefore potentially troublesome.

It is therefore necessary to define the level of change management for users, during the handover period for the eCertification functions. The main challenges for the integration in the deployment strategy choice are:

The capacity of users to be in conformity with prerequisite requirements, especially concerning the acquisition of digital certificates,

The handover and integration of the solution, for the DG SANCO administrators and for the users,

The different forms of resistance to the change, concerning countries and operators

The deployment can be based on a progressive approach, or on a 'big bang.'

A 'big bang' deployment consists of imposing the eCertification starting on a certain date. On this date, all users need to be in conformity with the prerequisites and employ the digital signature. The traditional advantages of this approach are related to its 'instantaneous' character for the widespread use of the solution: this maximizes the gains in efficiency, and reduces the costs for guiding users. The inconveniences are related to the respect for the prerequisites. On one hand, it is necessary to settle the questions concerning the updating of regulatory texts. On the other hand, it can seem difficult to find a date for the opening of the service (if the signature is mandatory) which allows all users to respect the prerequisites. Finally, the preparation efforts are more significant (translations for the online help, for example) and the risk of overloading the helpdesk is increased.

A progressive deployment consists of defining a reduced user population and a pilot user population to experiment with the eCertification. This population will be increased over time, when the correct functioning of the solution is validated. Eventually, the solution will be ready for use by all populations. The benefits of this approach revolve around securing the implementation: it is possible to monitor the user solution integration, and the different feedback collected during this period can lead to improvements during the deployment phase. Inconveniences with this approach are related to the costs of the support of end-users and the different associated forms of guidance.

TRACES



In the context of TRACES, it seems that the two approaches are possible: no constraint impedes either of the deployment strategies. It can therefore be beneficial to foresee an approach that combines the 'big bang' and 'progressive' deployments.

The ' big bang' offers the advantage of setting a delay, after which the users must conform to the prerequisites.

The 'progressive' approach secures the entire device (technical platform, support process, activity monitoring, etc.): this approach seems necessary considering the scope of the project, and based on the value of field feedback obtained during the experimentation phase.

The deployment planning could be as follows.

In summary, the deployment does not raise any blocking problems, as far as eCertification goes. It is possible to define a deployment strategy which facilitates the handover to the users by offering a calendar that is dynamic and optimized.

4.2.5 Cost analysis

The cost analysis detailed in this document is an estimation, for information purposes only. This analysis aims at giving a rough estimate of the total cost of implementing the solution over four years.

The costs were evaluated in the following manner:

Estimation of the cost of the 'building' phase of the solution, based on

Q1 Q2 Q3 Q4

M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12

Pro

ject

Ph

ases

Setu

pD

ep

loy

Gen

era

lise

Design

Integration &

testing

Identify

pilot users

Experiment

Deployment

kit

Validate

Fix & correct

Generalisation

Communication

kit

Communication & user support

Technical support & user helpdesk

TRACES



o An estimation of the cost of the software and hardware

o An estimation of the load corresponding to the solution implementation project

An estimation of the load corresponding to the training project for the deployment

Estimation of the cost of the 'run' phase of the software, based on

o An estimation of the cost of maintaining the software and hardware solutions

o An estimation of the cost of operating, support, and the helpdesk

Estimation of software and hardware costs

- The trust platform is estimated to be between 400 000 and 600 000 €.

- The annual software maintenance is between 90 000 and 140 000 €.

- 6 servers (unit price between 4000 and 5000 €, 2 test servers and 4 production servers, 2 of which are backup servers) and 2 Hardware Security Modules (unit price between 12 000 and 15 000 €), the hardware costs are estimated to be between 48 000 and 60 000 €.

- The annual maintenance for the hardware is between 7 000 and 9 000 €.

We deduce that:

- the cost of building the technical platform is estimated between 448 000 € and 660 000 €

- the maintenance cost of the platform is estimated between 107 200 € and 159 000 €

Estimation of the project costs

The platform implementation project (from the specifications until the opening of the production service) is estimated to take approximately 200 Man Days. It is estimated that around 50 Man Days will be necessary for deployment preparation.

The estimated cost of the 'project' is between 175 000 and 225 000 €.

Estimation of support and operation costs

These costs are divided between the technical operations of the platform, estimated to be a half day per week, and user support, estimated to need the time of one full-time employee.

The estimated cost is between 150 000 and 200 000 €.

Overall estimate

As the following table illustrates, the total cost of ownership, over four years, is estimated to be between 1.6 and 2.3 million euros. The average total cost should be around 2 million euros.

Build Run (1 year) TCO (4 years)

TOTAL 623 000 - 891 000 257 200 - 359 000 1 651 800 - 2 327 000 Hardware & Software 448 000 – 666 000 107 200 – 159 000 876 800 - 1 302 000

Project & Operation 175 000 – 225 000 150 000 – 200 000 775 000 - 1 025 000

4.3 Return on investment

The eCertification depends on technical components that increase the security level provided by the TRACES portal. The contributions of the eCertification stretch beyond the realm of Information Technology, to the entire business in general. For the cost / benefit analysis, it is

TRACES



beneficial to highlight the various types of ROI related to the implementation of the eCertification.

Measuring savings and earnings brought by dematerialisation can be a complicated task. The changes caused by the dematerialization often impact the entire business process, as for example in the case of veterinary certification. The main difficulty lies in the evaluation of the earnings. For example, with the example of the printing of a document, it is easy to say that it presents a financial saving (no more buying paper), as well as an organizational saving (less time is spent printing and manipulating the paper). While it is simple to measure the cost related to paper (by using a fixed price per sheet, for example), it is difficult to measure the amount of time that is related to the elimination of paper (how much time does printing and storing the documents take?). Because of this, it is therefore also difficult to measure the financial savings (depending on the employee salary, etc.).

In order to allow for a proper evaluation of the ROI, a two-phase approach is proposed. The first step involves identifying the ROI factors. In the second phase, the ROI areas are analysed and measured, when possible.

4.3.1 ROI factors

The ROI factors are defined as elements that introduce a gain for the users and for the European Administration. Once these subjects are identified, it is possible to study the ROI, according to which concrete gains will be possible. Three ROI factors have been identified for the eCertification in the context of TRACES.

Ergonomics

The eCertification allows for a focus on the usage of the TRACES portal. The users only employ one tool to process a health certificate, and the signature phase is simple and easily integrated in the TRACES program.

Increase in efficiency

The elimination of paper and signatures (by hand and with a stamp) offers an increase in efficiency for all users (economic operators and governmental authorities). The processing of a health certificate is more rapid (reading is accelerated by barcodes and printing time is saved).

Reliability

The eCertification increases the reliability of the certification chain thanks to a reduction of errors produced when entering information and when interpreting handwritten documents. It is also more reliable since it is impossible to forge an electronic document.

4.3.2 ROI areas

The three domains previously identified, and the nature of the transaction present concrete gains, which are presented according to the areas below.

Management of skills and HR organization

The eCertification presents an increase in efficiency, which must then be transformed by each actor. The first area of this increase in efficiency consists of examining the organization of the teams in charge of the certification chain. The actors can from then on consecrate their time to tasks that are more advantageous than the simple administrative functions. They can in particular refocus on the veterinary profession.

Evaluation of gains

TRACES



Based on the hypothesis of a 3 minute gain per certificate (related to the acceleration of the control and the entering of document information)

For information, the Roissy veterinarian centre handles 30,000 certificates per year.

The eCertification represents a gain of 90 000 minutes, or 1 500 hours per year, or more than 200 days of work per year.

The eCertification can represent the gain of a FTE (full-time employee) for a centre that processes 30 000 documents per year.

Fight against fraud, increase health security, and improve the well-being of the animal

Another area of optimization, aside from the increase in efficiency, involves consecrating some of the saved time to implementing more control points for the exchanged animals and merchandise. This increase in controls can lead to numerous advantages: improved techniques for combatting fraud, and the possibility of better controlling the well-being of the animals. In addition, the increased reliability will allow for improved health safety. It will be more difficult, or even impossible, to execute a false signature.

Reduced costs and financial gains

The optimization of HR presented in the previous section could be viewed as a source of cost reduction through the review of staffing in charge of document processing. It is up to each organization to implement this approach. The principal financial gain remains the elimination of paper.

Evaluation of gains

It is considered that the TRACES system will generate on average 1 million certificates per year. The certificates include on average 10 pages per document.

It is generally considered9,10

that the average cost for printing one page is between 0,07 € and 0,13 €, when using the most recently developed printers.

Eventually, the dematerialization of the paper certificates could represent a gain estimated between 700 000 € and 1 300 000 € per year.

Reduced carbon footprint

The elimination of paper allows for a reduction of the carbon footprint for the certification chain. This is in perfect accord with the 'e-Europe action plan,' which recommends the implementation of a 'simple paperless environment for customs and trade.' These gains are difficult to measure: the various studies seeking to measure the carbon footprint from one printed page give varying numbers, which in addition have to be weighed against the footprint of the additional hardware necessary for eCertification. The simple fact of being in accord with the European Administration can be perceived as a gain.

Facilitate and develop economic activity

The final advantage introduced by the eCertification is deduced from the gains in efficiency and the simplification of processes for economic operators. This modernization of administrative procedures leaves more time for enterprises to concentrate on commercial activities. It is

9 http://www.qualitylogic.com/tuneup/uploads/docfiles/QualityLogic-Cost-of-Ink-Per-Page-Analysis_EU_2-

Sep-2010.pdf 10

http://www.lasertekservices.com/blog/2010/11/cost-per-page-of-ink-jet-printers-%E2%80%93top-10-lowest-cpp-ink-jets.html

TRACES

http://www.qualitylogic.com/tuneup/uploads/docfiles/QualityLogic-Cost-of-Ink-Per-Page-Analysis_EU_2-Sep-2010.pdf

http://www.qualitylogic.com/tuneup/uploads/docfiles/QualityLogic-Cost-of-Ink-Per-Page-Analysis_EU_2-Sep-2010.pdf





difficult to calculate the gain in euros or in quantity of commercial exchanges, although this increase can be directly transformed into commercial activity.

TRACES



5. CONCLUSION

This study proved that the introduction of electronic certification in the TRACES system is possible. It focused on the first step of this introduction, which leads to give a reference value to electronic document and define TRACES as the reference system to produce, sign and manipulates these documents.

This step can be reached thanks to digital signature, the technical solution that offers security, compliance and trust to produce a digital mark of commitment on a digital document. Digital signature is more than a technical feature the TRACES must integrate. It involves digital certificates that user must have in order to sign a veterinary certificate. These prerequisites are clearly defined for both DG SANCO and TRACES users but it has been necessary to define the best way to help users to comply with them.

The deployment strategy defined in the study takes into account several contexts of use as well as the differences between economic operators and administration employees. Based on a software platform that would provide the expected features (on a business and on a technical basis), this strategy aims first to reduce and simplify prerequisites and then to allow a smooth but time-framed deployment

The very first step of the overall deployment strategy is to update legal and reference texts in order to allow veterinary certificates to be digitally signed. It is not included in the scope of this study and it would have to be discussed with member states.

But, during that phase, it is possible to define and prepare the solution, as the market proposes software that has been deployed in critical contexts for both private and public companies and that can meet every identified constraint.

This way, TRACES portal could comply with Europe Digital Agenda and could embody a positive message for e-Signature and e-Administration projects. It would be an opportunity for DG SANCO to take part in the modernisation of European administration processes thanks to a project that costs and benefits analysis proved to have an interesting and tangible ROI.

TRACES



TRACES



6. APPENDIXES

6.1 Appendix 1 – Interview guide


What user group do you represent?

What are the major program functions that you use?

How many users are you responsible for?

Do you know the number of product certificates for each user group?

Do you know when your peak work load and or peak solicitation periods will be?

What is the life cycle of a paper certificate?

Does the system TRACES meet your needs?


Does the possibility of creating a dematerialized paper process appeal to you?

Should the dematerialization be applied across the TRACES user spectrum (private operators, public service, just within the European Union, or in third countries as well)?

What do you expect to come from this project?

What are your main apprehensions?

According to you, which players would potentially use the electronic signature?

Is a 100% electronic process feasible? Do you think that in the end paper is necessary?


What is the most up to date / current technical environment / configuration?

Are there technical environments specifically for mobile or 'industrial' environment use?

Should you access other applications before or after a TRACES user session? Do you access TRACES through a portal?

Do you use electronic certificates? If yes, under what form/ what type?

Do you have a "re-materialization" operation? If yes, which one?

Do you already have experience with electronic certificates and / or dematerialization, whether personally or professionally?


Who would be responsible and what decision process would be followed in order to pursue a technological innovation relying upon the use of TRACES material or software?

Are there organizational or technical frameworks to respect in the event of evolution (ISO standards, RGS, etc.)?

Does the use of TRACES represent a cost for your organization?

In your opinion, who should be responsible for costs associated to evolutions / developments?

TRACES



What returns on investment would be expected (in terms of profit, man-days, security and integrity, saved time, confidentiality, etc.)?

6.2 Appendix 2 – Interview minutes

Interview minutes are presented for each visited country according on the following agenda.

Date Country City Type


22/02/2011 France Paris LVU lead

23/02/2011 France Roissy BIP

24/02/2011 France Le Havre BIP

07/03/2011 Italy Roma, Pisa, Livorno CCA, BIP

24/03/2011 Germany Hamburg BIP

28/03/2011 Slovenia Obrezje BIP

01/04/2011 Belgium Brussels, Zaventem CCA, BIP

TRACES



6.2.1 Belgium

Projet TRACES - Phase 1 Interview : BIP Zaventem - Vendredi 1 Avril 2001

Votre utilisation du système TRACES Quelle population d'utilisateurs représentez-vous ?

□ Opérateurs économiques (EO) □ Autorités Centrales Compétentes (CCA) □ Autorités Vétérinaires Locales (LVU) Points d'Inspection au Frontière (PIF) ou Border Inspection Post (BIP)

Quelles sont les fonctionnalités majeures que vous utilisez ?

Certification [INTRA / IMPORT / CVED / EXPORT] Notification Aide à la décision □ Enregistrement des contrôles -Douanes - Tarification

Combien d'utilisateurs avez-vous sous votre responsabilité ?

Vétérinaires du PIF et OE de l'aéroport de Zaventem

Connaissez-vous le nombre de certificats produits par les différentes populations d'utilisateurs ?

n/a

Avez-vous connaissance de pic de charge ou de période de forte sollicitation ?

Présence de quelques pics saisonniers (vacances, été, fin d'année).

Quel est le cycle de vie du certificat papier ?

- Premier volet du certificat préparé par l'opérateur économique et validé et signé par le vétérinaire. - La particularité du cycle est le lien avec la Douanes : le dédouanement est réalisée en parallèle par l'opérateur économique et doit être finalisé au moment de la finalisation du DVCE (pour des raisons de taxe douanières reversées aux autorités vétérinaires).

Le système TRACES convient-il à vos besoins ?

Oui, deux remarques cependant : - gestion des statistiques (la possibilité d'accéder au DWH était ignorée des équipes jusqu'à la visite). - besoin d'un suivi local parallèle au système, pour gérer notamment les taxes de dédouanement.

TRACES



Votre point de vue sur la dématérialisation La perspective de dématérialiser le certificat papier vous semble-t-elle intéressante ?

Oui : cela permet dans un premier temps une double économie par rapport à la réduction du papier : sur le plan financier compte-tenu du coût du papier et de son stockage et sur le plan de la productivité compte-tenu du temps consacré à manipuler le papier.

La dématérialisation doit-elle s'appliquer à tous les types d'utilisateurs de TRACES (opérateurs privés, service public, à l'intérieur de l'UE seulement ou pour les pays tiers également)?

A priori oui, le succès de la dématérialisation passe également par une adoption par tous les acteurs de la chaine.

Avez-vous des attentes vis-à-vis de ce projet ?

Les attentes sont les gains présentés ci-haut et tournent principalement autour des économies liées à la réduction du papier. Cela peut également permettre une augmentation du niveau de sécurité et éviter certaines fraudes.

Quelles sont vos principales craintes ?

Pas de crainte fondamentale vis-à-vis du projet. D'une manière plus générale, l'emploi de la carte d'identité comme moyen de signature dans un contexte professionnel peut éventuellement amener une question de gestion de la vie privée (Remarque Dictao : cependant le vétérinaire signe en son nom propre et non au titre de son organisation).

Selon vous, quels acteurs disposeraient de la signature électronique ?

A priori tous.

Le tout électronique est-il envisageable ? Le papier vous semble-t-il malgré tout nécessaire ?

Le papier est encore nécessaire dans un premier temps, et ceux pour deux raisons principales : d'une part certains pays tiers ont des difficultés d'ordre logistique et technique pour utiliser systématiquement un outil comme TRACES, et d'autre part le papier est pratique pour les contrôles.

Votre environnement technique Quel est l'environnement technique le plus courant ?

Poste de travail traditionnel (Windows, Internet Explorer) et Imprimantes

Y a-t-il des environnements techniques destinés à l'usage en mobilité ou dans un environnement "industriel" ?

Non.

Devez-vous accéder à d'autres applications avant ou après une session d'utilisation de TRACES ? Passez-vous par un portail pour accéder à TRACES ?

Non, sauf le fichier de suivi local (base de données MS Access partagée) pour des raisons de suivi locale.

TRACES



Disposez-vous de certificats électroniques ? Si oui, sous quelle forme ?

Carte d'identité Belgique

Disposez-vous de dispositif de "re-matérialisation" ? Si oui, lesquels ?

Non

Avez-vous déjà l'expérience de la certification électronique et / ou dématérialisation, à titre personnel / professionnel ?

Pas d'expérience à titre professionnel; expériences en tant que citoyen avec l'eID.

Votre organisation face aux évolutions potentielles Quel acteur / cycle décisionnel serait engagé en cas d'évolution technologique nécessitant le déploiement de matériel ou de logiciel liés à TRACES ?

Problématique non maitrisée par les acteurs rencontrées, du ressort de l'AFSCA.

Y a-t-il des cadres organisationnels ou techniques à respecter en cas d'évolution (normes ISO, RGS, etc.) ?


L'utilisation de TRACES représente-t-elle un coût pour vos organisations ?


Qui devraient à votre avis prendre en charge les éventuels coûts associés à une évolution ?


Quelle serait la nature du retour sur investissement attendu (€, JH, temps gagné, sécurité et intégrité, confidentialité etc.) ?

Gain de temps principalement.

Sujet complémentaires abordés durant l'entretien

TRACES



- Lien avec le processus de dédouanement. - Remarque d'ordre général sur le manque de temps des agents pour se former à TRACES et découvrir l'outil : seules les fonctionnalités utilisées couramment au quotidien sont connues, les autres possibilités ne sont même pas "explorées" par manque de temps. Cet élément est à prendre en compte pour le déploiement de la certification électronique.

Projet TRACES - Phase 1 Interview : Andrée Roels, Transitaire de la société ADELANTEX - Vendredi 1 Avril 2001


Opérateurs économiques (EO) □ Autorités Centrales Compétentes (CCA) □ Autorités Vétérinaires Locales (LVU) □ Points d'Inspection au Frontière (PIF) ou Border Inspection Post (BIP)


Certification [INTRA / IMPORT / CVED / EXPORT] Notification Aide à la décision Enregistrement des contrôles

Combien d'utilisateurs avez-vous sous votre résponsabilité ?

Moins de 15 personnes (employées de la société, qui partagent un même compte).


n/a


n/a


- Cycle de vie traditionnel du DVCE : le premier volet est préparé par le transitaire, sur la base des documents sanitaires reçus de l'expéditeur. - Le processus s'effectue en parallèle du processus de dédouanement via l'application PLDA.


Oui, le système est très bien perçu. D'une manière générale le transitaire s'adapte au système puisque la création de certificats est au cœur de son activité profesionnelle.

TRACES



Votre point de vue sur la dématérialisation La prespective de dématérialiser le certificat papier vous semble-t-elle intéressante ?

Oui, cela permet un gain de temps (plus besoin de se déplacer pour transmettre une liasse de documents).


Oui.


- La dématérialisation doit inclure les documents associés au DVCE (facture, lettre de transport aérien). Sinon ces documents seront à transmettre en version papier et seront accompagnées d'une réimpression du DVCE. - L'authentification doit être pratique : une carte à puce peut être oublié par un employé, un certificat logiciel partagé par l'équipe (le même sur chaque poste) semble plus adapté.


Crainte d'une complexification des processus actuellement rôdés (authentification trop complexe, sécurisation trop "couteuse" en temps et peu ergonomique).


A priori tous.


Oui (sur la partie du processus dont le transitaire est responable)


Poste de travail traditionnel et Imprimantes


A priori non. TRACES




A priori non.


Sujet non abordé en séance.



Avez-vous déjà l'expérience de la certification éléctronique et / ou dématerialisation, à titre personnel / professionnel ?



L'entreprise.

Y a-t-il des cadres organisationnels ou techniques à respecter en cas d'évolution (normes ISO, RGS, etc) ?

Non.


Oui mais il est intégré aux charges de l'entreprise.


L'entreprise doit s'adapter aux évolutions de TRACES puisque c'est un outil de travail incontournable et nécessaire à son activité quotidienne.

Quelle serait la nature du retour sur investissement attendu (€, JH, temps gagné, securité et integrité, confidentialité etc.) ?

Gain de temps et donc possibilité de traiter davantage de clients, donc gain financier in fine.

TRACES



Sujet complémentaires abordés durant l'entretien n/a

Projet TRACES - Phase 1 Interview : Alain Leroy et Equipe AFSCA / FAAV - Vendredi 1 Avril 2001


□ Opérateurs économiques (EO) Autorités Centrales Compétentes (CCA) Autorités Vétérinaires Locales (LVU) □ Points d'Inspection au Frontière (PIF) ou Border Inspection Post (BIP)


Certification [INTRA / IMPORT / CVED / EXPORT] Notification Aide à la décision Enregistrement des contrôles

Combien d'utilisateurs avez-vous sous votre responsabilité ?

Sujet non abordé directement en séance. Agence centrale en charge du "pilotage" de l'utilisation de TRACES.









Votre point de vue sur la dématérialisation

TRACES



La perspective de dématérialiser le certificat papier vous semble-t-elle intéressante ?

Sur le principe la démarche est intéressante mais elle se doit de prendre en compte les projets en cours et à venir au niveau local.


A priori oui.


- Prendre en compte l'ensemble des acteurs concernés par les documents manipulés au sein de TRACES - S'intégrer avec les projets comme FoodWeb et prendre en compte les besoins d'AdminLight


- Périmètre de la dématérialisation trop restrictif vu de la Belgique - Contraintes trop fortes imposées par la Commission


A priori tous.


Tant que faire se peut, cependant certaines étapes des processus nécessitent le recours au papier, notamment parce que des processus tiers exigent une version papier du certificat. Ce point souligne le besoin d'une approche globale : si le papier doit disparaitre il faut offrir des "passerelles" pour amener le document électronique aux autres systèmes.




- La problématique du poste de travail des vétérinaires en charge des contrôles (pour les certificats INTRA) a été abordée. Le vétérinaire doit-il disposer d'un équipement portable pour accéder à TRACES ou peut-il utiliser le matériel de l'opérateur économique ? - Le choix de se reposer sur le matériel de l'opérateur évite un engagement fort de l'administration vis-à-vis des vétérinaires (engagement financier et engagement de responsabilité si par exemple le matériel fourni intègre un moyen d'accès à TRACES type clé 3G) mais nécessite une bonne sécurité et une confiance dans le fait d'utiliser sa carte d'identité sur un matériel a priori inconnu.


Oui - Adminlight pour les vétérinaires "chargés de mission" (en charge des contrôles pour la certification INTRA), - Potentiellement Foodweb dans le futur et Sanitel (pour la liste des moyens de transport)

TRACES




Oui, carte d'identité.


Oui, dans le cadre de la gestion des échantillons à destination des laboratoires, un système de lecture de code-barres est déployée pour le suivi des échantillons. Il s'agit du projet LIMS (Laboratory Information Management System).


Oui, authentification forte par carte d'identité pour Foodweb (pas de signature électronique).


- Les différentes équipes de l'AFSCA seraient engagés, pour les différents aspects impactés (fonctionnels et techniques).


Oui, le projet doit respecter le cadre défini par l'ICT, notamment en terme de qualité et de sécurité (démarche ISO, processus de test et d'acceptance, etc.)


Oui, elle s'intègre dans l'ensemble des projets et programmes et des évolutions imposées pour TRACES peuvent impacter les différents travaux de l'AFSCA.


L'AFSCA peut prendre à sa charge des évolutions et souligne que tout aide (financière, humaine, etc.) de la Commission Européenne est bienvenue.


- Gain en matière d'interconnexion et d'intégration avec les systèmes tiers, - Mutualisation des efforts, - Augmentation de la fiabilité et de la sécurité (lutte contre la fraude).


TRACES



- Un point d'attention a été formulé concernant le référentiel des utilisateurs : la grande liberté accordée par le système peut mener à des doublons ou des utilisateurs inconnus (si un utilisateur est crée à distance par un OE d'un autre Etat, il n'est pas possible de maitriser la qualité des informations et dans certains cas leur véracité).

6.2.2 France

Projet TRACES - Phase 1 Interview Bruno Saimour of Wednesday 16 February 2011

Votre utilisation du système TRACES

TRACES



Quelle population d'utilisateurs représentez-vous ?

□ Opérateurs économiques (EO) □ Autorités Centrales Compétentes (CCA) □ Autorités Vétérinaires Locales (LVU) Points d'Inspection au Frontière (PIF) ou Border Inspection Posrt (BIP) - Il faut noter qu'en France, l'ensemble des PIF spécialisés en contrôle sanitaire sont regroupés au sein d'un service à compétence nationale (le SIVEP). Cette centralisation permet une mise en application harmonieuse des directives européennes. Cela permet aussi une bonne interaction et une bonne participation aux initiatives de la Comission Européenne. Cependant ce modèle d'organisation n'est pas systématique, ni en Europe (cas des Länder allemands par exemple), ni pour d'autres acteurs de la filière en France (cas des LVU). - Les PIF n'en réfèrent donc pas au Préfet en cas de question sanitaire sur un lot ou une marchandise. Les décisions sont prises à un échelon national, par le SIVEP, qui bénéfice d'une vue globale. - L'outil TRACES est devenu l'outil quotidien des agents des PIFs. Certains pays (les Pays-Bas, l'Allemagne, l'Espagne, la Grande Bretagne par exemple) utilisent également un outil à compétence national; une double saisie ou une intégration automatique complexe est nécessaire. Le principal argument pour le maintien de 2 systèmes en parallèle, celui de TRACES et celui national, est technique : ergonomie de saisie, couplage à d'autres applications nationales (douanes, etc.)... De plus, certains états ou régions préfèrent garder la maitrise de leurs outils informatiques. Le système TRACES permet une arborescence dans la gestion des droits d'accès : - L'Union Européenne donne les droits aux organismes nationaux (en France le SIVEP) - Le SIVEP donne les droits aux PIFs - Les PIFs donnent les droits aux transitaires


Certification [INTRA / IMPORT / CVED / EXPORT] □ Notification □ Aide à la décision □ Enregistrement des contrôles

TRACES




- PIFs en France : de l'ordre de 100 utilisateurs officiels. - Transitaires : le nombre exact d'utilisateurs transitaires est difficile à évaluer. On distingue 2 populations types : les professionnels et les particuliers. -- Pour les professionnels, la déclaration à l'avance est obligatoire et au minimum 24h pour les animaux vivants. Les transitaires sont des professionnels spécialisés dans les activités et procédures d'importation (préparation des certificats et des contrôles, interactions avec les douanes et les services vétérinaires, payement des frais). Ils sont le représentant légal des lots qu'ils font certifiés. -- Pour les particuliers, les obligations de déclaration sont identiques mais cette population d'utilisateurs n'a pas accès à TRACES. L'entrée dans le système TRACES se fait par le PIF concerné.


- Sujet non abordé directement en séance


- A Roissy, le nombre de signatures de CVED peut monter jusqu'à 200 par heure.


- On retrouve le cycle de vie des certificats "IMPORT" et "CVED". * Les transitaires ont l'obligation de déclarer à l'avance et remplissement donc la première partie du CVED (page 1), purement déclarative mais signé par le transitaire. * Ce document est imprimé et doit être joint des certificats sanitaires (les originaux) des lots importés. * Ces éléments sont présentés au PIF qui se chargent des contrôles. Ceux-ci sont formalisés via la seconde partie du CVED (page 2), signé par le vétérinaire compétent. * Le CVED doublement signé (pages 1 et 2) accompagne la marchandise jusqu'au premier destinataire. * Le CVED est archivé par le destinataire au minimum pendant la durée de vie du produit/lot. L'IMPORT est archivé 3 ans par les PIFs. * Les autorités certificatrices des pays tiers génèrent les certificats sanitaires (via les fonctionnalités de certificat d'IMPORT) et les signent. Ces certificats transitent avec la marchandise (sauf en cas de voyage maritime où elles sont généralement envoyées par courrier) et sont présentés aux PIF par les transitaires.


- Oui pour le volet "Certifications". Le CVED joue également un rôle majeur pour le dédouanement obligatoire des toutes les marchandises. - Un axe d'amélioration porterait sur la capacité du système à mettre des informations à disposition pour faciliter statistiques et analyses (en cas de clauses de sauvegarde par exemple). Les utilisateurs pourraient ainsi plus facilement s'approprier les données contenues au sein du système. - Il faut noter que le système TRACES a été très bien accueilli en France, puisque le pays ne disposait pas d'un système national remplissant ce type de fonction. Le système TRACES a permis également une mise à jour en temps réel des informations légales, sanitaires, etc. qui accompagnement le certificat. De plus le système a permis d'aider les autorités certificatrices des pays tiers (aide au choix du bon certificat) et il a permis de s'affranchir de la barrière de la langue (application multilingue).

TRACES




La prespective de dématérialiser le certificat papier vous semble-t-elle intéressante ?

- La signature électronique, comme possibilité de d'augmenter la valeur probante du certificat au format électronique, serait un avantage certain. L'utilisation du papier peut parfois donner lieu à des situations impactantes pour les opérateurs économiques (une petite erreur sur un document papier doit donner lieu au refus du lot) voire des situations délicates pour les autorités (un lot refusé contenant des animaux vivants ne peut parfois pas être bloqué trop longtemps pour des raisons de bien-être animal). - D'une manière générale, la dématérialisation, comme axe de suppression du papier, serait un plus pour s'affranchir des coûts, des lourdeurs du papier et de la rigidité que ce format peut imposer en matière de contrôle et de refus de lot (exemple : écriture non lisible).


- Sujet non abordé directement en séance (cependant l'échange a montré que le déploiement peut être progessif mais la dématérialisation pourrait être généralisée).


La signature électronique devra permettre : - Apporter la valeur probante aux informations contenues dans TRACES, et garantir une "chaîne de confiance" du certificat électronique - Gain de temps - Augmentation de la fiabilité grâce à la généralisation de l'électronique De façon plus général, l'application TRACES devra permettre : - Extraction de données statistiques (par exemple : Business Objects permettant de créer ses propres requêtes) pour répondre à des demandes du Ministère ou d'auters autorités nationales (par exemple : le Système d'Information de l'Alimentation) - Peut-être une généralisation de l'utilisation de TRACES par les différents opérateurs économiques

TRACES




- Dans certain PIF, les techniciens préparent les certificats qui sont ensuite tous signés par le vétérinaire compétent : -- Les techniciens se connectent sur TRACES via un compte utilisateur générique, remplissent en ligne le certificat pour chaque lot de marchandise et impriment les certificats. -- Le vétérinaire récolte tous les certificats imprimés, les contrôle et les signent un par un "à la façon parapheur". - L'introduction de la signature ne doit pas introduire une lourdeur vis-à-vis de cette répartition des tâches. - Par ailleurs toutes les évolutions doivent se faire en prenant en compte le contexte d'utilisation du systèmes : ainsi au sein d'un PIF, l'outil informatique est souvent placé au sein d'un environnement ouvert et partagé de type "open space". - Enfin, dans le cas des utilisateurs au sein des autorités certificatrices des pays tiers, il faut intégrer à l'étude la grande disparité en matière d'équipement. Certains pays sont très avancés et disposent de système mature (exemple : la Nouvelle Zélande); certains pays ne dispose pas d'ordinateurs et font que certificats manuscrits.


- Les textes imposent une signature personnelle réalisée par le vétérinaire compétent. - Cependant une opération de "préparation" de la signature pourrait être intéressante pour garder la fluidité existante du processus de préparation des CVED.


- Pour l'heure, il y a un besoin de papier entre le PIF et le destinataire du lot. Ceci s'explique par l'absence de postes informatiques chez certains destinataires (empêchant un accès à TRACES de l'inspecteur officiel) ainsi que par la question du contrôle routier par un représentant des forces de l'ordre. - Cependant il pourrait être envisageable de faire évoluer certaines pratiques pour tendre vers le "tout électronique".

Votre environnement technique

Quel est l'environnement technique le plus courant ?

- La connaissance des environnements techniques ne concerne que les postes installés dans le PIF. L'équipement des transitaires est de leur propre responsabilité. - Il n'y a pas de socle matériel ou logiciel strict. Cependant le schéma directeur du MAAPRAT impose Firefox comme navigateur Internet.


- A priori non, les PIF ne sont pas nécessairement bien dotés en matière d'outils informatiques.


- Non


- Il est possible que les agents du ministère disposent de certificat électronique dans le cadre de la signature de courrier électronique.

TRACES




- Les agents au sein de PIF disposent a priori tous d'imprimantes traditionnelles. - Ils ne sont a priori pas équipés en dispositif de lecture de code-barres ou de code 2D par exemple.


- Signature de courrier électronique

Votre organisation face aux évolutions potentielles

Quel acteur / cycle décisionnel serait engagé en cas d'évolution technologique nécessitant le déploiement de matériel ou de logiciel liés à TRACES ?

- Il faudrait prendre en compte le lien entre les PIF et les LVU : en matière d'équipement information les PIF dépendent des LVU et ne sont pas toujours les mieux dotés. - Bien que TRACES dispose d'un Helpdesk centralisé à Bruxelles, des formations sont souvent bienvenues. Un manque d'agent formateurs pour les PIFs est cependant souligné.


- Il serait intéressant de se rapprocher de la MOA au sein de la DSI du Ministère.


- Sujet non abordé directement en séance


- Pour les utilisateurs au sein de PIF, les dépenses pourraient être assumer par le Ministère.


- Principalement des gains de temps et de qualité au sens large (sécurité, fiabilité, statistiques notamment)


TRACES



- La relation avec les Douanes est intéressante à étudier dans le cas de la France. La fonction première du CVED est le dédouanement, qui peut avoir lieu soit au niveau PIF soit au niveau du premier destinataire du lot. Les Douanes s'assurent que les marchandises importées ont été contrôlés. - Les Douanes Françaises disposent d'une solution de dématérialisation du dédouanement via le système DELTA (Dédouanement En Ligne par Transmission Automatisée). Les opérateurs économiques peuvent s'y connecter pour réaliser cette opération. Cependant le dédouanement ne remplace pas les contrôles sanitaires (volet 2 du CVED). - Pour simplifier les opérations, une interface entre DELTA et TRACES a été mise en oeuvre : lorsqu'une opération de dédounament est initiée, l'opérateur économique peut renseigner dans DELTA le numéro du CVED préalablement généré dans TRACES. DELTA se charge alors d'interroger TRACES pour vérifier la validité du CVED et permettre de finaliser le dédouanement.

Projet TRACES - Phase 1 Interview Régis Raffin of Wednesday 16 February 2011



Opérateurs économiques (EO) : Le BICMA interagit avec les OE qui importent et exportent des animaux et produits d'originale animale dans l'Union Européenne. Il peut s'agir d'éleveurs (départ du flux d'exportation) ou par exemple d'abattoirs (arrivée du flux d'importation). Autorités Centrales Compétentes (CCA) : Le BICMA est une Autorité Centrale Compétente et, à ce titre, s'occupe la gestion des comptes utilisateurs TRACES, des requêtes et de l'extraction de données et de l'assistance aux LVU. Autorités Vétérinaires Locales (LVU) : Le BICMA représente et pilote les LVU (Direction des Services Vétérinaires) en France. □ Points d'Inspection au Frontière (PIF)




- LVU : 1 DSV par département donc environ 100 utilisateurs au total => l'évolution du modèle organisationnel vers les "Vétérinaires Certificateurs" (cf. Sujets Complémentaires) va faire augmenter ce chiffre (de 400 à 800 vétérinaires à la cible) - EO : environ 1200 utilisateurs


- De l'ordre de 90 000 certificats INTRA "FR -> Pays membres" dont 45 000 pour les bovins (par an) - De l'ordre de 40 000 certificats INTRA "Pays membres -> FR" (par an) - Pour les bovins ces 45 000 certificats représentent plus d'un million d'animaux, ce qui correspond à une valeur marchane de plus d'un milliard d'euros.

TRACES




Sujet non abordé directement en séance


- Le processus commence par la visite d'un vétérinaire privé qui va réaliser une première visite. Ceci est l'étape préalable à la certification, ou plus précisement, à la préparation du certificat par l'opérateur économique. - Puis le certificat est complété et finalisé par le LVU et il est remis à l'opérateur économique. - Ce dernier confie le certificat INTRA au transporteur. Le certificat doit alors accompagner les animaux jusqu'à leur destination. Si les lots sont décomposés, alors de nouveaux certificats sont mis au point et une copie du certificat initial est jointe au nouveau certificat. - Le nouveau modèle avec des "Vétérinaires Certificateurs" consiste à assermenter des vétérinaires privés pour qu'ils soient en mesure de signer le volet actuellement à la charge des LVU dans un certificat INTRA. Ce modèle va permettre de réaliser les contrôles sur place, au plus proche des animaux, et permet de combiner "visite du vétérinaire privé" et "passage au LVU pour certification".


Certains axes d'amélioration ont été abordés lors de l'entretien : - la disponibilité du système et de son datawarehouse pourraient être améliorées, - les fonctionnalités de requêtage pourraient être enrichies, et la fraicheur des données du datawarehouse améliorée, - les fonctionnalités d'aide à la décision (aide à la certification) pourraient être améliorées compte-tenu de la complexité et des évolutions réglementaires courantes. Sur ce dernier point la France (le BICMA) a mis au point un outil d'aide à la certification destinée à assister les vétérinaires dans leur utilisation quotidienne de TRACES. Ce système est déclinée selon la nature du flux (export : EXP@DON / import : IMP@DON). Il permet une aide pour une utilisation en parallèle du système TRACES (il ne se positionne ni en remplacement ni en "amont" comme peut le faire l'outil mis au point par le Royaume-Uni).


TRACES




La dématérialisation du certificat est perçue de manière positive, d'autant plus qu'elle va dans le sens d'autres initiatives en matière de dématérialisation. En effet la France est en cours d'étude de possibilités de dématérialiser le passeport bovin et les attestation sanitaires à délivrance anticipée (ASDA). Ces projets s'appuient sur un corpus réglementaire européen mais sont des initiatives nationales. Il faut noter qu'un document comme l'ASDA a une portée nationale. En cas de passage de la frontière, certaines informations contenues dans l'ASDA doivent être renseignées dans le certificat. Ceci est réalisé de façon manuelle pour le moment. La dématérialisation doit être abordée de bout-en-bout, pour permettre par exemple ce flux d'information continu "ASDA -> Certificat INTRA".


Idéalement la dématérialisation doit être accessible à l'ensemble des acteurs de la filière, pour permettre justement une dématérialisation de bout en bout et réduire au maximum le recours au papier. Les différents usages (notification de mouvements d'animaux) déjà en place ont accéléré l'équipement des opérateurs économiques; de fait, ils seraient également candidats à être acteur de la dématérialisation.


- La dématérialisation doit permettre de disposer du certificat dans TRACES dès le départ des animaux : la certification doit être concomittante aux mouvements d'animaux. - La solution envisagée doit permettre de disposer du certificat papier comme solution de secours, ne serait-ce que pour les acteurs non équipés de l'outil informatique.


- Les initiatives en matière de dématérialisation et le modèle des Vétérinaires Certificateurs va augmenter le nombre d'utilisateurs du système et donc introduire une nouvelle population (d'une taille non négligeable) à accompagner et à assister dans la certification électronique.


Tous les acteurs concernés par le processus de certification (EO, LVU, CCA)


- Le tout électronique est envisageable et souhaité dans la mesure où la dématérialisation concerne toutes les chaines. - Cependant le papier doit subsister comme solution de secours.


TRACES




- Dans les LVU comme chez le EO, les postes informatiques sont principalement des postes de travail "classiques". - Il faut noter que l'équipement des LVU est soumis au schéma directeur du Ministère. A ce titre, le navigateur internet est Firefox, par exemple. - Les LVU ne disposent pas nécessairement de lecteur de code-barres : il n'y a pas eu de politique nationale d'équipement mais certains acteurs se sont équipés directement. - En ce qui concerne les EO, le taux de pénétration de l'outil informatique est très bon, notamment après la possibilité de notifier par voie électronique les mouvements d'animaux. Ils disposent d'outils informatiques et également de lecteurs de code-barres. - Certaines populations d'EO disposent d'outil "professionnel" pour répondre aux besoins de notification des mouvements d'animaux à la BDNI : ces outils ont été largement répandus et soulignent le taux de pénétration de l'outil informatique.


- Pas nécessairement. La question des Vétérinaires Certificateurs pourrait ouvrir le débat à une utilisation "en mobilité" de TRACES. Mais l'utilisation du poste de l'Opérateur Economique visité semble la solution la plus pratique et la moins complexe.


- Il n'y a pas de portail a priori. L'accès à TRACES peut être direct mais la complexité de la certification peut nécessiter un passage par EXP@DON. - De même les différentes opérations à réaliser, comme la notification de mouvement ou la manipulation du passeport / ASDA par exemple, peuvent nécessiter l'accès à d'autres systèmes à des moments proches de l'accès à TRACES. Une vision de bout en bout est nécessaire.


- Des initiatives en matière de dématérialisation sont en cours et devraient permettre d'équiper certaines populations de certificats. * Les LVU pourraient être équipés compte-tenu de l'introduction de la signature électronique dans EXP@DON (flux entre la France et les DOM). * Les Vétérinaires pourraient être équipés pour leurs actions en tant que "vétérinaires privés mandatés" (signature du compte-rendu de visite sanitaire par exemple) : le sujet est discuté avec l'ordre des vétérinaires et il est suivi par le BISP (Bureau des intrants et de la santé publique en élevage)


- Imprimantes & lecteur de code-barres


- Cf. supra (initiatives dans EXP@DON et avec les Vétérinaires)


TRACES




- Commande publique pour les acteurs dépendant de l'Administration, comme les LVU. - Equipement en direct par les Opérateurs Economiques.


- Oui, notamment les cadres techniques propres au Ministère (Cf. Sous-direction Informatique, dépendant du SG, et BMOSIA).


- Non


- Pour les équipements éventuels, le Ministère peut équiper ses agents si cela permet des gains ou si cela s'inscrit dans une initiative globale de dématérialisation. - Pour les opérateurs économiques, le coût serait à leur charge. - Le modèle des Vétérinaires Certificateurs peut intégrer comme pré-requis à l'accréditation de disposer de l'outillage informatique nécessaire.


- A titre d'information, la dématérialisation pour l'identification bovine (passeport bovin et ASDA) représente un levier de 15 millions d'euro de gain et devrait permettre un retour sur investissement au bout de 3 à 4 ans. Cela représente plus de 20 millions de bêtes. - Un investissement vis-à-vis de la certification électronique dans TRACES pourrait être possible mais serait mesuré et en accord avec le volume de documents échangés via TRACES (90 000 certificats).

Sujet complémentaires abordés durant l'entretien TRACES



- Il pourrait être intéressant d'étudier le système mis en place aux Pays-Bas pour les fonctionnalités équivalentes à celles proposées par TRACES. De même, il serait intéressant de connaitre la solution retenue pour le passeport bovin aux Pays-Bas. - Il faut noter que la dématérialisation n'est pas perçue comme un facteur d'augmentation de la fiabilité ou de la sécurité des certificats : il n'y a pas de risque majeur de fraude identifié à l'heure actuelle (pas de gain pertinent pour un opérateur économique qui falsifie un certificat; les erreurs ne sont pas des actes de malveillance, sauf à de rares cas). - Les initiatives de dématérialisation des documents type "passeport bovin" et ASDA peuvent s'appuyer sur les solutions d'identification type "boucle" mis en place pour certains animaux. La présence de tels mécanismes pourrait être exploitée pour la dématérialisation globale. - Ces identités viennent alimenter une base nationale (qui permet de réduire la pression des contrôles sur le terrain). Une telle base est une initiative nationale et n'est pas une obligation communautaire. Les interactions et les accès à ces bases peuvent être un accès d'évolution des systèmes et un facteur de facilitation de la dématérialisation. A titre d'exemple, une téléprocédure mise en oeuvre lors de la FCO avait permis une première ouverture d'une base nationale à des opérateurs (à l'heure actuelle il s'agit principalement d'une notification par un opérateur à la BDNI). - Il faut noter que certaines populations qui utilisent les certificats papier (cas des abattoirs qui vérifient le certificat d'un lot importé d'un pays membre) n'ont actuellement pas accès à TRACES : le passage au tout électronique leur demanderait de s'y connecter. Ceci ferait de ces acteurs une population supplémentaire à assister et à accompagner. - Il faut noter que la future Loi de Santé Animale, en cours d'étude au niveau européen, pourrait mener à la suppression de la certification "intra". Cependant elle n'affranchira pas le besoin d'échanges d'informations sanitaires et commerciales sur les animaux. Ces échanges profiteront des initiatives en matière de dématérialisation et seront peut-être un levier d'ouverture et d'intereconnexion de bases / systèmes nationaux.

Projet TRACES - Phase 1 Interview : Selim Khodja & Michel Poli - Wednesday 23 February 2011


Opérateurs économiques (EO) : les interlocuteurs rencontrés n'appartiennent pas à ce type d'organisation mais ont des relations quotidiennes avec les OE utilisateurs du système TRACES. Il s'agit d'opérateurs économiques directement "consommateurs" des produits échangés ou de transitaires spécialisés dans le transport et la réception des produits. □ Autorités Centrales Compétentes (CCA) □ Autorités Vétérinaires Locales (LVU) Points d'Inspection au Frontière (PIF) ou Border Inspection Post (BIP) Le PIF de Roissy compte 28 personnes, décomposés en (10 vétérinaires, 2 techniciens et 8 contrôleurs du coté PIF (contrôles vétérinaires), et 10 du coté PEC (contrôles phytosanitaires). Il faut noter que le rapprochement entre services vétérinaires et phytosanitaires depuis 3 mois est encore en cours. Le PIF de ROISSY est rattaché à Saint Denis (93) et à la DDPP (Direction Départementale de la Protection des Populations) de BOBIGNY.

TRACES




Certification [INTRA / IMPORT / CVED / EXPORT] Notification Aide à la décision □ Enregistrement des contrôles - Le volet 1 du DVCE est créé par le transitaire (prénotification). Le PIF créé le volet 2. Dans certains cas, les transitaires utilisent le certificat IMPORT réalisé dans le pays tiers (si celui-ci utilise la fonctionnalité de certification de TRACES).


- Le PIF compte 28 personnes qui représentent autant d'utilisateurs de TRACES. - Au PIF de Roissy sont rattachés 124 organisations, avec un total de 328 utilisateurs. Il faut noter que tout compte est automatiquement vérouillé après deux mois consécutifs d'inactivité.


- Environ 30.000 certificats sont créés en une année au niveau du PIF de Roissy. - Le PIF contrôle des animaux vivants, des produits d'origine animale et des marchandises annexes (type foin par exemple). - Il faut noter que ce nombre a diminué compte-tenu de la perte d'agrément de la station animalière. Le PIF a vu se réduire la nature et le volume de ses activités (il s'agissait du seul PIF pouvant accueillir toute catégorie U/E/I d'animaux). Il ne peut plus inspecter aujourd'hui les produits dangereux à l'exception de ceux contenus en containers fermés (reptiles, amphibiens) et les primates de laboratoire grace à une dérogation spéciale. Le PIF de Roissy est par ailleurs limité à 16 chevaux. Les travaux de remise aux normes sont en phase de planification à Roissy.


Le plus fort pic de charge a lieu en fin d'année, peu avant les fêtes.

TRACES




Etape amont : préparation des certificats sanitaires - Cette première étape n'est pas inscrite dans le strict périmètre des actions réalisées par les transitaires et les agents du PIF. C'est cependant un pré-requis nécessaire à l'établissement d'un DVCE. - Les certificats sanitaires sont réalisés dans le pays tiers qui importe des marchandises dans l'UE. - La plupart du temps, il s'agit d'un certificat papier respectant le formalisme du pays tiers. - Dans certains cas, les pays tiers utilisent la fonctionnalité de TRACES permettant de créer un certificat IMPORT (8 pays sont concernés à ce jours : Madagascar, Maurice, Seychelle, Mayotte, Polynésie Française, Mexique, Sénégal, Maroc). La première étape du flux est alors électronique mais cela représente moins de 10% des certificats traités par le PIF. De plus le certificat est presque systématiquement rematérialisé (imprimé). Création du premier volet du DVCE (OE) - Dans le cas d'un certificat sanitaire créé via TRACES, l'opérateur économique peut "cloner" le certificat IMPORT en un DVCE qui voit son premier volet automatiquement pré-rempli. - Dans les autres cas, le transitaire crée un nouveau DVCE et en renseigner le premier volet (la "pré-notification"). - Le transitaire constitue une liasse de documents pour se planifier puis se présenter au contrôle vétérinaire. Cette liaisse se compose du certificat sanitaire, de la prén-notification et de documents annexes (factures et lettres de transport aérien le plus souvent). - Il faut noter que le transitaire s'assure que le lot faisant l'objet du DVCE et à contrôler est bien entré au niveau du bon centre de contrôle (3 zones agréées sur le PIF de Roissy). Création du second volet du DVCE - Le second volet sanctionne les contrôles vétérinaires. - Ces contrôles sont de deux types : documentaires (confirmité et signature des documents apportés par le transitaire) et identitaires (concordance entre les documents et les lots). - Il faut noter que le premier contrôle documentaire consiste à revoir le premier volet du DVCE (prénotification) renseigné par le transitaire. Ce contrôle se fait très souvent en visualisant l'impression papier. - Dans certains cas, ces contrôles sont complétés par des contrôles physiques (contrôles déterminés par les textes réglementaires, fonctions de la nature des produits et de grilles de fréquence). - Les contrôles "identitaires" et "physiques" se font avec une impression du DCE pour avoir les informations à contrôler sous les yeux. Validation du DVCE - Une fois les contrôles effectués, le DVCE est signé par le vétérinaire. Il est également signé par le transitaire. Etapes avales - Une fois validé et signé le DVCE est imprimé en trois exemplaires (1 exemplaire (original) pour accompagner la marchandise, 1 exemplaire pour archive locale du PIF 3 (ans, souvent accompagné des documents annexes type certificats sanitaires, factures, LTA), 1 exemplaire douane qui est, en fait, archivé par le transitaire).

TRACES




- Le système a été bien accueilli et est devenu l'outil du quotidien, tant pour les agents du PIF que pour les transitaires. - Les transitaires attachent une grande importance à l'ergonomie car elle est synonyme de gain de temps. Dans le cas de lots complexes (multi-espèces), la création du certificat peut prendre du temps. Si le pays tiers utilise la certification sur TRACES, le système est très très bien perçu par les transitaires. - A ses débuts (2005 / 2066), le système connaissait quelques lenteurs qui ne sont aujourd'hui plus présentes. - Il existe cependant deux axes d'amélioration : * Les OE occasionnels (souvent des particuliers ou des petites structures professionnelles) n'ont pas de compte sur TRACES et ne peuvent s'y connecter. Un DVCE vierge est alors imprimé et rempli. * Compte-tenu du besoin de statistique et de requêtage, une double saisie dans une base locale est encore nécessaire (l'enrichissement du datawarehouse pourrait permettre à terme de se passer de cet outil local).



- La possibilité de s'affranchir du papier est perçu comme un plus, tout comme la généralisation de l'utilisation du système TRACES. Cependant le papier reste utilise à certaines étapes. - L'interconnexion TRACES / DELTA (système de dédouanement) n'a pas permis une dématérialisation totale. Le DVCE reste imprimé (cependant l'interconnexion permet de ne saisir que l'identifiant du certificat).


- A priori tous les acteurs pourraient en être dotés, c'est-à-dire, les agents du PIF, les vétérinaires et les opérateurs économiques, dans la limite des possibilités techniques et des impacts "ergonomiques".


- La dématérialisation doit permettre un gain de temps et de fiabilité mais ne doit pas impacter le quotidien. - Elle peut également être un vecteur de sécurisation : l'utilisation d'un identifiant / mot de passe générique au PIF est ressenti comme une faiblesse pour les agents du PIF (un OE malveillant pourrait s'emparer du mot de passe). La signature se devant d'être personnelle, elle pourrait être une façon d'introduire des comptes personnels.


- La solution technique retenue ne doit pas complexifier l'utilisation de TRACES ni la rendre plus lourde ou plus consommatrice de temps.


- A priori tous les acteurs pourraient en être dotés.

TRACES




- Le papier est encore nécessaire pour son côté pratique (vérification du premier volet à l'arrivée du transitaire, utilisation lors des contrôles physiques ou visuels). - De plus, le DVCE est archivé avec des documents complémentaires (notamment le certificat sanitaire qui est "aggrafé" avec le DVCE pour établir un lien entre les documents).



- Il s'agit de postes de travail fixe, mis à disposition par le Ministère et respectant donc ses directives (utilisation de Firefox et d'OpenOffice) - La plupart sont dotés d'imprimantes de type multifonction avec scanner intégré.


- Non, il s'agit de postes de travail "traditionnels".


- Les différents utilisateurs accèdent à TRACES en direct, sans passer par un portail.


- Les usagers ne sont pas équipés de certificats pour le moment.


- Les postes sont équipés d'imprimantes "traditionnelles" (pas d'utilisation d'imprimantes spécialisées type étiquettes ou code-barres).


- Les agents du PIF n'ont pas d'expérience de signature électronique ou de dématérialisation, sinon la déclaration des revenus sur internet.



- Ce type de décision relève d'un niveau central, comme le Ministère, et non du niveau local du PIF.

TRACES




- Les directives du Ministère devraient être respectées. Les éventuelles contraintes doivent être discutées en direct avec les acteurs ministériels concernés.


- A ce jour, non.


- Ce type de décision relève d'un niveau central, comme le Ministère, et non du niveau local du PIF.


- Les deux types de bénéfices attendus seraient : * un gain de temps (document prérempli), * un gain de sécurité (identifiant personnel, renforcement de la fiabilité)


A Roissy les employés du PIF disposent de 3 badges différents: - 1 badge cantine et pointeuse, - 1 badge parking, - 1 badge 'rouge' délivré par la PAF, avec puce et antenne, dit de circulation aéroportuaire. Les 2200 textes règlementaires s'appliquant imposent une veille et un suivi des mises à jour. L'aide à la décision présente dans TRACES est complétée par les outils EXP@DON et IMP@DON mis à disposition par le Ministère.

Projet TRACES - Phase 1 PIF Le Havre : Interview de Régis Chenal et Franck Faivre le 24 février 2011


TRACES




□ Opérateurs économiques (EO) □ Autorités Centrales Compétentes (CCA) □ Autorités Vétérinaires Locales (LVU) Points d'Inspection au Frontière (PIF) ou Border Inspection Posrt (BIP) LE PIF Le Havre est le deuxième plus important PIF de France après Roissy CDG en terme de nombre de lots. Le Service d'Inspection Vétérinaire Et Phytosanitaire (SIVEP) regroupe maintenant les : - Postes d'Inspection Frontaliers (PIF) : pour les produits d'origine animale A12pour consommation humaine ou non - Points d'Entrée Désigné (PED) : pour l'alimentation non d'origine animale destinée aux animaux (exemple : vitamines, céréales...) - Points d'Entrée Communautaires (PEC) : pour les végétaux




Le PIF Le Havre (pif76.havre.sivep) comporte 13 employés: - 1 vétérinaire, - 1 IAE (Ingénieur Agricole et Environnement), - 5 techniciens, - 3 préposés Sanitaires, - 2 vacataires, - 1 adjoint technique Le PIF Le Havre supervise 30 transitaires et leur donne accès (accès nominatif et personnel) à TRACES.


17 390 lots en 2010 dont 16 700 DVCE. La différence étant des NOA - Annexe OA. 1 200 à 1700 lots par mois. 60 à 70 contrôles par jour. 5 jours sur 7. 80% des produits importés sont des produits de la pêche. 99% des produits sont surgelés.


Deux facteurs majeurs : - Les grèves - Les fêtes de fin d'année, se matérialisant par un pic de charge en Juillet - Septembre. Les marchandises sont principalement surgelées, d'où cette anticipation. TRACES




10% des DVCE du Havre proviennent d'un IMPORT créé par un LVU d'un pays exportateur tel que : - Maroc - Nouvelle Zélande, - Nouvelle Calédonie, - Madagascar, - Maurice - Mexique Les pays suivants, par ordre d'importance, font transiter leurs marchandises par le PIF du Havre : 1. Chine 2. USA puis : Chili, Thailande, Vietnam, Equateur, Nouvelle Zélande, Pérou. Le transitaire : - fait le clônage de l'IMPORT pour créé un DVCE partie 1 - prénotifie le PIF au moins 24h à l'avance (Certificat sanitaire + 3 exemplaires du DVCE remplis et signés) - organise le transport des containers du bateau au PIF pour contrôle par le PIF (les marchandises sont toujours sous douanes). - dédouane les marchandises en présentant le DVCE partie 2 signée par le PIF. Le PIF Le Havre : - utilise le logiciel Microsoft Word pour son modèle de FICHE D'INSPECTION (système qualité COFRACE 17020). Le vétérinaire imprime cette fiche d'inspection et se déplace dans la salle des contrôles d'inspection des containers. - utilise TRACES pour suivre les différents DVCE (contrôle documentaire, etc.). - utilise le logiciel Microsoft Access pour établir sa base de données locales complétées d'informations insérables dans TRACES. - utilise différentes bannettes pour stocker / empiler les différents dossiers (DVCE...) en attente de traitement. Le PIF Le Havre est géré en fux tendu et a une organisation très rigoureuse des processus. Le temps passé pour un DVCE est d'environ 20 minute dont 3 minutes pour les manipulations dans TRACES. - utilise, pour des raisons de disponibilité et rapidité, le logiciel Microsoft Access pour suivre les différents DVCE et faire des requètes TRACES. Le vétérinaire : - a l'obligation de signer tous les DVCE sauf ceux des produits de la pèche (qui représentent 80% de l'activité du PIF). - du fait qu'il n'y ait qu'un seul vétérinaire pour les 3 sites du PIF dans le port du Havre, le vétérinaire pré-signe OK les DVCEs et met les DVCE sur TRACES en statut "en cours" (le transitaire ne peut plus modifier la partie 1 du DVCE). Si le contrôle est OK, le technicien utilise le DVCE pre-signé, et valide le DVCE dans TRACES. Si le contrôle est KO, le technicien déchire le DVCE pré-signé et soumet au vétérinaire ou à l'IAE un DVCE KO pour signature et le met à jour dans TRACES. NB: les status "Nouveau", "En cours", "Original" n'ont aucune valeur juridique. Un DVCE n'a de valeur, quelque soit sont statut, que lorsqu'il est signé.


Oui, en partie. Nous devons nous appuyer sur d'autres applications logicielles pour des exigences d'efficacité de l'organisation et de suivi qualité. Les recherches dans TRACES doivent être améliorées et permettre d'effectuer les reportings demandés par le Ministère. Exemple : le PIF n'a accès qu'aux DVCE de moins de 3 mois.

TRACES





La dématérialisation permettrait de faire des économies de papier et d'encre essentiellement. Le PIF Le Havre n'a pas une contrainte de place pour les archives. Il faut néanmoins pouvoir passer en mode dégradé et revenir au papier (si problème informatique, accès TRACES, etc.)




la signature doit être réalisée en fonction de la personne retenue dans la liste


les transitaires et nous


La certification qualité ISO 17020 impose de conserver la FICHE D'INSPECTION du fait que plusieurs acteirs interviennent dans le processus.



Win XP / FireFox / Office. Imprimante, Scanner Pas de matériel 'mobile' Le scanner n'est utilisé que pour envoyer des copies de certificat en format PDF à la DGAL.


Non. TRACES




Oui : Microsoft Access qui existait avant TRACES et nous permet aujourd'hui: - de gérer les archives - de faire toutes nos recherches Microsoft Word : - d'imprimer les fiches d'inspections


Non. Des certificats logiciels installés sur tous les postes feraient sens. L'utilisation de tokens ou cartes à puce pourraient ralentir le processus.



Non.




Niveau qualité 17020 par la COFRAC


L'utilisation de TRACES non. Elle facilité au contraire la traçabilité. La double saisie dans Microsoft Access pourrait cependant être limitée voire supprimée si TRACES evoluaient (permet les fiches d'inspection, l'organisation du PIF, les recherches par le PIF ou en central depuis Paris, etc.)


Le Ministère pour le PIF. Les transitaires pour eux-mêmes.


En premier lieu, ne pas ralentir la procédure TRACES (accès, utilisation, recherches).

TRACES




Les 20 PIFs de France se réunissent une fois par an au ministère à Paris. Des réunions avec les autres ports d'Europe sont également organisées.

6.2.3 Germany

24/03/2011 BIP Hamburg Port, Germany

Peter Mielmann Head of BIP Hamburg Dr. Ute Gramm Deputy head and administrator of BIP Hamburg Andreas Micklich TRACES IT-Administrator in Germany (from the Friedrich-Loeffler-Institut, German Institute for animal health)



□ Economic Operators (EO) □ Central Competent Authority (CCA) □ Local Veterinary Unit (LVU) Ø Border Inspection Point (BIP)


Ø Certification [INTRA / IMPORT / DVCE / EXPORT] □ Notification □ Help to decision □ Control registration


In BIP Hamburg : The organisation (and paper validations / people and lorries movements) are specific to Hamburg Port : - there are indeed containers ports inside and outside the clearance area. - there are veterinary units from the BIP Hamburg inside and outside the clearance area. Therefore, there are specific clearance procedure to be fullfiled by the driver and economic operator. See below for the VetOK system.


The BIP Hamburg produces around 35 000 DVCE a year.

TRACES




The yearly peak workload appears in september.


BIP of Hamburg manages different paper processes : - Bill of handling - control of foreign veterinary certificates - TRACES/DVCE All paper documents are systematically scanned into PDF format. In order to be more efficient (during the process and for archiving), a colour code has been put in place. There is only one original, the other are copies. - Part.I of DVCE is printed out of the software COACH on blank paper - Part.II of DVCE is printed out of the software COACH on security paper (against forgery)


The IT system COACH enables further functions : - add comments - notify in advance the economic operator if he will be controlled and to which veterinary unit in the Hamburg port he has to take the container.



Yes. We already have all document in electronic format (after a scan procedure). Having all document already in electronic format will enable to spare time scanning documents. "The security has then to be at the right level". To that extend, BIP Hamburg uses a specific IT System called COACH. COACH is the main management application of the BIP Hamburg. TRACES is updated once processes on COACH are completed.

Should the dematerialization be applied across the TRACES user spectrum (private operators, public service, just within the European Union, or in third countries as well) ?

There is no interface / link between the COACH IT system and the IT system of the customs

What do you expect to come from this project ?

The first objectives are to have a better traceability and facilitate statistics.

What are your main apprehensions ?

1. How to do it on site when controlling before shipping (no internet access, no PC) 2. The time spent : - to be equipped and trained - to make an electronic signature

According to you, which players All players : Economic Operator + customs.

TRACES



would potentially use the electronic signature?


The process is already mainly based on paper (invoice, certificates, etc.) although all the information are also in COACH IT system. A 100% electronic process would be ideal, but there paper will still be necessary, in case : - no electronic sanitary certificate - no electronic invoices - no system to track containers/trucks across Hamburg Port - ...



▪ Up to date Microsoft Operating Systems and IE or FF browsers.


No mobile environment.


COACH IT System : - The economic operators enter into TRACES after accessing the Gateway application of Hamburg. The access rights are given by the BIP IT administrator. The economic operators do not enter into TRACES. - There is a technical interface between COACH and TRACES, but does not work all the time. - COACH is also used in Bremen, München and Halle. VetOK IT System (used if the container has to go out of the clearance area for vet control) : - When the paper control by the BIP is OK, the status in the VetOK system is set to OK. - The container can then go to vet control. - If the Vet control is OK the container can go to the customs with the Part.I+II of DVCE. ATLAS System : - This system is used by the customs but no interface or link with TRACES. - The customs do not keep any paper.


No for BIP of Hamburg. No for Customs of Hamburg. No card readers.

TRACES



Do you have a "re-materialization" operation ? If yes, which one?

No.




The BIP Hamburg is financially autonomous and budgets its expenses.


In Germany, the law (Signaturegesetz SigG and Signaturverordnung SigV) defines the technical requirement for a qualified electronic signature. It will need to be confirmed if it is mandatory to comply to that law (and use a smartcard) : - the use of a smartcard may add constraints - an advanced electronic signature instead of an qualified electronic signature is possible ? (the law may change this year)


Not really.


./.


1. Increase security (for example 20 false foreigner sanitary certificates have been detected in 3 months, especially from South Korea and Vietnam). Enable a better traceability and statistics. 2. Save time.

24/03/2011 LVU Rotenburg (Wümme) in Niedersachsen, Germany

TRACES



Dr. Joachim Wiedner Head of Veterinary Administration in Landkreis Rotenburg (Wümme) Dr. Susanne Jungnitz Veterinary in Landkreis Rotenburg (Wümme) Andreas Micklich TRACES IT-Administrator in Germany (from the Friedrich-Loeffler-Institut, German Institute for animal health)



□ Economic Operators (EO) □ Central Competent Authority (CCA) Ø Local Veterinary Unit (LVU) □ Border Inspection Point (BIP)


Ø Certification [INTRA / IMPORT / DVCE / EXPORT] Ø Notification Ø Help to decision Ø Control registration


In LVU Rotenburg (Amt39) : - 6 vets - 4,5 food controller (one part time) - 7 administration staff (full time) - 4 administration staff (part time) - 29 vets in slaughters - 27 meat controllers - 2 vets (part time) for sample control on animal bodies http://www.landkreis-rotenburg.de/


In 2010, the LVU Rotenburg sent inside Europe (INTRA) : - 148 groups of horses (= 197 horses) => needs an on site veterinary inspection - 216 groups of cattle (= 3 619 cattle) => needs an on site veterinary inspection - 9 groups of pork (= 1 364 porks) => needs an on site veterinary inspection - 5 groups of sheep (= 22 sheep) => needs an on site veterinary inspection - 72 groups of poultry (= 460 695 poultry) => needs an on site veterinary inspection - 47 groups of Category 1 (= 1 164 080 pieces) => doesn't need an on site veterinary inspection, but a control at destination - 70 groups of horse semen (= 96 horse semen) => doesn't need an on site veterinary inspection In 2010, the LVU Rotenburg sent outside Europe mainly cattle (around 6 400 cattle).


./.

What is the life cycle of a paper Standard INTRA Lifecycle. Some remarks :

TRACES



certificate? - See below : issues with The Netherlands and Denmark. - Part. III (control on site or on TRACES at the LVU) is not printed. Part. III is not used because you cannot add commentary. - Archiving is set for 5 years (although legally is set for 3 years).


Traceability and statistics are important. - DWH (DataWareHouse of TRACES) is OK to follow INTRA. - DWH is not designed to support exports outside Europe. - Problem to access DWH in the morning. - Problem with imports from The Netherlands and Denmark : they fill up the forms by hands and update TRACES days later. The goods already arrived at destination before any inputs in TRACES !



A dematerialised process could enable more efficiency but also constraints (see below).


- The Police needs also to have access to TRACES across Germany. In Niedersachsen, the Police has already the access rights to TRACES, and can use it from their car while making a road control. This is not the case in Bayern for example. - For some other actors, or vets on mobility, it may be difficult.


The first objectives are to have a better traceability and facilitate statistics.


1. How to do it on site when controlling before shipping (no internet access, no PC) 2. The time spent : - to be equipped and trained - to make an electronic signature


All players : Economic Operator + customs.


Paper would still be needed by : - The vet when he is on site for a control before shipment - The police for road control (if TRACES access not in place) - The slaughterhouse as he usually doesn't have a PC.


TRACES




Up to date Microsoft Operating Systems and IE or FF browsers.




No. They have a direct connection into TRACES.


There is today no deployment of electronic signature certificates on smartcard in the Land administration. There is no plan to do so. For information, the German law on eID enabling electronic signature is enforced since November 2010. Every German citizen asking for a new ID card becomes a smart card enabling electronic signature.


./.


Not really. Tax declarations are mainly still done on paper.

Your organisation and potential evolutions TRACES




The Veterinary Administration of Rotenburg Wümme depends from : - Land Niedersachsen -- Landrat Rotenburg --- Dezernat II ---- Amt39 The TRACES IT-Administrator for Germany gives access rights to Land Administrators who give access rights to the different users (LVU, Land Police...).


In Germany, the law (Signaturegesetz SigG and Signaturverordnung SigV) defines the technical requirement for a qualified electronic signature. It will need to be confirmed if it is mandatory to comply to that law (and use a smartcard) : - the use of a smartcard may add constraints - an advanced electronic signature instead of an qualified electronic signature is possible ? (the law may change this year)


Not really.


./.


1. Enable a better traceability and statistics. 2. Save time.

6.2.4 Italy

08/03/2011 BIP Livorno, Italy

Dr.ssa Grazia Tasselli Ministero del lavoro Salute Politiche Sociali - Direttore UVAC Toscana e PIF Livorno/Pisa

Donato Angelo Ministry of Labour, Health and Social Affairs, Health Sector - BIP and UVAC Coordinator

Greco Giorgio Ministry of Labour, Health and Social Affairs, Health Sector - TRACES IT team

Apicella Claudio Ministry of Labour, Health and Social Affairs, Health Sector - TRACES IT team

TRACES



Your usage of TRACES system

Whitch population of users do you represent ?

□ Economic Operator (EO) Central Competent Authority (CCA) □ Local Veterinary Unit (LVU) Border Inspection Post (BIP) Dr.ssa Tassello manages different entities : - The BIP of Livorno (Port) - The BIP of Pisa (Airport) - The UVAC of the region of Tuscany (See below)

What are the major features that you use?

Certification [INTRA / IMPORT / DVCE / EXPORT] □ Notification □ Help to decision □ Control registration

How many users do you have under your responsibility?

The BIP of Livorno employs : - 5 Veterinary - 3 technicians The UVAC of the region of Tuscany employs : - 4 Veterinary - 2 adminsitratifs - 1 health technician There are around 20 Economic Operators (OE) at BIP Livorno.

Do you know the number of certificates generated by different populations of users?

approximately 12 000 DVCE a year at BIP Livorno approximalely 5 DVCE a year at BIP Pisa approximately 80 000 documents a year at UVAC Tuscany

Are you aware of peak load or times of high stress?

On the BIP of Livorno, the TRACES activity is concentrated from 12h to 14h, after the morning was spent on port,

What is the lifecycle of paper certificate?

1/ The Economic Operator provides the 3 copies signed of Part 1 of DVCE. 90% of the DVCE are filled on the EO's PC. 2/ The Economic Operator pays the different taxes ( a stamp "Redevances paid" is then put on the DVCE) 3/ The BIP controls the data on Part 1 of DVCE and fills a check list 4/ The BIP fills the Part 2 of DVCE. The Veterinary just adds his name, but TRACES does not have any list of Veterinarians of the BIP. 5/ The Economic Operator gives the Part 2 of DVCE to the customs 6/ The transporter travels withe the Part 3 of DVCE. The LVU of destination is informed by e-mail from TRACES. 7/ The original of the sanitary certificate + invoice + IMPORT signed + check list + DVCE are archived 4 years (legally it is 3 years) by the BIP

The TRACES system right for your needs?

An IT System called SINTESI completes TRACES : - TRACES enables traceability through the European Union

TRACES



- SINTESI enables traceability also inside Italy and provides advanced search options The UVAC regroups 1 000 companies in Tuscany. 50 % of the companies use SINTESI which reprensents 70% of the documents. The othe companies use still paper.

Your perspective on the electonic certification

The prospect of the paperless certificate for you seem interesting?

Yes, but it is necessary to have a fall back procedure on paper in case (technical problem, specific health controls, etc.)

Electronic certification should it apply to all types of users of TRACES (private operators, public service, within the EU only or for third countries as well)?

The Economic Operator (EO) at the BIP : - has an access by login/password to TRACES - has an access by login/password to AIDA (customes IT system) The Consignor/Consignee : - has an access by login/password to SINTESI

Do you have any expectations for this project?

The use of electronic signature certificates is more and more standard in Italy.

What are your main concerns? TRACES should be able to sign electronically also, but this should not add contraints and ergonomy of use. As it's difficult to install a software, it is preferable to have certificates on smart cards rather than software.

What do you think players would have the digital signature?

All the players should be able to sign digitally. The management of certificate should be easy and done by the Chamber of Commerce for the local companies.

The 'all-electronic' Is it possible? The paper you seem to need it anyway?

See above.

Your technical environment

What is the most current technical environment?

Microsoft Windows and Internet Explorer

Are there technical environments for use in mobility or in an "industrial"?

No mobile equipment.

Do you need to access other applications before or after a session of TRACES? Do you use an access portal to TRACE?

Only producing control checklist with MS-Word

TRACES



Do you have digital certificates? If yes, how?

The BIP Livorno uses a smart card for purchasing. This card is personal and reserved to the Director.

Do you have any way for "re-materializing"? If yes, which

Have you ever experienced the digital certification and / or dematerialization, as an individual / professional

Your organization to potential changes

Which actor / decision cycle is initiated in cases of technological change requiring the deployment of hardware or software related to TRACES?

It would easier to use electronic signature on smartcards rather than deploying software certificates. Few vets use the same PC and few PC's in parallel. The digital signature should therefore be possible on each PC.

Are there organizational or technical rules or frameworks to follow in case of change (OSI, RGS, aso)?

The use of TRACES is there a cost to your organization?

Who do you think should bear the potential costs associated with evolution?

The BIP Livorno would need to get digital certificates for each vets in order to be able to sign eletronically. The Ministery of Health should provide and manage those cards.

What is the nature of the expected return on investment (€, workload, time saved, security and integrity, confidentiality, etc..)?

The electronic signature should not take more time than a manuscrit signature.

Additional topics covered during the interview

TRACES



The Economic Operator can be accreditated by the Customs to clear himself its goods. This procedure enables the Economic Operator to gain time but put a high responsability on his shoulder. The SVAD (Servizio di Vigilanza Antifrode Doganale or Security Service Customs Fraud) controls a posteriori the goods of those Economic Operator accreditated. The Economic Operator would loose its licence in case he fails the control. There are therefore very few Economic Operator who chose to be accreditated.

08/03/2011 Economic Operator, Livorno, Italy

Rita Billi Spediliv Srl

Dr.ssa Grazia Tasselli Ministero del lavoro Salute Politiche Sociali - Direttore UVAC Toscana e PIF Livorno/Pisa






Economic Operator (EO) □ Central Competent Authority (CCA) □ Local Veterinary Unit (LVU) □ Border Inspection Posrt (BIP) SPEDILIV is a forwarding company (import) registered in TRACES as Economic Operator.


□Certification [INTRA / IMPORT / DVCE / EXPORT] Notification □ Help to decision □ Control registration


2 people of Spediliv use TRACES for pre-notifications

TRACES




./.


./.


The paper documents are archived by the Economic Operator for 5 years. Health certificates can be requested for 4 years by the client, the BIP or customs


Yes but interfaces should be developed with AIDA and other information systems used by Economic Operators, including free application for managing adminsitrative and tax.



Yes.


./.


./.

What are your main concerns? ./.


All actors should be equipped with electronic signature software.


./.



Windows and microsoft

TRACES




No mobility equipment.


./.


Spediliv uses software certificates (keystore.ks 3 year validity RSA 1024 bits) in order to transfer files to the customs on their AIDA platform. Spediliv uses hardware certificates on smartcards (25€ a year, 2 year validity, free renewal) for VAT, tax and balance sheets declarations.


./.


Spediliv uses the M2R2 management software. Not linked with TRACES. Spediliv uses a free software from the government to sign (P7M) batches of documents to the Customs and to verify documents returned signed from customs. The access to the italian web portal is by login/password. The documents need to be uploaded, there is no SI to SI connection.



./.


./.


Not really.


The Economic Operators will have to adap and potentially bear the costs.

TRACES




./.


An Economic Operator can ask to be a CAD (Centri di Assistenza Doganale) : - This allows the Economic Operator to go through clearance without a priori declaring the goods. The responsibility is however very high. As 90% of EO, Spediliv didn't choose to be CAD.

08/03/2011 LVU Pisa, Italy

Riccardo Rossetti Azienda USL 5 di Pisa

Maurizio Calabrò Azienda USL 5 di Pisa






□ Economic Operators (EO) □ Central Competent Authority (CCA) Local Veterinary Unit (LVU) □ Border Inspection Posrt (BIP) The region of Tuscany is divided into 3 zones LVU (USL in italian) liable for health issues on its territory. One specific activity of the LVU Pisa is the export of horses within the European Community.


Certification [INTRA / IMPORT / CVED / EXPORT] □ Notification □ Help to decision □ Control registration

How many users do you have The LVU employs 3 veterinarians.

TRACES



under your responsibility?


For the first two months of 2011, 22 certificates, in which 20 INTRA for horses.


./.


Please refer to the attached schematic.


An IT System called SINTESI completes TRACES : - TRACES enables traceability through the European Union - SINTESI enables traceability also inside Italy and provides advanced search options

Your perspective on the electonic certification The prospect of the paperless certificate for you seem interesting?

to see …



Be able to use current authentication and signature cards to be able to authenticate and sign also in TRACES.

What are your main concerns? Use the same smartcard for TRACES as already used for the other applications.


Tuscany is one of the pilote Region in Italy around electronic signature. The citizen are therefore in their private (health card, eID…) and professional life confronted to electronic signature of official documents. Example : Carta Nazionale dei Servizi (CNS) used by the LVU to sign electronic documents. - signature type : PKCS#11 CSP - card type : Oberthur - software maker : Bit4ID Used currently as authentication by PIN entry. The user is disconnected from the application after 15 minutes without use and will need to reauthenticate again (new PIN entry).


The page 3 of a CVED is signed by the veterinary when controlling - on site - the marchandise. (CE 1/2005 and 19 mai 2010 nr. 0009519). A electronic signature may be more a constraint in this situation.

TRACES





Windows.


No mobile equipment


The LVU accesses TRACES with a single login/password for all employees. The LVU uses the software SFERACARTA, promoted by the Tuscany Region, for the administrative management of the LVU. This software is also used in Emilia Romana, Piemonte, Marche). The LVU uses SINTESI for anything that does not get through TRACES (national exchanges for example). The LVU uses the national database (BDN : Banca Dati Nazionale Anagrafo) for all data regarding animal identity. To connect to this application, the users authenticates itself using a free of charge contact smartcard (CNS, see above) issued by IZS and the Ministry of Health. This card can also be purchased to the national Post or to the local Chamber of Commerce.


Yes, see above.


./.


Tuscany is one of the pilote Region in Italy around electronic signature. The citizen are therefore in their private (health card, eID…) and professional life confronted to electronic signature of official documents.



The Region.


Although archiving is set to 5 years, it is common to archive it for 10 years.


No.

TRACES




The Region.


Time saved. Interoperability of the different Information Systems.


An italian citizen has the choice between : - a free paper ID - a payable eID on a smartcard (since 2004)

08/03/2011 Ministery of Health, Rome, Italy

Dott.ssa Claudia Biffoli Ministry of Labour, Health and Social Affairs, Health Sector - Directorate General of Information System






□ Economic Operators (EO) Central Competent Authority (CCA) □ Local Veterinary Unit (LVU) □ Border Inspection Posrt (BIP) The italian Ministry of Health is responsible for : - the 34 BIPs in Italy (120 to 130 Veterinarians) - the 17 UVAC. The UVAC defines the controls to be done by the LVU. The 20 italian Regions are responsible for : - the LVU (180 to 190 accross Italy).

TRACES




Certification [INTRA / IMPORT / DVCE / EXPORT] □ Notification □ Help to decision □ Control registration


See above.


The 34 BIPs in Italy produce about 65 000 DVCE a year (50% have a final destination in Italy). About 5 000 DVCE are treated in Italy after being produced in another european country BIP. Statistics are available on the ministery's website.



Economic Operators transform (called "cloning") in TRACES the electronic sanitory certificate into Part 1 of DVCE and print it on their own printer before passing the BIPs. 90% of Italians Economic Operators use TRACES for this work.


Different IT systems are needed to cover the different needs/requirements : - TRACES enables traceability of animal origin products through the European Union - SINTESI enables traceability also inside Italy and provides advanced search options (not printed, not signed). Accessible by the LVU or consignee through a web portal or XML B2B. - USMAF enables traceability ot non-animal origin products (not printed, not signed) - AIDA enables traceability for the customs. There are unfortunately no interconnections between TRACES or SINTESI and AIDA. In July 2011, a unique customs' web portal will be put in place and will manage all documents (health, sanitary, etc.) In January 2014, this portal will be fully interoperable for IMPORT and EXPORT.



The technology is now mature, even if no projects have helped to implement the principles of digital signature with certificates inside the Ministery of Health. Relationships with and within administrations are generaly dematerialized and supported by electronic signatures.


Yes.

Do you have any expectations A more efficient electronic cooperation between BIP and Customs

TRACES



for this project?

What are your main concerns? Cost and complexity to maintain.


All the players should be concerned.


An all-electronic would be ideal. A paper fall back option should always be possible (technical problems, new law not yet fucntionnaly integrated in TRACES, etc.)



Microsoft (Windows 7+ and Internet Explorer)


No mobile equipement. No deployement planned.


Users connected to the network of the Department access to the Internet through a proxy ... but they have direct access to TRACES from other point.


The representative of italian companies electronically signs the balance sheet of the company (which reprensents billion of documents a year). The Customs use digital signature since 2000 (accreditated by DigitPA ex-CNIPA). The Economic Operators use digital signature based on a software certificate to send documents to the customs. The BIPs do not use digital signature.




Which actor / decision cycle is initiated in cases of technological change requiring

See below.

TRACES



the deployment of hardware or software related to TRACES?


1/ All health procedure are paperless and electronically signed 2/ Italian laws enforce archiving and re-timestamping


No.


The Ministery of Health will be responsible to deploy digital certificates on smartcards to the BIPs agents. This is not yet planned. The Regions will be responsible to deploy digital certificates on smartcards to the LVUs agents. They will be able to simply use the Chambers of Commerce.


There initial investments will be a constraint, but the annual maintenance as well. The ROI is € driven.

Additional topics covered during the interview The italian Ministery of Health employs 2 500 persons. Some of their IT Systems are outsourced : - SINTESI to Accenture - Alma Viva Italia

6.2.5 Slovenia

28/03/2011 BIP Obrezje in Slovenia

Bozo Zakrajsek Chief of Border Inspection Simeon Zilevski Director of Obrezje and Dobova BIP Tina Kos Administrator for TRACES in Slovenia (for BIP and LVU)

TRACES



Christian Kuhn Projects Director at Dictao



□ Economic Operators (EO) □ Central Competent Authority (CCA) □ Local Veterinary Unit (LVU) Ø Border Inspection Point (BIP)


Ø Certification [INTRA / IMPORT / DVCE / EXPORT] Ø Notification Ø Help to decision Ø Control registration


There are 6 BIPs in Slovenia, around 10 000 DVCE /year : - BIP Jelšane : road BIP, around 4 000 DVCE/year - BIP Gruškovje : road BIP, around 1 000 DVCE/year - BIP Obrežje : road BIP, around 4 000 DVCE/year - BIP Dobova : rail BIP, around 5 DVCE/year - BIP Brnik : airport BIP, around 50 DVCE/year - MVP Koper : sea BIP, around 9 00 DVEC/year In BIP Obrežje: - 4 veterinarians (14 in all Slovenia) - 1 veterinarian - 1 Secretary


Of the 4 000 DVCE/year in Obrežje, 1 000 are cloned (IMPORT to DVCE). Mainly IMPORTs from Croatia.


./.


1. The Economic Operator fills the Part 1 of TRACES on his PC, in his office. 2. The BIP check the data of the page, proceed to the controls and prints and signs 3 exemplars the Part 2. 3. The Economic Operator signs the 3 exemplars of the Part 1. 4. The BIP keeps one signed exemplar. With the invoice and with the sanitory certificate. 5. The Economic Operator gives one signed exemplar to the customs. 6. The Economic Operator gives one signed exemplar to the driver. Signed documents (at BIP, at destination, at customs) are archived during 3 years.

TRACES




Global satisfaction. The BIP needs however to comply to national laws and EU directive 97/394/EC and collect minimal data on animals products. Therefore the BIP writes down in a notebook the different required data. An (easier) access to TRACES would enable to collect seach data ? [C. Kuhn]



Yes. - We have the technology and knowledge. - Similar process already deployed in banking sector and in customs.


The dematerialized signature at the BIP Obrežje should be easy because of : - the advanced equipment they have and, - the recent deployement by the government of signature certificate on smartcard. The Economic Operator may be relectant at the start the electronically signed regarding especially the costs (card + card reader). Less than 100 € over 2 years for a smartcard should however be OK.


1. Be compliant to EU guidelines. 2. Higher security and engagement of the responsibility of the BIP inspector.


./.


All players : Economic Operator + customs.


The BIP Obrežje will welcome a dematerialized process, but they would need to keep the paper : - as a backup process if some IT issues with TRACES - as a signed exemplar for the driver (compliance to EU rules)


What is the most up to date / current technical environment /

▪ Up to date Microsoft Operating Systems and IE or FF browsers.

TRACES



configuration?




No, direct connection into TRACES. At the BIP Obrežje, the connection is done by the veterinian with its own personal e-mail! This to enhance security. TRACES logs off after 20 minutres of inactivity. To validate a DVCE, the veterinian needs to tape his password (his FF doesn't keeps in cache the password).


The slovenian governement just deployed smartcard to some veterinians (not to all of them). They don't use it yet. To be confirmed if the card has an authentication certificate and/or an signature certificate.


./.


We managed to exchange also with the Customs at Obrežje border : - There is no link/interface between TRACES and their system SICIS. SICIS covers customs clearance of goods and enables customs supervision of goods as well as recording and accounting of duties. - They slovenian customs inspector already have a smartcard issued by the SIGOV-CA. (See picture). They will use it gradually. The first document electronic signed are import licences for goods. - They don't issue any printed paper. - Their PC are equiped with bar code reader. A priori, they are not national eID for citizen program. Banks allow customers, via their web portal logged in by login/password, to pay their bills. Member of the governement use a OTP Token (RSA SecureID ?) to generate a One Time Password to access to HKOM (Backbone of the Communications Network of State Organs) and use their permanent software electronic signature certificate installed on their PC.



TRACES




Organisation mostly driven by EU requirements. The governement of Slovenia requires however : - Invoices : A specific national database application needs to be filled. No link/interface with TRACES. Done by the veterenian and printed+signed by the veterenian. - Statistics : Another specific national database application needs to be filled in order for the Ministry of Agriculture to have statistics. Done by the secretary with her personal login/password access.


Not realy.


./.


Also there is no fraud on certificate at this BIP, keeping a good level of security is expected.

TRACES



6.3 Appendix 3 – Certificate authorities

The following list comes from the Microsoft Windows® Root Certificate Program. It shows that many countries are represented which is a good point for third-party states that are using TRACES.

Countries

Austria Mexico

Belgium Norway

Bermuda Poland

Brazil Portugal

Bulgaria Romania

Canada S Korea

Chile Serbia

China Singapore

Colombia Slovak Republic

Czech Republic Slovenia

Denmark South Korea

Estonia Spain

Finland Sweden

France Switzerland

Germany Taiwan

Hong Kong (SAR) Taiwan ROC

Hungary The Netherlands

India Tunisia

Ireland Turkey

Israel UK

Italy United Kingdom

Japan Uruguay

Latvia USA

Lithuania Venezuela

Macao SAR TRACES



6.4 Appendix 4 – Signature component : an example

The signature component introduced in 0 can be found on the market. For example, in the solution that is proposed by Dictao, this software comes in the form a java applet called AdSigner. The main functions of this component are:

Signature on the client workstation in order to meet regulatory requirements

Support of certificates (both software and stored on hardware devices)

Certificate filtering, to point out which certificate to use according to the context

Display of the document to sign, which is guaranteed by the ANSII component (WYSIWYS : What You See Is What You Sign)

Support of the main signature formats available on the market (XAdES, XML Sig, PDF, CMS, …)

Support for detached, enveloped and enveloping signatures

In order to access the resources on the user station, this applet is signed. Its size is about 400 Ko.

The deployment of the signature applet is automatically completed on the workstation, without initiation by the user.

The installation and the use of the AdSigner applet and its resources do not require any specific privilege on the user station: work files are written in a temporary repository to which the user has all of the rights (user profile) and which is systematically erased upon completion.

Because of the diverse range of configurations that can be encountered throughout the EU, the applet must be as flexible as possible.

Currently, the main Operating Systems that are supported are:

Windows XP 32bits SP2 or higher (SP3 for software certificates)

Windows Vista (32 or 64 bits)

Windows 7 (32 or 64 bits)

Mac OS X 10.4 or higher

Linux

For technical reasons that are directly related to the security of the signature process, certain out-dated OS are purposefully not supported.

The applet evolves constantly in order to support new environments, depending on OS updates.

The signature component supports the following browsers:

Internet Explorer 6 or higher

Firefox 1.5 or higher

Google Chrome 6 or higher

Safari 3 or higher

TRACES



6.5 Appendix 5 – Trust platform : an example

Trust platform introduced in 0 can be found in the market, as in the example of Dictao product.

Dictao Trust Platform is a software solution that is meant for organizations seeking to complete transactions with clients, suppliers, partners, and users through all channels (online, in-branch, by phone), with complete security and trust. DTP allows an organization to very easily implement dematerialized applications, and therefore offer new services, all while respecting regulatory frameworks.

In order to guarantee maximal levels of security and quality to its partners, Dictao has committed itself to a vast qualification and certification project, according to the Common Criteria, as defined by the ISO (International Standards Organisation), for its signature and signature validation products. The Common Criteria is an international standard, which evaluates the quality and reliability of security products. Certification according to this standard lends the signature process a legally binding value, and reinforces security. This standard is internationally recognized in Europe, North America, and Asia. This project represents one of Dictao’s main business strategies, and a long-term investment for the company.

Dictao’s software is qualified and certified by the FNISA (the French Network and Information Security Agency), which falls under the authority of the National Defence General Secretariat.

Dictao’s software is approved by the Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) which is under the authority of the Minister of the Economy and Technologies (BMWi).

6.5.1 DTP functionalities

The DTP platform has extended functionalities in the electronic signature field. Listed below are the principal functions for responding to electronic signature and signature validation needs:

TRACES



Personal signature on the workstation via a Java applet

DTP guarantees the deployment function for the signature applet on the user station

Personal signature on the server based on an instantly-generated certificate: XML-Dsig, XAdES, PDF/PAdES Basic, PKCS#7

Should a user not have a personal signature certificate, DTP is capable of generating and using a temporary certificate, which has a single usage and can complete a signature on the server on behalf of the user.

Signature validation : XML-Dsig, XAdES, PKCS#7, CMS, PDF, PAdES Basic

DTP ensures the validation of signatures by monitoring:

The certificate

o The recognition of the Certificate Authority

o The technical format of the certificate

o The validity of the certificate at the time of signature

o The authorization of the certificate to be used to complete signatures

o …

The validity of the signature in relation with the document

Constitution of the validation proof

After validating a signature, DTP constitutes a proof of this validation (which is also signed). Thanks to this, a trace of the information that led to DTP’s completion of this verification is maintained.

Signature timestamp (Token in the RFC 3161 format) : completion of XML-Dsig, XAdES, PKCS#7, PDF, PAdES Basic formats

The validity of the proof is reinforced by the attaching of a timestamp token. This gives a specific time to the validation operation.

Availability of a ‘user-friendly’ validation service for the validation portal

DTP displays pages which can be used to complete signature validations.

Client station eligibility verification service

The eligibility of the client station service ensures that the client station is compatible with the electronic signature function. It verifies the technical characteristics of the station, the presence of a valid certificate, etc. This operation is completed in a transparent fashion for the user.

TRACES



6.5.2 Technical characteristics of DTP

6.5.2.1 Supported OSs

DTP is an application that functions on standard OS servers (either directly, or virtually):

Sun Solaris 9

Windows Server 2003/2008

RedHat Enterprise 5.X 32 or 64 bits

Suse Enterprise Server 10 64 bits

AIX 5.3

6.5.2.2 Java platform

In addition to a Web application, DTP needs a JAVA platform to function. The following versions are supported:

JSE JDK 1.5

JSE JDK 1.6

6.5.2.3 Database

DTP functions with the following databases:

Oracle 10g R1/R2, Oracle 11g R1/R2

PostgreSQL 8.4

SQL Server 2005 SP3

6.5.3 Integration of DTP in an IS

DTP can be very easily integrated by using Web services through any supporting environment. It is possible to call the DTP services in Java from the TRACES portal.

6.5.4 DTP technical architecture

6.5.4.1 Implementation architecture

This diagram presents an example of the technical architecture for the implementation of DTP in an Information System.

TRACES



@

Reverse Proxy

Tiers archiveurs

Passerelle SMS

Portails métier

Clients

VLAN DMZ

PKI ACUSERS SGBD

VLAN LAN SGBDVLAN LAN BE

Firewall/IDS

HSM

VLAN DMZ DTP

Firewall

BUSINESS PORTAL

VLAN DMZ METIERS

Trust Platform

Security

Processing & services

BackEnd & storage

SERVEUR DTP

6.5.4.2 Architectural dimensions

The given example is based on the hypothesis of:

2 million signature validations per year

2 million timestamp tokens and constitutions of proof

Number of signatures per year equally divided on each day of the year.

With this hypothesis, DTP will operate correctly with one or two servers (Dell PowerEdge R410 dual processor Xeon E5506 / 16Go of RAM and a 500Go hard disk). This is based on an estimate, and is to be used as a reference only. The implementation phase will include a sizing stage taking into account the type of hardware used (Sun servers e.g.).

Dictao recommends implementing an extra server. This will avoid any interruptions in service during updates.

TRACES