Sharing ballistic data across Europe: A prototype network between France and Switzerland using Evofinder®.

Today, there is a real political urge to see the sharing of ballistic data intensify across Europe mostly due to recent events such as terrorist attacks. However, technical constraints remain and two main options are being discussed. The first one relies on a centralized common database, implying a vendor monopoly for all Europe and a unified protocol among member states. The second one advocates for a distributed framework relying on existing national infrastructures and leaving each country responsible for its own protocols. This article describes a prototype network linking Switzerland and France using the Evofinder® system by ScannBI. We will first focus on how this network was set up, and then report some results from tests conducted to assess the viability of the concept. These results demonstrate that the second option cannot be discarded and pave the way for a distributed network. This solution appears to be cheaper, more adaptable and answers the practical needs of member states.

Introduction

Worldwide, police databases have been growing in size, types and importance in the fight against crime. Ballistic databases make no exception. Since criminals do not stop at borders but rather use them to their advantage, sharing such information among neighbouring countries is more than ever necessary. It is especially the case in Europe where citizens are free to travel from one country to another with virtually no border control.

The idea of building comprehensive databases has been discussed [1,2] and stakeholders have come to an unassertive conclusion so far. However, progress in the field of Automated Pattern Recognition in general and Automated Ballistic Identification in particular may lead us to reconsider these statements [3]. It is to be noted that in any case interconnecting databases raises many practical problems. Countries, even regions, are equipped with different and incompatible Automated Ballistic Identification Systems (ABIS). Even among countries using the same system, coping with differences in languages, protocols, databases structures or data management policies is a challenge to rise to. The obvious solution is to send either test fires, double castings or even exhibits to the partner country for its experts to search through their national open case file. Even without considering the legal aspects of such international cooperation, many severe limitations will remain. First, it relies on postal services which are significantly slower than electronic connections and can expose sensitive exhibits to a risk of loss. Secondly, the workload falls on the agency which receives the query. These obstacles prevent such queries from being sent on a daily basis simply because it would be intractable for all partners. Sending digital images of the items only solves the first problem since their processing still falls on the receiving agency.

On the one hand, in some countries, such problems have been addressed thanks to the IBIN network which enables countries using IBIS to connect their databases to a central server. On the other hand, despite a few examples of already existing operational networks, Evofinder had long been considered as unsuitable for running an international network until we demonstrated the contrary. Imposing a single system to all member states would however be both unrealistic and non-desirable from many points of view.

During January 2018 EU EMPACT Firearms meeting in Brussel, the decision was made to establish a prototype network between France and Switzerland, both using Evofinder by ScannBI. The main goal was to establish a connection between the two countries (Proof Of Concept, POC), in order to identify the problems to be dealt with and the requirements for such a structure. The main questions this POC had to answer were the following:

What were the options offered by Evofinder to build a network? Did the network have to be centralized, or could it be distributed across different countries?

What were the technical IT specificities of such a network? How should it have been implemented in a secure and robust way?

Which parameters and protocols had to be harmonized? Did end users have to adapt their protocols and rethink their policies?

During this initial stage, legal aspects were considered but will not be discussed here. The aim was to obtain technical information first, before adapting bilateral conventions or trying to add ballistic data exchanges to the Prüm framework. As ballistic databases used in Evofinder are free from personal data and since the test would not concern any case-related data, the legal aspects could be addressed later on.

Network setup

IT considerations

Since 2016, France has been running a centralized network using Evofinder. The central server is hosted in Paris suburbs and six laboratories (5 laboratories for the National Police and the IRCGN for the National Gendarmerie) act as clients of this server. With all these clients, databases are regularly updated and queries are dealt with on a daily basis countrywide. All French laboratories have agreed on common protocols about how to integrate and process exhibits. To date, this network has not encountered any major problems. Containing more than 56,000 items, it is growing at a rate of around 10,000 items per year and has led to 413 cold hits1.

Switzerland runs a smaller network structure that has already been in place for more than 15 years and which is located within the premises of the Zurich Forensic Science Institute. To date, the Swiss Evofinder database which contains about 28,000 items, is growing at a rate of around 500 items per year and has led to 85 cold hits.

