Explore Research Data Collection Methods

ZEKEB

Advanced_Authentication_and_Au.pdf

Home >Information Systems homework help >Explore Research Data Collection Methods

ABSTRACT

KIM, TAE HYUN. Advanced Authentication and Authorization Protocol for IoT Networks.

(Under the direction of Dr. Douglas Reeves and Dr. Rudra Dutta).

Internet of Things (IoT) is an intelligent infrastructure and network service technology

that connects objects and people for monitoring and control. As IoT becomes increasingly

important to industry and daily life, we are interacting with more devices in a variety of

environments. From constrained networks to large enterprise businesses, the number of IoT

devices is growing rapidly due to the development of IoT technologies, the various benefits from

IoT devices, and the user’s convenience from Smart environments.

Today, however, IoT systems pose security vulnerabilities, and the use of different

platforms is restricted due to the lack of standards covering overall security. Most independent

IoT systems are building security authentication in an ID/password manner that relies on

network layer-level security protocols, and enterprise Cloud platforms (e.g., Google IoT Core,

Amazon AWS, etc.) have their own IoT security technologies based on their infrastructure.

Therefore, a baseline standard model of IoT security at the application layer level based on

robust and secure authentication and authorization is required.

In this dissertation, we propose an advanced authentication and authentication protocol

for IoT networks (IAuth+). Specifically, we provide a secure and robust mechanism to

authenticate major factors and to authorize IoT services in various IoT networks, such as

Enterprises, Smart Home, Smart Agriculture, etc., consisting of phased processes using extended

OAuth 2.0 and Kerberos v5 which are a strong network standard authentication protocol based

on tickets / tokens. Our proposed protocol supports (1) reliable device / administrator registration

procedure relying on extended OAuth 2.0 authentication, (2) secure Domain Name System

(DNS) name autoconfiguration through the security pairing channels in only Enterprise IoT

network environments, and (3) user / service authentication and authorization procedure based

on advanced Kerberos v2 for heterogeneity and scalability of various IoT networks.

In this dissertation, we also survey DNS vulnerabilities and attacks. DNS plays an

integral role in the functionality of the Internet. Clients receive Internet service by mapping

domain names into internet protocol addresses, which are routable. DNS provides a scalable and

flexible name resolution service to clients easily and quickly. However, DNS was initially

developed without security, and the information is not secured. Although DNS security extension

was released in 1999 to protect against vulnerabilities, it is not widely deployed, and DNS

continues to suffer from a variety of attacks. The purpose of this study is to summarize a

comprehensive survey of DNS security and to identify areas for improvement.

Advanced Authentication and Authorization Protocol for IoT network

Tae Hyun Kim

A thesis submitted to the Graduate Faculty of North Carolina State University

in partial fulfillment of the requirements for the degree of

Doctor of Philosophy

Computer Science

Raleigh, North Carolina 2022

APPROVED BY:

_______________________________ _______________________________ Dr. Douglas Reeves Dr. Rudra Dutta Committee Chair _______________________________ _______________________________ Dr. Khaled Harfoush Dr. Ruozhou Yu

DEDICATION

I humbly dedicate this achievement to my beloved wife, Hee Sun who has supported and

encouraged me with her love and prayer, to my precious sons, Haseuryn, Hairyn, and Haelrin

who are truly blessed by God, to my parents who have support and love to me, and to God

Almighty.

iii

BIOGRAPHY

Tae Hyun Kim was born on October 11, 1979, in Seoul, South Korea. He received his

Bachelor of Science in Computer Science from Korea Army Academy, Yeongcheon, South

Korea in 2003, his M.S. degree in Computer Science from Auburn University, Alabama, USA in

2008. He has been a military officer since 2003, currently serving as a computer officer

(Major) in Republic of Korean Army. In January 2016, he started his work as a PhD student in

the Department of Computer Science, North Carolina State University. Currently, he is working

as a member of Wolfpack Security and Privacy Research Lab (WSPR) at the network security

under Prof. Douglas Reeves and Prof. Rudra Dutta. In July 2020, he published the journal paper

in the Journal of Surveillance, Security and Safety. In August 2021, he also published the

conference paper in the IEEE GLOBECOM 2021, Madrid, Spain and submitted another

conference paper in the IEEE ICC 2022, Seoul, South Korea. After graduation, he will work at

the Cyber Operation Center in Republic of Korean Army as the cybersecurity engineer officer.

ACKNOWLEDGMENTS

First, I would like to extend an immeasurable appreciation for supports to the following

persons who contributed to completing this study. Prof. Douglas Reeves, my advisor, guided me

through each stage of the process in the completion of this study. He has shared his much

knowledge and experience in carrying out various research topics. His endless enthusiasm for

research has continuously motivated me throughout the Ph.D. study. In addition, he has been a

great mentor in my life. I am very thankful for having such a wonderful advisor like him.

Second, I would like to express heartfelt gratitude to Prof. Rudra Dutta provided me

many insightful comments for this dissertation. In addition, when I asked him to be my co-

advisor, he gladly accepted and helped me to experience research fields of IoT network

environments.

Third, I would like to acknowledge Prof. Khaled Harfoush and Prof. Ruozhou Yu for

their valuable comments and advice as my committee members.

Fourth, I would like to express my wholehearted thanks to my family for their generous

support throughout the process of pursuing a Ph.D. degree. Without their prayer and love, I could

not have the opportunity to complete this dissertation.

Lastly, I am very grateful to God for this dissertation would not have been possible

without His mercy and grace.

TABLE OF CONTENTS

LIST OF TABLES ......................................................................................................................... x

LIST OF FIGURES ...................................................................................................................... xi

Chapter 1: Introduction .............................................................................................................. 1

1.1 Contribution ............................................................................................................................. 3

1.2 Outline ...................................................................................................................................... 5

Chapter 2: Background and Related Work .............................................................................. 6

2.1 Generic IoT Network Architecture .......................................................................................... 6

2.2 IoT Protocols ............................................................................................................................ 7

2.2.1 DTLS......................................................................................................................... 8

2.2.2 CoAP vs. MQTT ....................................................................................................... 9

2.3 Recent IoT Security Trends ................................................................................................... 11

2.3.1 Authentication and Authorization ........................................................................... 12

2.4 DNS for IoT Network ............................................................................................................ 13

2.4.1 DNS benefits for IoT Network ............................................................................... 13

2.4.2 mDNS ..................................................................................................................... 13

2.4.3 DNSNA (DNS Name Autoconfiguration) .............................................................. 15

2.4.4 SDNSNA (Secure DNS Name Autoconfiguration) ................................................ 16

2.4.5 Is it efficient for IoT to adapt DNS? ....................................................................... 17

2.5 OAuth 2.0 for IoT network .................................................................................................... 18

2.6 Kerberos v5 for IoT network ................................................................................................. 21

Chapter 3: IAuth+ for Enterprise IoT Network ..................................................................... 23

3.1 Motivation: Enterprise Security Issues .................................................................................. 23

3.2 IAuth+ Architecture for Enterprise IoT Network .................................................................. 24

3.2.1 Entities .................................................................................................................... 24

3.2.2 Architecture ............................................................................................................. 25

3.3 IAuth+ Three-Step Solution ................................................................................................... 26

3.3.1 Step 1: Pairing ......................................................................................................... 26

3.3.2 Step 2: DNS Name Autoconfiguration ................................................................... 28

3.3.3 Step 2: Utilization ................................................................................................... 30

3.4 Effectiveness .......................................................................................................................... 32

3.4.1 STRIDE Model ....................................................................................................... 32

3.4.2 Benefits of IAuth+ for Enterprise IoT .................................................................... 36

3.5 Analysis.................................................................................................................................. 36

3.5.1 Comparison with SDNSNA .................................................................................... 37

Chapter 4: IAuth+ for Smart Home Network ......................................................................... 39

4.1 Motivation: Smart Home Security Issues .............................................................................. 39

4.1.1 Google IoT Core ..................................................................................................... 40

4.2 IAuth+ Architecture for Smart Home .................................................................................... 42

4.2.1 Entities .................................................................................................................... 42

4.2.2 Architecture ............................................................................................................. 43

4.3 IAuth+ Two-Step Solution ..................................................................................................... 44

4.3.1 Step 1: Pairing ......................................................................................................... 44

vii

4.3.3 Step 2: Utilization ................................................................................................... 46

4.4 Effectiveness .......................................................................................................................... 47

4.4.1 STRIDE Model ....................................................................................................... 47

4.4.2 Benefits of IAuth+ for Smart Home ....................................................................... 51

4.5 Analysis and Evaluation ........................................................................................................ 52

4.5.1 Comparison with Google IoT Core ......................................................................... 52

4.5.2 Comparison of Computation Cost .......................................................................... 54

Chapter 5: IAuth+ for LoRaWAN ........................................................................................... 56

5.1 LoRaWAN Security Review .................................................................................................. 56

5.1.1 Key Derivation and Distribution ............................................................................. 58

5.1.2 Device Activation ................................................................................................... 59

5.2 Motivation: LoRaWAN Security Issues ................................................................................ 61

5.2.1 Not protected Join Message .................................................................................... 62

5.2.2 Rogue Gateway Attack ........................................................................................... 63

5.2.3 Rogue End Device Attack ....................................................................................... 64

5.2.4 No User Authentication Protocol ............................................................................ 64

5.3 IAuth+ Architecture for LoRaWAN ...................................................................................... 65

5.3.1 Entities .................................................................................................................... 65

5.3.2 Architecture ............................................................................................................. 66

5.4 IAuth+ Two-Step Solution ..................................................................................................... 67

5.4.1 Step 1: Pairing for End Device ............................................................................... 68

5.4.2 Step 1: Pairing for Gateway .................................................................................... 70

viii

5.4.3 Step 2: Utilization ................................................................................................... 71

5.4.4 Integration of IAuth+ and LoRaWAN (OATT) ..................................................... 73

5.5 Effectiveness .......................................................................................................................... 75

5.5.1 STRIDE Model ....................................................................................................... 75

5.5.2 Benefits of IAuth+ for LoRaWAN ......................................................................... 78

5.6 Analysis and Evaluation ........................................................................................................ 79

5.6.1 Comparison with LoRaWAN ................................................................................. 79

5.6.2 Comparison with other security protocols .............................................................. 80

5.6.3 Comparison of Computation Cost .......................................................................... 81

5.6.4 Comparison of Number of Message and Time on Air ............................................ 83

5.7 Conclusion ............................................................................................................................. 86

Chapter 6: A Survey of DNS Vulnerabilities and Attacks ..................................................... 87

6.1 Motivation .............................................................................................................................. 87

6.2 Background ............................................................................................................................ 89

6.2.1 DNS (Domain Name System) ................................................................................. 89

6.2.2 DNSSEC (DNS Security Extensions) ..................................................................... 92

6.3 Vulnerabilities ........................................................................................................................ 95

6.3.1 DNS Vulnerabilities ................................................................................................ 96

6.3.2 DNSSEC Vulnerabilities ........................................................................................ 99

6.4 Attacks ................................................................................................................................. 102

6.4.1 DNS data tampering .............................................................................................. 103

6.4.2 DNS data flooding ................................................................................................ 106

6.4.3 Abuse of DNS ....................................................................................................... 107

6.4.4 DNS server structure ............................................................................................. 109

6.4.5 Assessment of DNS attacks .................................................................................. 111

6.5 Mitigations ........................................................................................................................... 114

6.5.1 DNS and redundant DNS ...................................................................................... 114

6.5.2 Existing DNS mitigation systems ......................................................................... 115

6.5.3 Overall assessment of DNS mitigation system ..................................................... 121

6.5.4 Secure/Enterprise DNS provider ........................................................................... 123

Chapter 7: Conclusion ............................................................................................................. 125

7.1 Conclusion ........................................................................................................................... 125

7.1.1 IAuth+ ................................................................................................................... 125

7.1.2 A Survey of DNS Vulnerabilities and Attacks ..................................................... 127

7.2 Recommendations of Future Work ...................................................................................... 128

REFERENCES ......................................................................................................................... 129

LIST OF TABLES

Table 2.1 Comparison between MQTT and CoAP .................................................................. 10 Table 3.1 Six Factors of STRIDE Threat Model ...................................................................... 32 Table 3.2 Comparison with SDNSNA ..................................................................................... 37 Table 4.1 Comparison with Google IoT Core .......................................................................... 53 Table 4.2 Notation for computation cost analysis .................................................................... 54 Table 4.3 Comparison of computation cost of our protocol with Google IoT Core ................ 55 Table 5.1 Functionality Comparison with LoRaWAN ............................................................. 80 Table 5.2 Comparison with other security protocols ................................................................ 81 Table 5.3 Notation for computation cost analysis .................................................................... 82 Table 5.4 Comparison of computation cost of our protocol with other security protocols ...... 82 Table 5.5 Transmission Bit Rate and Range with code rate 4/5 and a 125 kHz Bandwidth .... 84 Table 6.1 Assessment of DNS Attacks ................................................................................... 112 Table 6.2 Assessment of DNS Mitigation .............................................................................. 122 Table 6.3 List of the 10 Enterprise DNS providers ................................................................ 123

LIST OF FIGURES

Figure 1.1 2019-2020 Global IoT Malware Volume ................................................................... 2 Figure 2.1 Generic IoT Network Architecture ............................................................................. 7 Figure 2.2 Architecture of IoT Three Layers ............................................................................... 8 Figure 2.3 Publication from Elsevier, IEEE, Hindawi, and Springer from 2016 to 2018 ......... 11 Figure 2.4 Research Trends on Authentication ......................................................................... 12 Figure 2.5 mDNS Architecture .................................................................................................. 14 Figure 2.6 DNSNA Name Format ............................................................................................. 16 Figure 2.7 SDNSNA System Configuration .............................................................................. 17 Figure 2.8 OAuth 2.0 Protocol Flow ......................................................................................... 19 Figure 2.9 OAuth 2.0 Framework for IoT Network .................................................................. 20 Figure 2.10 Kerberos v5 Framework ........................................................................................... 21 Figure 3.1 IAuth+ Architecture for Enterprise IoT network ..................................................... 25 Figure 3.2 Pairing Step Message Flow ...................................................................................... 28 Figure 3.3 DNS Name Autoconfiguration Step Message Flow ................................................. 29 Figure 3.4 Utilization Step Message Flow ................................................................................. 31 Figure 4.1 Google IoT Core device activation .......................................................................... 42 Figure 4.2 IAuth+ Architecture for Smart Home ...................................................................... 43 Figure 4.3 Pairing Step Message Flow ...................................................................................... 45 Figure 4.4 Utilization Step Message Flow ................................................................................. 47 Figure 4.5 Comparison of the computation cost in IAuth+ and Google IoT Core .................... 55 Figure 5.1 LoRaWAN Network Configuration ......................................................................... 57 Figure 5.2 LoRaWAN Server Architecture ............................................................................... 58

xii

Figure 5.3 LoRaWAN Key Derivation and Distribution ........................................................... 59 Figure 5.4 Over-the-air Activation (OTAA) procedure ............................................................. 61 Figure 5.5 LoRaWAN Security Issues: Not protected Join Message ........................................ 62 Figure 5.6 LoRaWAN Security Issues: Rogue Gateway Attack ............................................... 63 Figure 5.7 LoRaWAN Security Issues: Rogue End Device Attack .......................................... 64 Figure 5.8 IAuth+ Architecture for LoRaWAN ........................................................................ 67 Figure 5.9 Pairing Step for End Device Message Flow ............................................................. 69 Figure 5.10 Pairing Step for Gateway Message Flow ................................................................. 71 Figure 5.11 Utilization Step Message Flow ................................................................................. 73 Figure 5.12 Integration of the Join Procedure with IAuth+ over LoRaWAN ............................. 74 Figure 5.13 Comparison of the time cost in IAuth+ and other related works ............................. 83 Figure 5.14 Time on Air of LoRaWAN with code rate 4/5 and a 125 kHz bandwidth ............... 84 Figure 5.15 Comparison of the number of the message in IAuth+ and other related protocols .. 85 Figure 5.16 Time on Air of IAuth+ and other related protocols with 20-byte payload ............... 86 Figure 6.1 DNS Structure .......................................................................................................... 90 Figure 6.2 DNS Architecture ..................................................................................................... 90 Figure 6.3 Public Key Cryptography Architecture .................................................................... 93 Figure 6.4 DNSSEC Architecture .............................................................................................. 94 Figure 6.5 DNS Attacks List .................................................................................................... 102 Figure 6.6 DNS Attack: DNS Data Tampering ....................................................................... 104 Figure 6.7 DNS Attack: DNS Data Flooding .......................................................................... 106 Figure 6.8 DNS Attack: Abuse of DNS ................................................................................... 108 Figure 6.9 DNS Attack: DNS Server Structure ....................................................................... 110

xiii

Figure 6.10 Classification: DNS Attacks by Purpose ................................................................ 113

CHAPTER 1

Introduction

IoT is the most popular Internet-based technology, a global network, providing services

by processing information collected from smart devices in various environments, such as a smart

home, an enterprise network, a smart city, and agriculture. The IoT market is also growing

rapidly. According to the Hype Cycle 2020 report [1], Gartner reported that the IoT market

revenue is $212 billion worldwide, and 20.4 billion IoT devices are connected to online in 2020,

approximately a 20% increase from 2019. However, IoT attacks are a severe security issue, as

has already been shown by the Mirai bot attack in 2016 [2]. Over 300,000 security-vulnerable

IoT devices in 164 countries were infected with Mirai Malware and carried out DDoS attacks. A

major reason for IoT devices’ vulnerability was their weak authentication and authorization

methods using default ID/PW. As usage of IoT grows, seriousness and potential damage of

cyber-attacks are expected to increase.

Figure 1.1 2019-2020 Global IoT Malware Volume

As shown in Figure 1.1, the number of IoT malware attacks increased by 66% between

2019 and 2020 (from 34.3 million to 56.9 million attacks) according to the 2021 Cyber Threat

Report published by SonicWall [3]. IoT manufacturers failed to implement proper security

controls to protect IoT devices from cyber-attacks despite much growth and effort. Moreover,

existing security solutions can be difficult to apply to IoT without modification because of

specific characteristics: low-capacity devices, heterogeneity, resource constraints, and privacy.

Domain Name System (DNS) is strongly recommended for IoT networks to manage and

address numerous IoT devices efficiently. However, DNS suffers from many cyber attacks using

compromising various vulnerabilities [5]. Bonjour, developed by Apple, automatically assigns

DNS names to Apple devices through a zero-configuration method called multicast DNS

(mDNS) [4]. Although mDNS is helpful for managing IoT devices in internal networks, it is not

suitable for IoT device name services in global networks [5]. Lee et al. proposed a new naming

framework for DNS Name Autoconfiguration (DNSNA) to automatically configure domain

names for globally accessible IoT networks [6]. DNSNA provides an automatic DNS name

through DNS. However, DNSNA was developed without any authentication process for device

registration. Thus, there is a vulnerability that allows attackers to register unauthenticated IoT

devices [7]. Although Secure DNS Name Autoconfiguration (SDNSNA) for IPv6 IoT devices

was published [7] to overcome security vulnerabilities of DNSNA through NFC-based

authentication, SDNSNA still has security problems.

1.1 Contribution

This dissertation includes two main topics: (1) Advanced Authentication and

Authorization protocol for IoT network and (2) a survey of DNS vulnerabilities and attacks.

First, we propose robust authentication and authorization in the various IoT networks.

The basic premise is to incorporate various IoT devices in a way that is suitable for many

environments. As discussed above, significant IoT security vulnerabilities are weak

authentication and authorization of entities in IoT networks. We present a new protocol called

Advanced Authentication and Authorization for IoT networks (IAuth+) to address these

problems. The purpose of this research is to provide an advanced secure authentication and

authorization mechanism for the three specific scenarios (Enterprise IoT network, Smart Home,

and LoRaWAN). The protocol provides an overall secure IoT procedure for device registration,

IoT DNS naming service, and service utilization with protection against cyber-attacks such as a

Mirai attack [4]. The root of trust for this configuration is a QR code attached to a device,

identifying the device, and allowing its secure configuration employing symmetric key

cryptography. Also, we utilize a modified OAuth 2.0 and Kerberos v5 for IoT networks, which

researchers have extensively validated to maximize the robustness of authentication and

authorization.

The major contributions of our research in IAuth+ are as follows:

• We define the security vulnerabilities in IoT networks. In representative three IoT

network environments – Enterprise IoT, Smart Home, and LoRaWAN- current

security issues related to authentication and authorization that result in potential

threats are described.

• We propose a robust authentication and authorization protocol with the advanced

OAuth 2.0 and Kerberos v5 for IoT network environments.

• We apply our proposed protocol to three different scenarios and show each with

unique requirements and constraints that require significant modification as

follow:

o For the enterprise IoT network, our proposed protocol supports an

efficient global DNS naming service based on secure authentication and

authorization.

o For the smart home network, our proposed protocol provides a simple but

robust authentication and authorization in which home users can utilize

tested-and-tried open concepts based on new lightweight authentication

and authorization, with minimal vendor dependence.

o For the LoRaWAN network, our proposed protocol suggests a robust

authentication and authorization protocol over LoRaWAN to mitigate

security vulnerabilities and possible attacks with authentication issues.

Second, this dissertation provides a comprehensive survey of DNS and DNSSEC

vulnerabilities, attacks exploiting those vulnerabilities, and mitigations proposed or deployed to

address such attacks.

The major contributions of our research in the survey of DNS security are as follows:

• The problems of DNS and DNSSEC security are described and classified as

fundamental, structural, and systematic vulnerabilities. Also, the increasing

seriousness of DNS attacks is discussed.

• Various DNS attacks are discussed and classified by purpose to understand and

analyze them.

• Defenses against DNS attacks are described, and the effectiveness of current DNS

attack mitigation is assessed.

1.2 Outline

Chapter 2 provides background on IoT security issues, IoT security architecture, DNS

philosophies, and two primary authentication and authorization protocols related to IAuth+.

Chapter 3 describes the IAuth+ for the enterprise IoT network with DNS name

autoconfiguration. Chapter 4 explains the IAuth+ for the smart home network compared with

Google IoT Core. Chapter 5 demonstrates the IAuth+ for the LoRaWAN network to improve the

