1

Digital Witness: Safeguarding DigitalEvidence by using Secure Architectures in

Personal DevicesAna Nieto, Rodrigo Roman, and Javier Lopez

Abstract—Personal devices contain electronic evi-dence associated with the behaviour of their ownersand other devices in their environment, which can helpclarify the facts of a cyber-crime scene. These devicesare usually analysed as containers of proof. However,it is possible to harness the boom of personal devices todefine the concept of digital witnesses, where personaldevices are able to actively acquire, store, and transmitdigital evidence to an authorised entity, reliably andsecurely. This article introduces this novel concept,providing a preliminary analysis on the managementof digital evidence and the technologies that can beused to implement it with security guarantees in IoTenvironments. Moreover, the basic building blocks ofa digital witness are defined.

Index Terms—Digital Evidence, IoT-Forensics, Se-cure Element, Identity Delegation.

I. INTRODUCTION

Mobile user devices are deeply rooted at the heartof our society. Indeed, social networks and educa-tion in new technologies have greatly boosted theacceptance of personal devices as part of our dailylives. They are, from a functional point of view, anextension of our human abilities. Therefore, it iswell known that our devices are a valuable sourceof electronic evidence (e.g. network events, user-generated events, user data) that can shed light on aparticular case. At present, collecting and handlingsuch electronic evidence is a very delicate process,in which different stakeholders can be involved.This is an almost artisan process; in order to avoidany doubt about the integrity of the digital evidence

A. Nieto, R. Roman and J. Lopez were with the Departmentof Computer Science, University of Malaga, Spain, e-mail:{nieto,roman,jlm}@lcc.uma.es.

the majority of the cases require the involvementof humans during the seizure of evidence and thesubsequent management process.

Traditional mechanisms for handling evidenceare very robust but insufficient considering the newchallenges that paradigms such as the Internet ofThings (IoT) pose [1]. Until now, personal deviceshave been seen as containers of electronic evidence,in the same way as a corpse is analysed to findproofs to clarify the facts. However, how these de-vices can testify against malicious cyber-behavioursor cyber-offenses directed to harm their owners, orother individuals in a city, is not considered at all.Indeed, this will open the door to actively acquiringelectronic evidence from the environment of a user(with his consent) that nowadays is inevitably lost.These new sources of evidence which have not beenconsidered until now could be key in demonstratingunproved or hidden cyber-attacks and demotivatenew ones.

The need to prepare our personal devices tocope with these open issues is the reason why theconcept of digital witness is being defined here. Thefollowing objetives are addressed in this article:• Formal definition of the requirements for a

digital witness.• Discussion about the feasibility of this new

concept in personal devices.• Definition of basic components to implement

this concept in future works.This article is written as follows. First, a brief

background to the latest trends in electronic evi-dence management and other concepts related to ourapproach are discussed. Then we define the concept

A. Nieto, R. Roman, and J. Lopez, “Digital Witness: Safeguarding Digital Evidence by using Secure Architectures in Personal Devices”, IEEENetwork, pp. 12-19, 2016.http://doi.org/10.1109/MNET.2016.1600087NMNICS Lab. Publications: https://www.nics.uma.es/publications

2

AuthorisationLiabilityPreservation / Integrity

Binding Delegation

Binding Credentials Witnessing Roles

Non-Repudiation

PrivacyTraceability

Security requirements

Social & normative requirements

New concepts defined for Digital Witness

Available to be used by Digital Witness, if new functional components are implemented

Policies / User AgreementsSecure Storage Secure communicationTrusted Execution

Embedded Security Architecture

Figure 1. Requirements of a Digital Witness and definitions.

of digital witness and its requirements. After thisdefinition, the feasibility of this new concept inpersonal devices given current technological trendsis analysed. Finally, the relationships for the compo-nents of a digital witness are defined. Conclusionsand future work are discussed at the end of thearticle.

II. BACKGROUND

Traditionally, digital evidence is identified, col-lected, stored and analysed within a Chain ofCustody to ensure the integrity, provenance andtraceability of the proofs (cf. UNE 71505:2013,ISO/IEC 27042:2015). Due to the immaterial andvolatile nature of digital evidence, there are exten-sive procedures whose aim is to ensure that thisevidence is not repudiated in a court of law [2].Furthermore, it is crucial to guarantee access toauthorised entities and also identify the people whoare responsible for the evidence.