Both data storage and calculations are only performed on the servers, in a sequential way. A queueing protocol with customizable prioritisation rules deals with simultaneous queries.

Both countries operate dedicated and secure intranets protected by firewalls and strict security policies. First, it was decided to open their server to the partner country and hence to link the two servers via a Virtual Private Network (VPN). Setting up such a VPN breached several security rules, so before opening the network the experimental structures had to be understood and accepted by IT security managers and rules had to be adjusted by technicians in both countries. Setting up the VPN was achieved by the end of 2019 and a menu was made available to the end user enabling them to choose which server to send their query to (Fig. 1).

Fig. 1

Screenshot of end user work station with server selection available.

However, it was still impossible for end users to actually connect to the foreign server. Extensive testing and re-engineering of the network connection was performed to tackle this problem. Initially the following work procedure was expected: a user opened a questioned item on his work station, then selected the foreign server and sent a query. This query went to their national server which forwarded it via the VPN to the foreign server, acting as a proxy.

Eventually, it appeared that the national server did not play this role. When a user wanted to send a query to a foreign server, their national server only sent them connection information in return in order that they could directly connect to the foreign server (See Fig. 2). This conclusion further enabled IT technicians to adapt their network configuration and addressing rules.

Fig. 2

When requesting information from a partner server, the local server establishes a connection to the remote server and checks if this connection is available (see link 1). On start-up, The client application (EVidenceFINDER) establishes a connection to the local server (see link 2), receives connection data from its local server and then checks connection to the remote server (link 3). If the connection succeeds, the name of the remote server is displayed on the user interface. When the user selects the remote server's name, the connection to the local server (link 2) is closed and the connection to the remote server (link 3) is established instead2.

When making comparisons on the foreign server, the end user had to download the questioned item locally on their work station, then switch to the desired server and launch the query, just as if they would be a local client in the partner country.

For the purpose of the test, a new user profile was added on each server. These were generic profiles used by the foreign server so that there would be only one generic “French” user on the Swiss server, and vice versa. They were given read-only lowest priority “Guest” profiles. System administrators could decide on which metadata was visible to the guest user, from “Item ID” only to full access.

At that time, all Evofinder stations and servers were running Evofinder version 6.4.2.28. We have to note that major versions (two first digits, here 6.4) have to be the same to run a network between servers and clients properly2. This will have to be taken in consideration for future updates, to ensure the long-term viability of the network. IT configurations are heavily dependent on countries' and laboratories’ doctrines which means providing many technical details will not be relevant here. Nevertheless, such information can be provided by the authors upon request.

End user point of view

Once the connection is fully operational, one can browse and search from a local client through the foreign server, just as if operating on a local server. Though, some issues need to be addressed. First, all windows related to browsing data or searching the database are linked directly to the server, and are therefore displayed in the server native language. Second, Evofinder enables users to customize many fields, both labels and content. Many laboratories have seized this opportunity to tailor the system to their needs. For instance, in France a checkbox is used for regional filtering including some specificities regarding overseas territories.

Furthermore, the Evofinder database structure is adaptable with some limitations and can also be adapted to laboratories’ protocols. For instance, France has chosen to sort bullets using simple and generic class characteristics: “CIP3 calibre – Direction of twist – Number of lands – Land width (0.1 mm increment)”. Switzerland, on the other hand, has chosen different land width increments because its database is lighter than the French one (see Fig. 3).

Fig. 3

Left: Screenshot showing the Swiss database structure. Right: Screenshot showing the French database structure.

These difficulties can be of great concern when it becomes imperative to reorganize an agency's database and change protocols in order to achieve international harmonisation. This can be time-consuming and potentially error-prone. However, these difficulties can easily be overcome by providing partner countries with simple guidelines displaying translated screenshots of the main interface windows and describing briefly one partner country's protocol and sorting process. Since most of the laboratories abide by ENFSI best practices and share many methods, a harmonisation within this framework should be possible.

Repeatability test

First of all, the authors would like to recall that this report does not aim at testing Evofinder capabilities per se, but to see how it performs when dealing with different integration and research protocols.

Method

