EVIDENCE2E-CODEX Linking EVIDENCE into e-CODEX for ......Version 1.2 Xenia Burlaca (INTERPOL) 13/02/2020 Version 1.3 Fabrizio Turchi 17/02/2010 This project was funded by the European

1/43 This project was funded by the European Union’s Justice Programme (2014-2020) under Grant Agreement No. 766468

JUSTICE PROGRAMME (2014-2020)

JUST-JCOO-CRIM-AG-2016

Action Grants to Support Transnational Projects to Promote Judicial Cooperation in Criminal Matters

Grant Agreement No. 766468

EVIDENCE2E-CODEX Linking EVIDENCE into e-CODEX for EIO

and MLA procedures in Europe

Functional, Technical Description of the Code for the Show Case

Deliverable D3.5

The contents of this deliverable are the sole responsibility of the authors and can in no way be taken to reflect the views of the European Commission

Ref. Ares(2020)991468 - 17/02/2020

www.evidence2e-codex.eu

This project was funded by the European Union’s Justice Programme (2014-2020) under Grant Agreement No. 766468

2

Document Version Control:

Version 0.1 Nikolaos Matskanis (CETIC) 29/11/2019

Version 0.2 Nikolaos Matskanis (CETIC) 23/12/2019

Version 0.3 Fabrizio Turchi (CNR-IGSG) 27/01/2020



Version 0.6 Nikolaos Matskanis 06/02/2020

Version 0.7 Alexandra Tsvetkova (LIBRe) 06/02/2020


Version 0.9 Alexandra Tsvetkova (LIBRe) 07/02/2020


Version 1.1 Eoghan Casey (UNIL) 12/02/2020

Version 1.2 Xenia Burlaca (INTERPOL) 13/02/2020

Version 1.3 Fabrizio Turchi 17/02/2010



3

Table of Contents List of Abbreviations ........................................................................................... 4 List of Figures ................................................................................................... 6 Executive Summary ........................................................................................... 7 1. Use Case Scenario under EIO ......................................................................... 9

1.1. Start of the Case .................................................................................... 9 1.2. German FL Extracts Data from the Smartphone .......................................... 9 1.3. The EP is Transferred to the German CA ................................................... 10 1.4. German CA Imports/Opens the EP .......................................................... 10 1.5. Italian CA Receives an EIO from German CA ............................................. 11 1.6. Italian FL Extracts Data from the Hard Disk .............................................. 11 1.7. Italian CA Replies to the EIO Request ...................................................... 12 1.8. German CA Imports the EP in the Existing One ......................................... 12 1.9. Summary............................................................................................ 12

2. EESP Application Overview ........................................................................... 15 3. EESP Application: Type of Uses ..................................................................... 17 4. Evidence Packaging and Unpackaging ............................................................ 20

4.1 Evidence Packaging .............................................................................. 20 4.2 Evidence Unpackaging .......................................................................... 21

5. Packaging Services: Architecture, API and Functionality .................................... 25 5.1 Packaging Services Architecture ............................................................. 25 5.2 Packaging Services Architecture and Deployment ...................................... 27 5.3 REST API ............................................................................................ 29 5.4 EESP Frontend – Packaging Views ........................................................... 33

6. Data and Metadata management .................................................................. 36 6.1 Ontology Repository Service (ORS) Architecture ........................................ 36 6.2 ORS REST API ..................................................................................... 37

7. Security, Encryption and Communication Protocols ........................................... 40 7.1 Package Encryption and Integrity Validation ............................................. 40 7.2 Communication Protocol and Access Control ............................................. 41 7.3 Data Storage Security ........................................................................... 42

8. Conclusions ............................................................................................... 43



4

List of Abbreviations

Acronym Explanation

API Application Program Interface: software intermediary that allows two applications to talk to each other.

CA National Competent Authority: A Judge, a Court, an Investigating Judge or a Public Prosecutor competent. (see the European Investigation Order, Article 2.c Issuing Authorities).

CASE Cyber-investigation Analysis Standard Expression (CASE) is a community-developed open source specification language for representing information commonly exchanged during investigations involving digital evidence and can be applied to digital forensic science, incident response, counter-terrorism, criminal justice, forensic intelligence and situational awareness. CASE is an extension of the Unified Cyber Ontology (UCO).

EC European Commission

EESP application Evidence Exchange Standard Package application is a web application for creating the Evidence Package and facilitating its exchange. The EESP application supports the UCO/CASE language.

EIO European Investigation Order.

EIO Directive Directive 2014/41/EU of the European Parliament and of the Council of 3 April 2014 regarding the European Investigation Order in criminal matters.

EP Evidence Package: encrypted archive of data and metadata (expressed in the UCO/CASE language) and may include actual data, the retrieved Electronic Evidence.

EP-CASE Evidence Package in plain text, not encrypted archive of data and metadata (expressed in the UCO/CASE language) of an Electronic Evidence.

EP-DATA Evidence Package – retrieved data container. This package is used for transferring the actual data that is retrieved using the digital forensic investigation tools and methods and can potentially serve as evidence.



5

EXEC Electronic Xchange of e-Evidences with e-CODEX European Project (GA 785818).

