ES2587584B2 - Digital witness: Procedure and devices for the secure management of electronic evidence with binding credentials - Google Patents

Abstract

Digital witness: Procedures and devices for the secure management of electronic evidence with binding credentials. The invention relates to a device for the secure management of electronic evidence with binding credentials (digital witness) on which the user or object that obtains, generates or receives evidence delegates his identity in a binding and indissoluble way through binding credentials characterized by comprising an operations manager between the user or object and the device, cryptographic mechanisms accepted within a secure element, secure storage media with access control, protected in a secure element (trust core), an electronic evidence manager for objects, and, optionally, a contractual manager. The invention also relates to procedures that make use of said digital witnesses and that include obtaining, signing, storing, delegating and, where appropriate, erasing electronic evidence.

Description

Digital witness: Procedures and devices for the secure management of electronic evidence with binding credentials

TECHNICAL SECTOR

The present invention relates to procedures and devices for the secure management of electronic evidence, particularly for the secure management of electronic evidence with binding credentials, more particularly related to the field of forensic computing.

STATE OF THE TECHNIQUE

Mobile user devices are strongly rooted in the heart of society. Indeed, social networks and education in new technologies have greatly promoted the acceptance of personal devices as part of our daily lives. They are, from the functional point of view, an extension of our human capabilities, since in them we store images, projects and data that, although they could have their physical version (eg the simile between a handwritten letter and an e-mail) , in their virtual version they are always available, with us, and they are considered private data whose access is even regulated by laws, such as the organic data protection law (LOPD) for access to personal data.

Inevitably, forensic analysts have adapted to take advantage of this attachment to new technologies. In the case at hand, mobile devices are a very valuable source of information about an individual, and when they are processed as evidence containers, evidence of an evidentiary nature can be extracted - electronic evidence that sheds light on an open case.

In the current paradigm, the manipulation of electronic evidence is a very delicate process. Due to the volatile nature of this type of evidence, there are much more comprehensive procedures to prevent electronic evidence from being repudiated as evidence. In fact, as a general rule, the acquisition of evidence in the most sensitive cases is carried out by authorized justice personnel, and, in the definition of Si.'ilemaS of Electronic Evidence Management (SGEE), given in The multi-noffi13 UNE 71505: 2013, emphasizes the owner of digital evidence and people as responsible [1].

Although the management of electronic evidence is quite regulated, we believe that it could be considerably improved if the latest technological advances that confer security architectures on mobile user devices are further exploited and, therefore, prepare them much better than the architectures. traditional to witness some facts.

For example, mobile devices are equipped with sensors that allow measurements of their environment, and their density allows this data to be contrasted by other devices. These measurements can be as heterogeneous as the sensors in mobile devices, and go as far as the communications protocol, network density, and collaborative applications that manage such data allow. Although cases of deception are frequent and in fact numerous works address this problem [2], it is also true that new advances in security architectures allow certain devices to be provided with a core of trust, which would be able to confess behaviors inappropriate even from its user.

This fact, which could be considered contrary to the principles of privacy, can be used to increase a user's privacy over manner. From hec ho, the use of these trusted core devices, supported by hardware-shielded chip storage against modifications (anti-tampering), is being used to shield users' personal data on mobile terminals.

From the point of view of forensic computing, these mechanisms make it very difficult to extract digital evidence, but they open a new framework and very interesting possibilities. And it is that these reliable devices can be very robust and reliable to witness or guard electronic evidence. For example, the window of time since an event occurs on the network and this event is lost may be small enough so that the electronic evidence of the event is lost before it can be captured and guarded by an authorized person, who has of moving or accessing the affected environment and taking the evidence. First, from a point of view of preserving the scene, any new access while an event happens can alter the data and evidence, and, second, it seems more reasonable that cases can be defined in which the evidence can be guarded by reliable devices, which are already on the scene, until they can be delegated to an official custodian.

The electronic evidence life cycle (CVEE) typically consists of six steps, defined in [1]: generation, storage, transmission, recovery, treatment and communication, which we have divided into two groups based on their immediate relationship.

First, the generation of electronic evidence can rely on the use of forensic methods and techniques. However, the concept of evidence is very broad, an application log or an image could be electronic evidence. How evidence is generated can prove or detract from credibility to the value of the evidence. But, in any case, the generation of evidence entails the storage of it. This is also a critical step, since, if there is a possibility that electronic evidence could have been manipulated by unauthorized agents, or modified in some form, it could lose its value as evidence in litigation. Also the phase of transmission of electronic evidence is subject to interpretations of this type. How electronic evidence is transmitted may lead to doubt of its reliability. At this point, aspects such as the format used, its traceability to third parties, transmission security, etc. are considered. Ensuring the integrity and reliability of the test, and the policies for its transmission to authorized entities, is essential at this point.

The second group of steps could take place after a while since the evidence was stored or transmitted to an authorized entity. Thus, electronic evidence must always be available to authorized personnel who request it. guaranteeing its recovery. For this the availability requirement is fundamental. After this step, the methods for the electronic evidence are established, the processes by which the facts are extracted. This step may lead to the correlation between different electronic evidences. The evidence must maintain its integrity. Normally the usual process is to treat digital copies of electronic evidence. The results of this process must be prepared from impartiality.

Finally, the communication step is intended that impartial facts that reflect electronic evidence be used in its communication in litigation, to resolve disputes between the elements involved, or internally to improve the organizational and security policies of organizations

Throughout the CVEE, the properties of data reliability and integrity of electronic evidence must be guaranteed, as well as preventing unauthorized entities from accessing the data. If the electronic evidence at some point in the cycle is capable of being modified without demonstrating its integrity, then the chain of custody would be compromised and the evidence would be meaningless as evidence in a trial, because it is easily refutable.

The concept of digital witness defined in the present invention arises from the need to cover open challenges in Electronic Evidence Management (GEE) to accommodate 10T scenarios. Some of these challenges follow from! work [3], where the concept of 10T-Forel1sics is defended as something new, which contemplates from the most restricted objects in resources to the eloud. As a result of this work, it is already perceived that the GEE in these environments has to consider additional requirements to the traditional GEE. This is because lol 'is a dynamic, heterogeneous and distributed environment, and the requirements of identification, preservation, analysis and presentation of the GEE require fine-grained control over computer data, difficult to provide in 101'. For example, work [4] identifies some of the open challenges for GEE in lor taking these requirements into consideration. Among these challenges are: identify where the information comes from and who generates the data, the local storage of data in things, the transfer of evidence between objects and how the chain of evidence is preserved. It also points e! possible inconvenience of the figure of suppliers of lor, that would store data of the devices, complicating e! preservation process Another open challenge is the forensic analysis of identifiable artifacts (evidences) in objects. The extraction of evidence from objects is not only not defined in its entirety (for example, in the case of sensors), but it is faced with presentation formats of the information of objects that can differ considerably according to the standard employee.

