데이즈

Introduction

Device drivers commonly execute in the kernel to achieve high performance and easy access to kernel services.

This paper introduces the Microdrivers architecture that achieves high performance and compatibility by leaving critical path code in the kernel and moving the rest of the driver code to a user-mode process.

Executing drivers in user mode provides several important benefits

 - driver developers can take advantage of user mode tools such as profilers, libraries, scripting languages and advanced debuggers

 - the user/kernel boundary isolates the kernel from driver failures

However, existing user mode drivers frameworks suffer from one of two problems

 - previous attempts to execute unmodified drivers in user mode performed poorly

 - user mode driver frameworks that achieve high performance require complete rewrites of the driver

The result is a new architecture for device drivers that we call Microdrivers. A microdriver is a device driver that is split into a kernel-level k-driver and a user-level u-driver. This architecture yields four concrete benefits over traditional kernel drivers.

1. user-level programming
1. The u-driver can be compiled and debugged with standard user-mode tools
2. good common-case performance
1. Microdrivers have common case performance comparable to traditional device drivers and better than kernel driver code executing fully in user mode.
3. Fault isolation
1. Microdrivers isolate faults better than traditional device drivers, because a buggy u-driver will not crash the entire system.
4. Compatibility
1. Microdrivers are compatible with commodity operating systems

DriverSlicer's splitter partitions driver code such that performance critical functions remain in the kernel.

DriverSlicer's code generator emits marshaling code to pass data between the microdriver components. Unlike traditional marshaling code for RPC, this tool employs static analysis to reduce the amount of data copied.

We evaluate the Microdrivers architecture and DriverSlicer on drivers from the Linux 2.6.18.1 kernel.

1. U-Drivers can be written and debugged with common user-level programming tools
2. Micro drivers achieve common-case performance similar to native kernel drivers
3. Microdrivers isolate failures in the u-driver from the kernel
4. Microdrivers reduce the amount of driver code running in the kernel

Enables applications to run correctly when device drivers fail.

We introduce a new operating system mechanism called a shadow driver.

A shadow driver monitors device drivers and transparently recovers from drivers failures.

85% Windows XP crashes - driver related

Linux drivers 7X more bugs than the kernel

Why do drivers fail?

There are so many of them! (70% of Linux kernel, 35,000 in Windows XP)

Developed by many third party suppliers

Privileged access inside your kernel!

Solutions

Change kernel-driver interaction

Detect driver failure

Isolate fault, avoid kernel corruption

Conceal driver failure, service requests

Restart & initialize driver

Shadow Drivers

Kernel agents attached to each device driver

Allow transparent restart of failed drivers

Implements both kernel and driver class interfaces

Shadow Driver Needs

Coordination - management of shadow drivers - Shadow manager

Redirection mechanism - transparent monitoring and recovery - Taps

Isolation service - prevents driver errors from corrupting the kernel - NOOKS

Object tracking service - track kernel objects created by the driver - NOOKS

Passive mode: normal operation

monitor communication driver-kernel

Active mode: fault detected

restart, initialize, transfer state

respond to calls from kernel

Limitations

Drivers that cannot be reloaded dynamically

Permanent faults

Ad-hoc driver-kernel communication

Irreversible side effects

Fault isolation is hard

Failure detection imperfect

How would the system be simplified?

Clear bounds between kernel/driver space

Standard communication, clean interface

More stateless drivers, easier to restart

대부분의 시스템 failures는 운영체제의 장치 드라이버에서 나타나며 예전 failure-isolation 커널를 포함한 시스템에서 커널 자체적 손실로부터 장치 failures를 예방하고 설계하였다. 해서 본 논문에서는 kernel에서 safe initial state로부터 failed driver를 reload하고 restart를 하게 설계하였다. Isolation 기술은 시스템의 crash frequency를 줄일 수 있으며 이를 본 논문에서 제안하는 shadow drivers에 적용하였다.

