ES2587584A1 - Digital witness: procedure and devices for the secure management of electronic evidence with binding credentials (Machine-translation by Google Translate, not legally binding) - 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 token) on which the user or object that obtains, generates or receives evidence delegates its identity in a binding and indissoluble manner through binding credentials characterized in that it comprises 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 methods that make use of said digital tokens and that include the obtaining, signing, storage, delegation and, where appropriate, erasure of electronic evidence. (Machine-translation by Google Translate, not legally binding)

Description

  2 Digital proof: Procedures and devices for the secure management of electronic evidence with binding credentials TECHNICAL SECTOR 5 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 referred to the field of forensic computing.   STATE OF THE TECHNIQUE 10 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 capacities, since 15 in them we store images, projects and data that, although they could have their physical version (ex.  the simile between a handwritten letter and an e-mail), in its 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.   20 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 - electronic evidence - that sheds light on an open case can be extracted.   25 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 delicate cases is carried out by authorized justice personnel, and, in the definition of Electronic Evidence Management Systems (SGEE), given in the multi -NORM 71505: 2013, emphasizes the owner of digital evidence and people as responsible [1].    3 Although the management of electronic evidence is quite regulated, we believe that it could be considerably improved if the latest technological advances that provide security architectures to mobile user devices are further exploited and, therefore, prepare them much better than traditional architectures to witness some facts.   5 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 the 10 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 they would be able to confess inappropriate behaviors even of its user.   This fact, which could be considered contrary to the principles of privacy, can be used to increase a user's privacy on a manner.  In fact, the use of these trusted core devices, supported by hardware-shielded chip storage against modifications (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 happens on the network and this fact 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.    4 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 way, 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 20 methods for the treatment of 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.   25 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 organizational and security policies of the organizations.   Throughout the CVEE, the properties of data reliability and integrity of electronic evidence must be guaranteed, in addition to preventing unauthorized entities from accessing the data.  If electronic evidence at any time in the cycle is likely to be 5 modified without being able to prove 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 5 IoT scenarios.  Some of these challenges arise from work [3], where the concept of IoT-Forensics is defended as something new, which contemplates from the most restricted objects in resources to the Cloud.  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 IoT is a dynamic, heterogeneous and distributed environment, and the requirements for identification, preservation, analysis and presentation of the GEE require fine-grained control over computer data, difficult to provide in the IoT.  For example, work [4] identifies some of the open challenges for GEE in IoT taking these requirements into consideration.  Among these challenges are: identifying 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.  The possible drawback of the figure of IoT providers, which would store device data, complicating the preservation process, is also pointed out.  Another open challenge is the forensic analysis of identifiable artifacts (evidences) in objects.  The extraction of evidence from objects is not only not fully defined (for example, in the case of sensors), but it is faced with formats for presenting 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 in mobile devices [5], or to standardize the presentation and formats for the exchange of electronic evidence [6].  The preservation of electronic evidence through the concept of Digital Chain of Custody (CCD) 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 IoT; 30 currently the objects could not be participants without compromising the CCD.  In [7] a CCD is proposed to send digital digital evidence with time stamp to an entity 6 through the Internet, while in [8] a CCD is proposed that considers tag cabinets 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.  [9] provides a state of the art on the latest works on CCD.  In this work it is reflected that the CCD follows an orientation towards traditional communication architectures, where the management of electronic evidence is carried out by unrestricted resources resources, and mobile devices, despite integrating security architectures, remain within this chain as mere containers of evidence, and, if participating (p. ex.  to send the evidence via the Internet), the process requires direct user intervention at all times.   However, the requirements to make use of a CCD in the IoT considering the 10 security features 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 Identities of Things (IDoT) is being widely discussed [10] before the proliferation of devices, to define the relationship between 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 IoT is the storage of electronic evidence in bulk.  Initiatives such as the EVIDENCE project (European Informatics 20 Data Exchange Framework for Courts and Evidence) 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 IoT 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 forensic 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 forensic procedure does not interrupt the operation of the device from which the 30 evidences are extracted, or (b) dead (when the evidences are obtained from a device with no function other than the one to be analyzed, for example when the data of a partition of 7a hard disk seized [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 (CoT) to the platform where they were embedded, as is the case of the chip called Trusted Platform Module (TPM) developed by the Trusted Computing Group (TCG).  The TPM 10 chips integrate a factory master key that never leaves the chip, since it has its own cryptographic processor that allows hash, encryption and signature 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 it also allows measurements of the environment parameters that are stored as hashes in PCR records, and that validate the integrity of the measurements.   This last feature was available as of version 1. 2 of TPM where remarkable 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, chip 20 is still integrated in the board.   The TPM chip has had many applications in recent years, also being 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 25 and that this fact would allow updating the software that uses the device conveniently and carry out a check on the state 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 Cards / UICC, 30 (ii) microSD Cards, or (iii) embedded in the mobile device (eSE).  In addition, you can 8 Consider that the SE uses the antenna of the mobile device (Single Wire Protocol, SWP), or that the options (i-ii) have their own integrated antenna (Dual Interface).   The SE can be found on mobile devices or personal devices such as tablets, and even wearables.  Its most palpable functionality in this area has been seen with Near Field Communication (NFC) technology, a short-range communication technology for making electronic payments with mobile devices without contact with the payment terminal.  Although NFC defines the 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 device's own body.  In order to extend mobile payment, solutions such as Boosted NFC SE integrate the secure element into ultra-small devices, such as the case of smart wearables.   It should be noted that the identification cards and tokens are themselves anti-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 (ex.  fingerprint) of the device owner or authorized [16].  In addition, from W3C, efforts are made to define interfaces between Web applications and SEs.   However, some see in the use of the SE a limitation to carry out transactions, so alternatives also arise to avoid the use of the SE, such as Host Card Emulation (HCE) technology, which uses the 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 25 integrated in the device, which would be located in the Cloud, and therefore the control of that data would be left to the care of 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 computer data, and therefore the evidence 9Electronics, 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.   The acquisition and management of electronic evidence must be carried out so that the 5 tests cannot be called into question.  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 electronic evidence it is not to carry out a computer equipment, but to reach the individual 10 or corporation behind the computer equipment and assign responsibilities.  For this to be possible, linking a device with a user is essential.   Today, examples of links between a natural person and an object exist.  The oldest example could be in the use of a person's identification.  The papers that identify an individual and certify that he is who he says he is, allow for paperwork.  Thus, 15 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 the relevant authorities of the loss, loss or theft of the DNI-e using the legal mechanisms and procedures available for 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 your convenience allows the objects that carry our identity to perform actions more comfortably, and integrate new technologies that are still in the spotlight, as is the case of the DNI-e v3. 0, which incorporates NFC.   Therefore, digital testification is necessary because it would support GEE for the new challenges that are marked by the implementation of paradigms such as IoT: DESCRIPTION OF THE INVENTION 30 10An aspect of the present invention relates to procedures for the secure management of electronic evidence within the framework of the IoT.  Although in the present document the invention is contextualized 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 evidence Electronic  5 First of all, 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 IoT not considered is precisely how to bring 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 20 evidences, the digital custody chain must be maintained to preserve the evidence while maintaining the reliability of the test and the user-device linkage.  As a final result, a functional architecture for digital testification is proposed in the present invention.   Figure 1 shows in simplified form the basic steps of a general embodiment of the procedure that constitutes a first object of the invention from the time the electronic evidence is obtained until, where appropriate, the space of its storage is released.  Each step of the process is subject to the management of contextual information.   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 11 secure storage.  The signature of the evidence will depend on the mechanism chosen to link the identity.   At some point, if the evidence is to be delegated, a digital witness is chosen to transmit the evidence (3).  We believe that electronic evidence must be delegated when: 5 a.  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.  10 d.  If B is more likely to reach the final destination soon and the transfer does not harm the life of the evidence more than if A stored / guarded it.  On the other hand, the choice of the next digital witness, if applicable, is conditioned on compliance with the following requirements: 15 rt1.  B can attest that he is a digital witness and his role / level.  rt2.  B is a digital token of the same level as A, or A has a lower level than B.  That is, the set of possible pairs is: {(td, td), (cd, cd), (td, cd)}, with td: digital witness, cd: digital custodian.  20 rt3.  B 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.  B 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.  B is a digital custodian and requests that evidence be sent, and A can verify the identity of B.  Once witness B is chosen, information on electronic evidence is sent (4) using the FEE adapted for digital testification, using a secure channel.  B 12Then authenticate the electronic evidence and proceed to its storage.  In this step, B 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 B does not send this proof, A records in the record that the evidence was sent to B, but does not eliminate it.  The reception guarantee is stored in the history (7).   5 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).   10 Finally, A can free up the space of evidence or set of evidence (8), if appropriate.    Storage and format of electronic evidence 15 Electronic evidence can take up a lot of space, since, unlike an anomaly, an electronic evidence can be any data.  So it is necessary to (i) define what we will consider evidence, (ii) the format for the IoT evidence (the one defined in [1] is too ambitious for small objects), (iii) the amount of information / evidence that we will store , (iv) what evidence will be more priority.   20 As defined in [1], in an SGEE a FEE is required that serves both for the exchange of evidence and to assist in obtaining forensics.  The objective of using a format is to facilitate the understanding of the evidence and expedite its processing.  This also allows summarizing the information, using identifiers, when using standardized mechanisms that we can classify and make available to the participants of the environment.  25 We would thus 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: c1.  Exchange: version, size, identifier, organization, description, time stamp, total files, file number, file size, file format, signature type, signature size.   13c2.  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, size of signature.  5 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 storage medium of the test (ex.  hard disk from which the evidence has been extracted), and have a clear aspect towards obtaining dead data (Section II-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 made up of interchangeable parts.   However, in the field of mobile devices, considering that these are 15 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 known characteristics of the devices with a certain profile.  Since the FEE has a version identifier 20, 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 the information includes more aspects to consider.  For example, if only the data of the device generating the evidence or the data of the intermediate devices where the evidence is temporarily housed are considered.  The latter case is closely linked to the transfer of electronic evidence between the different participants.   In addition to simplifying the headers considering the limitations of the devices, at least the following aspects should be considered to implement our approach: 30 14  Safe Element.  Data relating to which implementation of the safe element has been used, or if it has not been used.    Life time.  Information on the possible expiration of the evidence.  It can be composed of a code that indicates the interpretation of the life time (ex.  based on the number of pivots) and a value. 5  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.    10 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 signed evidence.  The use of anti-tampering mechanisms to store hash values has been used, for example, for reliable startup, or Root of Trust (RoT) of the TPM chip (Table I).  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 Configuration 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 format of evidence 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 commitment window of 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 15 as a recognized digital witness, (b) a personal object in the 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 character of the 5 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.    10 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, it must allow during the handling of the evidence to unequivocally trace the natural person behind that 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 SIM / UICC card (p. ex.  IMSI identifiers, MSISDN [17]), since in certain countries such as Spain the natural person needs to provide a legal document to obtain that identity.  Another example is the use of digital identity documents (e.g. ex.  DNI-e), as they allow a natural 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 an 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 signatures [19].  Moreover, all the strategies to implement this cryptographic primitive [19] we 16 allow to implement the link between user and evidence, as shown in Figure 4 and developed in the following paragraph.   In its simplest form (full delegation, 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 warrant, DbW) consists in 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 signing it with its own password.  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 these keys are associated with the identity of the user (p. ex.  using identity-based cryptography [20]), the identity of the user who generated the evidence can be verified.   In our approach, the result of the FD, DbW 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 (p. ex.  FD or PK case) 15 or tokens (p. ex.  case of warrant), 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 proxy signatures 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 (e.g. ex.  eSE), which will allow operations of 20 digital signature.  These requirements can be resolved using the underlying mechanisms of binding identities.  For example, in the case of mobile devices, and according to the 3GPP TS 33 standard. 221 [21], 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 in the UICC.  This would allow the evidence to be signed within the UICC itself and include the necessary identifiers (IMSI, 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 a DNI-e to a device through a card reader and a USB port, and 30 through an NFC connection using the DNI-e v3. 0.  This allows to use the private key of the individual contained within the DNI-e to, for example, sign the evidence directly or 17Provide 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.   5 All these methods work if only one mobile device is used for the acquisition and management of evidence.  However, its use may be restricted in ecosystems such as IoT, where several devices with quite limited resources could participate in CVEE.  Moreover, the problem of the identification of IoT objects (and their owners) is still open today [23].  However, there are several jobs 10 whose objective is to develop a reliable personal area network (PAN) environment, in which the devices are owned by a single user.  Works such as [24] demonstrate that it is possible to exchange information securely among members of a NAP, delegating the most complex tasks (p. ex.  authentication with external devices, storage of information) to those elements that have sufficient capacity to perform them.  Other works, such as 15 [25], develop the concept of personal PKIs, in which each device controlled by a user can have its own pair of keys, which are generated by the user (p. ex.  through your DNI-e).  All these properties allow that, in certain PAN environments, it may be possible to generate evidence, store them, and verify them through proxy signatures.   20 Finally, there is another aspect that should be considered with caution: the use of proxy signatures allows linking an 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 warrant through his DNI-e, but not control the device during the process of acquisition and / or transmission of evidence.  If this is necessary, 25 context-based authentication mechanisms [26] or biometric systems [27] can be used to ratify the user's presence.  Another approach to take into account, inherited from the principles of IoT, is that it is the object itself or objects that collect evidence of user participation throughout the process.   30 Secure transmission of electronic evidence 18 The secure transmission of electronic evidence in accordance with the present invention requires establishing what is called a digital custody chain (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 electronic evidence), 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: give 1.  Delegation of a user to another user with more privileges.  It would correspond to 10 citizen collaboration to collect evidence and notification to a user with the power to manage them.  give 2.  Delegation of a user to another object (mobile) with more privileges or resources.  It is similar to the case of him, 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.  give 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 carried out on fixed structures, which will probably be the final storage of the evidence before processing or transfers to other entities following the traditional schemes 20 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 of their evidences to another user with power.  25 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 30 delegation between objects less restricted with resources and less linked to personal use.   19 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 5 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 figure of Digital Witness being understood. such as a device with a trusted core capable of protecting electronic evidence against any modification and unauthorized access and transferring it 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 management of electronic evidence.  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).    20It 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 5 saves a lot of information that would allow identifying 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.  10 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.   15  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 a digital witness is strong if it is a device with a trusted core 20 and also has the identity of the user.  This allows, 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 device 25 belongs to an individual with representation in the legal system (ex.  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 the evidence is more controlled and its safeguarding too.  This is the custodian figure 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 30 linked to the administration, because as a general rule custody is carried out by state security bodies.    21The 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 5 electronic evidences of a probative nature, acceptable in a possible litigation, in dynamic, heterogeneous and distributed IoT scenarios.  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 makes it possible to expedite police work through binding 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: 15 1) Operations manager between the user and the device .  It allows you to link the identity of a user with your 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 biometric tests from the user for the GEE. 20 2) Contract manager.  It is an optional component that allows the digital witness to indicate the 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 accepted mechanisms, 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, anti-tampering) that will be used during the GEE, and probably (although not necessarily) by the user-device operations manager.  30 4) Secure storage with access control.  Protected storage in a secure item (it can be the same secure item as the one containing the 22 cryptographic mechanisms or other).  This component would store keys and other protected data, such as hashes of electronic evidence, the contract, and binding credentials.  5) Electronic evidence manager for objects.  Coordinates the operations of acquisition of electronic evidence, secure storage, and transfer of electronic evidence 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 (p. ex.  considering the privacy of the data).  Specifically, in [1] the following are defined as allowed operations:  Symmetric key algorithms: 2TDEA, 3TDEA, AES l28bits-256 bits.  Electronic signatures and hash applications: SHA224 / 256/384/512.  HMAC, key derivation functions, random number generation: SHA1 / 20 224/256/384/512.    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, in accordance with the requirements of [1], the OPTIGA Trust authentication chip using 2048bit RSA could protect high level confidential information, and using 512bit ECCs and 256 AES protect high level secret information (the maximum scale defined in [one]).  Therefore, it is a good option for use as a strong digital witness.  In addition, it allows the exchange of keys using diffie hellman (DH) or DH using elliptic curve cryptography (ECDH), speeding up the creation of secure communication channels.   In the present invention, the minimum requirements that the device technology must satisfy to be a digital witness according to our definition are established, but it is possible 23state that although examples are proposed to demonstrate that the scheme is implementable in practice, such implementation is not specifically associated with a single type of device, but that the proposed requirements can be satisfied by a broad spectrum of devices.   5 DESCRIPTION OF THE FIGURES Figure 1.  Basic steps of digital testification and scale of values.  Figure 2  Roles in digital testification and basic requirements.  Figure 3  Pivoting evidence.  10 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 15 (binding credentials, BD).  Figure 9  Flowchart for the case (A) considering the Contract Manager.  Figure 10  Flowchart for case (C) considering the use of biometric mechanisms.  Figure 11  Biometrics as an additional test.   20 EXAMPLE OF EMBODIMENT OF THE INVENTION The constitution and characteristics of the invention will be better understood with the aid of the following description of embodiments, it being understood that the invention is not limited to these embodiments, but that the protection encompasses all those alternative embodiments. that may be included within the content and scope of the claims.  Likewise, the present document refers to various documents as prior art, being understood by reference the content of all these documents, as well as the complete content of the documents referred to in said documents, in order to offer a description as possible complete state of the art in which the present invention is framed.  The terminology used below is intended for description 24 of the examples of embodiments that follow and should not be construed as limiting or restrictive.    Interaction between components 5 Next we define three basic cases (A-C) of interaction between the components shown in Figure 6.  The flow chart detailing the interaction between the components is shown in Figure 7: (A) Establishment of action policies for the use of the digital token.   10 (B) Creation of binding credentials (BD). (C) Evidence management with BDs.    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, (GP1, Group Policy 1) the policies that relate the user to the device, not only by terms of service, but by other policies that depend on the use of the device (e.g. ex.  20 acceptance of permits, configuration of resources such as the space that can be used to store evidence), and, on the other hand, (GP2, Group Policy 2) the policies that define the operation of the Electronic Evidence Manager for Objects (EE Manager).  In general, GP1 and GP2 form the set of security associations (SA), which will be used by the digital witness.   25 The more general policies, GP1, 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: (P1) evidence generation policy, (P2) evidence transmission policy 30, (P3) evidence storage policy, (P4) deletion or deletion policy of evidence.  All policies include the list of mechanisms of 25security and cryptographic accepted for each case and consider the list of requirements mentioned above.  In relation to (P1), 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 a 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.   15 Finally, case (C) 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 hash writing 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 historical 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, 30 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 26 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 (e.g. ex.  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).   5 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 15 with delegation level 1 (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 You have 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 25 evidences.  This more specific example also shows that it would be desirable for the role of the device (e.g. ex.  the level of delegation) is 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.   30 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 27 valid for other mechanisms that allow establishing binding credentials that help to unequivocally define the relationships between users, devices and electronic evidence.    Optional interaction between components, optional components and extensions 5 Contract manager The case (A) detailed in the previous section can be improved through the use of the optional Contract Manager component to establish the policies for the electronic evidence manager 10 of objects.  If the contractual manager is employed in this 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 electronic evidence (Figure 9).   In this scenario, the interaction occurs between the contractual manager and the EE 15 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 25 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.    30 Use of biometric mechanisms as part of the User-Device Operations Manager 28 As can be seen in Figures 7 and 9, another optional element within our architecture is the use of biometric systems to test the user's presence.  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 5 acceptable configurations, which must define at least i) the type of biometric system to be used (e.g. ex.  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 statically, or dynamically in those architectures that have the optional Contract Manager component.   10 This optional interaction is mainly carried out between the user and the User-Device Operations Manager (figure 10).  Before performing any operation that requires the presence of the user, he must indicate to the Operations Manager his availability (p. ex.  responding to an alert from the Operations Manager).  At this point the Operations Manager will ask the User to authenticate by means of the biometric systems 15 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 policies of the digital witness, the use of biometric mechanisms is recorded as evidence once the user consents to the terms of the service.  But, in addition, there are traces of the use of biometric systems every time an operation requires user approval (p. ex.  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 using a simple record to biometric information (e.g. ex.  the image of the fingerprint used at that time) in those mechanisms that allow it.   25 Regarding the use of a biometric system, the nature of these data should be pointed out.  Today, most biometric systems allow you to store information about a user who will use the device (e.g. ex.  "Touch ID" by Apple [30]), but nothing guarantees that the user registered on the device is the same as the user who performed the process of the binding credentials.  This data is relevant, because it is the binding credentials that determine the final person responsible for the evidence.  The case of the existence of multiple users who can make use of the device therefore requires special consideration.    29 Figure 11 shows different use cases of the digital device: (1).   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 5 test.  (3).   Weak biometric (not collated).  Biometric data is provided as additional evidence to the evidence, but must be collated or authenticated by the remote entity that receives the evidence.  10 If you want to hold a specific user responsible for sending electronic evidence, the biometric information provided by the user (p. ex.  your fingerprint) must be checked against a legally valid source (e.g. ex.  the fingerprint stored in a DNI-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 (p. ex.  using a DNI-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 20 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 collate the evidence provided by the biometric mechanism (e.g. ex.  the fingerprint) with the existing databases to identify the individual who authorized the sending of the evidence.  25 In this case, the digital token 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.  30 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 30 relevant based on context (p. ex.  biometric data collated from authorized individuals).  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 simultaneous activation of multiple binding credentials, one for each user.  Although 5 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] Une 71505: Information technologies (ti).  electronic evidence management system (sgee).  Information Technology, 2013.  [2] Mariantonietta La Polla, Fabio Martinelli, and Daniele Sgandurra.  A survey on security for 15 mobile devices.  Communications Surveys & Tutorials, IEEE, 15 (1): 446–471, 2013.  [3] Edewede Oriwoh, David Jazani, Gregory Epiphaniou, and Paul Sant.  Internet of things forensics: Challenges and approaches.  In Collaborative Computing: Networking, Applications and Worksharing (Collaboratecom), 2013 9th International Conference Conference on, pages 608–615.  IEEE, 2013.  20 [4] RC Hegarty, DJ Lamb, and A Attwood.  Digital evidence challenges in the internet of things.  In Proceedings of the Tenth International Network Conference (INC 2014), page 163.  Lulu  com, 2014.  [5] S Omeleze and HS Venter.  Towards a model for acquiring digital evidence using mobile devices.  In Proceedings of the Tenth International Network Conference (INC 2014), page 25 173.  Lulu  com, 2014.  [6] Eoghan Casey, Greg Back, and Sean Barnum.  Leveraging cyboxTM to standardize representation and exchange of digital forensic information.  Digital Investigation, 12: S102 – S110, 2015.  [7] Tomás Marqués Arpa and Jordi Serra Ruiz.  Chain of custody in forensic analysis.  30 implementation of a digital evidence management framework.  In XIII Spanish Meeting on Cryptology and Information Security (RECSI 2014).  University of Alicante, 2014.  [8] Yudi Prayudi, Ahmad Ashari, and Tri K Priyambodo.  Digital evidence cabinets: A proposed frameworks for handling digital chain of custody.  Int.  J.  Comput  Appl, 35 109 (9): 30–36, 2014.  [9] Yudi Prayudi and SN Azhari.  Digital chain of custody: State of the art.  International Journal of Computer Applications, 114 (5), March 2015.  [10] Ingo Friese, Jorg Heuer, and Ning Kong.  Challenges from the identities of things: Introduction of the identities of things discussion group within kantara initiative.  In 40 31 Internet of Things (WF-IoT), 2014 IEEE World Forum on, pages 1–4.  IEEE, 2014.  [11] Cory Altheide and Harlan Carvey.  Digital Forensics with Open Source Tools: Using Open Source Platform Tools for Performing Computer Forensics on TargetSystems: Windows, Mac, Linux, Unix, etc.  Elsevier, 2011.  [12] Eoghan Casey.  Digital evidence and computer crime: forensic science, computers and the 5 internet.  Academic press, 2011.  [13] Ray Hunt and Jill Slay.  Achieving critical infrastructure protection through the interaction of computer security and network forensics.  In Privacy Security and Trust (PST), 2010 Eighth Annual International Conference on, pages 23–30.  IEEE, 2010.  [14] Irfan Ahmed, Sebastian Obermeier, Martin Naedele, and Golden G Richard III.  Scada 10 systems: Challenges for forensic investigators.  Computer, (12): 44–51, 2012.  [15] Tcg tpm 2. 0 automotive, committee draft.  Technical report, Trusted Computing Group (TCG), 2014.  [16] Raul Sanchez-Reillo, Daniel Sierra-Ramos, Roberto Estrada-Casarrubios, and Jose A Amores-Duran.  Strengths, weaknesses and recommendations in implementing biometrics 15 in mobile devices.  In Security Technology (ICCST), 2014 International Carnahan Conference on, pages 1–6.  IEEE, 2014.  [17] Rick Ayers, Sam Brothers, and Wayne Jansen.  Sp 800-101 rev.  1, guidelines on mobile device forensics.  Technical report, Gaithersburg, MD, United States, 2014.  [18] Víctor Gayoso Martinez, Luis Hernández Encinas, Antonio Martín Muñoz, and Juan 20 Ignacio Sanchez García.  Identification by means of a national id card for wireless services.  In 2013 16th International Symposium on Wireless Personal Multimedia Communications (WPMC), pages 1–5, June 2013.  [19] Alexandra Boldyreva, Adriana Palacio, and Bogdan Warinschi.  Secure proxy signature schemes for delegation of signing rights.  Journal of Cryptology, 25 (1): 57–115, 2012.  25 [20] He Debiao, Chen Jianhua, and Hu Jin.  An id-based proxy signature schemes without bilinear pairings.  Annals of Telecommunications, 66 (11–12): 657–662, 2011.  [21] 3GPP TS 33. 221: Support for Subscriber Certificates.  http: // www. 3gpp org / DynaReport / 33221. htm  Accessed on April 2015.  [22] STORK2: Secure Identity Across Borders Linked.  https: // www. eid-stork2. eu /.  Accessed 30 on April 2015.  24 [23] Sabrina Sicari, Alessandra Rizzardi, Luigi Alfredo Grieco, and Alberto Coen-Porisini.  Security, privacy and trust in internet of things: The road ahead.  Computer Networks, 76 (0): 146-164, 2015.  35 [24] Marc Barisch.  Design and evaluation of an architecture for ubiquitous user authentication based on identity management systems.  In 2011 IEEE 10th International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom), pages 863–872, Nov 2011.  [25] John Lyle, Andrew Paverd, Justin King-Lacroix, Andrea Atzeni, Habib Virji, Ivan 40 Flechais, and Shamal Faily.  Personal pki for the smart device era.  In Sabrina De Capitani di Vimercati and Chris Mitchell, editors, Public Key Infrastructures, Services and Applications, volume 7868 of Lecture Notes in Computer Science, pages 69–84.  Springer Berlin Heidelberg, 2013.  [26] Seyed Amir Hoseini-Tabatabaei, Alexander Gluhak, and Rahim Tafazolli.  A survey on 45 smartphone-based systems for opportunistic user context recognition.  ACM Computing 32Surveys, 45 (3): 27: 1–27: 51, Jul 2013.  [27] Liam M.  Mayron  Biometric authentication on mobile devices.  IEEE Security and Privacy, 13 (3): 70–73, May 2015.  [28] Syed Rahat and Wayne Browning.  Methods and systems for secure communications between client applications and secure elements in mobile devices, December 2 2014.  US 5 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 Yousuf H Vaid.  Apparatus and methods for secure element transactions and management of assets, February 6 2014.  US Patent App.  14 / 174,791.  10 [30] About Touch ID security on iPhone and iPad.  https: // support. Manzana. com / en-us / HT204587.  Accessed on July 2015.    

Claims (1)

33 CLAIMS 1. 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 their identity in a binding and indissoluble way through binding credentials 5, and characterized in that it comprises : to. An operations manager between the user or object and the device, responsible for establishing the policies that relate the user or object to the objective and that allows linking the identity of a user or object with their device, generating at least one binding credential (binding credential , BD); 10 b. a nucleus of trust, responsible for ensuring the integrity of the electronic evidence, preventing unauthorized access and allowing its transfer to an authorized entity, and which in turn comprises: 1. Cryptographic mechanisms accepted within a secure element (hw chip, anti-tampering) to establish a secure communication channel; and 15 2. secure storage media with access control, protected in a secure element (it can be the same secure element as the one that contains the cryptographic mechanisms or a different one), to store keys and other protected data, for example the hashes of electronic evidence and binding credentials; and 20 c. 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, erasure or elimination of evidence. Device according to the preceding claim, characterized in that the manager of operations between the user or object and the device requires the user or object to authenticate through context-based authentication mechanisms or, in the case of a user, through biometric systems. . 30 343. Device according to any of the preceding claims, characterized in that the cryptographic mechanisms are used by the operations manager between the user or object and the device. 4. Device according to any of the preceding claims, characterized in that the cryptographic mechanisms that integrate the secure element to establish a secure communication channel are chosen from among the following technologies: Symmetric key algorithms (2TDEA, 3TDEA, AES l28bits-256 bits ), electronic signatures and hash applications (SHA224 / 256/384/512), HMAC, key derivation functions, random number generation (SHA1 / 224/256/384/512). Device according to any of the preceding claims, characterized in that it also comprises a contractual manager, which allows indicating to the digital witness the cryptographic mechanisms and the most robust configuration acceptable for the acquisition of evidence. 15 6. Procedure for the secure management of electronic evidence with binding credentials characterized in that it makes use of two or more devices according to any of the previous claims and that it comprises the following stages: 1. Establishment of cryptographic mechanisms, configurations and policies 20 that make up the set of security associations (SA, Security Associations) of the digital witness through the operations manager between the user or object and the digital witness and through the electronic evidence manager, security associations that, once established, are safeguarded as electronic evidence; 25 2. 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 the obtaining or generation of evidence through binding credentials, said Binding credentials (keys, tokens) generated by the operations manager between the user or object and the digital token using accepted cryptographic mechanisms 35and safeguarded by means of secure storage protected in a secure element of the digital witness; 3. When a user or object obtains the evidence (1) in accordance with the security associations of the digital witness, a header is generated with the pertinent information according to a specific Electronic Evidence Format (FEE), 5 generating an identifier of the evidence to starting from the binding identifier of the electronic device that generates it, and the time stamp, said header comprising (i) data relative to which implementation of the secure element has been used, or if it has not used the 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; 4. The evidence is signed according to the mechanism chosen to link the identity and the probative value is stored (2) according to criteria of secure storage, said probative value consisting at least of the hash value of the signed evidence, said hash being generated through appropriate cryptographic mechanisms and registered in the secure storage media of the digital witness either directly or at the request of the electronic evidence manager, updating the history of 20 evidences, where appropriate, and verifying the integrity of the evidence if said value hash matches the protected one on the secure storage medium; 5. If the evidence is to be delegated, a digital witness is chosen to transmit the evidence to (3), considering that, according to the evidence transfer policy, it must be delegated when: 25 i. A is not a digital custodian. A must transmit the evidence at least once to a custodian, ii. Device reaches a supported (configurable) storage threshold, 30 iii. The evidence generated is critical, or the life span will be consumed, or 36iv. If B has a better chance of reaching the final destination soon and the transfer does not harm the life of the evidence any more than if A stored / safeguarded it; and considering the choice of the following digital witness to the fulfillment of the 5 following requirements: rt1. B can attest that he is a digital witness and his role / level; rt2. B is a digital token of the same level as A, or A has a lower level than B; that is, the set of possible pairs is {(td, td), (cd, cd), 10 (td, cd)}, with td: digital witness, cd: digital custodian; rt3. B meets the criteria for safeguarding electronic evidence; rt4. B is the candidate with the highest level of delegation of all the possible ones, or else the candidate that offers the most guarantees / probability that the evidence reaches its final destination while minimizing pivoting; or 15 rt5. B is a digital custodian and requests the sending of the evidences, and A can verify B's identity; 6. Once witness B is chosen, the information on the electronic evidence is delegated or sent to said witness B (4) using the FEE adapted for digital witnessing, preferably through a secure channel establishing a digital chain of custody. (CCD) by means of pivoting or virtual delegation of electronic evidence; 7. B authenticates the electronic evidence and proceeds to its storage, creating its own evidence to reflect the receipt of this evidence in its history, sending or not sending to A a proof that the reception and storage of the evidence 25 has been possible ( 6): i. If B sends A proof that the receipt and storage of the evidence has been possible (6), A records it in the history (set of identifiers of the evidence generated and a code indicating whether it was transmitted, and the guarantee given by the receiver in step 30 37 (6)), with A proceeding to eliminate or not the evidence in accordance with the storage and erasure policies for digital witness evidence; ii. If B does not send this proof, A records it by sending the evidence in the history (set of identifiers of the evidence generated and a code that indicates whether it was transmitted) but does not delete it. 5 7. Procedure 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, Security Associations) of the digital witness, the contractual manager also intervenes, updating on demand (by 10 example, of a digital custodian) the information on the cryptographic mechanisms, configurations and policies defined by the electronic evidence manager, said information updated by the contractual manager also safeguarded as electronic evidence in the means of secure storage of the digital witness. 15. Procedure according to any of claims 6 or 7, characterized in that the 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 is carried out by means of a SIM / UICC card, a digital identification certificate, or through a biometric system. 20. Procedure according to the preceding claim, characterized in that for 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 evidence by means of binding credentials, the user or object has a pair of Public and private keys, the private key protected within a security chip (for example, eSE) and the indissoluble binding delegation of identity is carried out by means of a cryptographic primitive (proxy signature). 10. Procedure according to the preceding claim, characterized in that for 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 By means of binding credentials, the user or object delegates the use of their private key to the device to sign the evidence using said device. 11. Procedure according to claim 9 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 evidence through binding credentials comprises 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. 12. Procedure according to claim 9, characterized in that the indissolubly 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 comprises the use of the private key of the user or object to generate a pair of private and public keys 15 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. 13. Procedure according to any of the preceding claims, characterized in that the header generated when the evidence (1) is obtained and containing the relevant information according to a specific Electronic Evidence Format (FEE), comprises the following data: a. Exchange: version, size, identifier, organization, description, timestamp, total files, file number, file size, file format, signature type, signature size; and b. Forensic retrieval: version, size, identifier, creator, creation date, acquisition date, total files, file number, file size, file format, device type, device model, device serial number, number of sectors device, first sector, number of sectors of the evidence, type of signature, size of signature. 3914. Procedure according to the preceding claim, characterized in that the header of the evidence also includes information on the role (level of delegation) of the device. 15. Procedure according to any of the preceding claims, characterized in that the user or object delegates their identity in a binding and indissoluble way to more than one electronic device, said two or more electronic devices comprised within the same personal area network environment ( PAN) reliable. 16. Procedure according to any of claims 7 to 15, characterized in that the user or object delegates their identity in a binding and indissoluble way to more than one electronic device, said two or more electronic devices having their own pair of keys that are generated by the user or object (for example, through an electronic identification certificate such as a DNI-e). 17. Procedure 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 means of context-based authentication mechanisms or by biometric systems. 18. Procedure according to the preceding claim, characterized in that before performing any operation that requires the presence of the user or object, the latter must indicate to the operations manager its availability (for example, responding to an alert from the operations manager) when said manager Operations requires the user or object to authenticate through context-based authentication mechanisms or, in the case of a user, through biometric systems in accordance with the security associations established for the digital token, so that if the authentication is correct , which is recorded as evidence, the operations manager continues with the planned operations. 19. Procedure according to the preceding claim, characterized in that the authentication through context-based authentication mechanisms or, where appropriate (user, object number), through biometric systems in accordance with the security associations established for the digital witness is performed locally in a step prior to sending the 40evidence to delegate, saving the result of the verification as proof and validating the use of said context-based authentication mechanisms or said biometric systems before each successive use thereof. 20. Procedure according to claim 18, characterized in that the authentication 5 by means of context-based authentication mechanisms or, where appropriate (user, non-object), by means of biometric systems in accordance with the security associations established for the digital witness is provided as proof additional to the evidence but it must be collated or authenticated by the digital witness who receives the evidence, using existing databases that allow the identification of the user or object that sends 10 or delegates the evidence as the same user or object that established the binding credentials . 21. Procedure according to any of claims 7 to 20, characterized in that the user or object that establishes the binding credentials authorizes the use of the digital token to other users or objects through context-based authentication mechanisms or through biometric systems associated with said others. users or objects. 22. Method according to any of claims 7 to 20, characterized in that the user or object that establishes the binding credentials simultaneously activates 20 binding credentials for other users or objects (one binding credential per user or object).