데이즈

오늘날, 기성품(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. 발급된 접근토큰을 이용하여 소비자에서 사용자 정보에 접근한다.