The pervasiveness of IoT devices makes the delivery mechanism of security updates a challenge. Current IoT systems rely on centralized or brokered paradigms or clouds with huge computational and storage capacities. The existing centralized IoT setups are therefore expensive, owing to the high costs associated with cloud server infrastructures and maintenance, as well as other factors such as network equipment. Thus, the need for a fully decentralized peer to peer and secure technology to overcome these problems rises into the realm of existence. Blockchain provides a solution that fulfills the requirements of such a platform. Ideally, the update infrastructure should implement the CIA triad properties (Confidentiality, Integrity, and Availability). In this article, we study how a blockchain application can meet these requirements and propose a novel system to decentrally distribute digital content in a peer-to-peer network using the blockchain technology and smart contracts to overcome the concerns mentioned above. Additionally, in order to prevent the issues stemming from the free-riding challenge in P2P networks (peers refrain to generously share their resources to distribute updates), we exploit a Nash equilibrium micropayment mechanism to grant adequate incentive for peers to participate in distributing IoT update files.

1. Decentralized and
Secure Delivery
Network of IoT
Update Files Based on
Ethereum Smart
Contracts and
Blockchain Technology
Salar Arbabi Mehdi Shajari

2. Agenda
System
Architecture
Problem Definition, Solution and
Goals
2
1

3. Proof of Concept
4
3
Protocol

4. Conclusion
5

5. Before starting the main
part of the presentation
Blockchain Technology
fundamentals
Smart Contracts
Ethereum Principals
Previous and related works

6. Part 1.
Problem Definition,
Solution and Goals

7. Problem Definition
Based on Gartner Inc. 25 billion connected “things” will be in use by the end of 2020.
Control Structure: Centralized Architecture, Trusted Third Parties, Central Controller
Security
Privacy
Availability
Cost
Single Point Of
Failure!

9. Ethereum Smart
Contracts to Control
Business Logic
Use of Blockchain as
a Distributed Public
Ledger
Decentralized Control
Mechanism
Micropayment
Incentives to Boost Full
Nodes’ Participation in
File Transfer
P2P File Transfer
Distributed File
Storage
IDEA

10. Goals
Decentralization Security Privacy Cost Reduction
Eliminate Single
Point of Failure
Transparency
Availability
Authentication
Access Control
Anonymity
Copyright
Provider in Control
of the Content
Maintenance Cost
Security Costs

11. Part 2.
System
Architecture

12. Ethereum Contract Accounts
Account Management Layer
Ethereum Externally
Owned Accounts (EOA)
Ethereum Wallets
Presentation Layer
Abstract Binary Interface (ABI)
Web-3 Technology
Abstract Binary Interface (ABI)
GUI
Blockchain Layer (Ethereum)
Cryptocurrency (Ether)
Smart Contracts
Light Client Support
Network Layer
Distributed Storage
Distributed Hash Tables (DHT)
P2P File Transfer
Incentive Mechanism

13. Part 3.
Proposed Protocol

14. Limitations
IoT devices are
often limited in
resources
IoT Devices can’t
store the
blockchain
Blockchain has
limited storage and
computation
capability

15. Roles
IoT Devices with limited
resources and capabilities
Intra-Network connection
Update Receiver
A User who owns a few IoT
devices to use in his own
network
Transacts in Ethereum on
IoT Devices’ behalf
IoT Device Vendor
Update Producer
1 2 3Network Owner
IoT Devices –
End Peers –
Target Nodes
Vendor

16. Roles (2)
Update Distributor
Registers IoT Devices
Provided by each vendor
4 5
Vendor Registrar
Contract
Full Node
CONTRACT

17. Registration
CONTRACT
Vendor Vendor Registrar
Contract
Network Owner
Purchase
Registers Device
to enable it and
benefit update
possibilityDeploy
Provide
Protocol - Registration
Registration with
network owner’s
EOA