Various researchers have proposed the conceptof a Digital Chain of Custody (DCoC) [3], wherecertain evidence can be routed towards its desti-nation through intermediary devices. While DCoCadds flexibility to the traditional approach, it hassome drawbacks. For example, the type of evidencehandled is very limited (e.g., pictures with geolocal-isation), and they tend to be managed by powerfulintermediary platforms (e.g., the cloud). Besides, allexisting DCoC approaches require the interventionof their human owners at all times [4], [5].

Given the variety of scenarios where personaldevices with limited resources (e.g. mobile userdevices) are involved, including the IoT, it is nec-essary to explore new solutions that could includepersonal devices as collaborators in a DCoC. Suchsolutions must consider the basic requirements fordigital evidence management shown in Figure 1,which are derived from the standards UNE 71505,ISO/IEC 27037 and ISO/IEC 27042. There arealso standards related to digital forensics (UNE71506, ISO/IEC 30121) that include the definitionof formats and procedures during the analysis. Onepotential solution that we discuss in this article is touse the security architectures embedded in personaldevices to define the concept of digital witness.

III. DIGITAL WITNESS: CONCEPT OVERVIEW

As an evolution of existing DCoC approaches, itseems reasonable to define cases in which multipledevices behave as human witnesses. Therefore, wedefine a Digital Witness as a device which is ableto collaborate in the management of electronicevidence from both technological and legal stand-points. In order to realise this vision, a digital wit-ness defines critical components to implement thesecurity and legal requirements shown in Figure 1,and expands over various concepts and topics whichare summarized in Table I. The link between therequirements and the principles behind the conceptof digital witness will be detailed in the followingparagraphs.

3

Table IDIGITAL WITNESS - TECHNOLOGICAL LEAP.

Concept / Topic New concept BreakdownIdentity Binding Credentials

(BC) • Binds all elements (User-Device-Evidence)• Binding Delegation – delegate evidence between witnesses

Privacy IoT-based legal granu-larity • Privacy and security policies must be accepted by the user.

• The information depends on the granularity / options selected by the user.

EmbeddedSecurityArchitecture

Improve the use of exist-ing architectures in per-sonal devices

• Solutions to store electronic evidence preserving its integrity• Electronic evidence management in compliance with standards and legal

principles

IoT-Forensics Enable heterogeneousdevices to handleelectronic evidence

• Taxonomy of evidence for IoT• Homogenisation of cooperative mechanisms• Objects: ranging from wearables to vehicles and buildings

Digital Chain ofCustody (DCoC)

DCoC for IoT devices(DCoC-IoT)

The devices are collaborators, not only containers:• Format of documents for DCoC• Adapt security mechanisms for compliance with the standards and

resources without compromising security• Hardiness of DCoC-IoT based on the user’s profile

Role-based Digital evidence man-agement based in inher-ited roles

Acquisition of digital evidence based on the user’s profile:• Digital Witness: basic digital witness to be used with the user’s consent.• Digital Custodian: digital witness handled by a user with privileges (e.g.,

police officer authorised with a search warrant).

Digital witnesses are defined considering embed-ded security architectures to make use of a coreof trust to i) implement trusted execution environ-ments and ii) store and protect, with anti-tamperinghardware-based solutions, the proof of integrity ofthe digital evidence. Note that the heterogeneity ofsolutions to do this in IoT devices requires newsolutions for acquiring evidence (e.g., in propietarysensors) following IoT-forensics requirements [1],and also to homogeneise the access to securityarchitectures as far as possible.

A digital witness also needs to prove that theuser knows about the procedures that his/her de-vice is carrying out, and therefore authorises thedevice to perform the acquisition, handling andprocessing of the evidence. This is related to theliability requirement; a digital witness is a powerfultool for obtaining digital evidence and how andwhy it is being used has to be controlled. Bind-

ing Credentials help solve this issue and also addtraceability to the evidence during the delegationprocedure. Furthermore, the user’s privacy will beensured according the policies accepted or not bythe user. For example, certain policies can definethe granularity of user’s data based on the type ofobject and the context (e.g., a camera that revealsthe number of individuals in the building but notwho they are). Notice that the use of mobile devicesin this approach is considered as a responsibility;the authorities should be notified of the loss or theftof a digital witness as if it were the loss or theft ofan official id.