본 논문에서는 장치 드라이버가 실패 할 경우 지속적인 실행을 위해 응용프로그램을 활성화하기 위해 shadow drivers라는 새로운 운영 체제 메커니즘을 소개한다. Commodity OS에서 신뢰성을 개선하는 것은 가장 큰 도전 과제 중 하나이며 Shadow driver에 관한 내용을 자세히 설명 하였다. Shadow driver는 4가지 원칙을 반영하였는데 첫 번째로 디바이스 드라이버 failures는 드라이버의 client로부터 conceal 해야 하며, 두 번째로 복구 로직은 하나의 서브 시스템에 집중해야 한다. 세 번째로 드라이버 복구 로직은 generic 해야 하며 마지막으로 복구 서비스는 필요하지 않을 때는 작은 오버헤드가 있어야 한다. Shadow driver는 각 디바이스 드라이버에 장착 커널 에이전트이다. 또한 실패 드라이버의 transparent restart할 수 있으며 kernel과 driver class interface 모두 구현한다. Shadow Driver는 4가지 Needs가 있는데 Coordination, Redirection mechanism, Isolation service, Object tacking service 이다. Coordination은 shadow driver를 관리해주는 shadow manager가 있으며 새로운 shadow driver를 instantiate하고 디바이스 드라이버와 커널 사이에 Call Interface로 taps을 inject한다. Taps는 Redirection mechanism으로 shadow driver functioning driver와 kernel 통신 사이에서 모니터링하며 고장 및 복구하는 동안 component가 다른 것으로 impersonate한다. Nooks OS를 이용하여 isolation service와 Object tracking service 할 수 있으며 isolation은 손상된 커널로부터 driver error를 예방할수 있으며 object tracking service를 통해 driver에 의해 track kernel object를 생성할 수 있다. 본 논문에서는 Passive mode와 Active mode를 소개 하고 있는데 Passive mode는 driver kernel의 통신을 모니터링하는 normal operation이며 Active mode는 restart, initialize, transfer state 등과 같은 fault detected operation이다. Active mode는 커널로부터 call를 response하여 recovery를 한다.

본 논문은 새로운 시스템의 application reliability를 개선하기 위해 shadow drivers 기법을 제안하였고, shadow driver는 recovery 기술에서 효과적이고 transparent하며 현존하는 드라이버의 코드를 바꾸지 않아도 된다는 것에 매력적인 장치 드라이버이다.

Goals

1. Isolation
2. Recovery
3. Backward Compatibility

논문의 목적

커널의 reliability를 높이는 것

Extensions이란?

하나의 도메인이면서 모듈 역할을 하는 존재

loadable module은 커널의 모듈화를 높여줌

하드웨어 지원 없이 isolation이 가능하지 않으며 MMU를 이용하여 address space를 구현한다.

Nooks는 page table을 이용하며 Nooks lightweight protection domain은 kernel thread의 limited version이다.

Memory object?

프로세스와 쓰레드의 차이점은?

프로세스는 address space와 1대1로 맵핑하며 쓰레드는 address space에 하나를 공유한다.

XPC? To make calls

XPC는 다른 address space(extensions랑 커널이 다른 address space domain)에서 call을 할 경우가 생긴다.

Recovery? Steps? Failer를 찾는다. 모든 resource들을 해체한다.

Reload와 restart의 차이점? Reload는 프로그램을 메모리에 올리는 것이며 restart는 프로그램을 다시 처음부터 시작하는 것이다.

xHTTPd의 performance가 낮은 이유는 XPC가 높아서….

Motivation

Address the ever increasing system crashes due to new OS extensions

Design for fault resistance not fault tolerance

Interested in reliability, not security

Architecture

Goal and implementation

 1. Isolation

The Nooks isolation mechanisms prevent extension errors from damaging the kernel (or other isolated extensions).

 2. Interposition

The Nooks interposition mechanisms transparently integrate existing extensions into the Nooks environment.

 3. Object Tracking

The NIM's object-tracking functions oversee all kernel resources used by extensions.

1. Maintains a list of kernel data structures that are manipulated by an extension,
2. controls all modifications to those structures, and
3. provides object information for cleanup when an extension fails.

 4. Recovery

Nooks' recovery functions detect and recover from a variety of extension faults. Nooks detects a software fault when an extension invokes a kernel service improperly or when an extension consumes too many resources.

Implementation

확장(Extensible) 가능한 운영체제 기술에서 수십 년간의 연구에도 불구하고, 장치 드라이버 확장은 System failures의 중대한 원인으로 남아있다. 이 논문에서는 Nooks를 이용하였는데, OS를 항상 신뢰하기 위해서 드라이버 실패(driver failures)로부터 운영체제를 분리한 신뢰된 서브시스템을 설명하였으며 목표는 기존 드라이버 및 시스템 코드를 거의 변화하지 않고 기존 드라이버 인한 충돌을 방지하는 것이다. 또한 논문에서 제안한 기법을 증명하기 위해, Nook를 Linux 운영체제에서 구현하고 여러 가지 장치 드라이버(device driver)를 결함 및 분리하는데 사용하였다.