FL Forensic Laboratory, a private or public organisation with expertise in forensic science.

ISP Internet Service Provider.

JA National Judicial Authority (see the European Investigation Order, Article 2.c Issuing Authorities). A Judge, a Court, an Investigating Judge or a Public Prosecutor competent.

LEA Law Enforcement Agencies.

R.I. portal Reference Implementation portal. It is the portal of the e-Evidence Digital Exchange System, provided by the European Commission. It is the system able to manage the EIO/MLA procedures /instruments: e-Forms, business logic, statistics, log, etc.

UCO Unified Cyber Ontology (UCO) is a community-developed open source ontology/model, which is intended to serve as a consistent foundation for standardised information representation across the cyber security domain/ecosystem.



6

List of Figures

Figure 1 Use Case Evidence timeline starting from the bottom left ........................... 13

Figure 2 Evidence Package CASE (EP-CASE) content .............................................. 14

Figure 3 Main uses of the EESP application for communication between FL/LEA and CA 18

Figure 4 Evidence Package transfer from the FL and the CA Executing State side ........ 19

Figure 5 EESP Export functionality (Evidence Packaging) ........................................ 23

Figure 6 EESP Manifest file (Evidence Packaging) .................................................. 24

Figure 7 EESP architecture, main elements .......................................................... 25

Figure 8 The EESP Application Deployment diagram ............................................... 29

Figure 9 Export Evidence Package page of EESP Frontend with Manifest data form ..... 33

Figure 10 Downloading of exported packages ....................................................... 34

Figure 11 Package Import with package merging list open ...................................... 34

Figure 12 Examining the manifest file of imported EP ............................................. 35

Figure 13 Ontology Repository Services component (ORS) ...................................... 37

Figure 14 Document operation in the swagger interface ......................................... 38

Figure 15 Resource operations of ORS ................................................................. 39



7

Executive Summary

This deliverable, D3.5 “Functional, Technical Description of the Code for the Evidence Exchange” (hereinafter “Deliverable D3.5”) describes the architecture of the evidence packaging system for exchanging of investigation related information and evidence between Competent Authorities and Forensic Laboratories of member states that are collaborating in the investigation.

The content of this Deliverable is the following:

• Section “Use Case Scenario under EIO” describes the time line of an investigative case (Use Case) within an European Investigation Order involving Germany (Issuing State) and Italy (Executing State) in order to describe how the Evidence Package (meta data and data relating to an evidence) is prepared and transferred/exchanged between the involved stakeholders: Forensic Laboratory, Law Enforcement Agency, national Competent/Judicial Authorities.

• Section “EESP Application Overview” briefly describes the Evidence Exchange Standard Package (EESP) application that is used to prepare the Evidence Package (EP) and to facilitate its transfer/exchange, in a secure manner, between the national FL or LEA and the CA or between CAs in different member States through the Reference Implementation portal (R.I. portal) and over e-CODEX. It also provides the main use-cases of the EESP application in preparing and exchanging the Evidence Package between the involved stakeholders under the European Investigation Order legal instrument.

• Section “EESP application overview” explains the EESP application, which has the primary function of preparing the Evidence Package and facilitating its exchange via the Reference Implementation portal and over e-CODEX.

• Section “EESP Application: Types of Uses” illustrates the main context where the EESP application is used.

• Section “Evidence Packaging and Unpackaging” explains in details the two mechanisms that occur during the transfer/exchange processes.

• Section “Packaging Services: Architecture, API and Functionality” explains the architecture of the packaging services and their API;

• Section “Data and Metadata Management” describes the data and metadata management in the Evidence Package.



8

• Section “Security, Encryption and Communication Protocols” goes into the details of the security encryption and communication protocols.

• Section “Conclusion” contains the conclusion of this deliverable which summarises the obtained outcomes and issues that still need to be addressed.



9

1. Use Case Scenario under EIO

The general scenario under the European Investigation Order (EIO) instrument includes exchange of evidence between a national Forensic Laboratory (FL) or a Law Enforcement Agency (LEA) and a national Competent Authority (CA) or between two national Competent Authorities in different member States. The transfer is to be made using the Reference Implementation Portal (R.I. portal), being the user interface of the e-Evidence Digital Exchange System Project led by the EC and implemented over the e-CODEX infrastructure. Thus, in order to illustrate how to handle packing/unpacking of an Evidence to facilitate its transport in a secure manner under the framework of the scenario given above, a fictional - but inspired by a real investigative case - Use Case has been created. This Use Case demonstrates how the Evidence Exchange can take place and how the Evidence Exchange Standard Package application accomplishes this goal (see Figure 1 as a reference of the numbered points of the Use Case timeline).

1.1. Start of the Case

The Use Case refers to the child grooming, via Facebook, of a 14-year-old girl named Maria Sieland living in Berlin. The case begins in Germany following a complaint made by Maria’s parents. Maria was contacted via the Facebook chat by Mario Rossi who posed as a 15-year-old boy. Mario convinced Maria to send him an explicit photograph (naked image). Afterwards, the boy started threatening Maria, telling her that he would publish the image online if she did not send him more pictures. The frightened girl sent other pictures to Mario and the next day she spoke with her parents about what had happened. Maria’s parents reported the boy to the police and they, voluntarily, they provided the LEA with their daughter's smartphone.