Moreover, a digital witness is defined to becollaborative, to allow the independence of a ma-jor network as in the case of DCoC approaches.Therefore, a digital witness will be able to senddigital evidence to other digital witnesses or anyother entity with the authority to safeguard the elec-

4

tronic evidence, opening the door for more variedscenarios. During this delegation of evidence, theexistence of procedures such as the maintenance ofa historical log will also help to keep the traceabilityof the digital evidence.

Finally, we consider two types of digital wit-nesses based on user profiles: citizen (or digitalwitness) and custodian (or digital custodian). Whilethe first refers to a digital witness with the basicproperties described in Table I, the second is adigital witness with privileges. This digital witnessis able to perform more actions in the environment,some of them depending on search warrants prop-erly handled by the device. So, this is a propertythat the device inherits from its user. Furthermore,authorisation is not only given by the role, this willdepend on the user’s identity.

IV. TECHNICAL COMPLIANCE WITHREQUIREMENTS

The following section analyses how the newtechnological trends in personal devices can helpimplement the concept of digital witness, providingthe basis on which to define the new componentsrequired (c.f., Figure 1).

A. Integrating a Core of Trust: Trusted PlatformModules and Secure Elements

In order to be used for the storage and transmis-sion of digital evidence, these devices must employtechnologies suitable for the management of digitalevidence according to existing standards. Moreover,these devices should provide a protected space thatcannot be tampered with, where the representativeinformation of the electronic evidence managementprocess can be stored.

Table II shows a representative set of hardwaresecurity devices that are integrated inside IoT de-vices, ranging from vehicles (e.g., TPM v2.0) towearables (e.g., boosted NFC SE). For example,the Trusted Platform Module (TPM), is an anti-tampering chip that is embedded in a platform toprovide a Core of Trust (CoT). A CoT is feasiblebecause these chips integrate a master key that neverleaves the chip, together with its own cryptographic

processor that allows standarised operations. In ad-dition, the TPM also provides support to validate theintegrity of software components, allowing third-party applications using internal registers (PCRs)to store hash values.

Another, different approach is the use of a SecureElement (SE). An SE is integrated inside mobiledevices, usually for mobile payments. However, SEscan also be used by other technologies to store keysor hashes of biometric data (e.g., fingerprints) [6].Therefore, SEs can also be useful for providingadditional security in other areas, such as the man-agement of digital evidence.

Both the TPM and the SE also provide anadditional advantage: most of these chips havemechanisms for deploying a secure communicationchannel (e.g., using diffie hellman (DH) or EllipticCurve DH (ECDH)). In fact, there are also solutionsfor defining transactions involving a secure element,wherein the device identity is stored [7].

Note, however, that a serious limitation to thesesecurity devices is their limited storage capac-ity (Table III). For example, in some commer-cial SE chips, the available memory ranges from800KBytes to 1.5MBytes (SLE 97 SOLID FLASHfamily - UICC/SIM and embedded), or from240KBytes to 500KBytes (Boosted NFC SE - SIM,SD and microSD). This is a limitation, becausedigital evidence is classed as anything that is ofinterest given a context. So, the amount of electronicevidence can be very high. Therefore, at the veryleast a guarantee of integrity of the evidence (i.e.hash) must be preserved. The integrity of the digitalevidence is verified if the hash matches the hashstored in the protected secure storage medium. Thisinformation is also stored in the chips and must bedelegated to an entity with the necessary authorityto process the digital evidence as soon as possible.

B. Schemes for Binding the User Identity

As mentioned, it is essential that a user candelegate his or her identity to the devices that act asdigital witnesses, establishing an unbreakable linkbetween a piece of evidence and the individual whogenerated it. One particular cryptographic primitive,proxy signatures, can fulfil the role of establishing

5

Table IISECURITY FEATURES OF CHIPS EMBEDDED IN PERSONAL DEVICES.

Device Asymmetric (max bits) Symmetric (max bits) Hash (max) OthersTPM v2.0 (car). SE ifJavaCard

RSA 2048, ECC 256 AES 128 SHA-256, HMAC Universally UniqueID, CoT

SLE 97 SOLID FLASHFamily. UICC/SIM