본 논문에서 제안한 Nooks isolation 기법은 4가지 functions을 제공하는데 다음과 같다. isolation, interposition, object Tracking, recovery이다. 첫째로 Isolation에서 Nook isolation 메커니즘은 Extension에서 일어나는 커널의 손상으로부터 오류를 방지한다. 하지만 하드웨어 지원 없이 isolation이 가능하지 않으며 MMU를 이용하여 address space 를 구현한다. Isolation의 컴포넌트는 Nook의 두 부분으로 구성되어 있다. 메모리 관리와 Extension Procedure Call(XPC)로 이루어져 있는데, 메모리 관리는 경량화 보호 기법을 사용하고, XPC는 extensions과 커널 사이에서 안전한 호출을 제어한다. 다시 말해 XPC의 경우 다른 address space(extensions랑 커널이 다른 address space domain)에서 call을 할 경우가 생긴다. 둘째로 interposition의 Nook interposition 메커니즘은 기존의 확장 기능을 integrate한 환경에 통합 할 수 있습니다. Interposition은 Nooks가 Extensions 사이에 통신 제어와 intercept 할 수 있도록 도와준다.  객체 추적(object Tracking) 기능은 확장에 의해 사용되는 모든 커널 리소스를 보는 역할을 한다. 복구(recovery) 기능은 다양한 Extension fault로부터 감지하고 복구하는 기능을 가진다. 다시 말해서 Failure를 찾은 다음 모든 resource들을 해체한다.

performance에서는 Nooks의 isolation 서비스의 성능 비용을 평가하는 벤치 마크 결과를 제공합니다. 본 논문의 실험은 기존 벤치마크와 툴을 이용하여 Nooks를 사용한 시스템 성능을 비교하였으며 Web server benchmarks에서는 xHTTPd의 performance가 낮게 나왔으며 그 원인으로 XPC가 높게 나왔다.

본 논문에서는 커널의 확장은 현 운영체제에서 major source의 failure가 큰 이슈 점이며 Nooks 기법이 신뢰성 있으며 확장과 관련된 failures들을 줄일 수 있다. 본 논문에서 실현한 것은 Nooks의 구현은 리눅스와 같은 모놀리딕 운영 체제에서도 중간 정도의 엔지니어링 노력으로 성취할 수 있으며, 장치 드라이버와 같이 extension은 적은 양의 extension code의 수정으로도 isolation를 할 수 있다. Isolation과 recovery는  extension faults으로부터 생존 및 개선 가능하게 하는 시스템의 기능이다. 

오늘날, 기성품(off-the0shelf) 운영체제의 요구사항은 신뢰성 또는 실시간으로 필요로 하는 애플리케이션을 지원으로 복잡해 졌다. 이러한 요구사항을 다루기 위해서는 Microkernel-based separation이 해결책일 수 있다. Microkernel-based separation은 legacy 어플리케이션을 다시 사용할 수 있으며, 요구되는 검증부분이 작다. 또한 실시간 어플리키에션, 신뢰성 어플리케이션을 다시 사용할 수 있다. 때문에 본 논문에서는 Microkernel based workhorse approach를 제안한다.

Workhorse 운영체제는 리눅스 또는 윈도우 운영체제와 같이 기성품 운영체제이며 유저모드에서 동작한다. Core는 운영체제에 의지하며 core 어플리케이션은 core 안에서 작동한다. I/O supporting는 유저모드 I/O 드라이버을 사용하며 안전한 I/O를 위해 workhorse로부터 I/O 드라이버를 분리시킨다. 이 기법은 faulty drivers나 실시간 시스템과의 충돌을 workhorse를 안전하게 보호 가능하며 신뢰된 어플리케이션 또한 보호된다.

Application scenario in Workhorse approach에서는 신뢰할 수 있는 응용 프로그램과 핵심 버그와 악의적인 공격으로부터 보호하며 성공적으로 workhorse를 encapsulation 할 수 있다. 그 예로 PDA에서 신뢰 가능한 E-mail 핸들러는 신뢰하지 않는 workhorse 안에 파일 시스템을 사용할 때 서버로부터 Fetch가 할 수 있으며 암호화, 복호화를 통해 유저에게 전달 한다. 이때 안전하고 신뢰할 수 있는 서비스를 위해 자체 core를 사용한다. 이는 기밀성과 신뢰할 수 있는 응용 프로그램의 무결성은 보장하지만 가용성은 보장하기 않기 때문에 secure storage가 필요로 합니다.

