Colorado State University Internet of Things Forensics Survey

Write a survey paper from only 3 selected papers using IEEE format. (the papers and template will be attached).

the length of survey paper between (5-6) pages.

The papers will be attached talk about Internet of Things Forensics

2017 IEEE Trustcom/BigDataSE/ICESS
A Methodology for Privacy-Aware IoT-Forensics
Ana Nieto, Ruben Rios and Javier Lopez
Network, Information and Computer Security (NICS) Lab
Computer Science Department
University of Malaga, Spain
Email: {nieto,ruben,jlm}@lcc.uma.es
Abstract—The Internet of Things (IoT) brings new challenges
to digital forensics. Given the number and heterogeneity of
devices in such scenarios, it bring extremely difﬁcult to carry
out investigations without the cooperation of individuals. Even
if they are not directly involved in the offense, their devices can
yield digital evidence that might provide useful clariﬁcation in
an investigation. However, when providing such evidence they
may leak sensitive personal information. This paper proposes
PRoFIT; a new model for IoT-forensics that takes privacy into
consideration by incorporating the requirements of ISO/IEC
29100:2011 throughout the investigation life cycle. PRoFIT is
intended to lay the groundwork for the voluntary cooperation of
individuals in cyber crime investigations.
The problems that have been considered so far in IoTforensics are just the tip of the iceberg. The IoT is not only
about billions of heterogenous devices connected to the Internet. The user also plays a fundamental role in this paradigm
and obviating it is a terrible mistake. Collecting evidence from
IoT devices may have implications for individual privacy and
thus tackling this problem is critical in IoT-forensics. This
is precisely the goal of this article. We deﬁne the PRoFIT
(Privacy-aware IoT-Forensic Model) methodology to integrate
privacy properties in accordance with ISO/IEC 29100:2011
throughout the phases of a forensics model adapted to the
IoT. Moreover, unlike previous approaches, the PRoFIT model
highlights the importance of collaborating with surrounding
(and potential sporadic) devices to gather electronic evidence
that helps to fully clarify the context of the crime scene.
This paper is organized as follows. Section II describes the
forensic models and privacy principles on which the PRoFIT
methodology is built. Section III explains the phases of the
PRoFIT model and Section IV the methodology. Then, a use
case scenario is presented in Section V to illustrate the model
more clearly. Finally, Section VI concludes the paper.
I. I NTRODUCTION
Traditional computer forensics is based on a series of wellestablished processes whose primary goal is to preserve the
integrity of digital evidence. To that end, there are several
similar models that describe precise actions to be followed
but they are are not prepared for dynamic and heterogeneous
environments [1]. These traditional models are deﬁned to
manage physical evidence from its seizure until it is returned,
and the collection of digital evidence is part of this process.
Throughout the process, chains of custody are implemented
by means of documents manually signed by the people in
charge of managing the evidence. This cumbersome process is
to ensure the integrity of the evidence but it is rather inﬂexible
and conceived for static scenarios.
These rigid methodologies are unsuitable for current scenarios with a growing number of devices of a heterogeneous
nature, as is the case in IoT environments [3]. Nowadays,
forensic analysts face the problem of a lack of tools and
methodologies for the treatment of IoT devices [2]. Not only
devices but also intermediate platforms and infrastructures
pose great challenges. For example, the exponential increase
of data that needs to be processed [4], and the need to deploy
collaborative approaches where IoT devices are able to install
forensic software to help to include them as collaborators
(a.k.a. witnesses) in a crime scene [13]. In this respect, the
approach in [13] provides a technical solution to preserve
the digital evidence and share it with remote entities, but
without considering privacy requirements over the lifecycle
of the investigative process. Not only in this approach, but in
general, steps have to be taken to integrate privacy issues in
IoT-forensics [3] to deal with new scenes of cybercrime due
to the IoT.
2324-9013/17 $31.00 © 2017 IEEE
DOI 10.1109/Trustcom/BigDataSE/ICESS.2017.293
II. BACKGROUND
This section provides some background information about
existing digital forensic models and their phases. It also
introduces some privacy principles that need to be considered
when dealing with personal information.
A. Forensic Models
Forensic models are intended to preserve evidence throughout its life cycle, from acquisition until it is processed and
possibly returned. A review of several of these models is
presented in [1], where the Enhanced Systematic Digital
Forensic Investigation Model (ESDFIM) is proposed. This
model contemplates the following phases:
•
•
•
626
Preparation: refers to all actions performed prior to the
investigation, including analysis of the legal framework,
application for search warrants, setup of information
processing tools, etc.
Acquisition & Preservation: includes the identiﬁcation,
collection of evidence, labelling, packaging, etc.
Examination & Analysis: at this stage, the investigators
examine and analyze the contents of the devices that were
collected and appropriately preserved.
Information Sharing: refers to the ability of different authorized organizations to share and exchange data relating
to an investigation.
• Presentation: the authorities are presented with the results of the investigation. This phase is critical for the
admissibility of the evidence.
• Review: this stage is intended to evaluate and improve
the investigation process. It also considers the process
for returning the collected evidence (e.g., a PC).
ISO/IEC 27050:2016 [5] deﬁnes different phases for the
management of electronically stored information: identiﬁcation, preservation, collection, processing, review, analysis and
production. These can be easily mapped to the ones deﬁned
by the ESDFIM model with the exception of the information
sharing phase, which is not considered. This phase is of
particular interest in IoT scenarios and thus we adopt the
ESDFIM model.
There are very few models speciﬁc to IoT-forensics. To the
best of our knowledge, the only models that deﬁne phases in
their methodological approach for IoT-forensics are those proposed in [6] and [7] (TABLE I). Other IoT-forensic solutions
(e.g., [8], [9]) are not considered here because they do not
strictly deﬁne phases.
•
them, one of the ﬁrst to consider privacy was the US Privacy
Act of 1974, where the Fair Information Practices (FIPs) were
established. These practices or principles were later embraced
and adapted in several guidelines [10], directives [11] and standards, such as the ISO/IEC 29100:2011 [12], which considers
the following privacy principles:
• Consent and choice (P1): the user must give explicit
consent to the collection and processing of his/her data.
• Purpose legitimacy and speciﬁcation (P1): the system
must clearly present the purpose for data collection to
the user.
• Collection limitation (P3): the system must collect the
data that is strictly necessary to fulﬁl the original purpose.
• Data minimization (P4): the data sent to and processed
by the system must be reduced to its minimum.
• Use, retention and disclosure limitation (P5): the system
must not use the collected data for a purpose other than
the one originally speciﬁed. Also, it must be disposed of
once the purpose has been accomplished.
• Accuracy and quality (P6): the data provided by the user
must be precise, truthful and current.
• Openess, transparency and notice (P7): the user must be
aware of the policies, procedures and practices of the
system with regard to personal data.
• Individual participation and access (P8): the user must
be able to access his/her own data as well as ask for
corrections.
• Accountability (P9): the system is responsible for following the privacy policies and, in the case of noncompliance, the user can ask for compensation.
• Information security controls (P10): the system must
protect personal data from unauthorized access, loss and
manipulation.
• Compliance (P11): the system must implement auditing
mechanisms to verify that it is compliant with privacy
principles.
In general, these privacy principles try to return control over
their own data to the users. More precisely, they establish that
the user must be aware of the data collection and consent to
it. The purpose for data collection must be clearly speciﬁed
and under no circumstances may the data collected be used for
other purposes. Moreover, the data collector must only request
the minimum amount of data necessary to provide the service
and once provided it should be deleted. In the meantime, the
data must be safe from intrusion or harm.
TABLE I: IoT-forensics Models with phases
Model
[6]
[7]
Phases
Planning (authorization and warrant obtained), IoT data acquisition (base device identiﬁcation, zone, triage examination,
acquisition of data from data accumulation platforms, structured data / unstructured data), chain of custody, lab analysis,
result, proof & defense, achieve & storage
Proactive process (IoT scenario deﬁnition, evidence source
identiﬁcation, planning incident detection, potential evidence
collection, digital preservation, storage of potential evidence),
IoT-forensics (cloud forensics, network forensics, device level
forensics), Reactive Process (initialization, acquisitive, investigative), Concurrent Process (obtain authorization, documentation, chain of custody, physical investigation)
Even though [7] considers the possibility of setting up the
IoT environment, these models do not yet consider ethics
and privacy rights as part of their methodology. In addition,
these models use search warrants from the beginning of the
process thereby delaying the investigation in high-density
scenarios. Usually search warrants are needed to collect digital
evidence from a suspect or potentially involved devices in an
investigation. However, in some scenarios the user might be
disposed to cooperate (e.g., as a witness).
In summary, neither traditional nor IoT models currently
consider the potential beneﬁts of voluntary cooperation. In this
paper we wish to exploit the social side of the IoT to boost
the successful resolution of forensic investigations but to that
end we need to carefully consider user privacy throughout the
investigative process.
III. P RIVACY- AWARE I OT-F ORENSIC M ODEL (PRO FIT)
This section describes the PRoFIT model. The proposed
model deﬁnes six phases detailed in Section III-A, which
take into consideration the privacy requirements established
by ISO/IEC 29100:2011, as described in Section III-B, and
the use cases in Section III-C.
B. Privacy Principles
Several laws and directives are intended to set limits on the
collection, processing and dissemination of personal information when interacting with other entities and services. Among
A. PRoFIT Phases
The cooperation of devices nearby calls for the re-deﬁnition
of the phases of the reference models used so far. In particular,
627
data offered to requestors depending on the data provided, such
as a signed warrant. We have called this software the PRoFIT
software. Note that there is a dependency on the ability of IoT
devices and platforms to install any piece of software. This
is subject to the owner of the device. Therefore, we assume
that not all the devices will have PRoFIT software installed
and so the investigator will be responsible for complying with
the privacy requirements of those willing to collaborate in the
investigation.
we maintain the deﬁnition of the last three phases of the
ESDFIM model (Section II-A), but we re-deﬁne the ﬁrst three
phases and the methodology to adapt the model to an IoTforensic environment. Thus, PRoFIT deﬁnes the following
phases: (1) Preparation (planning and environment set up), (2)
Context-based collection, (3) Data analysis and correlation,
(4) Information Sharing, (5) Presentation and (6) Review. A
summary of the PRoFIT model workﬂow is shown in Fig. 1.
start
Environmental
Preparation
Investigator
IoT devices /
platforms
IoT Device
Planning (legal
framework,
tools, etc.)
IoT Device
ﬁne grained
privacy
new devices, new
authorisations or new
warrants are required
Data
Centralised
Infrastructure
Middleware PRoFIT
yes
Middleware PRoFIT
data
Contextbased
Collection
no
yes
IoT Device
(preconﬁgured)
Investigator
Analysis and
Correlation
request data
request data
data
Investigator
new
information
Information
Sharing
Fig. 2: Preconﬁguration of IoT Devices and Platforms
no
Review
Presentation
It is important to highlight that the PRoFIT model tries
to solve the case with the information voluntarily provided
by the users. In this way, PRoFIT promotes the collaboration
of devices while promoting user privacy. By doing so, we
expect to reduce the cumbersome and time-consuming process
of requesting authorization for collecting digital evidence.
Nonetheless, some investigations may require that court orders
are requested in the ﬁrst phase and not only after a person is
already collaborating. PRoFIT allows both approaches and is
more dynamic that its predecessors so as to better adapt to the
IoT context.
2) Context-based Collection: This phase concerns the collection of data from the devices involved in the case and the
deployment of chains of custody. Depending on the investigation it may be necessary to request court orders, as in
the traditional approach, but the PRoFIT model is speciﬁcally
intended to promote the user’s cooperation while preventing
the requisitioning of personal devices.
The process shown in Fig. 5a is performed by the investigator. This process ends when there is no new information or
permissions to request (Fig. 1). The devices may or may not
be pre-conﬁgured with the PRoFIT software. We distinguish
three types of device proﬁles for the investigation:
• Victim / Offended: belongs to the person who suffered
an offense. The owner of the device will therefore want
an investigation into his/her device’s data to be opened
(c.f. use case in Section V).
• Suspect: is a device that may contain digital inculpatory
or exculpatory evidence.
• Witness: provides relevant digital evidence for the investigation but it is neither the victim nor the suspect.
3) Data Analysis and Correlation: This step is devoted
to the analysis and correlation of the data obtained in the
previous phase. This phase may also receive information from
Others
end
Fig. 1: PRoFIT workﬂow
More precisely, phase (1) in our model is divided into
two ﬂows. One is related to the investigator and the other
is associated with IoT devices and/or platforms. Phases (2)
to (6) are concerned with the forensic investigation therefore
the investigator is the main actor even though devices and
users are also involved because of the implementation of
privacy principles. Phases (4) to (6) are inherited from the
ESDFIM model but are modiﬁed so as to take into account the
privacy principles deﬁned in Section III-B. It is worth noting
that phases (2) to (4) can be accessed several times if new
information is provided to the investigator.
The following sections describe the main objectives of the
PRoFIT phases, while the workﬂow of each phase will be
detailed in Section IV.
1) Preparation: Unlike the ESDFIM model, the Preparation phase separates the tasks involving the investigator and
the task to prepare the devices and platforms of the IoT
environment. At this stage, the investigator elaborates the
traditional plan before any investigation (c.f. Section II-A), but
there is an optional – although recommended – task related
to the preparation of the environment. This optional phase
involves conﬁguring the devices and the IoT platform to
consider the requirements of the PRoFIT model. Thus, the
PRoFIT model is intended to simplify the subsequent phases
of the investigation.
This preparation may consist in installing a piece of software (e.g., a middleware, Fig. 2) to assist and advise the user
about the information contained in the device according to privacy policies and forensic restrictions, as well as to manage the
628
user will decide whether or not these data are offered to the
investigator without a warrant.
The data collection phase begins when the forensic investigator requests data from the device. The investigator will
request only those data that are relevant to the investigation
(P3). To ensure that the data have not been falsiﬁed (P6),
remote attestation mechanisms based on reliable platforms
will be used, allowing both the user and the investigator to
check the integrity of the system. Likewise, the requests of
the investigator can be limited if they are considered abusive
by the user’s policies (P4). In this respect, the software may
decide to offer the information requested but in less detail or
simply not offer it. Once offered, the user can verify that the
data collected by the investigator are correct. In the case that it
is necessary, the user can later offer a ﬁner level of granularity
and even provide new evidence (P8).
Once the data have been collected, during the analysis and
correlation phase, it is critical to ensure that the data are
adequately protected from tampering, manipulation or loss
(P10). Otherwise, the user may demand accountability and
even compensation (P9).
In some investigations, it may also be necessary to share
information with other agencies or entities to solve the case.
If this possibility has not been contemplated from the start,
the system will ask the user to give consent (P1, P2). Once
consent is given, the transfer or access to the information will
be carried out under strong security measures to protect the
conﬁdentiality and integrity of the data (P10). The same data
protection principles and security guarantees must be offered
at the destination as the origin.
In the presentation phase, it will be ensured that the quality
and accuracy of the data are sufﬁcient to clarify the case
(P6). It is important to avoid giving more detail than strictly
necessary as well as preventing the appearance of data on third
parties which are not relevant for the clariﬁcation of the case
(P4). The revision phase will help investigators to improve
the data collection, analysis, protection and dissemination
processes. In this phase, the investigators must proceed to the
secure erasure of data and to return any material conﬁscated
(P5). In addition, the user must be able to verify that the data
has actually been deleted (P7).
Throughout the process, internal audits and mechanisms
must be performed to ensure that the process complies with
the privacy principles (P11).
new sources via phase 3, as shown in Fig. 1. Unlike the
ESDFIM model, in our deﬁnition we consider that all the
inputs are digital evidence and probably raw data collected
from the cooperative devices. Due the heterogeneity of IoT
environments, working with heterogeneous formats may be a
requirement. All the data must be processed to ﬁlter useful,
relevant information to the case. As this is a phase that may
require feedback and therefore the knowledge is incremental,
some of the data to be correlated could be pre-processed from
a previous step. So the tools in this phase should be designed
to work both with well-structured digital evidence and with
raw data.
4) Information Sharing: This phase maintains the main
objective of the ESDFIM model (Section II-A). However, our
methodology modiﬁes the behavior to consider the privacy
requirements (Section II-B).
5) Presentation: The focus in this phase is to present the
results of the investigation to the authorities for its admissibility (c.f. ESDFIM model in Section II-A). However, the
methodology deﬁned in the PRoFIT model is different so as
to consider the privacy requirements (Section II-B).
6) Review: This last phase pursues the main objective of the
ESDFIM model (Section II-A). However, in order to consider
the privacy requirements (Section II-B) the methodology in
the PRoFIT model is very different from its predecessor.
B. Privacy Requirements
TABLE II aligns the privacy requirements described in
ISO/IEC 29100 with each of the phases of the PRoFIT model.
TABLE II: Privacy Requirements in PRoFIT phases
PRoFIT phase
ISO/IEC 29100
Preparation
P1
P2 P4
P7
Context-based collection
P1
P2 P3
P6
P8
Data analysis and correlation P9
P10
P11
Information sharing
P1
P2 P10
Presentation
P4
P6
Review
P5
P7
P1. Consent and choice, P2. Purpose legitimacy and speciﬁcation, P3.
Collection limitation, P4. Data minimization, P5. Use, retention and
disclosure limitation, P6. Accuracy and quality, P7. Openness, transparency
and notice, P8. Individual participation and access, P9. Accountability, P10.
Information security controls, P11. Compliance
During the environment preparation phase it is necessary
to comply with several data protection principles, especially
those focused on the user being well informed and aware of
the practices to be carried out. On the one hand, the purpose of
the PRoFIT software must be clearly and concisely speciﬁed
(P2, P7). After that, the user can choose whether or not to
accept the conditions of the software installation (P1). During
the normal execution of the device, PRoFIT will be able to
collect information according to the policies and the consent
offered by the user (P2). For example, the software can help
the user avoid having to store data about third parties thereby
promoting the principle of data minimization (P4). Finally,
the user must be able to check what data is being collected
by PRoFIT (P7). In the case of being ask to collaborate, the
C. Use cases for the Methodology
The efﬁcient application of digital forensic techniques will
be virtually impossible in IoT scenarios without the cooperation of devices nearby. For example, imagine that the crime
scene is in a hospital, where the delincuent uses local access
technologies to affect pacemakers and other body area network
devices. Therefore, the devices at the scene of the crime may
or may not be involved in the case but having access to their
information can help the investigation, especially when the
attack uses wireless technologies for propagation. Obviously,
in order to promote the cooperation of the different users at the
629
information that may expose user privacy (e.g., by using antiforensic techniques) but this would result in a useless device
from the point of view of an investigation. To the contrary, the
device can be conﬁgured to collect as much public information
as possible (e.g., data shared by others) but sharing all this
information may result in privacy violations.
crime scene we need to consider privacy and this is dependent
on the context surrounding the devices (Fig. 3).
Not isolated
UC1: various
personal devices
Isolated
UC3: personal
device
Main source
Personal device
Device
UC2: various
devices
Communication
Infrastructure (e.g.,
Internet, Cloud)
start
Potential sources /
witnesses
User consent
(P1), Purpose
legitimacy (P2)
Install
PRoFIT
PRoFIT middleware
Personal device
UC5: hybrid
Check user
consent and
purpose (P1, P2)
Device
UC4: device
request?
(op)
Execute
request (op)
Fig. 3: Use Case Contexts
end
Check data
minimisation
(P4)
Openness & Transparency (P7)
Compliance (P11)
The policies to be applied to an investigation vary depending
on whether the personal device or object is alone (UC3 and
UC4 ), or it is surrounded by more things: other personal
devices (UC1 ), objects (UC2 ), or both (UC5 ). The reason
for this is that personal devices store information that may
be subject to privacy restrictions. In addition, they may store
information due to their relationships with other entities. On
the other hand, non-personal devices may belong not only to
one user, but also to a group of users, a public or private
organization, etc. They can store non-personal information or
sensitive information that concerns a set of users, such as
patient data in a hospital.
It is worth noting that the dynamism of the IoT may also
involve changes in the context of the investigation. At the
beginning of the investigation the investigator may think that
a personal device was isolated (UC3 ) and consequently use a
set of policies considering this use case. Later, the investigator
may realize that there were more devices in the area (UC1 ,
UC2 , UC5 ). In this case, the investigator may request the
collaboration of the devices nearby as potential witnesses in
the investigation.
Fig. 4: PRoFIT software lifecycle
Fig. 4 shows the process of installing a PRoFIT-compliant
software and its activities within an IoT device or platform.
According to the privacy requirements it is necessary to ask
for the user’s consent to proceed with the installation of the
software (P1, P2). Once installed, the software controls the
operations requested by the system (e.g., store evidence) or
by third parties (e.g., request evidence) ensuring they are
not in conﬂict with the privacy policies of the user. Once
the operation has been granted and executed, this is done
according to the principle of data minimization (P4). For
example, a device will send information to an investigator up
to a particular level of granularity.
B. Context-based collection
The process of data collection is guided by the types of
devices involved in the investigation: victim, suspect and
witness, as shown in Section III-A. These particular steps are
depicted in Fig. 5a, where it is worth noting that throughout the
process of gathering digital evidence the devices will remain
under their owners’ control. Otherwise, if the owner is not
willing to cooperate, the investigator will proceed as usual,
requesting warrants and conﬁscating the devices.
When the device to be analyzed is the victim, we assume that
the identity of the owner (or manager) of the device is known.
In this case, the victim is presented with the purpose and
practices to be performed on the data (P2), which needs to be
conﬁrmed by the victim (P1) in order to start the investigation.
The investigator must also check that the device belongs to
the user or that the manager is authorized to request the
investigation. If so, evidence is collected from the device using
forensic tools while ensuring the integrity of the evidence and
documenting the process (P6).
If required by the investigation, it is checked whether the
device was isolated or not. This is useful in the case other
devices can provide new evidence to clarify the case (e.g.,
digital witness [13]) or to identify new cases of infection due to
IV. PRO FIT M ETHODOLOGY
For the sake of simplicity we reduce the problem to investigating a case starting with a single victim device. This device
may be personal (e.g., a cellphone) or non-personal (e.g., a
workstation) and the investigation can consist of obtaining
data from that device alone or require information from other
devices nearby. The process should be replicated in the case
there are several victims. The exposition of methodology is
guided by the phases deﬁned by the PRoFIT model.
A. Environment preparation
We focus on devices that may be set up with the PRoFIT
software (Fig. 2) according to the privacy criteria agreed upon
with the user. Therefore, devices are conﬁgured to collect
information according to the data minimization principle.
Note that this process can be as restrictive as desired but
it is advisable to ﬁnd the right balance between privacy
and usability. The device can be conﬁgured to remove any
630
Start
Phase 2
Are there any
NON-PERSONAL
devices?
(UC2 / UC5)
Start
No
Is the device
directly involved?
Determine
Witness level
Are there
PERSONAL
devices?
(UC5)
No
Yes
Suspect?
No
Determine
Witness policies
– Consent (P1) for
collection by user
request (P2)
(P4)
Collect relevant
information
from the device
¿Is it a
PERSONAL
device?
No
(UC1, UC3,
UC5)
Yes
Request for UC3:
No
Is it isolated?
(UC3 / UC4)
No
Yes
Phase 3
(Analysis and
Correlation)
Request for
Collect relevant
information (P4)
UC2
– based on UC –
Determine the
owner/s /
responsible/s
for the object
Collection limitation (P3)
Request for
Check P6
(Accuracy &
Quality)
Let PERSONAL
devices to next iterations
UC5 (hybrid)
end
(b) Witness data collection
Determine the
responsible/s
for the object
Start
Phase3
Get data
Request for UC4:
Processing
Correlation
(NON-personal)
Yes
Collect (P4)
information from
devices
UC1
Determine the
responsible/s
for the object
(PERSONAL device)
Check P6
(Accuracy &
Quality)
-Consent (P1)
for information
that may be
incriminating/
exculpatory
(P2) over
others
Request for
Yes
Yes
Request for UC1:
Determine the
owner/s for
the object
Yes
Yes
Victim?
No
– Consent (P1) for
information that
may be
incriminating/
exculpatory (P2)
– Warrant if needed
Authorization
Phase 2
Context-based
Collection
Access Control
(P10)
Data
Collect relevant
information from
witnesses
Are additional
context data
necessary?
Are data
needed from other
sources?
No
Yes
No
Store Report
Phase 4
Information
Sharing
Query request from
additional sources in the next
phase (Information Sharing)
Yes
Go to
Start Phase 3
Is there an
answer?
No
Information Security Controls (P10)
Accountability (P9)
(a) Context-based collection steps
(c) Analysis and correlation steps
Fig. 5: Forensic Investigation
the spread of a malware. In that case, we propose following the
steps depicted in Fig. 5b to collect information from witnesses.
Here we also take into consideration different contexts. We
wish to emphasize that, the analysis of new devices is not
undertaken unless it is strictly needed to solve the case. Thus
satisfying the principle of collection limitation (P3).
C. Analysis and correlation
This phase includes the access to, processing and correlation
of data from different sources (see Fig. 5c). In the case that
during this phase the need for new evidence is identiﬁed, the
workﬂow leads the investigator back to phase 2. Likewise, if
the investigator considers that it is necessary to query external
sources for data, it jumps to phase 4 to obtain the information
(recall the PRoFIT workﬂow in Fig. 1). Once the results have
been obtained, access control permission must be checked
again because the permission on the data may have been
revoked or expired.
Note that principles P1 and P2 affecting the user are not
present in this phase because we assume that the data provided
here were obtained using fair information practices.
When the device to be analyzed belongs to a suspect, the
requested permissions will differ from the previous case. In
this case, the investigator will probably need a warrant to
obtain the data since a suspect is highly unlikely to cooperate,
unless his/her device contains exculpatory evidence. In either
case, it is necessary to ﬁnd out who is responsible for the
device when the device is not a personal device directly linked
to a person.
D. Information Sharing
Finally, in the case that the device is considered to be a
witness and to encourage cooperation, we include a clause
stating that the data collected from the device cannot be used
against the witness him/herself. The investigator must carefully
look at the data collected following this procedure or simply
discard them. Note that, if the attacker is a false witness
and he/she signs a collaboration contract then the inculpatory
evidences found on his/her device cannot be used against
him/her. However, it would be easier for him/her to simply
delete the data from the terminal rather than revealing the
truth about him/herself.
This phase involves remote entities, such as foreign authorities, requesting access to the evidence collected from a device
(Fig. 6a). We consider that the owner of the device who offered
the data may have only authorized the use of these data for
a particular entity or to a particular investigation. This is the
reason why we enforce the principles of purpose speciﬁcation
and consent (P1, P2) once again.
The workﬂow shown in Fig. 6a is valid both for queries
for data from different investigations carried out within the
same agency and for queries issued by external entities. We
631
Start
Phase 4
No
Check / Request
(P1) for Information Sharing (P2)
Start
Phase 5
It is an
external
request?
No
Access Control
to the System
(P10)
Sort and
Prioritize
Recopilation
Perform request
Yes
Perform signed
request (P10)
Authorization 1
Query an external
entity via secure
channel (P10)
Authorization 2
External
Entity
Phase 4 in
External Entity
Data
Access Control
(P10)
Write results
Access Control
to data
requested
(P10) for the
speciﬁc
purpose (P2)
Minimization
(P4)
Did the data
expired?
———————-
Authorization
(Action)
Start
Phase 6
———–xx—x—-
Yes
Return and
Safe Erasure
(P5)
Generate proof
of erasure
Generate report
(P6)
Data
…….
…….
Notify User
(P7)
Evaluation
(Admisibility)
Authorization
User /
Collaborator
Data
It is an
explicit request
(e.g., death,
prescribed)
(b) Presentation steps
Supervised access
by a responsible
(P7)
Save proof of
erasure
(P5)
Data
(c) Review steps
(a) Information sharing steps
Fig. 6: Cooperation, admissibility and erasure
consider two authorization criteria; one to receive access to
the data and the other to enable the modiﬁcation of data (e.g.,
to include new information).
detecting the attack, the PRoFIT software decides to store
information related to the attack. Moreover, it alerts Bob to
the presence of a device nearby trying to propagate a worm,
exploiting a vulnerability in the meetMe application, which
uses Bluetooth to detect other users in the vicinity with similar
interests. After being notiﬁed of the offense, Bob decides that
this incident needs to be reported to the authorities as soon
as possible. To that end, Bob decides to request the start of
an investigation by sending the evidence stored in his device
to the PRoFIT system (phase 2). A PRoFIT investigator is
assigned to the case, who, after analyzing the data conﬁrms
that the attack was launched from the local network. However,
the investigator needs more evidence to properly carry out
the investigation and commands the PRoFIT agent installed in
Bob’s device to collect new evidence from any devices nearby
willing to collaborate (back to phase 2).
Following the methodology described in Section IV, the
local PRoFIT agent ﬁrst asks non-personal devices for any
information they can offer. The person responsible for some
of these devices is the owner of the coffee shop, who agrees to
collaborate and allows the devices (e.g., the cash register) to
send information to the investigator using the PRoFIT agent
installed in Bob’s device as the gateway. This information is
encrypted and signed. After reception by the investigator, the
device receives a proof of correct reception that can be checked
by its owner. This proof can be used by the owner of the coffee
shop to ask the investigator to (i) check the correctness of the
data provided, and (ii) to recant and request the erasure of
the statement. Based on the new evidence provided by the
coffee shop owner (phase 3), the results of the investigation
indicate that the malware is latent in a non-personal device,
the Raspberry Pi, and the infection was received from outside
the network, as indicated by the logs of the router. Since it
has not been possible to identify the source of the problem
with the information collected, Bob gives his consent to the
investigator to share his information with other agencies but
only for the purpose of the investigation (phase 4).
After some time has passed, an improved version of the
E. Presentation
The goal of this phase is to generate a forensic report. This
report should be clear to all the actors involved in the case,
including those without expertise in the area, such as lawyers
and judges. The steps involved in this phase are depicted
in Fig. 6b. During this phase, the investigator sorts all the
evidence and information generated in the previous phases.
Data minimization is applied in the case of redundant data
or in the case that the data are considered irrelevant for the
generation of the ﬁnal report. While elaborating this report,
the investigator must pay particular attention to a number
of quality parameters (e.g., legibility) in order to ease the
evaluation of the case.
F. Review
Finally, digital evidence must be erased after a period of
time that must be no less than the timespan of the case. After
that time, it is necessary to delete all the material from data
bases and notify the users involved in the investigation of this
fact. The generation of proof of erasure and its transmission
to the user are optional but revelant for the principles of
transparency (see Fig. 6c). At this point, it is also necessary
to return physical evidence (e.g., a workstation) to the user in
the case it was conﬁscated due to the combination of PRoFIT
with traditional procedures.
V. U SE CASE – S OCIAL M ALWARE
Here we describe a realistic scenario to illustrate how to
apply the PRoFIT methodology in practice. Let us suppose
Bob has a smartphone with a PRoFIT-compliant software
installed (phase 1). He walks into a coffee shop, where there
are several IoT devices, both personal and non-personal (see
Fig. 7). While Bob is in the coffee shop, his device detects an
attempted attack from some of the devices in its vicinity. After
632
smartTV
Mobile
Phone
Smart
Watch
Camera
C
The Coffee Shop
Offended / Victim
Bob’s personal
device PRoFIT compliant
Potential sources /
witnesses
Personal device
Mobile
Phone
Transaction
Proof
Mobile
Phone
(Owner)
Raspberry
Ra
& Cash
Register
Smart
Watch
UC5: hybrid
PRoFIT
Investigator
Internet
Device
Private
wiﬁ
Public
P
wiﬁ
Bluetooth
Connections
Mobile
Phone
Refrigerator
Router
Ro
R
Data
Fig. 7: Scenario
same malware affects new IoT devices. Since the PRoFIT
system has kept information regarding the initial attack, it is
possible to correlate these data with new evidence taken from
various sources and discover the source of the attack and a
potential suspect. The data provided by Bob and other devices
are ﬁnally used to elaborate a ﬁnal report (phase 5), which is
admitted at the trial. Some time after the court ruling, Bob is
notiﬁed that the data he provided has been removed from
the system. A proof of deletion is provided to him (phase 6).
Although this is a hypothetical scenario and the malware as
well as the meetMe application are ﬁctitious, it is reasonable
to think that this type of attack is occurring (or will occur)
without the user even noticing it [14].
VI. C ONCLUSION
This paper has presented the PRoFIT model for conducting
digital forensic investigations in IoT environments. Unlike
previous approaches, the PRoFIT model integrates privacy requirements (ISO/IEC 29100:2011) as part of the methodology.
The goal of considering privacy is to promote the voluntary
collaboration of personal and non-personal IoT devices in
digital forensic investigations. The proposed methodology has
been applied to a realistic use case scenario of malware
propagation in an IoT-enabled coffee shop.
ACKNOWLEDGMENT
This work has been funded by Junta de Andalucia through
the project FISICCO (TIC-07223), and by the Spanish Ministry of Economy and Competitiveness through the project
IoTest (TIN2015-72634-EXP /AEI).
R EFERENCES
[1] K. Kyei, P. Zavarsky, D. Lindskog, and R. Ruhl, “A review and comparative study of digital forensic investigation models,” in International
Conference on Digital Forensics and Cyber Crime. Springer, 2012, pp.
314–327.
[2] S. Watson and A. Dehghantanha, “Digital forensics: the missing piece of
the internet of things promise,” Computer Fraud & Security, vol. 2016,
no. 6, pp. 5–8, 2016.
[3] E. Oriwoh, D. Jazani, G. Epiphaniou, and P. Sant, “Internet of things
forensics: Challenges and approaches,” in Collaborative Computing:
Networking, Applications and Worksharing (Collaboratecom), 2013 9th
International Conference Conference on. IEEE, 2013, pp. 608–615.
[4] T. Geller, “In privacy law, it’s the us vs. the world,” Communications of
the ACM, vol. 59, no. 2, pp. 21–23, 2016.
[5] ISO/IEC 27050:2016+ – Information technology – Security Techniques
– Electronic discovery, ISO/IEC JTC 1/SC 27 Std., 2016. [Online].
Available: http://www.iso27001security.com/html/27050.html
[6] S. Perumal, N. M. Norwawi, and V. Raman, “Internet of things
(iot) digital forensic investigation model: Top-down forensic approach
methodology,” in Digital Information Processing and Communications
(ICDIPC), 2015 Fifth International Conference on. IEEE, 2015, pp.
19–23.
[7] V. R. Kebande and I. Ray, “A generic digital forensic investigation
framework for internet of things (iot),” in Future Internet of Things and
Cloud (FiCloud), 2016 IEEE 4th International Conference on. IEEE,
2016, pp. 356–362.
[8] E. Oriwoh and P. Sant, “The forensics edge management system:
A concept and design,” in Ubiquitous Intelligence and Computing,
2013 IEEE 10th International Conference on and 10th International
Conference on Autonomic and Trusted Computing (UIC/ATC). IEEE,
2013, pp. 544–550.
[9] S. Zawoad and R. Hasan, “Faiot: Towards building a forensics aware
eco system for the internet of things,” in Services Computing (SCC),
2015 IEEE International Conference on. IEEE, 2015, pp. 279–284.
[10] Organisation for Economic Co-Operation and Development
(OECD), “The OECD Privacy Framework,” 2013, [Last Access:
02/2017]. [Online]. Available: http://www.oecd.org/internet/ieconomy/
privacy-guidelines.htm
[11] The European Parliament and the Council of the European Union,
“Regulation (eu) 2016/679 on the protection of natural persons with
regard to the processing of personal data and on the free movement
of such data, and repealing directive 95/46/ec (general data protection
regulation),” 2016, [Last Access: 02/2017]. [Online]. Available: http:
//ec.europa.eu/justice/data-protection/reform/ﬁles/regulation oj en.pdf
[12] ISO/IEC 29100:2011 – Information technology – Security techniques
– Privacy framework, JTC 1/SC 27 Std., 2011. [Online].
Available: http://www.iso.org/iso/iso catalogue/catalogue tc/catalogue
detail.htm?csnumber=45123
[13] A. Nieto, R. Roman, and J. Lopez, “Digital witness: Safeguarding
digital evidence by using secure architectures in personal device,” IEEE
Network, In Press.
[14] S. Peng, S. Yu, and A. Yang, “Smartphone malware and its propagation modeling: A survey,” IEEE Communications Surveys & Tutorials,
vol. 16, no. 2, pp. 925–941, 2014.
633
NETWORK FORENSICS AND SURVEILLANCE FOR
EMERGING NETWORKS
Digital Witness: Safeguarding Digital Evidence by Using Secure Architectures in
Personal Devices
Ana Nieto, Rodrigo Roman, and Javier Lopez
Abstract
Personal devices contain electronic evidence
associated with the behavior of their owners
and other devices in their environment, which
can help clarify the facts of a cyber-crime scene.
These devices are usually analyzed as containers of proof. However, it is possible to harness
the boom of personal devices to define the concept of digital witnesses, where personal devices
are able to actively acquire, store, and transmit
digital evidence to an authorized entity reliably
and securely. This article introduces this novel
concept, providing a preliminary analysis on the
management of digital evidence and the technologies that can be used to implement it with security guarantees in IoT environments. Moreover,
the basic building blocks of a digital witness are
defined.
Introduction
The authors are with the
University of Malaga.
Digital Object Identifier:
10.1109/MNET.2016.1600087NM
34
Mobile user devices are deeply rooted at the
heart of our society. Indeed, social networks
and education in new technologies have greatly
boosted the acceptance of personal devices as
part of our daily lives. They are, from a functional
point of view, an extension of our human abilities. Therefore, it is well known that our devices are a valuable source of electronic evidence
(e.g., network events, user-generated events, user
data) that can shed light on a particular case. At
present, collecting and handling such electronic evidence is a very delicate process, in which
different stakeholders can be involved. This is an
almost artisanal process; in order to avoid any
doubt about the integrity of the digital evidence,
the majority of cases require the involvement of
humans during the seizure of evidence and the
subsequent management process.
Traditional mechanisms for handling evidence
are very robust but insufficient considering the
new challenges that paradigms such as the Internet of Things (IoT) pose [1]. Until now, personal
devices have been seen as containers of electronic evidence, in the same way as a corpse is analyzed to find proof to clarify the facts. However,
how these devices can testify against malicious
cyber-behaviors or cyber-offenses directed to
harm their owners, or other individuals in a city,
is not considered at all. Indeed, this will open the
door to actively acquiring electronic evidence
from the environment of a user (with her/his consent) that nowadays is inevitably lost. These new
sources of evidence, which have not been con-
0890-8044/16/$25.00 © 2016 IEEE
sidered until now, could be key in demonstrating
unproved or hidden cyber-attacks and demotivate
new ones.
The need to prepare our personal devices to
cope with these open issues is the reason the concept of digital witness is being defined here. The
following 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 on the latest trends in electronic evidence management and other concepts related
to our approach are discussed. Then we define
the digital witness concept and its requirements.
After this definition, the feasibility of this new concept in personal devices given current technological trends is analyzed. Finally, the relationships for
the components of a digital witness are defined.
Conclusions and future work are discussed at the
end of the article.
Background
Traditionally, digital evidence is identified, collected, stored, and analyzed within a chain of custody
to ensure the integrity, provenance, and traceability of the proof (cf. UNE 71505:2013, ISO/IEC
27042:2015). Due to the non-material and volatile nature of digital evidence, there are extensive
procedures aimed at ensuring that this evidence is
not repudiated in a court of law [2]. Furthermore,
it is crucial to guarantee access to authorized entities and also identify the people who are responsible for the evidence.
Various researchers have proposed the concept of a digital chain of custody (DCoC) [3],
where certain evidence can be routed toward its
destination through intermediary devices. While
DCoC adds flexibility to the traditional approach,
it has some drawbacks. For example, the type of
evidence handled is very limited (e.g., pictures
with geolocalization), and they tend to be managed by powerful intermediary platforms (e.g.,
the cloud). Besides, all existing DCoC approaches
require the intervention of their human owners at
all times [4, 5].
Given the variety of scenarios where personal devices with limited resources (e.g., mobile
user devices) are involved, including the IoT, it
is necessary to explore new solutions that could
include personal devices as collaborators in a
IEEE Network • November/December 2016
Security requirements
Social & nominative requirements
New concepts defined for digital witness
Available to be used by digital witness,
if new functional components are implemented
Binding delegation
Embedded security architecture
Secure storage
Trusted execution Secure communication Binding credentials
Preservation / integrity
Traceability
Liability
Policies / user agreements
Witnessing roles
Privacy
Authorisation
Non-repudiation
FIGURE 1. Requirements of a Digital Witness and definitions.
DCoC. Such solutions must consider the basic
requirements for digital evidence management,
shown in Fig. 1, which are derived from the standards UNE 71505, ISO/IEC 27037, and ISO/IEC
27042. There are also standards related to digital forensics (UNE 71506, ISO/IEC 30121) that
include the definition of formats and procedures
during the analysis. One potential solution that we
discuss in this article is to use the security architectures embedded in personal devices to define
the digital witness concept.
Digital Witness: Concept Overview
As an evolution of existing DCoC approaches, it
seems reasonable to define cases in which multiple devices behave as human witnesses. Therefore, we define a digital witness as a device that
is able to collaborate in the management of electronic evidence from both the technological and
legal standpoints. In order to realize this vision,
a digital witness defines critical components to
implement the security and legal requirements
shown in Fig. 1, and expands over various concepts and topics, which are summarized in Table
1. The link between the requirements and the
principles behind the digital witness concept are
detailed in the following paragraphs.
Digital witnesses are defined considering
embedded security architectures to make use of
a core of trust to:
• Implement trusted execution environments
• Store and protect, with anti-tampering hardware-based solutions, the proof of integrity
of the digital evidence
Note that the heterogeneity of solutions to do this
in IoT devices requires new solutions for acquiring evidence (e.g., in propietary sensors) following IoT-forensics requirements [1], and also to
homogenize the access to security architectures
as far as possible.
A digital witness also needs to prove that the
user knows about the procedures that his/her
device is carrying out, and therefore authorizes
the device to perform the acquisition, handling,
and processing of the evidence. This is related
to the liability requirement; a digital witness is a
powerful tool for obtaining digital evidence, and
how and why it is being used has to be controlled. Binding credentials help solve this issue
and also add traceability to the evidence during
the delegation procedure. Furthermore, the user’s
privacy will be ensured according to the policies
accepted or not by the user. For example, certain
policies can define the granularity of a user’s data
based on the type of object and the context (e.g.,
IEEE Network • November/December 2016
As an evolution of existing DCoC approaches, it seems reasonable to define cases in which multiple
devices behave as human witnesses. Therefore, we define a digital witness as a device that is able to
collaborate in the management of electronic evidence from both the technological and legal standpoints.
a camera that reveals the number of individuals
in the building but not who they are). Notice that
the use of mobile devices in this approach is considered as a responsibility; the authorities should
be notified of the loss or theft of a digital witness
as if it were the loss or theft of an official id.
Moreover, a digital witness is defined to be
collaborative, to allow the independence of a
major network as in the case of DCoC approaches. Therefore, a digital witness will be able to send
digital evidence to other digital witnesses or any
other entity with the authority to safeguard the
electronic evidence, opening the door for more
varied scenarios. During this delegation of evidence, the existence of procedures such as the
maintenance of a historical log will also help to
keep the traceability of the digital evidence.
Finally, we consider two types of digital witnesses based on user profiles: citizen (or digital
witness) and custodian (or digital custodian).
While the first refers to a digital witness with the
basic properties described in Table 1, the second is a digital witness with privileges. This digital witness is able to perform more actions in the
environment, some of them depending on search
warrants properly handled by the device. Hence,
this is a property that the device inherits from its
user. Furthermore, authorization is not only given
by the role, but will depend on the user’s identity.
Technical Compliance with Requirements
The following section analyzes how the new
technological trends in personal devices can help
implement the concept of digital witness, providing the basis on which to define the new components required (c.f., Fig. 1).
Integrating a Core of Trust: Trusted Platform
Modules and Secure Elements
In order to be used for the storage and transmission of digital evidence, these devices must
employ technologies suitable for the management of digital evidence according to existing
standards. Moreover, these devices should provide a protected space that cannot be tampered
with, where the representative information of the
electronic evidence management process can be
stored.
35
Concept/topic
New concept
Breakdown
Identity
Binding credentials (BC)
• Binds all elements (user-device-evidence)
• Binding delegation — delegate evidence between witnesses
Privacy
IoT-based legal granularity
• Privacy and security policies must be accepted by the user.
• The information depends on the granularity/options selected by the user.
Embedded security
architecture
Improve the use of existing
architectures in personal devices
• Solutions to store electronic evidence preserving its integrity
• Electronic evidence management in compliance with standards and legal
principles
IoT forensics
Enable heterogeneous devices to
handle electronic evidence
• Taxonomy of evidence for IoT
• Homogenization of cooperative mechanisms
• Objects: ranging from wearables to vehicles and buildings
Digital chain of
custody (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 management
based on inherited 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)
TABLE #1. Digital witness — technological leap.
The integrity of the digital evidence is verified if the hash matches the hash stored in the protected
secure storage medium. This information is also stored in the chips and must be delegated to an
entity with the necessary authority to process the digital evidence as soon as possible.
Table 2 shows a representative set of hardware security devices that are integrated inside
IoT devices, ranging from vehicles (e.g., Trusted Platform Module [TPM] v2.0) to wearables
such as boosted near field communication (NFC)
secure elements (SEs). For example, the TPM is
an anti-tampering chip that is embedded in a platform to provide a core of trust (CoT). A CoT is
feasible because these chips integrate a master
key that never leaves the chip, together with its
own cryptographic processor that allows standardized operations. In addition, the TPM also
provides support to validate the integrity of software components, allowing third-party applications using internal registers (PCRs) to store hash
values.
Another, different approach is the use of an
SE. An SE is integrated inside mobile devices, usually for mobile payments. However, SEs can also
be used by other technologies to store keys or
hashes of biometric data (e.g., fingerprints) [6].
Therefore, SEs can also be useful for providing
additional security in other areas, such as the
management of digital evidence.
Both the TPM and SE also provide an additional advantage: most of these chips have mechanisms for deploying a secure communication
channel (e.g., using Diffie Hellman [DH] or elliptic
curve DH [ECDH]). In fact, there are also solutions for defining transactions involving an SE
wherein the device identity is stored [7].
Note, however, that a serious limitation to
these security devices is their limited storage
capacity (Table 3). For example, in some commercial SE chips, the available memory ranges
36
from 800 kB to 1.5 MB (SLE 97 SOLID FLASH
family — UICC/SIM and embedded), or from
240 kB to 500 kB (boosted NFC SE — SIM, SD,
and microSD). This is a limitation because digital
evidence is classed as anything that is of interest
given a context. Thus, the amount of electronic
evidence can be very high. Therefore, at the very
least a guarantee of integrity of the evidence (i.e.,
hash) must be preserved. The integrity of the digital evidence is verified if the hash matches the
hash stored in the protected secure storage medium. This information is also stored in the chips
and must be delegated to an entity with the necessary authority to process the digital evidence as
soon as possible.
Schemes for Binding the User Identity
As mentioned, it is essential that a user can delegate his or her identity to the devices that act as
digital witnesses, establishing an unbreakable link
between a piece of evidence and the individual
who generated it. One particular cryptographic
primitive, proxy signatures, can fulfill the role of
establishing a link between a user and the information generated by his/her devices [8]. In fact,
all strategies that can be used to implement this
particular cryptographic primitive allow us to create this link.
In the most basic approach, known as full delegation (FD), the user delegates the use of his/her
own private key to his/her digital witness device.
This private key can then be used to sign the evidence. Another strategy, delegation by warrant
(DbW), involves the use of a token (warrant),
signed by the private key of the user. This token,
which includes several fields such as the identity
of the device and the validity period of the token
itself, is stored within the device and appended to
all pieces of evidence. All evidence is then signed
using the private key of the device. Finally, in the
last approach (private key), the user’s private key
is used to generate a pair of private and public
IEEE Network • November/December 2016
Device
Asymmetric (max bits)
Symmetric (max bits)
Hash (max)
Others
TPM v2.0 (car). SE if JavaCard
RSA 2048, ECC 256
AES 128
SHA-256, HMAC
Universally unique ID, CoT
SLE 97 SOLID FLASH family.
UICC/SIM
RSA 4096, ECC 521
3DES, AES 256
—
Fingerprint match-on-card
SLE 97 SOLID FLASH family.
eSE
RSA 2048, ECC 521
3DES, AES 256
—
Fingerprint match-on-card
OPTIGA trust authentication
chip
RSA 2048, ECC 52l
3DES, AES 256
SHA-512
GlobalPlatform ID
configuration, CoT, DH/
ECDH, logs
Boosted NFC SE. SIM, SD,
and microSD with integrated
antenna
RSA 4096, ECC 521
3DES, AES
—
—
TABLE 2. Security features of chips embedded in personal devices.
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 is possible to check the identity of
the user who generated the evidence. In this article, we refer to the outcome of these approaches,
or the outcome of any mechanism that provides a
link between a user and his/her device, as binding
credentials.
However, there are some requirements that
must be fulfilled in order to use the output of
proxy signatures as binding credentials in the context of digital witnesses. First, it is mandatory for
users to own a pair of public and private keys,
and such keys must be linked to the identity of
the person themselves. Second, the private key
must be properly secured in a secure element that
allows digital signature operations. Both requirements can be fulfilled by using technologies such
as SIM/UICC cards and electronic identity cards.
In the first case (SIM/UICC cards), according to the Third Generation Partnership Project
(3GPP) TS 33.221 standard [10], it is possible —
with the assistance of the telecommunications
operator — to include certificates and private keys
within the UICC. Moreover, as several countries
require the mandatory registration of SIM card
users by means of a national identity card or
passport, all the information stored within a SIM/
UICC card (including identifiers such as IMSI,
MSISDN [11]) can be used to identify a particular individual. In this case, the evidence management system is developed in collaboration with
the operator, becoming part of the services that
are included within the UICC. This not only allows
the SIM/UICC identifiers to be included within
the evidence, but it also means that the evidence
inside the UICC itself is signed.
Electronic identity cards (eIDs, e.g., the Spanish DNI-e) have a secure element preloaded with
personal information (e.g., national ID, fingerprints), including a pair of private and public keys.
By using the interfaces of the eID card, a natural person can be authenticated for a device or
service using that card [12]. Such interfaces can
also be used to meet the aforementioned requirements: the eID can act as a secure element, generating the necessary binding credentials using
the private keys contained therein. Moreover, as
the key pairs contained within an eID are issued
by the government, there is no need to involve an
IEEE Network • November/December 2016
Device
Memory
(up to)
Interface
SDK
TPM v2.0 (car). SE if
JavaCard
1.6 kB
APDU for
communication with SE
tpm-tools
SLE 97 SOLID FLASH
family. UICC/SIM and eSE.
1.5 MB
ISO/IEC 7816, SWP
Application Development
Toolkit, Java Card
OPTIGA trust
authentication chip
150 kB
ISO/IEC 7816 UART
(400kbps)
Crypto applets, host source
code, Java Card
Boosted NFC SE. SIM,
SD, and microSD with
integrated antenna
500 kB
ISO/IEC 7816, ISO/IEC
14443
—
TABLE 3. Other features of chips embedded in personal devices.
industrial trusted third party in the management
of the evidence. Furthermore, thanks to research
projects like STORK2 [13], different national eIDs
can interoperate with each other.
Delegation of Evidence between Entities
Figure 2 shows the basic steps to delegate one
or more pieces of evidence between digital witnesses. We call this delegation procedure binding
delegation because the first step depends on the
agreement with the policies and creation of binding credentials.
This delegation procedure can be performed
in an ad hoc fashion, where the evidence is
obtained and transmitted by different types of digital witnesses as soon as possible, considering the
role and characteristics of the digital witness. For
example, a personal device belonging to a civilian always has to send the evidence to a digital
custodian at the end of the DCoC-IoT. However,
a digital custodian will never send evidence to
a digital witness; it only collaborates with other
digital custodians. The final destination of the evidence is an official collection point of evidence
(e.g., a building acting as a digital witness with
more resources). At this last point of storage the
evidence is processed.
During this entire transmission process, the
DCoC has to be maintained. In order to do so,
we follow a specific procedure that is detailed in
the following paragraphs.
When the evidence is obtained, a header is
generated with relevant information according
37
Real world
Roles of digital
witness
Identity
Digital world
Binding
credentials
1. User agreement
DW
DW
Secure channel
DW
DW
2. Generation
& storage
DW
5. OK
A
4. Reception
and custody
B
Secure
channel
6. Release
5. Delegation
(…)
DW
Official
collection point
DCoC-IoT
3. Delegation
Liability
1. [A] Binding credentials and policies
3. [A] Generation, identification, and secure storage
4. [A−>B] Delegation of evidence
4. [B] Reception and custody
5. [B−>C] Delegation of evidence, [B−>A]; warranty of reception
6. [A] Release the storage space
DW
C
FIGURE 2. Binding delegation.
The OMUD allows the identity of a user to be linked with his/her personal device. As a result,
it generates a set of binding credentials that are used throughout the digital evidence management
process. In addition, it provides additional options such as request biometric inputs.
to a format for electronic evidence (e.g., [14])
adapted to the requirements of the digital witness.
During this process, an identifier of the evidence
is generated using the binding credentials of the
electronic device that generates the evidence and
the timestamp. This identifier is present throughout the life cycle of the digital evidence. The digital evidence and the probative value are stored
according to the criteria of secure, anti-tampering
storage. The signature process depends on the
mechanism chosen to perform the binding of the
identity of the user to the device.
At some point, an entity A will need to delegate the evidence (e.g., the evidence is considered critical, a strong digital custodian is located
in the vicinity, the device reaches the permitted
threshold for storage). The choice of the next digital witness B is subject to compliance with several
requirements:
• B can attest that it is a digital witness and its
role/level.
• B is a digital witness at the same level as A or
higher.
• B meets the criteria for safeguarding the electronic evidence.
• B is the best candidate (e.g., B minimizes the
number of jumps to the collection point).
• B is a digital custodian and requests the evidence from A, and A can verify the identity
of B.
Once witness B has been chosen, the information concerning the electronic evidence is sent
over a secure channel. B then authenticates the
electronic evidence and proceeds to safeguard
it. In this step, B generates its own evidence to
prove the reception of this evidence in its historical of evidence. The historical of evidence (or
historical) is a summary of the evidence that has
been handled, and ensures the traceability of the
evidence. Then B sends A the proof, indicating
that the reception and storage of the evidence
38
has been possible — a reception guarantee. If B
does not send the proof, A records in 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 was occupied by
the evidence or the sets of evidence.
Functional Components and Relationships
Building on the analysis developed in the previous
section, this section describes the main components that embody the basic concept of a digital
witness. These components enable the basic security architecture to acquire electronic evidence
in dynamic, heterogeneous, and distributed IoT
scenarios. To do so, the requirements of the life
cycle of digital evidence are considered [5, 7, 14].
The functional requirements for digital witnesses must provide, at the very least, the components shown in Fig. 3. As can be seen, ideally
these components are provided or implemented
using the basic capabilities of a secure element.
The main components of this architecture are the
operations manager user device (OMUD), contract manager, cryptographic mechanisms, secure
storage with access control, and digital evidence
manager (DEM).
The OMUD allows the identity of a user to be
linked with his/her personal device. As a result,
it generates a set of binding credentials that are
used throughout the digital evidence management process. In addition, it provides additional
options such as requesting biometric inputs.
The contract manager is an optional component that advises as to the cryptographic mechanisms that are admissible in a court of law and
the different configuration alternatives for managing the evidence, such as the granularity of the
data collected. When a digital witness requests
advice from a contract manager, the system
stores a proof of the advice given by the contract
manager. If this component is not used, the digital witness must be manually configured to use
the cryptographic mechanisms that are allowed.
These cryptographic mechanisms are implemented within a secure element, which is then used
during the management process and probably
(but not necessarily) by the OMUD. Moreover,
IEEE Network • November/December 2016
Digital witness
Operations manager
user-device
FD/DbW/PK
User
User’s
identity
Components within one or more secure elements
e.g., get biometrics
Contract
manager
Anti-tampering secure storage with access
control
Keys
DbW
Role
SA
FD
Historical
H(evidence)
PK
Cryptographic
mechanisms
SA
H(evidence)
Store/delete
evidence
Get
evidence
Historical
Send
evidence
H(evidence)
Digital evidence manager
SA
negotiation
Evidence
Digital custodian
Evidence
Encrypted
evidence
Contract
manager
Updated DB with cryptographic
mechanisms and allowed
operations (legal and regulatory
issues)
Depends on the binding credentials scheme.
Modifications related to evidence.
Modifications related to the transmission.
Modifications related to the contract.
Optional element (recommended)
FIGURE 3. Functional requirements for digital witness based on binding credentials).
the keys and other critical resources (e.g., hashes,
security associations, binding credentials) should
be stored using the secure element.
Finally, the DEM coordinates the processes of
the life cycle of the digital evidence within the
digital witness: generation, identification, secure
storage, delegation, and so on [14].
Interaction between Components
We define three basic cases of communication
between the components shown in Figure 3:
C1. Establishment of action policies for the use
of digital witnesses
C2. Creation of binding credentials
C3. DEM using binding credentials, delegation
of evidence
In C1, the objective is to define the cryptographic mechanisms and configurations that are acceptable, and those additional policies that are necessary
to define the behavior of the digital witness. We
classify the policies into two groups. The first group
(GP1, group policy 1) defines policies relating the
user to the device; for example, the agreement of
the terms of service (without which the digital witness cannot be started), the preferences of the user,
or the way in which the resources in the device are
managed. The second group (GP2, group policy 2)
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, are
negotiated between the user and the OMUD,
while the policies in GP2 are set up through the
DEM. Once accepted, all policies become part
of the security associations that define the behavior of the digital witness and are safeguarded as
electronic evidence, thus constituting a proof of
the negotiation between the physical user and
IEEE Network • November/December 2016
When a digital witness requests advice from a contract manager, the system stores a proof about the
advice given by the contract manager. If this component is not used, the digital witness must be
manually configured to use the cryptographic mechanisms that are allowed.
the digital witness. Subsequently, the policies are
checked for each component, and the integrity of
the policies files is periodically checked using the
corresponding hash. Note that all policies include
the list of security and cryptographic mechanisms
that are accepted for each case, and consider the
list of aforementioned requirements.
In C2, the OMUD is responsible for creating
the credentials (passwords or tokens) that link the
user to the device. The BCs are used transparently
by the DEM to handle the evidence (e.g., storage, transmission) and the historical data. For this
reason, these BCs have to be defined following
the requirements discussed above, and generated
using accepted cryptographic mechanisms available in the digital witness. Moreover, the binding
credentials are stored in an anti-tampering device
within the digital witness.
In C3, we detail the internal behavior of the
components when implementing the delegation procedure described earlier. The evidence
is obtained using forensic mechanisms that are
accepted in a court of law. The hash of the electronic evidence is created using the appropriate
cryptographic mechanisms and is stored inside
the protected area of the secure element when
this functionality is available in the digital witness.
Otherwise, the DEM is responsible for writing the
resulting hash value in the storage space. In any
case, when new evidence is acquired or used, the
historical of evidence must be updated.
39
There is one important topic that requires further analysis in future work: the registration and
verification of the user’s biometric data. This is important because there is no inherent guarantee
that a given user account which is registered in the device belongs to the same user
who created the binding credentials.
Regarding the delegation of evidence, first
the next witness in the chain (candidate for the
delegation) is chosen according to the criteria
previously described. Note that the next witness
can be chosen in a local context (e.g., hop-by-hop
communication) or in a global context (e.g., the
Internet) if other communication methods and
peers are available. The evidence (in this case the
hash of the evidence) and the historical are then
sent to the next witness in the chain using secure
communication channels, which are built using
accepted cryptographic mechanisms, and stating
the binding credentials that demonstrate the link
between the user and the device. Finally, regardless of the result of the delegation (whether or
not it was possible to delegate the evidence), the
historical is updated and the supporting data for
the operations (digital proof of the operations)
are stored in the digital witness.
Optional Interaction between Components
Case C1 can be improved by using the optional component Contract Manager to set up the
policies for managing electronic evidence. In this
case, the Contract Manager is responsible for
assessing the best configuration that satisfies a set
of criteria for the digital witness, plus other factors
such as the granularity of the information.
In this scenario, the interaction mostly occurs
between the Contract Manager and the DEM.
The Contract Manager advises the DEM of the
acceptable configurations for managing electronic evidence, in accordance with the security level
required by the legal framework and the preferences of the user. Initially, the digital witness can
be configured using the default policies defined
by the DEM, and, upon request from an authenticated custodian, it may update these policies
according to the security association negotiated with the digital custodian. In doing so, GP2
is updated. This update can be required at any
moment, and, in fact, it can affect the terms of
service or any other factor detailed in the rest
of the policies. If that is the case, the modifications requested are communicated to the user for
acceptance.
Another security feature that could be very
useful is the use of biometric systems. Such systems can be used in case C2, just before generating the binding credentials, and in case C3 during
the process of acquisition and/or transfer of evidence.
The elements of the architecture that most
actively participate in this optional process are
the user and the OMUD. Before executing any
operation that requires the user’s presence (e.g.,
transmitting a batch of evidence), the user must
advise the OMUD of his/her availability (e.g., by
responding to an alert). At this point, the OMUD
will prompt the user to authenticate him or herself by using the biometric systems listed in the
acceptable configuration. After the authentica-
40
tion process, if the validation has been successful, the OMUD will continue with the planned
operations. Note that evidence will be produced
whenever an operation requires a user’s authentication via biometric systems. The information
stored inside this piece of evidence can range
from a simple registration of the event to specific
biometric information (e.g., the image of a fingerprint), if allowed.
Regarding the implementation of biometric systems, there is one important topic that
requires further analysis in future work: the registration and verification of the user’s biometric
data. This is important because there is no inherent guarantee that a given user account which
is registered in the device belongs to the same
user who created the binding credentials. Note,
however, that it is possible to unambiguously
prove the presence of a specific user involved
in a particular operation if the biometric information provided by the user is validated against
a valid source, such as a legally binding token
or similar device that stores biometric information (e.g., a national eID that stores the user’s
fingerprints). Moreover, if this validation process
is performed during the user account registration
phase, the generated biometric proof that links
the biometric data with the user account will, in
turn, be linked to the user’s identity.
Conclusions and Future Work
In this article, we have introduced and analyzed the concept of digital witnesses. We
have explained the technological solutions and
approaches (e.g., secure elements, binding credentials, DCoC-IoT) that could be used to turn
this particular concept into a reality. Moreover,
we have defined the basic components for the
deployment of digital witnesses.
Whenever a novel concept is defined, there
are always some open issues that must be considered in order to further refine and expand the
applicability of that particular concept. In this article we have shown that it is possible to design a
digital witness for mobile user devices and personal networks; however, this particular design,
which is based on the existence of a binding credential that links the identity of the object to the
identity of a person, might not be applicable in
all IoT contexts. This is because certain devices
might not have unique identities, or even just one
owner. Therefore, future work will be to implement the solution proposed in this article, but also
to analyze use cases within IoT environments that
have not been analyzed here.
Acknowledgment
This work has been funded by the Spanish Ministry of Economy and Competitiveness through
the project IoTest (TIN2015-72634-EXP), https://
www.nics.uma.es/projects/iotest.
References
[1] E. Oriwoh et al., “Internet of Things Forensics: Challenges
and Approaches,” 9th IEEE Int’l. Conf. Collaborative Computing: Networking, Applications and Worksharing, 2013,
pp. 608–15.
[2] E. Casey, Digital Evidence and Computer Crime: Forensic
Science, Computers and the Internet, Academic Press, 2011.
[3] Y. Prayudi and S. Azhari, “Digital Chain of Custody: State
of the Art,” Int’l. J. Computer Applications, vol. 114, no. 5,
Mar. 2015.
IEEE Network • November/December 2016
[4] T. Marqués Arpa and J. Serra Ruiz, “Cadena de custodia en
el análisis forense. implementación de un marco de gestión
de la evidencia digital,” XIII Reunión Española sobre Criptología y Seguridad de la Información, Univ. Alicante, 2014.
[5] S. Omeleze and H. Venter, “Towards a Model for Acquiring
Digital Evidence Using Mobile Devices,” Proc. 10th Int’l.
Network Conf., Lulu.com, 2014, p. 173.
[6] R. Sanchez-Reillo et al., “Strengths, Weaknesses and Recommendations in Implementing Biometrics in Mobile Devices,”
IEEE Int’l. Carnahan Conf. Security Tech., 2014, pp. 1–6.
[7] D. T. Haggerty et al., “Apparatus and Methods for Secure
Element Transactions and Management of Assets,” U.Sa
Patent App. 14/174,791, Feb. 6, 2014.
[8] A. Boldyreva, A. Palacio, and B. Warinschi, “Secure Proxy
Signature Schemes for Delegation of Signing Rights,” J.
Cryptology, vol. 25, no. 1, 2012; http://dx.doi.org/10.1007/
s00145-010-9082-x, pp. 57–115.
[9] H. Debiao, C. Jianhua, and H. Jin, “An Id-Based Proxy Signature Schemes without Bilinear Pairings,” Annals Telecommun., vol. 66, no. 11–12, 2011; http://dx.doi.org/10.1007/
s12243-011-0244-0, pp. 657–62.
[10] 3GPP TS 33.221, “Support for Subscriber Certificates,”
http://www.3gpp.org/DynaReport/33221.htm, accessed
Apr. 2015.
[11] R. Ayers, S. Brothers, and W. Jansen, “Sp 800-101 rev. 1,
Guidelines on Mobile Device Forensics,” tech. rep., Gaithersburg, MD, 2014.
[12] V. Gayoso Martinez et al., “Identification by Means of a
National ID Card for Wireless Services,” 2013 16th Int’l.
Symp. Wireless Personal Multimedia Commun., June 2013,
pp. 1–5.
[13] STORK2: Secure Identity Across Borders Linked, https://
www.eid-stork2.eu/, accessed Apr. 2015.
IEEE Network • November/December 2016
[14] “Une 71505: Tecnologías de la información (ti), sistema de
gestión de evidencias electrónicas (sgee),” Tecnología de la
Información, 2013.
B iographies
Ana Nieto (nieto@lcc.uma.es) is a postdoctoral researcher at
the University of Malaga, Spain. She received her M.Sc. in computer engineering in 2008 and her Ph.D. in computer science in
2015. She has relevant publications on the topic of security and
quality of service trade-offs. Her current research activities are
mainly focused on IoT forensics; she is involved in new research
topics related to digital witnessing.
Rodrigo Roman (roman@lcc.uma.es) is a security researcher
working at the University of Malaga, where he obtained his
Ph.D. and M.Sc. degrees in computer engineering and computer science, respectively, in 2008 and 2003. Previously, he
worked for the Institute of Infocomm Research (I2R) in Singapore in the areas of sensor network security and cloud security.
Working to make security simple and usable, his research is
focused on the development of protection mechanisms for the
Internet of Things and related paradigms, such as cloud computing and fog computing.
Javier Lopez (jlm@lcc.uma.es) is full professor at the University
of Malaga, and his research activities focus on network and protocol security, where he has led more than 50 research projects
and has co-authored over 200 papers. He is Editor-in-Chief of
the International Journal of Information Security, and a member
of the Editorial Boards of IEEE Wireless Communications and the
IEEE Internet of Things Journal. He also is the Spanish representative to IFIP Technical Committee 11 — Security and Protection in
Information Processing Systems.
41
THEME ARTICLE: CYBERTHREATS AND SECURITY
Internet of Things
Forensics
The Need, Process Models, and Open Issues
Maxim Chernyshev
Edith Cowan University
The Internet of Things (IoT) brings a set of unique
Sherali Zeadally
University of Kentucky
forensics. To take advantage of the volume and
Zubair Baig
CSIRO
Andrew Woodward
Edith Cowan University
and complex challenges to the field of digital
variety of data captured by and stored in ubiquitous
IoT services, forensic investigators need to draw
upon evidence-acquisition methods and techniques
from all areas of digital forensics and possibly create
new IoT-specific investigation processes. Although a
number of conceptual process models have been developed to address the unique
characteristics of the IoT, many challenges remain unresolved.
Recent advances in hardware, software, and communication technologies have accelerated the
deployment of a wide range of Internet-enabled devices, resulting in the Internet of Things (IoT).
Industry predictions indicate that the number of connected devices has already surpassed the
population of the planet, with no foreseeable slowdown in growth.1 The evolution and growth of
the IoT has driven the convergence of several technological paradigms comprising wireless sensor networks (WSNs), mobile and cloud computing, and the Internet as the overarching ubiquitous connectivity enablers.
Environmental data–collection systems using sensors and physical world interactions via actuators enable valuable and convenient consumer and industry-focused applications and services.
The current landscape of the IoT represents a ubiquitous, constantly evolving, pervasive, and
highly heterogeneous network of interconnected devices with diverse physical properties and
computational capabilities that are being deployed on a large scale for various applications such
as healthcare, manufacturing, construction, automotive, retail, and engineering.
Unfortunately, security considerations are not always given sufficient priority during IoT system
design and development. Inherent vulnerabilities in communication protocols and software
stacks leave many devices susceptible to threats.2 Cybercriminals exploit these vulnerabilities
and continue to launch highly disruptive and large-scale attacks with increasing levels of sophistication. A case in point was the 2016 denial of service (DoS) cyberattack against Dyn domain
IT Professional
May/June 2018
40
Published by the IEEE Computer Society
1520-9202/18/$33.00 ©2018 IEEE
Authorized licensed use limited to: Consortium – Saudi Arabia SDL. Downloaded on February 13,2020 at 08:45:34 UTC from IEEE Xplore. Restrictions apply.
IT PROFESSIONAL
name servers.3 Having the practical ability to investigate IoT-related cybercrimes will enable the
successful and timely prosecution of those responsible, which is paramount to curbing the growth of adversarial threats.
The science of digital forensics focuses on supporting investigations
involving digital devices, including those in the IoT ecosystem. Digital forensics relies on digital evidence, scientifically derived and
proven evidence-acquisition methods, and validated tools used by
qualified forensic experts. The main objective of digital forensics is to
facilitate acquisition and analysis of forensically sound digital evidence that can be presented and admitted in a court of law. The emergence of the IoT has brought many challenges to digital forensics,
especially by requiring current methods and techniques to be applied
to a highly diverse and ever-changing digital environment.
In this work, we present a succinct review of the state of the art of
conceptual digital forensic models that can be applied to the IoT environment. We also discuss open issues that exist in these conceptual
digital forensic techniques when they are applied to IoT devices.
The science of digital
forensics focuses on
supporting
investigations
involving digital
devices, including
those in the IoT
ecosystem.
THE NEED FOR IOT FORENSICS
The emergence of the IoT is perceived as a potential enabler for novelty in the digital investigation process. For instance, the data collected and shared by ubiquitous
sensors present an abundance of potential digital evidence by virtue of their numbers, variety,
and coverage in many application areas. The digital artifacts found in the IoT ecosystem can be
used to support or refute investigation hypotheses and subsequently any claims made by parties
involved in an investigation. In fact, we have already observed civil and criminal investigations
that made use of data from consumer wearable devices in personal injury and murder cases.4
However, the underlying complexity involved in extracting data from the IoT infrastructure and
its devices can hinder the investigator’s ability to produce forensically sound and admissible evidence.5 This complexity stems from a number of challenges outlined by R.C. Hegarty and colleagues:6
•
•
•
•
uncertainty around where the data came from, where and how it is stored, and the data
attributes that are stored;
difficulty in securing the chain of custody due to increasing data volatility and complex
data transit routes among the IoT architecture layers;
inapplicability of traditional digital forensics extraction techniques to aggregated data
stored in the cloud; and
diverse and proprietary data storage and exchange formats featuring reduced granularity
due to capacity constraints used by IoT services.
To illustrate the unique characteristics of IoT-based digital investigations, we discuss some of
these challenges in this article. In the context of the IoT, an investigator will most likely need to
examine a diverse range of potential evidence sources. This need often presents the requirement
to select and combine multiple digital forensic methods and techniques, which increases the
overall complexity of the investigation procedure as well as the baseline training, skill, and expertise requirements.
For example, consider a contemporary smart home. The Law Enforcement Cyber Centre’s IoT
infographic7 includes 17 potential sources of digital evidence, including smart appliances, connected vehicles, personal assistants, personal health and medical devices, digital photo frames,
smart meters, and home automation systems. These IoT sources run on a heterogeneous set of
technologies that include a combination of multi-protocol wired and wireless communications,
speakers, cameras, microphones, remote and local storage, ambient sensors, voice recognition,
and location tracking. Extraction of evidence from all such devices requires currency in expertise
across multiple digital forensic branches, such as computer, mobile, and embedded forensics for
May/June 2018
41
www.computer.org/itpro
Authorized licensed use limited to: Consortium – Saudi Arabia SDL. Downloaded on February 13,2020 at 08:45:34 UTC from IEEE Xplore. Restrictions apply.
CYBERTHREATS AND SECURITY
working with local storage; network forensics for accessing and analyzing the communications
medium; and cloud forensics for analyzing the remote storage. This issue becomes increasingly
significant in the context of large-scale IoT environments such as industrial deployments and
smart cities. These environments present a considerably larger number of potential individual
evidence sources and introduce additional complexity due to significant technological diversity.
Furthermore, traditional digital forensic methods and techniques such as carving, which is used
to search for specific content in an extracted filesystem image, might not apply to IoT devices
such as lightweight sensors that rely on flash memory with no built-in filesystem storage capability.8 Even if a flash memory image of a device such as a wireless sensor could be acquired by a
known forensic data acquisition tool, it is unlikely that this tool or other tools concerned with
image parsing would be able to interpret the underlying format correctly. Subsequently, the ability to produce human-readable evidence from IoT devices can be severely limited due to lack of
consistency in format and protocol support. Although specialized tools and techniques can be
developed to extract and interpret the contents of specific system on chip (SoC) circuit boards
(for instance, to extract network topology–based evidence such as routing information9), derivation and validation of SoC-specific techniques can be a slow process, which can prove to be unsustainable in practice.
The forensic tools taxonomy provided by NIST does not clearly identify the tools that can be
useful in an IoT-based investigation. The taxonomy lists only a handful of tools (such as iVe and
XRY Complete) that target embedded devices that are widely used in the IoT sensors landscape
outside of the consumer segment.10 Unlike consumer-grade connected devices such as smart appliances (like smart televisions and refrigerators), embedded IoT sensors and actuators are usually based on low-power constrained chips that are based on specialized energy-efficient routing
and application layer protocols such as the Routing Protocol for Low-Power and Lossy Networks (RPL) and the Constrained Application Protocol (CoAP) for connectivity and data transfers.11 The limited capabilities of resource-constrained IoT devices naturally result in higher data
volatility. As a result, potential evidence might not be present at all on
the device or might only reside on the device for a very short period of
time before being overwritten by more recent data.
May/June 2018
Finally, the complexity of digital forensic investigations increases
with the number of potential evidence sources. Consider a compromised IoT solution comprising multiple WSNs with several gateways
and cloud nodes hosting the centralized data store and application services, which also form the back end of a consumer mobile app. If the
compromise is suspected to have originated at the perceptual layer
(see the IoT architecture layers in Table 1) in one of the WSN segments, what sensor selection strategy should be used for analysis when
dealing with hundreds of sensors? Will physical sensor location and
external diagnostics capabilities, if any, allow an investigator to access
the data that might be present, notwithstanding the data parsing and
interpretation challenges discussed earlier? In a case where no initial
pointers to the possible evidence location are available, the investigator needs to be able to correctly identify and select the elements of the
IoT ecosystem from a large number of possible permutations. Incorrect selection can prevent the successful extraction of evidence or facilitate only a partial view.
IoT environments
Aside from these unique characteristics, investigations involving the
IoT will face the same fundamental jurisdictional and data ownership
challenges as more traditional digital investigations involving cloud
services, albeit on a much greater scale.
diversity.
42
present a
considerably larger
number of potential
individual evidence
sources and
introduce additional
complexity due to
significant
technological
www.computer.org/itpro
Authorized licensed use limited to: Consortium – Saudi Arabia SDL. Downloaded on February 13,2020 at 08:45:34 UTC from IEEE Xplore. Restrictions apply.
IT PROFESSIONAL
Table 1. The 1-2-3 Zones of Digital Forensics model and Internet of Things (IoT) architecture.3,11,13
Architecture
layer
Layer description
Device examples
Process
model zone
Applicable
digital forensic areas
Evidence examples
Application
Data aggregation, storage,
analytics,
and dependent
consumer
services
Cloud services, database
servers,
web servers
Zone 3
Cloud forensics
Service
logs, authentication
data, virtual
machines,
and containers
Network
Communication technologies
that facilitate the
data transfer between
layers
Gateways,
firewalls, intrusion detection
systems
(IDS)
Zone 2
Network forensics
Packet
traces, appliance
logs, firewall
and IDS
alerts
Perceptual
A collection
of heterogeneous hardware end
nodes,
physical
sensors,
and actuators
Smart appliances, mobile devices,
constrained
sensors,
embedded
readers,
and tags
Zone 1
Computer,
mobile, and
embedded
forensics
Disk images, sensor
readings,
routing tables, and
device identifiers
IOT FORENSICS PROCESS MODELS
In response to these unique challenges, the digital forensic research community has developed
several conceptual process models to guide forensic investigations involving the IoT. This effort
is still in the early stages of development, with a significant focus devoted to the development of
theoretical process models that are based on hypothetical case studies.12
The Next Best Thing (NBT) triage model was introduced in response to the challenges posed
during the forensic identification phase to assist with determining the potential sources of evidence.3 NBT recognizes the fact that devices—and any original evidence stored on them—could
become unavailable or compromised due to theft, destruction, or tampering. Therefore, an investigator needs to be able to recognize other elements of the IoT ecosystem that are related to the
original device in question, because these elements could contain artifacts that might have evidentiary value. The NBT principle is part of the 1-2-3 Zones of Digital Forensics process model,
which can be mapped to the core three layers (perceptual, network, and application) of the IoT
architecture, as shown in Table 1.
The key principle of the 1-2-3 Zones model is that zone-specific evidence extraction activities
can occur in parallel as well as in isolation for cases where clear direction priorities for investigation are available. As discussed earlier and shown in Table 1, each model zone and IoT architectural layer are associated with a specific digital forensic area or set of areas. To achieve a
thorough forensic investigation covering all zones, we will most likely need to apply methods
May/June 2018
43
www.computer.org/itpro
Authorized licensed use limited to: Consortium – Saudi Arabia SDL. Downloaded on February 13,2020 at 08:45:34 UTC from IEEE Xplore. Restrictions apply.
CYBERTHREATS AND SECURITY
and techniques across the entire field of digital forensics. The combination of techniques from
various areas of digital forensics applied at the perceptual layer has
been grouped under the umbrella of device-level forensics.13
Similarly, the combination of techniques and resources from all digital
forensic areas involved in an IoT investigation forms the conceptual
construct of IoT forensics, which is used as the basis for the ForensicAware IoT (FAIoT) model. The key feature of FAIoT is a centralized,
trusted evidence repository that incorporates a secure logging scheme,
an evidence preservation module, and a provenance module, with investigator access facilitated programmatically through a read-only
API. In this model, the acquisition of evidence is performed live (in
real time) as part of the normal operation of a collection of IoT devices. One of the key advantages of FAIoT is the potential ability to
correlate multiple types of evidence from different zones using the
centralized data store. Unfortunately, the practical implications of this
model and device enrollment procedures have not been tested. Sundresan Perumal and colleagues presented a more concrete top-down
process model that involves significant focus on the development of
specialized standard operating procedures (SOPs).14 However, they
also did not discuss the practical context of their proposed model, as it
has not been practically tested.
Digital forensic
readiness facilitates
proactive evidence
collection in
anticipation of
security incidents,
minimizing the cost of
cyber investigations.
Subsequently, Victor R. Kebande and Indrakshi Ray proposed the Digital Forensic Investigation
Framework for IoT (DFIF-IoT), which focuses on establishing digital forensic readiness and increases the admissibility of evidence extracted through process concurrency.5 Digital forensic
readiness allows organizations to support digital forensic investigations by facilitating proactive
evidence collection in anticipation of security incidents, thus minimizing the cost of cyber investigations. Similar to FAIoT, this model is built with IoT forensics in mind. From the readiness
perspective, the model requires significant attention to proactive scenario-driven activities aimed
at making sure that the environment can inherently capture the necessary evidence and implement we…

Turn in your highest-quality paper
Get a qualified writer to help you with

“ Colorado State University Internet of Things Forensics Survey ”

Get high-quality paper

Guarantee! All work is written by expert writers!

Still stressed from student homework?

Get quality assistance from academic writers!

Order now