ICACT20220290 Slide.16
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
Thank you for your attention.
|
|
ICACT20220290 Slide.15
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
In this paper, we introduce IPP that can interpret IoTivity packets particularly for encrypted CoAP messages. We demonstrate that IPP can successfully interpret all fields for a CoAP message by extracting session keys with our modified version of IoTivity.
|
|
ICACT20220290 Slide.14
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
We discuss several limitations and future work.
We had to test IPP under the localhost. With the cloud setting, every normal operation after discovery and provisioning should be through the cloud. Testing our parser with the cloud is part of our future work.
Second, the current version of IoTivity supports DTLS v1.2. Thus, IPP must be updated if IoTivity employs a higher version of DTLS (v1.3) because the key format of v1.2 significantly differs from that of v1.3.
Third, we plan to expand the usage of IPP in finding a vulnerability for the design of the IoTivity protocol.
|
|
ICACT20220290 Slide.13
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
Figure illustrates an example of decrypting and parsing messages with IPP.
In this example, the captured device has no ownership.
In case of being owned, the device would not advertise itself during the discovery phase.
At the second phase of owner transfer, IPP successfully parses a message type, token, code, and URI information.
The URI information implies the delivery status from OBT, client or server.
Additionally, we confirmed varying statuses for authentication options, device IDs, ownership transfers onboarding, and provisioning tasks.
|
|
ICACT20220290 Slide.12
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
Figure depicts an overview of IPP.
We developed IPP that takes both raw packets captured by Wireshark and session keys acquired from the modified IoTivity source as inputs, decrypting and parsing CoAP payloads on demand.
We utilize pyshark for Python packet parsing with Wireshark dissectors, and txThings for CoAP interpretation.
IPP can facilitate further analysis by field-wise parsing from decrypted messages, which the naive Wireshark cannot offer.
|
|
ICACT20220290 Slide.11
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
It does not provide this function in the case of IoTivity.
We can extract the necessary key in that format after analyzing the source code.
And create a parser that automatically decrypts packets by providing the obtained key to pyshark.
decrypted messages in the CoAP format.
|
|
ICACT20220290 Slide.10
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
It shows the key format required for dtls decryption.
Definition label for NSS log format.
IOTIVITY-LITE for implementation supports TLS V1.2, so only client_random (*) labels are required.
TLS V1.3 requires seven different labels, including client and server confidentiality.
|
|
ICACT20220290 Slide.09
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
DTLS is similar to SSL/TLS and may be DTLS messages can be decrypted if a key is provided.
However, the key can be obtained through a browser feature by setting up an environment variable.
The key follows a specific log format. In the case of DTLS version 1.2, it is a client random format.
|
|
ICACT20220290 Slide.08
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
However, Our experimental setup excludes the cloud server because its setup is unavailable.
Currently, it is because the IoTivity project does not support cloud environments and only tests locally.
So, we only support the “a”part.
|
|
ICACT20220290 Slide.07
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
This is the overall IoT architecture for communication between an IoT device, mobile controller, relay server, and cloud server.
As an initial step, the IoT device can be registered with the controller via either the relay server ( b and c) or a direct communication over short-range networks ( a), followed by further communication with the cloud server ( c and d).
|
|
ICACT20220290 Slide.06
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
Authentication options are justworks , random PIN, and certificates. Options can be selected and checked from the device at the discovery step.
First, JustWorks does not involve with any authentication mechanism, which may be vulnerable to an attack.
Second, Random PIN confirms that OBT and a device have the same PIN by generating a random number.
Third, Certificate employs a signed certificate for authenticating the device.
|
|
ICACT20220290 Slide.05
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
This figure shows an on-boarding process of IoTivity.
The first Onboaring step is discovery where the OBT explores the unregistered devices.
The second onboarding step is owner transfer.
In this step, OBT selects an authentication method and requests connection.
The last step is provisioning. OBT Perform DTLS handshake with a Pre-Shared Key or PSK that was generated during the Owner transfer step.
|
|
ICACT20220290 Slide.04
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
IoTivity utilizes both Datagram Transport Layer Security (DTLS) and Constrained Application Protocol (CoAP) to support a lightweight and secure communication.
CoAP is an application protocol that has been specialized for devices under resource-hungry environments such as wireless sensor networks.
In particular,
it adopts a simple design that can be easily converted to HTTP using a REST based protocol.
the DTLS protocol offers confidentiality, integrity and over UDP with its simple design.
DTLS handshaking establishes a secure session channel dynamically via an automatic key negotiation between the client and the server, followed by sending and receiving encrypted messages for application data.
|
|
ICACT20220290 Slide.03
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
In order to solve the interoperability problem of the device. The Open Connectivity Foundation (OCF) has established a standard protocol for seamless IoT communication.
IoTivity is one of reference implementations that conforms to the OCF specification.
|
|
ICACT20220290 Slide.02
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
The Internet of Things (IoT) market has been ever-growing in the past years.
This is because more and more people enjoy smart lives.
However, IoT device manufacturers tend to employ closed-source operating systems and network protocols.
So, there is a problem with device interoperability.
|
|
ICACT20220290 Slide.01
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
Hi everyone, my name is hyeonah jung. For ICACT 2022, I have collaborated with two partners, Professor Hyung-joon Koo and Professor Jae-hoon jeong of Sungkyunkwan University. Today's presentation is IoTivity Packet Parser for Encrypted Messages in Internet of Things.
|