1.2. German FL Extracts Data from the Smartphone

The German Competent Authority authorises the forensic acquisition of the smartphone (Maria’s parents, voluntarily, provided it to the LEA). The forensic acquisition is assigned to a German Forensic Laboratory that specialises in handling mobile devices. They use a specific forensic tool to perform the forensic acquisition



10

and to extract pertinent digital evidence from the mobile device. The German FL then uses the EESP application to create an Evidence Package (EP) containing all of the relevant data for the following actions (manual and forensic):

• the Search and Seizure of Maria’s smartphone;

• the Transfer of the smartphone from the LEA to the trusted Forensic Laboratory;

• the Forensic Acquisition carried out using the appropriate forensic tool (the output may already be represented in the CASE standard or may be converted in such a format);

• the Forensic Extraction of Maria’s mobile device data, containing both the conversation with the Facebook account under the name of “Mario Rossi” and the pictures taken with the mobile device as “Selfies”.

1.3. The EP is Transferred to the German CA

After the German FL has completed all of the forensic tasks, it transfers the Evidence Package, in a secure manner, to the German CA. The Evidence Package is first prepared using the EESP application and then made available on a secure sharing platform (provided by the Forensic Lab or negotiated/agreed by the stakeholders involved) Web. The secure URL (Uniform Resource Locator) of the Evidence Package is communicated to the German CA using different channels (phone, in person, etc.).

1.4. German CA Imports/Opens the EP

The German CA receives the EP and uses the EESP application to open/read its content, and then requests information from Facebook about the IP addresses of the account of interest under the name of “Mario Rossi”. The information that Facebook provides contains an IP address belonging to an Italian Internet Service Provider (ISP). Therefore, the German CA issues an EIO to the Italian CA, using the Reference Implementation portal, asking them to carry out a Search and Seizure of the devices of the suspect and to extract digital evidence from those seized items.



11

1.5. Italian CA Receives an EIO from German CA

The German CA shares the Facebook account information and the messages to support the EIO request to the Italian CA. On the basis of this EIO request, the Italian CA authorizes a Search and Seizure. The Italian CA provides information about the Search and Seizure to the German Public Prosecutor and requests for further instructions. Three different scenarios are possible:

• The German CA can instruct the Italian CA to send the original device (the hard disk) before taking the forensic image;

• The German CA can instruct the Italian CA to perform a forensic acquisition of the hard drive and send a forensic copy of the data with supporting documentation to Germany for analysis;

• The German CA can instruct the Italian CA to perform a forensic acquisition of the hard drive, extract relevant digital evidence from the device and send the complete Evidence Package to Germany for the final report.

In this deliverable we will consider the last scenario, in which the Italian CA assigns responsibility to an Italian FL to carry out the forensic actions including the extraction of the digital evidence from the seized devices.

1.6. Italian FL Extracts Data from the Hard Disk

Using the EESP application, the Italian FL using the EESP application creates an Evidence Package containing all data of related to the following actions (manual and forensic):

• the Search and Seizure of Mario Rossi’s device

• the Forensic Acquisition of the hard disk, carried out using an appropriate forensic tool.

The Italian FL creates an Evidence Package using the Export service of the EESP application and then transfers the Evidence Package, in a secure manner, to the Italian CA.



12

1.7. Italian CA Replies to the EIO Request

The Italian CA receives the EP, reads its content to verify that it is coherent with what it has been requested, and creates another Evidence Package using the Export service of the EESP application. The process to re-create the EP is mandatory because the secure transfer relies on the Public Key of the recipient, therefore each transfer must go through this secure process. The Export service creates all the necessary files related to the EP and the EP can be sent back to the German CA, using the Reference Implementation and via e-CODEX.

1.8. German CA Imports the EP in the Existing One

The German CA receives, along with the EIO reply, the EP prepared by the Italian CA and imports it in the existing EP containing the forensic actions carried out in Germany at the beginning of the investigation.

1.9. Summary

The above scenario, broken down in eight elements, is depicted in Figure 1 which represents the most relevant part of the Evidence timeline.

As it is explained in the Section 3 “EESP Application: Type of Uses” below, the primary aim of this deliverable is to demonstrate how the EP is exported (packaged) and imported (unpackaged) during the Evidence Exchange flow from the CA of the Executing State to the CA of the Issuing State and between the national CA and its trusted FL. In Figure 1 these actions are carried out under the following steps:

• Step 3: the German FL exports the EP and transfers it to the national CA (export);

• Step 4: the German CA imports the EP into a new package and reads its content (import);

• Step 6: the Italian FL exports the EP and transfers it to the national CA (export);



13

• Step 7: the Italian CA imports the EP, reads its content and exports it for the German CA (import and export);

• Step 8: the German CA imports the EP received from Italy into an existing package and reads the whole content (import).

Figure 1 Use Case Evidence timeline starting from the bottom left



14

Figure 2 Evidence Package CASE (EP-CASE) content