RSA 4096, ECC 521 3DES, AES 256 - Fingerprint match-on-card

SLE 97 SOLID FLASHFamily. eSE

RSA 2048, ECC 521 3DES, AES 256 - Fingerprint match-on-card

OPTIGA Trust authentica-tion chip

RSA 2048, ECC 52l 3DES, AES 256 SHA-512 GlobalPlatform IDconfiguration, CoT,DH/ECDH, Logs

Boosted NFC SE. SIM,SD and microSD with in-tegrated antenna

RSA 4096, ECC 521 3DES, AES - -

Table IIIOTHER FEATURES OF CHIPS EMBEDDED IN PERSONAL DEVICES.

Device Memory (up to) Interface SDKTPM v2.0 (car). SE ifJavaCard

1.6KB APDU for communicationwith SE

tpm-tools

SLE 97 SOLID FLASHFamily. UICC/SIM andeSE.

1.5MB ISO/IEC 7816, SWP Application DevelopmentToolkit, Java Card

OPTIGA Trust authentica-tion chip

150KB ISO/IEC 7816 UART(400kbps)

Crypto applets, hostsource code, Java Card

Boosted NFC SE. SIM,SD and microSD with in-tegrated antenna

500KB ISO/IEC 7816, ISO/IEC14443

-

a link between a user and the information generatedby his/her devices. [8]. In fact, all strategies that canbe used to implement this particular cryptographicprimitive allow us to create this link.

In the most basic approach, known as (full del-egation, FD), the user delegates the use of his/herown private key to his/her digital witness device.This private key can then be used to sign theevidence. Another strategy (delegation by warrant,DbW) involves the use of a token (warrant), signedby the private key of the user. This token, whichincludes several fields such as the identity of thedevice and the validity period of the token itself,is stored within the device and appended to allpieces of evidence. All evidence is then signedusing the private key of the device. Finally, in thelast approach (PK), the user’s private key is used togenerate a pair of private and public keys, which,in turn are used by the device to sign the evidence.

As these keys are associated with the user’s identity(e.g. using identity-based cryptography [9]), it ispossible to check the identity of the user whogenerated the evidence. In this article, we refer tothe outcome of these approaches, or the outcome ofany mechanism that provides a link between a userand his device, as Binding Credentials (BCs).

However there are some requirements that mustbe fulfilled in order to use the output of proxy signa-tures as binding credentials in the context of digitalwitnesses. First, it is mandatory for users to own apair of public and private keys, and such keys mustbe linked to the identity of the person themselves.Second, the private key must be properly securedin a secure element that allows digital signatureoperations. Both requirements can be fulfilled byusing technologies such as SIM/UICC cards andelectronic identity cards.

In the first case (SIM/UICC cards), according tothe 3GPP standard TS 33.221 [10], it is possible

6

– with the assistance of the telecommunicationsoperator – to include certificates and private keyswithin the UICC. Moreover, as several countriesrequire the mandatory registration of SIM card usersby means of a national identity card or passport, allthe information stored within a SIM/UICC card (in-cluding identifiers such as IMSI, MSISDN [11]) canbe used to identify a particular individual. In thiscase, the evidence management system is developedin collaboration with the operator, becoming partof the services that are included within the UICC.This not only allows the SIM/UICC identifiers tobe included within the evidence, but it also meansthat the evidence inside the UICC itself is signed.

Electronic identity cards (eIDs, such as the Span-ish DNI-e), have a secure element preloaded withpersonal information (e.g. national ID, fingerprints),including a pair of private and public keys. By usingthe interfaces of the eID card, a natural person canbe authenticated for a device or service using thatcard [12]. Such interfaces can also be used to meetthe aforementioned requirements: the eID can act asa secure element, generating the necessary bindingcredentials using the private keys contained therein.Moreover, as the key pairs contained within an eIDare issued by the government, there is no needto involve an industrial trusted third party in themanagement of the evidence. Furthermore, thanksto research projects like STORK2 [13], differentnational eIDs can interoperate with each other.

C. Delegation of Evidence between Entities

Figure 2 shows the basic steps to delegate one ormore pieces of evidence between digital witnesses.We call this delegation procedure Binding Delega-tion because the first step depends on the agreementwith the policies and creation of binding credentials.