A set of 6 pistols, 9 mm Luger calibre, with six right-twist 2.0 mm wide conventional lands, round firing pins, were selected from the French reference collection3. Two test shots were fired with each gun, one with Fiocchi full-brass ammunition and one with Sellier&Bellot full-brass ammunition. This set of 12 bullets and 12 cartridge cases were acquired and processed both in France and in Switzerland. On purpose, no agreement was made about database integration or land marking protocols, and nothing was modified in each laboratory's routine. To be certain of this, items were not integrated by the authors but rather by qualified technicians who integrated them blindly.

The first goal was to look at the scores obtained by the same object depending on the country where it was integrated. It had been expected to be close to 1 since the objects were the same. The second goal was to check if there was a difference in the obtained scores for the same query depending on the direction of search.

Results

Cartridge cases which were integrated in France were searched on the Swiss server among 245 candidates and their correlation score and rank in the hit list for “breech face” score and “firing pin total” score were recorded. The reverse action was also performed, which means that for example cartridge cases integrated in Switzerland were searched on the French server among 542 candidates.

Bullets on the French database were searched on the Swiss server among 3118 candidates and vice versa, among 1375 candidates on the French server. All results about the main correlation score and rank in the hit list were recorded.

All expected hits (“clones”) were ranked in first position for both countries with outstanding scores.

Differences in scores depending on the origin of the query, (France searching on Swiss server or vice versa) appear to be minimal (see Fig. 4). For cartridge cases, the difference in both “firing pin total” or “breech face” score is less than 0.1, and less than 0.05 in 96.9% of correlations (281 scores among 288). For bullets, score differences are less than 0.1 except for one bullet, which shows a difference of 0.16. The difference is less than 0.05 in 86.1% (124 scores among 144).

Fig. 4

Scores obtained when comparing a bullet (a) or a cartridge case (b) with its “clone” on the partner country's server and differences in correlation scores depending on the sense of correlation (FR- CH or CH-FR) for bullets (c) and cartridge cases (d).

Considering these results, without prior agreement on integration and marking4 protocols, this test has shown that correlation scores are very close, no matter where items have been integrated and which of the two countries has searched the partner country's server.

Such results are promising for a wider international cooperation since it means that laboratories will not have to adapt their way of working to brand new protocols. However, these results can still be improved with minimal adjustments. For instance, two bullets registered low scores when compared to their clone in the partner country (see Fig. 4). The main explanation for this is that land impression limits had not been precisely flagged in the same way in both countries (see Fig. 5).

Fig. 5

Match detected in the groove mark by the Evofinder algorithm when comparing open case bullet 1 (TEST FR-CH Question 1) scanned in France to the Swiss network's one (Bullet “Test Netz Frankreich, SaNr.: 5425 P1″).

Mock cases

Two mock cases were generated by the Swiss laboratory. First a set of “open case” shots was prepared and acquired in one database. The corresponding set of test shots was sent (physically) to the partner country (IRCGN). Once the test shots were registered in the partner country database, the goal was to show whether Evofinder would be able to find a “hit” with its automated search function. Tests (Table 1) were conducted in both directions for each case to ensure that results were consistent regardless of the direction of the query:

Table 1

Mock case configuration.

	Open case shot firearm 1 (physically in France)	Open case shot firearm 2 (physically in Switzerland)
Test set firearm 1 (physically in Switzerland)	Mock case 1Beretta 90TWO, 9 mm Luger	Non-corresponding
Test set firearm 2 (physically in France)	Non corresponding	Mock case 2Beretta Px4 Storm, 9 mm Luger

- Mock case 1: a set of test shots from firearm 1 was sent to France and a set of open case shots from firearm 1 was kept in Switzerland;

- Mock case 2: a set of test shots of firearm 2 was kept in Switzerland and a set of open case shots from firearm 2 was sent to France.

Both test sets were obtained with two different weapons in 9 mm calibre Luger from Beretta, with six right-twist conventional lands. “Firearm 1” was a Beretta 90TWO and “Firearm 2” was a Beretta Px4 Storm. For mock case 1, open case projectile 1 was slightly deformed and therefore showed some bad marks. The deformation of this projectile was intentionally induced by firing it through a piece of wood. Open case projectile 2 was pristine and showed good marks. For mock case 2, all bullets were pristine. The aim was again not to challenge the system in itself but to stick to what a real case file could be.