It is important to remember that the EP-CASE1 contains data and metadata related to digital evidence: Figure 2 outlines content of an EP-CASE: mostly of the information is metadata, such as the People involved in the case, the Tools used to carry out the forensic actions, and the main information about the digital Trace (e.g., file name, path, size, integrity hash value). The digital file itself is not included in the EP-CASE – it will be part of the encrypted Evidence Data (EP-DATA)2. However, in some cases, such as for a SMS Trace, the body of the message, is contained in the Evidence Package, even though it represents digital evidence, rather than just metadata.

1 Evidence Package in plain text, not encrypted archive of data and metadata (expressed in the UCO/CASE language) of an Electronic Evidence. 2 Further referenes are given in Section 4.1 Evidence Packaging



15

2. EESP Application Overview

Considering the importance of the use of a standard for the representation of the Evidence Package, it is necessary to rely on an application that is able to supports that standard. In our case this is the CASE/UCO language. Thus, this is the primary aim of the EESP application.

The main features of EESP are:

• it supports the CASE/UCO language, being a standard for the representation of the Evidence Package meta data;

• it is a web application for managing the EP;

• it aims at preparing the EP and facilitates its exchange via the Reference Implementation and over e-CODEX.

The functional requirements for the EESP application have been defined in the tasks and workshops organized under EVIDENCE2e-CODEX WP3 ‘Matching EVIDENCE into e-CODEX and Linking to Other EU member States’ and have been reported in deliverables D3.1-D3.43. A summary of the application’s requirements is provided below:

• import, handle and integrate cyber-investigation analysis information;

• import and handle outputs of forensic analysis tools;

• use a standard representation language as a data model and as serialisation/representation format for the cyber-investigation elements;

• present the cyber-investigation actions and forensic procedures including Chain of Custody and Chain of Evidence;

• create Evidence Packages for the exchange of cyber-investigation files (data and metadata) via the Reference Implementation and e-CODEX;

• open and import contents of EPs.

The architecture of the EESP application has been described in D3.2 “Interim Workshop on Electronic Evidence Standard Package Application with Digital

3 Namely D3.1 “Interim Workshop with Digital Forensic and Legal Experts on the Formal Language for the Evidence Exchange Representation”, D3.2 “Interim Workshop on Electronic Evidence Standard Package Application with Digital Forensic and Legal Experts”, D3.3 “Final Workshop with Digital Forensic and Legal Experts on the Formal Language for the Evidence Exchange Representation”, and D3.4 “Report on Options for Large File Handling”.



16

Forensic and Legal Experts” and the additional features and status of integrated components are described in D3.3 “Final Workshop with Digital Forensic and Legal Experts on the Formal Language for the Evidence Exchange Representation”.

In the present document we provide information about the architecture and API of the packaging components responsible for creating and managing the EP. These include the authentication and access control service, the package downloading service as well as the Manifest file supported by the packaging service. As a reminder, we provide Figure 7 as an overview of all the components and modules of the EESP Application.



17

3. EESP Application: Type of Uses

Before delving into the details on how the EESP application provides the Export (packaging) and the Import (unpackaging) of the Evidence, it is essential to give a rundown of the uses of the application. Important features of the EESP application include, but are not limited to, the following:

• creating an Evidence Package, after a Search and Seizure;

• importing a report from a forensic tool in an Evidence Package, after a Forensic Acquisition;

• reading the contents of an Evidence Package;

• importing (merging) an Evidence Package from the CA of the Executing State into the Evidence Package already in the hands of the Competent Authority of the Issuing State;

• exporting an Evidence Package, for its further Exchange.

The main uses of the EESP application for the communication between FL/LEA and CA are depicted in Figure 3. For the purpose of this deliverable an emphasis is placed on phases 3 and 4 indicated in Figure 3 as the packaging and the unpackaging of the Evidence are attained during the Export and Import processes.

• The Export is carried out when there is the need to transfer the EP after its preparation in a secure manner.

• The Import is carried out in several circumstances such as:

o Importing a report from a forensic tool in an empty EP-CASE (e.g. after a Search and Seizure);

o Importing an already existing EP-CASE containing only the Search and Seizure meta data (after a Forensic Acquisition/Extraction);

o Importing an EP-CASE into an already existing EP-CASE, as per the Use Case described in Section “Use Case Scenario under EIO” above. The investigation begins in State A, where an EP-CASE is created, and then the investigation continues in State B (being the Executing State of the EIO), where a second EP-CASE is created as a result of the forensic activities carried out in the Executing State. Finally, the two EP-CASE must be merged into a single EP-CASE package containing all the Evidence data and meta data related to the investigative case.



18

In this context it is most important to explain how the EESP can (a) import/reads an EP (encrypted EP-CASE), and its correlated data, and (b) export an EP with all the information (data and metadata) necessary for preparing its transfer/exchange.

Figure 3 Main uses of the EESP application for communication between FL/LEA and CA



19

Figure 4 Evidence Package transfer from the FL and the CA Executing State side



20

4. Evidence Packaging and Unpackaging

The transfer/exchange of the Evidence Package can occur in two different conditions:

• The EP must be transferred/exchanged between the FL/LEA and the national Competent Authority. In this case there is no secure infrastructure to attain the goal, so it relies on a secure channel (SSL/TLS) over the Internet