Software Architecture에서는 Microkernel(L4 fiasco) + 신뢰된 서비스 역할을 하는 small trusted core, Dataspace를 통해 메모리는 신뢰하지 않은 컨테이너에 any type 데이터를 넣을 수 있다. 메시지 기반 통신은 region과 copy strings을 공유하는데 쓰이며, Bus-based DMA는 기기의 Dataspace에 있는 물리적 주소를 기억하고 있고 그 값들을 메모리에 pin한다. Window manager는 활성화된 윈도우 display를 제어한다. Secure storage는 키와 신뢰된 어플리케이션의 자격 증명서(credentials)를 가지고 있다. Encryption을 사용하여 workhorse가 메시지의 내용을 볼 수 없도록 하며 이때 secure storage가 필요하다. DMA는 CPU처럼 동작하며 physical address를 이용한다

workhorse로부터 드라이버들을 분리시키는 설명이 있었으며 Separate driver는 메시지(5 sequence)를 사용하며 internal driver는 인터럽트를 사용한다고 한다. 디바이스 드라이버가 Separating address space를 가지는 것에 대한 장점으로 메인 메모리가 디바이스 드라이버가 사용할 공간이 생겼다는 것이다. 분리된 드라이버와 Data transfer는 중요한 이슈이며

Data transfer는 address space간의 data 전송을 의미한다. Bus-master DMA는 bus를 통해 실시한 작업에 대해서 tranjaction 작업하며 중간에 오류 나면 해당 작업 전체를 처음부터 안 한 상태로 되돌린다.

I/O MMU에서 DMA는 반드시 연속적이어야 하며 Physical address에서 동작해야 한다. System call mmap()를 이용하여 Mapping이 가능하다. mmap()에서 각각은 서로 다른 Virtual address지만 같은 physical address page를 이용한다. Workhouse가 I/O MMU를 지원하며 그것은 I/O MMU에서 mapping을 설정하거나 취소할 수 있는 핵심 응용 프로그램을 신뢰한다. 본 논문에서는 I/O MMU mapping의 steps에 대해 잘 나와있으며 Encapsulating을 통해 I/O MMU을 사용하지 않고도 성능(performance)이 있다는 방법도 보여준다.

본 논문에서는 Microkernel based workhorse approach 기법을 제안하였고 workhorse로부터 드라이버가 분리될 수 있으며 workhorse를 encapsulate 하는 기법에 대해 제시하였다. 이에 비슷한 연구들이 많이 진행 되었고, 연구들에 대한 survey도 함께 제시하였다. 본 논문을 통해 옛 드라이버를 수정 없이도 활용이 가능하다는 것을 알게 되었으며 마이크로커널을 통해 다양한 방법으로 디바이스 드라이브를 접근할 수 있다는 것을 배우게 되었다.

Wireless Sensor Network (WSN) is a key technological building block of IoT, which is considered the future evolution of the Internet.

Centralized Approach VS. Distributed Approach

1. Centralized Networks: there is little or no support to access the data sensing network devices directly.
1. Centralized WSN, data from the sensor nodes are transmitted to a single central location, which process, combine, and provide information acquisition for customers.
2. Due to the high data availability and massive network size, processing of data on a single location might be inefficient, processing of data on a single location might be inefficient, congested and undertaking a high risk at single entity failure.
2. Distributed networks: allowing the end-users and other network entities to obtain raw data straightway from the sensor nodes
1. The sensor nodes can retrieve, process and provide data for other entities and end-users.
2. Distributed architecture supports the IoT network applications by providing services at local level, and collaborating with all the network devices and users to achieve common goals
3. Due the network heterogeneity and device mobility, there can be many security threats and issues are encountering with distributed IoT

Design and evaluation of a two-phase authentication scheme for WSNs in distributed IoT applications

 -> the edge nodes and end-users exploit implicit certificates for mutual authentication, the protocol is lightweight and it supports the heterogeneity of the entities.

Registration Phase: to obtain security credentials from a trusted party as described below

1. Figure 1 network edge device and end-users request security credentials and certificates from the certificate authority
2. CA issues implicit certificates(절대적 증명)
3. stages
1. The protocol starts the handshaking with a Requestor Hello message, node identity(U), and cipher suites
2. CA  uses node or user identities to verify the legitimacy of the certificate requestors
3. CA agrees to one cipher suite combination from the received options, and sends CA Hello message with its public key
4. Upon receiving CA Hello message, the requestor generates a certificate request EC point and a true nonce, calculates their Message Authentication Code value and sends Certificate Request message to CA
5. CA first verifies the MAC value to identify the integrity of the request, and then calculates the implicit certificate and private key construction value
6. CA sends Certificate message including the two values followed by a nonce and MAC value.
7. Upon receiving Certificate and after verifying the MAC value, the requestor  computes its own private and public keys
8. The Finished message contains an encrypted message digest of previous handshake messages using the requestor's public key
9. CA answers with the Finished message to complete the handshake of the registration phase