This delegation procedure can be performed inan ad-hoc fashion, where the evidence is obtainedand transmitted by different types of digital wit-nesses, as soon as possible, considering the role andcharacteristics of the digital witness. For example, apersonal device belonging to a civilian always hasto send the evidence to a digital custodian at theend of the DCoC-IoT. However, a digital custodianwill never send evidence to a digital witness, it only

collaborates with other digital custodians. The finaldestination of the evidence is an Official CollectionPoint of evidence (e.g., a building acting as a digitalwitness with more resources). In this last point ofstorage the evidence is processed.

During this entire transmission process, theDCoC has to be maintained. In order to do so, wefollow a specific procedure that is detailed in thefollowing paragraphs.

When the evidence is obtained, a header is gen-erated with relevant information according to aformat for electronic evidence (e.g. [14]) adaptedto the requirements of the digital witness. Duringthis process, an identifier of the evidence is gener-ated using the binding credentials of the electronicdevice that generates the evidence and the times-tamp. This identifier is present throughout the lifecycle of the digital evidence. The digital evidenceand the probative value are stored according tothe criteria of secure, anti-tampering storage. Thesignature process depends on the mechanism chosento perform the binding of the identity of the user tothe device.

At some point, an entity A will need to dele-gate the evidence (e.g. the evidence is consideredcritical, a strong digital custodian is located in thevicinity, the device reaches the permitted thresholdfor storage). The choice of the next digital witness Bis subject to compliance with several requirements:(i) B can attest that it is a digital witness and itsrole/level, (ii) B is a digital witness at the samelevel as A or higher, (iii) B meets the criteria forsafeguarding the electronic evidence, (iv) B is thebest candidate (e.g. B minimises the number ofjumps to the collection point), and (v) B is a digitalcustodian and requests the evidence from A, and Acan verify the identity of B.

Once witness B has been chosen, the informationconcerning the electronic evidence is sent over asecure channel. B then authenticates the electronicevidence and proceeds to safeguard it. In this step,B generates its own evidence to prove the receptionof this evidence in its historical of evidence. Thehistorical of evidence (or historical), is a summaryof the evidence that has been handled, and ensuresthe traceability of the evidence. Then, B sends A

7

Binding Credentials

Real wold Digital world

Identity Liability

B2 Generation & Storage

Secure Channel 4. Reception and Custody

5. ok

6 Release

C

Secure Channel

5.Delegation (...)

3.Delegation

DW#

1.[A] Binding credentials & Policies2.[A] Generation, Identification and Secure Storage3.[A->B] Delegation of evidence4.[B] Reception and Custody5.[B->C] Delegation of evidence, [B->A] warranty of reception6.[A] Release the storage space

DCoC-IoT

ADW# DW#

DW#

1.User agreement

Roles of Digital Witness

DW#

DW# DW#

Official collection point

Figure 2. Binding Delegation.

the proof, indicating that the reception and storageof the evidence has been possible – a receptionguarantee. If B does not send the proof, A recordsin its historical that the evidence was sent to B,but that the evidence has not been deleted in A.The reception guarantee is stored in the historical.Finally, A can release the storage space that wasoccupied by the evidence or the sets of evidence.

V. FUNCTIONAL COMPONENTS ANDRELATIONSHIPS

Building on the analysis developed in the previ-ous section, this section describes the main compo-nents that embodies the basic concept of a digitalwitness. These components enable the basic secu-rity architecture to acquire electronic evidence indynamic, heterogeneous and distributed IoT scenar-ios. To do so, the requirements of the lifecycle ofdigital evidence are considered [5], [7], [14].

The functional requirements for digital witnessesmust provide, at the very least, the componentsshown in Figure 3. As can be seen, ideally thesecomponents are provided or implemented using thebasic capabilities of a secure element. The maincomponents of this architecture are: the Operations

Manager User-Device (OMUD), contract manager,cryptographic mechanisms, secure storage with ac-cess control, and Digital Evidence Manager (DEM).

The OMUD allows the identity of a user to belinked with his/her personal device. As a result,it generates a set of binding credentials that areused throughout the Digital Evidence Managementprocess. In addition, it provides additional optionssuch as request biometric inputs.