current authentication mechanism. Each IAuth+ section includes the effectiveness and analysis

as the evaluation. Chapter 6 presents a survey of DNS vulnerabilities, attacks, and mitigations

with the analysis and the assessment. Chapter 7 concludes with the implications of this study and

future directions.

CHAPTER 2

Background and Related Work

This chapter summarizes fundamental IoT network philosophy, some recent IoT security

trends, and two trusted authentication techniques - OAuth 2.0 and Kerberos v5, which are the

foundation of the proposed protocol model.

2.1 Generic IoT Network Architecture

The generic IoT network architecture consists of four parts [8]:

(1) End devices: IoT devices collet data in the physical world for analysis.

(2) Network: allows IoT devices to connect to the Internet

(3) Middleware: a software or a platform that serves as an interface between

components of IoT, providing information to application servers or users.

(4) Application: an end-user to receive the information from IoT devices.

Our proposed protocol covers authentication and authorization between end devices and

applications to prevent malicious access from attackers.

Figure 2.1 Generic IoT Network Architecture 2.2 IoT Protocols

The IoT network typically consist of three layers: a perception layer, a network layer, and

an application layer as shown in Figure 2.2 [8, 9].

(1) The perception layer, as a physical layer, focuses on comprehensively collecting

external information from the devices in the environment. The perception layer

includes RFID, GPS, temperature, and various sensors. The information collected

is transferred to the application layer via the network layer.

(2) The network layer is responsible for securely and efficiently transmitting and

processing the information to other IoT devices, network devices, or servers.

(3) The application layer is a core of IoT services. The application layer is

responsible for delivering the information to users in various services – smart

homes, smart agriculture, and other applications. This thesis focuses on the

security of the application layer.

Figure 2.2 Architecture of IoT Three Layers

2.2.1 DTLS

DTLS (Datagram Transport Layer Security) is a security protocol for UDP that allows

the Transport Layer Security (TLS) protocol to be applied to UDP, which provides security for

the TCP protocol of the Transport layer [10]. Thus, UDP-based applications can use DTLS to

prevent possible attacks on the network, such as eavesdropping, interference, and message

tampering. In particular, IoT devices are a protocol based on UDP rather than TCP due to the

requirements such as low processor performance and low power. UDP for connectionless

datagram has less network overhead and smaller packets than TCP, meeting IoT network

requirements. Therefore, DTLS is a suitable security protocol for the transport layer in IoT

networks. Currently, DTLS version 1.2 was released for UDP-based security that provides

security for the TCP protocol of the transport layer.

The IoT environment provides services based on intercommunication between objects

without human intervention. Most IoT devices are limited by low power, small capacity, high

loss/low bandwidth networks, and MQTT and CoAP are attracting attention as lightweight

communication protocols suitable for these characteristics.

2.1.2 CoAP vs. MQTT

CoAP (Constrained Application Protocol) is a REST-based protocol for supporting

communication between M2M nodes at a higher application layer, including a transmission layer

based on 6LoWPAN [11]. It is a lightweight message transmission protocol based on the REST

(Representational State Transfer) that is optimized for bandwidth-constrained communication

environments such as Machine to Machine (M2M) and Internet of Things (IoT).

MQTT is a TCP-based, publish-subscribe network protocol developed by IBM and

established in 2014 by Oasis, an international standards organization. MQTT is suitable for IoT

with limited communication bandwidth. In particular, the Google IoT platform also uses

reflecting the MQTT protocol. MQTT consists of three factors: an MQTT broker, a publisher,

and a subscriber. First, a publisher sends a message to a connected broker. The broker then

distributes the data to any subscribers that have subscribed to that topic. Conversely, subscribers

who have not subscribed to that topic do not receive the data [12, 13].

As shown in Table 2.1, the main difference between CoAP and MQTT is in the

communication model. While CoAP is a request-response model such as HTTP, MQTT is a

publish-subscribe model, in which publishers, subscribers, and brokers handle topics in the

middle of the process. For CoAP, the observe extension [11] can support the publish-subscribe

model, but the scalability extension is limited because there are no factors like that in MQTT. In

addition, CoAP messages are delivered over UDP, while MQTT messages are delivered over

TCP connections. Accordingly, CoAP based on UDP cannot provide security using SSL/TLS.

Instead, CoAP provides security through DTLS that provides the same level of security as TLS

but ensures data transfer over UDP. Both TLS and DTLS use a method of exchanging data by

generating and exchanging keys while performing a handshake process by asymmetric key

encryption and then using the generated key for symmetric key encryption. CoAP devices with

DTLS generally support RSA or ECC encryption algorithms for key generation and exchange. In

addition, it supports AES as an encryption algorithm for data transmission using the generated

key.

Table 2.1 Comparison between MQTT and CoAP

CoAP MQTT

Protocol UDP TCP

Communication One-to-one (Response-Request)

Many-to-many (Publish-Subscribe)

Complexity More Complex Simple

Message Size Large (Text-based Status)

Small (2-byte Subscribe ID)

Encryption DTLS SSL based on TCP

RESTful Yes No

Functions Response-Request or Need Broker to handle data

On the other hand, MQTT provides user authentication via ID/Password for connections

with brokers. But the initial request message is plaintext, unencrypted. For more reliable

security, MQTT needs a secure authentication method.

2.3 Recent IoT Security Trends

As the IoT market has grown, but the IoT security failures could make serious results, the

study in IoT security is of paramount significance. In recent academic research, many papers

related to security issues for IoT systems have been published. The challenges for IoT security

mitigation, which consider IoT environments such as physical coupling, heterogeneity, resource

constraints, privacy, large scale, and lack of security consideration, vary widely [14]. Noor et al.

surveyed the research trends in IoT security between 2016 and 2018 and found that

authentication is currently still the most popular security mitigation (60%) to grant access to the

user at the application layer and also give access to the device in the IoT network as shown in

Figure 2.3 [15]. Also, Nandy et al. surveyed various authentication mechanisms in IoT. They

found that most of the research focuses on IoT security, authentication protocols, and IoT attack

models, but a wide range of robust IoT authentication protocols are required to provide better

IoT service for end users [16].

Figure 2.3 Publication from Elsevier, IEEE, Hindawi, and Springer from 2016 to 2018

2.3.1 Authentication and Authorization

Authentication is to verify the identity of a user, process, or device, often as a prerequisite

to allowing access to resources in an information system. Authorization is to determine what

users can do within the application and what data they have access to [17]. There are two ways -

Vertical Authorization and Horizontal Authorization. For example, an Access Control List

(ACL) allows users to configure which resources can be accessed after authentication at any

level after access.

Nandy et al. also found the recent research trends on Authentication for IoT networks.

The paper explained most of the authentication research focuses on lightweight mechanisms.

Moreover, mutual authentication and multi-factor are significant keys for IoT authentication

protocol, as shown in Figure 2.4 [16]. Thus, our proposed protocol is developed, taking these

factors into account.

Figure 2.4 Research Trends on Authentication taken from [18]

The ways to authenticate are what you know (i.e., Password), what you have (i.e., Token

Keys), and what you are (i.e., Scanned Body part, Fingerprint). Otherwise, the ways to authorize

are Token-based, Role-based Access Control (RBAC), and Access Control List (ACL).

Recently, as a powerful authentication method, multi-factor authentication (MFA) is suggested,

which combines two different ways of authentication (i.e., Password and Token) to provide more

robust security when providing identity [18].

2.4 DNS for IoT Network

2.4.1 DNS benefits for IoT Network

DNS provides a human-understandable domain name for IoT addressing. (e.g., Apple -

Bonjour based on mDNS). With DNS, users can utilize IoT addressing services with convenient

domain names for IoT devices. But, currently, mDNS provides only local service with zero-

configuration. If users want to use IoT services out of the network boundary, IoT networks need

global DNS service for utilization. Also, Domain names for IoT devices can be implemented for

an IoT location-based service. Current IoT name addressing protocol based on UID and serial

number [19] only supports the name lists. If users have numerous devices on the network, it

becomes a burden to know the device’s location and identifier. Thus, to efficiently manage and

reference multiple IoT devices, it is recommended to adapt DNS name autoconfiguration on each

IoT device without any intervention [6].

2.4.2 mDNS

The mDNS protocol, released by RFC 6762 [50], is a DNS service to resolve a hostname

to IP address in small networks without a local name server. Unlike a conventional unicast DNS,

the mDNS uses the IP multicast UDP packet. Thus, every node on the network receives the IP

packets to identify a hostname.

With the advent of IPv6 and the increasing use of numerous embedded devices (e.g., IoT

devices), the complicated procedure of registering IP addresses in DNS has become inconvenient

for small network configurations. mDNS was implemented by the Apple Bonjour [50] and

Microsoft Link-local Multicast Name Resolution (LLMNR) to solve the problems [51]. Initially,

mDNS searched for printer devices within the network but later expanded to the ability to

resolve hostnames.

Figure 2.5 mDNS Architecture

Figure 2.5 describes how mDNS works with IP multicast UDP packets.

(1) Device #1 requests the IP address of Device #2 to all devices within the network.

(2) Device #2 responses the own IP address (172.0.1.15) to all devices within the

network.

When the device sends a response, it sends its own information, such as hostname, IP

address, etc. All hosts on a multicast channel in the same network receive this information and

update it in their cache.

The significant benefits of mDNS are zero configuration and no infrastructure. It is

available without conventional DNS settings and does not require a local name server. In

addition, users can connect and use devices in the network more conveniently because access to

devices is intuitive.

mDNS makes it easier to configure networks in the home or small business. However,

there are security issues compared to the efficiency of mDNS. First, if mDNS is exposed to the

Internet, an attacker can easily collect information. The mDNS packet itself has no security and

can be used for hacker attacks (e.g., DDoS attacks) because anyone in the same network can

easily obtain the information. And since mDNS is also a UDP-based protocol, it can be

vulnerable to amplification attacks using the mDNS queries. Spoofing attacks on target IP

addresses can exhaust the device’s resource due to overwhelming the mDNS response.

2.4.3 DNSNA (DNS Name Autoconfiguration)

DNSNA is designed to provide effective DNS name configuration for many IoT devices

and follows the Internet Engineering Task Force (IETF) [6]. DNSNA uses the DNS option of

Router Advertisement (RA) or DHCPv6 for IPv6 Neighbor Discovery (ND). Once IoT devices

obtain a DNS search list, it automatically configures DNS names using DNS search lists and

device-specific information and then requests a router on the same subnet to register DNS

names. The router then requests the DNS server to register the new DNS name. DNSNA also

provides a new DNS name format consisting of unique id, Object Identifier (OID), location, and

domain name: “unique_id” is created by the IoT device automatically based on the RA. “object

identifier (OID)” is a standard ID of IoT devices [20]. OID consists of M2M (Machine to

Machine) node indication ID, manufacturer ID, model ID, and serial number ID. “location” has

physical location information about where IoT devices are installed. “domain name” is a DNS

name to identify the network of which the IoT is part.

Figure 2.6 DNSNA Name Format

DNSNA, however, was developed without consideration of authentication for users and

IoT devices. An attacker can exploit vulnerabilities in the DNS name collection step from a

router to easily register IoT devices illegally. These malicious IoT devices can distribute

malware to internal networks and intercept information from other devices within the network.

2.4.4 SDNSNA (Secure DNS Name Autoconfiguration)

SDNSNA was developed to overcome security vulnerabilities of DNSNA through NFC-

based authentication [7]. First, an administrator’s smartphone requests authentication

information to the Authentication Server (AS) supported by the IoT device manufacturer. AS

then generates a key pair consisting of a signing key and a verification key and then responds

with these keys. Then, the smartphone sends the signing key to the IoT device via NFC. After

receiving the signing key, the IoT device will make a digital signature for an NI reply to register

its DNS name. SDNSNA, nevertheless, still has security issues, such as:

(1) Administrator Authentication: Methods to authenticate an administrator are

required. Attackers could attempt to register malicious IoT devices into the

network as malicious administrators.

(2) NFC Protection: NFC communication is not very secure. Attackers may attempt

to distribute malicious keys via NFC.

(3) Key Management: Because IoT devices are very constrained, credentials in IoT

devices could easily be compromised or disclosed.

Figure 2.7 SDNSNA System Configuration

2.4.5 Is it efficient for IoT to adapt DNS?

In enterprise IoT networks, there are numerous devices for automated systems and

continue to receive data from devices. For the efficiency of many users in enterprise networks,

DNS can support convenient device addressing and location information through the device's

domain. DNS in IoT networks makes it easier for people to remember names that numbers for

things they need to reference, and indirection allows easy reassignment without impacting users.

Therefore, the efficiency is much greater than the cost of a DNS system.

However, in smart home networks, DNS system is costly compared to efficiency due to

the network environment of small devices and small areas. Also, Smart Home does not need a

globally accessible domain name per device because IoT devices have unique own address

configuration, local information, unique ID, and subscribe ID [35]. For instance, Google IoT

Core has its own addressing mechanism, and the MQTT broker can address the specific devices

using the global ID. Thus, Smart Home does not require DNS name configuration in terms of

efficiency.

LoRaWAN (Long-Range Wide Area Network) is a networking protocol based on the

LoRa radio modulation technique that provides low-power, low-data rate communication over a

wide range of network area [113]. In the LoRaWAN network structure, end devices connect with

a gateway that sends the data to a globally distributed IoT service server. Thus, LoRaWAN

addressing is an integral part of optimal routing between end devices and servers. LoRaWAN

has two identifiers for the addresses of devices [113]. 1) DevEUI is assigned by the manufacturer

as a unique, static ID of 64 bits for individual devices. 2) DevAddr is a dynamic and non-unique

32-bit device address. Of the 32 bits, 7 bits are fixed by the LoRaWAN provider, and 25 bits can

be assigned to the device by the network server. LoRaWAN was designed for the centralized

architecture and network server to address devices and gateways with the two identifiers. Thus,

DNS is not required.

2.5 OAuth 2.0 for IoT network

OAuth is an open standard authorization protocol designed to allow clients to access

limited resources under user control without providing user credentials [21]. OAuth 2.0 can be

seen as simply obtaining certification and authority and an industry-standard protocol that can be

authorized in various platform environments through authentication by trusted third parties.

The OAuth 2.0 framework consists of the following four parts, as shown in Figure 2.8:

(1) A resource owner is a user who has the resource or personal information in

third-party applications (e.g., Google, Facebook, etc.) and wants to use the

services provided by the client.

(2) A client is an application that uses OAuth 2.0 to implement the third-party

log-in function.

(3) A resource server is a server that has users’ personal information and

resource. The server can get resource owners’ resources with the access token

issued by Authorization Server.

(4) An authorization server is a server that grants permission to be used for

authentication. The user can enter ID and Password to this server to obtain the

authorization code. The Client can receive the access token from the

authorization server using the authorization code.

Figure 2.8 OAuth 2.0 Protocol Flow

Without consideration of any user authorization process, applications are developed

through OAuth 2.0 based on trusted third-party applications. Figure 2.9 explain the fundamental

advanced OAuth 2.0 framework for IoT network. Cirani et al. proposed an OAuth-based

authorization service architecture in IoT scenarios [22]. This architecture is developed to provide

an authorization framework based on an external OAuth-based Authorization Service (OAS).

Also, Echeverria et al. presented Authentication and Authorization for Constrained

Environments (ACE), based on an IETF proposal [23]. The ACE is designed to provide a

standardized solution for authentication and authorization of IoT devices by extending OAuth

2.0. These authentication protocols are suitable to control access to restricted resources.

Figure 2.9 OAuth 2.0 Framework for IoT Network

However, according to the RFC 6819 [24], OAuth 2.0 has possible security threats to

issuing tokens for users. The primary issue is about obtaining user credentials. The attacker could

try to impersonate the valid user using the “client_id” to target a replay attack while refreshing

the token or obtaining tokens. The risk of exposing user credentials can result in severe security

damage. In addition, ID / Password could be exposed through malicious applications such as a

phishing attack [24]. Therefore, flexible and secure authentication and authorization protocols

for users and services should be required.

2.6 Kerberos v5 for IoT network

The Kerberos v5 protocol is a ticket-based authentication and authorization protocol used

by users sending requests on unsecured network environments and servers receiving requests to

ensure each other’s reliability [25]. In particular, Kerberos protects against exposure of important

information, such as user credentials. Kerberos also provides server-client-based robust

authentication through Authentication Server (AS) for authorized users and Ticket-Granting

Server (TGS) for authorized services, using a Key Distribution Center (KDC) as shown in Figure

2.10 [26].

Figure 2.10 Kerberos v5 Framework

Kerberos is suitable as an authentication method for numerous users in IoT network

environments because user tickets, as a user credential, can be protected by timestamp and secret

key encryption even when the tickets are exposed.

Also, Kerberos provides protection against man-in-the-middle (MITM) attacks [26].

Since Kerberos performs mutual authentication under KDC control, by supporting not only the

end user authentication but also the service authorization, MITM attacks are precluded.

Therefore, it is expected that adapting the Kerberos into IoT has the advantage of protecting

against MITM attacks in IoT networks. However, Kerberos has limitations. First, the AS and

TGS in the KDC must be implemented in the network, and the client and the servers must have

the pairing key in advance. In this thesis, our protocol integrates the benefits of OAuth 2.0 and

Kerberos v5 to provide robust authentication and authorization for the overall IoT network.

CHAPTER 3

IAuth+ for Enterprise IoT Network

Our proposed protocol provides a new authentication and authorization mechanism for

the Enterprise IoT network. In this chapter, we first define why we need a standard

authentication protocol in the Enterprise IoT network. And then, we introduce our protocol’s

architecture and how to work in this specific network environment. Especially with the benefits

of prominent features in Enterprise IoT network, IAuth+ can be implemented with the expended

OAuth 2.0 and Kerberos v5 for robust, secure authentication for IoT components.

3.1 Motivation: Enterprise Security Issues

Enterprise IoT is a system that connects properties and devices with end applications and

automates all the activities of Enterprises such as factories, companies, and universities by

embedding devices without or with less intervention from humans [27]. Many industries,

universities, and companies utilize Smart IoT systems for automatic productive activities based

on their network infrastructure. However, Enterprise IoT does not have any standard protocol for

their own IoT network with secure mechanisms, and they only rely on other Enterprise IoT

service companies, such as - Google, IBM, and Cisco. Thus, our protocol proposes a first

standard authentication and authorization protocol for Enterprise. Moreover, DNSNA can be

adapted to Enterprise IoT with our protocol for efficient IoT device name addressing.

3.2 IAuth+ Architecture for Enterprise IoT Network

3.2.1 Entities

IAuth+ consists of administrator, users, router, gateway, IoT devices, authorization server

in OAuth 2.0, DNS server, authentication server and ticket-granting server in KDC of Kerberos

v5, and IoT service server. The description of these entities is as follow:

• An administrator registers and manages IoT devices.

• Users utilize IoT devices inside or outside the network.

• A router connects gateways to the Internet, provides IPv6, and manages DNS

Search List.

• A gateway connects IoT devices to a router. (e.g., Wi-Fi, LTE, Bluetooth, etc.).

• IoT devices provide QR codes and can generate DNS names and validate access

tokens.

• Authorization Server in OAuth 2.0 (AS) authenticates Admin and issues Access

Token. This is a part of OAuth2.0.

• A DNS server supports DNS name registration and resolution.

• Authentication Server in KDC (AS-KDC) authenticates a user with ID/PW and

issues Ticket-Granting Ticket (TGT) as a part of Kerberos v5.

• Ticket-Granting Server in KDC (TGS-KDC) validates TGT and issues

Service-Granting Ticket (SGT) as a part of Kerberos v5.

• A IoT service server provides a service with IoT data to users. The server

exchanges data with IoT devices and provides that data to users.

3.2.2 Architecture

IAuth+ follows a fundamental IoT network framework. Figure 3.1 shows the architecture

of IAuth+. First, IoT devices are connected to the gateway by an administrator responsible for

installing and connecting IoT devices to the network. IoT devices are connected to wide area

networks via gateways or routers, authentication servers and DNS platforms for authentication

and authorization, and DNS name services. Users should also be connected to this authentication

server and DNS platform to utilize IoT services. This authentication and platform are divided

according to the functionality of each stage. Our proposed protocol provides secure

authentication and DNS name services across IoT networks, from the setup of IoT devices to the

utilization of users.

Figure 3.1 IAuth+ Architecture for Enterprise IoT network

3.3 IAuth+ Three-Step Solution

The IAuth+ protocol proceeds sequentially with a three-step solution: First, the “Pairing

Step” securely registers IoT devices and establishes a secure channel between the administrator

and the device. In this step, the concept of OAuth 2.0 is extended and applied to IAuth+ for

secure IoT device registration and authentication by administrators. Next, IoT devices are

securely registered to the network to perform DNS name autoconfiguration, called the “DNS

Name Autoconfiguration Step.” Finally, the “Utilization Step” authenticates users' utilization of

IoT devices. In this step, we apply the expanded Kerberosv5 developed for IoT environments for

multiple user authentication. The proposed protocol’s three-step solution provides the following

benefits:

• In IoT device pairing, the administrator securely requests IoT devices and

administrator authentication through a QR code provided by the manufacturer. A

secure, shared symmetric key is provided via the QR code, thus providing strong

authentication without requiring assistance from the IoT devices.

• Since DNS name autoconfiguration proceeds after secure device authentication,

security vulnerabilities can be mitigated.

• By issuing tickets with controlled access permission and usage time for each user,

a safe user access control can be provided.

3.3.1 Step 1: Pairing

This step aims to authenticate and register IoT devices in the network, and for the

administrator to be granted administrative rights to IoT devices. The authentication mechanism

refers to and extends the ACE model [23], which is based on OAuth 2.0. In this step, devices

initially boot into “Pairing Mode” and wait for device registration. After this step, devices switch

to “Operating Mode” to provide service. If rebooted, devices return to “Pairing Mode” again. An

administrator scans a QR code with the IoT device and obtains information about a Pre-Shared

Key (PSK), IoT device ID, and AS. Because it includes credentials for an administrator, the QR

code must be physically protected by the administrator. Usage of the QR code has the advantage

of having sufficient capacity, and it does not impose any workload on IoT devices [16]. In

