[논문]이종 사물인터넷 플랫폼 간 보안 상호운용을 위한 프레임워크

오세라; 김영갑

doi:10.3745/ktccs.2018.7.3.81

이종 사물인터넷 플랫폼 간 보안 상호운용을 위한 프레임워크
Interoperable Security Framework for Heterogeneous IoT Platforms 원문보기

정보처리학회논문지. KIPS transactions on computer and communication systems 컴퓨터 및 통신 시스템, v.7 no.3, 2018년, pp.81 - 90

초록
AI-Helper

IoT(Internet of Things)의 급격한 발달로 인하여 2024년까지 수백억 개의 IoT 디바이스가 만들어질 것으로 예측되고 있으며, 그러한 IoT 디바이스들에 영향을 미칠 수 있는 IoT 플랫폼의 중요성이 부각되고 있다. 현재 FIWARE, oneM2M, AllJoyn 등의 많은 IoT 플랫폼이 개발되고 있지만 이런 환경에서는 각 IoT 플랫폼의 통신 프로토콜, 보안 정책 등이 상이한 이종성(Heterogeneity)으로 인해 데이터를 연동하거나 보안 인터워킹을 수행하기가 어렵다. 보안이 고려되지 않은 인터워킹은 각종 개인, 기업 정보의 유출 등 심각한 문제를 야기할 수 있다. 이러한 문제를 해결하기 위해, 본 논문에서는 IoT 플랫폼 중에서도 대표적인 IoT 플랫폼인 FIWARE와 oneM2M을 대상으로 보안 인터워킹 구조를 제안하고 구현하였다. 본 논문에서는 해당 보안 인터워킹 구조에서 사용하는 FIWARE의 보안 아키텍처를 분석하고 구현하여 시사점을 도출하고, 현재 공식적인 보안 컴포넌트가 존재하지 않는 oneM2M 플랫폼에 OAuth 2.0 기반의 보안 프레임워크를 개발하였다. 또한, 본 논문에서 제안한 방법을 LED(Light-Emitting Diode) 예제로 개발하여 oneM2M 플랫폼과 FIWARE 플랫폼 간의 인증 및 인가 인터워킹을 수행하였다. 구현된 LED 예제는 인가 받은 사용자에게만 제어될 수 있도록 만들어졌으며, 향후에는 LED 이외의 스마트 홈의 CCTV, 도어 락(Door Lock)과 같이 다양한 디바이스 및 다양한 IoT 플랫폼(예를 들어, Watson IoT, IoTivity, AllJoyn 등)에 적용이 필요하다.

Abstract ▼ AI-Helper

Due to the dramatic advancement of IoT (Internet of Things), it is expected that tens of billions of IoT devices will be connected by the year 2024. Furthermore, as IoT technologies evolves, the security management in IoT platforms has become a critical issue. For example, there are interworking problems between heterogeneous IoT platforms caused by differences from communication protocols, security policies, etc. in each platform. In addition, unsecured interworking can cause major security issues including the information leakage. In this paper, in order to solve these problems, a security interworking architecture is proposed and implemented in both FIWARE and oneM2M, which are representative IoT platforms. First, the security architecture of FIWARE is analyzed and implemented, and then the security framework based on OAuth 2.0 is developed on Mobius platform. Finally, in order to validate the proposed security interworking architecture, a LED (Light-Emitting Diode) example, where the LED is controlled by only authorized users, is developed. The proposed architecture can be extended to the diverse IoT platforms and devices.

주제어

AI 본문요약
AI-Helper

* AI 자동 식별 결과로 적합하지 않은 문장이 있을 수 있으니, 이용에 유의하시기 바랍니다.

문제 정의