The contract manager is an optional componentthat advises as to the cryptographic mechanismsthat are admissible in a court of law, and thedifferent configuration alternatives for managingthe evidence, such as the granularity of the datacollected. When a digital witness requests advicefrom a contract manager, the system stores a proofabout the advice given by the contract manager. Ifthis component is not used the digital witness mustbe manually configured to use the cryptographicmechanisms that are allowed. These cryptographicmechanisms are implemented within a secure ele-ment, which is then used during the managementprocess, and probably (but not necessarily) by theOMUD. Moreover, the keys and other critical re-sources (e.g., hashes, SAs, BCs) should be stored

8

Digital Witness

Components within one or more Secure Elements

UserCryptographic Mechanisms

Anti-tampering secure storage with access control

RoleDbW

H(Evidence)

KeysFD

<<use>>

FD/ D

bW/ P

K

User's Identity

SA

Historical

H(Evidence)

Encrypted Evidence

<<Inherits the characteristics of Digital Witness>>

Digital Custodian

Updated DB with cryptographic mechanisms and allowed

operations (legal and regulatory issues)

Contract Manager

SA Negotiation

SAContract Manager

Depends on the binding credentials scheme.Modifications related to evidence.

Modifications related to the transmission.Modifications related to the contract.Optional element (recommended).

e.g., get biometrics

Operations Manager User-Device

Get Evidence

Store/Delete Evidence

Send Evidence

H(Evidence) Historical

Digital Evidence Manager

Evidence

Evidence

<<use>>

PK

Figure 3. Functional requirements for digital witness based on Binding Credentials).

using the secure element.Finally, the DEM coordinates the processes of the

lifecycle of the digital evidence within the digitalwitness: generation, identification, secure storage,delegation, etc. [14].

A. Interaction between components

We define three basic cases of communicationbetween the components shown in Figure 3:C1 Establishment of action policies for the use of

digital witnesses.C2 Creation of binding credentials (BCs).C3 DEM using BCs, delegation of evidence.

In C1, the objective is to define the cryptographicmechanisms and configurations that are acceptable,and those additional policies that are necessary todefine the behaviour of the digital witness. Weclassify the policies in two groups. The first group(GP1, Group Policy 1) defines policies relating theuser to the device. For example, the agreementof the terms of service (without which the digitalwitness cannot be started), the preferences of theuser, or the way in which the resources in the device

are managed. The second group (GP2, Group Policy2) contains the policies used by the DEM (e.g.generation of evidence, transmission of evidence,storage and deletion of evidence).

The GP1 policies, which are more general, arenegotiated between the user and the OMUD, whilethe policies in GP2 are set up through the DEM.Once accepted, all policies become part of theSecurity Associations (SA) that define the behaviourof the digital witness, and are safeguarded as elec-tronic evidence, thus constituting a proof of thenegotiation between the physical user and the digitalwitness. Subsequently, the policies are checked foreach component, and the integrity of the policiesfiles is periodically checked using the correspond-ing hash. Note that all policies include the listof security and cryptographic mechanisms that areaccepted for each case, and consider the list ofaforementioned requirements.

In C2, the OMUD is responsible for creatingthe credentials (passwords or tokens) that link theuser to the device. The BCs are used transparentlyby the DEM to handle the evidence (e.g., storage,transmission) and the historical data. For this rea-

9

son, these BCs have to be defined following therequirements discussed above, and generated usingcryptographic accepted mechanisms available in thedigital witness. Moreover, the BCs are stored in ananti-tampering device within the digital witness.

In C3, we detail the internal behaviour of thecomponents when implementing the delegation pro-cedure described earlier. The evidence is obtainedusing forensic mechanisms that are accepted ina court of law. The hash of the electronic evi-dence is created using the appropriate cryptographicmechanisms and is stored inside the protected areaof the secure element when this functionality isavailable in the digital witness. Otherwise, the DEMis responsible for writing the resulting hash value inthe storage space. In any case, when new evidenceis acquired or used, the historical of evidence mustbe updated.

Regarding the delegation of evidence, first thenext witness in the chain (candidate for the delega-tion) is chosen according to the criteria previouslydescribed. Note that the next witness can be chosenin a local context (e.g. hop-by-hop communication)or in a global context (e.g. Internet) if other com-munication methods and peers are available. Theevidence (in this case the hash of the evidence) andthe historical are then sent to the next witness in thechain using secure communication channels, whichare built using accepted cryptographic mechanisms,and stating the BCs that demonstrate the link be-tween the user and the device. Finally, regardless ofthe result of the delegation (whether or not it waspossible to delegate the evidence), the historical isupdated and the supporting data for the operations(digital proof of the operations) are stored in thedigital witness.