addition, an administrator is granted control of the IoT devices via Access Tokens from the AS.

As shown in Figure 3.2, the procedure for this step is as follows:

(1) The admin scans the QR code of the IoT device with a camera.

(2) The admin obtains a 128-bit PSK from the QR code.

(3) The admin requests an Access Token from the AS to access the IoT device using

the ID and PSK. The request message is encrypted and signed with the PSK.

(4) The AS validates the request, and if valid, the AS generates an Access Token for

the device ID.

(5) The AS sends the Access Token to the admin.

(6) The admin requests protected resources from the IoT device using the Access

Token.

(7) The IoT device validates the Access Token and responds to the admin if valid.

Figure 3.2 Pairing Step Message Flow

3.3.2 Step 2: DNS Name Autoconfiguration

The goal of this step is that IoT devices automatically generate their name and register

the DNS name into a DNS Server with a DNS Search List (DSL) provided from the network

after the “Pairing Step.” The DNS mechanism for this step uses the framework of DNSNA [6]

discussed in Chapter 2. However, the security vulnerability of DNSNA is mitigated by secure

channels provided by the “Pairing Step.” Figure 3.3 shows the message flow in the “DNS Name

Autoconfiguration Step.” The procedure for this step is as follows:

(1) The router periodically distributes DNS search lists (DSLs). Devices inside the

network receive a DSL from the router [28].

(2) The router collects DNS names by a NI query [29].

(3) The IoT Device automatically generates its own DNS name using a suffix from

the Model ID, OID, location, and DSL.

(4) The IoT device sends its DNS name and IPv6 address to the router in response to

the NI query.

(5) The router validates NI responses (DNS names and IP addresses).

(6) If a valid NI response, the router requests DNS dynamic update [30] to the DNS

server.

(7) The DNS server registers the DNS name and IP address with the DNS zone file.

(8) After registration, the DNS server responds to the router with the results.

(9) The router updates the DSL with results.

(10) The router deploys the updated DSL. All these processes assume that the IoT

device contains a DNS name generation algorithm based on IPv6.

Figure 3.3 DNS Name Autoconfiguration Step Message Flow

3.3.3 Step 2: Utilization

This step aims to authorize users to utilize IoT devices after the “DNS Name

Autoconfiguration Step”. From the previous two stages, secure channels have been established,

and valid IoT devices have been registered in the network to provide services. However, a

standardized user authentication protocol should be required to obtain data from IoT devices. We

introduce an advanced Kerberos v5 to provide an authentication and authorization protocol

between users and IoT devices (IoT service server). First, IAuth+ utilizes Key Distribution

Centers (KDCs) to provide secure user authentication and service authentication. AS-KDC

validates users in the network, and TGS-KDC validates authorized users to utilize IoT services.

As shown in Figure 3.4, the procedure for this step is as follows:

(1) The user sends a request of TGT for utilizing IoT devices to AS-KDC with the

user’s ID.

(2) AS-KDC validates the user’s request.

(3) After verification, AS-KDC issues TGT and the user's session key, encrypts it

with the user’s symmetric key, and responds. TGT contains the user’s ID and

session key and is encrypted with a KDC symmetric key.

(4) The user requests SGT to TGS-KDC with TGT, Authenticator, and IoT device

information.

(5) TGS-KDC is decoded by the KDC symmetric key to verify TGT.

(6) After verification, TGS-KDC generates SGT, a session key between the user and

IoT service server; encrypts with the user’s session key; and responds. SGT

contains a user ID and a session key between the user and the IoT service server

and is encrypted with a symmetric key between TGS-KDC and the IoT service

server.

(7) Users request the use of IoT devices with information from SGT, Authenticator,

and IoT devices.

(8) IoT service server uses a symmetric key shared between TGS-KDC and IoT

service server to verify SGT.

(9) After verification, the IoT service server encrypts and sends a response message

to the user using the session key between the user and the IoT service server.

Figure 3.4 Utilization Step Message Flow

All of these processes assume that (1) users must register their IDs and PWs with AS-

KDC in advance, and (2) AS-KDC - TGS-KDC and TGS-KDC - IoT service servers must share

symmetric keys with each other.

3.4 Effectiveness

In this section, we explore the effectiveness of IAuth+ for the Enterprise IoT network

using the STRIDE model. This analysis demonstrates the effectiveness by examining how

IAuth+ mitigates potential threats.

3.4.1 STRIDE Model

We adapt the STRIDE model to analyze the threat model of IAuth+ for the Enterprise

IoT network as a tool of proof-of-concept [37]. STRIDE is a technique for classifying threats

corresponding to six factors by adding authentication, denial prevention, and authorization into

three fundamental elements of security: confidentiality, integrity, and availability. The model

helps to identify vulnerabilities and potential attack possibilities in applications. And

Repudiation and Denial of Service are out of the scope in this thesis.

Table 3.1 Six Factors of STRIDE Threat Model

Threat Definition Property

Spoofing Attackers impersonate authorized users Authentication

Tampering Attackers maliciously modifies internal data for exploitation Integrity

Repudiation Attackers deny malicious activities Non-repudiation

Information Disclosure Exposure to protected information Confidentiality

Denial of Service Attack based on reliable access to the service. (Called DDoS) Availability

Elevation of Privilege A limited user obtains the privileges of another user Authorization

Spoofing

The Spoofing factor is illegally accessing and then using another user’s authentication

information. Spoofing can be exploited in IoT networks for registering malicious IoT devices,

impersonating administrators, or camouflaging users. We adapted the Spoofing factor into our

protocol and analyzed the threat result:

(1) In the Pairing step, attackers can impersonate any administrator to register

malicious IoT devices into the network.

(2) In the DNS Name Autoconfiguration step, attackers can hijack/exploit any DNS

query of an IoT device to derive a malicious IP address.

(3) In the Utilization step, attackers can impersonate any user to gain unauthorized

access to IoT devices and obtain information.

IAuth+ can mitigate these potential threats as follows:

(1) Administrator reads a QR code that is physically protected and then gets PSK.

PSK encrypts the device register request from the administrator. AS validates the

request with PSK and responds to the administrator with the access token.

(2) After pairing mode, IoT devices are connected to the router. Router authenticates

the NI query of the paired IoT device through DNS dynamic update.

(3) In the Utilization step, users are already registered in AS-KDC with their ID and

PW. Thus, AS-KDC validates users’ requests using their ID/PW.

Tampering

The Tampering factor is a malicious modification and unauthorized change. Tampering

can be exploited in IoT networks to modify communication with illegal attempts and weak

authorization. We adapted the Tampering factor into our protocol and analyzed the threat result:

(1) In the Pairing step, attackers can modify data flow between an administrator and

AS to obtain unauthorized access to IoT devices or modify data flow between an

administrator and IoT devices to obtain unauthorized access to IoT devices.

(2) In the DNS name autoconfiguration step, attackers can modify data flow between

IoT devices and a DNS server to disrupt IoT DNS name service.

(3) In the Utilization step, attackers can modify data flow between users and IoT

devices (or IoT service servers) to obtain unauthorized data.

IAuth+ can mitigate these potential threats as follows:

(1) PSK encrypts the data flow between an administrator and AS provided from a QR

code. After verification by AS, the access token is issued. Moreover, the data is

protected by the access token from AS.

(2) After pairing mode, IoT devices are connected to the router. The router

authenticates the NI query of the paired IoT device through DNS dynamic update.

(3) In the expanded Kerberos v5 for IoT network, SGT protects the data flow

between users and IoT devices (or IoT service servers) for IoT service.

Information disclosure

The Information disclosure factor involves the exposure of information to individuals

who are not supposed to access it. Information disclosure can be exploited in IoT networks to

steal data from vulnerable subjects, such as IoT devices, administrators, and users. We adapted

the Information disclosure factor into our protocol and analyzed the threat result:

(1) Attackers can sniff data flow between an administrator and AS to disclose

credential data during the pairing step.

(2) Attackers can sniff data flow between an administrator and IoT devices to

disclose credential data during the pairing step.

(3) Attackers can sniff data flow between users and IoT devices to disclose credential

data during the service authorization.

IAuth+ can mitigate these potential threats as follows:

(1) The register request is encrypted by PSK provided from a QR code, which an

administrator physically protects. Thus, the data can be protected by secure QR

code protection.

(2) The data is authenticated by the access token from AS. Thus, the access token is

issued only for the valid administrator.

(3) Credential data and IoT services are protected by TGT and SGT, which Kerberos

manages. TGT guarantees the authenticated users, and SGT guarantees the

authorized service to the users.

Elevation of Privilege

In the Elevation of Privilege factor, unprivileged users gain privileged access to

compromise the system and effectively penetrate and become part of the trusted system.

Elevation of Privilege can be exploited in IoT networks to get credentials from administrators,

devices, and users. We adapted the Elevation of Privilege factor into our protocol and analyzed

the threat result:

(1) In the Pairing step, attackers could obtain a valid Access Token to elevate an

admin privilege to exploit IoT devices as botnets.

(2) In the Utilization step, attackers could obtain a valid TGT/SGT to elevate a user

privilege to exploit IoT data.

IAuth+ can mitigate these potential threats as follows:

(1) An administrator with PSK from a QR code should be authenticated by AS. The

access token for an administrator is issued by the trusted AS.

(2) AS-KDC and SGS-KDC issue a valid TGT/SGT, including the timestamp for

users to prevent reuse. Tickets are protected by session key and authenticator.

3.4.2 Benefits of IAuth+ for Enterprise IoT

IAuth+ presents a standard model for advanced authentication and authorization to

Enterprise IoT networks. With the benefits of Enterprise security infrastructure, IAuth+ allows

these environments to mitigate the challenges of various IoT security attacks by providing strong

authentication and authorization procedures developed by expanded OAuth 2.0 and Kerberos v5.

Specific benefits of IAuth+ are as follows:

(1) IAuth+ provides overall authentication and authorization based on the Enterprise

infrastructure from secure devices registration to user utilization.

(2) The Paring step can be implemented for administrator authentication and

authorization of device registration using a QR code and access token.

(3) DNS Name Autoconfiguration Step can be implemented under secure

communication after the Pairing step.

(4) Utilization Step with advanced Kerberos can be implemented for user

authentication and service authorization using tickets from trust KDC.

3.5 Analysis

As we discussed in Section 3.1, there is no standard authentication protocol for Enterprise

IoT. Thus, we analyze the capacity of IAuth+ by comparison with SDNSNA.

3.5.1 Comparison with SDNSNA

As we discussed in section 2.4.4, SDNSNA [7] was proposed to improve security

vulnerabilities in DNSNA using NFC-based authentication. However, as discussed in section

2.4.3, SDNSNA has security issues when applied to real-world environments for secure device

authentication. The administrator’s smartphone receives the signing key from the authentication

server and distributes the signing key to IoT devices through NFC. However, SDNSNA did not

mention how to authenticate a device using the signing key and the authentication server and

negotiate a key between the device and the server. Compared with SDNSNA, IAuth+ can

provide a specific authentication mechanism with the legacy scheme of DNSNA and provide a

secure DNS naming service to IoT devices. Table 3.2 shows the comparison with SDNSNA.

Table 3.2 Comparison with SDNSNA

SDNSNA IAuth+

Authentication Method

NFC-based PSK from the QR code

Administrator Authorization

No Yes (Access token)

Infrastructure Required

DNS and IPv6 Network NFC-based Device

DNS and IPv6 Network Authorization Server in OAuth KDC in Kerberos

Human Effort Tag device using NFC Scan the QR code

Key Management Key distribution by NFC PSK

SDNSNA provides an authentication protocol based on NFC. A user receives information

from the device using a smartphone and delivers a signature key through NFC communication.

However, NFC-based communication has a severe vulnerability that can be very vulnerable to

attackers with physical access. Anyone can tag the devices using the NFC-based smartphone and

impersonate the device as the valid user. Therefore, IAuth+ provides device authentication and

administrator authorization by receiving device credentials through the QR code included in the

device. At this time, the QR code should be physically protected. Since both protocols are based

on the DNSNA mechanism, DNS and IPv6 network infrastructure should be required, and

IAuth+ additionally requires Authorization Server in OAuth and Key Distribution Center (KDC)

in Kerberos.

CHAPTER 4

IAuth+ for Smart Home Network

Our proposed protocol provides a new authentication and authorization mechanism for

smart homes. In this chapter, we first define why we need an advanced authentication protocol in

smart home networks. And then, we introduce our protocol’s architecture and how to work in

this specific network environment. Especially, we attempt to overcome the constrained network

features in smart homes. IAuth+ includes a new lightweight authentication and authorization for

users and services with the benefits of expanded Kerberos v.5.

4.1 Motivation: Smart Home Security Issues

A smart home refers to a convenient home control where devices can be automatically

controlled remotely from anywhere with an Internet connection using a mobile or other

networked device [31]. A smart home is one of the most popular services based on the IoT

network. The devices in Smart Home can be set up through wireless or hardwired systems and

provide homeowners with convenience and cost savings. However, there are security issues since

Smart home does not have any infrastructure for security and only relies on ISP. Thus, security

risks and bugs continue to plague vendors and users of smart home technology. Specific security

vulnerabilities are the following [32]:

(1) Outdated IoT devices: out-of-date or legacy version firmware

(2) Insecure web application and services authentication

(3) Weak Passwords: Top exploited a vulnerability in smart homes

(4) Open or Insecure network services: IoT vendors take open-source or insecure

firmware

(5) Off-brand and low capacity IoT devices: Not name-brand and cheaper devices

pose a security risk to privacy or information disclosure because of the lack of a

security system.

(6) Poor physical security: Need Secure Physical security infrastructure

Based on these vulnerabilities, potential attacks in smart homes are Man-In-The-Middle,

Data and Identity Theft, Device Hijacking, Denial of Service(malware), and Brute Force

password attack [33]. Major enterprise platforms have been released to mitigate security issues in

smart home networks - Google IoT Core, AWS IoT, IBM Watson, and Azure IoT HUB [34].

4.1.1 Google IoT Core

Google IoT Core is a representative enterprise IoT platform to support the overall IoT

network system, a service to connect, manage, and ingest data from millions of globally

dispersed devices easily and securely. IoT core collects, processes, and analyzes IoT data in real-

time to support improved operational efficiency provided by Google [35]. The main security

features include a device activation on Google’s network infrastructure based on MQTT (MQ

Telemetry Transport) and HTTP and Per-device public/private key authentication using JWT

(JSON Web Token) as described by Figure 2. However, IoT Core still has potential weaknesses;

MQTT protocol's possible security issues [36], the device self-activation using JWT signature,

and the dependency of Google IoT platform and infrastructure. MQTT is a standard messaging

protocol for IoT networks developed by OASIS [36]. While MQTT provides lightweight and

efficient client messages, as the recent MQTT version 3.1.1 pointed out, the communication

between a publisher (device) and subscribers (applications) / MQTT brokers could be intercepted

or disclosed by attackers using a weak authentication mechanism. IoT Core adapts JWT

signatures based on MQTT messages to improve MQTT's weak authentication, but due to a

fundamental problem in IoT networks, the device creates its own credentials for authentication.

JWT also has a security issue about information disclosure. The header and payload contain

crucial information such as a JWT type, an identity (device ID), and token expiration time [111]

and are just encoded by a hash algorithm. Thus, attackers could easily intercept or sniff the

message and exploit the information. In addition, the high dependence of enterprise IoT

platforms evolves into centralized systems, so one platform can affect the entire IoT system and

pose heterogeneity of the IoT network environment.

Our proposed protocol mitigates these issues through trust homeowner’s intervention

using a QR code attached to the device as the root of trust for authentication, which identifies the

device and allows its secure configuration using symmetric key cryptography by owner’s

intervention. Also, we propose a new lightweight authentication and authorization based on

Kerberos v5 without the infrastructure to suit the characteristics of the smart home network

environment.

Figure 4.1 Google IoT Core device activation [35]

4.2 IAuth+ Architecture for Smart Home

4.2.1 Entities

IAuth+ consists of an owner, users, a router, a gateway, IoT devices, and authorization

server in OAuth 2.0, IoT service servers. The description of the entities is as follow:

• An owner registers and manages IoT devices. Additionally, KDC in Kerberos

runs on the homeowner's API (e.g., IoT Application).

• Users utilize IoT devices inside and outside the network.

• A router connects gateways to the Internet.

• A gateway connects IoT devices to a router. (e.g., Wi-Fi, LTE, Bluetooth, etc.).

• IoT devices provide QR codes and can generate DNS names and validate access

tokens.

• Authorization server in OAuth 2.0 (AS) authenticates an owner and issues

Access Token, as a part of OAuth2.0.

• IoT service servers provides a service with IoT data to users. The server

exchanges data with IoT devices and provides that data to users.

4.2.2 Architecture

IAuth+ follows a fundamental Smart Home IoT network framework. Figure 4.2 shows

the architecture of IAuth+. First, IoT devices are connected to the gateway at home by an owner

responsible for installing and connecting IoT devices to the network. IoT devices are connected

to wide area networks via gateways - routers. Users should also be with the owner at home to

authorize their request for IoT utilization. The authentication and platform are divided according

to the functionality of each stage. Our protocol provides secure authentication and authorization

across IoT networks, from the setup of IoT devices to users’ utilization.

Figure 4.2 IAuth+ Architecture for Smart Home

4.3 IAuth+ Two-Step Solution

The IAuth+ protocol proceeds sequentially with a two-step solution: First, the “Pairing

Step” securely registers IoT devices and establishes a secure channel between the owner and the

device. In this step, the concept of OAuth 2.0 is extended and applied to IAuth+ for secure IoT

device registration and authentication by an owner. Next, the “Utilization Step” authenticates

users' utilization of IoT devices. We apply the expanded Kerberosv5 developed for IoT

environments for multiple user authentication. The proposed protocol’s two-step solution

provides the following benefits:

(1) In IoT device pairing, an owner securely requests IoT devices and owner

authentication through a QR code provided by a manufacturer. A secure shared

symmetric key is provided via the QR code, thus providing strong authentication

without requiring assistance from the IoT devices.

(2) By issuing tickets with controlled access permission and usage time for each user,

a valid user access control can be provided under an owner.

4.3.1 Step 1: Pairing

This step aims to authenticate and register IoT devices in the network, and for the owner

to be granted administrative rights to IoT devices. The authentication mechanism refers to and

extends the ACE model [23], which is based on OAuth 2.0. Devices initially boot into “Pairing

Mode” and wait for device registration. After this step, devices switch to “Operating Mode” to

provide service. If rebooted, devices return to “Pairing Mode” again. An owner scans a QR code

with the IoT device and obtains information about a Pre-Shared Key (PSK), IoT device ID, and

AS. Because it includes credentials for an owner, the QR code must be physically protected by

the owner. Usage of the QR code has the advantage of having sufficient capacity, and it does not

impose any workload on IoT devices [23]. In addition, an owner is granted control of the IoT

devices via Access Tokens from the AS. As shown in Figure 4.3, the procedure for this step is as

follows:

(1) The owner scans the QR code of the IoT device with a smartphone camera.

(2) The owner obtains a 128-bit PSK from the QR code.

(3) The owner requests an Access Token from the AS to access the IoT device using

ID and PSK. The request message is encrypted and signed with PSK.

(4) The AS validates the request, and if valid, the AS generates an access token for

the device ID.

(5) The AS sends the access token to the owner.

(6) The owner requests protected resources from the IoT device using the access

token.

(7) The IoT device validates the access token and responds to the owner if valid.

Figure 4.3 Pairing Step Message Flow

4.3.2 Step 2: Utilization

This step aims to authorize users to utilize IoT devices after the “Pairing Step”. Secure

channels have been established and valid IoT devices have been registered in the network to

provide services. However, a standardized user authentication protocol should be required to

obtain data from IoT devices. We introduce a lightweight authentication and authorization

protocol based on an advanced Kerberos v5 between users and IoT devices. First, IAuth+ utilizes

the owner as KDC to authenticate valid users in the same Smart Home using a random

authentication code. Second, IAuth+ adds a service authorization process into the IoT service

server as a ticket-granting server in KDC. As shown in Figure 4.4, the procedure for this step is

as follows:

(1) The owner requests a utilization of an IoT device with Owner ID for a user to the

IoT service server.

(2) After verification, the IoT service server generates a random authentication code.

The authentication code replaces the role of TGT and should be protected.

(3) The IoT service server responds to the authentication code encrypted with PSK to

the owner.

(4) The owner decrypts the response and delivers the authentication code directly to

the user.

(5) With the authentication code, the user generates Key KA.

(6) The user requests the utilization of the IoT device with SGT, including a user ID,

timestamp, and IoT device info, encrypted with KA. This request replaces the role

of SGT.

(7) The IoT service server uses a symmetric key generated with the authentication

code to verify SGT.

(8) After verification, the IoT service server encrypts and sends a response message

to the user, including the session key between the user and the IoT service server.

Figure 4.4 Utilization Step Message Flow

All processes assume that (1) the owner must have a secure connection with the IoT

service server after the Pairing step, and (2) the authentication code should be securely protected

and transmitted to the user directly.

4.4 Effectiveness

In this section, we explore the effectiveness of IAuth+ for Smart Home using the

STRIDE model. This analysis demonstrates the effectiveness by examining how IAuth+

mitigates potential threats.

4.4.1 STRIDE Model

We analyze the threat model of IAuth+ for smart home networks using the STRIDE

model as a tool of proof-of-concept [37]. STRIDE is a technique for classifying threats

corresponding to six factors by adding authentication, denial prevention, and authorization into

three fundamental elements of security: confidentiality, integrity, and availability. The model

helps to identify vulnerabilities and potential attack possibilities in applications. And

Repudiation and Denial of Service are out of the scope in this thesis.

Spoofing

The Spoofing factor is illegally accessing and then using another user’s authentication

information. Spoofing can be exploited in IoT networks for registering malicious IoT devices,

impersonating administrators, or camouflaging users. We adapted the Spoofing factor into our

protocol and analyzed the threat result:

(1) In the Pairing step, attackers can impersonate any homeowner to register

malicious IoT devices into the network.

(2) In the Utilization step, attackers can impersonate any user to gain unauthorized

access to IoT devices and obtain information.