18. Protocol
Proposed Protocol
Update provider Super Contract
(Proposed Framework)
Instance 1
(Service 1)
Instance 2
(Service 2)
Network Owner
asks for a service
(update in our
case)
{Full Nodes
(P2P File
Distributors)
Update Provider Injects
new encrypted update
to the P2P Distribution
Network
Many to many
relationship
Each instance
for one service
{
update provider informs our
system of new content release
Contract checks for an
agreement
Auction for
Transferring File
and receiving
reward
Grants
Access
(Ticket) in
Case of
Agreement
Auction winner full node
transfers encrypted
update
(Network Owner) Gets
decryption key from
related service contract
Decrypted
update

19. Protocol – Content Abstraction and Access
Control
Blockchains are not efficient for data storing due to its distributed architecture and proof of work
mechanisms
How to achieve content authentication?
Remember
this
Symbol?
Content Abstraction
Checksum
How to store?
Recall Hashmaps from OO.
programming
Solidity
Mapping
x: Update Provider Address
(msg.sender)
y: Update Name Digest
_Update_abstraction[x][y] :
Checksum
z: Network Owner Address
_access_tickets[x][y][z][w] :
Ticket
How about a mapping
of mappings of
mappings?
O(1)
w: IoT Device ID

20. Protocol – Content Abstraction and
AuthenticationProposed
Mechanism
Content
provider
Developed Contract
Content Provider
establishes content
checksum in contract
Upon receiving content, consumer
checks received file with the
checksum of the abstraction stored
at contract
Only the one with
access to private key
can trigger this
Recall msg.sender in
Solidity
Checksum checking
Only gets payed if delivers
authentic file
Otherwise, Waste of gas,
Costly!!!
Access Checking done
before all this! Right at
the request
Consumer
Full Node

21. Protocol - Incentives
Napster, As the first decentralized content delivery system, free riding challenge
Reputation-based
Mechanisms
Micropayment Mechanisms
Reciprocity Mechanism
Capacity
Free Bandwidth
Transfer Duration
Content Size and etc.
Lowest Price Offer wins the
auction
Nash EquilibriumFile Transfer Reverse Auction
Reward := Bid

22. Protocol – File Transfer Auction
First Price Reverse Auction
N ≥ 2 Participants
Each seller i = 1, · · · , N knows his private cost ci ≥ 0 of
production
Production costs are independent and identically
distributed as a p.d.f. f and c.d.f. F, and have a continuous
support J
bidding strategy β maps a bidder’s cost ci to a
corresponding bid bi
Denote the infimum and the supremum of the support J of
the cost distribution by č and ĉ, allowing the possibility of ĉ
being ∞.

23. Part 4.
Proof of Concept

24. Evaluation – Centralized Architectures
Amazon
62%
Microsoft Azure
20%
Google
12%
Other
6%
IoT Market Distribution
3923 $
Monthly
Amazon Web Service
2447 $
Monthly
Microsoft Azure
1443 $
Monthly
Google Cloud Platform
• Node Assignments
• Key Management
• Functional Features
• IoT Core
• Storage
• IoT Hub
• File Transfer
• DDOS Protection
• Functional Features
• Storage
• API
• Azure Firewall
• Automation
• IP Assignment
• IoT Hub
• DDOS Protection
• Storage
• Functional Features
• API
• Bandwidth
• Network Traffic
Management

25. Storage Cost Analysis
Storage Cost
Finished Updates
Demanded Updates
_updateOwner
Field
Maximum Storage
Space
(Bytes)
_updateFileName
_updateFileHash
_winnerBidderIP
_transferPrice
_bandWidth
20
1024
256
60
64
64
_price 64
Total: 1536
Total: 1536 Bytes
_updateOwner
_updateFileName
_updateFileHash
_timestamp
20
1024
256
256
_initialized 8
Total: 1564
Total: 1564 Bytes

26. Functional Cost Analysis
Actor Function Gas Price
per
Execution
Cost Per Month
(8K
transactions -
Dollars)
Network
Owner
Instance
Contract
Finalize
Register IoT
Device
Demand Update
Total:
128.874
320000
42000
28223
28351
0.073
76.961
0.006
51.95
Full
Node
Register Full
Node
Bid to Update
28415
28287
0.007
51.833
Total:
51.84

27. Response Time Analysis
(Mili Seconds)
620.22 584.75 681.38
Number of
Transactions
(Seconds)
8 × 103
4 × 105
6 × 106
3 × 108
4200 6 × 105
8 × 106
16.7916
21.758
74.4197
519.528
15.491
20.58
58.793
382.87
13.41
18.143
51.8362
226.025

28. Choosing the device to be updated

29. Update Information

30. Strengths and Weaknesses
Strengths
Eliminate Single Point of Failure - Availability
Transparency
Content Provider in Control of The Content
Cost Reduction
Weaknesses
Cannot prevent or detect hardcopy distribution of Updates
High average response time and low throughput (Offchain State Channels / Parachains /
Consensus Algorithms)
Scalability

31. Part 5 – Proof of Concept