• The EP is already in the national Competent Authority hands and it must be exchanged to a Competent Authority of a different member State, using the R.I. portal, relying on the secure e-CODEX infrastructure.

From packaging/unpackaging perspective it does not make any relevant difference, because in both cases the EESP application will export the package before the transfer/exchange and import the package for its reading when the package reaches the recipient, regardless of the channel used for the exchange. For the purpose of explaining the packaging/unpackaging processes, it is sufficient to describe the flow that occurs between the FL/LEA and the national Competent Authority. The scenario which is taken into consideration is the one where the FL/LEA and the CA use different information systems. Therefore, the EESP application is separately installed in both the FL/LEA and the CA’s systems, but no data/database is shared except for their Public Key to support encryption and guarantee a secure transfer/exchange.

The process starts with an EP-CASE containing all of the data and meta data related to the case under investigation. The FL/LEA has completed the forensic action (search and seizure, acquisition, extraction, analysis) and it must prepare the Evidence Package (data and metadata) to be transferred to the national CA.

4.1 Evidence Packaging

The Forensic Lab/LEA prepares the package, using the Export functionality provided by the EESP application. The package contains the following files:

1. the EP: the EP-CASE meta data related to the evidence, expressed in CASE-JSON format, encrypted with the symmetric key (SK), being automatically generated at random by the EESP application. The symmetric key is generated using the AES block cipher that works on 128-



21

bit blocks and use a 128-bits (16 bytes) key length. It is also possible to use a 192-bit key, or 256-bit key. All three of these options are considered secure according to today’s standard;

2. the EP-DATA: is the package with the data related to the evidence, compressed in ZIP format and encrypted with the same SK used for the Evidence Package. For clarity in this section we will call it EP-DATA-ZIP-ENC. If the data size is greater than 2GB4 the EP-DATA file is treated as a Large File5 and for clarity we will name it the EP-LARGE-FILE-ZIP-ENC. Again, this large data file is related to the evidence, compressed using the ZIP algorithm and encrypted with the same SK used for the Evidence Package.

3. the EP-MANIFEST-RECEIVER-PKI: the Manifest of the Evidence Package (see Figure 5), encrypted with the Public Key (PKI) of the Competent Authority of Executing State.

Details of the EESP FL/LEA side workflow are shown in Figure 4.

From the technical point of view the Export functionality is accomplished using a set of REST API, see details in Section 5 “Packaging Services: Architecture, API and Functionality”.

When the Evidence Package along with the corresponding Evidence Data are ready, they will be transferred to a secure online platform, owned by the FL/LEA or property of external providers. The online location and associated access credentials are communicated to the national CA, using a different channel (e.g. phone, in person). The security levels, confidentiality, integrity and authenticity, are provided by the mixed encryption systems described above via the secure symmetric key and the public key of the recipient.

4.2 Evidence Unpackaging

Once the Evidence Package and its data are downloaded from the secure online platform, the national CA has to open the package (unpackaging) and reads its content because the national CA must check the content of the package before sending it to the CA of the Issuing State. The national CA opens the package, using

4 The current size limit to exchange files on e-CODEX infrastructure. 5 See Deliverable D3.4, Report on Options for Large file Handling, for further details on handling Large File of Evidence.



22

the Import functionality provided by the EESP application. In this specific case the Import begins with an empty EP-CASE, and follows these sequential steps to accomplish the Import functionality:

1. the EP-MANIFEST-RECEIVER-PKI file is decrypted, using the national CA Private Key (it is provided to the EESP), then the content of the EP-MANIFEST is read;

2. the integrity of EP, EP-DATA-ZIP-ENC or EP-LARGE-FILE-ZIP-ENC (if data size greater than 2GB), is verified, using the correspondent’s integrity hash values stored in the EP-MANIFEST. In case of mismatching hash values an error is displayed, and the process stops;

3. the EP and the optional EP-DATA-ZIP-ENC or EP-LARGE-FILE-ZIP-ENC, are decrypted using the SK stored in the EP-MANIFEST.


Figure 5 EESP Export functionality (Evidence Packaging)



24

Figure 6 EESP Manifest file (Evidence Packaging)



25

5. Packaging Services: Architecture, API and Functionality

5.1 Packaging Services Architecture

The Packaging API is a collection of services for accessing and creating the Evidence Packages (EP, EP-DATA files). The Packaging services architecture uses a task manager service that assigns the packaging operations to service task workers. The packaging services and their deployment is summarised in the components diagram of Figure 7.

Figure 7 EESP architecture, main elements



26

The packaging services include:

• Web Service Interface (REST API). A web service developed in python that exposes an interface for applications to integrate and use the packaging services.

• Task Manager (RabbitMQ (Pivotal, 2019)). A service for managing the packaging tasks that are assigned to the Celery workers.

• Packaging & Encryption module – the service task worker - for background task processing (Celery Community, 2019). This module is a Celery worker and is responsible of contacting the repository for exporting the case document, collecting the attached to the document files and creating a zip archive with all these files. The zip archive is then encrypted and stored until it is retrieved by the user.