IAuth+ can mitigate these potential threats as follows:

(1) A homeowner reads a QR code that is physically protected and then gets PSK.

PSK encrypts the device register request from the homeowner. AS validates the

request with PSK and responds to the homeowner with the access token.

(2) In the Utilization step, users are authenticated by the homeowner directly, and the

homeowner gets the authentication code for users from the IoT service server.

Thus, the homeowner validates users’ requests of the utilization as home

members.

Tampering

The Tampering factor is a malicious modification and unauthorized change. Tampering

can be exploited in IoT networks to modify communication or data with illegal attempts and

weak authorization. We adapted the Tampering factor into our protocol and analyzed the threat

result:

(1) In the Pairing step, attackers can modify data flow between a homeowner and AS

to obtain unauthorized access to IoT devices or modify data flow between

administrator and IoT devices to obtain unauthorized access to IoT devices.

(2) In the Utilization step, attackers can modify data flow between users and IoT

devices (or IoT service servers) to obtain unauthorized data from IoT Service

Server.

IAuth+ can mitigate these potential threats as follows:

(1) The data flow between a homeowner and AS is encrypted by PSK provided from

a QR code. After verification by AS, the access token is issued. Moreover, the

data is protected by the access token from trusted AS.

(2) In the lightweight Kerberos v5 for a smart home, SGT protects the data flow

between users and IoT devices (or IoT service servers) for IoT service.

Information disclosure

The Information disclosure factor involves the exposure of information to individuals

who are not supposed to access it. Information disclosure can be exploited in IoT networks to

intercept data from vulnerable subjects, such as IoT devices, a homeowner, and users. We

adapted the Information disclosure factor into our protocol and analyzed the threat result:

(1) Attackers can sniff data flow between a homeowner and AS to disclose credential

data during the Pairing step.

(2) Attackers can sniff data flow between a homeowner and IoT devices to disclose

credential data during the Pairing step.

(3) Attackers can sniff data flow between users and IoT devices to disclose credential

data during the service authorization.

IAuth+ can mitigate these potential threats as follows:

(1) The register request is encrypted by PSK provided from a QR code, which a

homeowner physically protects. Thus, the data can be protected by secure QR

code protection.

(2) The data is authenticated by the access token from trusted AS. Thus, the access

token is issued only for the valid homeowner.

(3) Credential data and IoT services are protected by TGT and SGT, which Kerberos

manages. TGT guarantees the authenticated users, and SGT guarantees the

authorized service to the users.

Elevation of Privilege

In the Elevation of Privilege factor, unprivileged users gain privileged access to

compromise the system and effectively penetrate and become part of the trusted system.

Elevation of Privilege can be exploited in IoT networks to get credentials from a homeowner,

devices, and users. We adapted the Elevation of Privilege factor into our protocol and analyzed

the threat result:

(1) In the Pairing step, attackers could obtain a valid access token to elevate an admin

privilege to exploit IoT devices as botnets.

(2) In the Utilization step, attackers could obtain a valid TGT/SGT to elevate a user

privilege to exploit IoT data.

IAuth+ can mitigate these potential threats as follows:

(1) A homeowner should be authenticated by PSK from a QR code. The access token

for the homeowner is issued by trusted AS.

(2) AS-KDC and SGS-KDC issue a valid TGT/SGT, including the timestamp for

users to prevent reuse. Tickets are protected by session key and authenticator.

4.4.2 Benefits of IAuth+ for Smart Home

IAuth+ presents a standard model for advanced authentication and authorization to a

smart home. With smart home’s two major network features which are limited network

infrastructure and dependence on network service providers, IAuth+ should be developed by

lightweight and flexible environments. In the Paring step, IAuth+, like Enterprise IoT networks,

can be provided the same support through expanded OAuth 2.0, which vendors manage.

However, since additional servers cannot be installed in the smart home environment, we

developed a new lightweight Utilization step based on Kerberos v5 with a replacement for

authentication server and ticket-granting server and simple authorization procedures. Thus,

IAuth+ allows these environments to overcome the challenges of Smart Home limitation and

mitigate various IoT security attacks by providing strong authentication and authorization

procedures developed by expanded OAuth 2.0 and Kerberos v5. Specific benefits of IAuth+ are

as follows:

(1) IAuth+ provides overall authentication and authorization without any security

infrastructure from secure devices registration to user’s utilization.

(2) The Paring step with advanced OAuth 2.0 can be implemented for homeowner

authentication and authorization of device registration using a QR code and an

access token.

(3) The Utilization step with advanced Kerberos can be implemented for user

authentication and service authorization using tickets from trusted KDC.

4.5 Analysis and Evaluation

We analyze the capacity of IAuth+ using a comparison of Google IoT Core for Smart

Home networks. Additionally, as proof-of the-concept, we compare and evaluate with Google

IoT Core for authentication security.

4.5.1 Comparison with Google IoT Core

As we discussed in section 4.1.1, Google IoT Core [35] is a representative enterprise IoT

platform to support the overall IoT network system, a service to connect, manage, and ingest data

from millions of globally dispersed devices easily and securely. However, IoT core has security

issues: (1) MQTT and JWT vulnerability: Header and Payload are encoded by base64 hash

algorithm and not protected [111], (2) Device self-activation: Resource-constrained device self-

activation has limitations to protect the credentials, and (3) Service centralized to IoT Core:

Manufacture could provide service centralized to IoT Core. The security issues with IoT Core

would affect all IoT device connected to IoT Core. Also, enterprise IoT platforms could be one

of the targets for attackers.

Compared with IoT Core, IAuth+ can protect the request message encrypted by PSK for

verification, provide trusted homeowner intervention instead of device self-activation, and

propose independent authentication and authorization protocol for Smart Home. Table 4.1 shows

the comparison with Google IoT Core.

Table 4.1 Comparison with Google IoT Core

Google IoT Core IAuth+

Activation Method Device self-activation Trusted Homeowner Activation

Authentication method

JWT (Public header, payload)

PSK (All information encrypted)

Key Encryption Type Asymmetric Key Symmetric Key

Key Encryption Method RS256 / ES256

Various options depends on vendors

Infrastructure required

MQTT Bridge / Broker Device Manager Server Authentication Server

Authorization Server on OAuth Administrator API

Key distribution Vendor (directly) Vendor (directly)

Who verifies the request? Device Management System Authorization Server by Vendor

Workload for Authentication Yes (Create JWT on device) No (Install API on owner device)

Google IoT Core uses the authentication method of device self-activation based on JWT

with credentials stored by the provisioner without user intervention. However, in the initial

phase, the connection request message is transmitted after being encoded with base64url, not

protected. Thus, anyone can see the header and payload after decoding. Thus, with the disclosed

header and payload, an attacker can perform a replay attack. However, IAuth+ mitigates the

weakness of device self-activation through trusted homeowner activation and encryption of the

initial message by PSK. Since IoT Core is device-oriented, only two key encryption methods –

RSA256 and ES256 can be selected, but since IAuth+ is authenticated through the homeowner

and manufacturer’s authorization server, various essential encryption methods can be selected. In

addition, the intervention of the trusted homeowner instead of device authentication can reduce

the device's workload.

Also, IAuth+ reduces the dependence on many manufacturers' enterprise IoT platforms

and provides an independent and secure authentication and authorization protocol for overall IoT

procedure.

4.5.2 Comparison of Computation Time Cost for Device Activation

This section presents a performance comparison of the proposed protocol with Google

IoT Core [35]. Table 4.2 shows the notation for a time of computational cost comparison

required for device activation [35]. Additionally, Table 4.3 shows the result of the computation

cost compared with Google IoT Core based on the message flow.

Table 4.2 Notation for computation cost analysis [121, 127]

Notation Description Approximate execution time

Th Time for performing Hash Function ≈ 0.0023 ms

TEnc / TDec Time for performing a symmetric key encryption / decryption ≈ 0.0046 ms

TEnc-RSA256 / TDec-RSA256

Time for performing RSA256 encryption / decryption ≈ 0.35 ms / 0.96 ms

Table 4.3 Comparison of computation cost of our protocol with Google IoT Core

Google IoT Core (RSA256) IAuth+ (PSK)

Computation Cost of Device TEnc-RSA256 + TDec-RSA256 ≈ 1.31 ms 10 Th +2 (TEnc + TDec)

≈ 0.0598 ms

Computation Cost of Administrator -

TEnc + TDec + 4 Th ≈ 0.1058 ms

Total Computation Cost 1.31 ms 0.1656 ms

The computational cost is the time needed for a device activation to be transmitted from

end device to the server. The results of IAuth+ and Google IoT Core are shown in Figure 4.5,

considering the number of nodes. Since Google IoT Core chooses the RSA-256 cryptographic

algorithm, the computation cost has the highest cost [127]. Our protocol is much lower than

other protocols because the trusted administrator sends the encrypted Pairing Request message

instead of the device self-activation. Also, the cost is very low for the administrator as shown in

Table 4.2. Furthermore, the difference in the time cost increases, as the number of end-devices

increases.

Figure 4.5 Comparison of the computation cost in IAuth+ and Google IoT Core

CHAPTER 5

IAuth+ for LoRaWAN

Our proposed protocol supports a new authentication and authorization mechanism over

the existing LoRaWAN (Low-power Long-range Wide Area Network) [112]. This chapter first

explains LoRaWAN security issues and why LoRaWAN needs a robust standard authentication

protocol. And then, we introduce the architecture of our protocol and how to work in this specific

network environment. Especially, we attempt to mitigate LoRaWAN security vulnerabilities and

possible attacks with authentication issues. Also, IAuth+ includes the integrated device

activation with new authentication and authorization and expands user authentication and

services authorization with the benefits of a modified Kerberos v5.

5.1 LoRaWAN Security Review

LoRaWAN is an open standard protocol that allows resource-constrained small sensors

or devices with low battery to send messages up to tens of kilometers and survive for several

years even without a power source [112]. LoRaWAN is utilized in various network

environments, such as Smart City, Smart Home, Logistics, Agriculture, and Wildlife Monitoring.

The main features of LoRaWAN are the following [112]:

(1) Long Range: based on legacy cellular system (1km ~ up to 10km)

(2) Ultra-Low Power Operation: AA or coin-sized batteries

- Transmission Rate: 1 kbps ~ 21.9 kbps

- Payload: 65 bytes ~ 255 bytes

- Channel Bandwidth: 125, 250, 500 kHz

LoRaWAN consists of 4 parts in the network architecture as described in Figure 5.1. All

payloads in a transaction are securely encrypted by AES using a 128-bit key:

(1) End device: Collect data from a sensor with a low battery and frequency.

(2) Gateway: Receive packets from the end nodes and forward to a network server.

(3) Network Server: manage all LoRaWAN network systems.

(4) Application Server: receive data from the network server and provide service.

Figure 5.1 LoRaWAN Network Configuration

LoRaWAN consists of 4 specific servers as described in Figure 5.2: (1) Network Server

(NS), (2) Gateway Server (GS), (3) Join Server (JS), and (4) Application Server (AS). Network

Server is responsible for validating the message from the end device with Network Session Key

(NwkSKey) and selecting the servers/gateways for the uplink/downlink. Gateway Server is

responsible for managing secure gateway connections and configurations. Join Server is

responsible for key derivation and distribution based on the pre-programmed keys that are the

root of trust – Network Key (NwkKey) and Application Key (AppKey). Application Server

provided by the LoRaWAN provider is responsible for decrypting the data from the end device

with Application Session Key (AppSKey), sending the data to the cloud application servers (e.g.,

AWS, Google cloud), and encrypting the data sent to the end device with AppSKey. LoRaWAN

providers manage the servers, and the severs should be connected securely.

Figure 5.2 LoRaWAN Server Architecture

5.1.1 Key Derivation and Distribution

In LoRaWAN v1.1 [113], the two session keys are derived by the pre-programmed root

keys by manufacturers. The Join procedure is performed by end devices, NS, and JS as the

device activation. The key derivation is accomplished during the Join procedure. The

unencrypted Join-Request message includes MIC (Message Integrity Code) signed with

NwkKey, which is stored in end devices and JS. The Join-Request packet includes JoinEUI (an

8-byte global application ID), DevEUI (an 8-byte global end device ID), and DevNonce (2-byte

counter to prevent attacks that replay JoinEUI) [10,11]. NS responds to the end device with the

Join-Accept message when the Join Request message from the end device is accepted. The end

device and JS generate each of the session keys (NwkSKey and AppSKey) using the Join-Accept

message. Finally, JS distributes two session keys to NS and JS for encrypted communication

with the end device. Figure 5.3 describes the process.

Figure 5.3 LoRaWAN Key Derivation and Distribution

5.1.2 Device Activation

To join a LoRaWAN network, there are two procedures for device personalization and

activation: (1) over-the-air activation (OTAA) and (2) activation by personalization (ABP) [113].

OTAA dynamically generates session keys from root keys during the join procedure. By

contrast, ABP does not follow the join procedure; the session keys and related parameters are

provisioned in the end device by manufacturer. Thus, due to these static pre-installed keys, ABP

is a less secure activation method than OTAA and is suitable for a single network with the same

security. Since most LoRaWAN devices opt for more secure OTAA instead of limited ABP, our

proposed protocol focuses on the popular OTAA procedure. As shown in Figure 5.4, the

procedure of OTAA is as follows:

(1) The end device sends Join-Request message with MIC signed by NwkKey to the

network server. The Join-Request message has DevNonce, DevEUI, and JoinEUI

and is not encrypted.

(2) The network server sends the Join-Request message to the join server.

(3) The join server validates the request with the same NwkKey.

(4) The join server sends the Join-Ans message based on Join-Accept message to the

network server.

(5) The network server sends the Join-Accept message encrypted by NwkKey to the

end device. The Join-Accept message has DevAddr, JoinNonce, NetID, network

settings.

(6) The end device decrypts the Join-Accept message and generates NwkSKey and

AppSKey using the parameters of Join-Request and Join-Accept, NwkKey, and

AppKey.

(7) The end device sends uplink packets encrypted by NwkSKey and AppSKey to the

application server.

(8) The network server decrypts the uplink packets with NwkSKey and delivers the

packets to the application server. The application server also encrypts the packets

with AppSKey.

Figure 5.4 Over-the-air Activation (OTAA) procedure

After the Join-Request message, the Join Server also generates NwkSKey and AppSKey

with the same parameters shared with the device through the Join procedure. Finally, the end

device and the servers have the same session keys for secure transactions. Moreover, the Join

procedure provides device authentication.

5.2 Motivation: LoRaWAN Security Issues

The original LoRaWAN specification version 1.0 has a primary security mechanism.

However, since version 1.0 lacks end-to-end security mechanism, there are many security

vulnerabilities: reuse of frame counter, reuse of nonce value, lack of replay attack protection for

Join-Accept, weak replay attack protection for Join-Request, and missing an end-to-end integrity

protection [114]. LoRaWAN version 1.1 [113], released in 2017, significantly improves key

management and data confidentiality issues as described in version 1.0. First, the manufacturer

stores two 128-bit pre-shared root keys in the end device and the Join Server. Second, the Join

Server is a new entity in version 1.1 for the end device authentication. The Join Server verifies

the authenticity of the end device with the root keys and derives the session keys using

parameters related to the end device.

LoRaWAN version 1.1, however, still has security issues. Based on the papers [115-117],

we describe the four major specific security issues related to authentication in this section.

5.2.1 Not protected Join Message

During the Join procedure of OTAA, Join-Request is not encrypted as described in the

previous section. DevNonce, DevEUI, and JoinEUI in the Join-Request message are also not

protected [115]. These parameters should be protected because it is essential to derive the session

keys. Also, it can be possible for an attacker to eavesdrop and exploit the contents for the

sniffing attack, the impersonation attack, and the self-replay attack [118].

Figure 5.5 LoRaWAN Security Issues: Not protected Join Message

5.2.2 Rogue Gateway Attack

In LoRaWAN v1.1, gateway authentication is activated by the users. Through gateway

activation API, the users register the gateways with gateway ID and configuration information.

After that, the Gateway Server sends the activation request to the gateway, and then the gateway

finally participates in the LoRaWAN network, as shown in Figure 5.6. The gateway

communicates with the gateway server based on MQTT protocol, a publish-subscribe messaging

protocol based on TCP/IP protocol. In the transport layer, the gateway can use the TLS-

based security protocol, but the application layer needs a more secure protocol for authentication.

Also, compared with device activation, the gateway has a weak authentication

mechanism that only relies on the users [115]. If an attacker sniffs the activation message and

intercepts the gateway’s information, the attacker can easily register the rogue gateway into the

LoRaWAN network. If the attacker attempts an impersonation attack with the malicious

gateway, malicious data can be sent to the application server. Thus, a protocol for gateway

authentication should be required to protect the data from end devices.

Figure 5.6 LoRaWAN Security Issues: Rogue Gateway Attack

5.2.3 Rogue End Device Attack

LoRaWAN has vulnerability regarding rogue end device attacks related to device

authentication. As shown in Figure 5.7, an attacker with physical access may compromise the

LoRa end-devices to exploit jamming or self-replay attacks [115]. Also, an attacker can intercept

information to create a mock device with the same credentials or manipulate the data payload.

Thus, a protocol for robust device authentication should be required along with all Join

procedure protection.

Figure 5.7 LoRaWAN Security Issues: Rogue End Device Attack

5.2.4 No User Authentication Protocol

LoRaWAN v1.1 relies on external user authentication mechanisms [119]: API key,

OAuth via Enterprise platform (e.g., Google Cloud, Microsoft Azure), and session cookies.

These mechanisms have no independent user authentication protocol, which enables users and

end-devices to mutually authenticate each other over LoRaWAN [113]. Thus, it is possible to

compromise the data for end users if a custom application service has weak security methods.

Therefore, we propose a new user authentication and service authorization protocol in

LoRaWAN based on expanded Kerberos v5.

5.3 IAuth+ Architecture for LoRaWAN

In the following, we propose modifications to LoRaWAN 1.1 that will protect the Join

Message, detect and prevent rogue gateways from operating, detect and prevent rogue devices

from joining the network, and authenticate users accessing data collected by the LoRaWAN

network.

5.3.1 Entities

IAuth+ consists of an administrator, end devices, a gateway, users, authorization server in

OAuth 2.0, a network server in LoRaWAN, KDC (authentication server and ticket-granting

server) in Kerberos v5, and an application server. The description of the entities is as follow:

• An administrator is a person who is responsible for registering IoT devices in

the network. The administrator should have a device (e.g., smartphone) with a

camera to read a QR code from an IoT device.

• An end device is a device that has a QR code provided by the manufacturer. The

QR code has a pre-shared key and an authorization server info for registration.

The administrator should protect the QR code. These IoT devices should follow

the generic IoT network.

• A gateway is a device that connects IoT devices to the network. It is changeable

depending on the case. Usually, the gateway connects with IoT devices via

LoRaWAN.

• A user is a person who utilizes IoT devices inside/outside the network. Users

should get a ticket for utilization. When the ticket time expires, a user should

request a ticket again. The authentication server should register users with IP/PW.

• A network server is a server belonging to LoRaWAN, which delivers the uplink

from end devices to the application server and transmits the downlink to end

devices.

• Authorization server in OAuth 2.0 (AS) is a server that authenticates the

administrator and issues ID tokens and access tokens. The server is a part of

OAuth 2.0 protocol for authentication and runs on Join Server in LoRaWAN.

• Authentication server in Kerberos v5 is a server that authenticates a user with

ID/PW and issues Ticket-granting Ticket (TGT). The server is a part of Kerberos

v5 for authentication.

• Ticket-granting server in Kerberos v5 is a server that validates TGT and issues

Service-Granting Ticket (SGT). The server is a part of Kerberos v5 for

authentication.

• An application server is a server that provides a service with IoT data to users.

The server exchanges data with IoT devices and provides that data to users.

5.3.2 Architecture

IAuth+ follows a fundamental LoRAWAN framework. Figure 5.8 shows the architecture

of IAuth+. First, end devices are connected to the gateway by an administrator responsible for

installing and connecting the end devices to the network. End devices connect to wide area

networks via gateways – the network server. The administrator can obtain the administrative

right for end devices through the authentication procedure with the authorization server in OAuth

2.0. Users should also connect with the authentication server and the ticket-granting server as

Key Distribution Center (KDC) in Kerberos v5 to authorize their request for IoT utilization. This

authentication and platform are divided according to the functionality of each stage. Our protocol

provides secure authentication and authorization over LoRaWAN from device registration to

user’s utilization.

Figure 5.8 IAuth+ Architecture for LoRaWAN

5.4 IAuth+ Two-Step Solution

The IAuth+ protocol proceeds sequentially with a two-step solution: First, the “Pairing

Step” securely registers end devices and establishes a secure channel between the administrator

and the device. In this step, the concept of OAuth 2.0 is extended and applied to IAuth+ for

secure end device registration and authentication by an administrator. Next, the “Utilization

Step” provides mutual authentication for users and end devices. We apply the expanded

Kerberosv5 developed for LoRaWAN environments for multiple user authentication. The

proposed protocol’s two-step solution provides the following benefits:

(1) In end device pairing, the administrator securely requests end devices, gateways,

and administrator authentication through a QR code provided by the

manufacturer. A secure, shared symmetric key is provided via the QR code, thus

providing strong authentication without requiring assistance.

(2) By issuing tickets with controlled access permission and usage time for each user,

a secure user access control can be provided by KDC.

5.4.1 Step 1: Pairing for End Device

This step aims to authenticate and register end devices in LoRAWAN and allow the

administrator to be granted administrative rights to end devices. The authentication mechanism

refers to and extends the ACE model [23], which is based on OAuth 2.0. Devices initially boot

into “Pairing Mode” and wait for device registration. After this step, devices switch to

“Operating Mode” to provide service. If rebooted, devices return to “Pairing Mode” again. An

administrator scans a QR code with the end device and obtains information about the Pre-Shared

Key (PSK), DevEUI, JoinEUI, DevNonce, MIC, and the AS info. Because it contains credentials

for an administrator, the QR code must be physically protected by the administrator. Usage of

the QR code has the advantage of sufficient capacity, and it does not impose any workload on

IoT devices [23]. In addition, an administrator is granted control of the end devices via Access

