정보통신·방송 연구개발사업
클라우드와 IoT 컴퓨팅 자원 연계를 위한 IoT 서비스 프 로토콜/행위 분석 기반의 성능향상 엔진 생성 및 초
연결 IoT 네트워크/서비스 자원 관리 기술 개발 Creation of PEP based on automatic protocol behavior analysis and Resource management for
hyper connected for IoT Services
한국과학기술원
보고 서식 제 호
연차보고서
사업명 정보통신 방송 연구개발 과제번호
과제명
국문 클라우드와 컴퓨팅 자원 연계를 위한 서비스 프로토콜 행위 분석 기반의 성능향상 엔진 생성 및 초 연결 네트워크 서비스 자원 관 리 기술 개발
영문 Creation of PEP based on automatic protocol behavior analysis and Resource management for hyper connected for IoT Services
주관기관 한국과학기술원 총괄책임자 한동수
참여기관
책임자 건국대학교 산학협력단 한선영 동명대학교 산학협력단 안현식
총수행기간 년
협약기간 년
해당년도
수행기간 개월
협약기간 총사업비 천원
정 부 출연금
민 간 부담금
현금
계 현물
해당연도 사업비 천원
정 부 출연금
민 간 부담금
현금
계 현물
키워드 개
프로토콜 자동 분석 성능 향상 프록시 클라우드 매니지드
초연결 융합 서비스 지원 클라우드 연계 자원 관리 확률적 대역폭 보장
정보통신 방송 연구개발 관리규정 제 조에 의거하여 연차보고서를 제출합니다
년 월 일
총괄책임자 한 동 수 인 주관기관장 강 성 모 인
정보통신기술센터장 귀하
목 차
해당 연도 추진 현황
1. ··· 1
1-1. 기술개발 추진 일정 ··· 1
1-2. 해당 연도 추진 실적 ··· 6
주관기관 추진실적 한국과학기술원 1-2-1. [ ] ··· 6
1-2-2. 참여기관 추진실적 건국대학교 ··· 28
1-2-3. 참여기관 추진실적 동명대학교[ ] ··· 93
2. 기술개발결과 ··· 104
2-1. 지식재산권 ··· 105
2-2. 시제품 ··· 105
2-3. 기술문서 ··· 105
2-4. 논문실적 ··· 106
2-5. 표준화 실적 ··· 107
2-6. 고용 창출 ··· 107
2-7. 기타 성과 ··· 107
3. 결론 및 차년도 계획 ··· 108
3-1. 종합적인 결론 ··· 108
3-2. 차년도 계획 ··· 114
3-3. 차년도 수행을 위한 건의사항 및 변경사항 ··· 115
4. 사업비 사용현황 ································································································116
주관기관 사업비 사용현황 한국과학기술원 4-1. [ ] ······································116
참여기관 사업비 사용현황 건국대학교 4-2. [ ] ··············································117
참여기관 사업비 사용현황 동명대학교 4-3. [ ] ··· 118
5. 기업 재무건전성 현황 ··· 119
자체보안관리진단표 6. ··························································································120
유형적 발생품 연구시설 연구장비 등 구입 및 관리 현황 7. ( , ) ·····················121
해당 연도 추 진 현황
기술개발 추진 일정
한국과학기술원
계획 실적
일련
번호 개발 내용 추진 일정 개월 달성도
안드로이드 바이너리를 분석하여 자동으로 의 정규표현식을 도출 HTTP Request/Response
기능 개발
도출된 HTTP Request/Response 정규표현식들을 하나의HTTP트랜잭션으로
페어링하는 기능 개발
확률적 대역폭 보장을 위한 단일 중앙 클라우드에서 가상화 서비스 요청 모델 정립
단일 중앙 클라우드에서 가상화를 위한 네트워크 자원 할당 방법 설계 및 수락 제어
메커니즘 개발
개발내용의 경우 사업계획서 내용에 근거하여 작성할 것
건국대학교
계획 실적
일련
번호 개발 내용 추진 일정 개월 달성도
에서의 호스트 자원관리 기술 개발
동명대학교
계획 실적
일련
번호 개발 내용 추진 일정 개월 달성도
초연결 네트워크 기반의 응용서비스 자원관리 기술 개발
참고자료 전체사업개요
새로운 환경의 도래와 현 네트워크 관리 방법의 충돌
단말의 폭증과 컴퓨팅 자원연계를 통한 클라우드 서비스의 확장 1. IoT IoT
단말의 폭증 - IoT
매년 IoT 단말 모바일 기기 각종 센서( , , IP 카메라 스마트 가전 제품 등 이 폭증하고 있, ) 다 가트너는. 2015년 ‘인터넷 연결 기기(connected things)’의 대다수가 올해 보다 30%
증가한 49억 대, 2020년에는 250억 대에 이를 것이라고 예측했다. IoT 디바이스들이 출현 하고 있다 또한 스마트. , TV, 가전 등을 비롯하여 많은 디바이스들이 인터넷에 연결된 서 비스를 활용할 수 있는 플랫폼으로 진화하고 있으며 이에 따라, 2015년 신규 출시되는 모든 디바이스 (PC 포함 의) 50% 이상이 안드로이드 플랫폼을 탑재하는 등 단말에 큰 변 화가 이루어지고 있다.1)
컴퓨팅 자원을 활용한 로컬 클라우드 컴퓨팅의 활성화 - IoT
이와 더불어 로컬 컴퓨팅을 지원할 수 있는 기기들 예 라우터 홈 게이트 웨이, ( , , , Cloud 집중국의 클라우드 장비 노드 등 도 늘어가고 있다 이러한 RAN, Base station, ISP , CDN ) .
로컬 컴퓨팅 자원을 활용하여 기존에 클라우드에서 운용되는 서비스를 가속시키고 부하, 를 분산시켜 서비스 품질 향상 및 경제성을 증대시키는 사업이 활성화 되고 있다 (예,
사의 사의 사의
AT&T cloudlet, Akamai dynamic site accelerator, Netflix open connect).
이러한 로컬 컴퓨팅 자원의 활용은 IoT 디바이스의 폭증과 함께 가속화하고 있다 스마. 트 폰 뿐만 아니라, TV, 냉장고 전열기기 냉방 기기 전력계 스마트 홈 콘솔 등 많은, , , , 디바이스들이 날씨 정보 등 클라우드 서비스를 이용하게 되어 트래픽 및 컴퓨팅 자원의 수요가 폭증할 것이기 때문이다 뿐만 아니라 차세대. ICBM (IoT, Cloud, Big Data, Mobile) 서비스는 다양한 IoT 자원을 센서 로컬 클라우드 등 활용하여 제공이 될 것이다( , ) . 이는 서비스를 제공하는 서비스 플랫폼이 전통적인 클라우드 뿐만 아니라 로컬 컴퓨팅 자원을 포함하는 넓은 개념으로 확대되고 있음을 의미한다.
1) http://www.itworld.co.kr/news/90601
그림
[ 1] IoT 환경에서의 자원관리 문제
현재 기술의 제약 2.
다수종의 초연결 서비스 지원의 제약 -
현재의 인터넷 기반의 서비스 제공의 기본 방식은 클라우드에서 구동되는 서버 소프트 웨어와 스마트 단말에서 구동되는 클라이언트 소프트웨어를 예 안드로이드 어플리케이( , 션) 제작하여 배포한는 것이다 이때 소프트웨어 배포는 서버의 경우 클라우드 서비스. , 제공자가 제공하는 인터페이스를 사용하여, 클라이언트의 경우는 플랫폼에서 제공하는 오픈 마켓 예 구글( , Play 스토어, SK텔레콤의 T스토어 을 통하여 자동적으로 이루어진다) .
하지만, IoT 환경에서 다수의 단말과 다수의 원할한 서비스 제공을 위한 로컬 클라우드 에서 구동되는 성능향상 엔진 (PEP: Performance Enhancement Proxy)은 현재 비자동화 되어 있고 응용별로 개별화되어 있다 이 과정은 대부분 제 자가 서비스 프로토콜의 행, . 3 동을 수동으로 분석하여 작성하거나 서비스를 제작한 사업체에서 직접 수동으로 작성하 고 있다 이 과정은 초연결 서비스의 개발과 보급 사이클을 지연시킬 뿐만 아니라 원활. 한 서비스 제공에 악영향을 미쳐 초연결 서비스 저변 확대에 장애요소가 되고 있다.
서비스 관리 및 자원 관리의 어려움 -
로컬 컴퓨팅 자원과 IoT 디바이스에서 제공되는 각종 서비스 센서 정보 제공 등 는 초( ) 연결 서비스 구성 요소일 뿐 아니라 서비스 제공에 필수적인 자원이다 하지만 전통적인. 클라우드 기반으로 서비스를 제공하는 것에 비하여 자원의 관리와 통제가 어렵다 이는, .
매우 다양하기 때문이다.
또한 관리 대상의 자원의 종류도 다양하여 네트워크 자원, IoT 기기 노드 그리고 서비/ , 스가 있다 하지만 이러한 자원들이 서비스의 구성 요소이기 때문에 관리와 제어가 되지. , 않는다면 서비스 품질 관리에 막대한 장애를 초래하고 이는 초연결 서비스의 보급을 저, 해하게 된다.
해결방법 환경에 특화된 효율적인 서비스 관리 환경 제공
현 과제에서는 위의 문제점에 대해 두 가지 해결방안을 제시하고 있으며 첫 번째로 IoT 환 경에 특화된 효율적인 서비스 관리 환경을 개발하는 것이다 주관기관인 한국과학기술원에서. 는 IoT 서비스의 네트워크 행동 패턴을 자동적으로 분석하여 IoT 서비스에서 발생하는 네트 워크 트래픽을 효율적으로 처리하기 위한 자동분석 프레임워크를 개발한다 이 프레임워크의. 결과는 3차년도에 PEP엔진의 자동생성 시스템을 위한 기반이 되고 건국대학교의 2~3차년 목 표인 IoT 환경의 중앙집중형 네트워크 관리 및 QoS 동적 라우팅 알고리즘에 이용된다 이러. 한 IoT 특화의 네트워크 관리 기법을 제공함으로써 기존의 메인클라우드에 대한 추가비용 없 이 새로운 IoT 환경에 유연하게 대처할 수 있을 것이라 기대한다.
그림
[ 2] IoT 환경에 특화된 효율적인 서비스 관리 환경 제공
해결방법 환경에 특화된 종합적인 클라우드 자원 관리와 통제 환경 제공 두 번째 해결방법으로는 IoT 환경에 특화된 종합적인 클라우드 자원 관리와 통제 환경을 개 발하는 것이다 참여기관인 동명대에서는. 1~2차년도에 IoT 서비스 자원 생성 및 관리 기술을 개발하여 한국과학기술원의 클라우드 내에서 중앙집중형 확률적 품질보장기술과 건국대에서,
차년도에 수행하는 중앙집중형 호스트 이동성 지원연구기술의 기반을 마련한다 이러한
3 . IoT
특화의 클라우드 자원관리와 통제 환경을 제공함으로써 새로운 IoT환경에서의 메인클라우드 가 수행해야 할 자원할당 및 관리 측면의 어려움을 극복할 수 있으리라 생각한다.
그림
[ 3] IoT 환경에 특화된 종합적인 클라우드 자원 관리와 통제 환경 제공
위에서 제시한 해결방법을 개발하기 위해서 차 년도에 기관별 추진 실적을 아래에 기술한다
해당 연도 추진 실적
사업계획서의 연차별 개발 목표 및 내용 대비 성과를 상세히 기술 개발 목표 달성 정도를 구체적으로 제시
주관기관 한국과학기술원
가 안드로이드 바이너리를 분석하여 자동으로 의 정규표현
식을 도출하는 기능 개발
정적 바이너리 분석 기법을 통한 어플리케이션 네트워크 행동 패턴 분석 프레 임 워크의 설계
¡ 추진 성과 및 검증 결과 요약
§ 프로그램 정적 분석기법을 구현한 프로그램 슬라이싱 모듈 개발 완료 1. Request Signature를 위한 Backward 프로그램 슬라이스 추출 개발 및 검증 완료 2. Response Signature를 위한 Forward 프로그램 슬라이스 추출 개발 및 검증 완료
§ 추출된 슬라이스 기반으로 네트워크 메시지 포맷을 추론할 수 있는 정규표 현식 생성 모듈의 개발 완료
1. HTTP URL의 정규표현식 도출을 위한 Semantic 모델 설정 (org.apache.http, 등 개발 완료
android.net.http, java.net )
2. HTTP Request/Response body의 정규표현식 도출을 위한 Semantic 모델 설정 서드파티 라이브러리 등 개발 완료
(JSON, XML )
§ 검증 결과
1. 14개 어플리케이션의 모든 HTTP메시지 포맷 도출 (100%)
개의 포맷 개의 포맷 개의
(98 HTTP Request URI , 92 HTTP Request body , 48 HTTP 메시지
Response )
2. 144개의 Request body/query 키워드 도출
(99%, 동적 바이너리 업데이트 메시지 1개 놓침) 3. 372개의 Response body/query 도출 (100%)
4. 10개 이상의 어플리케이션의 프로토콜 평균 분석시간 63.1초
§ 기대효과
1. 세계 최초의 안드로이드 어플리케이션의 네트워크 고유 지문을 자동적으로 추출 기술
2. 네트워크 지문을 이용하여 다양한 어플리케이션에 맞춤형 서비스를 제공 3. 전 세계적으로 수작업으로 네트워크 고유의 지문을 도출하는 것을 자동화
4. IDS, 네트워크 고속화 같은 다양한 네트워크 관리 분야의 솔루션들과 융합되어 기 존 솔루션들의 고부가 가치창출
5. 최종 출력물인 HTTP Request/Response 패턴의 정규표현식을 도출하는데 걸리는 시간이 60분 이내로 사용이 가능한 성능 보장
¡ 개발 개요
다양한 IoT 기기들이 사용하는 안드로이드 어플리케이션들의 행동 패턴을 자동화하여 정 적 바이너리 분석을 수행하고 이를 기반으로, HTTP기반의 어플리케이션 트래픽 지문을 추 출하기 위해서 IoT 응용서비스 프로토콜 자동 분석 시스템을 개발 완료하였다.
¡ 개발내역 상세 설명
§ 개발 시스템 기본 개념도
그림
[ 4 정적 바이너리 분석 기법을 통한 행동패턴 분석 프레임워크]
그림 는 네트워크 인지 프로그램 슬라이싱 모듈과 정규표현식 생성 모듈을 포함하는 전체적인 시스템 개념도를 보여준다
기 시스템의 첫 번째 단계는 네트워크 인지 프로그램 슬라이싱의 경우 정적 바이너리 분석 기법에 포함된다 본 모듈의 목적은 바이너리에서 필요한 부분 만을 뽑아내기 위함이다 일반적으로 어플리케이션의 바이너리에는 많은 양의
에 관련된 인스트럭션만 슬라이싱 한다 네트워크로 데이터가 보내지거나 네 트워크에서부터 데이터가 프로그램으로 입력되는 모든 객체들의 데이터의존성 분석을 기반으로 모든 프로그램 슬라이스가 생성된다 이때
슬라이스를 슬라이스 슬라이스를
슬라이스라고 명명한다
기 시스템의 두 번째 단계는 정규표현식 생성 모듈로 슬 라이스를 입력으로 받아서 각각의 메시지 포맷을 유추하고 정규표현식으로 표 현하는 단계이다 프로그램 슬라이스가 또는 메시지를 저장 하는 객체나 메시지를 조립하는 과정에 해당하는 모든 인스트럭션을 담고 있 기 때문에 슬라이스에 모든 정보가 있다고 볼 수 있다 시스템에서는 정규표 현식 생성을 위해서 모델을 이용하는데 기본적으로 에서 제공하
는 관련 및 자주 쓰이는 서드파티 들에 대해 모델링이
되어있다
§ 네트워크 인지 프로그램 슬라이싱 모듈 상세 설명
네트워크 동작과 관련된 인스트럭션만 포함하고 있는
프로그램 슬라이스를 추출하기 위해서 시스템에서는 네트워킹 관련 객체의 데 이터 의존성 분석인 를 기반으로 수행된다 기 개발된 시스템 은 오픈소스 프로그램 분석 프레임워크인 를 기반으로 확장되었다 하지만 기존 프레임워크는 특정 데이터가 에서 까지 데이터 흐름의 존재여부를 분석하는 것이 목적이지만 기 시스템은 객체들의 모든 오퍼레이션을 추적하는 것이 목적이다
바이너리 상의 모든 객체를 테인트 분석하는 것은 퍼포먼스 측면에서 매우 값비싼 작업이다 현존하는 범용 정적 분석 프레임워크의 경우는 위와 같은 문제를 해결하기 위해서 와 라는 데이터 흐름 분석의 시작과 끝에 해당하는 메소드들을 지정하여 분석한다 하지만 이런 분석 방법은 바이너리 의 메시지 포맷 및 행동 패턴을 분석하는 데에는 측면에서 의 문제가 존재한다 따라서 기 시스템에서는 및 에서 제공되는 연결 메소드들과 자주 쓰이는 서드파티 라이브러리들의 메소드들을 미 리 정의하고 이들을 기준으로 데이터 의존성 분석을 수행한다
이나 시스템에서는 이러한
메소드들을 라고 명명한다
그림 는 클라이언트의 프로그램 슬라이스 이다
함수는 객체를 파라메터로하고 객체를 리턴 하는
형태로 볼 수 있다 이 코드들을 바탕으로 시스템은 테인트 분
석을 자동적으로 수행한다 시스템에서 를 기준으로
분석을 수행하면 데이터를 담고 있는 객체에 대한 데이터 의존성 분석이 진행되는데 이때의 결과로 슬라이스가 도출된다
슬라이스는 이나 파라메터가 어떻게 구성되고 조립되는지 정보를 담고 있다 반대로 분석을 수행하면 데이터를 담고 있는 객체에 대한 데이터 의존성 분석이 수행되고 그 결과로 슬라이 스가 도출된다 이는 그림 에서 볼 수 있듯 데이터가 어떤 형태로 파싱되고 바이너리에서 사용되는지 알 수 있다 최종적으로 시스템은 더 이상 테인트 된 객체가 없을 때 까지 분석을 수행한다
그림
[ 5 오픈소스 어플리케이션] Diode의 Request 및 Response 슬라이스 예제
와 슬라이싱을 수행할 때 분석의 방향이 두 상황에 다르게 작동한다 슬라이싱을 할 때 메시지 포맷의 정확도를 높이기 위해서 해당 객체와 관련 된 모든 인스트럭션을 슬라이싱 하는데 이 때 시스템은 의 규칙을 대 부분 이용한다 슬라이싱을 수행 할 때 시스템은 모든 를 거꾸로 뒤집고
규칙도 거꾸로 적용한다 즉 다시 말해 할당문의 경우는 방향에서 방향으로 테인트 대상 객체가 바뀐다 즉 이렇게 방향에 따라서 규칙
이 바뀌면서 테인트 시키는 것을 라 한다
§ 정규표현식 생성 모듈
이 모듈에서는 슬라이스를 입력으로하고 각 슬라이스에서 도출할 수 있는 메시지 포맷을 정규표현식으로 처리한다 세부적으로 이 모듈에서는 가지 처
리를 순서대로 수행한다 시스템은 파라메터 파라메터와
연관되는 객체를 모델을 통해서 인지한다 시스템은 전 단계에서 인지된 객체와 관련된 인스트럭션을 분석하면서 실제 정규표현식으로 된 메시지 포맷을 도출 한다 아래 에서 각 단계 세부 개발내용을 기술하였다
정규표현식 생성 모듈의 단계에서 모두 모델을 사용하는데 와
에서 통신을 위해서 널리 사용되는 메소드들을 대상으로 모델링 하였다 대
표적으로 와 개의 서드파티
라이브러리 또한 에서 기본적으로 제공하는 각종 에 대한 모델이 정립되 어 있다
첫 번째 단계는 객체 인지 단계로 정립된 모델을 이용해
서 시스템은 관련 데이터를 담고 있는 객체를 정확하게 인지
한다 본격적으로 슬라이스를 분석할 때 시스템에서는 내부적으로 각 객체에 대한 의 존성 그래프틀 생성한다 이 그래프를 기반으로 정규표현식을 생성하는데 슬 라이스의 경우는 객체에 대한 그래프와 파라메터에 대한 그래프가 생성 되어 논리적으로 개의 분리된 슬라이스가 각각 분석되는 것처럼 수행된다
파라메터 슬라이스 또한 슬라이스의 경우에는 뿐만 아니라 헤더의 정보까지 포함되어 있다
두 번째 단계는 정규표현식 도출 단계로 가지의 슬라이스를 이용해서 정규표현식을 도출한다 프로그램 슬라이스의 부터 객체 인지 단계에서 인지된 객체의 데 이터 흐름 분석을 통해서 관련 인스트럭션을 분석한다 그림 는 클라이언트 의 슬라이스 예제이며 이 예제에는 슬라이스를 각각 보여주고 있 다
시스템이 특정 객체에 어떤 동작을 가하는 인스트럭션을 만나면 알맞은 모 델을 찾아서 그 모델에 맞는 분석을 수행한다 분석이 끝나면 그림 과 같은 중간언 어로 표현되며 이것을 다시 정규표현식으로 변환한다 이 중간언어를 바탕으로 관련 객체들 사이의 의존성을 파악하고 정규표현식에 반영한다
그림
[ 6 메시지 생성 관련 인스트럭션을 인코딩하여] 정규표현식 도출에 사용하는 중간언어
그림 는 커뮤니티의 클라이언트 중 하나인 어플리케이션의 예제이 다 시스템은 네트워크 인지 프로그램 슬라이싱단계를 통해서 슬
라이스들을 효과적으로 도출해낸다 그림 는 하나의 를 기준으
로 도달 할 수 있는 모든 함수를 검은색 노드로 나타내고 시스템이 실제로 분석하는 함수를 붉은색 노드로 표시하였다 이는 전체코드의 에 해당하는 아주 적은 수치 라고 볼 수 있다
그림
[ 7] Diode 어플리케이션의 Sub-CFG
그림 의 예제를 보면 시스템은 메소드에서 모델을 통해서 첫 번째 매개변수가 객체임을 인지한다 거꾸로 데이터 흐름 분석을 수행하면서 이 메시지가 메소드를 이용하고 총 개의 이 도출 될 수 있음을 알 수 있다 이 예제에서는 함수내에서 다양한 블록들이 존재하고 정규표현식의 정확도와 커버리지를 높이기 위해서 시스
템은 그래프를 만든 후 흐름을 따라서 인스트럭션을
분석한다 그림 는 그림 의 함수에 대한 그래프와
이를 순회하면서 분석된 개의 파라메터 정규표현식을 나타내고 있
다 예를들어 을 순서로 순회하면
의 정규표현식이 도출된다
그림
[ 8] Diode의 Request 슬라이스의 Control Block Graph와 도출되는 모든 정규표현식
¡ 네트워크 행동 분석 정확도 검증 작업 상세 설명
§ 추진 내용
오픈소스 어플리케이션 저장소인 에서 통신을 사용하는 유명어플 리케이션 개에 대해서 을 통해 패킷을 수집하고 도출한 정규표현식 과 매칭하여 모두 포함하는 것을 확인하였다
§ 검증 실험 내용
그림 네트워크 모니터링 프로그램인 와 안드로이드 스마트폰 을 이용하여 에서 개의 오픈소스 어플리케이션을 선정하고 어플 리케이션에서 발생하는 모든 패킷을 수집한다
그림
[ 9] Diode의 HTTP 패킷을 Wireshark로 수집
개발된 자동분석 프레임워크에서 도출된 메시지 정규표현식을
로 제작된 스크립트로 비교하여 시스템에서 도출하는 정규표현식의 커버리 지와 정확도를 평가한다
아래의 표는 우리가 선정한 의 오픈소스 어플리케이션 목록과 각 어플리케이션이 어떤 프로토콜을 사용하고 어떤 를 사용하는 지 보여주고 있다 각 오픈소스 어플리케이션들의 프로토콜 및
은 소스코드 분석 및 수동 를 통해 조사하였다
App Protocol Message Type Request Response Adblock Plus(ADP) HTTPS GET, POST XML
AnarXiv (AXV) HTTP GET XML
blippex (BLP) HTTPS GET JSON
Diaspora WebClient(DIW) HTTP GET JSON Diode (DIO) HTTP(S) GET, POST JSON
iFixIt (IFX) HTTP GET JSON
Lightning (LTN) HTTP(S) GET XML
qBittorrent (QBT) HTTP GET, POST JSON radio reddit (RRD) HTTP(S) GET, POST JSON Reddinator (RDN) HTTP(S) GET, POST JSON
Twister (TWT) HTTP POST JSON
TZM (TZM) HTTPS GET XML
Wallabag (WLB) HTTP GET XML
Weather Notification (WTN) HTTP GET JSON
아래의 표는 선정한 모든 오픈 소스 어플리케이션을 대상으로 시스템에서 출력된 정규표현식의 개수와 으로 표현된 부분은 모든 캡쳐된 패킷을 시 스템에서 출력된 정규표현식이 매칭될 수 있는지 없는지를 비율로 나타 낸 결과이다 우리는 이 실험에서 시스템이 대상 어플리케이션의 모든 메시지 포맷을 도출 해낸 것을 증명하였다
App Request Response
Body #Pair
GET POST Body
Adblock Plus 2 (100%) 1 (100%) 1 (100%) 1 (100%) 1 (100%)
AnarXiv 2 (100%) - - 2 (100%) 2 (100%)
blippex 1 (100%) - - 1 (100%) 1 (100%)
Diaspora WebClient 1 (100%) - - 1 (100%) 1 (100%)
Diode 24 (100%) - - 2 (100%) 5 (100%)
iFixIt 15 (100%) 7 (100%) 3 (100%) 14 (100%) 14 (100%)
Lightning 2 (100%) - - 1 (100%) 1 (100%)
qBittorrent 3 (100%) 13 (100%) 13 (100%) 3 (100%) 3 (100%) radio reddit 3 (100%) 3 (100%) 3 (100%) 4 (100%) 4 (100%) Reddinator 3 (100%) 3 (100%) - 6 (100%) 6 (100%) Twister - 11 (100%) 11 (100%) 8 (100%) 8 (100%)
TZM 2 (100%) - - 1 (100%) 1 (100%)
Wallabag 1 (100%) - - 1 (100%) 1 (100%)
Weather Notification 2 (100%) - - 2 (100%) 2 (100%)
그림 시스템에서 도출된 정규표현식이 실 패킷을 매칭하는데 얼마나 많은 정보를 담고 있는지를 보여주기 위한 실험이다 각 정규표현식을 키워 드 단위로 나누고 소스코드분석 및 기 시스템에서 도출된 키워 드 개수를 나타내고 있다 이때 키워드는 과 의 쿼리스트링 과 파라메터의 필드로 정의하였다 우리는 과 소스코드 분 석을 통해서 파라메터의 경우는 개의 키워드를 발견했고 기 개 발된 시스템의 경우는 단 개의 키워드를 놓쳤다 동적 바이너리 업데이트 관련 네트워크 메시지 의 경우는 비슷하나 의 경우는 실 제 패킷에서는 많은 키워드가 있지만 소스코드에서는 반정도의 키워드만 사용됨을 발견하였다 이는 대부분 서버로부터 많은 양의 데이터를 받고 실 제로 바이너리에서 사용하는 데이터는 적다는 사실을 나타낸다
그림
[ 10 오픈소스별 키워드 개수비교]
¡ 네트워크 행동 분석 시간 검증 작업 상세 설명
§ 추진 내용
오픈소스 어플리케이션 저장소인 에서 통신을 사용하는 유명어플 리케이션 개에 대해서 네트워크 분석 실행 시간을 측정하여 초의 평균 분석 시간을 얻음 정량적 목표 분
§ 검증 실험 내용
에서 개의 오픈소스 어플리케이션을 선정하고 파일을 확보 한다
개발된 자동분석 프레임워크를 이용해 대상 어플리케이션들을 분석하여 와 의 정규표현식을 얻는 데 필요한 시간을
각각 측정한다
아래의 표와 그림 을 참고하면 평균 초의 실행 시간이 걸렸다 이는 목표였던 분을 훨씬 상회한다
어플리케이션 Request시간 초( ) Response시간 초( ) 총 시간 (초)
1 Adblock Plus 21 19 40
2 AnarXiv 7 6 13
3 blippex 21 16 37
4 Diaspora WebClient 7 9 16
5 Diode 77 99 176
6 iFixIt 193 48 241
7 Lightning 37 36 73
8 qBittorrent 21 21 42
9 radio reddit 12 9 21
10 Reddinator 58 55 113
11 Twister 6 5 11
12 TZM 11 8 19
13 Wallabag 20 21 41
14 Weather Notification 20 20 40
평균 36.5 26.6 63.1
그림
[ 11 안드로이드 프로토콜 자동 분석 시간 검증 그래프]
나 도출된 정규표현식들을 하나의 트랜잭션으로 페 어링하는 기능 개발 차년도에 완료를 목표
개발된 프레임워크를 확장하여 각 슬라이스들의 를 찾아서 하나의 트랜잭션으로 구성하는 모듈을 추가
¡ 추진 성과 및 검증 결과 요약
§ 프로그램 슬라이스 간 데이터의존성 분석을 위한 모듈의 설계 완료 프로그램 슬라이스 사이의 데이터 의존성 분석 완료
의존성 있는 슬라이스들의 페어 유추를 통해 하나의 트랜잭션으로 표현 완 료
§ 검증 결과
개 어플리케이션의 모든 메시지 페어 트랜잭션 를 도
출
개 어플리케이션의 커버리지 정확도 달성
§ 기대효과
1. 네트워크 행동 패턴 추론 (2차년도 목표 의 기반인) HTTP트랜잭션 유추
2. Request/Response 슬라이스의 의존성 분석으로 HTTP요청에 따른 알맞은 HTTP응답을 유추
¡ 개발 개요
정적 바이너리 분석을 통해 HTTP기반의 어플리케이션 트래픽 지문을 추출하였다 하지만. 트래픽 지문 뿐 만아니라 그들의 네트워크 행동패턴 (2차년도 목표 에 대해서도 분석하기 위) 해 Request/Response로 짝지어진 HTTP트랜잭션들을 추론 모듈 개발 완료하였다.
¡ 개발내역 상세설명
§ 슬라이스 간 의존성 분석모듈
기본적으로 이 모듈은 분석 이용해서 슬라이스와
슬라이스의 의존성을 분석하다 기술적으로 우리는 분석 기법을 사
분석 기법에는 와 라는 중요한 개념이 존재하며 전자는 분석의 시작지 점을 가리키고 후자는 분석의 종료지점을 가리킨다 결과적으로 에서 시작
하여 로 끝나는 가 존재하는지 확인한다
예를 들어 어떤 슬라이스의 를 가리키는 변수가 어떤 슬
라이스의 까지 가 존재하면 이 두 슬라이스는 하
나의 트랜잭션이라고 추론한다 그림 의 변수가 변수까지 흘
러가는 것을 예로 들 수 있겠다
¡ 검증 작업 상세 설명
§ 추진 내용
동적 바이너리 분석을 통해 HTTP기반의 어플리케이션 트래픽 지문의 메시지를 이용하여 트랜잭션의 신뢰성 검증 완료
§ 검증 실험 내용
가 의 검증 실험과 같이 네트워크 모니터링 프로그램인 와 안드 로이드 스마트폰을 이용하여 에서 개의 오픈소스 어플리케이션을 선정하고 어플리케이션에서 발생하는 모든 패킷을 수집한다
수집 된 패킷을 트랜잭션별로 분류한다
개발된 자동분석 프레임워크에서 도출된 트랜잭션 정규표현식을 로 제작된 스크립트로 비교하여 시스템에서 도출하는 정규표현식의 커버리지와 정확도를 평가한다
아래의 표는 선정한 모든 오픈 소스 어플리케이션을 대상으로 시스템에서 출력된 트랜잭션 정규표현식의 개수와 으로 표현된 부분은 모든 캡 쳐된 트랜잭션을 시스템에서 출력된 정규표현식이 매칭될 수 있는지 없는지를 비율로 나타 낸 결과이다 우리는 이 실험에서 시스템이 대상 어 플리케이션의 모든 트랜잭션을 도출 해낸 것을 증명하였다
App #Pair Adblock Plus 1 (100%)
AnarXiv 2 (100%)
blippex 1 (100%)
Diaspora WebClient 1 (100%)
Diode 5 (100%)
iFixIt 14 (100%)
Lightning 1 (100%) qBittorrent 3 (100%) radio reddit 4 (100%) Reddinator 6 (100%)
Twister 8 (100%)
TZM 1 (100%)
Wallabag 1 (100%)
Weather Notification 2 (100%)
다 확률적 대역폭 보장을 위한 단일 중앙 클라우드에서 가상화 서비스 요청 모델 정 립
정규분포 기반의 가상화 서비스 요청 모델 정립
¡ 추진 성과 및 검증 결과 요약
§ 고객의 통계를 기반으로 서비스 품질 요청을 정의할 수 있는 가상화 서비스 모델 개발 완료
정규분포를 기반으로 서비스 품질 수준을 정의할 수 있는 고객 단일 중앙 클라 우드 간 호스모델 개발 완료
확률적 서비스 요청 모델과 기존의 결정적 서비스 요청 모델의 관계를 추론하기 위한 수식적 분석
§ 기대효과
고객의 통계적 요구사항을 받아들일 수 있으므로 네트워크 가상화 서비스 모델로 서 더 적합
작업 보장성과 통계적 다중화를 동시에 달성함으로써 기존 가상화 서비스 모델 대 비 더 많은 고객을 수용
확률적 대역폭 보장으로 인한 통계적 다중화 이득의 인터넷 전송 구간 으로 의 확장
¡ 개발 개요
서비스 품질 보장을 위한 초기 요소 기술
IoT 로써 단, 일 중앙 클라우드의 확률적 네트워크
가상화 서비스 기술을 위하여, 정규분포 기반의 서비스 요청 방식의 모델 정립을 완료하였 다.
¡ 개발내역 상세 설명
§ 개발 모델 기본 개념도
그림
[ 12 호스 모델]
그림 는 가상 네트워크 요청 방식 중 호스 모델을 나타낸 것이다 그림 와 같이 고객은 서버의 개수와 각 서버들로부터 연결된 스위치까지 들어오고 나가는 대역폭을 명시할 수 있다 호스 모델은 또 다른 요청 방식인 파이프 모델에 비해 사용자가 필요로 하는 대역폭을 명시하기 쉽고 사업자에게는 유연하게 네트워크 자원을 운용하게 한다는 장점이 있다 때문에 우리의 호스 모델을 기반으로 가상 네트워크 서비스 요청 인터페이스를 개발하였다
§ 확률적 호스 모델 상세 설명 및 장점
그림
[ 13 확률적 호스 모델과 기존 호스 모델의 비교]
그림 는 기존 호스 모델과 우리가 제안하는 확률적 호스 모델의 비교표이다 두 모델 모두 서버의 개수와 그 서버들을 연결시키는 스위치의 형태로 가상 네트 워크를 요청하는 호스 모델을 기반으로 한다 하지만 기존의 호스 모델에서는 고 객이 필요로 하는 네트워크 자원의 양을 하나의 숫자로 나타낼 수밖에 없는 것에 비해 확률적 호스 모델에서는 정규 분포의 형태로 표현한다 확률적 호스 모델의 명시 방법에서 은 서버의 개수 μ와 σ는 트래픽 최고값의 평균 및 표준 편차 ε
는 에러 확률을 의미한다 예를 들어 는 고객이 개의
서버를 필요로 하고 서버와 스위치 간 대역폭이 의 정규 분포 형태로 만큼 보장되어야 함을 뜻한다 고객은 각 서버와 스위치 간 필요로 하 는 대역폭을 다른 값으로 요청하고 싶을 때 트래픽 행렬의 형태로 이를 표현할 수 있다
트래픽은 랜덤 프로세스이므로 시간에 따라 필요로 하는 대역폭이 다르다는 특 징을 가지고 있다 확률적 호스 모델은 고객이 필요로 하는 대역폭을 통계적으로 요구할 수 있으므로 요청방식으로서 더 적합하다 뿐만 아니라 기존 호스 모델은 고객의 트래픽의 양이 많지 않더라도 일정한 양의 대역폭을 할당하기 때문에 네 트워크 자원이 낭비될 수 있다는 단점이 존재한다 하지만 확률적 호스 모델은 사 업자가 서비스 품질을 보장함과 동시에 통계적 다중화를 달성할 수 있으므로 기 존 호스 모델 대비 더 효율적인 네트워크 자원 운용이 가능하다
§ 기존 호스 모델과의 비교
그림
[ 14 확률적 호스 모델과 기존 호스 모델의 비교 수식]
확률적 호스 모델의 성능을 검증하기 위해서는 동일한 서비스 품질을 갖는 비교 대상이 필요하다 그림 는 확률적 호스 모델을 동일한 서비스 품질의 기존 호스 모델로 변환하는 방법 중 하나이다 우리는 위의 수식을 이용하여 시뮬레이션에서 확률적 호스 모델의 우수성을 입증하였다
라 단일 중앙 클라우드에서 가상화를 위한 네트워크 자원 할당 방법 설계 및 수락 제 어 메커니즘 개발
서비스 품질 보장 여부를 기반으로 가상 네트워크 요청의 수락 및 제어를 판 단하는 메커니즘 개발
¡ 추진 성과 및 검증 결과 요약
§ 확률적 서비스 요청 모델에 대한 수락 제어 메커니즘 및 자원 할당 알고리 즘 개발 완료
확률적 서비스 요청에 대해서 서비스 품질 보장이 가능할 때에만 요청을 허용하는 수락 제어 메커니즘 개발 완료
각 서비스마다 최소의 네트워크 자원을 할당하는 자원 할당 알고리즘 개발 완료
§ 확률적 및 기존 결정적 서비스 요청 모델을 대상으로 수락 제어 메커니즘 결과를 도출하는 실험을 수행
트리 구조의 단일 데이터센터를 갖는 시뮬레이션 환경 구축 완료
확률적 및 기존 결정적 호스 모델 요청에 대한 수락 제어 메커니즘 결과를 도출하 는 시뮬레이션 수행 및 성능 비교 완료
§ 검증 결과
기존 결정적 호스 모델 대비 더 많은 고객 수용 고객의 요청보다 더 우수한 서비스 품질을 제공
§ 기대효과
효율적인 네트워크 자원과 고객의 요청보다 더 우수한 작업 보장성을 동시에 달성 할 수 있으므로 실용적인 서비스 모델로서의 안착 가능
가상화 서비스의 가격 인하 등의 부가가치를 창출시켜 더 활발한 네트워크 자원 운용이 가능
¡ 개발 개요
정규분포 기반의 서비스 요청 방식의 모델을 기반으로 단일 중앙 클라우드의 확률적 네트 워크 가상화 서비스 기술을 구현하기 위하여 네트워크 자원 할당 알고리즘을 개발 및 추가 적인 자원 관리 모듈을 개발을 완료하였다.
¡ 개발내역 상세 설명
§ 수락 제어 장치 알고리즘
사업자가 트리구조의 단일 데이터 센터 클라우드 내에서 할당할 수 있는 같은 서브 트리- (sub-tree)내의 가상 머신 개수는 1) 그 서브 트리 내의 비어있는 가상- 머신 슬롯의 개수와 2) 각 링크의 이용 가능한 대역폭 두 조건과 연관이 있다, . 가상 머신과 네트워크 자원을 가장 효율적으로 할당하는 방법을 찾는 최적화 문 제는 다항시간(Polynomial-time) 내에 풀 수 없는 NP-난해(NP-hard)로 알려져 있 기 때문에 본 발명에서는 자원을 할당하기 위한 근사 방법으로서 옥토퍼스, , (2011 년 Sigcomm 논문에 수록 에서 사용했던 것처럼 작은 단위의 서브 트리부터 탐색) - 하는 탐욕 알고리즘(Greedy algorithm)을 사용한다.
그림 는 수락 제어 장치에서 가상 머신 할당을 위해 사용하는 탐욕 알고리
[ 15] ·
즘의 예로서 하나의 서버가 하이퍼바이저에 의해, 4개의 가상 머신으로 분할될 수 있을 때 <4, D>의 호스 모델을 이용한 가상 네트워크 요청이 들어온 경우이다 수. 락·제어 장치는 요청이 들어온 만큼의 가상 머신을 할당하기 위해서 잎 노드 에서 루트 까지 작은 단위의 서브 트리부터 탐색한다 그림 의
(Leaf node) (Root) - . [ 15]
왼쪽 그림에서 보듯이 4개의 가상 머신을 단일 서버에 할당하는 것은 불가능하므 로, [그림 15]의 오른쪽 그림처럼 한 층을 더 올라가고 나서야 가상 머신 할당이 가능해진다.
그림
[ 15 기 수락] ·제어 장치에서 할당 가능한 가상 머신 슬롯을 탐색하는 알고리즘의 예
수락·제어 장치는 그림[ 15]에서 설명한 1번 조건 외에도, 2번 조건 역시 고려 해야 한다 각 링크마다 필요한 양의 대역폭은 해당 링크와 연결된 서브 트리 내. - 에 할당하고자 하는 가상 머신의 개수에 따라 달라진다 예를 들어. , <4, 100, 102>
의 확률적 호스 모델 요청을 그림[ 16]과 같이 할당하려고 할 때 붉은 색 링크에, 필요한 대역폭은 그 링크와 연결된 서브 트리에 할당하려는 가상 머신의 개수와- , 나머지 네트워크에 할당하고자 하는 가상 머신의 개수 중 최소값( × 요청한 대
당을 위해서 붉은 링크에 필요한 대역폭은 D이다.
그림
[ 16 기 알고리즘의 서브 트리 링크] - 조건의 예
번 조건을 일반화하면 가상 네트워크 요청이
2 r : <Nn, μn, σn, εn>의 확률적 호 스 모델로 들어왔을 때 사업자는 그 중 개의 가상 머신을 특정 서브 트리에 할, i - 당하고 그 서브 트리와 연결된 링크는, - L인 시나리오를 생각해 볼 수 있다 각 고. 객이 생성하는 트래픽은 독립적이고 모두 정규 분포를 따르므로 링크, L을 지나 는 모든 트래픽의 합 또 하나의 정규 분포로 표현될 수 있다 정리하면 링크. , L을 지나는 모든 트래픽의 합은 <μe,σe>의 정규 분포를 따르고 εe의 서비스 품질 파 라미터를 갖는다. 새로운 고객과 이미 서비스를 이용 중인 고객 모두에게 확률적 대역폭 보장을 제공하기 위해서는 링크, L의 대역폭 B가 아래 식을 만족해야 한 다. F는 표준 정규 분포의 누적밀도함수(Cumulative density function)를 가리킨다.
B ≥ μ + σF−1(1−ε)
=
μ μe+μn·min{i,Nn-i}, σ2 = σe2+σn2 ·min{i,Nn-i}, 1−ε = max{1−εe, 1−εn}
그림 은 위에서 기술한 가지 제약 조건을 고려하는 서버 및 네트워크 자원 할당 알고리즘이다
그림
[ 17 수락] ·제어 모듈 알고리즘
¡ 시뮬레이션을 통한 기 가상화 서비스 모델의 성능 검증 작업 상세 설명
§ 추진 내용
가상화 서비스 모델의 서비스 요청의 수락 비율과 평균 서비스 품질 값 측정하 여 본 모델이 더 많은 고객 수용 가능함을 확인
§ 검증 시뮬레이션 환경
시뮬레이션에서는 확률적 호스 모델의 성능을 검증하기 위해서 서비스 요청 의 수락 비율과 평균 서비스 품질 값을 기존 호스 모델과 비교하였다 그림 은 우리가 수행한 시뮬레이션 환경 중 데이터센터 네트워크 구조를 나타낸 그 림이다 총 개의 가상머신이 개의 서버에 개씩 나뉘어져 있는 단계의 트리 토폴로지로써 모든 링크는 의 용량을 갖는 것으로 설정하였다
명의 고객으로부터 가상 서비스 요청이 들어오는 시뮬레이션 시나리오에서 가상 머신의 개수 와 대역폭의 평균값 μ 은 성능에 영향을 미치지 않으므로 값을 고 정시켰고 표준편차 와 에러 확률 을 변화시켰다 그림 는 표준편차와 에러 확률을 변화시킨 각 시나리오에서 사용한 파라미터의 값이다
그림
[ 18 시뮬레이션에서 사용된 데이터센터 네트워크 구조]
그림
[ 19 각 시뮬레이션 시나리오에서 사용된 파라미터 값]
§ 확률적 및 결정적 호스 모델 시뮬레이션 결과 비교
그림 은 표준편차 값이 달라질 때 서비스 요청의 수락 비율과 평균 서비스 품질 값을 나타낸 그래프이다 그림 의 왼쪽 그림에서 보듯이 확률적 서비스 요청 모델이 기 시스템에 들어왔을 때 약 많은 고객을 수용할 수 있음을 알 수 있고 이는 통계적 다중화를 달성함으로써 대역폭을 절약했기 때문이다 그림 의 오른쪽 그림은 고객에게 보장되는 평균 서비스 품질이다 확률적 서비스 모 델을 이용했을 경우 더 높은 평균 서비스 품질을 보장할 수 있는데 그 이유는 사 업자가 대역폭을 절약했을 뿐 아니라 해당 링크를 사용하는 모든 트래픽의 서비 스 품질 중 최대치를 고객들에게 제공하기 때문이다
그림
[ 20 표준편차가 변하는 시나리오에서의 요청 수락 비율과 평균 서비스 품질]
그림 은 에러 확률이 달라질 때 서비스 요청의 수락 비율과 평균 서비스 품 질 값을 나타낸 그래프이다 그림 에서와 마찬가지로 기존 호스 모델 대비 더 높은 수락 비율과 서비스 품질 보장을 동시에 달성할 수 있음을 검증하였다
그림
[ 21 에러 확률이 변하는 시나리오에서의 요청 수락 비율과 평균 서비스 품질]
![그림 는 주소 수집에 대한 개념도이다 컨트롤러는 네트워크 내 각 스위치와[22]. 연결되어 있으며 컨트롤러는 네트워크와 연결되면서 각 스위치가 가지고 있는 연, 결된 호스트 및 연결된 스위치 스위치 자신의 정보를 수집하게 된다 이것이 컨,](https://thumb-ap.123doks.com/thumbv2/123dokinfo/5434201.232357/33.892.145.715.623.903/개념도이다-컨트롤러는-네트워크-스위치와-연결되어-컨트롤러는-네트워크와-연결되면서.webp)