Both tests were performed on Evofinder version 6.4.2.28. Both laboratories worked according to their own protocols without changing them or agreeing on a common method in advance.

The network connection has not encountered any problems. However, the responsiveness of the partner server can be slower than the responsiveness of one's own network, depending on the available internet bandwidth. The inconvenience has been barely noticeable and fully compatible with the daily routine.

Evofinder returns the scores for the possible observable marks on ammunition on different “correlation” sheets. A separate ranking is displayed on each sheet. The most meaningful marks in Evofinder for projectiles are normally the secondary marks (land marks; called “rayures” in French and “sekundäre Spuren” in German).

The most meaningful marks in Evofinder on cartridge casings are normally observed on the breech face or on the firing pin impression (called “trace de culasse” and “trace du percuteur” in French and “Stossbodenspur” and “Schlagbolzenspur” in German). Even if the system takes other marks into account, the aforementioned marks are either automatically detected or mandatorily marked by the operator during the acquisition phase. Indeed, these are the only marks that will always be present on a partner server, whatever the acquisition protocol is like. Optional marks are not always available.

Each country and each laboratory has its own policy when it comes to check the list of candidates for a potential match. There is no absolute threshold neither in score nor in ranking [4]. Nevertheless, and for the sake of clarity, we have used a colour scale to assess the ease with which the right “match” is found. If the desired hit is ranked in position:

from 1 to 5, in bold: this kind of hit will be found anyway;

from 6 to 20, in italics: depending on the policy or the workload of the expert verifying the hit list, a hit in this position might sometimes be missed;

beyond 20, reported as X: except for very sensitive cases, there is a high probability that the expert will not verify with full attention down to this rank in the hit list. A rank that low is not relevant anymore and is replaced by an “X” to show this is a missed hit.

For both kinds of items, two ranks are provided (breech face and firing pin marks for cartridge cases, land and groove marks for bullets). Obtaining a good ranking for only one of them is sufficient to find a match and thus confirm the hit.

Bullets

For mock case 1, open case projectile 1 has yielded bad results due to its poor markings compared to all the other open case bullets which were pristine. As expected, results are highly dependent on the quality of markings (see Table 2).

Table 2

Ranks in the hit list resulting from queries for bullets for mock case 1by both laboratories. Open cases were located physically in France, and test fires were located physically in Switzerland. Comparison to 6274 items on the Swiss server, and 2639 items on the French server.

Mock case 1: Bullets		Open case 1 (damaged bullet)		Open case 2 (pristine bullet)
		FR searching on CH server	CH searching on FR server	FR searching on CH server
Test fire 1	Land marks	X	X	2
	Groove marks	1	2	2
Test fire 2	Land marks	X	X	1
	Groove marks	11	6	1
Test fire 3	Land marks	X	X	3
	Groove marks	X	X	X

Additionally, correlations from Switzerland to France and vice versa have showed that corresponding bullets/marks always yield similar scores. Furthermore, the relative ranking in the hit list has been also consistent, regardless of the direction of the query. The differences observed can be explained by the fact that the number of exhibits compared was different in the respective databases. Moreover, both databases were powered by different data sets, for this reason slight differences in the results were expected and can be noticed in the provided tables (Table 2, Table 3).

Table 3

Ranks in the hit list resulting from queries for bullets for mock case 2 by both laboratories. Open cases were located physically in Switzerland and test fires were located physically in France. Comparison to 6274 items on the Swiss server, and 2639 items on the French server. Note that following the French protocol, groove marks are not marked in the system by default. The flagging of these marks is optional depending on the expert›s decision. In this respect, not all of the groove marks have been marked in this study and therefore results are partially available for comparison.

Mock case 2: Bullets		Open case 1 (pristine bullet)		Open case 2 (pristine bullet)
		FR searching on CH server	CH searching on FR server	FR searching on CH server
Test fire 1	Land marks	2	4	1
	Groove marks	1	3	2
Test fire 2	Land marks	1	3	2
	Groove marks	1	4	4
Test fire 3	Land marks	1	2	2
	Groove marks	1	2	12
