Page 70 - ITU Journal Future and evolving technologies Volume 2 (2021), Issue 5 – Internet of Everything

ITU Journal on Future and Evolving Technologies, Volume 2 (2021), Issue 5

HTLC‑Timeout and HTLC‑Success Transactions: LN makes IoT
Gateway 3-of-3 Destination
use of these two‑stage HTLCs to protect nodes from losing Payment 2-of-2 LN Node
Channel
2 Payment
any funds . Both HTLC transactions are almost identical Channels
Bridge
and can be spent with a valid revocation key in case of a Protocol LN Gateway LN Node
cheating attempt. Messages
Cloud ...
The information provided in this section is essential to Hop 1 Hop k
understand the modi ications we propose to BOLT #3 in IoT Lightning
Section 5.4. Device Network
Fig. 4 – Illustration of our assumed system model.
4. SYSTEM & THREAT MODEL
We consider the following attacks to our proposed system:
In this section, we present our system model and state the
threat assumptions. Threat 1: Revoked State Broadcasts: The LN gateway
and bridge LN node can broadcast revoked states to the
4.1 System model blockchain to steal money from other parties.
There are ive entities in our system which are IoT de‑ Threat 2: Spending IoT Device’s Funds: The LN gate‑
way can spend the IoT device’s funds that are committed
vice, IoT gateway, LN gateway, bridge LN node, and
to the channel by sending them to other LN nodes without
destination LN node as shown in Fig. 4. The IoT de‑
the consent of the IoT device.
vice wants to send payments to the destination LN node
for the goods/services. The IoT gateway acts as an access
point connecting the IoT device to the Internet through 5. PROPOSED PROTOCOL DETAILS
a wireless communication standard such as WiFi, Blue‑
In this section, we explain the details of the proposed
tooth, 5G, etc. depending on the application. The IoT gate‑
channel opening, payment sending, and channel closing
way provides connectivity when the IoT device is within
protocols. As mentioned in Section 3, we propose changes
its communication range. With this Internet connection,
to LN’s BOLT #2 and BOLT #3 and show these changes
the IoT device communicates with the LN gateway which
throughout the protocol description.
is running on the cloud. The LN gateway hosts the full
Bitcoin and LN nodes to serve the IoT device and collects
fees in return for its services. Upon a channel opening re‑ 5.1 Channel opening process
quest from the IoT device, the LN gateway opens a chan‑
As mentioned earlier, payment channels are created by
nel to a bridge LN node that it selects from the existing
the on‑chain funding transaction. In our case, the IoT de‑
LN nodes on the network. This bridge LN node is used
vice does not have direct access to Bitcoin and LN thus
to route the IoT device’s payments to the destination LN
cannot broadcast a funding transaction by itself to open a
node. While the LN gateway is free to choose any node, it
channel. For this reason, we propose that the IoT device
should choose a highly connected node with many open
securely initiates the channel opening process through
channels to prevent routing failures. Our proposed sys‑
the LN gateway and generates signatures whenever re‑
tem requires changes to the LN protocol. Therefore, the
quired. This necessitates modifying the LN’s existing
LN gateway and bridge LN node have to run the modi ied
channel opening protocol. The main modi ication is to re‑
LN software.
quire a third signature which is going to be generated by
We assume that both the IoT device and the LN gateway
the IoT device. Regular 2‑of‑2 multisignature LN channels
stay online during an LN operation such as sending a pay‑ are not suitable to accompany 3 signatures; therefore, we
ment. The IoT device can be of line for the rest of the time. propose to change the 2‑of‑2 multisignature channels to
3‑of‑3 multisignature channels. With this change, an LN
4.2 Threat model channel can securely be opened by involving 3 parties.
This is the main novelty in our approach.
We make the following security related assumptions:
1. The LN gateway can post old (revoked) channel The steps of the proposed channel opening protocol are
states to the blockchain. It can gather information depicted in Fig. 5. We explain the protocol step by step
below:
about IoT devices and can try to steal/spend funds
in the channel. However, it follows the proposed IoT Channel Opening Request: The IoT device sends
protocol specifications for communicating with an OpenChannelRequest message to the LN gateway to re‑
the IoT device. quest a payment channel to be opened (#1 in Fig. 5). This
2. The IoT device and the LN gateway have an message has the following ields: Type: OpenChannelRe-
encrypted and authenticated communication quest, Channel Capacity. Channel Capacity is speci ied by
channel between them (i.e., SSL/TLS). the IoT device and this amount of Bitcoin is taken from
the IoT device’s Bitcoin wallet as will be explained in the
2 An explanation on why two-stage HTLCs are needed in LN can be found next steps.
at https://github.com/lnbook/lnbook/issues/187.

58 © International Telecommunication Union, 2021