Various works combine efforts to define models for the acquisition of electronic evidence on mobile devices [5], or to standardize the presentation and formats for e! exchange of electronic evidence [6]. The preservation of electronic evidence through the Digital Chain of Custody (eeD) concept is used in other works as in [7], [8]. The objective of a CCD is to streamline the concept of chain of custody by allowing the sending of electronic evidence through computer equipment using security measures, for example, included in standards such as UNE 71505 [1]. However, the concept of CCD is still very recent, and does not consider the particularities of the lor; Currently the objects could not be participants without compromising the CCD. In (7] an eCD is proposed to send digital digital evidence with time stamp to an entity through the Internet, while in [81 a CCD is proposed that considers tag tags to mark the evidence and facilitate its recovery in the previous step to the analysis In the latter case, the CCD is represented in the access to the data In (9) a state of the art is provided on the last works in the matter of CCO In this work it is reflected that the CCD follows an orientation towards traditional communication architectures, where electronic evidence management is carried out by unrestricted resources equipment, and mobile devices, despite integrating security architectures, remain within this chain as mere containers of evidence, and, in case of to participate (eg to send the evidence through the Internet), the process requires direct user intervention at all times.

However, the requirements to make use of a CCD in 101 'considering the security characteristics of the objects to guard the evidence have not yet been discussed, much less the collaboration between custodial objects. However, we believe that this is a basic step to expedite the intervention of people in the management of digital evidence.

In addition to these works, the concept of identity of things, or Idel1lities of fhil1gs (1 DoT) is being widely discussed [10] before the proliferation of devices, to define the relationship between the devices and their users. In fact, as detailed in [10], the identity of the objects speeds up the tasks of authentication, authorization, and presents challenges in the management of said identities and the privacy of individuals.

Another challenge in the GEE for 10T is the mass storage of electronic evidence. Initiatives such as the EVIDENCE project (Europeal1ll1formatics Data Exchange Framework for COllrls alld Evidellce) focus their efforts precisely on the search for a unified framework to collect and share electronic evidence. Adapting these types of approaches to collaborate with SGEE defined for what could mean a great step for distributed approaches such as the one we propose in this work.

Forensic computing in personal devices emerges as a natural evolution of traditional foren computing, so it inherits part of the checks and analyzes on storage units [11], [12], [3]. Forensic analysis can be (i) on the device (which would act as an evidence container), (ii) on the network (where traffic analyzers could come into play, and in turn, can be carried out in (a) live) when the foren procedure does not interrupt the operation of the device from which the evidence is extracted, or (b) dead (when the evidence is obtained from a device with no function other than that of being analyzed, for example when the data of a partition of a requisitioned hard disk [13], [14]). Analyzes of the latter type occur once the crime has occurred, offline, while type (a) analyzes usually aim to process the evidence as soon as possible and may even combine them with intruder detector systems, storing events of these systems as possible evidence.

Hardware security devices designed to safeguard critical information such as passwords, passwords, etc. , have evolved considerably fast since the appearance of the first cryptographic tokens. These were linked to the user, while other subsequent designs allowed to provide a core of trust (core-o! Trust, CoT) to the platform where they were embedded, as is the case of the chip called n-you Plaljorm Module (TPM) developed by The n · you Computing Group (TCG). The TPM chips integrate a factory master key that never leaves the chip, since it has its own cryptographic processor that allows hash, encryption and signing operations, and the generation of public and private keys that equipment applications can use To perform your own operations.

The private keys generated by the TPM are stored in it, and also allow measurements of the environment parameters that are stored as hashes in PCR records, and that allow the integrity of the measurements to be validated.

This last feature was available from version 1.2 of TPM where significant improvements were introduced. Subsequently, the chip was also presented on a separate board that could be incorporated into the user's equipment (GC-TPM). In this case, the chip is still integrated in the board.

The TPM chip has had many applications in recent years, being also analyzed as CoT in vehicle networks. This use is detailed in documents of the TCG for version 2.0 of the chip [15]. One of the points in favor of the use of TPM in vehicles is that they themselves have to periodically pass the technical inspection by authorized personnel and that this fact would mean updating the software that uses the device conveniently and carrying out a check on the status of the TPM .

Perhaps the evolution of the TPM as an anti-tampering storage concept lies in the figure of the secure element or Secure Element (SE). According to the definition of MasterCard, there are three basic ways in which the SE can be used: (i) SIM CardslUlCC,

(ii) ruicroSD Cards, or (iii) embedded in the mobile device (eSE). In addition, you can

consider that the SE makes use of the mobile device antenna (Single Wire Pr% col, SWP), or that the options (i-ii) have their own integrated antenna (Dual i n / eIJace).

The SE can be found on mobile devices or personal devices such as lab / e / s, and even wearab / es. Its most palpable functionality in this area has been seen with Nea technology. Fie / d Commul1icafion (NFC), a short-range communication technology for making electronic payments with mobile devices without contact with the payment agent. Although NFC defines e! Use of the SE embedded in various components, its most robust use is when it is integrated in the mobile device's own circuitry, since in this way the SE is linked to the body itself! device. In order to extend e! mobile payment, solutions such as Boosted NFC SE integrate the secure element into ultra-small devices, such as smar / wearab / es.

It should be noted that the cards identify you and the tokens are themselves anli-tampering mechanisms but with a much more limited purpose than the anti-tampering devices that we echo in this section. For example, in the case of! TPM, applications can define how to make use of the chip. This feature has made the TPM chip continue to evolve towards its virtual side (vTPM), which allows its use by virtual systems without loss of generality. On the other hand, the SE integrated in the mobile devices can also be used by other technologies for their characteristics to store keys, or hashes of biometric data (eg fingerprint) of the device owner or authorized (1 6). The W3C joins efforts to define interfaces between Web applications and SEs.

However, some see in e! use of the SE a limitation to carry out transactions, so alternatives also arise to avoid e! use of SE, such as Hos / Card Emulation (HCE) technology, which uses e! Cloud to consult the data that would be consulted in an SE. This type of technologies has as a counterpart the loss of the physical core of trust integrated in the device, which would be located in the C / oud, and therefore the control of that data would be taken care of by external entities, not of our device, being able to question The reliability of the information.

One of the challenges of managing electronic evidence is to include the different legal frameworks that are in force at national, European and international levels. This requirement is imposed by necessity, since it is the laws that define the actions accepted as valid by the company that drives them. Since the infonnatic data, and therefore the electronic evidence, do not understand borders, it is vital that the management of the evidence does understand what are the rules by which the acquisition of evidence and its treatment are governed. Otherwise, electronic evidence could be erroneously manipulated and repudiated by it.

5 The acquisition and management of electronic evidence must be carried out in such a way that the evidence cannot be challenged. Demonstrating any of the above assumptions may be unusable if, finally, the judge or jury (according to the legal framework) doubts the procedure for collecting electronic evidence. We must not forget the context at hand. When a case requires the use of

10 electronic evidence is not to carry out an infonnatic team, but to reach the individual

or corporation behind the computer team and assign responsibilities. For this to be possible, linking a device with a user is essential. To this day, examples of links between a physical person and an object exist. The oldest example could be in the use of a person's identification. The papers

15 that identify an individual and certify who they say they are, allow them to carry out procedures. Thus, these binding objects have been introduced gradually and with some degree of suspicion in the virtual world. The clearest example is the use of the DNI-e that allows expediting procedures that would require our displacement. This is so because it is assumed that our DNI-e is in our possession; otherwise, the citizen has the obligation to notify of the loss,

20 loss or theft of the DNJ-e to the relevant authorities using the legal mechanisms and procedures at their disposal for the notification. It should be noted that the strength or credibility of these linked objects and devices, which gives them the power to perform actions on our behalf, is our identity. The adoption of new technologies without contact for their convenience allows the objects they carry

25 our identity reacts actions more comfortably, and integrates new technologies that are still in the spotlight, as is the case of ONI-e v3.0, which incorporates NFC. For all this, digital testification is necessary because it would support GEE for the new challenges that are marked by the implementation of paradigms such as the loT:

DESCRIPTION OF THE INVENTION One aspect of the present invention relates to procedures for the secure management of electronic evidence within the framework of the lar. Although in the present document the invention is made with textualization in the legal or legal field, its application is not necessarily restricted to said field, being extensible to other areas or contexts in which it is possible, advisable, or even forced the safe management of electronic evidence.

In the first place, it is necessary to define the requirements and steps necessary for said safeguarding of electronic evidence using personal devices of users that would act as digital witnesses before the law. Specifically, the present invention focuses on the phases of generation, storage and transmission (1-3) of electronic evidence, and more particularly in the storage and transmission thereof, since the recovery, treatment and communication phases ( 4-6) can fall on entities with more resources that are responsible for carrying out an analysis afterwards. In fact, a critical point in the management of evidence in what is not considered is precisely how to take the evidence from its place of occurrence to its custody using the devices of the environment itself.

We will consider that (i) the generation of evidence can occur anywhere, using recognized forensic techniques; (ii) the storage of evidence may be temporary or definitive, but in any case tools that provide guarantees of integrity and reliability must be used; (iii) these tools must be supported by system users, in this case authorized objects; (iv) these objects belong to people, who can attest to these objects; and, in addition, (v) during the transmission of the evidence, the digital custody chain must be maintained to preserve the evidence while maintaining the reliability of the evidence and the user-device linkage. As a final result, a functional architecture for digital testification is proposed in the present invention.

Figure I shows of simplified fOffila the basic steps of a general embodiment of the procedure that constitutes a first object of the invention from the electronic evidence is obtained until, where appropriate, the space of its storage is released. Each of the process steps is subject to contextual information management!

When the evidence (1) is obtained, a header is generated with the relevant information according to a certain Electronic Evidence Format (FEE). In this process, an evidence identifier is generated from the binding identifier of the electronic device that generates it, and the time stamp. This will be the identifier of the evidence during its life cycle. The evidence is signed and the probative value is stored (2) according to criteria of

secure storage The end of the evidence will depend on the mechanism chosen for the identification of identity.

At some point, if the evidence is to be delegated, a digital witness is chosen to whom

transmit the evidence (3). We believe that electronic evidence has to be delegated

when:

to.

A is not a digital custodian. A must transmit the evidence at least once to a custodian.

b.

The device reaches a supported storage threshold (configurable).

C.

The evidence generated is critical, or the life time will be consumed.

d.

If 8 is more likely to reach the final destination soon and the transfer does not harm the life of the evidence more than if it was stored / guarded.

On the other hand, the choice of the following digital witness, where appropriate, is conditioned on compliance with the following requirements:

rtI. 8 can attest that it is a digital witness and its role / level.

rtl. 8 is a digital witness of the same level as A, or A has a level less than 8. That is, the set of possible pairs is: {(td, td), (cd, cd), (td, cd)), with td: digital testi, cd: digital custodian.

rt3. 8 satisfies the criteria to safeguard electronic evidence. This may be subject to the criticality of the evidence. For example, electronic evidence of a criminal nature should be sent exclusively to digital custodians.

rt4. 8 is the best candidate: candidate with the highest level of delegation of all possible, or that candidate who offers more guarantees / probability that the evidence reaches the final destination minimizing pivot.

rt5. 8 is a digital custodian and requests the sending of evidence, and A can verify the identity of 8.

Once witness 8 is chosen, the information on the electronic evidence is sent (4) using the FEE adapted for digital testification, using a secure channel. 8 then authenticate the electronic evidence and proceed to its storage. In this step, S creates its

own evidence to reflect the reception of this evidence in its history. Then, send A proof that the receipt and storage of evidence has been possible (6). If S does not send this proof, A records in the record that the evidence was sent to S, but does not delete it. The reception guarantee is stored in the history (7).

The evidence history is a summary of the managed evidence that must be stored securely. It means the acknowledgment of the transactions operated by the witness. It will consist of the set of identifiers of the evidence generated and a code that indicates whether it was transmitted, and the guarantee given by the recipient in step (6) (for example, the identifier of the signed evidence).

Finally, A can free the space of the evidence or set of evidence (8), if appropriate.

Storage and format of electronic evidence

Electronic evidence can take up a lot of space, since, unlike an anomaly, an electronic evidence can be any data. Therefore, it is necessary to (i) define what we will consider evidence, (ii) the format for delloT evidence (the one defined in [1] is too ambitious for small objects), (iii) the amount of information / evidence we will store, (iv) what evidence will be more priority.

As defined in [1], in an SGEE a FEE is required that serves both for the exchange of evidence and to assist in obtaining forensic. The objective of using a format is to facilitate the understanding of the evidence and expedite its processing. This also allows you to summarize the information, using identifiers, when using standardized mechanisms that we can classify and make available to participants in the environment. We would replace extensive descriptions with identifiers in a simplified report.

In [1] the following data are proposed for the headers for the exchange of electronic evidence and its secure collection for forensic analysis:

he. Exchange: version, size, identifier, organization, description, timestamp, total files, file number, file size, file format,

signature type, signature size.

e2. Forensic collection: version, size, identifier, creator, creation date, date of obtaining, total files, file number, file size, file format, device type, device model, device serial number, number of sectors of the device, first sector, number of sectors of the evidence, type of signature,

5 signature size.

For example, the "version" field refers to the version of the FEE used, the "identifier" field includes information on the NIF / CIF of the responsible organization. In c2, the data referring to the device refers to the test storage medium

10 (eg hard disk from which the evidence has been extracted), and they have a clear aspect towards obtaining dead data (Section U-B, case b). This type of FEE is designed for storage of various types, considering the wide variety of alternatives, for example, hard drives, market, and traditional computer systems are composed of interchangeable parts

15 However, in the field of mobile devices, considering that these are embedded systems with known characteristics based on the model of the device, information on the characteristics of the device can be deduced based on the identifiers of the model of the device used for capture of evidence. In this way the FEE fields for this type of devices can be simplified, avoiding the

20 known features of devices with a certain profile. As the FEE has a version identifier, a version can even be defined for devices of this nature, so an SGEE could use both the format indicated by the standard, and the simplified one for devices with fewer resources, without loss of generality. It should be noted that the traceability of information includes more aspects to consider.

25 For example, if you consider only the data of the device that generates the evidence or the data of the intermediate devices where the evidence is temporarily housed. The latter case is closely linked to the transfer of electronic evidence between the different participants. In addition to simplifying headers considering device limitations,

30, at a minimum, the following aspects should be considered to implement our approach:

•

Safe element Data relating to which implementation of the safe element has been used, or if it has not been used.

•

Time of life. Information on the possible expiration of the evidence. It can be composed of a code that indicates the interpretation of the life time (eg based on the number of pivots) and a value.

•

Priority. Data for example to prioritize the storage of some evidence over others.

•

Criticality Define the type of device that can guard the evidence.

•

Pivot Number of breaks (or intermediaries) of the evidence.

The fields of the FEE must be relevant for the understanding of the evidence, concise, and contain information proving the integrity of the evidence. The limited space to store the evidence suggests that at least the integrity of the evidence be preserved, that is, to store at least the hash value of the signed evidence. This value would be transmitted along with the eden.encia finnada. The use of al1li-lampering mechanisms to store hash values has been used, for example, for reliable startup, or Root or [Trust (RoT) of the TPM chip (Table 1). In this case, the integrity of the software is verified if the hash of the components matches the hash measurements stored in the PCR (Platform Conflg1watioll Registers) registers of the chip. In the case at hand, the integrity of the evidence would be verified if the hash matches that protected in the secure storage medium.

It should be noted that despite the fact that the evidence pool does not take up too much space on the chip, the number of evidence will depend on the context and the type of evidence stored on the device. In any case, it seems inevitable and reasonable that this information stored on the chip is delegated, whenever appropriate, to an entity with authority for it as soon as possible, due to two factors: (i) limited space and (ii) minimize the window of commitment of the evidence. In addition, for very critical evidence, the profile of the devices that can safeguard the evidence should be defined.

In another order, we consider that there are different roles or profiles within the digital testification. The basic classification (figure 2) is to distinguish between digital witness and digital custodian, as a particular case of digital witness but with more privileges. Thus, the evidence could be collected (figure 3) either by (a) an object belonging to a civilian acting as a recognized digital witness, (b) a personal object in possession of a privileged user, recognized as a digital custodian (strong digital witness with privileges), OR by (c) an object or entity with more resources belonging to the security body and recognized as a digital custodian.

The separation of cases (b) and (c) is important because of the delimiting nature of the resources of the devices that the user would carry with privileges (or with power) in (b). This limitation would mean that the number of recorded evidence could not exceed a certain threshold, so, like the objects in (a), the objects in (b) should release the evidence as soon as possible.

Delegation of identity and signature of electronic evidence

It is essential that a user can delegate their identity to the device OR devices that act as digital witnesses. As a first step, and in the context at hand, it is necessary that the identity of a user within a device be binding; that is to say. During the handling of the evidence, you must unequivocally trace the physical person behind this identity. Currently, there are already mechanisms and processes that allow you to associate the identity of a user with a device in a binding way. An example is the information stored on a SIMlUICC card (eg IMSI identifiers, MSISDN [17]), since in certain countries such as Spain the physical person needs to provide a legal document to obtain that identity. Another example is the use of digital identity documents (eg DNl-e), as they allow a physical person to authenticate to a device or service using such documentation [18]. We must also take into account those mechanisms that depend on the characteristics of the person, such as biometric systems.

Although an identity can be binding, there is a main challenge that must be solved within the handling of the evidence: How to inextricably link evidence to a specific user throughout the CVEE. Securing such a link is necessary not only during the transfer of evidence between digital witnesses, but also at the time when evidence is used as evidence within a trial. To this end, it is possible to use a cryptographic primitive that precisely allows an unequivocal link between a user and the information generated by their devices: the so-called proxy signGfUreS [19]. Moreover, all the strategies to implement this cryptographic primitive [1 9] we

They can implement the link between user and evidence, as shown in Figure 4 and is developed in the following paragraph.

In its simplest form (fu "delegalion, FD), the user delegates the use of his private key to the device. This can then be used to sign the evidence. Another strategy (delegation by warral1l, DbW) is the use of a token (warrant), signed with the user's private key, which indicates the identity of the device and the period of validity of the delegation, among other data.This token would be provided to the device, which would attach it to the evidence by endorsing it with its own Finally, in the last scheme (PK) the user's private key is used to generate a pair of private and public keys, which will be used by the device to sign the evidence, since said keys are associated with the user's identity (eg using identity-based cryptography [20]), the identity of the user who generated the evidence can be verified.

In our approach, the result of the FO, ObW or PK schemes (or any other scheme that provides a link between a user and their device) is called binding credentials (BD), since they are key (e.g. case of FO or PK)

or tokens (eg warral1l case), are the means used to sign the electronic evidence creating the relationship between the user, the device and the electronic evidence.

On the other hand, for the use of signa / l / res proxy it is mandatory that the user has a public and private key pair. In addition, the private key must be conveniently protected within a security chip (eg eSE), which will allow digital signature operations. These requirements can be resolved using the underlying mechanisms of binding identities. For example, in the case of mobile devices, and according to 3GPP TS 33.221 [211, it is possible with the assistance of the telecommunications operator to include certificates and private keys within the UICC. In this case, the evidence management system would be developed jointly with the operator, being able to be part of the services included within the UICe. This would allow the evidence to be signed within the UICC itself and include the necessary identifiers (LMS1, MSISDN).

An alternative that does not require a reliable industrial third party, and which also directly involves the user may be the use of the DNI-e or equivalent. It is currently possible to connect an ONI-e to a device through a card reader and a USB port, and through an NFC connection using the DNl-e v3.0. This allows you to use the private key of the individual contained within the DNI-e to, for example, sign the evidence directly or provide a warrant. An advantage of this method is the use of a document with legal validity for the handling of the evidence, which would facilitate its use before a court of law without having to involve third parties. In addition, projects such as STORK and STORK2 [22] have shown that interoperability between European electronic identifiers is possible, so linking the evidence can be valid at the continental level.

All these methods work if only a mobile device is used for the acquisition and management of evidence. However, its use may be restricted in ecosystems such as lar, where several devices with quite limited resources could participate in the CVEE. Moreover, the problem of identifying objects 101 '(and their owners) is still open today (23). However, there are several jobs whose objective is to develop a reliable personal area network (PAN) environment, in that the devices are owned by a single user.Works such as [24] demonstrate that it is possible to exchange information securely between members of a PAN, d. choosing the most complex tasks (eg authentication with external devices, storage of information) to those elements that have sufficient capacity to perform them.Other works, such as (25), develop the concept of personal PKJs, in which each device controlled by a user can have its own pair of keys, which are generated by the user himself (eg through his ONI-e). All these properties allow that, in certain PAN environments, it may be possible to generate evidence, store them, and verify them through proxy

sigl1atllres.

Finally, there is another aspect that should be considered with caution: the use of sigl1atllres proxies allows linking evidence to a specific individual, but does not ensure that the individual was controlling the device (s) at all times. For example, a user can generate a warral1l through his DNl-e, but not control the device during the process of acquisition and / or transmission of evidence. If this is necessary, context-based authentication mechanisms [26] or biometric systems [27] can be used to ratify the presence of the user. Another approach to consider, inherited from the principles of the lor, is that it is the object itself or objects that collect evidence of user participation throughout the process.

Secure transmission of electronic evidence

The secure transmission of electronic evidence confers to the present invention requires establishing what is called a digital chain of custody (CCD) [9], but where those involved would be objects of personal use. Said transmission or secure release of electronic evidence would be carried out by means of what we will call evidence pivoting (or virtual delegation of electrical evidences), a process by which the evidence is transferred from the object of the individual acting as a digital witness, to the final source of the information, where the evidence would be stored for final analysis. According to figure 3, it is possible to consider six pivotal base cases:

gives 1. Delegation of a user to another user with more privileges. It would correspond to citizen collaboration to gather evidence and notification to a user with the power to manage them.

gives 2. Delegation of a user to another (mobile) object with more privileges or resources. It is similar to case 1, but electronic evidence would be delivered to an object of the security body with more resources or greater possibility of finding an object for the final storage of the evidence.

gives 3. Delegation of a user to another object with more privileges or resources. Similar to the previous case, but in this case the delegation is made on fixed structures, which will probably be the final storage of the evidence before processing or transfers to other entities following the traditional schemes for the transfer of electronic evidence.

db 1. Delegation of a user with power to another user with power. This case would contemplate those reasons for which a user with power delegates a part OR all his evidences to another user with power.

db 2. Delegation of a user with power to an object with power. It is the simile with da 2, but where the object can be mobile or not. In this case no distinction is made, because the delegation of evidence comes from a device that acts as a strong witness, and therefore, in principle, the level of reliability is assumed to be higher.

db 3. Delegation of an object with power to another object with power. This is the case of delegation between objects less restricted with resources and less linked to personal use.

It should be noted that objects such as cars would be in db 3 because, although they are handled by users, the attachment is not as continuous as that of a mobile terminal, which accompanies the user even inside buildings. Therefore, we consider it convenient to separate these types of cases. The difference between the devices and the users allows to establish the context in which the transfer of the evidence takes place and to identify suspicious cases of bad behavior.

A second aspect of the invention relates to devices for the secure management of electronic evidence, devices capable of implementing the procedures object of the first aspect of the invention, devices that, generically, we call digital witnesses, the Digital Witness figure being understood as that of a device with a trusted core capable of protecting electronic evidence against any modification and unauthorized access and of making its transfer to an authorized entity, which may be another digital witness or an entity with the power to host electronic evidence. The interrelationship between said devices or digital witnesses can form different systems for secure electronic evidence management.

We propose the use of a personal device capable of acquiring events from the communications network, for example, an attempt at an unauthorized remote connection. We can also consider the use of the personal device to acquire local evidence, for example, the presence of a virus. This use requires limiting the type of information that the user device can share without compromising user privacy. For example, it might be feasible to take as evidence a list of applications, or the contacts agenda, however, this should have the approval of the user, and the contexts in which this type of information should not be used or shared should be defined. .

Figure 2 shows two types of digital token considered based on user profiles. In line with the identity delegation discussed above, we understand that there is a basic principle, and that is that the device that acts as a witness has to link the identity of the user to the device because this allows the legal framework to be brought closer to the electronic evidence that is kept . In addition, this position also allows adding a user responsibility value to the device, something that is also necessary today. In this way, the idea is that the loss or theft of a device considered a witness must be notified to the relevant authorities as if it were a DNI-e (Spanish case).

It could be understood that linking the identity of the user to his personal device could affect the user's privacy, considering that, for example, in a mobile phone the running applications can be very diverse and from different sources, lacking the control to which other devices Officers are subdued.

However, this risk already exists today. The mobile device of per saves a lot of information that would allow to identify the owner of the terminal. Therefore, we consider that linking the terminal to the user's identity only adds clarity to the fact that a mobile device with personal data is a responsibility. Thus, the mobile device could take actions on behalf of its owner as long as a series of requirements are satisfied to ensure that those actions were ordered by a specific owner. As basic requirements, we can consider:

•

Existence of a trust core that provides a degree of reliability to the action.

•

Existence of a final human responsible for the action, that is, a human-machine identity link.

•

Existence of a means by which the action is recorded, either locally, or by establishing the security procedures necessary to transmit it to an authorized entity.

Thus, we consider that an eS / lIrte digital witness if it is a device with a trusted core and also has the identity of the user. This means, on the one hand, to protect electronic evidence and, on the other, to have the power to act as a digital witness on behalf of the user.

On the other hand, as in the physical world, different user profiles would give rise to different digital witnesses. Therefore, we understand that when the device belongs to an individual with representation in the legal system (eg a police officer), acting not as a citizen but, for example, as an agent of the law, that is, the device is not private property, Obtaining evidence is more controlled and its safeguarding too. This is the figure of clIs / hate represented in figure 2. Thus, although a strong digital witness can safeguard information, the term custodian is reserved for the latter type of digital witness linked to the administration, because by nonna general custody is performed State security forces.

The ultimate goal is for electronic evidence to complete the first phase of the CVEE in which objects are involved, and which may be more critical for their resources. To do this, in the context at hand, digital witnesses may require transmitting electronic evidence to other digital witnesses.

The Digital Witness concept defines the basic security architecture for acquiring electronic evidence of a probative nature, acceptable in a possible litigation, in dynamic, heterogeneous and distributed scenarios of the LA. A clear advantage of the digital witness is that it takes advantage of embedded security architectures to provide, for the first time, the management of electronic evidence in personal devices as collaborators, creating the simile with human testification. Another added advantage is that the use of digital witnesses to speed up police work through citizen collaboration with the devices.

To make this possible, the architecture of a scenario for digital testification comprises the components shown in Figure 5, although some of them optional, which define the essential technical characteristics:

1) Operations manager between the user and the device. Penllite link a user's identity with their personal device. As a result, it generates a set of binding credentials (BD), which will be used throughout the GEE process. In addition, it would provide additional options such as requesting evidence.

Biometric to the user for the GEE. 2) Contract manager. It is an optional component that allows the witness to be indicated

Digital cryptographic mechanisms and the most robust configuration acceptable for the acquisition of evidence. Provide the witness with proof of advice from a witness with more privileges. If this component is not used and the witness uses mechanisms

Accepted the evidence will have the same validity as if the contractual manager had been used.

3) Cryptographic mechanisms accepted. They are the cryptographic mechanisms within a secure element (hw chip, al1li-lamp ering) that will be used during the GEE, and probably (although not necessarily) by the user-device operations manager.

4) Secure storage with access control. Protected storage in a secure element (it can be the same secure element as the one containing the cryptographic mechanisms or another one). Keys would be stored in this component