Authentication Phase: to start mutually trusted communication between two network entities, using the obtained security credentials.

1. In order to establish authenticated communication, the edge nodes and end-users should possess implicit certificates for particular cipher suites
2. stages
1. The client sends the Client Hello message to the server followed by cipher suite options and its identity.
1. The client only sends the cipher suites, which its implicit certificates are composed of.
2. If the server possesses certificates, which matches the given list of cipher suites, it agrees to one cipher suite and replies with the Server Hello message and its identity.
1. Otherwise, the server abolishes the handshake by sending the End message.
3. Upon receiving the Server Hello message, the rest of the protocol can be further proceeded
4. The Client sends its certificate accompanied with a random cryptographic nonce and the MAC value
5. If the MAC verification is successful, the server calculates the client's public key, using the received certificate and CA's public key.
6. The server uses its private key and client's public key
7. The server sends its certificate, nonce, and MAC value
8. The client verifies MAC, computes the public key of the server, and derives the common key using own private key and the public key of the server
9. Exchanging the Finished messages concludes the handshake

사물인터넷(IoT) 기술은 M2M 통신의 확장 기술로 구성 장치(사물)들을 인터넷에 연결시켜 사물지능통신을 실체화하기 위해 제안되었다. IoT를 구성하는 다양한 사물들은 일반적으로 자원이 제한적이고, 이기종 장치들은 저용량 네트워크로 상호 연결된다. 이러한 IoT 환경에서 보안 서비스를 제공하기 위해서는 기밀성, 상호인증, 메시지 송신 인증 등이 제공되어야 한다. 그러나 자원이 제한적인 환경 특성상 기존 인터넷 환경에 적용했던 보안 기술들을 그대로 적용하기에는 무리가 있다. IETF 표준화 그룹에서는 안전한 IoT 서비스를 위해 경량화된 DTLS(Datagram TLS) 프로토콜의 적용을 제안하고 있지만 초경량 장치까지 모든 장치를 수용할 수는 없다. 이를 해결하기 위해 본 논문에서는 자원 제약의 이유로 해쉬 함수 혹은 암호 함수와 같은 단일 보안 모듈만을 탑재할 수 있는 경량화 장치들이 상호 인증하고 세션키를 합의할 수 있는 방안을 제안한다. 제안 기술은 세션키 생성 시 사전 계산 방식을 통해 성능을 향상시킬 수 있고 다양한 보안 공격에 대응 할 수 있다.

Two factor authentication techniques - reliable, well-analyzed and claimed to be secure

1. Online banking or Secure link establishment in Bluetooth (Bluetooth v2.1+EDR Core documentation)
2. Coming up to biometric scanners implemented in a number of portable devices (iPhone 5S Specification)

Problems

1. The overwhelming majority of available solutions for authentication is not fully scalable
1. text passwords or emerging graphical passwords
2. force the user either to apply the same password for all the systems
3. to generate passwords in a similar and easy-to-remember way, or even to create notes

How FIDO Works

FIDO protocols use standard public key cryptography techniques to provide stronger authentication.

During registration with an online service -> the user's client device creates a new key pair -> It retains the private key and registers the public key with the online service. -> Authentication is done by the client device proving possession of the private key to the service by signing a challenge. -> the client's private keys can be used only after they are unlocked locally on the device by the user -> The local unlock is accomplished by a user: swiping a finger, entering a PIN, speaking into a microphone, inserting a second-factor device or pressing a button.

In order not to compromise the security level

 -> the device has to perform a mutual authentication with the service instead of a one-side authentication in conventional systems.

문제점

Independent generation of encryption keys on different nodes can result in repetitions in the keys matrix, which can possibly compromise the security

Fulfil the usability requirements, we have to store a set of encryption keys for every user on the department side or 반대로

프로토콜

1. 초기화 단계

• 초기화 단계를 수행하기 전에 사용자는 공개키 기반 구조하에서 공개키 쌍을 생성하여 인증서를 발행
• 유사시 키 복구를 위한 비밀정보 위탁 및 키 복구 정보 생성 과정에서 사용자와 키 복구 기관 그리고 사용자와 신뢰기관 사이에 이루어지는 통신은 안전한 채널을 통하여 이루어진다 라고 가정
1. 유사시 키 복구를 위한 비밀정보 위탁 및 키 복구 정보 생성 과정
1. 사용자는 키 복구 기관과 비밀값 c를 안전하게 공유한다.
2. 키 복구 기관은 공유된 비밀값 c의 공개값 (2)를 계산하여 공개한다
3. 사용자는 신뢰기관과 비밀값 를 안전하게 공유한다.
4. 신뢰 기관은 공유된 비밀값의 공개 검증값