Tokens from AS. As shown in Figure 5.9, the procedure for this step is as follows:

(1) The administrator scans the QR code of the end device with a smartphone camera.

(2) The administrator obtains a 128-bit PSK from the QR code.

(3) The administrator requests an access token from AS to access the end device,

using the DevEUI, JoinEUI, DevNonce, MIC, and PSK. The request message is

encrypted and signed with PSK.

(4) AS validates the request, and if valid, AS generates an access token for the

DevEUI.

(5) AS sends the access token to the administrator.

(6) The administrator requests protected resources of the end device from the

Application Server using the Access Token.

(7) The application server validates the Access Token.

(8) The application server responds to the administrator if valid.

Figure 5.9 Pairing Step for End Device Message Flow

5.4.2 Step 1: Pairing for Gateway

This step aims to authenticate and register a gateway in LoRAWAN and for the

administrator to be granted administrative rights to gateways. The authentication mechanism is

similar to the Pairing for the end device. In addition, an administrator is granted control over the

gateway via access tokens from AS. As shown in Figure 5.10, the procedure for this step is as

follows:

(1) The administrator scans the QR code of the gateway with a smartphone camera.

(2) The administrator obtains a 128-bit PSK from the QR code.

(3) The administrator requests an access token from AS to access the end device,

using the GatewayID and PSK. The request message is encrypted with PSK.

(4) AS validates the request, and if valid, AS generates an access token for the

GatewayID.

(5) AS sends the access token to the administrator.

(6) The administrator requests protected resources of the gateway from the gateway

Server using the access token.

(7) The gateway server validates the access token.

(8) The gateway server responds to the administrator if valid.

Figure 5.10 Pairing Step for Gateway Message Flow

5.4.3 Step 2: Utilization

This step aims to authorize users to utilize IoT devices after the “Pairing Step.” Secure

channels have been established from the previous stage, and valid end devices have been

registered in LoRaWAN to provide services. However, a standardized user authentication

protocol should be required to obtain data securely from end devices. We introduce an advanced

Kerberos v5 to provide a new authentication and authorization protocol between users and end

devices (application server). First, IAuth+ utilizes Key Distribution Centers (KDCs) to provide

secure user authentication and service authentication. AS-KDC validates users in the network,

and TGS-KDC validates authorized users to utilize IoT services. As shown in Figure 5.11, the

procedure for this step is as follows:

(1) The user sends a request of TGT for utilizing an end device to AS-KDC with the

user’s ID.

(2) AS-KDC validates the user’s request.

(3) After verification, AS-KDC issues TGT and the user's session key, encrypts it

with the user’s symmetric key, and responds. TGT contains the user’s ID and

session key and is encrypted with a KDC symmetric key.

(4) The user requests SGT to TGS-KDC with TGT, Authenticator, and end device

information.

(5) TGS-KDC is decoded by the KDC symmetric key to verify TGT.

(6) After verification, TGS-KDC generates SGT, a session key between the user and

IoT service server; encrypts with the user’s session key; and responds. SGT

contains a user ID and a session key between the user and the application server

and is encrypted with a symmetric key between TGS-KDC and the application

server.

(7) Users request the use of end devices with information from SGT, Authenticator,

and end devices.

(8) The application server uses a symmetric key shared between TGS-KDC and the

application server to verify SGT.

(9) After verification, the application server encrypts and sends a response message to

the user using the session key between the user and the application server.

Figure 5.11 Utilization Step Message Flow

All processes assume that (1) users must register their IDs and PWs with AS-KDC in

advance, and (2) AS-KDC - TGS-KDC and TGS-KDC - Application server must share

symmetric keys with each other.

5.4.4 Integration of IAuth+ and LoRaWAN (OATT)

As discussed in section 5.2.1, our protocol integrates the existing LoRaWAN Join

Procedure in OATT to improve the unprotected Join Request message. First, instead of the

device self-activation, our protocol provides trusted administrator intervention for the Join

Request. The administrator can securely receive the information from a QR code for device

activation. Through API on the administrator’s device, the Join Request encrypted by PSK is

sent to the network server. After validation from the authorization server, the join server sends

the Join-Accept message to the end device. If the end device receives the Join Accept message,

the end device generates two session keys. Thus, compared with LoRaWAN v1.1, our protocol

supports robust device authentication and protect all Join procedures. Second, the administrator

can obtain the administrative right of the end device with the access token issued by the

authorization server, which runs on the join server. Thus, without any ID/PW registration, our

protocol guarantees a secure administrator authorization protocol with the authorization server in

expanded OAuth 2.0. Figure 5.11 shows the integrated Join procedure with IAuth+ over

LoRaWAN.

Figure 5.12 Integration of the Join Procedure with IAuth+ over LoRaWAN

5.5 Effectiveness

In this section, we explore the effectiveness of IAuth+ for LoRaWAN using the STRIDE

model. This analysis demonstrates the effectiveness by examining how IAuth+ mitigates

potential threats.

5.5.1 STRIDE Model

The following analyzes threats to LoRaWAN with IAuth+ using the STRIDE model. For

a review of STRIDE, see section 3.4.1.

Spoofing

The Spoofing factor is illegally accessing and then using another user’s authentication

information. Spoofing can be exploited in IoT network for registering malicious IoT devices,

impersonating administrators, or camouflaging users. We adapted the Spoofing factor into our

protocol and analyzed the threat result:

(1) In the Pairing step, attackers can impersonate any administrator to register

malicious IoT devices into the network.

(2) In the Utilization step, attackers can impersonate any user to gain unauthorized

access to IoT devices and obtain information.

IAuth+ can mitigate these potential threats as follows:

(1) Administrator reads a QR code that is physically protected and then obtains PSK.

The device register request from the administrator is encrypted by PSK. AS

validates the request with PSK and responds to the administrator with the token.

(2) In the Utilization step, users are already registered in AS-KDC with their ID and

PW. Thus, AS-KDC validates users’ requests using their ID/PW.

Tampering

The Tampering factor is a malicious modification and unauthorized change. Tampering

can be exploited in IoT networks to modify communication or data with illegal attempts and

weak authorization. We adapted the Tampering factor into our protocol and analyzed the threat

result:

(1) In the Pairing step, attackers can modify data flow between an administrator and

AS to obtain unauthorized access to IoT devices or modify data flow between

administrator and IoT devices to obtain unauthorized access to IoT devices.

(2) In the Utilization step, attackers can modify data flow between users and IoT

devices (or IoT service servers) to obtain unauthorized data.

IAuth+ can mitigate these potential threats as follows:

(1) The data flow between an administrator and AS is encrypted by PSK provided

from a QR code. After verification by AS, the access token is issued. Moreover,

the data is protected by the access token from trusted AS.

(2) In the expanded Kerberos v5 for IoT network, SGT protects the data flow

between users and IoT devices (or IoT service servers) for IoT service.

Information disclosure

The Information disclosure factor involves the exposure of information to individuals

who are not supposed to access it. In IoT networks, Information disclosure can be exploited for

stealing data from vulnerable subjects, such as IoT devices, administrators, and users. We

adapted the Information disclosure factor into our protocol and analyzed the threat result:

(1) Attackers can sniff data flow between an administrator and AS to disclose

credential data during the pairing step.

(2) Attackers can sniff data flow between an administrator and IoT devices to

disclose credential data during the pairing step.

(3) Attackers can sniff data flow between users and IoT devices to disclose credential

data during the service authorization.

IAuth+ can mitigate these potential threats as follows:

(1) The register request is encrypted by PSK provided from a QR code, which the

administrator physically protects. Thus, the data can be protected by secure QR

code protection.

(2) The access token from trusted AS authenticates the data. Thus, the access token is

issued only for the valid administrator.

(3) Credential data and IoT services are protected by TGT and SGT, which Kerberos

manages. TGT guarantees the authenticated users, and SGT guarantees the

authorized service to the users.

Elevation of Privilege

In the Elevation of Privilege factor, unprivileged users gain privileged access to

compromise the system and effectively penetrate and become part of the trusted system.

Elevation of Privilege can be exploited in IoT networks to get credentials from administrators,

devices, and users. We adapted the Elevation of Privilege factor into our protocol and analyzed

the threat result.

(1) In the Pairing step, attackers could obtain a valid Access Token to elevate an

admin privilege to exploit IoT devices as botnets.

(2) In the Utilization step, attackers could obtain a valid TGT/SGT to elevate a user

privilege to exploit IoT data.

IAuth+ can mitigate these potential threats as follows:

(1) An administrator should be authenticated by PSK from a QR code. The access

token for an administrator is issued by trusted AS.

(2) AS-KDC and SGS-KDC issue a valid TGT/SGT, including the timestamp for

users to prevent reuse. Tickets are protected by session key and authenticator.

5.5.2 Benefits of IAuth+ for LoRaWAN

IAuth+ presents a standard model for advanced authentication and authorization for

LoRaWAN. Conceded with major network features: resource-constrained end devices and

central infrastructure in LoRaWAN, IAuth+ should be adapted to mitigate the challenges of

potential security attacks by providing strong authentication and authorization procedures

developed by expanded OAuth 2.0 and Kerberos v5. Specific benefits of IAuth+ are as follows:

(1) Provide robust authentication and authorization protocol over LoRaWAN for

device registration, administrator authorization, user authentication, and service

authorization using expanded OAuth 2.0 and Kerberos v5.

(2) Mitigate LoRaWAN security vulnerabilities and possible attacks with

authentication issues, such as

a. Protect the Join Procedure and Secure Gateway authentication protocol

b. Provides Robust Device authentication protocol with administrator

authorization

c. Propose first standard User authentication protocol for LoRaWAN

d. Prevent possible attacks such as a sniffing (eavesdrop) attack, an

impersonation attack, and a replay attack

5.6 Analysis and Evaluation

To analyze the capacity of IAuth+, we compare it with secure related protocols for

LoRaWAN. Additionally, as proof-of the-concept, we compare and evaluate it with other

proposed protocols for authentication security.

5.6.1 Comparison with LoRaWAN

As we discussed in section 5.2, LoRaWAN v1.1 has security issues. In this section, we

compare the functionality of LoRaWAN and IAuth+ with 12 major factors related to the

evaluation of authentication and authorization.

LoRaWAN v1.0 is typically developed to be vulnerable to replay attacks due to the Key

negotiation problem [114]. LoRaWAN v1.1 was released with Join Procedure, NwkSKey and

AppSKey to solve this problem [113]. In LoRaWAN, the Join procedure provides mutual

authentication and key agreement with the NwkKey and AppKey as the root key to the network

server. Still, the unprotected Join Request has vulnerabilities of the device, user anonymity, and

malicious device registration. With these vulnerabilities, attackers can attempt potential threats

such as Privileged-Insider Attack, Replay Attack, and Stolen Verifier [114]. However, IAuth+

provides a robust device authentication and administrator authorization protocol through mutual

authentication between the administrator and the authorization server in OAuth provided by the

manufacturer and ensures secure IoT service provision for users through lightweight Kerberos.

At this time, the user receives the authentication code provided from the IoT service server safely

from the homeowner and sends a service ticket for mutual authentication. Therefore, the attacker

will fail to compromise the devices using a stolen verifier, such as the impersonation attack and

the replay attack.

Table 5.1 Functionality Comparison with LoRaWAN

LoRaWAN IAuth+

Mutual Authentication Yes Yes

Key Agreement Yes Yes

Intractability No Yes

User Anonymity No Yes

Device Anonymity No Yes

User Impersonation No Yes

Malicious Devices Impersonation No Yes

Privileged-Insider Attack No Yes

Replay Attack No Yes

Stolen Verifier No Yes

Token (Ticket) Impersonation N/A Yes

Token (Ticket) Modification N/A Yes

5.6.2 Comparison with other security protocols

As discussed in section 5.2, LoRaWAN, many papers have been published for secure

authentication in LoRaWAN. Among these papers, we select two authentication protocols

related to the unencrypted Join Procedure and compare these two protocols with IAuth+. Na et

al. proposed a method of XOR with tokens to create a unique Join request message [117]. Danish

et al. proposed a two-factor authentication mechanism for the Join procedure based on

blockchain technology [120].

Table 5.2 Comparison with other security protocols

Na et al. Danish et al. IAuth+

Main security issues

Not encrypted Join Procedure

Not encrypted Join Procedure. Centralized network servers

Not encrypted Join Procedure Overall authentication/ authorization procedure

Security method XOR with token Blockchain OAuth 2.0 Kerberos v5

P ra

ct ic

al it

Complexity Simple Complicated Simple

Cost Low High (extra layer of security and several servers)

High (KDC Installation)

Feasibility Low (No mention about issuing token) Low (hard to employ extra layer) High

E ff

ec ti

ve ne

Security Range Only Device

Device - Network Server

Device, Gateway, Administrator, User, and Service

Data Integrity

Low (No mechanism for managing Token)

Middle (First Join-request is not protected)

High

Threats prevented Replay Attack

Impersonation Attack, MITM Attack

Replay Attack, Impersonation Attack, Sniff Attack MITM Attack

5.6.3 Comparison of Computation Cost

This section presents a performance comparison of the proposed protocol with other

related authentication protocols [117, 120]. Table 5.3 shows the notation for a time of

computational cost required for Join procedure [121]. Additionally, Table 5.4 result the

computation cost compared with LoRaWAN and other security protocols.

Table 5.3 Notation for computation cost analysis [121]

Notation Description Approximate execution time

Th Time for performing Hash Function ≈ 0.0023 ms

TEnc / TDec Time for performing a symmetric key encryption / decryption ≈ 0.0046 ms

TXOR Time for performing XOR (≈ Th ) ≈ 0.0023 ms

Table 5.4 Comparison of computation cost of our protocol with other security protocols

LoRaWAN Na et al. Danish et al. IAuth+

Computation Cost of Device

2x10 Th +2 (TEnc + TDec) ≈ 0.0664 ms

LoRaWAN + TXOR ≈ 0.0667 ms

2 x LoRaWAN ≈ 0.0828 ms

10 Th +2 (TEnc + TDec) ≈ 0.0598 ms

Computation Cost of Administrator - - -

TEnc + TDec + 4 Th ≈ 0.1058 ms

The computational cost is the time needed for a Join procedure to be transmitted from an

end device to the network server over LoRaWAN. The results of IAuth+ and other security

protocols related to the authentication are shown in Figure 5.13, considering the increase in the

number of nodes. LoRaWAN and Na et al. have almost the same computation costs because Na

et al. add the XOR with tokens into the Join Request message. Danish et al. have the highest cost

because two Join procedures must receive blockchain ID as two-factor authentication. Our

protocol is much lower than other protocols because the trusted administrator sends the

encrypted Join Request message instead of the device self-activation. Also, the cost is very low

for the administrator, as shown in Table 5.4. Furthermore, the difference in the time cost

increases as the number of end-devices increases.

Figure 5.13 Comparison of the time cost in IAuth+ and other related works

5.6.4 Comparison of Number of Messages and Time on Air

This section compares the number of messages of the proposed protocol with other

related authentication protocols [117, 120]. Communication between end devices and a network

server begins with a Join procedure. Each frame is transmitted with a different Spreading Factor

(SF), defined as SF = log2 (Rc / Rs), where Rs is the symbol rate and Rc is the chip rate [122]. As

described in Table 5.5, based on code rate 4/5 and a 125 kHz bandwidth, the higher the SF, the

slower the transmission rate, and the longer the communication range. The transmission bit rate

varies from 0.3 kbps to 27 kbps, depending on the SFs (SF7 to SF12), the bandwidth of the

communication channel, and the Code Rate (CR). The transmission bit rate is defined as for

formula (7.1) [112], where Tb is the transmission rate, BW is the channel bandwidth, and CR is

the code rate.

Table 5.5 Transmission Bit Rate and Range with code rate 4/5 and a 125 kHz Bandwidth

SF SF7 SF8 SF9 SF10 SF11 SF12

Range 2 km 4 km 6 km 8 km 9 km 10 km

Tb 5.47 kbps 3.12 kbps 1.76 kbps 0.98 kbps 0.54 kbps 0.29 kbps

𝑇! = 𝑆𝐹 × "# $!" × 𝐶𝑅

Figure 5.14 shows that the larger payloads increase the Time on Air. Consequently, as SF

increases, the Time on Air increases significantly, considering the bandwidth according to the

transmission bit rate equation (7.1). It means that the larger the payload for specific SFs, the

longer the latency, and higher SFs exacerbate the issue. Therefore, considering the efficiency of

LoRaWAN with the limited network environment, the number of messages for secure device

activation, which is the initial phase, is significant.

Figure 5.14 Time on Air of LoRaWAN with code rate 4/5 and a 125 kHz bandwidth

(7.1)

The number of messages in IAuth+ and other security protocols related to the

authentication is shown in Figure 5.15, considering the increase in the number of nodes.

Compared with other protocols, IAuth+ has the lowest message number because of the trusted

administrator’s intervention. Instead of the Join Request message from the device, the

administrator with the secure device and network environment performs device authentication

based on the expanded OAuth 2.0. Thus, IAuth+ guarantees fewer messages than LoRaWAN

and other protocols. In conclusion, as shown in Figure 5.16, IAuth+ has a lower Time on Air

compared to other protocols because of the large SF. That is, compared to other protocols,

IAuth+ has a lower latency.

Figure 5.15 Comparison of the number of the message in IAuth+ and other related protocols

Figure 5.16 Time on Air of IAuth+ and other related protocols with a 20-byte payload

5.7 Conclusion

LoRaWAN is an open-source protocol over frequency bands. Many IoT environments

utilize LoRaWAN for long-range communication with small end devices. However, LoRaWAN

suffers from various vulnerabilities depending on its environment, which an attacker could target

to launch authentication and authorization attacks. This chapter concludes that the adaptation of

two robust authentication and authorization protocols, OAuth 2.0 and Kerberos v5, can mitigate

these issues in LoRaWAN environments. Also, the threat model and analysis help validate the

security architecture process for LoRaWAN environments.

The next chapter discusses a survey of the DNS and DNSSEC vulnerabilities and attacks

published in Journal of Surveillance, Security and Safety, 2020.

CHAPTER 6

A Survey of DNS Vulnerabilities and Attacks

6.1 Motivation

Over the past 30 years, we have experienced more convenient Internet services through

the human-friendly Domain Name System (DNS) functionality, which maps domain names to

internet protocol (IP) addresses using globally distributed hierarchical name servers. Internet

users with domain addresses can utilize various Internet services, such as web surfing, e-mail,

and even mobile services without entering machine-recognized IP addresses. However, DNS was

first developed without consideration of cybersecurity and caused many problems [38, 39]. There

is no doubt that there are many cyber attacks on DNS in the wild. In a recent attack, for instance,

attackers redirected DNS lookup for MyEtherWallet.com to a malicious website that looked like

an authentic website, for hijacking victims’ account information [40].

To overcome such various DNS security problems (i.e., directory lookup) and reinforce

cybersecurity, the DNS Security Extensions (DNSSEC) protocol was developed. DNSSEC

implanted the digital signature mechanism of public-key cryptography into the DNS system [41,

42]. DNSSEC extends DNS based on the hierarchical Public Key Infrastructure (PKI) to protect

data published in DNS. Certificates for the public keys are issued by trusted Certificate

Authorities (CAs), which certify the ownership of the public keys. Thus, clients and resolvers

can verify that DNS responses have not been forged or altered, using DNSSEC. However,

DNSSEC still suffers from deployment issues in the current Internet. Chung et al. [43] found that

31% of domains supporting DNSSEC failed to publish all relevant records required for

validation and 39% of domains used an insufficiently strong key-signing key. They also found

that 82% of the resolvers requested DNSSEC records, but only 12% of them attempted to

validate the DNSSEC records. Additionally, several studies have been performed to scrutinize

the CA model for lack of transparency and choice of trusted CA sets [44, 45]. If one of the CAs

acting as a trust anchor is compromised, all information certified by the CA may be falsified.

The 2016 Dyn cyberattack was a significant event indicating serious DNS risk. Dyn,

which is a popular DNS provider, was attacked by two large and complex distributed denial-of-

service (DDoS) attacks against the DNS infrastructure [46]. Eventually, several major Internet

services and banking systems were paralyzed. An interesting issue with this attack is that a large

part of the US was impacted by attacking Data Centers in only certain parts of the US. That is,

the attack directly targeted only a locally distributed DNS with a local Botnet. Moreover, the

Cyber Security Report [47], released in 2018, describes DNS as the largest (82%) Internet

service target of application-layer attacks. Despite efforts to improve DNS’s security problems,

DNS is still a popular target for cyberattacks because of its essential role on the Internet, and its

vulnerability.

6.2 Background

6.2.1 DNS (Domain Name System)

DNS is an Internet system to map alphabetic domain names to numeric IP addresses [38,

39, 48]. In 1983, domain names were first translated to addresses through a local service,

managed by the Operating System (OS). The host file in the OS stored these translations.

Initially, only about 15 organizations used a single network, so keeping these files consistent and

updated was straightforward, but not scalable. To address this inefficiency, the Stanford

Research Institution Network Information Center (SRI-NIC) developed a new naming

mechanism. The previous name service within the OS was transformed into a system that was

managed and deployed collectively by SRI-NIC. The host file containing translation information

(host name and numeric address) was hosted online by SRI-NIC and could be downloaded over

FTP. However, as the Internet grew the difficulties of keeping the file updated, and the size of

the file, became impractical. This resulted in poor search performance and traffic bottlenecks. To

overcome these drawbacks, a new type of name system was introduced 1987 as IETF Request

for Comments (RFC) 1034 [39].

Technically, DNS is a hierarchical name server system that uses a globally distributed

database system that holds information about each domain. The DNS information is stored in

distributed DNS servers, and the information can be searched at any time upon user request.

Figure 6.1 illustrates the hierarchical DNS structure via a common domain name. DNS begins

with the . (Root) domain at the top. .com is a TLD (Top Level Domain) whose parent is the .

(Root) domain. .google is a SLD (Second Level Domain) whose parent is the .com domain.

Finally, .www (i.e., a web service) is a subdomain of .google.com.

Figure 6.1 DNS Structure

The process of translating IP addresses to corresponding domain names through DNS is

called name resolution or DNS resolution [38]. DNS resolution begins with a client’s DNS