B. Optional interaction between components

Case C1 can be improved by using the optionalcomponent Contract Manager to set up the policiesfor managing electronic evidence. In this case, theContract Manager is responsible for assessing thebest configuration that satisfies a set of criteria forthe digital witness, plus other factors such as thegranularity of the information.

In this scenario, the interaction mostly occursbetween the Contract Manager and the DEM. TheContract Manager advises the DEM of the accept-able configurations for managing electronic evi-dence, in accordance with the security level requiredby the legal framework and the preferences of theuser. Initially, the digital witness can be configuredusing the default policies defined by the DEM, and,under the request from an authenticated custodian, itmay update these policies according to the securityassociation negotiated with the digital custodian. Indoing so, the GP2 is updated. This update can berequired at any moment, and, in fact, it can affectthe terms of service or any other factor detailedin the rest of the policies. If that is the case, themodifications requested are communicated to theuser for acceptance.

Another security feature that could be very usefulis the use of biometric systems. Such systems can beused in case C2, just before generating the BindingCredentials, and in case C3 during the process ofacquisition and/or transferring of evidence.

The elements of the architecture that most ac-tively participate in this optional process are theUser and the OMUD. Before executing any oper-ation that requires the user’s presence (e.g. trans-mitting a batch of evidence), the User must advisethe OMUD of its availability (e.g. by respondingto an alert). At this point, the OMUD will promptthe User to authenticate him or helself by usingthe biometric systems listed in the acceptable con-figuration. After the authentication process, if thevalidation has been successful, the OMUD willcontinue with the planned operations. Note thatevidence will be produced whenever an operationrequires the user’s authentication via the biometricsystems. The information stored inside this pieceof evidence can range from a simple registration ofthe event to specific biometric information (e.g. theimage of a fingerprint), if allowed.

Regarding the implementation of the biometricsystems, there is one important topic that requiresfurther analysis in future work: the registration andverification of the user’s biometric data. This isimportant because there is no inherent guaranteethat a given user account which is registered in

10

the device belongs to the same user who createdthe binding credentials. Note, however, that it ispossible to unambiguously prove the presence ofa specific user involved in a particular operation ifthe biometric information provided by the user isvalidated against a valid source, such as a legallybinding token or similar device that stores biometricinformation (e.g. a national eID that stores the user’sfingerprints). Moreover, if this validation processis performed during the user account registrationphase, then the generated biometric proof that linksthe biometric data with the user account will be, inturn, linked to the user’s identity.

VI. CONCLUSIONS AND FUTURE WORK

In this article, we have introduced and analysedthe concept of digital witnesses. We have explainedthe technological solutions and approaches (e.g.secure elements, binding credentials, DCoC-IoT)that could be used to turn this particular conceptinto a reality. Moreover, we have defined the basiccomponents for the deployment of digital witnesses.

Whenever a novel concept is defined, there arealways some open issues that must be considered inorder to further refine and expand the applicabilityof that particular concept. In this article we haveshown that it is possible to design a digital witnessfor mobile user devices and personal networks;however this particular design, which is based onthe existence of a binding credential which links theidentity of the object to the identity of a person,might not be applicable in all IoT contexts. Thisis because certain devices might not have uniqueidentities, or even just one owner. Therefore, futurework will be to implement the solution proposed inthis article, but also to analyse use cases within IoTenvironments that have not been analysed here.

ACKNOWLEDGMENT

This work has been funded by the Spanish Min-istry of Economy and Competitiveness through theproject IoTest (TIN2015-72634-EXP), https://www.nics.uma.es/projects/iotest.

REFERENCES

[1] E. Oriwoh, D. Jazani, G. Epiphaniou, and P. Sant, “Internetof things forensics: Challenges and approaches,” in Collab-orative Computing: Networking, Applications and Work-sharing (Collaboratecom), 2013 9th International Confer-ence Conference on. IEEE, 2013, pp. 608–615.