Voca

Passphrase

일반적으로 디지털 서명이나 암호화, 복호화에 사용되는 패스워드보다 긴 문자열로 된 비밀번호, 예를 들면, "Pretty Good Privacy" 암호 프로그램에서 요구하고 있는, 패스프레이즈는 최고 100문자까지 구성된 것도 있다.

FIDO Alliance

To change the nature of online authentication by following three things:

1. Developing technical specifications that define an open, scalable, interoperable set of mechanisms that reduce the reliance on passwords to authenticate users.
2. Operating industry programs to help ensure successful worldwide adoption of the Specifications.
3. Submitting mature technical Specification(s) to recognized standards development organization(s) for formal standardization

Specifications

PASSWORDLESS Experience - supported by the universal Authentication Framework(UAF) protocol

1. User carries client device with UAF stack installed
2. User presents a local biometric or PIN
3. Website can choose whether to retain password

The user registers their device to the online service by selecting a local authentication mechanism such as swiping a finger, looking at the camera, speaking into the mic, entering a PIN, etc.

SECOND-FACTOR Experience - supported by the universal Second-Factor(U2F) protocol

1. User carries U2F device with built-in support in web browsers
2. User presents U2F device
3. Website can simplify password (e.g. - 4 digit pin)

It allows online services to augment the security of their existing PW infrastructure by adding a strong second factor to user login. The user logs in with a username and PW as before. The service can also prompt the user to present a second factor device at any time it chooses. The strong second factor allows the service to simplify its passwords, e.g. 4-digit PIN, without compromising security.

Gateway

한 네트워크에서 다른 네트워크로 들어가는 입구 역할을 하는 장치. 근거리통신망(LAN)과 같은 하나의 네트워크를 다른 네트워크와 연결할 때 사용된다. 게이트웨이가 필요한 것은 네트워크마다 데이터를 전송하는 방식이 다르기 때문이다. 다시 말해 각각의 네트워크는 다른 네트워크와 구별되는 프로토콜(데이터를 처리하는 방식으로 미리 정해 놓은 약속)로 데이터를 전송한다. 다른 프로토콜을 사용하는 네트워크와 직접 연결하면 데이터를 공유할 수 없다. 흔히 인터넷으로 보내온 전자우편을 PC통신 서비스에서도 받아 볼 수 있는데, 이것은 인터넷과 PC통신 서비스 회사의 통신망을 중개하는 게이트웨이가 있기 때문이다.

network topology

구내 정보 통신망(LAN) 등 컴퓨터 통신망 내의 노드의 배치 형태 또는 망의 기하학적인 형상. 망 내의 노드들을 통신 회선으로 상호 접속하면 어떤 형태의 도형이 형성된다. 기본적으로는 방사형, 고리형, 선형, 즉 버스형의 3가지가 있다. 방사형 망의 종단 노드로부터 다시 방사형으로 노드를 배치하면 나무형의 망이 형성된다. 이와 같이 기본형을 응용하여 조합하면 그물형, 혼합형 등 여러 가지 형태의 망이 형성된다

기본적인 보안 요구사항

1. 인증: 전송된 메시지가 자기라고 주장하는 실제의 출처로부터 전송되었음을 수신자에게 확인시키는 것
2. 기밀성: 전송 정보에 대한 도청이나 감시와 같은 소극적 공격으로부터 전송 정보를 보호하는 요구사항
3. 무결성: 전송 정보가 전송되는 과정에서 제 3자에 의해 불법적으로 수정 또는 위조되지 않고 수신됐음을 보장하는 요구사항
4. 무선 환경에서 사용되는 무선 단말기는 연산량이 적기 때문에 보안성을 유지하면서 연산량을 최소화하야여 한다.
5. 위장 공격 방지: 제 3자가 사용자 또는 서비스 제공자로 위장하여 통신 상대방에게 피해를 주는 행위를 방지하기 위한 요구사항

OAuth인증은 소비자와 서비스 공급자 사이에서 일어나는데 이 인증 과정은 다음과 같다.

1. 소비자가 서비스제공자에게 요청토큰을 요청한다.
2. 서비스제공자가 소비자에게 요청토큰을 발급해준다.
3. 소비자가 사용자를 서비스제공자로 이동시킨다. 여기서 사용자 인증이 수행된다.
4. 서비스제공자가 사용자를 소비자로 이동시킨다.
5. 소비자가 접근토큰을 요청한다.
6. 서비스제공자가 접근토큰을 발급한다.
7. 발급된 접근토큰을 이용하여 소비자에서 사용자 정보에 접근한다.