Test fire 4	Land marks	1	1	2
	Groove marks	1	1	X

Cartridge cases

Initially, results were quite disappointing after Switzerland started to search for breech face results on the French server, when expected hits ranked far beyond 20 (see Table 4). The reason for these bad results was that cartridge cases are not always orientated the same way, depending on acquisition protocols in partner countries. Evofinder enables to tick a check box prior to launching the query, labelled “non-orientated”. If ticked, the system performs full rotations of the scans and automatically correlates the whole breech face marks in a 360° rotation. This necessitates longer processing time but has led to far better results (Table 5). Regarding firing pins, the above mentioned process is the default setting (see Fig. 6).

Table 4

Ranks in the hit list resulting from queries for cartridge cases for mock case 1 by both laboratories. Open cases were physically located in France and test fires were physically located in Switzerland. Comparison to 5463 items on the Swiss server, and 1663 items on the French server. The “not orientated” option was not ticked prior to launching the queries on the data base.

Mock case 1: Cartridge cases“Not orientated” optionNot selected		Open case 1	Open case 2
		CH searching on FR server	CH searching on FR server
Test fire 1	Breech face marks	X	X
	Firing pin marks	X	X
Test fire 2	Breech face marks	X	X
	Firing pin marks	5	1
Test fire 3	Breech face marks	X	X
	Firing pin marks	X	1

Table 5

Ranks in the hit list resulting from queries for cartridge cases for mock case 1 by both laboratories. Open cases were located physically in France, and test fires were physically located in Switzerland. Comparison to 5463 items on the Swiss server, and 1663 items on the French server. The “not orientated” option was ticked prior to launching the queries on the data base.

Mock case 1: Cartridge cases“Not orientated” option selected		Open case 1		Open case 2
		FR searching on CH server	CH searching on FR server	FR searching on CH server
Test fire 1	Breech face marks	2	2	2
	Firing pin marks	X	X	X
Test fire 2	Breech face marks	1	2	1
	Firing pin marks	X	5	1
Test fire 3	Breech face marks	3	2	13
	Firing pin marks	X	X	2

Fig. 6

Match in the land mark region detected by the Evofinder algorithm when comparing open case bullet 2 (TEST FR-CH Question 2) scanned in France to the Swiss network's one (Bullet “Test Netz Frankreich, SaNr.: 5425 P1″).

When observing the results obtained by “Open case cartridge case 2”, it stands out that some of the marks (e.g. firing pin mark, see Table 6) have been consistently ranked far away from position 1 although “Open case cartridge case 2” has shown consistently good overall rankings. This result indicates that the firing pin mark on some cartridge casings is only of moderate quality, which makes it difficult for the algorithm to find the correspondent cartridge case on the partner network. This hypothesis can be confirmed when manually examining the scanned pictures of the cartridge casing (see Fig. 7) in Evofinder. These cartridge cases display firing pin marks which are difficult to identify. All other visible marks, and therefore also the corresponding exhibits, are easily found in the partner database hence resulting in a good overall ranking (see Fig. 8).

Table 6

Ranks in the hit list resulting from queries for cartridge cases for mock case 2 by both laboratories. Open cases were located physically in Switzerland and test fires were located physically in France. Comparison to 5463 items on the Swiss server, and 1663 items on the French server. The “not orientated” option was ticked prior to launching the queries on the data base.

Mock case 2: Cartridge cases“Not orientated” option selected		Open case 1		Open case 2
		FR searching on CH server	CH searching on FR server	FR searching on CH server
Test fire 1	Breech face marks	1	4	2
	Firing pin marks	1	4	X
Test fire 2	Breech face marks	1	2	2
	Firing pin marks	1	3	X
Test fire 3	Breech face marks	1	1	2
	Firing pin marks	1	1	X
Test fire 4	Breech face marks	1	3	2
	Firing pin marks	1	2	X

Fig. 7

Detail of the breech face and firing pin region on two exhibits (see table 6, “Test Netz Frankreich, SaNr.: 5374 H2” compared to “TEST FR-CH RECUP 3″) with low ranking positions.

Fig. 8

Detail of a firing pin mark comparison (CC “Test Netz Frankreich, SaNr.:5425 H2” compared to “TEST FR-CH QUESTION 2”), which displays fine details hence showing a correspondence with high evidential value.