request. Figure 6.2 illustrates how a client obtains the IP address for a web server via DNS

resolution, allowing it to receive web services.

Figure 6.2 DNS Architecture

(1) A client requests an IP address www.google.com from a local recursive DNS

resolver.

(2) The recursive DNS resolver first checks the address translation in its own local cache.

(3) If there is no information in the cache, the recursive DNS resolver requests the IP

address of the TLD nameserver from the Root name server.

(4) The Root name server send back the IP address of the .com name server as a

response.

(5) Using this IP address, the recursive DNS Resolver requests the IP address of the SLD

nameserver from the .com name server.

(6) The .com name server sends back the IP address of the .google.com name server as a

response.

(7) With the IP address, the recursive DNS Resolver requests the IP address for

www.google.com from the .google.com name server.

(8) The .google.com name server sends back the own IP address of www.google.com to

the recursive DNS resolver.

(9) The recursive DNS resolver sends back the IP address of www.google.com to the

client as a response. Finally, with the IP address (172.217.7.197 in this example), the

client connects to the www.google.com server.

The DNS framework consists of the following three parts:

(1) Client: They request IP addresses with domain names through the stub resolver, a

client of DNS, and transmits the request to the local DNS server address set on its

own device.

(2) Local DNS Server (Recursive DNS Resolver): They receive the DNS query

from clients and obtains the IP address for the domain name from domain name

servers. Also, the IP address once found is stored in memory for a certain period.

So, it is called Caching Resolver.

(3) Domain Name Server (Authoritative Name Server): They have and manage IP

addresses for the domain names as well as the information related to the IP

addresses. The Authoritative Name Server is composed of more than 3-levels

(Root, TLD, Lower-level Domain). Each domain server consists of a single

master server and several slave servers.

The major vulnerability in DNS is the lack of security. The original DNS protocol did not

consider this issue in depth. Thus, DNS data could be forged to translate to a malicious IP

address, so that Internet users would connect to a non-authorized site. This could, for example,

be used to distribute false information, or to surreptitiously collect personal information. DNS

does not provide a way to verify that the received IP address translation is authentic. A corrupted

or intercepted DNS response may provide false information to any requester. DNSSEC has been

developed to overcome this fundamental security vulnerability of DNS [41, 42].

6.2.2 DNSSEC (DNS Security Extensions)

DNSSEC, which is an Internet standard technology, aims to eliminate this vulnerability

of DNS. DNSSEC was originally standardized in 2005 as IETF RFCs 4033 through 4035 [41,

42]. Using two keys – the Zone Signing Key and Key Signing Key – to create digital signatures

with Public Key Cryptography, DNSSEC guarantees integrity and authentication for DNS data.

DNSSEC significantly enhances DNS security by adding Public Key Cryptography to the

existing DNS. The DNS cache poisoning attack, for instance, configures an ISP’s local DNS

resolvers and their cache to map specific domain names to malicious IP addresses. As a solution

to such DNS fundamental security problems, DNSSEC provides strong authentication using

digital signatures, based on Public Key Cryptography [41, 42].

Figure 6.3 Public Key Cryptography Architecture

Figure 6.3 shows the basics of data authentication using public-key cryptography.

(1) Alice generates an asymmetric key pair, composed of a Public and a Private key.

(2) Alice distributes the public key to the Internet.

(3) Alice creates “signature” by signing the plain text with her private key.

(4) Alice transmits “signature” along with “original data” to Bob.

(5) Bob receives “original data” with “signature” from Alice

(6) Bob looks up the public key of Alice

(7) Bob performs the signature validation of “original data” with “signature”, using

Alice’s Public key.

(8) If the signature is successfully verified, then Bob is assured that the original data

purportedly from Alice is correct.

DNSSEC applies the digital signature mechanism to resource records (RRs) to protect the

data itself, which is set in each section of the response message. DNSSEC has added four new

RR types to existing DNS records; these are Resource Record Signature (RRSIG), DNS Public

Key (DNSKEY), NSEC/NSEC3, and DS. These record types support the digital signatures and

the signature verification process [49].

(1) RRSIG: This RR has a signature for a DNSSEC-secured record set.

(2) DNSKEY: This RR contains the public key to verify the signature in RRSIG

records.

(3) NSEC/NSEC3: This RR is for the explicit denial-of-existence of a DNS record.

(4) DS (delegation signer): This RR holds the name of a delegated zone. The DS

record is placed in the parent zone along with the delegating NS records for the

authentication chain between the parent zone and child zone.

Figure 6.4 DNSSEC Architecture

The DNSSEC protocol uses a Chain of Trust due to a strong, reliable connection between

DNS servers. Figure 6.4 shows how DNSSEC works as the Chain of Trust. Compared with

Figure 6.2, the IP address request of DNSSEC is the same as that of DNS. However, the

verification process is added to the existing DNS. DNS servers verify each other with digital

signatures from trusted CAs. Thus, DNS servers maintain a strong security chain between each

other to guarantee the integrity and authentication of DNS data [42]. DNSSEC adds strong

security to authenticate DNS responses. Thus, DNSSEC assures users where the DNS data

originated from, that it is not forged in transit, and verifies whether a domain exists or not.

(A) A DNS resolver first sets a “Trust Anchor” that corresponds to the public key

from a Root domain zone, as the Key Signing Key (KSK) over DNSKEY record.

(B) The “Trust Anchor” is the starting point for verifying the signature in the signed

DNS data, as the basis for ensuring “Trust” for Data Integrity.

the A record data, which is the final node of verification, and then trusts the data.

DNSSEC adds strong security to authenticate DNS responses. Thus, DNSSEC assures

users where the DNS data originated from, that is not forged in transit, and verifies whether a

domain exists or not.

6.3 Vulnerabilities

Cybersecurity is a defense mechanism to protect the system from various malicious

attacks; cyberattacks disable or avoid these defenses. Vulnerabilities or weaknesses enable such

attacks. This section looks specifically at DNS and DNSSEC vulnerabilities.

6.3.1 DNS Vulnerabilities

DNS vulnerabilities can be viewed in 3 ways: (1) by concept, (2) by structure, and (3) by

communication.

Conceptual view

The CIA Triad is a conceptual model of information security, consisting of three factors:

confidentiality, integrity, and availability [52]. The following is an assessment of DNS in terms

of information security.

(1) Confidentially: DNS requests and responses are in most cases sent via the UDP

protocol, which is light and fast, but normally unencrypted, allowing

eavesdropping on all messages. Besides, the information stored by DNS servers is

necessarily public, as name to address bindings must be served on demand.

(2) Integrity: DNS without modification does not have a mechanism sign data

cryptographically, which is its single greatest weakness; anyone can tamper with

or forge DNS data.

(3) Availability: the hierarchical structure of DNS, unless augmented with

redundancy, is very much subject to attacks on DNS servers, or to failures of

those servers.

Structural view

DNS servers have a hierarchical tree structure ranging from the Root to a specific domain

name server. However, such a DNS feature includes structural problems, which can affect DNS

vulnerabilities. The structural problems in DNS are as follows:

(1) Lack of redundant DNS [53]: The hierarchical DNS structure distributes and

processes DNS queries more efficiently. Users can request an IP address of the

desired domain step by step and obtain the response. Although DNS is designed

to be distributed, traffics is concentrated because of the centralization. The

centralized DNS structure makes it easier for an attacker to attack multiple

Internet services used by many Internet users. For example, in 2016, a DYN

attack exploiting such vulnerability made many users unable to receive normal

DNS responses, as well as Internet services unavailable [46]. DNS above the SLD

level, and major domain nameservers, have evolved over the years into a highly

redundant system through numerous studies and cases. However, lower-level

DNS servers remain exposed to threats due to a lack of redundancy. Resilient and

reliable DNS support is possible if more domains adopt and support secondary

DNS configurations [53].

(2) DNS server information exposure [54]: Because the fundamental security

configuration of the DNS server is insufficient, the server information (e.g., server

list, version) can be exposed through DNS servers of many companies. If such

information is exploited, not only DNS operation but also server operation inside

the companies can be exposed to the risk by attackers. The leakage of DNS server

information allows malicious DNS data to be sent and the user to trust wrong

DNS information. Additionally, attackers can collect information by

reconnaissance attack and finally attack the server. Therefore, the security

configuration of restricted server information transmission needs to be set up in

each company’s DNS servers.

Communication view

Responses to queries are only weakly protected in DNS. DNS uses the IP address,

destination and source port numbers, and transaction ID in responses to match them with queries.

It is relatively straightforward for attackers to craft responses that pass these tests, as follows:

(1) No secured packet through UDP [55]: The basic query of DNS is delivered over

the UDP protocol, which is unencrypted. An attacker could first capture a DNS

query packet and forge a response from the name server in a malicious response

before the resolver receives a valid response. This attack is made easier if routers

are subverted as well.

(2) Transaction ID prediction [56]: The transaction ID is unique among several

parameters that match DNS responses to requests. However, if the transaction ID

is predictable, it makes it easier to forge a DNS response. The transaction ID is a

16-bit field in the DNS header and issued by the DNS algorithm. The ID value

has a range of 32,768 values, but it is easier to predict if DNS randomization is

poorly done (e.g., overload in cache). It is also predictable just by observing the

request ID. Thus, attackers can easily guess the transaction ID and have their

DNS response accepted as valid. For BIND (Berkeley Internet Name Domain)

versions 4 and 8, a sequential transaction ID method is used, allowing the

response ID simply to add 1 to the request ID. BIND version 9 and later adopts all

randomized transaction ID and does not re-use the same ID for the same domain

name. and predict the next transaction ID.

(3) Caching problems [57]: Caching is used for DNS efficiency. By storing the IP for

the domain for a period, unnecessary IP address requests and access time to that

domain can be reduced. Cache Poisoning, a typical DNS attack using such

vulnerability, is one of the major threats to DNS. In cache poisoning, an attacker

injects a malicious IP address into the DNS cache, causing users to receive false

translation information for an extended period.

(4) Lack of protection against Distributed Denial of Service (DDoS): About 93% of

all cyberattacks on the Internet are reported as DDoS attacks [47]. DNS is also

vulnerable to this attack. If DNS request floods occur, the DNS name server that

handles the requests cannot respond to all requests making DNS service

unavailable. Consequently, all users using the DNS name server are unable to use

the Internet. Due to the absence of a mechanism to block and prevent such attack

patterns, DNS is currently suffering from many DDoS attacks.

6.3.2 DNSSEC Vulnerabilities

As shown in Section II, DNSSEC has enhanced security for authentication and integrity

by adding digital signatures using public and private keys to existing DNS to overcome known

DNS vulnerabilities. However, DNSSEC is still suffering from various attacks through

vulnerabilities and limitations.

Overhead

DNSSEC adds four record types to the DNS: Resource Record Signature (RRSIG), DNS

Public Key (DNSKEY), Delegation Signer (DS), and Next Secure (NSEC). Because of these

extended records, DNSSEC requires more overhead than traditional DNS and increases

processing time and packet size. The size of the DSSEC packet is up to 2000 bytes, while the

UDP size specified by the RFC is 512 bytes. Therefore, the packets in DSSEC are fragmented,

100

which may result in DNS fallback. For example, if the fragmented DNSSEC packets are not

delivered properly and a public key that was previously verified during a key rollover is still

stored in the local cache and a DNS data packet signed with a new key is received, verification

of the new packet will eventually fail and be ignored. As a result, the user is provided neither

with the DNS service nor authentication [58].

Complexity

The implementation of DNSSEC has been found to have problems in deployment.

Misconfiguration may be increased because DNSSEC significantly increases the complexity of

the existing DNS infrastructure [59]. The misconfiguration may result in incorrect DNSSEC RRs

and authentication problems such that the data is regarded as fake, even though it is correct,

causing name translation to fail [60].

Untrustworthy resolver [61]

Assuming a reliable DNSSEC system is built on DNS, most of the DNS responses are

trustworthy. However, if there are unreliable resolvers to deliver the final DNS response

provided by the secure DNS server, Internet users are exposed to DNS threats despite the robust

DNSSEC. Usually, most people do not consider how much they trust the local DNS resolver that

is set up for them but simply use the default local DNS resolver provided by the network. For

example, if a typical user connects to the Internet over public Wi-Fi, the DNS resolver is

automatically configured as the default. Exploiting such a problem, an attacker may intercept the

request and configure a malicious DNS resolver that delivers false DNS data to the victim. To

counteract this, the chain of trust should be extended from the DNS resolver to the users.

Dynamic Host Configuration Protocol (DHCP) with authorization tickets is one way to identify

101

DNS resolvers that are trustworthy [62]. However, if the DHCP server is disabled, or

untrustworthy itself, all users in the network could be affected.

Zone list exposure

The DNS database is broken into zones of records. Each zone contains not only a

domain’s records but may also contain its subdomains and related records. DNSSEC has a

security function that can digitally prove a domain or resource record that does not exist, using

the NSEC (Next Secure) record type. This, however, makes it possible for an outsider to find the

names in an entire zone, a process known as zone enumeration. To address this issue, the

standardization of the NSEC3 RR has been completed, but can still be seriously impacted by

malicious NSEC3 and DNS servers that do not implement the standard [63].

Also, zone transfer is used to synchronize zone files between primary and secondary

DNS servers. To synchronize zone files between DNS servers, it is often accomplished using

NFS, or a specialized zone-transfer function. Although zone file transfers are necessary,

misconfiguration of the transfer may pose a serious threat of leaking information.

Low deployment of DNSSEC

DNSSEC provides much stronger security for DNS, but it is currently plagued by the

slow deployment of DNSSEC. According to an Internet Society Report in 2016 [64], TLDs

zones signed with DNSSEC were about 90%, while SLDs were only 65% of DNSSEC-enabled

zones. In addition, considering that the usage of DNSSEC-validating resolvers is approximately

26%, the percentage of deployment might be lower. The report also points out that DANE’s

deployment, which enhances the DNSSEC’s vulnerability, is also low.

Amplification and reflection DDoS threat

102

DNSSEC is still a possible vehicle for amplification and reflection attacks [65]. Due to

the additional information caused by complex digital signatures, DNSSEC's record is

significantly larger than a normal DNS response. On average, the size of an "ANY" response

from DNSSEC is 28 times larger than a normal DNS "ANY" response [66], making

amplification and reflection attacks even more damaging.

6.4 Attacks

This section presents the state-of-the-art for DNS attacks, classifies, and assesses them.

Generally, the DNS attack is an attack that targets multiple DNS servers on the Internet, using

the DNS and DNSSEC vulnerabilities described in the previous section. The goal of the DNS

attack is to deplete the targeted system resource or to corrupt the data, make the DNS system

unavailable, or exploit the system to achieve the final attack. As of now, the attacks are received

considerable attention from researchers, governments, and industry, but they still cause a

significant risk for Internet users.

DNS attacks may be separated into four categories: DNS data tampering, DNS data

flooding, abuse of DNS, and DNS server structure. Figure 6.6 shows the list of 11 DNS attacks

that are categorized.

Figure 6.5 DNS Attacks List

103

6.4.1 DNS data tampering

DNS Data Tampering occurs when an attacker hijacks and/or compromises unencrypted

DNS data in the middle between users and DNS servers, and then users receive false address

translation information. The attack is based on the vulnerability of insecure DNS data. Figure 6.7

shows how a typical DNS data tampering attack occurs. DNS attacks using data tampering are

listed below.

DA01. DNS cache poisoning

DNS cache poisoning attack corrupts the data in the DNS cache. An attacker first queries

a recursive DNS server for a domain. If the recursive DNS server(A) does not have an IP address

corresponding to the requested domain in its cache, A sends queries to the authoritative name

server (B). Before B can send an NXDOMAIN response, the attacker sends a large number of

spoofed responses to A that appear to come from B. If the DNS response matches the DNS

query, A will accept a spoofed response from the attacker and keeps the resource records (RRs)

provided in that response in its cache. At a later time, a user asking for the translation of this

same domain name contacts the A, which will provide the cached malicious IP address to the

user [57].

Alharbi et al. did a study on the risk of client-side DNS cache poisoning attack and

discovered that a new type of DNS poisoning attack using vulnerabilities to caching within the

end-user’s operating system is feasible. Such vulnerability is still exposed because the client side

is not considered as part of the DNS framework and, therefore, not considered in mitigations to

the DNS cache poisoning attack [67].

104

Figure 6.6 DNS Attack: DNS Data Tampering

DA02. Kaminsky [68]

To protect against conventional cache poisoning attacks, DNS resolvers use a technique

known as “bailiwick checking”. To protect against malicious DNS additional records, the DNS

resolver accepts only basic information and ignores additional information. To overcome this,

attackers exploited the authoritative name server to poison resolver caches. Dating from Steven

Bellovin's study in 1990, DNS hijacking and poisoning attacks developed into attacks based on

the “birthday paradox”, and eventually evolved into Kaminsky attacks in 2008 [69].

Kaminsky attack hijacks the authoritative records instead of RRs. To succeed in the

attack, the attacker should configure a domain name server that is authoritative for the malicious

website zone, including all records, as a precondition. Kaminsky attack consists of two steps:

Step 1: The attacker requests fake DNS queries about a random name within the target domain to

local DNS servers. Since the local DNS server does not have the information in its cache, it will

generate subsequent queries to authoritative name servers. Step 2: The attacker sends a barrage

105

of forged answers to the local DNS server. Instead of fake RRs, it delegates to another name

server, using the malicious authority record.

Finally, an attacker owns an authoritative name server for the specific website and

provide users with malicious IP addresses for normal DNS requests of the domain through the

DNS resolver. This attack is a higher level of attack than DNS Cache Poisoning Attack because

it can affect not only the domain but also the subdomain.

DA03.DNS hijacking [70]

DNS Hijacking modifies DNS record settings (most often at the domain registrar) to

point to a bogus DNS server or domain. Attackers hack the vulnerable DNS servers to change

the IP address and the mapped domain address. Cisco Talos discovered a new DNS hijacking

attack called “DNSpionage” [71]. The main feature of this attack is to keep it as inconspicuous

as possible during the attack. DNSpionage uses malicious Microsoft Office files with embedded

malware, which provides HTTP and DNS communication with the attackers. Finally, malicious

DNS redirection works when a user opens a forged document or malicious site. The main feature

of this attack is to be as inconspicuous as possible during the attack.

6.4.2 DNS data flooding

In general, the goal of flooding attacks is to disable the user-server function by

overwhelming the server, thereby hampering the DNS name resolution for its zone. Through the

DNS data flooding attack, the attacker tries to exhaust server resources with an enormous

amount of apparently valid queries, overwhelming server resources, and impeding the server's

ability to respond to legitimate requests. Figure 6.8 describes the specific method of DNS data

flooding.

106

Figure 6.7 DNS Attack: DNS Data Flooding

DA04.DNS Flooding Attack [72]

DNS flooding attack attempts to exhaust server-side resources through a flood of UDP

requests from multiple machines contaminated by malware. DNS servers, which rely on UDP

protocol for name resolution, may not be able to distinguish large UDP packets from normal

requests. Attackers send a large volume of packets, mimicking legitimate DNS requests to a

DNS server, causing the DNS server to run out of resources to handle legitimate requests.

DA05. DNS Reflection and Amplification DDoS Attack [73]

The obvious difference between DNS reflection/amplification DoS attack and DNS

flooding attack is in the target of attacks. While DNS flooding attack depletes DNS server’s

ability, DNS reflections and amplification attack attempts to saturate network capacity with

heavy bandwidth traffic. This attack takes advantage of the vulnerability of third-party open

resolvers in the network that combines reflection and amplification. An attacker sends out small

request queries to multiple open recursive DNS servers, with a spoofed source IP address. The

request is crafted to cause a large response packet. Through simultaneous reflection and

amplification attack, the open recursive DNS servers generate a number of legitimate DNS

responses, and finally, the victim server is attacked by DDoS. To mitigate such a DNS

107

amplification attack, several security guidelines [74] have been issued, but still, amplification

attacks have been widespread in recent years.

DA06. Random Subdomain [75]

The random sub-domain attack is another type of DNS data flooding attack, sending a

flood of randomized DNS requests for non-existent domains. To succeed in the random

subdomain attack, an attacker first infects numerous clients. Infected clients create request

queries by adding randomly generated subdomain strings to the victim’s target domain. Each

client sends these numerous queries to a DNS recursive server, which attempts to resolve them

with another server. Because this server continuously responds that the domain is nonexistent

(NXDomain), the requests for random lookups eventually exhaust the limited resources, which

delays or stops responses of legitimate lookups and all domains under the DNS server control.

These attacks are used for DDoS attacks against domain name servers.

6.4.3 Abuse of DNS

The latest cyber attacks are active in botnets using C&C (Command Control) servers. A

C&C server is a server that controls communication between attackers and zombie PCs (called

Botnets) to attack a target. An attacker uses a C&C server to make it difficult to find the source

of an attack and to scale to large numbers of bots. To counteract the development of methods for

detecting C&C servers, an attacker exploits DNS to hide the location of C&C servers or to

exfiltrate traffic to conceal the attack. To bypass firewalls, an attacker attempts to send malicious

commands from inside a network to an external C&C server. In such a case, an attacker could

conceal the information of the C&C server by using seemingly innocuous DNS (DNS TTL,

NXDOMAIN) records, as shown in Figure 6.9.

108

Figure 6.8 DNS Attack: Abuse of DNS

DA07. DNS tunneling [76, 77]

DNS Tunneling is a type of bypass technology that allows an attacker to send attack

commands and receive the results without blocking by the defense system. DNS requests may

use up to 255 characters for a domain name, and subdomains separated by “.” can be up to 63

characters. For example, if an attacker sends a DNS query of

“ghAAAAATTTAAAACCCKKakdg.malware.com”, the malware.com name server, as the C&C

server, accepts the query as a malicious attack command. Conversely, the malware.com name

server exploits records (A, CNAME, TXT) of the DNS response query to include the results for

that attack command. Since an attacker and a C&C server communicate through DNS port 53,

DNS tunneling may evade a defensive system.

DA08. DGA [78]

DGA (Domain Generation Algorithm) is an algorithm that randomly generates numerous

domains (from hundreds to tens of thousands). An attacker uses DGA to support malware