• Encryption is performed using the symmetric key method and the AES256 algorithm. The library that we use for the encryption is the GnuPG6 and the details are explained in Section 7 ‘Security, Encryption and Communication Protocols’.

• Un-packaging module. This is a task also for the Celery worker, which in this case it is executing the reverse procedure to unpack the Evidence Package: decrypt the package, unzip the archive and import the case files into the repository.

• Package Hosting Service. This is a file hosting service for the EP and EP-DATA. The files are stored for only until they are imported or downloaded. This type of service is required as the encryption of large packages can take a long time.

• Notification Service (partly implemented). Currently the notification service is partially implemented using the functionality of the Task Manager component.

• Manifest File and Package Validation. The Packaging services to support the Manifest file generation, include supporting tasks for the Task Workers, comprising:

6 https://gnupg.org



27

o calculation of the MD5 hashes of the packages before their encryption, as described in RFC 13217;

o creation of the Manifest file in the outgoing directory that currently includes the EIO number, the hash calculation, the internal/national identifier, and the issuing and executing state. These are only a subset of the manifest file schema that is presented in Figure 6. A sample manifest information, provided below, has been generated during the demonstration by the Packaging service:

{ "issuingState" : "Germany", "EP-hash": "89a7399069f2c64875092ac601947b06", "EP-data-hash": "1d7b6457ab3ca386c7cf8a6c7fc56d54", "eio": "DE-IT-Response", "EPDataURL" : "https://evidence2e-codex.cetic.be/packaging/download/paolo/...” "nationalId": "FA3656",

"ep_symmetric_key": ".>M[726:eWgy627:$)D&9ptW+:crQ3w", "executingState" : "Italy" }

o validation of the MD5 hash when importing evidence packages. This functionality at the time of writing of this document is under development and not demonstrated at the workshop.

• Keys service is a repository of known public keys. The list of keys is used by the frontend so that the users can choose the key for encrypting the Manifest file.

5.2 Packaging Services Architecture and Deployment