and other protected data, such as hashes of electronic evidence, the contract, and

the binding credentials.

5) Electronic evidence manager for objects. Coordinate acquisition operations

of electronic evidence, secure storage, and transfer of evidence

electronics to another witness in the chain.

The inclusion of hardware security chips brings several advantages, such as the fact that some of these chips integrate mechanisms to provide a secure communications channel. There are also solutions to define transactions that involve the participation of the secure element, in which the identity of the device is stored [29].

In the case at hand, it is not enough for the chip to integrate mechanisms to establish a secure communications channel, but, in addition, those mechanisms must employ technologies that are acceptable for the management of evidence in accordance with the rules that apply and agree to the current legality (eg considering the privacy of the data). In

specifically, in [1 1 defined, as pemlitidal operations:

•

Symmetric key algorithms: 2TDEA, 3rd EA, AES 128bits-256 bits.

•

Electronic signatures and hash applications: SHA224 / 2561 3841 5 12.

•

HMAC, key derivation functions, random number generation: SHA I! 224/256/384/5 12.

The security level is classified according to the life time of the security and the type of data that it keeps considering the LOPD. For example, according to the requirements of [11, the OP1JGA Trust aulhenlicatioll chip using RSA of 2048bits could protect high-level confidential information, and using 512-bit ECC and AES 256 protect high-level secret information (the maximum scale defined in (1 ]) Therefore, it is a good option for use as a strong digital token, and allows the exchange of keys using diffie hellmall (OH) or OH using elliptic curve crypto gratia (ECDH), speeding up the creation of secure channels of communication.

The present invention establishes the minimum requirements that the technology of the device must meet to be a digital witness according to our definition, but it is possible

note that although examples are proposed to demonstrate that the scheme is implementable in

In practice, such implementation is not specifically associated with a single type of device, but the proposed requirements can be satisfied by a broad spectrum of dispositives.

DESCRIPTION OF THE FIGURES

Figure l. Basic steps of digital testification and scale of values. Figure 2. Roles in digital testification and basic requirements. Figure 3. Pivoting evidence. Figure 4. IDEEs in digital witnesses. Figure 5. Basic components for digital testification. Figure 6. Basic functional architecture for digital testification. Figure 7. Flowchart with simplified use case. Figure 8. Functional architecture for digital testification based on binding credentials

(binding credentials, B D).

Figure 9. Flowchart for case (A) considering the Contract Manager. Figure 10. Flowchart for case (C) considering the use of biometric mechanisms. Figure 11. Biometrics as additional evidence.

EXAMPLE OF EMBODIMENT OF THE INVENTION

The constitution and characteristics of the invention will be better understood with the help of the following description of embodiments, it should be understood that the invention does not is limited to these embodiments, but the protection covers all those realizations alternatives that may be included within the content and scope of the claims. Likewise, this document refers to various documents as prior art, understood to be incorporated by reference the content of all these documents, as well as of the complete content of the documents referred to in said documents, in order to to provide a description as complete as possible of the state of the art in which the present invention fits. The terminology used below is intended for description

of the examples of embodiments that follow and should not be construed as limiting or restrictive.

Interaction between components

Below we define three basic cases (A-e) of interaction between the components shown in Figure 6. The flow chart detailing the interaction between the components is shown in Figure 7:

(TO)

Establishment of action policies for the use of the digital witness.

(B)

Creation of binding credentials (billdillg credelltials, 80).

(C)

Evidence management with 80s.

In case (A), the objective is to define what the cryptographic mechanisms and acceptable configurations will be, and those additional policies that are necessary to define the behavior of the digital witness. For example, in this step the user must accept the conditions of the service, and this information must be stored properly for his delegation to official sources. Therefore, there are two distinct parts at this point. On the one hand, (G PI, Group Policy J) the policies that relate the user to the device, not only for the terms of service, but for other policies that depend on the use of the device (eg acceptance of permits, configuration of resources such as the space that can be used to store evidence), and, on the other hand, (G P2, Grollp Policy 2) the policies that define the operation of the Electronic Evidence Manager for Objects (EE Manager). In general, GP I and GP2 constitute the set of security associations (SA), which will be used by the digital witness.

The more general policies, GP 1, will be negotiated between the user and the User-Device Operations Manager, while another group of policies, GP2, will be established through the EE Manager. Defining the set of applicable policies is very critical, since it will define the behavior of the digital witness. In particular, we define four policies that would be applicable from the EE Manager: (P 1) evidence generation policy, (P2) evidence transmission policy, (P3) evidence storage policy, (P4) deletion or deletion policy of evidence. All policies include the list of security and cryptographic mechanisms accepted for each case and consider the list of requirements mentioned above. In relation to (IP), the forensic mechanisms used to acquire the evidence will be detailed.

It is assumed, therefore, that, as a basic case, the EE Manager integrates basic information on the accepted mechanisms for the management of electronic evidence. The policies, once accepted, are safeguarded as electronic evidence, constituting proof of the mechanisms that will be valid in the digital witness scheme. An improvement that would enable the deployment of a more dynamic scenario implies the use of the contractual manager as an advisor.

In case (B), the user-device operations manager is responsible for carrying out the pertinent operations for the creation of the credentials (keys or tokens) that link the user with the device. These binding credentials will be used transparently by the GEE to operate with the evidence, historical and transmission of these. The binding credentials will satisfy the binding requirements detailed above, and will be generated using the accepted cryptographic mechanisms available in the digital token. In addition, credentials will be stored with anti-tampering protection in the digital token.

Finally, case (e) corresponds to the minimum steps performed internally in the architecture to process evidence, from the time it is obtained until it is eliminated. While Figure 1 obviates the internal operations between the components of a witness, here we detail these steps. The evidence is obtained using accepted forensic mechanisms, in accordance with current regulations and legality. The hash of the electronic evidence will be done using the appropriate cryptographic mechanisms and, if this component can write directly on the protected space of the secure element of the digital witness, the writing of the hash will be direct (a). In another case, the electronic evidence manager for objects will be the component responsible for requesting the writing of the resulting hash value in the storage space. Finally, obtaining evidence implies updating the history of evidence.

The last step would correspond to the sending of the evidence (or set of evidence). The number of evidences to be sent, the moment in which they are sent, and the way of erasing or eliminating the evidence, will depend on the set of policies established for such purposes. Figure 7 shows the steps that would be taken once the evidence is sent, and it is also assumed that the next witness in the chain (candidate for delegation) has already been chosen and that it meets the criteria already detailed. The task of choosing the next witness corresponds to the typical problems of selecting the next node in a jump-to-jump communication, but using security and privacy measures. Depending on the policy, it may even be necessary to send the evidence through other means (eg Internet). This decision work therefore depends on the policies for the transmission of the evidence and would be one of the functions that the EE Manager would coordinate (figure 8).

In addition, the transmission step involves an update of the evidence history to reflect the effectiveness or not of the delegation of evidence. The first step is to obtain the evidence (in this case the hash of the evidence) and the historical. These values are sent to the next witness in the chain using secure communication channels constructed using accepted cryptographic mechanisms, and indicating the credentials that demonstrate the link between the user and the device.

As mentioned above, the way of erasing or removing the evidence will depend on the erasure policy. In Figure 7, a deletion policy is implemented that involves the elimination of each evidence that is delegated correctly. However, it doesn't always have to be that way. For example, if the evidence is sent to a digital witness with delegation level l (figure 1), it may be convenient to save the evidence for a short additional period of time in order to try to forward the evidence to another digital witness with a higher level if It has the possibility.

Finally, whatever the result of the delegation (whether it was possible to send the evidence or not) the history is updated and the supporting data of the operations and their success or failure are saved in the protected space of the digital witness.

Figure 8 shows Figure 6 appropriate to the use of credentials binding to the cases presented in the section referring to delegation of identity and signature of electronic evidence (FD, DbW, PK). There are also three functions that the EE Manager would perform at least: obtaining evidence, storing (and deleting) evidence, and transmitting evidence. This more specific example also shows that it would be desirable that the role of the device (eg the level of delegation) be stored in the secure element, together with the contract established by the contractual manager. At a minimum, the proof of the contract established with the user for the use of the personal device as a digital witness must include the role with which the device will participate in communications.

It should be noted that, apart from the specific examples shown for the implementation of the binding credentials, the digital witness scheme would continue to be valid for other mechanisms that allow establishing binding credentials that help

unequivocally define the relationships between users, devices and electronic evidence.

Optional interaction between components, optional components and extensions

Contract Manager

The case (A) detailed in the previous section can be improved through the use of the optional component GeslOf "COl1lractual to establish the policies for the electronic object evidence manager. If the contractual manager is employed for that case, we delegate part of the decision on the configuration options to the contractual manager Case (A) would be redefined as obtaining recommendations on cryptographic mechanisms and acceptable configurations for the management of electrical evidence (Figure 9).

In this scenario, the interaction occurs between the contractual manager and the EE Manager. The first would indicate to the second the acceptable configurations so that the electronic evidence management is carried out according to the security levels stipulated by commonly accepted norms and the legal framework. Initially, the digital token can be configured with the default policies defined by the EE Manager, and, upon request of an authenticated custodian, could update these policies according to the security association established with the custodian. This GP2 policy update may be required at any time, and, if it influences the terms of service, or any other factor detailed in the rest of the policies, it would be communicated to the user for acceptance.

Although the use of the contractual manager is optional so as not to limit the usability of the digital token, its use is advisable since the contractual manager can help optimize the selected mechanisms depending on the device and the context. The security associations (SA) agreed between the electronic evidence manager for objects and the contractual manager would be stored in the digital token, and in the issuer of the SAs, as well as the recording of the evidence of this collaboration between the components.

Use of biometric mechanisms as part of the User-Device Operations Manager As can be seen in Figures 7 and 9, another optional element within our architecture is the use of biometric systems to test the presence of the user. This element can be used within case (B) (figure 7) before the creation of the binding credentials, or within case (C) (figure 7) during the process of collecting and / or sending evidence. The way in which these biometric systems are used is defined within the acceptable configurations, which must define at least i) the type of biometric system to be used (eg fingerprint, iris, voice), ii) the expected combinations of biometric systems, and iii) the characteristics that the implementation of the biometric system must meet. These configurations can be specified in a static way, or dynamically in those architectures that have the optional Contract Manager component.