attacks. First, an attacker attempts an attack by sending malicious commands to many botnets

infected with malware through a C&C server. However, security devices or agencies may block

109

the IP address of the C&C server to prevent communication. Some malware (such as the Necurs

Botnet) applies numerous domain names generated by DGA to continuously change the domain

of the C&C server. This evades a domain reputation defense to hide the location of the C&C

server.

DA09. Fast Flux [79]

Fast Flux is a method of allocating multiple IP addresses to one domain. By setting the

DNS response TTL (Time to Live) to a minimum value (typically within five minutes) and

changing the DNS record on the DNS server periodically, the corresponding IP address of the

C&C server may be changed repeatedly in a short time interval. This usually relies on a DNS

server controlled by the attacker. If a security manager confirms access to a malicious domain

and blocks the IP address of that C&C server on the firewall, Fast Flux attempts to bypass this

defense.

6.4.4 DNS server structure

As we mentioned in the previous section, DNS has its structural problems. In the

hierarchical structure, if a domain on the lowest level does not exist or has a problem, the DNS

query processed from the top level may be contaminated. Due to the structural weakness, DNS

can easily be attacked, resulting in a large number of victims connected to the DNS server.

Figure 6.10 explains how the DNS attack with the DNS server structure vulnerability works.

110

Figure 6.9 DNS Attack: DNS Server Structure

DA10. DNS NXDOMAIN [80]

NXDOMAIN(Non-Existent Domain) is one of the DNS response queries, which means

that a domain does not exist. An attacker sends numerous queries to DNS servers for non-

existent domains. The DNS servers try to process the queries to find non-existing domains, but

they send back the NXDOMAIN queries because the domains do not exist. Eventually, the cache

in the recursive DNS server could be filled with NXDOMAIN results and users will experience

slower DNS server response times for legitimate DNS requests. The authoritative DNS servers

also spend valuable resources due to the multiple recursive queries to obtain resolution results.

DA11. Phantom Domain [81]

The Phantom Domain attack is similar to the DNS NXDOMAIN attack. However, the

major difference is that attackers use multiple phantom domains to interfere with normal DNS

resolution. First, an attacker sets up several phantom domains which either respond very slowly

or do not respond to DNS requests. Then, numerous bots send malicious DNS queries for the

phantom domains to DNS resolvers. The DNS resolvers handle and deliver the queries to the

authoritative servers. However, under the phantom domain attack, the DNS resolvers will

111

continue to wait for responses and continue to query the unresponsive servers, which consumes

their resources. As a result, the DNS resolvers’ resources are used to process the queries for the

phantom domain, and users could be delayed or unable to receive responses to normal DNS

queries.

6.4.5 Assessment of DNS attacks

To classify DNS attacks, the types of attacks first are evaluated for each factor. Table 6.1

shows the assessment of the 11 DNS attacks introduced in this thesis. There are five criteria for

evaluating DNS attacks. First is the Attack Method, as described above. The Effect factor

classifies attacks according to their intended outcome. The Attack Mode factor refers to whether

the attack is passive (i.e., takes place in response to a user-initiated query) or aggressive

(launched by the attacker). The Attack Source / Target classifies the multiplicity of attack

source(s) and target(s). The Location of Attack Target factor means the location where the attack

is executed. If an attacker attempts to attack the DNS infrastructure directly, it is labeled

“Internal”. Otherwise, if an attacker attempts to attack a target using the DNS infrastructure, it is

labeled “External”.

The assessment for each factor is a filled circle, meaning fully or completely, half-filled

circle, meaning partially, and empty circle, indicating does not apply or not at all. DNS attacks

have a variety of purposes. Hijacking/poisoning-based attacks (DNS cache poisoning, Kaminsky,

and DNS hijacking) mainly have attack targets to lead to specific malicious sites, while flooding-

based attacks (DNS reflection and amplification, DNS flooding, Random sub-domain, DNS

NXDOMAIN, and Phantom domain) have the purpose to exhaust DNS servers’ resources

through direct and aggressive attacks from malware-infected Botnets. Van Rijswijk-Deij et al.

112

[65] found that DNSSEC could be exploited as DNS reflection attacks. Thus, this attack can

target specific servers as well as DNS servers. Finally, attacks that hide their attacks in normal

DNS packets or procedures have the purpose of exploiting DNS.

Table 6.1 Assessment of DNS Attacks

113

Figure 6.10 Classification: DNS Attacks by Purpose

Based on the assessment, Figure 6.11 shows the classification of DNS attacks by purpose.

(1) DNS Server Unable/Slow: These attacks target DNS servers. The attacker sends a

flood of queries to a DNS server, and then the DNS server is forced to exhaust

server resources to handle the enormous queries. Eventually, the DNS server will

not function normally and not be able to provide the domain service to the user.

(2) Specific Target Server Unable: These attacks target a specific server. The attacker

attempts to send heavy traffic to the target server through flooding from the DNS

servers. Attackers exploit open DNS resolvers to amplify heavy traffic volume, as

a third party [52]. The victim server receives a number of legitimate DNS

responses and finally, is subjected to a denial-of-service attack.

(3) Malicious Website: These attacks provide malicious websites to victims despite

requests with normal domains is a DNS Poisoning attack. By manipulating

normal response queries, an attacker can illegally acquire and exploit user

information by providing bogus IP addresses to the user.

114

(4) Hidden Attack: These attacks abuse DNS servers to hide their attack location or

attack message. The attacker tries to conceal the location of C&C servers or to

exfiltrate the botnet command from C&C, using a vulnerability in internal DNS.

6.5 Mitigation

Although DNS has suffered from many attacks, researchers’ efforts to mitigate these

attacks are ongoing. In particular, DNSSEC, which is the product of their efforts, has helped

ensure the integrity of the unreliable DNS data as the main vulnerability of DNS. Additionally,

various advanced methods have been introduced to overcome a number of limitations. This

section briefly describes them.

6.5.1 DNSSEC and redundant DNS

Common DNS attacks, such as cache poisoning and spoofing attacks, occur easily by

forging DNS data and disguising fake DNS queries. Designed to overcome these problems,

DNSSEC uses digital signatures to authenticate the contents of DNS responses, preventing the

use of forged DNS data and enhancing the reliability of DNS queries.

As discussed in Section III, DNSSEC suffers from technical complexity, overhead, and

low deployment [43]. In 2018, NS1 [83] has developed DNSSEC guidelines, so that DNSSEC

can be configured correctly and used more easily. However, this does not solve all DNS security

issues, including vulnerability to DDoS attacks. The additional length of DNSSEC responses

exacerbates the problems of reflection and amplification (DDoS attacks). This dilemma is a

major challenge for DSSEC to address in the future.

115

Redundant DNS servers are one solution to attacks on availability. The DNS standard

specified that up to eight spare servers may be used for redundancy [84], so that if a server is

unreliable or unavailable, another server can provide name lookup for the user [85]. However,

these settings are rarely used in practice by enterprises and ISPs [86], although redundancy has

been recommended for a long time.

Ansari et al. [87] introduced a new technique to overcome the limitation of DNSSEC and

reinforce DNS security, based on using Cloud services for availability and reliability. The

redundancy, flexibility, and managed nature of the cloud make it a promising solution for DNS

security.

6.5.2 Existing DNS mitigation systems

A number of approaches for securing DNS have been proposed. We describe these

systems by grouping them into three categories: Monitoring and Detection Systems, Security

Extensions on DNS records, and Advanced DNS with additional security functions.

Monitoring and detection systems

DNS is vulnerable to the threat of counterfeited data. One approach is to detect and

monitor forged data to distinguish reliable DNS data. The following systems are representative

DNS defense systems that include these functions.

(1) Kopis System [88]: Independently detects malware-related domains at the higher

levels of the DNS hierarchy (e.g., TLD level) by monitoring network traffic at a

high level of the DNS hierarchy. In particular, the Kopis System analyzes the

streams of DNS queries and responses at authoritative name servers. From the

monitored DNS traffic, they extract the statistical features such as the diversity in

116

the network locations and the reputation of the IP space into which the domain

name resolves. Kopis can predict malware-related domains based on monitored

traffic patterns with a statistical classification which is determined from higher

DNS levels’ information. This feature is different from existing detection systems

such as Notos [89] (see below) or Exposure [90]. Even without current IP

reputation information, Kopis can accurately detect malware-related domains.

(2) Domain Watcher System [91]: A detection system that detects malicious domain

names with local and global textual-based features based on machine learning.

This system utilizes three textual features of domains - Lexical features, imitation

features, and bi-gram features. First, they use the lexical features to combine the

existing characteristic data provided by systems such as EXPOSURE [90] or

Detection of Phishing Attacks [92] and new characteristics, such as the number of

special characters and numeric characters in the domain name or the number of

continuous numeric characters, to easily fetch and normalize the pattern. Imitation

features and bi-gram features both utilize the domain information, but imitation

looks at the distance between domain names, while bi-gram looks at the similarity

of the distribution of letters in domain names.

(3) Anax [93]: A DNS protection system that detects the cache poisoning attack using

a large set of open recursive DNS servers (ORDNSs), identifying poisoned DNS

caches through DNS records. An infrastructure is added to intercept DNS

responses (DNS Scanning Points) and collect and process the resulting data (DNS

Data Collector). A Data Preparation Engine analyzes and labels this data, offline,

117

in training mode. A Detection Engine then monitors in real-time DNS responses

and flags suspicious responses as poisoning attempts.

(4) Notos-Dynamic Reputation System for DNS [94]: a dynamic reputation system to

compute scores of domain names. The goal is to determine if a domain is

legitimate or malicious using malicious domains’ distinctive features or

characteristics.

Other methods of DNS attack detection have been proposed. Zhang et al. [95] introduces

a new detection method based on machine learning and hybrid methods, which obtains DNS data

through active domain name data or passive domain name data. Palau et al. [96] proposes an

approach to detect DNS tunneling, based on a Convolutional Neural Network (CNN) with a

minimal architecture complexity. Also, they use their dataset that contains DNS Tunneling

domains generated with five well-known DNS tools. The resulting CNN model correctly

detected more than 92% of total Tunneling domains with a false positive rate close to 0.8%.

Rajendran et al. [97] uses specific properties of DNS amplification and DNS tunneling attacks

and presents a number of countermeasures and mitigation techniques to protect against these

attacks on the DNS infrastructure.

Fast Flux generates a variety of domain names based on specific algorithms to avoid

suppression. Normal DNS-based detection approaches and blacklist filtering are ineffective

against the Fast Flux attack. Methods for analyzing new DNS traffic patterns using these Fast

Flux characteristics have been developed. These methods recognize the overwhelmingly large or

abnormal DNS traffic, filtering the suspicious DNS mapping, and detecting domains of

pseudorandom strings generated by the algorithm compared with legitimate domain patterns [98,

99]. In particular, DNSMap [100] can quickly identify excessive DNS traffic in real-time by

118

analyzing the DNS mapping of abnormal domains and IP addresses through graphical analysis,

unlike conventional methods of domain analysis based on machine learning.

Security extension of DNS records

DNS records provide information about domains that are needed by users. More

information may be added to provide data integrity and improve/extend trust. Several methods

attempt to do so with less overhead than DNSSEC.

(1) The Transaction SIGnature (TSIG) using CGA (Cryptographically Generated

Addresses) Algorithm in IPv6 [101]: DNS has a security problem between the

client and the DNS resolver due to the untrustworthy resolver as discussed in the

‘Vulnerabilities’ section. To address this issue, TSIG is used. TSIG establishes a

trust relationship between a client and a DNS server. This process provides not

only end-to-end authentication but also data integrity between each other through

a one-way hash algorithm and shared keys. However, TSIG faces one problem

that it requires the keys is exchanged manually. A solution to the key distribution

problem is TSIG using CGA. TSIG-CGA provides an automated way for the

negotiation of a shared secret key, with authentication of the host via IPv6’s CGA

algorithm.

(2) DNS-Based Authentication of Named Entities (DANE) [102-104]: DANE takes

advantage of the source of trust provided by DNSSEC to authenticate TLS

certificates. Through TLSA records in the DNS hierarchy, DNSSEC can verify

the integrity of DNS data. DANE was designed to provide a stronger trust anchor

using DNS as the root. Especially, DANE uses the DNSSEC chain of trust to

authenticate X.509 certificates used for Transport Layer Security (TLS) and, as it

119

relies on DNSSEC infrastructure, it can support authentication and data integrity.

DANE allows domain owners to issue their certificates without CAs. Using the

DNS hierarchy as a single trust anchor instead of many existing CAs, DANE

greatly reduces the attack surface. DANE can be used to solve issues related to

CAs’ vulnerability through the use of a new DNS resource record type, TLSA,

signed with DNSSEC. As a result, DANE allows TLS users to better control

certificate validation.

(3) DNS-over-HTTPS (DoH) [105]: DoH is a standard web protocol to send DNS

traffic over HTTPS. DoH is developed to prevent fundamental DNS privacy

problem of unencrypted communication between users and DNS resolvers. As

shown in the previous section, without a trusted DNS resolver, DNS queries

cannot be guaranteed. In DoH, by using HTTPS’s security platform, DNS queries

and responses are protected. Moreover, DNS traffic and requests are not directly

observable because DoH applies the same port 443 used by HTTPS traffic.

Additionally, DoH can be provided by existing DNS servers using a built-in web

server. Starting with Mozilla Firefox and Google Chrome in 2018, most major

web browsers support or plan to support DoH. Despite this, there are some

drawbacks to DoH. First, DNS traffic is encrypted, making it difficult to

track/analyze. Mitigation systems that detect DNS attacks based on DNS data

analysis will fail to function. Second, the prerequisite for DoH is the support of a

trusted DNS resolver. Each web browser, such as Firefox-Cloudflare and

Chrome-Google OpenDNS, provides a trusted open DNS resolver. However,

traffic is centralized with a few DNS resolvers, with corresponding privacy and

120

performance concerns. Finally, the policies of these enterprises will be difficult to

ensure transparency in DNS operations.

Advanced DNS with additional secure functions

According to the DNSSEC deployment tracking system SecSpider [106], current

DNSSEC-enabled zones number approximately 3.3 million. It seems that the full deployment of

DNSSEC will take considerable time despite many efforts. Thus, additional security functions

for DNS are required. The following are methods for improving DNS security.

(1) DNS Proxy Server (DPS) and BIND [107]: a new approach to detect cache

poisoning attacks and then send an additional request for the same DNS Resource

Record using a local proxy for the BIND caching server. This defensive system

makes cache poisoning attacks more difficult.

(2) T-DNS [108]: DNS uses unconnected UDP as the standard protocol. However,

because of the poorly secured UDP protocol, DNS is subject to attacks such as

spoofing and flooding. T-DNS uses TCP and transport layer security (TLS) to

provide DNS security. T-DNS provides more secure DNS data through TCP

encryption, reduces the impact of DoS attacks by establishing mutual connections,

and overcomes the limitations of UDP’s response size. DNS based on TLS can

provide more secure privacy, support large payload, and mitigate spoofing and

reflection DDoS attacks compared to the use of existing UDP protocols.

However, the fundamental problems of TCP, latency, and resource needs, remain.

(3) S-DNS [109]: A security solution to prevent DNS cache poisoning and spoofing

attacks. Based on the predictability measures and timing analysis, S-DNS

mitigates man-in-the-middle attacks in the DNS hierarchy. This protocol has

121

effects on decreasing the probability of the attack and also provides a simple

security mechanism with lightweight computation and overheads.

(4) Response Rate Limiting (RRL) [73]: A defense mechanism to reduce the impact

of DNS amplification attacks and reflection attacks. The DNS server will respond

a limited number of times to requests for a domain name resolution from a

particular IP address, making it more difficult to flood the victim with traffic.

6.5.3 Overall assessment of DNS mitigation system

Table 6.2 shows the assessment of whether the mitigation system can protect against

DNS attacks. A full circle denotes yes or fully, a half-circle denotes partially, and empty circles

denote no or not at all. Each mitigation system was developed to solve specific vulnerabilities in

DNS. Several key findings of our assessment are provided:

(1) DNSSEC is a major enhancement to DNS but can be exploited for DDoS attacks.

According to the 2019 report released by Neustar [110], the number of DDoS

attacks increased by 133% and the average DDoS attack size is 7.5 Gbps

compared to 2018.

(2) Most monitoring and detection systems can observe the malicious DNS traffic,

not protect against the attacks. But, using these mitigation systems, it is possible

to filter or protect against the DNS data attacks.

(3) TSIG with CGA and DANE are solutions to overcome DNSSEC’s limitations and

are promising alternatives.

(4) Because most advanced DNS mitigation systems with additional security

functions are focused on specific security problems in DNS, they do not cover all

122

DNS attacks. On the other hand, T-DNS prevents most of the DNS attacks

because they address the fundamental protocol problem in the DNS protocol.

However, T-DNS, based on the TCP protocol, greatly helps improve DNS

privacy, while its latency is the slower, and overall cost is significant compared to

the UDP protocol.

Table 6.2 Assessment of DNS Mitigation

123

6.5.4 Secure/Enterprise DNS provider

Unlike these mitigation systems which provide additional security functions or

monitor/analyze/detection techniques, an openDNS of major companies or organizations that

ensure improved security, reliability and speed would be better option to defend against some of

the DNS attacks. It is called Secure / Enterprise DNS, which is a fast and reliable DNS service

from large organizations. Enterprise DNS centrally manages its security architecture that

guarantees a more sophisticated and reliable DNS service.

Table 6.3 List of the 10 Enterprise DNS providers

To better understand the current Enterprise DNS situation, we provide and evaluate a list

of 10 large Enterprise DNS providers, as shown in Figure 6.3. Each organization provides its

open DNS and can be set up and used by anyone on their device. Except for Microsoft Azure and

Oracle, most providers support DNSSEC. Azure and Oracle protect DNS through their systems.

124

Another factor is the support of the Certification Transparency and Certification

Authority (CAA) records, which are techniques to compensate for weaknesses and defects in the

PKI-certificate system. While all organizations provide Certification Transparency, some do not

offer CAA records. Regardless of whether DoH or DoT is supported or not, it is judged as the

support of a security solution for certificates.

Almost all providers support DoH and/or DoT, except for Oracle and Verisign. We

expect that the support of the DoH/DoT would increase with time.

Finally, all providers offer TLS 1.2 for cipher transmission, especially Google, Cloudfare,

and Quad9 that support DoH, up to the latest TLS 1.3. Therefore, these institutions are expected

to provide more stable DoH based on TLS 1.3 in the future.

125

CHAPTER 7

Conclusion and Future Work

7.1 Conclusion

This study examines the security issues of authentication and authorization in IoT

networks and proposes advanced authentication and authorization protocols suitable for various

IoT network environments. In particular, by analyzing and comparing three typical IoT

environments of Enterprise, Smart Home, and LoRaWAN, our proposed protocol was proved for

practical and specific robust authentication and authorization protocol based on expanded OAuth

2.0 and Kerberos v5. This study also includes a survey of DNS security, starting with an

overview of DNS vulnerabilities and attacks. Attacks are classified by purpose. Methods for

defending against these attacks are described and assessed. We conclude with a summary of the

current state of DNS security.

126

7.1.1 IAuth+

IoT security suffers from various vulnerabilities depending on its environment, which an

attacker could target to launch authentication and authorization attacks. This thesis concludes

that the adaptation and fusion of two robust authentication and authorization protocols: OAuth

2.0 and Kerberos v5, can mitigate these issues in three specific environments, the Enterprise IoT

network, the smart home network, and LoRaWAN. Table 7.1 shows the comparison with the

three different scenarios.

Table 7.1 Comparison with 3 scenarios – Enterprise, Smart Home, and LoRaWAN

Enterprise IoT Smart Home LoRaWAN

Main Configuration

Authorization Server DNS Server KDC

Authorization Server Authorization Server KDC

Main Features Many Users/Devices Network Infrastructure Small Users/Devices No Infrastructure

Various Environments Standard LoRaWAN Protocol

Authentication Devices, Users, DNS configuration Devices, Users Devices, Users

Authorization Administrator, Service Homeowner, Service Administrator, Service

Provider Enterprise Network Vendor LoRaWAN Provider

DNS Yes No No

Administrator IT Technitian General User General User (or LoRaWAN Provider)

Network Support Yes No Yes

127

The basic mechanisms are the same, and the objects of authentication and authorization

are almost similar. However, since the characteristics of each network environment are different,

it is essential to adjust configuration according to the situation. Enterprise network has sufficient

network infrastructure and IT technical support, whereas Smart Home has a limited network

structure and support with relatively few devices and users. LoRaWAN is similar to Enterprise

network but aims to improve the problems of existing standard protocols - LoRaWAN v1.1 and

provide robust authentication and authorization protocols suitable for constrained network

environments.

Also, the STRIDE threat modeling results help verify the IAuth+ security architecture

process for IoT network environments and the analysis, and evaluation prove the IAuth+’s

adaptation for various environments and security capacity for robust authentication and

authorization.

7.1.2 A Survey of DNS Vulnerabilities and Attacks

This study presents a survey of DNS security. The background of fundamental DNS and

DNSSEC is described, with an explanation for the motivation of DNSSEC. DNS is essential for

the proper operation of the Internet, but it is still subject to various attacks due to its

vulnerabilities, lack of widespread adoption of available mitigation techniques, and limitations of

those techniques. These vulnerabilities were described, and DNS attacks were classified based on

those vulnerabilities. The classification of DNS attacks supports understanding and analysis of

future DNS attacks. In addition, several methods suggested in the literature for defending against

such attacks were summarized. The analysis of various mitigation systems suggests indicators

for future DNS developments.

128

7.2 Recommendations for Future Work

Based on this study, the following topics are recommended for future work.

• Future research is needed to implement the simulation of IAuth+ and other related

authentication protocols for practical evaluation. In this dissertation, we analyzed the

comparison of the several factors with IAuth+ and other related works using the

theoretical approach.

• In this study, we focused on potential threats related to authentication and authorization

in various IoT networks. Expansion of research scope against DDoS and other

cyberattacks would be valuable for future work to support secure IoT network services.

129

REFERENCES

[1] Gartner. Inc., “Hype Cycle for the Internet of Things 2020,”