ABSTRACT

CoAP is being standardized as an application layer protocol for the IoT. CoAP proposes to use DTLS to provide end-to-end security to protect the IoT. DTLS is a heavyweight protocol and its headers are too long to fit in a single IEEE 802.15.4 MTU(The Maximum Transmission Unit(MTU) for 802.15.4 is 127 bytes)

.

-> 6LoWPAN provides header compression mechanisms to reduce the size of upper layer headers.

-> 6LoWPAN header compression mechanisms can be used to compress the security headers as well.

We propose 6LoWPAN header compression for DTLS. We link our compressed DTLS with the 6LoWPAN standard using standardized mechanisms. We show that our proposed DTLS compression significantly reduces the number of additional security bits.

6LoWPAN = IPv6 over Low-power Wireless Personal Area Network

-> Enables the use of IP in IEEE 802.15.4 low power and loosy wireless networks such as wireless sensor network (WSN)

Security is particularly important for the things as they are connected to the untrusted and unreliable Internet.

UDP is mostly used and a new connection-less lightweight Constrained Application Protocol (CoAP) is proposed

-> CoAP proposes to use Datagram Transport Layer Security(DTLS) as a security protocol for automatic key management and data encryption and authentication.

->CoAP with DTLS support is termed as secure-CoAP (CoAPs)

System model

IoT setup having 6LoWPAN that consists of CoAPs enabled nodes and a border router; messages within 6LoWPAN travel in compressed form. The 6LoWPAN border router acts as a bridge between 6LoWPAN and the conventional Internet.

CoAPs enabled devices can securely communicate with Internet hosts such as laptops, smartphones, etc that support DTLS.

* DTLS was designed for the Internet and not for resource constrained IoT devices

  -> We can exploit 6LoWPAN compression capabilities to compress the DTLS headers and messages

DTLS and 6LoWPAN

DTLS is a protocol used to secure datagram traffic for client/server applications.

 -> It is composed of a Record Protocol that carries other protocols such as Handshake, Alert, and application data.

 -> The initial Handshake authenticates the server and optionally the client using a Public Key Infrastructure.

6LoWPAN standard defines IP header Compression(IPHC) for the IP header and next header Compression(NHC) for the IP extension headers and the UDP header.

 -> also defines fragmentation schemes for the packets that do not fit in 127 bytes MTU

 -> apply 6LoWPAN header compression mechanisms in DTLS that contained heavyweight protocol

Integrating compressed DTLS into 6LoWPAN

6LoWPAN standard does not provide ways to compress the UDP payload and the layers above

 -> Recently, 6LoWPAN-GHC has been proposed as a plug-in for 6LoWPAN which can be used to compress the UDP payload

 -> DTLS is being part of the UDP payload can be compressed via 6LoWPAN-GHC

The proposed ID bits in the NHC for UDP-GHC are used to differentiate NHC for UDP from NHC for UDP-GHC.

 -> The ID bit 11010 in the NHC for UDP-GHC indicates that the UDP payload is compressed with 6LoWPAN-GHC

 -> UDP-GHC is defined >> we can compress DTLS by providing GHC for the DTLS messages.

 -> When the 6LoWPAN-GHC for DTLS is completed we use the STOP code, set to 10010000 in the 6LoWPAN-GHC draft, to indicate that the DTLS header compression is completed

6LoWPAN-GHC for the DTLS Record and handshake

Proposal of 6LoWPAN-GHC for compressing the Record and handshake header indicated in two cases in this thesis.

First, Compressing both the Record header and the Handshake header using a single encoding byte

 ->6LoWPAN-GHC for Record + Handshake byte defines an encoding for both the Record header and the Handshake header.

Second, in order to complete the Handshake protocol, we define 6LoWPAN-GHC for the Record header (6LoWPAN-GHC-R)

 -> the fragment field in the Record header is an application data rather than a Handshake header as in the first case.

1. The first four bits in the 6LoWPAN-GHC-RHS represent the ID field.
1. set these bits to 1000.
2. Being needed to comply with 6LoWPAN-GHC encodings
1. Set these bits to 1001
3. Version
1. If 0 - the version will be DTLS latest version and field is elided(생략)
2. If 1 - the version field is carried inline(즉시처리)
4. Epoch
1. If 0 - an 8 bit epoch is used and the left most 8 bits are elided
2. If 1 - all 16 bits of the epoch are carried inline
5. Sequence Number
1. If 0 - a 16 bit sequence number is used and the left most 32 bits are elided.
2. If 1 - all 48 bits of the sequence number are carried inline
3. The case of 6LoWPAN-GHC-R
1. If 00 - 1 16 bit sequence number is used and the left most 32 bits are elided
2. If 01 - a 32 bit sequence number is used and the left most 16 bits are elided
3. If 11 - all 48 bits of the sequence number are carried inline
4. If 10 - sequence number is reserved and are not used
6. Fragment
1. If 0 - the handshake message is not fragmented and the fields fragment_offset and fragment_length are elided
1. This is common case when the handshake message is not bigger than maximum record size
2. If 1 - the fields fragment_offset and fragment_length are carried inline.