This optional interaction is mainly carried out between the user and the User-Device Operations Manager (figure ID). Before performing any operation that requires the presence of the user, the user must indicate to the Operations Manager their availability (eg responding to an alert from the Operations Manager). At this point the Operations Manager will ask the User to authenticate through the biometric systems indicated in the acceptable configurations. The User will use said biometric systems, and if all the results are correct, the Operations Manager will continue with the planned operations.

Being part of the digital witness's policies, the use of biometric mechanisms is recorded as evidence once the user consents to the terms of service. But, in addition, there are traces of the use of biometric systems every time an operation requires User approval (eg the test sent by the user in Figure 10 would be an integral part of the evidence to be stored). The use of biometric tests can be evidenced by using a simple register to biometric information (eg the image of the fingerprint used at that time) in those mechanisms that allow it.

Regarding the use of a biometric system, the nature of this data should be pointed out. Today, most biometric systems allow you to store information about a user who will use the device (eg "] 'ollch ID" from Apple [30]), but nothing guarantees that the user registered on the device is the same as the user who made the process of the binding credentials. This data is relevant, because it is the binding credentials that determine the ultimate responsible for the evidence. The case of the existence of multiple users who can make LISO of the device therefore requires special consideration.

2S

Figure 11 shows different cases of use of the digital device:

(one). Basic. Default behavior of the digital witness without the use of biometrics.

(2). Strong biometric (checked locally). The biometric data was collated locally

in a pre-shipment step. The device saves the verification result as

proof.

(3). Weak biometric (not collated). Biometric data is provided as additional pmeba to

the evidence. but it must be collated or authenticated by the remote entity that receives the

evidence.

If you want to respond to a specific user by sending electronic evidence, the biometric information provided by the user (eg your fingerprint) must be checked against a legally valid source (eg the fingerprint stored in a DN1-e) to establish a robust bond.

In case (2) the biometric test is collated locally using an element that can validate the test regarding the identity of the individual (eg using a DN1-e to validate the fingerprint of the DNI-e regarding the fingerprint that the witness identifies as the user's fingerprint). In this way, successive uses of the biometric system are validated before use. When the user authorizes the sending of evidence using a collated biometric mechanism, the system acknowledges before sending the evidence that the user who authorized the action is the same as the one who established the binding credentials.

The case in which the biometric test is not collated locally (case (3)) should also be considered. This implies that subsequently the entity that processes the evidence must check the evidence provided by the biometric mechanism (eg the fingerprint) with the existing databases to identify the individual who authorized the sending of the evidence. In this case, the digital witness could not ensure that the user authorizing the shipment is the same user who established the binding credentials.

Finally, we consider a third assumption, and that is that in the initial contract between the user and the user-device operations manager for the use of the digital token, the user who establishes the binding credentials can authorize the use of the witness to other users. For this, the linked user should indicate the personal data (identity) of those other users who are going to make use of the digital token, as well as other data that are considered

relevant based on context (eg the collated biometric data of individuals

authorized). This information will be provided to the relevant authorities to facilitate the automated processing of the evidence. Another option that would add complexity to the digital token scheme is to allow the

5 simultaneous activation of multiple binding credentials, one for each user. Although it would add complexity, considering different binding credentials can provide independence between user actions. In the previous case, the final responsible is the user who established the binding credentials, since it is he who gives his consent for the use of the device as a digital witness and the one who registers the users.

10 References

[1 J Une 71505: Information technologies (ti). electronic evidence management system (sgee). Information Technology, 201 3. 15 (2) Mariantonietta La Polla, Fabio Martinelli, and Oaniele Sgandurra A survey on security for mobile de vices Communications Surveys & Tutorials, IEEE, 15 (I): 446-471, 20 13 .

[3] Edewede Oriwoh, David Jazani, Gregory Epiphaniou, and Paul San !. Internet of things forensics: Cha llenges and approaches. In Collahoralive Compulil1g: Networking, Applicatiol1s and Worksharing (Collaboratecom), 20/3 9th / l1fernational COl1ference

20 COIlJe, .ellce 0/1, pages 608-615. IEEE, 2013.

[4] Re Hegarty, OJ Lamb, and A Attwood. Digital evidence challenges in the intemet ofthings. In Proceedings of the Tenth International Network Conference (JNC 2014), page 163. Lulu. com, 2014.

(5J S Omeleze and HS Venter. Towards a model for acquiring digital evidence using mobile 25 devices. In Proceedil1gs of the Temh Interna / iol1a! Network Conference (JNC 2014), page

173. Lulu. com, 20 14.

[6] Eoghan Casey, Greg Sack, and Sean Samum. Leveraging cybox ™ to standardize representation and exchange of digital forensic information. Digital Investigation,

12: SI02-S II0, 2015.

30 [7] Tomás Marqués Arpa and Jordi Serra Ruiz. Chain of custody in forensic analysis. Implementation of a digital evidence management framework. In XIii EspGliola Meeting on Cryptography and Information Security (RECSJ 20/4). University of Alicante,

2014.

[8] Yudi Prayudi, Ahmad Ashari, and Tri K Priyambodo. Digital evidence cabinets: A

35 proposed frameworks for handling digital chain of custody. 1111. J. Computo Appl, 109 (9): 30-36, 2014.

[9] Yudi Prayudi and SN Azhari. Digital chain of custody: State of the arto Jntemaliol1al) ournal of Computer Applications, 114 (5), March 20 15.

[10] Ingo Friese, Jorg Heuer, and Ning Kong. Challenges from the identities of things:

40 Introduction of the identities of things discussion group within kantara initiative. In 30

Internet ojThings (WF-loT), 2014 IEEE World Forul11 0 11, pages 1-4. IEEE, 20 14.

[11] Cory Altheide and Hadan Carvey. Digilal Forensics wilh Open Source Tools: Using Open SOlll'ce Platform Too / sjor Pefjormil1g Computer Forensics on TargetSystems: Windows, Mac, Linux, Unix, elc. Elst :: Friday, 2011.

5 (121 Eoghan Casey. Digital evidence and computer crime: jorensic science, computers and the interne !. Academic press, 20 11.

(1 31 Ray Hunt and Jill Slay. Achieving critical infrastructure protection through the interaction of computer security and network forensics. In Privacy Secllrity and Trust (PSl), 2010 Eighth Annllal nlema / ional Conjerence on, pages 23-30. IEEE, 2010 .

10 [141 Irfan Ahmed, Sebastian Obenneier, Martin Naedele, and Golden G Richard 111. Scada systems: Challenges for forensic investigators. Computer, (12): 44-51, 20 12. (1 51 Tcg tpm 2.0 automotive, committee draft. Technical report, Trusted Computing Group (TCG), 20 14.

(1 61 Raul Sanchez-Reillo, Daniel Sierra-Ramos, Roberto Estrada-Casarrubios, and Jose A 15 Amores-Duran. Strengths, weaknesses and recommendations in implementing biometrics in mobile devices. In Securily Techl1ology (ICCS!), 2014 In / ernatiofla / Carnahan

Conjerenceon, pages 1-6. IEEE, 20 14. [171 Rick Ayers, Sam Brothers, and Wayne Jansen. Sp 800-101 king. 1, guidelines on mobile device forensics. Technical report, Gaithersburg, MD, United States, 2014.

20 [181 Víctor Gayoso Martinez, Luis Hernández Encinas, Antonio Martín Muñoz, and Juan Ignacio Sanchez García. Identification by means of a national id card for wireless services. In 2013 16 / h Internal / iollal Symposiul11 on Wireless Personal Multimedia COJ11l11unicafions (WJlMC), pages 1-5, June 20 13.

(191 Alexandra Boldyreva, Adriana Palacio, and Bogdan Warinschi. Secure proxy signature 25 schemes for delegation of signing rights. JOllrnal ojOyp / ology, 25 (1): 57-115, 2012. [201 He Debiao, Chen Jianhua, and Hu Jin An id-based proxy signature schemes without bilinear pairings AflIJals ojTe / ecommunicatiol1s, 66 (1 1-12): 657-662, 20 11.

(21) 3GPP TS 33.221: Support for Subscriber Certificales. http: //www.3gpp.orglDynaReport/33221.htm. Accessed on April 2015. 30 (22) STORK2: Secure Idenlity Across Borders Linked. hllPS: //www.eid-stork2.eu !. Accessed

on Apri1 20 15. 24 [231 Sabrina Sicari, Alessandra Rizzardi, Luigi Alfredo Grieco, and Alberto Coen-Porisini. Security, privacy and trust in internet of things: The road ahead. Computer Nelworks,

35 76 (0): 146-164,2015. (241 Marc Barisch. Design and evaluation ofan architecture for ubiquitous user authentication based on identity management systems, In 2011 IEEE '10lh Imemaliollal Conjerellce 011 Trust, Security olld Privacy ill Computing and Communicalions (TrusICom), pages 863872, Nov 201 L

40 [251 John Lyle, Andrew Paverd, Justin King-Lacroix, Andrea Atzeni, Habib Virji, (van Flechais, and Shamal Faily. Personal pki for the smart device era. In Sabrina De Capitani di Vimercati and Chris Mitchell, editors, Fublic Key Injraslruclures, Services and Applications, volume 7868 of Lecture No / es in Computer Science, pages 69-84 Springer Berlin Heidelberg, 2013.

45 [261 Seyed Amir Hoseini-Tabatabaei, Alexander Gluhak, and Rahim Tafazolli. A survey on smartphone-based systems for opportunistic llser context recognition. ACM Compu / ing 31

SlIrveys, 45 (3): 27: 1-27: 51, Jul 2013.

[27] Liam M. Mayron. Biometric authentication on mobile devices./EEE Securily aud Privacy,

13 (3): 70-73, May 201 5.

[28] Syed Rahat and Wayne Browning. Methods and systems for secure communications 5 between dient applications and secure elements in mobile devices, December 2 2014. US

Patent 8,904,195.

(29) David T Haggerty, Ahmer A Khan, Christopher B Sharp, Jerrold Von Hauck, Joakim

Linde, Kevin P McLaughlin, ZIAT Mehdi. and YousufH Vaid. Apparatus and methods for secure element transactions and management of assets, February 6 2014. US Patent

10 App. 14 / 174.79 1.

(30) About Touch ID security on iPhone and iPad. https://support.apple.com/en-us/HT204587.

Accessed on July 2015.

Claims (23)

l.

Procedure for the secure management of electronic evidence with credentials

binding characterized by that

s

to. makes use of two or more devices for secure evidence management

electronic with binding credentials (digital witnesses) on which the

user or object that obtains, generates or receives evidence delegates his identity of

binding and indissoluble form through binding credentials, each of

10

said two or more devices comprising:

l. An operations manager between the user or object and the device,

responsible for establishing policies that relate to the user or

object with the objective and that allows to link the identity of a user

lS

or object with your device generating at least one credential

binding (binding credential, 80);

11. A core of trust, responsible for ensuring the integrity of the

electronic evidence, prevent unauthorized access and allow its

transfer to an authorized entity, which includes:

twenty

1. Cryptographic mechanisms accepted within an element

safe (hw chip, anti-tampering) to establish a channel of

secure communications; Y

2. secure storage media with access control,

2S

protected in a secure element (it can be the same element

sure that the one containing the cryptographic mechanisms or other

different), to store keys and other protected data, by

example hashes of electronic evidence and

binding credentials; Y

30

i¡j. an electronic evidence manager for objects, which coordinates the operations (and establishes the policies to be applied on said operations) of acquisition or generation of electronic evidence, secure storage, transfer of electronic evidence to another witness in the chain, and, in its case of deletion or elimination of evidence; and because b. It comprises the following stages: l. Establishment of the cryptographic mechanisms, configurations and policies that make up the set of security associations (SA) of the digital witness through the operations manager between the user or object and the digital witness and through the electronic evidence manager, associations of security that, once established, are safeguarded as electronic evidence; 11. Binding and indissoluble delegation of the identity of the user or object to the electronic device (digital witness or digital custodian -that is, a digital witness with more privileges-) that allows obtaining or generating the evidence through binding credentials, such credentials binders (keys, tokens) generated by the operations manager between the user or object and the digital token using cryptographic mechanisms accepted and safeguarded by secure storage means protected in a secure element of the digital token; 111. When a user or object obtains the evidence (1) confuses the security associations of the digital witness, a header is generated with the relevant information according to a detailed Electronic Evidence Format (FEE), generating an identifier of the evidence from of the binding identifier of the electronic device that generates it, and the time stamp, said header comprising (i) data relating to which implementation of a secure element has been used, or if it has not used a secure element; (ii) information on the possible expiration of the evidence, (iii) data to prioritize the storage of some evidence over others, (iv) type of device that can guard the evidence, and (v) number of jumps or intermediaries of the evidence;

IV.

The evidence is finalized based on the mecamsmo chosen for the identification of the identity and the probative value is stored (2) according to safe storage criteria, said probative value consisting at least of the hash value of the signed evidence, said hash being generated through appropriate cryptographic mechanisms and recorded in the secure storage media of the digital witness either directly or at the request of the electronic evidence manager, updating the history of evidence where appropriate and verifying the integrity of the evidence if said value coincides with the protected in the secure storage medium;

v.

If the evidence is to be delegated, a digital witness is chosen to transmit the evidence (3), considering that, in accordance with the evidence transfer policy, it must be delegated when:

one.

A is not a digital custodian. A must transmit the evidence at least once to a custodian,

2.

The device reaches a supported storage threshold (configurable),

3.

The evidence generated is critical, or the lifetime will be consumed, or

Four.

If 8 is more likely to reach the final destination soon and the transfer does not harm the life of the evidence more than if it was stored / guarded;

and considering the choice of the next digital witness to compliance of the following requirements: rtl. B can attest that he is a digital witness and his level;

rt2.

B is a digital witness of my smo level that A, or A has

level less than B; that is, the set of possible couples

is

{(td, td), (cd, cd), (td, cd)), with td: digital token, cd:

digital custodian;

rt3.

B satisfactory the criteria for safeguard the evidence

electronics;

rt4.

B is the highest delegation candidate of all

possible,

O well that candidate that offer plus

guarantees / probability that the evidence reaches the destination

final minimizing pivot; or

rt5.

B is a digital custodian and requests the sending of evidence,

and A can verify the identity of 8;

saw. Once witness B is chosen, the electronic evidence information is delegated or sent to said witness B (4) using the FEE adapted for digital testification, preferably through a secure channel establishing a digital custody chain (CCD) by means of pivoting or virtual delegation of electronic evidence; vii.B authenticates the electronic evidence and proceeds to its storage by creating its own evidence to reflect the receipt of this evidence in its history, sending or not to A proof that the receipt and storage of the evidence has been possible (6 ): l. If B sends A proof that the receipt and storage of the evidence has been possible (6), A records it in the record (set of identifiers of the evidence generated and a code indicating YES was transmitted, and the guarantee given by the receiver in step (6 », proceeding A to eliminate or not the evidence according to the storage and deletion of evidence of the digital witness;

2. If B does not send this proof, A will send the evidence

in the history (set of evidence identifiers

generated and a code indicating if it was transmitted) but not the

eliminates

s

2.

Method according to the preceding claim characterized in that in the

establishment of the cryptographic mechanisms, configurations and policies that

make up the set of security associations (SA) of the

digital witness also intervenes the contractual manager, updating on demand (for

10

example, from a digital custodian) information about cryptographic mechanisms,

configurations and policies defined by the electronic ev manager; cas, said

information updated by the contractual manager also safeguarded as

electronic evidence in the secure storage means of the digital witness.

fifteen

3. Method according to any of claims J or 2 characterized in that the

binding delegation of the identity of the user or object to the device or

electronic devices that allow obtaining or generating evidence

performs using a SIM / U1CC card, a digital identification certificate, or

through a biometric system.

twenty

Four.

Method according to the preceding claim characterized in that for the

indissoluble binding delegation of the identity of the user or object to the

electronic devices that allow obtaining or generating the

evidence by binding credentials the user or object di spone of a couple of

2S

public and private keys, the private key protected within a security chip

(for example, eSE) and the inextricable delegation of identity is carried out

using a cryptographic primitive (proxy s; gnature).

5.

Method according to the preceding claim characterized in that for the

30

binding delegation indiso luble of the identity of the user or object towards the

device or electronic devices that allow obtaining or generating the

37

evidence through binding credentials the user or object delegates the use of their private key to the device to sign the evidence using that device.

6.

Method according to claim 4 characterized in that the indissoluble binding delegation of the identity of the user or object to the electronic device or devices that allow the obtaining or generation of the evidence through binding credentials includes the use of a token (warrant), signed with The private key of the user or object, which indicates the identity of the device and the period of validity of the delegation, among other data, said token once provided to the device would be attached to the evidence by signing it with its own key.

7.

Method according to claim 4 characterized in that the indissoluble binding delegation of the identity of the user or object to the electronic device or devices that allow obtaining or generating the evidence includes the use of the user's private key or object to generate a pair of private and public keys associated with the identity of the user or object, which are used by the device to sign the evidence while allowing the verification of the identity of the user or object that generated the evidence.

8.

Method according to any of the preceding claims characterized in that the header that is generated when the evidence (1) is obtained and that contain the relevant information according to a certain Electronic Evidence Format (FEE), comprises the following data:

to.

Exchange: version, size, identifier, organization, description, timestamp, total files, file number, file size, file format, signature type, finna size; Y

b.

Forensic collection: version, size, identifier, creator, creation date, date of obtaining, total files, file number, file size, file format, device type, device model, serial number

of the device, number of sectors of the device, first sector, number of sectors of evidence, type of signature, size of signature. 9. Method according to the preceding claim characterized in that the head of the evidence also includes information on the role (level of delegation) of the device. 10. Method according to any of the preceding claims characterized in that the user or object delegates his identity in a binding and indissoluble way to more than one electronic device, said two or more electronic devices comprised within the same reliable personal area network (PAN) environment. eleven . Method according to any of claims 2 to 10 characterized in that the user or object delegates his identity in a binding and indissoluble way to more than one electronic device, said two or more electronic devices possessing his own pair of keys that are generated by the user or object (for example, through an electronic identification certificate such as a DNI-e).

12.

Method according to any of the preceding claims characterized in that the presence of the user or object that generates or receives the evidence is ratified by context-based authentication mechanisms or by systems

Biometric

13.

Method according to the preceding claim characterized in that before performing any operation that requires the presence of the user or object, it must indicate to the operations manager its availability (for example responding to an alert of the operations manager) when said operations manager demands to the user or object that is authenticated through context-based authentication mechanisms or, in the case of a user, through biometric systems confers to the

security associations established for the digital witness, so that if the authentication is correct., what is recorded as evidence, the manager of operations continue with the planned operations. 14. A method according to the preceding claim, characterized in that authentication by means of authentication mechanisms based on context or, where appropriate (user, not object), by means of biometric systems confuses security associations 5 established for the digital witness is done locally in a step prior to sending the evidence to be delegated, keeping the result of the verification as evidence and validating the use of such authentication mechanisms based on context or said biometric systems before each successive use thereof. A method according to claim 13, characterized in that authentication by means of authentication mechanisms based on context or, where appropriate (user, non-object), by means of biometric systems confides to the security associations established for the digital token is provided as evidence additional to the evidence but must be collated or authenticated by the digital witness who receives the evidence 15 using existing databases that allow the identification of the user or object that sends or delegates the evidence as the same user or object that established the binding credentials.

16.

Method according to any of claims 2 to 15 characterized in that the user or object that establishes the binding credentials authorizes the use of the digital token to other users or objects by means of authentication mechanisms based on

context or through biometric systems associated with said other users or objects.

17.

Method according to any of claims 2 to 15 characterized in that the user or object that establishes the binding credentials simultaneously activates binding credentials for other users or objects (a credential binding by

user or object).