For the purposes of demonstrating the application and providing an example integration with user management systems, we have deployed the EESP Application and its packaging services at the CETIC server (https://evidence2e-codex.cetic.be) with an authentication service and a basic access control service. The authentication and access control services are implemented using the PassportJS8 library and the appropriate mechanisms at the Ontology Repository Services and Packaging Services. In addition, the services that have been deployed at the CETIC server for demonstration purposes are only using HTTPS so that all communications between the server and the clients are encrypted. HTTP requests

7 https://tools.ietf.org/html/rfc1321 8 http://www.passportjs.org



28

are redirected to the HTTPS port. HTTPS and password authentication and access control is the default approach for deploying the services.

The application is setup for two deployment setups of the services, a local for testing and a “production” configuration using the NginX server9.

The deployment of the services using the NginX server is depicted in Figure 8. In this deployment configuration NginX is responsible for routing of all requests going to the EESP and authenticating them using the authentication token that clients have obtained from the authentication service. Non-authenticated requests are blocked, except for acquiring authentication.

The NginX server and the frontend application expects to find the services at the following endpoints:

ORS repository service: https://servername:18080/repository

EESP Application fronted: http://servername:4200/

Packaging services – Packaging API: https://servername:5000

Packaging Services – EIO API: https://servername:5001

Packaging Services – Key service: https://servername:5002

Authentication Service : https://servername:3456

9 Nginx (pronounced "engine X") is a web server which can also be used as a reverse proxy, load balancer, mail proxy and HTTP cache. Nginx is free and open-source software, released under the terms of the 2-clause BSD license.



29

Figure 8 The EESP Application Deployment diagram

5.3 REST API

The following table provides the Representational state transfer programming interface or REST API10, which provides the programming specification of the packaging services. The packaging services as RESTful Web services, can be called using the HTTP methods (GET, POST, PUT, DELETE), the requests are made to their endpoints (URL of their resources) with certain parameters and will elicit a response with a payload formatted in JSON or encrypted ZIP archives for the packages (EP, EP-DATA) and the encrypted manifest file.

10 https://en.wikipedia.org/wiki/Representational_state_transfer


HTTP Method

Resource Action Endpoint Parameters

POST Imports an EP, by running the unpackaging

workflow and calling the document/import

method of the ORS REST API.

/packaging/import Filename: Package file name

encKey: key for decrypting the package

encAlgo: Algorithm of package encryption

dataHash: the md5 hash string of the DATA

archive

EPHash: the md5 hash string of the EP

Graphid: the investigation identification

string

Returns:

JobId -> job identifier

GET Polls the progress status of the unpackaging

and importing tasks

/packaging/import/progress

Request:

Jobid: job identifier

Returns:

Status={STARTED, RETRY, PENDING,

SUCCESS, FAILURE}

Progress %


HTTP

Method

Resource Action Endpoint Parameters

POST Creates the EP package and supporting EP-

DATA, EP-Manifest files.

/packaging/export Uri: investigation identifier

resource: root resource

encAlgo: encryption algorithm

recipient: recipient public key identifier

userId: user identifier

GET Lists contents of “incoming” folder, should be

the e-codex incoming folder or equivalent.

/packaging/incoming

GET Lists contents of outgoing folder of specific

user

/packaging/outgoing/

Username: string, the id of the user

GET Downloads an EP with the given filename that

was generated by the specified user

/download//

Username: string, the id of the user

Filename: the name of the file that the user

wishes to download

GET Downloads the DATA archive that was

generated by the specified user

/download-

data//

Graph: the id of the investigation

Filename: the file name for download.

POST Uploads one or more files in the given path /upload Path: user’s uploads path

Files: one or more files to upload

GET Unzips an uploaded DATA file that is attached

to an investigation graph.

/upload/unzip//

Filename: the name of the file to unzip


The following table provides the REST API of the keys service that handles the public keys repository:

HTTP method Endpoint Explanation Parameters

GET /key/ retrieves, available keys Username

PUT /key Updates a key username, key pairs in JSON

POST /key Inserts a key username, key pairs in JSON

DELETE /key Deletes a key Username , key id

The REST API for managing the list of the imported packages is provided by the following table:

HTTP method Endpoint Explanation Parameters

GET /eio/ retrieves, available packages username

PUT /eio Updates an EIO package username, eio pairs in JSON

POST /eio Inserts an EIO package username, eio pairs in JSON

DELETE /eio/ Deletes an EIO package Username , eio id



33

5.4 EESP Frontend – Packaging Views

The EESP Application frontend has reached its third prototype version (v0.3.3). The pages of the application and the way it presents the data (data views) has received substantial improvements both on their look and feel and also on their functionality and application behaviour.

Another new feature of the EESP frontend is the support of the manifest file in the Import and Export pages. The Export Evidence Package page includes manifest file information form, which users can complete to add this information into the manifest file (see Figure 9). Support for the downloading service has also been added (see Figure 10).

Figure 9 Export Evidence Package page of EESP Frontend with Manifest data form



34

Figure 10 Downloading of exported packages

The Package Import form is automatically filled in when the manifest file is available and is imported. If the manifest file is not available, the user has to fill in the form to provide the required information (see Figure 11).

In any case the users need to provide the unique identifier of the imported investigation data. The functionality of merging two packages is available to the users by selecting the same root document identifier for the two packages. This feature is indicated to the user when importing a package, and the list of available packages available to merge with is updated each time in the import form (see Figure 11).

Figure 11 Package Import with package merging list open



35

Figure 12 Examining the manifest file of imported EP



36

6. Data and Metadata management

6.1 Ontology Repository Service (ORS) Architecture

The Ontology Repository Services (ORS) is an open-source tool for generating ontology-based web services for web applications. It is developed by CETIC and is available at https://github.com/cetic/ORS. The architecture of the ORS as a backend for the EESP Application has been described in D3.2 “Interim Workshop on Electronic Evidence Standard Package Application with Digital Forensic and Legal Experts”. As reminder, we provide the architecture diagram that lists all of the components of ORS. The main components are:

• The ORS Protege Plugin. It is used to generate from the CASE Ontology, the Restful Web services and the convertor component from JSON to RDF. It enables easy and fast upgrade of the EESP to the newest developments of the CASE specification and supporting ontology.

• The REST API component generated by the ORS Protege plugin

• The Java JSON-LD library for converting the contents of the ORS Repository to JSON-LD and vice-versa.

• The FUSEKI triple-store that is the RDF Repository for the ORS and EESP Application. The Jena TDB store can also be used especially in production environments.



37

Figure 13 Ontology Repository Services component (ORS)

6.2 ORS REST API

For facilitating the debugging of the EESP application, integrating the EESP with other systems (for example the R.I. portal) and developing new interfaces and features, we have deployed a graphical interface for browsing and testing the ORS Rest API operations. Screenshots of the graphical interface are provided in Figure 14 and Figure 15. In Figure 14 we can see the document operations such as the import/export, their parameters and return values.



38

Figure 14 Document operation in the swagger interface

Figure 15 shows a subset of the resource operations. For each concept in the CASE ontology a GET (retrieve a resource), PUT (update functionality), POST (create a resource) and DELETE operations are available and generated by the ORS. All resource operations have the URL parameter that refers to the investigation identifier and the “id” parameter that refers to the identity of the resource.



39

Figure 15 Resource operations of ORS



40

7. Security, Encryption and Communication Protocols

7.1 Package Encryption and Integrity Validation

To support the secure transfer of the Evidence Package between a Forensic Laboratory and a Competent Authority, Executing State side, the following proof of concept solution is implemented:

1. the EP and EP-DATA are encrypted with a Symmetric Key (SK) by the Forensic Laboratory, Executing State side;

2. the SK is stored in the manifest file (MF) in the element Symmetric Key. The MF is then encrypted with the Public Key of the Receiver (Competent Authority, Executing State side).

3. the Competent Authority, when they receive the Evidence Package along with its Manifest, can decrypt the MF and get access to the SK for opening the Evidence Package, using the EESP application, to verify the integrity of the content and, optionally, view its content;

4. The Competent Authority prepares, using the EESP application, the Evidence Package and generates another Manifest file, where the element Symmetric Key of the MF will contain SK and will be encrypted with the Public Key of the new Receiver (Competent Authority, Issuing State side).

In this way it will also be possible to manage the scenario related to the Exchange of Large File of evidence because Large File containing digital evidence is encrypted with the same symmetric key generated for the Evidence Package exchange and so that encryption key could be used to open the file, once it is downloaded.

For the encryption and decryption of the EP and EP-DATA with the Symmetric key and also for the encryption of the Manifest file with the public key of the receiver the GnuPG library is used. The GnuPG11 is a complete and free implementation of the OpenPGP standard as defined by RFC488012 (also known as PGP). GnuPG allows encryption and signing of the packages and the communications; it features

11 https://gnupg.org 12 https://www.ietf.org/rfc/rfc4880.txt



41

a key management system, and has access modules that allows it to be integrated with several implementations of public key directories.

The EESP application uses the Message-digest algorithm (MD5), a hash function producing 128-bit hash value, as a checksum to verify the integrity of the package files (EP, EP-DATA). The hash value of the packages is stored inside the - encrypted with the receiver’s public key - manifest file for verifying the data integrity when receiving the package files (EP, EP-DATA).

7.2 Communication Protocol and Access Control

The EESP web application client and the EESP services use the HTTPS protocol transmission of the requests and responses. The HTTPS is used for secure communication over a computer network. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS)13 or, formerly, its predecessor, Secure Sockets Layer (SSL).

