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. 발급된 접근토큰을 이용하여 소비자에서 사용자 정보에 접근한다.

 

 


 


+ Recent posts