In summary, the tables provided highlight the fact that for the two mock cases, open cases can successfully be associated with at least one of the test fires for both directions of query. The prototype network should accordingly be considered as being effective for these kinds of cases. Furthermore, except for the damaged bullet, all items fired by the same weapon can be linked whichever direction of query we consider.

Conclusion

Answers to pending questions

The prototype network has proven the sustainability of a distributed, customizable and efficient network. It has also brought to light valuable insights for building such a network and has enabled us to answer the three questions mentioned in the introduction.

It has been possible to perform effective and realistic cross-border correlations. No change has proven necessary neither regarding the structures of databases nor the protocols used by the two countries. For the end user, adapting to a foreign server only requires the reading of a 2-page guideline explaining the other partner's protocol and how to find the requested information. After a few days, this guideline is not even needed anymore. Even though it is not a mandatory and constraining prerequisite, the more protocols will be harmonized across Europe, the easier the searching process in a foreign database will be.

The main challenge has been on the IT side and concerned the network configuration and security policies. An upgrade of the existing network is planned to make it more robust and easier to administrate. A rough draft of the prototype structure is provided in Fig. 9.

Fig. 9

Proposed future European delocalised ballistic network structure to be implemented from the authors' point of view. The structure can be extended to any Evofinder country willing to join.

Finally, this POC confirms previous work on and recommendations about sharing ballistic data across Europe [5,6]. This previous work states that imposing a common system and protocol to all European countries will be unrealistic and not even desirable when considering the cost/efficiency ratio and the fact that almost all hits are made within a 100 km radius around the first use of the firearm.

This POC shows that a centralised server shared by all countries is not the only option and as aforementioned might even not be desirable. Sharing a centralized server for all European partners would require a huge and expensive server, high-speed connections and strict protocols to guarantee acceptable waiting time and to manage a coherent database. To date, no structure in Europe is able to run such a network nor has the manpower to run this structure.

On the contrary, keeping the network distributed between the different countries has several key advantages. It allows countries to tailor the system to their needs. It avoids any change in their databases or protocols imposed by a third party. The different agencies remain the only host and owner of their data. They can choose what to share and whom with. Maintenance of the network will also be significantly cheaper since it will rely on an existing infrastructure which can be easily upgraded. While all countries connected to such a network remain financially and technically responsible for their infrastructures, they will have the opportunity to work efficiently and pragmatically in synergy with their neighbours. As the respective servers are available to partners in DMZ and, moreover, are distributed among partner countries and secured by them, the vulnerability of this network will be lower. On the other hand, a single central server solution could put the system at risk making it more vulnerable to hackers’ attacks.

Europol can nevertheless play a key role in such a network, e.g. by providing a central node acting both as a router and a proxy. This will solve the main difficulty we have encountered when connecting the Swiss and the French servers (above described as the IT configuration). A distributed network will require multiple connections and, with n participants, would end up with a total of n (n-1) connections to configure. A central proxy will limit these connections to n and will route the different queries to the desired partners. Furthermore, this solution will ensure both a technical traceability of queries on ballistic data and provide a legal framework for direct cooperation, for instance related to the Prüm treaty. Furthermore, it will be compatible with the above mentioned distributed architecture, and will not require Europol to hire many experts in the field.

Future work

The prototype network between France and Switzerland described in this paper has to be improved in many respects. Further tests and cross-checks are still pending. Nevertheless, the results published in this paper depict a way in which Evofinder can sustain an international network. Further steps would be to extend the network to all Evofinder-using partners willing to join. The legal aspects will have to be addressed, either thanks to bilateral conventions or through an extension of the Prüm treaty, to ballistic data. In parallel, the development of the X3P format will have to be continued, paving the way to ballistic data exchanges between countries using different ballistic comparison systems

CRediT authorship contribution statement

Cédric Sautier: Conceptualization, Methodology, Investigation, Writing – original draft. Stephan Christen: Conceptualization, Methodology, Investigation, Writing – original draft. Fayçal Chidiac: Methodology, Investigation, Validation, Writing – review & editing.

Declaration of competing interest

The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.