이때, 일부 보안적으로 유해하지 않은 REST API도 존재하지만 시스템이나 디바이스를 제어하거나 보안적으로 중요한 데이터들을 요청하고 조작하는 REST API들은 심각한 보안 피해를 야기할 수 있다. 그러므로 Mobius 자체를 포함하여 디바이스나 중요 데이터들을 안전하게 보호하려면 REST API의 사용을 제한할 필요가 있으며, 이를 위해 본 연구에서는 OAuth 2.0에 기반한 oneM2M 보안 프레임워크를 제안한다.
본 논문의 주목적은 보안 인터워킹의 연구로, IoT 플랫폼 간의 인터워킹 시나리오에서 인증과 인가를 수행하는 것이 핵심이다. 따라서 본 논문에서는 다양한 보안적 사양을 요구하는 oneM2M의 보안 아키텍처를 분석하거나 구현하지 않고 인증과 인가를 제공할 수 있는 OAuth 2.0 기반 보안 프레임워크를 설계하여, KETI(Korea Electronics Technology Institute)에서 개발한 Mobius 플랫폼에 oneM2M 보안 프레임워크를 구현하고자 한다.
따라서 본 논문에서는 이종 IoT 플랫폼 간 보안 상호운용을 위한 방법을 제안하고자, 대표적인 IoT 플랫폼인 FIWARE와 oneM2M을 중심으로 IoT 플랫폼 간의 보안 인터워킹에 대해 연구하고 구체적인 FIWARE-oneM2M 보안 인터워킹 구조를 제안한다. FIWARE와 oneM2M은 대표적인 IoT 플랫폼이며 이미 Wise-IoT(Wolrdwide Interobability for Semantics IoT)의 일환으로 인터워킹 연구를 수행한 사례가 존재하기도 하지만 그 과정에서 보안이 고려되지는 않았다.
FIWARE와 달리, oneM2M은 보안 아키텍처에 대한 논의만 이루어지고 있고, 아직 공식적으로 구현되어 제공되는 보안 컴포넌트가 존재하지 않는다. 본 논문의 주목적은 보안 인터워킹의 연구로, IoT 플랫폼 간의 인터워킹 시나리오에서 인증과 인가를 수행하는 것이 핵심이다. 따라서 본 논문에서는 다양한 보안적 사양을 요구하는 oneM2M의 보안 아키텍처를 분석하거나 구현하지 않고 인증과 인가를 제공할 수 있는 OAuth 2.
본 연구에서는 IoT 플랫폼 간의 보안 인터워킹에서 가장 중요한 인증과 인가를 제공하는 OAuth 2.0 기반의 보안 프레임워크를 개발하여 oneM2M을 대상으로 적용하여 테스트하였으며 FIWARE의 보안 아키텍처를 분석하고 구현하였다. 또한 oneM2M 보안 프레임워크와 FIWARE의 보안 아키텍처를 기반으로 보안 인터워킹 구조를 제안하고 구현하였으며 이 과정에서 보안 인터워킹 구조와 보안 프레임워크의 검증을 위해 LED 예제를 개발하였다.
0 기반의 보안 프레임 워크를 제안 및 구현하며, 이는 향후 oneM2M을 제외한 다른 IoT 플랫폼을 대상으로도 적용될 수 있을 것이다. 본 연구에서는 더 나아가, 보안 인터워킹 구조와 보안 프레임워크의 동작을 검증하기 위해서 LED (Light- Emitting Diode) 예제를 개발한다. LED 예제는 정당한 권한을 가진 유저만 oneM2M의 LED를 제어할 수 있도록 만들어졌으며, 향후에는 LED 외에 CCTV나 도어 락(Door Lock) 같이, 다양한 사물들을 대상으로 적용할 수 있을 것이다.
하지만 앞서 언급된 IoT 및 OAuth 관련 연구들은 IoT 환경에서 활용할 수 있는 OAuth 기반의 보안 아키텍처나 프레임워크를 개발하는 것만을 목적으로 하여, 실제 IoT 플랫폼을 대상으로 보안 프레임워크를 적용하거나 IoT 플랫폼 간의 보안 인터워킹을 수행하는 것에 대해서는 고려하지 않았다. 이에 반해 본 연구는 국제적인 IoT 플랫폼인 FIWARE와 oneM2M을 대상으로 인증과 인가에 중점을 맞춘 구체적인 보안 인터워킹 구조와 보안 프레임워크를 제안한다. 마지막으로, 윤재석 외[15]은 IPE(Interworking Proxy Entity)를 통해 oneM2M 기반의 IoT 시스템과 기존의 IoT 상품이 인터워킹할 수 있는 방법을 연구했으며 보안을 고려하여 OAuth 2.
앞서 언급하였듯이, IoT 플랫폼 간의 인터워킹 연구들이 진행되고 있지만 아직까지 보안에 관한 논의가 부족한 실정이다. 이에 본 논문은 대표적인 IoT 플랫폼인 FIWARE와 oneM2M을 대상으로 IoT 플랫폼 간의 보안 인터워킹에 대해 연구하였으며, 보안 인터워킹 구조를 제안하고 공식 보안 컴포넌트가 존재하지 않는 oneM2M에서 활용할 수 있는 OAuth 2.0 기반 보안 프레임워크를 개발하였다.

