A Public Digital Ledger Based Forensic Investigation Framework for IoT

1. Motivation
The increase deployment of IoT systems (smart home, city,
medical sensors, wearables, and automobiles) makes them target
for IoT-based cyber-crime.
Smart devices can be used as tools for committing crimes. Attacks
on medical IoT and connected vehicles jeopardize the lives of
patients and road users.
We need a digital forensic investigation framework to find facts in
the incidents of forensic concerns: criminal activities and disputes.
Limitations of Conventional Forensic Models
The conventional forensic approaches, such as media, cloud, and
network forensics, cannot be applied to IoT as is because:
 Acquisition of logs stored in a device's storage is not possible for
devices that are implanted in a body or required to remain always
online.
 Cloud logs cannot be used as evidence for services running on IoT
devices and are accessed locally.
 Network logs are not useful to analyze incidents in mobile IoT-
based systems where network topology changes over the time.
Proposed Forensic Framework: Probe-IoT
We propose Probe-IoT, a forensic investigation framework using a
public digital ledger.
 Proble-IoT considers interactions that take place among various
entities of IoT systems, such as clouds, users, and smart devices,
as evidence (Figure 2).
 Proble-IoT collects interactions and stores them securely as
transactions in a public, distributed and decentralized blockchain
network (Figure 3).
 Proble-IoT eliminates a single entity's control over the evidence
storage to avoid evidence tampering.
 Proble-IoT avoids single-point-of-failures on evidence storage media
and ensures high availability of the evidence by adopting the
distributed architecture.
 Proble-IoT ensures confidentiality, anonymity, and non-repudiation
of the evidence stored in the public digital ledger.
 Probe-IoT provides a mechanism to acquire evidence from the digital
ledger during an investigation and to verify authenticity and integrity
of obtained evidence.
Interaction Provenance
Figure 3: System Overview
Evidence Collection
Evidence Preservation
 The miners assigned by stakeholders (e.g., audit firms, IoT service
providers, insurance providers, and device manufacturers) collect
transactions periodically from the blockchain network.
 A miner compiles transactions for a particular timespan. The miner
validates the signatures attached to the transactions. Next, it
creates an interaction block that contains the transactions. Finally,
the miner adds the block in the blockchain or digital ledger.
Evidence Acquisition
During an investigation, an investigator follows the steps presented below
to acquire evidence from the public blockchain (Figure 5):
 An investigator is provided with the identities of the parties involved in
an incident.
 The investigator provides the identities to the Escrow service and
receives their public keys. The Escrow service has a mapping of the
identity and public key for each party as a tuple [identity, public key].
The Escrow service finds the public keys using the provided identities.
 The investigator acquires transactions related to the incident from the
ledger using public keys, and provides the transactions to the Escrow
service.
 The Escrow service decrypts the interaction data included in the
transactions using it private key.
 The investigator analyzes unencrypted interaction data to find facts.
References
Evidence Security
Confidentiality: Interaction information (request and response data)
available in the public ledger is encrypted using the public key of the
Escrow service. Therefore, it cannot be learned from the public
transactions what data is exchanged between parties.
Non-repudiation: The parties involved in an interaction sign interaction
data. In addition to encrypted interaction data, hashes of the interaction
data and signatures of the involved parties are included in the
transaction. Therefore, a party cannot deny its participation in an
interaction found in the public ledger.
Anonymity: A transaction contains public keys of the involved parties in
addition to hashes and signatures. However, the identities of the parties
are not included in the transaction. The Escrow service has the mapping
of identity and public key, and only knows public keys found in the public
ledger belong to which parties. Therefore, it cannot be determined which
parties are involved in an interaction from the public keys found in a
transaction.
[1] F. Cicirelli, A. Guerrieri, G. Spezzano, and A. Vinci, “An edge-based
platform for dynamic smart city applications,” Future Generation
Computer Systems, 2017.
[2] T. T. Dandala, V. Krishnamurthy, and R. Alwan, “Internet of Vehicles
(IoV) for traffic management,” in ICCCSP. IEEE, 2017.
[3] S. M. R. Islam, D. Kwak, M. H. Kabir, M. Hossain, and K. S. Kwak,
“The Internet of Things for Health Care: A Comprehensive Survey,”
IEEE Access, 2015.
[4] M. Conoscenti, A. Vetr, and J. C. D. Martin, “Blockchain for the
Internet of Things: A systematic literature review,” in AICCSA. IEEE,
2016.
Figure 1: Attack surfaces of Internet of Vehicles
Figure 2: Types of Interactions in IoT-based systems
Figure 4: Transaction creation process
The process of evidence collection (transaction creation) from the
distributed and mobile IoT infrastructure is as follows (Figure 4):
 The initiator of an interaction starts a transaction.
 The parties involved in the interaction sign the transaction using their
public keys issued by an Escrow service.
 The transaction ends when the last party located in the forwarding
path of the interaction signs the transaction.
 The transaction is sent to the blockchain network when it is
completed. Note that the interaction data included in the transaction
is encrypted using the public key of the Escrow service. Figure 5: Investigation process
Acknowledgements
This research was supported by the National Science Foundation
CAREER Award CNS-1351038 and ACI-1642078.
Probe-IoT: A Public Digital Ledger Based Forensic
Investigation Framework for IoT
Mahmud Hossain, Ragib Hasan, and Shams Zawoad
SECRETLab, Department of Computer Science, University of Alabama at Birmingham, AL 35294, USA
{mahmud, ragib, zawoad}@uab.edu