http://www.gartner.com/technology/research/methodologies/hype-cycle.jsp

[2] Constantinos Kolias et al., “DDoS in the IoT: Mirai and Other Botnets,” Computer (Long

Beach, California), vol. 50, pp. 80-84, 2017.

[3] Sonicwall, “2021 Cyber Threat Report,” https://www.sonicwall.com/2021-cyber-threat-

report

[4] Stuart Cheshire and Marc Krochmal, “Multicast DNS,” RFC 6762, February 2013.

[5] Tae Hyun Kim and Douglas Reeves. “A survey of domain name system vulnerabilities and

attacks,” Journal of Surveillance, Security and Safety, vol. 1.1, pp. 34-60, 2020.

[6] Sejun Lee, Jaehoon Paul Jeong and Jung-Soo Park, “DNSNA: DNS name auto-

configuration for internet of things devices,” 18th International Conference on Advanced

Communication Technology (ICACT), pp. 410-416, IEEE, 2016.

[7] Keuntae Lee et al., “Secure DNS name autoconfiguration for IPv6 internet-of-things

devices,” 2016 International Conference on Information and Communication Technology

Convergence (ICTC), pp. 564-569, IEEE, 2016.

[8] Lan Li, “Study on security architecture in the Internet of Things,” Proceedings of 2012

International Conference on Measurement, Information and Control, vol. 1, pp. 374-377,

2012.

[9] Pallavi Sethi, and Smruti R. Sarangi, “Internet of things: architectures, protocols, and

applications,” Journal of Electrical and Computer Engineering, 2017.

[10] Rescorla, Eric, and Nagendra Modadugu. “Datagram transport layer security version 1.2,”

RFC 6347, 2012.

[11] Shelby, Zach, et al., “The constrained application protocol (CoAP),” RFC 7252, 2014.

[12] Hyun Cheon Hwang, JiSu Park, and Jin Gon Shon, “Design and implementation of a

reliable message transmission system based on MQTT protocol in IoT,” Wireless Personal

Communications, vol. 91, no. 4, pp. 1765-1777, 2016.

[13] Geo-Su Yim, “IoT MQTT Security Protocol Design Using Chaotic Signals,” The Korea

Institute of Information & Electronic Communication Technology, vol. 11, No. 6, pp.778-

783, Dec 2018.

130

[14] Kewei Sha, et al., “On security challenges and open issues in Internet of Things,” Future

Generation Computer System, pp. 326–337, 2018.

[15] Hassan and Wan Haslina, “Current research on Internet of Things (IoT) security: A

survey,” Computer Networks, vol. 148, pp. 283-294, 2019.

[16] Tarak Nandy, et al., “Review on Security of Internet of Things Authentication Mechanism,”

IEEE Access, vol. 7, pp. 151054-151089, 2019.

[17] Glass Steven, et al., “Mobile IP Authentication. Authorization, and Accounting

Requirements,” RFC 2977, 2000.

[18] Aleksandr Ometov, et al., “Multi-factor authentication: A survey,” Cryptography, vol. 2.1,

2018.

[19] Gubbi Jayavardhana, et al., “Internet of Things (IoT): A vision, architectural elements, and

future directions.” Future generation computer systems, vol. 29.7, pp. 1645-1660, 2013.

[20] oneM2M, “Object Identifier based M2M Device Identification Scheme,” http:

//www.onem2m.org

[21] Dick Hardt, et al., “The OAuth 2.0 Authorization Framework,” RFC 6749, October 2012.

[22] Simone Cirani, et al., “IoT-OAS: An OAuth-Based Authorization Service Architecture for

Secure Services in IoT Scenarios,” IEEE Sensors Journal, vol. 15, pp. 1224-1234, 2015.

[23] Sebastian Echeverria et al., “Authentication and authorization for IoT devices in

disadvantaged environments,” 2019 IEEE 5th World Forum on Internet of Things (WF-

IoT), IEEE, 2019.

[24] Torsten Lodderstedt, Mark McGloin, and Phil Hunt, “OAuth 2.0 Threat Homeland Security

Considerations,” RFC 6819, IETF, January 2013.

[25] Clifford Neuman, et al., “The Kerberos Network Authentication Service (V5),” RFC 4120,

July 2005.

[26] Zakariae Tbatou, et al., “A New Mutuel Kerberos Authentication Protocol for Distributed

Systems,” International Journal Network Security, vol. 19.6, pp. 889-898, 2017.

[27] Slama Dirk, et al., “Enterprise IoT: Strategies and Best practices for connected products and

services,” O'Reilly Media, Inc., 2015.

[28] J. Jeong, S. Park, L. Beloeil, and S. Madanapalli, “IPv6 Router Advertisement Options for

DNS Configuration,” IRFC 6106, November 2010.

131

[29] Matt Crawford and Brian Haberman, “IPv6 Node Information Queries,” RFC 4620, August

2006.

[30] Paul Vixie, et al., “Dynamic Updates in the Domain Name System (DNS UPDATE),” RFC

2136, April 1997.

[31] Waqar Ali, et al., “IoT based smart home: Security challenges, security requirements and

solutions.” 2017 23rd International Conference on Automation and Computing (ICAC).

IEEE, 2017.

[32] Komninos Nikos, Eleni Philippou, and Andreas Pitsillides, “Survey in smart grid and smart

home security: Issues, challenges and countermeasures,” IEEE Communications Surveys &

Tutorials, vol. 16.4, pp. 1933-1954, 2014.

[33] Ryan Heartfield, et al., “A taxonomy of cyber-physical threats and impact in the smart

home.” Computers & Security, vol. 78, pp. 398-428, 2018.

[34] Schiefer Michael, “Smart home definition and security threats,” 2015 ninth international

conference on IT security incident management & IT forensics, IEEE, 2015.

[35] Google, “Google Cloud IoT Core,” https://cloud.google.com/iot-core

[36] Standard, OASIS, “MQTT version 3.1.1,” URL http://docs.oasis-open.org/mqtt/mqtt/v3 1

(2014).

[37] A. Mackman, et al., “Improving Web Application Security: Threats and Countermeasures,”

Microsoft, 2003.

[38] Mockapetris Paul, “Domain names-implementation and specification,” RFC1035, 1987.

[39] Mockapetris Paul, “Domain names-implementation and facilities,” RFC1034, 1987.

[40] Engel S., “My ether wallet DNS attack explained,” https://cryptovoid.net/mew-dns-attack-

explained

[41] Arends Roy, et al., “DNS security introduction and requirements,” RFC 4033, 2005.

[42] Eastlake Donald and C. Kaufman, “Domain name system security extensions,” RFC 2535,

1999.

[43] Chung Taejoong, et al., “A longitudinal, end-to-end view of the DNSSEC ecosystem,”

Proceedings of the 26th USENIX Conference on Security Symposium, pp. 1307-1322,

August 2017.

[44] NIST, “Estimating USG IPv6 and DNSSEC external service deployment status,”

https://fedv6-deployment.antd.nist.gov/cgi-bin/generate-gov

132

[45] Roosa Steven B. and Schultze Stephen, “Trust darknet: control and compromise in the

internet's certificate authority model,” IEEE Internet Computing, vol. 17.3, pp. 18-25, 2013.

[46] Wikipedia, “2016 Dyn cyberattack,” https://en.wikipedia.org/wiki/2016_Dyn_cyberattack.

[47] NETSCOUT, “NETSCOUT's 14th Annual Worldwide Infrastructure Security Report,”

https://www.netscout.com/report

[48] Casalicchio Emiliano, Caselli Marco, and Coletta Alessio, “Measuring the global domain

name system,” IEEE network, vol. 27.1, pp. 25-31, 2013.

[49] Wikipedia, “List of DNS resource records,” https://en.wikipedia.org/wiki/List-of-DNS-

record-types

[50] Cheshire Stuart and Krochmal Marc. “Multicast DNS”, RFC 6762, 2013.

[51] Aboba Bernard, Thaler Dave, and Esibov Levon, “Link-local Multicast Name Resolution

(LLMNR)”, RFC 4795, January 2007.

[52] Andress Jason, “The basics of information security: understanding the fundamentals of

InfoSec in theory and practice,” 2nd ed. Syngress, 2014.

[53] Bates Samantha, et al., “Evidence of decreasing internet entropy: the lack of redundancy in

DNS resolution by major websites and services,” No. w24317, National Bureau of

Economic Research, SSRN Electronic journal, 2018.

[54] Schiffman Mike, “Bound by tradition: a sampling of the security posture of the internet's

DNS servers,” Linux Security 2003, http://packetfactory.openwall.net/papers/DNS-

posture/DNS-posture-1.0.pdf

[55] Migault Daniel, Cédric Girard, and Laurent Maryline, “A performance view on dnssec

migration,” 2010 International Conference on Network and Service Management (CNSM),

pp. 469-474, IEEE, 2010.

[56] Klein Amit, “BIND 9 DNS cache poisoning,” SecuriTeam, 2007,

https://securiteam.com/securitynews/5vp0l0um0a

[57] Yu Xi, Chen Xiaochen, and Xu Fangqin, “Recovering and protecting against DNS cache

poisoning attacks,” 2011 International Conference on Information Technology, Computer

Engineering and Management Sciences, vol. 2, pp. 120-123, IEEE, 2011.

[58] Ager Bernhard, Dreger Holger, and Feldmann Anja, “Predicting the DNSSEC overhead

using DNS traces,” In 2006 40th Annual Conference on Information Sciences and Systems,

IEEE, 2006.

133

[59] Van Adrichem NLM, Blenn N, Lua AR, Wang X, Wasif M, et al., “A measurement study

of DNSSEC misconfigurations.” Security Informatics, vol. 4.1, pp. 1-14, 2015.

[60] Deccio Casey, et al., “Quantifying and improving dnssec availability,” 2011 Proceedings of

20th International Conference on Computer Communications and Networks (ICCCN), pp.

1-7, IEEE, 2011.

[61] Clark Lin. “A cartoon intro to DNS over HTTPS,” https://hacks.mozilla.org/2018/05/a-

cartoon-intro-to-dns-over-https

[62] Droms Ralph and Arbaugh William, “Authentication for DHCP messages,” RFC 3118,

2001.

[63] Bau Jason and Mitchell John C., “A security evaluation of DNSSEC with NSEC3,”

Proceedings of the Network and Distributed System Security Symposium (NDSS), pp. 18,

2010.

[64] Internet society, “State of DNSSEC deployment 2016,”

https://www.internetsociety.org/resources/doc/2016/state-of-dnssec-deployment-2016

[65] van Rijswijk-Deij Roland, Sperotto Anna, and Pras Aiko, “DNSSEC and its potential for

DDoS attacks: a comprehensive measurement study,” Proceedings of the 2014 Conference

on Internet Measurement Conference, pp. 449-460, November 2014.

[66] Neustar, “DNSSEC: how Savvy DDoS attackers are using our defenses against us,”

Security Research Report, 2016, https://hello.neustar.biz/dnssec_report_it_security_lp.html

[67] Alharbi Fatemah, et al., “Collaborative Client-Side DNS Cache Poisoning Attack,” IEEE

INFOCOM 2019-IEEE Conference on Computer Communications, April 2019.

[68] Kaminsky Dan, “Black ops 2008: It's the end of the cache as we know it,” Black Hat USA,

2008.

[69] Zhauniarovich Yury, et al., “A survey on malicious domains detection through DNS data

analysis,” ACM Computing Surveys (CSUR), vol. 51.4, pp. 1-36, 2018.

[70] Vissers Thomas, et al., “The wolf of name street: hijacking domains through their

nameservers,” Proceedings of the 2017 ACM SIGSAC Conference on Computer and

Communications Security, pp. 957-970, 2017.

[71] Rascagneres Paul. Mercer Warren, “DNSpionage campaign targets middle east,”

https://blogs.cisco.com/security/talos/dnspionage-campaign-targets-middle-east

134

[72] Thornewell PM, Golden LM. “DNS flood protection platform for a network.” US Patent,

2012.

[73] Rozekrans Thijs, Mekking Matthijs, and de Koning Javy, “Defending against DNS

reflection amplification attacks,” University of Amsterdam System & Network Engineering

RP1, 2013.

[74] Chandramouli Ramaswamy and Rose Scott, “Secure domain name system (DNS)

deployment guide,” NIST Special Publication, vol. 800, pp. 81-82, 2006.

[75] Feibish SL, Afek Y, Bremler-Barr A, Cohen E, and Shagam M, “Mitigating DNS random

subdomain DDoS attacks by distinct heavy hitters sketches,” Proceedings of the fifth

ACM/IEEE Workshop on Hot Topics in Web Systems and Technologies, pp. 1-6, October

2017.

[76] Farnham Greg and Atlasis Atlasis, “Detecting DNS tunneling,” SANS Institute InfoSec

Reading Room, vol. 9, pp. 1-32, 2013.

[77] van Leijenhorst T, Chin KW, and Lowe D, “On the viability and performance of DNS

tunneling,” The 5th International Conference on Information Technology and Applications

(ICITA), pp. 560-566, 2008.

[78] Zhou Yonglin, et al., “DGA-based botnet detection using DNS traffic,” Internet Service

Information Security, vol. 3.3/4, pp. 116-123, 2013.

[79] Metcalf, Leigh B, Dan Ruef, Jonathan M., and Spring, “Open-source measurement of fast-

flux networks while considering domain-name parking,” The LASER Workshop: Learning

from Authoritative Security Experiment Results (LASER 2017), USENIX Association, pp.

12-24, October 2017.

[80] Dagon David, et al., “Corrupted DNS resolution paths: The rise of a malicious resolution

authority,” Proceedings of the 15th Network and Distributed System Security Symposium

(NDSS), February 2008.

[81] Mergenhagen Paul, “Deindexing Phantom Deomains,” Mainstreethost,

https://www.mainstreethost.com/blog/deindexing-phantom-domains

[82] Krämer Lukas, et al., “Amppot: Monitoring and defending against amplification ddos

attacks,” International Symposium on Recent Advances in Intrusion Detection, Springer,

November 2015.

[83] NS1, “Enabling DNSSEC on a primary zone,” https://ns1.com/knowledgebase/dnssec

135

[84] Elz Robert, Bush R, Bradner S, and Patton M, “Selection and Operation of Secondary DNS

Servers,” RFC 2182, 1997.

[85] Yu Yingdi, et al., “Measuring the placement of DNS servers in top-level-domain,” Verisign

Technical Report, 2011.

[86] Jean-Yves Bisiaux, “DNS threats and mitigation strategies,” Network Security, vol. 7, pp.

5-9, 2014.

[87] Ansari Ahlam, et al., “Reinforcing security of DNS using AWS cloud,” Proceedings of the

3rd International Conference on Advances in Science & Technology (ICAST), April 2020.

[88] Antonakakis Manos, et al., “Detecting malware domains at the upper DNS hierarchy,”

Proceedings of the 20th USENIX Conference on Security, vol. 11, pp. 1-16, August 2011.

[89] Antonakakis M, Perdisci R, Dagon D, Lee W, and Feamster N, “Building a dynamic

reputation system for DNS,” Proceedings of the 19th USENIX Conference on Security, pp.

273-289, August 2010.

[90] Bilge Leyla, et al., “EXPOSURE: finding malicious domains using passive DNS analysis,”

Proceedings of the Network and Distributed System Security Symposium, February 2011.

[91] Zhang Panpan, et al., “Domain watcher: detecting malicious domains based on local and

global textual features,” Procedia Computer Science, vol. 108, pp. 2408-2412, 2017.

[92] Muhammet Baykara and Ziya Gürel Zahit, “Detection of phishing attacks,” 2018 6th

International Symposium on Digital Forensic and Security (ISDFS), IEEE, pp. 1-5, March

2018.

[93] Antonakakis Manos, et al., “A centralized monitoring infrastructure for improving dns

security,” Proceedings of the 13th International Conference on Recent Advances in

Intrusion Detection, Springer, pp. 18-37, September 2010.

[94] Antonakakis Manos, et al., “Notos: Building a Dynamic Reputation System for DNS,”

GEORGIA INST OF TECH ATLANTA COLL OF COMPUTING, 2010.

[95] Zhang Kunsan, et al., “Detection of malicious domain name based on DNS data analysis,”

Journal of Physics: Conference Series, vol. 1544, 2020.

[96] Palau F, Catania C, Guerra J, Garcia S, and Rigaki M, “DNS tunneling: a deep learning

based lexicographical detection approach,” Cryptography and Security, 2020.

136

[97] Rajendran, Balaji. “DNS amplification & DNS tunneling attacks simulation, detection and

mitigation approaches,” 2020 International Conference on Inventive Computation

Technologies (ICICT), IEEE, pp. 230-236, February 2020.

[98] Berger Andreas, et al., “Mining agile dns traffic using graph analysis for cybercrime

detection,” COMPUT NETWORKs, vol. 100, pp. 28-44, 2016.

[99] Perdisci Roberto, ignio Corona, and Giacinto Giorgio. “Early detection of malicious flux

networks via large-scale passive DNS traffic analysis,” IEEE Transactions on Dependable

and Secure Computing, vol. 9.5, pp. 714-726, 2021.

[100] PerfOps, “DNSMap,” https://dnsmap.io

[101] Vixie Paul, et al., “Secret key transaction authentication for DNS (TSIG),” RFC2845,

2000.

[102] Barnes Richard, “Use cases and requirements for DNS-based authentication of named

entities (DANE),” RFC6394, 2011.

[103] Gudmundsson Olafur, “Adding acronyms to simplify conversations about DNS-based

authentication of named entities (DANE),” RFC 7218, 2014.

[104] Zhu Liang, et al., “Measuring dane tlsa deployment,” International Workshop on Traffic

Monitoring and Analysis, Springer, pp. 219-232, April 2015.

[105] Hoffman P and McManus P, “DNS queries over HTTPS (DoH),” RFC 8484, 2018.

[106] SecSpider, “Global DNSSEC deployment tracking,” http://secspider. net

[107] Trostle Jonathan, van Besien Bill, and Pujari Ashish, “Protecting against DNS cache

poisoning attacks,” 2010 6th IEEE Workshop on Secure Network Protocols, IEEE, pp. 25-

30, October 2010.

[108] Zhu Liang, et al., “T-DNS: Connection-oriented DNS to improve privacy and security,”

2015 IEEE symposium on security and privacy, IEEE, pp 379-380, 2015.

[109] Bassil Ramzi, et al., “Security analysis and solution for thwarting cache poisoning attacks

in the domain name system,” 2012 19th International Conference on Telecommunications

(ICT), pp. 1-6, April 2012.

[110] Neustar, “2019 Cyber threats and trends report,”

https://www.home.neustar/resources/whitepapers/2019-cyberthreats-trends-report

[111] J. Son, “Vulnerability Analysis and Secure Coding of JWTbased Authentication Server,”

Proceeding of KISS, 2016.

137

[112] Raza Usman, Parag Kulkarni, and Mahesh Sooriyabandara, “Low power wide area

networks: An overview,” IEEE communications surveys & tutorials, vol. 19.2, pp. 855-

873, 2017.

[113] Lora Alliance, “LoRaWAN 1.1 Specification,” October 2017,

http://lora-alliance.org/lorawan-for-developers

[114] Butun Ismail, Pereira Nuno, and Gidlund, Mikael, “Analysis of LoRaWAN V1.1

Security,” In Proceedings of the 4th ACM MobiHoc Workshop on Experiences with the

Design and Implementation of Smart Objects, pp. 5:1-5:6, June 2018.

[115] Butun Ismail, Nuno Pereira, and Mikael Gidlund. “Security risk analysis of LoRaWAN

and future directions,” Future Internet, vol. 11.1, 2019.

[116] Han Jialuo and Jidong Wang, “An enhanced key management scheme for LoRaWAN,”

Cryptography, vol. 2.4, 2018.

[117] SeungJae Na, et al., “Scenario and countermeasure for replay attack using join request

messages in LoRaWAN,” 2017 International Conference on Information Networking

(ICOIN), IEEE, 2017.

[118] W. Sung, H. Ahn, J. Kim and S. Choi, “Protecting end-device from replay attack on

LoRaWAN,” 2018 20th International Conference on Advanced Communication

Technology (ICACT), pp. 167-171, 2018.

[119] Abdollah Jabbari and Jamshid. Bagherzadehmohasefi, “A Secure and LoRaWAN

Compatible User Authentication Protocol for Critical Applications in the IoT

Environment,” in IEEE Transactions on Industrial Informatics, vol. 18, no. 1, pp. 56-65,

Jan. 2021.

[120] Danish, Syed Muhammad, et al., “A lightweight blockchain based two factor

authentication mechanism for LoRaWAN join procedure,” 2019 IEEE International

Conference on Communications Workshops (ICC Workshops), IEEE, 2019.

[121] Vanga Odelu, Ashok Kumar Das, and Adrijit Goswami, “An efficient biometric-based

privacy-preserving three-party authentication with key agreement protocol using smart

cards,” Security and Communication Network, vol. 8, no. 18, pp. 4136–4156, 2015.

[122] Adelantado Ferran, et al., “Understanding the limits of LoRaWAN,” IEEE

Communications magazine, vol. 55, no. 9, pp. 34-40, 2017.

138

[123] Islam, Muhammad Ariful, et al. “A modified and secured RSA public key cryptosystem

based on “n” prime numbers,” Journal of Computer and Communications, vol. 6, no. 03,

2018.

ProQuest Number:

INFORMATION TO ALL USERS The quality and completeness of this reproduction is dependent on the quality

and completeness of the copy made available to ProQuest.

Distributed by ProQuest LLC ( ). Copyright of the Dissertation is held by the Author unless otherwise noted.

This work may be used in accordance with the terms of the Creative Commons license or other rights statement, as indicated in the copyright statement or in the metadata

associated with this work. Unless otherwise specified in the copyright statement or the metadata, all rights are reserved by the copyright holder.

This work is protected against unauthorized copying under Title 17, United States Code and other applicable copyright laws.

Microform Edition where available © ProQuest LLC. No reproduction or digitization of the Microform Edition is authorized without permission of ProQuest LLC.

ProQuest LLC 789 East Eisenhower Parkway

P.O. Box 1346 Ann Arbor, MI 48106 - 1346 USA

29100678

2022