For the purposes of demonstrating the application and providing an example integration with user management systems, we have deployed the EESP Application and its packaging services at the CETIC server (https://evidence2e-codex.cetic.be) with an authentication service and a basic access control service. The authentication and access control services are implemented using the PassportJS14 library and the appropriate mechanisms at the Ontology Repository Services and Packaging Services. Due to lack of time, only limited features of access control have been deployed in the demonstration server. In addition, the services that have been deployed at the CETIC server for demonstration purposes are only using HTTPS so that all communications between the server and the clients are encrypted. HTTP requests are redirected to the HTTPS port. HTTPS and password authentication and access control is the default approach for deploying the services.

13 https://tools.ietf.org/html/rfc2818 14 http://www.passportjs.org



42

7.3 Data Storage Security

The temporary storage service (see Figure 7) holds the encrypted package files that are ready for transmission and deletes them as soon as they are requested. This ensures that even encrypted the files are not stored in the backend services. The access to the encrypted files – for the purposes of the prototype – is “anyone with the link”. This can be changed in deployments of the services “in production” environment where only authorised users could access the files.

Regarding encryption of the data that is held in the server (encryption “at-rest”) - that is mainly the user provided RDF data, that are held in the triplestore repository and the data that are in the relational/document database - the following solutions are being investigated:

• Triplestore data. A state of the art research on best practices and methods for encrypting triplestore data (RDF) will be required as future work for investigating the best approach or guidelines for a secure encrypted implementation of data “at-rest”. This approach may not be suitable for all deployments and should be evaluated for each deployment use-case.

• Document/Relational Database. For the purposes of the CETIC deployment we have chosen MongoDB a document database (see D3.2) as storage for the user data. The database uses SSL/TLS protocols for network communications encryption, which ensures secure “in-flight” communication between the database and the client. MongodDB Enterprise edition supports encryption of data at server side (or “at-rest”). It is up to each deployment use-case to enable the encryption “at-rest” functionality, which is available at additional cost.



43

8. Conclusions

This report describes the typical digital Evidence Package exchange scenarios, considered and demonstrated in the project, involving two competent/judicial authorities of different member States and also national appointed Forensic Laboratories or LEA to carry out forensic activities. The report also provides the details of the software components that have been used to facilitate and implement this exchange through the EESP application that supports the CASE/UCO language. The latter is the most promising standard in the digital forensic domain.

The primary aim of the EESP Application has been to adopt a “standard” specification language that is widely supported by practitioners, industry and academia for representing information commonly exchanged during investigations involving digital evidence. In this context, Chain of Custody of the evidence and the Chain of Evidence are particularly important aspects covered by the standard language. The CASE/UCO language has been selected for these purposes. The CASE/UCO language is used both as a data model for the application and as a serialisation format for the cyber-investigation data. Thus, the ORS backend is a natural choice as it is able to generate services from the CASE/UCO language itself and also store the CASE/UCO represented data in its native format.

The main feature of the EESP application is the creation and import of Evidence Packages and their accompanying data (EP-DATA) for the exchange of cyber-investigation information between authorities of EU member States. This document described in detail the architecture, interface and some implementation aspects (security, encryption, communication protocols) of the packaging services of the EESP application. The packaging services are the components that enable the features of the application for packaging/unpackaging or the export/import of Evidence Packages features of the application.

The priority of the development team was to implement the EESP application features that are required for the evidence exchange scenarios described in the Section “Use Case Scenario under EIO” of this document. Thus, the development of the EESP application focused on the Evidence Package import, generation of packages, and browsing of package contents. These features, as well as technology that is necessary for the scenarios, has been put in place and was made available for testing at the project workshops and to practitioners that collaborated with the project.

Documents

EVIDENCE2E-CODEX Linking EVIDENCE into e-CODEX for ......Version 1.2 Xenia Burlaca (INTERPOL) 13/02/2020 Version 1.3 Fabrizio Turchi 17/02/2010 This project was funded by the European