In the Record header, content_type field is always carried inline; also, msg_type and message_seq fields in the Handshake header are always carried inline.

The length filed in the Record and Handshake headers are always elided as they can be inferred from the lower layer: either from the 6LoWPAN fragmentation header or the IEEE 802.15.4 header

6LoWPAN-GHC for ClientHello

The proposal of 6LoWPAN for the ClientHello message (6LoWPAN-GHC-CH) is that ClientHello message is sent twice during the handshake process -- with cookie and without cookie

1. The first four bits in the 6LoWPAN-GHC-CH represent the ID field.
1. set these bits to 1010.
2. Session ID
1. If 0 - the seesion_id is not available and this field and 8 bits of prefixed length field are elided
1. The actual session_id field in the ClientHello contains 0 to 255 bits;
2. It is always prefixed with an 8 bit field that contains the size of the session_id
3. The ClientHello message uses seesion_id only if the DTLS client wants to resume the old seesion.
2. If 1 - the session_id filed is carried inline.
3. Cookie
1. If 0 - The cookie field is not available and this field and its prefixed 8 bits length field are elided.
1. The actual cookie field in the ClientHello contains 0 to 255 bits;
2. It always has an 8 bit length field that contains the size of the cookie.
2. If 1 - the cookie field is carried inline.
4. Cipher Suits
1. If 0 - the default cipher-suites for the CoAP that supports automatic key management is used and this field and the prefixed 16 bits length field are elided
1. 16 bits and is always prefixed with a 16 bit field that contains the size of the cipher_suites
2. If 1 - the cipher_suites field is carried inline.
5. Compression Method
1. If 0 - the default compression method -> COMPRESSION_NULL is used and this field and the prefixed 8 bit length field are elided.
1. The actual compression_methods field contains 8 to 2^8 - 8 bits;
2. It is always prefixed with an 8 bits field that contains the size of the compression_methods
2. If 1 - the compression_methods field is carried inline.

The random field in the ClientHello is always carried inline whereas the version field is always elided. In the normal case, when using 6LoWPAM-GHC-CH, we only send random field in the ClientHello message and all other field are elided.

6LoWPAN-GHC for ServerHello

The proposal of 6LoWPAN for the ServerHello message(6LoWPAN-GHC-SH)

1. The first four bits in the 6LoWPAN-GHC-SH represent the ID field.
1. set these bits to 1011.
2. Server Version
1. If 0 - the version will be DTLS 1.0 and the field is elided.
1. The DTLS 1.2 standard suggests that the server implementation should use DTLS version 1.0 due to avoiding negotiation in the initial handshake
2. The DTLS clients must not assume that the server does not support higher versions
2. If 1 - the version field is carried inline.
3. Session ID
1. If 0 - the session_id is not available and this field and 8 bits of the prefixed length field are elided
2. If 1- the session_id field is carried inline
4. Cipher Suits
1. If 0 - the default cipher_suites for CoAP that supports automatic key management is used and this field is elided.
2. If 1 - the cipher_suites field is carried inline.
5. Compression Method
1. If 0 - the default compression method -> COMPRESSION_NULL is used and this field is elided
2. If 1 - the compression_methods field is carried inline.

Size Reduction Using 6LoWPAN-GHC

Using 6LoWPAN-GHC compression mechanisms we can significantly reduce DTLS headers sizes.

In this poster abstract we only provide 6LoWPAN-GHC for the Record, Handshake, ClientHello, and ServerHello.

Table I shows

 -> The number of additional bits we send during DTLS message exchanges with and without 6LoWPAN-GHC compression.

 -> Using DTLS compression we can save a significant number of bit. The Record header that is included in all messages when the DTLS is enabled can be compressed by 64 bits (62% of the Record header) for each message.

Conclusions and Future Work

CoAP enabled hosts will be an integral part of the Internet of Things. DTLS is a standard protocol to secure CoAP messages. DTLS can be compressed using 6LoWPAN standardized mechanisms.

더 많은 이야기는 다음 URL에서 참고하세요!

http://hunift.blogspot.kr/2017/04/research-paper-review-6lowpan.html