[2] E. Casey, Digital evidence and computer crime: forensicscience, computers and the internet. Academic press,2011.

[3] Y. Prayudi and S. Azhari, “Digital chain of custody: Stateof the art,” International Journal of Computer Applications,vol. 114, no. 5, March 2015.

[4] T. Marqués Arpa and J. Serra Ruiz, “Cadena de custodia enel análisis forense. implementación de un marco de gestiónde la evidencia digital,” in XIII Reunión Española sobreCriptología y Seguridad de la Información (RECSI 2014).Universidad de Alicante, 2014.

[5] S. Omeleze and H. Venter, “Towards a model for acquiringdigital evidence using mobile devices,” in Proceedings ofthe Tenth International Network Conference (INC 2014).Lulu. com, 2014, p. 173.

[6] R. Sanchez-Reillo, D. Sierra-Ramos, R. Estrada-Casarrubios, and J. A. Amores-Duran, “Strengths,weaknesses and recommendations in implementingbiometrics in mobile devices,” in Security Technology(ICCST), 2014 International Carnahan Conference on.IEEE, 2014, pp. 1–6.

[7] D. T. Haggerty, A. A. Khan, C. B. Sharp, J. Von Hauck,J. Linde, K. P. McLaughlin, Z. Mehdi, and Y. H. Vaid,“Apparatus and methods for secure element transactionsand management of assets,” Feb. 6 2014, uS Patent App.14/174,791.

[8] A. Boldyreva, A. Palacio, and B. Warinschi, “Secure proxysignature schemes for delegation of signing rights,” Journalof Cryptology, vol. 25, no. 1, pp. 57–115, 2012. [Online].Available: http://dx.doi.org/10.1007/s00145-010-9082-x

[9] H. Debiao, C. Jianhua, and H. Jin, “An id-based proxysignature schemes without bilinear pairings,” Annalsof Telecommunications, vol. 66, no. 11–12, pp. 657–662, 2011. [Online]. Available: http://dx.doi.org/10.1007/s12243-011-0244-0

[10] 3GPP TS 33.221: Support for Subscriber Certificates,http://www.3gpp.org/DynaReport/33221.htm, Accessed onApril 2015.

[11] R. Ayers, S. Brothers, and W. Jansen, “Sp 800-101 rev. 1,guidelines on mobile device forensics,” Gaithersburg, MD,United States, Tech. Rep., 2014.

[12] V. Gayoso Martinez, L. Hernández Encinas,A. Martín Muñoz, and J. I. Sanchez García, “Identificationby means of a national id card for wireless services,” in2013 16th International Symposium on Wireless PersonalMultimedia Communications (WPMC), June 2013, pp.1–5.

[13] STORK2: Secure Identity Across Borders Linked, https://www.eid-stork2.eu/, Accessed on April 2015.

[14] “Une 71505: Tecnologías de la información (ti). sistemade gestión de evidencias electrónicas (sgee).” Tecnologíade la Información, 2013.

11

Ana Nieto is postdoc researcher atthe University of Malaga (Spain). Shereceived her M.Sc. in Computer Engi-neering in 2008 and her Ph.D. in Com-puter Science in 2015. She has relevantpublications in the topic of Securityand Quality of Service (QoS) trade-offs. Her current research activities aremainly focused on IoT-forensics; she isinvolved in new research topics relatedto digital witnessing.

Rodrigo Roman is a security re-searcher working at the University ofMalaga (Spain), where he obtained hisPh.D. and M.Sc. degrees in ComputerEngineering and Computer Science, re-spectively, in 2008 and 2003. Previ-ously, he worked for the Institute ofInfocomm Research (I2R) in Singaporein the areas of sensor network securityand cloud security. Pursuing to makesecurity simple and usable, his research

is focused on the development of protection mechanisms forthe Internet of Things and related paradigms, such as cloudcomputing and fog computing.

Javier Lopez is Full Professor, andhis research activities focus on networkand protocols security, where he hasled more than fifty research projectsand has co-authored above two hun-dred papers. He is Editor-in-chief ofthe “International Journal of Informa-tion Security”, and member of the ed-itorial boards of “IEEE Wireless Com-munications” and “IEEE Internet ofThings Journal”. He also is the Spanish

representative at “IFIP Technical Committee 11 âAS Securityand Protection in Information Processing Systems”.