제안 방법

oneM2M 보안 프레임워크는 설정에 따라서 특정 REST API만 사용을 제한할 수 있지만, 본 연구에서는 기본적으로 어떤 REST API든지 Mobius의 자원(http://localhost:7579/*)에 접근하면 토큰을 검증받도록 설정하였다. 이때 중요한 것은 Mobius의 실행 파일 중 일부가 처음 실행될 때 REST API를 사용한다는 사실이다.
0 기반의 보안 프레임워크를 개발하여 oneM2M을 대상으로 적용하여 테스트하였으며 FIWARE의 보안 아키텍처를 분석하고 구현하였다. 또한 oneM2M 보안 프레임워크와 FIWARE의 보안 아키텍처를 기반으로 보안 인터워킹 구조를 제안하고 구현하였으며 이 과정에서 보안 인터워킹 구조와 보안 프레임워크의 검증을 위해 LED 예제를 개발하였다. LED 예제는 oneM2M의 외부에서 접근하는 사용자가 보안 프레임워크에서 인증과 인가를 받지 않으면 LED를 제어할 수 없도록 만들어졌으며 향후 LED만이 아니라 oneM2M 플랫폼이 적용된 CCTV, 도어락 등 실용적인 사물들에 적용될 것이다.
본 연구의 LED 예제는 OCEAN(Open allianCE for iot stANdard)의 LED 예제[26]와 Fig. 8에서 제안한 보안 인터워킹 구조를 기반으로 개발되었다. Fig.
0 Flow를 위한 정보를 얻어야 한다. 이를 위해 본 연구에서는 Fig. 6과 같이 node.js 기반의 로그인, 회원 가입, 클라이언트 등록 페이지를 만들었다.

대상 데이터

토큰은 헤더의 X-Auth-Token에 넣고, Wilma (localhost:1706) 에 원하는 자원의 URL(v2/entities/My_Room)을 보낸다. Wilma의 설정 파일(config.js)에는 토큰의 검증을 성공적으로 마치면 요청을 리다이렉트할 주소를 입력하도록 되어 있는데, 본 연구에서는 컨텍스트 정보를 관리해주는 Orion의 주소(localhost:1026)로 설정하였다. 따라서 Wilma는 토큰을 성공적으로 검증하면 Orion에 요청을 리다이렉트하여 My_Room의 정보를 검색하고, 결과는 요청자에게 다시 보내준다.
또한 본 연구에서 토큰을 발급받기 위해 사용한 resource owner password credentials 방식은 신뢰도가 높은 클라이언트에서만 사용할 수 있는 한계점이 존재하기 때문에 다른 허가 방식으로도 IoT 환경에서 토큰 발급과 사용의 자동화를 단순화하고 경량화할 수 있을지 더 연구할 필요가 있다. 그리고 구체적인 보안 인터워킹 구조의 설계와 구현은 FIWARE와 oneM2M을 대상으로만 수행되었다. 이에 대해서는 향후 더 다양한 IoT 플랫폼을 대상으로 확장하여 일반적으로 사용할 수 있는 보안 인터워킹 구조에 대해서 연구해야 한다.
본 연구에서는 oneM2M 보안 프레임워크의 OAuth 2.0 서버 기능 구현을 위해 node.js 기반의 ‘oauth2-server’ 라이브러리를 사용하였으며, 이를 Mobius Yellow Turtle 2.3.8에 적용하였다.

이론/모형

표준 문서에서는 클라이언트를 클라이언트의 신뢰도에 따라서 높은 신뢰도의 confidentials 타입과 그렇지 않은 public 타입으로 나누는데, authorization code와 implicit 방식은 클라이언트가 public 타입일 때 일반적으로 사용하며, 나머지는 confidentials 타입일 때 사용한다. 본 연구에서 사용한 방식은 resource owner password credentials 방식이다. 이 방식은 자원 소유자의 정보인 username과 password만 알면 다른 추가적인 과정 없이 곧바로 토큰을 발급받을 수 있지만, 자원 소유자의 정보는 기본적으로 노출되어서는 안 되므로 클라이언트와의 신뢰도가 높은 일부 상황에서만 활용해야 하고, 실제 환경에서는 TLS(Transport Layer Security) 등의 암호화 기술과 사용되어야 한다.
IoT 환경의 디바이스들은 자동화된 경우가 많아서 사람의 개입이 필요하게 되면 활용성이 제한되므로 보안 과정의 자동화가 필요하다. 본 연구에서는 이러한 한계점을 극복하기 위해서 토큰을 발급받을 때 resource owner password credentials 방식을 사용하였다. 이 방식은 추가적인 인증 과정 없이, 자원 소유자의 정보만 확실하면 바로 토큰을 발급받을 수 있기 때문에 토큰 발급이 간단하고 발급 과정의 자동화 또한 간편하지만 자원 소유자의 정보가 유출되면 타인도 해당 정보로 토큰을 발급받을 수 있게 된다.
이때 필요한 정보는 OAuth 2.0 표준에 따라 클라이언트 id와 secret, content-type (application/x-www-form-urlencoded), grant_type (password), username, password이며, 이는 사용하는 인가 방식(grant type)에 따라서 달라지는데, 2장에서 언급한대로 본 연구에서는 resource owner password grant 방식을 사용하였다.

성능/효과

FIWARE는 과거 여러 차례 보안 컴포넌트를 개발했지만 KeyRock, Wilma, AuthZForce는 아직까지 폐기되지 않고 업데이트와 테스트가 진행되고 있다. 그러나 보안 인터워킹의 연구와 구현을 위해 실제 보안 컴포넌트들을 설치하고 테스트해본 결과, 아직 설정이 까다롭고 특정 버전끼리 의존성이 강한 문제가 있음을 확인하였다.
LED 예제는 oneM2M의 외부에서 접근하는 사용자가 보안 프레임워크에서 인증과 인가를 받지 않으면 LED를 제어할 수 없도록 만들어졌으며 향후 LED만이 아니라 oneM2M 플랫폼이 적용된 CCTV, 도어락 등 실용적인 사물들에 적용될 것이다. 본 논문에서는 LED 예제를 통해 제안한 보안 프레임워크가 권한이 없는 외부 플랫폼의 사용자가 oneM2M의 자원(LED)에 접근하는 요청들을 제한하는데 효과가 있음을 확인하였다.
1이 아닌 다른 버전에서는 의도하지 않은 문제가 발생할 수 있다. 본 연구에서는 AuthZForce 5.4.1이 Ubuntu 16.04를 지원하지 않으므로 7.0.0 버전을 사용하였는데, 별다른 버그나 의도하지 않은 문제가 발생하지는 않는 것을 확인하였다. Fig.

후속연구

5장에서 언급하였듯이, 향후 연구로는 지역이나 시간 정보 등을 이용한 상세한 인가를 제공할 수 있는 보안 프레임워크의 개발이 필요하며 이와 관련하여 보안 인터워킹 시나리오들을 자세히 정의해야 한다. 또한 보안 프레임워크는 resource owner password credentials 방식만이 아닌 다양한 OAuth 2.
또한 oneM2M 보안 프레임워크와 FIWARE의 보안 아키텍처를 기반으로 보안 인터워킹 구조를 제안하고 구현하였으며 이 과정에서 보안 인터워킹 구조와 보안 프레임워크의 검증을 위해 LED 예제를 개발하였다. LED 예제는 oneM2M의 외부에서 접근하는 사용자가 보안 프레임워크에서 인증과 인가를 받지 않으면 LED를 제어할 수 없도록 만들어졌으며 향후 LED만이 아니라 oneM2M 플랫폼이 적용된 CCTV, 도어락 등 실용적인 사물들에 적용될 것이다. 본 논문에서는 LED 예제를 통해 제안한 보안 프레임워크가 권한이 없는 외부 플랫폼의 사용자가 oneM2M의 자원(LED)에 접근하는 요청들을 제한하는데 효과가 있음을 확인하였다.
본 연구에서는 더 나아가, 보안 인터워킹 구조와 보안 프레임워크의 동작을 검증하기 위해서 LED (Light- Emitting Diode) 예제를 개발한다. LED 예제는 정당한 권한을 가진 유저만 oneM2M의 LED를 제어할 수 있도록 만들어졌으며, 향후에는 LED 외에 CCTV나 도어 락(Door Lock) 같이, 다양한 사물들을 대상으로 적용할 수 있을 것이다. 또한 본 연구에서 제안하는 보안 인터워킹 구조와 보안 프레임워크는 향후 타 IoT 플랫폼에 적용 가능하다.
0 grant 유형을 제공해야 하며, 이에 관한 토큰 발급의 자동화나 경량화 등의 연구와 IoT의 상황인지 특성을 십분 활용한 토큰 발급 방안에 대한 연구도 필요하다. 그리고 FIWARE와 oneM2M이 아닌 다른 플랫폼을 대상으로 사용할 수 있는 일반적인 보안 인터워킹 구조를 연구하고, 그 과정에서 각 도메인의 요구사항(보안 정책)에 따라 구체적인 인증과 인가 과정을 구현하고, 인증, 인가 이외의 다른 보안 기능도 보안 프레임워크가 제공할 수 있도록 개발되어야 한다.
더 나아가, 보안 정책에 따라 토큰을 사용할 때 FIWARE 토큰을 oneM2M에서 사용하거나 oneM2M 토큰을 FIWARE 에서 사용할 수 있도록 만들 수 있다. 다만, oneM2M 측에서 FIWARE 토큰을 받았을 때 해당 토큰이 FIWARE의 토큰임을 알아야 하고, FIWARE 측에 토큰의 검증을 요청할 수 있어야 하며 해당 토큰의 권한으로 특정 oneM2M 자원의 어느 수준까지 접근할 수 있는지 확실한 보안 정책이 수립되어야 한다. 또한, 이를 위해 FIWARE와 oneM2M은 기존에 신뢰 관계가 형성되어야 하고 전송된 검증 정보 등을 신뢰하기 위한 프로토콜도 마련되어야 한다.
5장에서 언급하였듯이, 향후 연구로는 지역이나 시간 정보 등을 이용한 상세한 인가를 제공할 수 있는 보안 프레임워크의 개발이 필요하며 이와 관련하여 보안 인터워킹 시나리오들을 자세히 정의해야 한다. 또한 보안 프레임워크는 resource owner password credentials 방식만이 아닌 다양한 OAuth 2.0 grant 유형을 제공해야 하며, 이에 관한 토큰 발급의 자동화나 경량화 등의 연구와 IoT의 상황인지 특성을 십분 활용한 토큰 발급 방안에 대한 연구도 필요하다. 그리고 FIWARE와 oneM2M이 아닌 다른 플랫폼을 대상으로 사용할 수 있는 일반적인 보안 인터워킹 구조를 연구하고, 그 과정에서 각 도메인의 요구사항(보안 정책)에 따라 구체적인 인증과 인가 과정을 구현하고, 인증, 인가 이외의 다른 보안 기능도 보안 프레임워크가 제공할 수 있도록 개발되어야 한다.
LED 예제는 정당한 권한을 가진 유저만 oneM2M의 LED를 제어할 수 있도록 만들어졌으며, 향후에는 LED 외에 CCTV나 도어 락(Door Lock) 같이, 다양한 사물들을 대상으로 적용할 수 있을 것이다. 또한 본 연구에서 제안하는 보안 인터워킹 구조와 보안 프레임워크는 향후 타 IoT 플랫폼에 적용 가능하다.
추후 본 연구의 보안 프레임워크는 단순 토큰의 검증으로만 인가를 수행하는 것이 아니라, 요청자의 나이, 지역, 접속한 시간, 사용하는 이메일 도메인 등을 통해서 세세한 인가를 수행하는 것이 필요하며 인증과 인가 외에도 복잡한 보안 인터워킹 시나리오에서 요구되는 다양한 보안 기능을 제공해야 한다. 또한 본 연구에서 토큰을 발급받기 위해 사용한 resource owner password credentials 방식은 신뢰도가 높은 클라이언트에서만 사용할 수 있는 한계점이 존재하기 때문에 다른 허가 방식으로도 IoT 환경에서 토큰 발급과 사용의 자동화를 단순화하고 경량화할 수 있을지 더 연구할 필요가 있다. 그리고 구체적인 보안 인터워킹 구조의 설계와 구현은 FIWARE와 oneM2M을 대상으로만 수행되었다.
본 논문에서 제안한 보안 프레임워크의 토큰 발급과 활용에 대해서도 논의가 더 필요하다. PC 환경과는 달리 IoT 환경에서 토큰을 발급받을 때 중요한 차이점은 상황인지(contextaware) 특성의 여부이다.
FIWARE와 oneM2M 간에 보안 인터워킹이 수행되기 위해서는 각 플랫폼에 보안 컴포넌트들이 필요하지만 FIWARE의 경우에만 보안 컴포넌트가 존재하고 oneM2M은 제공되지 않고 있다. 본 연구에서는 FIWARE-oneM2M 보안 인터워킹 구조에서 핵심 보안 기능인 인증과 인가를 수행할 수 있는 OAuth 2.0 기반의 보안 프레임 워크를 제안 및 구현하며, 이는 향후 oneM2M을 제외한 다른 IoT 플랫폼을 대상으로도 적용될 수 있을 것이다. 본 연구에서는 더 나아가, 보안 인터워킹 구조와 보안 프레임워크의 동작을 검증하기 위해서 LED (Light- Emitting Diode) 예제를 개발한다.
또한, 이를 위해 FIWARE와 oneM2M은 기존에 신뢰 관계가 형성되어야 하고 전송된 검증 정보 등을 신뢰하기 위한 프로토콜도 마련되어야 한다. 이러한 IoT 플랫폼 간 토큰의 교차 사용에 대해서는 향후에 보다 집중적인 연구가 필요하다.
그리고 구체적인 보안 인터워킹 구조의 설계와 구현은 FIWARE와 oneM2M을 대상으로만 수행되었다. 이에 대해서는 향후 더 다양한 IoT 플랫폼을 대상으로 확장하여 일반적으로 사용할 수 있는 보안 인터워킹 구조에 대해서 연구해야 한다.
하지만 본 연구에서 개발한 보안 프레임워크는 토큰을 통한 기본적인 인가만 수행하였으며 세부적인 인가는 수행하지 않았다. 추후 본 연구의 보안 프레임워크는 단순 토큰의 검증으로만 인가를 수행하는 것이 아니라, 요청자의 나이, 지역, 접속한 시간, 사용하는 이메일 도메인 등을 통해서 세세한 인가를 수행하는 것이 필요하며 인증과 인가 외에도 복잡한 보안 인터워킹 시나리오에서 요구되는 다양한 보안 기능을 제공해야 한다. 또한 본 연구에서 토큰을 발급받기 위해 사용한 resource owner password credentials 방식은 신뢰도가 높은 클라이언트에서만 사용할 수 있는 한계점이 존재하기 때문에 다른 허가 방식으로도 IoT 환경에서 토큰 발급과 사용의 자동화를 단순화하고 경량화할 수 있을지 더 연구할 필요가 있다.

질의응답

핵심어	질문	논문에서 추출한 답변
	IoT란 무엇인가?	IoT(Internet of Things)는 일반적으로 상황인지, 지능화, 자동화 기능을 가진 디바이스가 서비스 제공 등의 특정 목적을 위해 네트워크에 연결되는 협업 환경을 나타낸다. 가트너, 시스코, IDC(International Data Corporation) 등의 기업들은 IoT를 미래의 유망한 기술로 꼽았으며[1], IDC는 IoT 시장 규모가 2015년부터 2020년까지 연평균 15.
	IoT(Internet of Things) 플랫폼이 IoT 시장에서 중요한 이유는?	이에 구글과 아마존, 삼성, 시스코 등의 세계적 기업들이 IoT 시장을 선점하기 위해서 IoT와 관련된 기술이나 표준, 디바이스 등을 개발하고 있으며, 그 중에서도 IoT 플랫폼은 특히 중요하다. 그 이유는 IoT 플랫폼이 IoT 디바이스들의 기본적인 기능들을 제공해줌으로써 향후 만들어질 것으로 예측되는 500억개 이상의 IoT 디바이스들에 직·간 접적으로 영향을 미칠 수 있기 때문이다[3]. 지금까지 FIWARE (Future Internet ware), oneM2M, AllJoyn, IoTivity와 같은 IoT 플랫폼들이 다수 만들어졌지만 각 IoT 플랫폼의 기반 기술, 통신 프로토콜, 보안 정책 등이 상이하여 이종 플랫폼 간에 원하는 정보나 서비스를 교환하거나 이용하기 어려운 상황이다.
	보안 인터워킹에서 중요한 과정은 무엇인가?	보안 인터워킹에서는 상대방이 누구인지 확인하는 과정인 인증과 확인된 상대에게 권한을 부여하는 인가 과정이 중요하며, OAuth 2.0은 이런 경우에 사용할 수 있는 인증, 인가 프레임워크 표준[5]이다.

참고문헌 (26)

S.-R Oh and Y.-G Kim, "Security Requirements for Internet of Things," IEEE 2017 Platform Technology and Service (PlatCon), pp.1-6, February 2017.
IDC (International Data Corporation), "Worldwide Semiannual Internet of Things Spending Guide," [Internet], https://www.idc.com/getdoc.jsp?containerIdIDC_P29475.
Cisco, "The Internet of Things," [Internet], https://www.cisco.com/c/dam/en_us/about/ac79/docs/innov/IoT_IBSG_0411FI NAL.pdf.
oneM2M, "Latest Draft Specifications," [Internet], http://www.onem2m.org/technical/latest-drafts.
D. Hardt. RFC6749: The OAuth 2.0 Authorization Framework. 2012.
FIWARE, "Security Architecture," [Internet], https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Security_Architecture.
I. T. Hwang and Y.-G. Kim, "Analysis of Security Standardization for the Internet of Things," IEEE 2017 Platform Technology and Service (PlatCon), pp.1-6, February, 2017.
J. H. Kim, S.-C. Choi, N.-M. Sung, and J. S. Yun, "Standard Interworking Technologies for Internet of Things," The Journal of The Korean Institute of Communication Sciences, Vol.33, pp.55-64, 2016.
D. G. Lee, D.-H. Kim, and T.-M. Chung, "A Proposal for a Method of Interworking with DDS on IoT Platforms," Proceedings of Symposium of the Korean Institute of Communications and Information Sciences, Vol.60, pp.385-386, 2016.
K.-H. Kim, H.-K. Lim, J.-S. Heo, and Y.-H. Han, "Design and Implementation of CoAP Authorization Framework Based on OAuth 2.0," Tr. Comp. and Comm. Sys., Vol.6, pp.329-342, 2017.
S. Sciancalepore, G. Piro, D. Caldarola, G. Boggia, and G. Bianchi, "OAuth-IoT: an access control framework for the Internet of Things based on open standards," Computers and Communications (ISCC), pp.676-681, 2017.
S. W. Jung and S. Jung, "Personal OAuth authorization server and push OAuth for Internet of Things," International Journal of Distributed Sensor Networks, Vol.13, pp.1-11, 2017.
P. Solapurkar, "Building Secure Healthcare Services Using OAuth 2.0 and JSON Web Token in IOT Cloud Scenario," Contemporary Computing and Informatics (IC3I), pp.99-104, 2016.
F. Fernandez, A. Alonso, L. Marco, and J. Salvachua, "A Model to Enable Application-scoped Access Control as a Service for IoT Using OAuth 2.0," Innovations in Clouds, Internet and Networks (ICIN), pp.322-324, 2017.
J. S. Yun, R. C. Teja, N. Chen, N.-M. Sung, and J. H. Kim, "Interworking of oneM2M-based IoT Systems and Legacy Systems for Consumer Products," Information and Communication Technology Convergence (ICTC), pp.423-428, October, 2016.
oneM2M, "TS-0012: Base Ontology v3.3.0," 2017.
oneM2M, "TS-0014: LWM2M Interworking v3.1.0," 2017.
oneM2M, "TS-0021: oneM2M and AllJoyn Interworking v2.0.0," 2016.
oneM2M, "TS-0024: OIC Interworking v2.0.1," 2017.
oneM2M, "TS-0026: 3GPP Interworking v0.2.0," 2017.
oneM2M, "TS-0030: Generic Interworking v0.2.0," 2017.
oneM2M, "TS-0033: Proximal IoT Interworking v0.1.0," 2017.
oneM2M, "TR-0027: DDS usage in oneM2M system v0.2.0," 2016.
oneM2M, "TR-0042: WoT Interworking v0.0.1," 2017.
oneM2M, "TR-0043: Modbus Interworking v0.1.0," 2017.
OCEAN (Open alliance for iot standard), "LED Sample," [Internet], http://www.iotocean.org/download/?tab12.

저자의 다른 논문 :

LOADING...

표제어: PCR

동의어: Packet Collision Rate

용어 설명 출처 목록 (6)

용어 설명: PCR은 세균 특이성이 있는 primer를 이용하여 적은 수의 세균이 있을지라도 쉽게 검출할 수 있는 유용한 방법이며, 이를 이용하여 구강 내 치면세균막이나 타액에서 직접 세균을 검출할 수 있게 되었다[8].

내보내기 구분	파일저장 인쇄 메일전송
구성항목	기본정보 상세정보 관리번호, 논문명, 저널/프로시딩명, 저자 , 발행년, 권, 호, 시작페이지, 끝페이지, 발행기관 관리번호, 논문명, 대등논문명, 저자 , 저널/프로시딩명, 발행기관, 발행년, 발행언어, 권, 호, 시작페이지, 끝페이지, ISBN, ISSN, 주제분야, 키워드, 초록(한글), 초록(영문), 저자(소속기관)
저장형식	Text(ASCII format) Excel format RefWorks Direct Export RIS format (for Reference Manager, ProCite, EndNote), Scholar's Aids, Mendeley
메일정보	받는사람 (필수) @ 보내는사람 (선택) @ 제목 내용 KISTI 검색결과 이메일 서비스
안내	총 건의 자료가 검색되었습니다. 다운받으실 자료의 인덱스를 입력하세요. (1-10,000) 검색결과의 순서대로 최대 10,000건 까지 다운로드가 가능합니다. 데이타가 많을 경우 속도가 느려질 수 있습니다.(최대 2~3분 소요) 다운로드 파일은 UTF-8 형태로 저장됩니다. 파일의 내용이 제대로 보이지 않을실 때는 웹브라우저 상단의 보기 -> 인코딩 -> 자동선택 여부를 확인하십시오. ~ Text(ASCII format) Excel format

연합인증