KR102222868B1

KR102222868B1 - Usb 시리얼 장치에 대한 리눅스 기반 보안 시스템 및 방법

Info

Publication number: KR102222868B1
Application number: KR1020190051581A
Authority: KR
Inventors: 김상진; 김영환; 정동섭
Original assignee: (주)휴네시온
Priority date: 2019-05-02
Filing date: 2019-05-02
Publication date: 2021-03-04
Also published as: KR20200127451A

Abstract

본 발명은 리눅스 기반 보안 시스템 및 해당 시스템의 외부 장치에 대한 보안 방법에 대한 것으로, 응용 프로그램에 대한 인증 상태 정보에 기초하여 응용 프로그램의 외부 장치 사용 여부를 결정하되, 해쉬 코드 값들을 비교하여 결정하는 구성을 포함한다.

Description

USB 시리얼 장치에 대한 리눅스 기반 보안 시스템 및 방법{LINUX-BASED SECURITY SYSTEMS AND METHODS FOR USB SERIAL DEVICES}

본 발명은 리눅스 기반 시스템의 USB 시리얼 장치에 대한 보안 방법에 대한 것으로, 보다 상세하게는 리눅스 시스템에서 커널이 USB 시리얼 장치에 안전한 보안을 적용하는 방법에 대한 것이다.

USB 장치는 Plug-and-Play라는 특징이 있으며, 해당 특징으로 인해 새로이 등장하는 많은 장치들이 USB 유형으로 개발되고 있다. USB 장치 유형 중 USB 시리얼 장치가 있다. USB 시리얼 장치에는 USB-to-Serial Bridge, 더미 터미널(dummy Terminal), LTE 통신 모뎀, 3G 통신 모뎀, Bluetooth 기기, GPS 기기 등이 있다.

이때 임베디드 시스템에서부터 서버급에 이르기 까지 많은 리눅스 시스템에서 USB 시리얼 장치를 채용하고 있다. 리눅스 시스템은 이와 같은 USB 시리얼 장치를 쉽게 사용할 수 있도록 단순한 장치 파일 인터페이스, 편리하고 많은 리눅스 명령어들, 잘 알려진 리눅스 응용 프로그램 등을 제공하고 있다. 아울러 리눅스 시스템은 초보 개발자도 쉽게 자신의 응용 프로그램을 개발할 수 있는 개발 환경을 제공하고 있다. 리눅스 시스템은 사용자들에게 사용 편의성을 최대한 제공한다는 장점과 더불어 USB 시리얼 장치를 안전하게 사용하게 하는 보안 수단이 부족하다는 약점이 함께 존재한다

이와 같은 유용한 USB 시리얼 장치를 쉽게 사용할 수 있도록 리눅스 시스템은 다양한 사용자 편의성을 제공하고 있다. 사용자 편의성의 예로써 단순한 장치 파일 인터페이스, 많은 편리한 리눅스 명령어, 잘 알려진 리눅스 응용 프로그램 등을 들 수 있다. 아울러 리눅스 시스템은 초보 개발자도 쉽게 자신의 응용 프로그램을 개발 할 수 있는 개발 환경을 제공하고 있다.

장치 파일 인터페이스를 좀 더 자세히 설명하면 모뎀이 없는 첫번째 시리얼 장치는 /dev/ttyUSB0, 두번째 시리얼 장치는 /dev/ttyUSB1 등과 같은 방법으로 명명된다. 모뎀이 있는 첫번째 시리얼 장치는 /dev/ttyACM0, 두번째 시리얼 장치는 /dev/ttyACM1 등과 같은 방법으로 명명된다. ARM 플랫폼에서 첫번째 시리얼 장치는 /dev/ttyAMA0, 두번째 시리얼 장치는 /dev/ttyAMA1 등과 같은 방법으로 명명된다.

Serial 장치를 편리하게 사용할 수 있게 하는 리눅스 쉘 명령으로는 ">"(표준 입력 리다렉션), ">"(표준 출력 리다이렉션), "2>"(표준 에러 리다렉션), "|"(명령어 수행 결과 파이프), cat, echo, cu 등이 있다.

Serial 장치를 편리하게 사용할 수 있게 하는 리눅스 응용 프로그램으로는 minicom, picocom 등이 있다.

리눅스 시스템은 시스템 사용자에게 사용 편의성을 무제한적으로 제공한다는 이점이 있으나 장치 사용의 안전을 보장하는 수단이 적다는 약점이 있다. 즉, 다수의 사용자가 임의의 응용 프로그램을 사용하여 시리얼 장치에 동시에 접근하는 것에 제한을 가하지 않는다. 이로 인해 보안이 중요치 않는 사용 환경하에서는 문제가 되지 않으나 보안이 요구되는 용도에는 USB 시리얼 장치가 사용될 수 없다.

따라서, 보안 기능이 부족한 USB 시리얼 장치에 강력한 보안 기능을 적용하여 장치 사용의 안정성을 제공하는 기술이 필요한 실정이다.

본 발명은 사용 편의성은 높으나 보안성이 낮은 USB 시리얼 장치에 대해 리눅스 커널이 안전한 보안을 적용하는 목적이 있다.

본 발명은 시스템이 안전한 보안을 제공하여 시스템이 허용하기로 결정한 특정 응용 프로그램에 대해서만 USB 시리얼 장치 사용권을 부여하는데 그 목적이 있다.

본 발명은 USB 시리얼 장치 사용이 인증된 특정 응용 프로세스 외의 프로세스에 대해서 사용자가 실수로 USB 시리얼 장치를 사용하려고 시도한 경우, 그 사용을 금지하는데 그 목적이 있다.

본 발명은 USB 시리얼 장치 사용이 인증된 특정 응용 프로그램을 가장한 거짓 응용 프로그램으로 공격을 받는 경우, 거짓 응용 프로그램의 USB 시리얼 장치의 사용을 제지하는데 그 목적이 있다.

본 발명은 특정 응용 프로그램의 유출, 시스템 콜 모니터링 도구를 사용하여 동작 코드 이해, 리버스 엔지니어링 기술을 사용하여 동작 코드 이해 등을 통해 특정 응용 프로그램을 가장한 위변조 프로그램을 개발하여 공격하더라도 보안이 위협받지 않는 안전성을 가진 보안 방법을 제공하는데 그 목적이 있다.

본 발명은 USB 시리얼 장치 보안을 제공하는 핵심 수단인 공개된 해쉬 코드 텍스트 파일을 위변조하더라도 보안이 위협받지 않는 안전성을 갖춘 보안 방법을 제공하는데 그 목적이 있다.

본 발명에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

본 발명은 리눅스 기반 보안 시스템 및 해당 시스템의 외부 장치에 대한 보안 방법에 대한 발명에 해당될 수 있다. 하기의 실시예들은 보안 시스템 및 보안 방법에 모두 적용될 수 있는 실시예들에 해당될 수 있다.

본 발명의 실시예에 따라 보안 방법을 수행하기 위하여 시스템에 대해 초기 설정을 수행하는 단계, 초기 설정된 시스템 정보에 기초하여 응용 프로그램의 보안성에 대해 판단하고, 응용 프로그램에 대한 인증 상태 정보를 결정하는 단계 및 응용 프로그램의 외부 장치에 대한 사용 요청을 수신한 경우, 인증 상태 정보에 기초하여 응용 프로그램의 외부 장치 사용 여부를 결정하는 단계를 포함할 수 있다.

이때 인증 상태 정보를 결정하는 경우, 제 1 해쉬 코드 값과 제 2 해쉬 코드 값을 비교하여 결정하되, 제 1 해쉬 코드 값은 초기 설정 시에 생성된 보안 엔진 응용 프로그램에 대한 해쉬 코드 값이고, 제 2 해쉬 코드 값은 응용 프로그램에 대한 해쉬 코드 값에 해당될 수 있다.

본 발명의 일 실시예에 있어서, 제 2 해쉬 코드 값은 응용 프로그램의 바이너리 파일의 저장 위치를 파악하고, 바이너리 파일로부터 해쉬 코드를 도출한 값에 기초하여 생성될 수 있다.

본 발명의 일 실시예에 있어서, 제 1 해쉬 코드 값과 제 2 해쉬 코드 값이 동일한 경우, 응용 프로그램은 보안 엔진 응용 프로그램에 해당되는 것으로 판단되어 인증 상태 정보는 허용 상태로 결정될 수 있다.

본 발명의 일 실시예에 있어서, 제 1 해쉬 코드 값과 제 2 해쉬 코드 값이 동일하지 않은 경우, 응용 프로그램의 인증 상태 정보는 불허 상태로 결정되어 응용 프로그램은 종료될 수 있다.

본 발명의 일 실시예에 있어서, 시스템 초기 설정을 수행한 후 tty (teletypewriter) 장치에 대해 수행되고 있는 프로세스들이 종료될 수 있다.

본 발명의 일 실시예에 있어서, 응용 프로그램이 tty 장치의 파일 열기를 요청하여 허용된 경우, 동적 할당 메모리 상에 상기 tty 장치의 자료 구조가 할당될 수 있다.

본 발명의 일 실시예에 있어서, 보안 엔진 응용 프로그램은 배타적 모드 단계를 포함하되, tty 장치의 파일 열기를 요청하여 허용된 경우 보안 엔진 응용 프로그램은 배타적 모드 적용을 요청하여 다른 상기 응용 프로그램의 상기 tty 장치의 파일 열기를 차단할 수 있다.

본 발명의 일 실시예에 있어서, 보안 엔진 응용 프로그램의 바이너리 파일은 마운트 파일 시스템에 저장되고, 보안 엔진 응용 프로그램의 해쉬 코드 파일은 루트 파일 시스템에 저장될 수 있다.

본 발명의 일 실시예에 있어서, 루트 파일 시스템은 메모리 파일 시스템에 해당할 수 있다.

본 발명의 일 실시예에 있어서, 시스템은 USB 호스트 제어기로부터 신호를 수신하고 상기 인증 상태 정보가 허용 상태로 결정된 경우, 신호로부터 도출된 문자열이 버퍼에 저장될 수 있다.

본 발명의 일 실시예에 있어서, 응용 프로그램의 외부 장치에 대한 문자열 읽기 시스템콜을 호출한 경우, 버퍼에 상기 문자열이 저장되어 있는지 판단하고, 문자열이 저장되어 있는 경우 응용 프로그램으로 상기 문자열을 전송할 수 있다.

본 발명의 일 실시예에 있어서, 응용 프로그램에서 외부 장치에 대한 문자열 쓰기 시스템콜을 호출하고 인증 상태 정보가 허용 상태로 결정된 경우, USB 호스트 제어기로 문자열 쓰기 명령을 전송할 수 있다.

본 발명의 일 실시예에 있어서, 응용 프로그램의 인증 상태 정보를 결정하기 위한 인증 요청 신호에 기초하여 상기 응용 프로그램의 보안성에 대해 판단할 수 있다.

본 발명의 일 실시예에 있어서, 응용 프로그램이 인증 종료를 요청한 경우, 상기 인증 종료 요청에 기초하여 상기 인증 상태 정보를 변경할 수 있다.

본 발명은 시스템이 허용하기로 결정한 특정 응용 프로그램에만 특정 USB 시리얼 장치에 대한 사용 권한을 독점적으로 허용한다. 아울러 특정 응용 프로그램을 제외한 여타 응용 프로그램에 대해서는 어느 한 순간도 사용 권한이 허용되는 순간이 없다.

어떤 순간이든 로컬의 특정 USB 시리얼 장치는 오직 특정 응용 프로그램에 의해서만 사용된다. 즉, 둘 이상의 응용 프로그램들이 공유하는 순간이 없다. 그 결과 기밀성(Confidentiality)을 별도로 구현할 필요가 없다. 아울러 무결성(Integrity)을 검사가 불필요하다. 상대 시스템이 수신한 문자열은 오직 특정 응용 프로그램에 의해 송신 되었음을 부인할 수 없다(Non-Repudiation). 다른 응용 프로그램이 훔쳐보기를 시도하는 것이 불가능하다. USB 시리얼 장치에 대해 이와 같은 강력한 보안이 적용되지만 USB 시리얼 장치의 사용 편의성은 전혀 반감되지 않는다

본 발명에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

도 1은 본 발명의 일 실시예에 따른 USB 시리얼 장치에 대한 리눅스 기반 보안 시스템에 대한 구성도에 해당된다.
도 2는 본 발명의 일 실시예에 따른 리눅스 기반 시스템의 USB 시리얼 장치에 대한 보안 방법에 대한 흐름도에 해당될 수 있다.
도 3(a) 및 (b)는 본 발명의 일 실시예에 따라 리눅스(Linux)에 기반한 외부 장치 보안 시스템의 특징을 설명하기 위한 도면이다.
도 4는 본 발명의 일 실시예로, USB 시리얼 장치 보안 시스템의 초기 설정 동작에 대한 흐름도를 나타낸 도면이다.
도 5는 본 발명의 일 실시예에 따라, 응용 프로그램이 USB 시리얼 장치를 본격 사용 하기에 앞서 수행 객체들이 수행되어야 할 올바른 절차를 순서도로 나타낸 것이다.
도 6은 본 발명의 일 실시예에 따라, 응용 프로그램이 USB 시리얼 장치를 본격 사용시 수행 객체들이 수행해야 할 올바른 절차를 순서도로 나타낸 도면에 해당된다.
도 7은 본 발명의 일 실시예에 따라, 응용 프로그램이 USB 시리얼 장치를 본격 사용이 끝난 뒤 수행 객체들이 수행해야 할 올바른 절차를 순서도로 나타내었다.

본 발명의 실시 예를 설명함에 있어서 공지 구성 또는 기능에 대한 구체적인 설명이 본 발명의 요지를 흐릴 수 있다고 판단되는 경우에는 그에 대한 상세한 설명은 생략한다. 그리고, 도면에서 본 발명에 대한 설명과 관계없는 부분은 생략하였으며, 유사한 부분에 대해서는 유사한 도면 부호를 붙였다.

본 발명에 있어서, 어떤 구성요소가 다른 구성요소와 "연결", "결합" 또는 "접속"되어 있다고 할 때, 이는 직접적인 연결관계뿐만 아니라, 그 중간에 또 다른 구성요소가 존재하는 간접적인 연결관계도 포함할 수 있다. 또한 어떤 구성요소가 다른 구성요소를 "포함한다" 또는 "가진다"고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 배제하는 것이 아니라 또 다른 구성요소를 더 포함할 수 있는 것을 의미한다.

본 발명에 있어서, 제1, 제2 등의 용어는 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용되며, 특별히 언급되지 않는 한 구성요소들간의 순서 또는 중요도 등을 한정하지 않는다. 따라서, 본 발명의 범위 내에서 일 실시 예에서의 제1 구성요소는 다른 실시 예에서 제2 구성요소라고 칭할 수도 있고, 마찬가지로 일 실시 예에서의 제2 구성요소를 다른 실시 예에서 제1 구성요소라고 칭할 수도 있다.

본 발명에 있어서, 서로 구별되는 구성요소들은 각각의 특징을 명확하게 설명하기 위함이며, 구성요소들이 반드시 분리되는 것을 의미하지는 않는다. 즉, 복수의 구성요소가 통합되어 하나의 하드웨어 또는 소프트웨어 단위로 이루어질 수도 있고, 하나의 구성요소가 분산되어 복수의 하드웨어 또는 소프트웨어 단위로 이루어질 수도 있다. 따라서, 별도로 언급하지 않더라도 이와 같이 통합된 또는 분산된 실시 예도 본 발명의 범위에 포함된다.

본 발명에 있어서, 다양한 실시 예에서 설명하는 구성요소들이 반드시 필수적인 구성요소들은 의미하는 것은 아니며, 일부는 선택적인 구성요소일 수 있다. 따라서, 일 실시 예에서 설명하는 구성요소들의 부분집합으로 구성되는 실시예도 본 발명의 범위에 포함된다. 또한, 다양한 실시 예에서 설명하는 구성요소들에 추가적으로 다른 구성요소를 포함하는 실시 예도 본 발명의 범위에 포함된다.

이하에서는 첨부한 도면을 참고로 하여 본 발명의 실시 예에 대하여 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나, 본 발명은 여러 가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시 예에 한정되지 않는다.

도 1은 본 발명의 일 실시예에 따른 외부 장치에 대한 리눅스 기반 보안 시스템에 대한 구성도에 해당된다.

본 발명을 통해 외부 장치에 안전한 보안을 제공할 수 있다. 특히 본 발명의 일 실시예에 따라 본 발명은 USB 시리얼 장치에 대해 안전한 보안을 제공할 수 있다. 이때 본 발명에 따르면 외부 장치에 대해 안전한 보안을 제공하기 위하여 리눅스에 기반한 시스템에 발명을 구현할 수 있으며, 해당 내용은 도 3 내지 도 7에서 보다 상세히 설명할 수 있다.

본 발명에서 외부 장치는 본 발명의 보안 시스템과 접속되어 정보를 송수신할 수 있는 장치를 의미할 수 있으며, 본 발명의 일 실시예에 따라 USB 시리얼 장치가 외부 장치에 포함될 수 있다. 다만, 외부 장치는 USB 시리얼 장치에 한정되는 것은 아니며, 하기에서는 발명의 설명의 편의성을 위해 USB 시리얼 장치로 설명하나 해당 구성에 한정되는 것은 아니다. 또한, USB 시리얼 장치는 USB-to-Serial Bridge, 더미 터미널(dummy Terminal), LTE 통신 모뎀, 3G 통신 모뎀, Bluetooth 기기, GPS 기기 등이 포함되는 장치를 통칭하는 명칭에 해당될 수 있으나, 언급한 실시예에 한정되지 않는다.

본 발명에 따르면 외부 장치 사용 권한을 특정 응용 프로그램(이하, 보안 엔진 응용 프로그램) 하나에만 독점적으로 허락하고, 나머지 응용 프로그램들로부터 발생하는 USB 시리얼 장치 사용 시도를 불허하는 강력한 보안 기능을 제공할 수 있다. 즉, 둘 이상의 응용 프로그램이 동시에 USB 시리얼 장치를 사용하지 않도록 제어할 수 있다. 이와 같이 USB 시리얼 장치에 안전한 보안이 강건하게 동작되면 리눅스 기반 보안 시스템에서 USB 시리얼 장치를 보안 목적의 장치로 활용할 수 있게 된다는 이점이 존재한다.

본 발명에서 보안 엔진 응용 프로그램은 시스템이 특정 외부 장치를 사용할 수 있는 권한을 허용하기로 결정한 한 개의 특정 응용 프로그램으로 정의될 수 있다. 즉, 본 발명의 실시예에 따를 때 보안 엔진 응용 프로그램은 시스템이 기 설정한 응용 프로그램으로서, 특정 USB 시리얼 장치를 사용할 수 있는 단 하나의 특정 응용 프로그램에 해당될 수 있다.

일반적으로 언급되는 인증은 사용자 인증을 의미한다. 이때 사용자 인증은 사용자가 어떤 응용 프로그램을 사용하고자 하면 응용 프로그램 내부 코드 혹은 시스템 라이브러리에 의해 인증이 수행되고, 인증이 성공한 경우에만 사용자에 대해 응용 프로그램 사용이 허락되고 그렇지 않는 경우에는 거부될 수 있다.

그러나 본 발명에서의 인증은 상기와 같은 일반적인 사용자 인증을 의미하는 것이 아니라 응용 프로그램에 대한 인증을 의미할 수 있다. 본 발명의 인증은 사용자의 개입 없이 자동으로 수행하기 위하여 암호키를 사용하지 않고 해쉬 코드 방식을 사용하여 인증을 수행하는 것을 의미할 수 있다. 그리고 공격자의 공격을 안전하게 방어하기 위하여 루트 파일 시스템으로써 메모리 기반 파일 시스템을 사용할 수 있다.

본 발명에서 인증 상태 정보는 해당 응용 프로그램이 외부 장치에 접근할 수 있도록 시스템이 기설정한 보안 엔진 응용 프로그램에 해당되는지 여부에 대한 정보에 해당될 수 있다. 따라서 인증을 요청한 응용 프로그램이 인증이 되면 인증 상태가 디폴트 값 Off에서 On으로 변경될 수 있으며, 해당 응용 프로그램에 대해서 인증 상태 정보가 허용 상태로 결정될 수 있다. 또한 응용 프로그램의 인증 상태가 Off 값인 경우, 해당 응용 프로그램에 대해서 인증 상태 정보가 불허 상태로 결정될 수 있다.

이때 리눅스 기반 보안 시스템(100)은 응용 프로그램부(110), 리눅스 커널부(120), 보안 엔진 해쉬 코드 파일부(130), 보안 엔진 바이너리 파일부(140) 및 USB 호스트 제어기(150)를 포함할 수 있다.

이때 리눅스 커널부(120)는 응용 프로그램 인증 루틴부(122) 및 인증 검사 매크로부(124)를 포함할 수 있다.

이때 응용 프로그램부(110)는 보안 엔진 응용 프로그램(312), 배포 응용 프로그램(314) 및 보안 엔진 위변조 프로그램(316)과 같은 응용 프로그램들의 USB 시리얼 장치에 대해 열기, 읽기, 쓰기, 닫기 등의 요청을 리눅스 커널로 전달할 수 있다.

본 발명의 일 실시예에 따라 응용 프로그램부(110)는 보안 엔진 응용 프로그램(312)에서 생성한 인증 켜기 및 인증 끄기 요청 신호를 응용 프로그램 인증 루틴부(122)로 전달할 수 있다.

이때 응용 프로그램 인증 루틴부(122)는 리눅스 커널(320)내 tty core(321)의 응용 프로그램 인증 루틴(322)의 동작을 수행할 수 있다.

이때 인증 검사 매크로부(124)는 리눅스 커널(320) 내 tty 디바이스 드라이버(323)의 인증 검사 매크로(324)의 동작을 수행할 수 있다.

이때 보안 엔진 해쉬 코드 파일부(130)는 메인 메모리(330)로 사용되는 루트 파일 시스템(332)에 저장된 보안 엔진 해쉬 코드 파일(334)을 저장 및 관리하는 구성에 해당될 수 있다.

이때 보안 엔진 바이너리 파일부(140)는 스토리지(340)로 사용되는 마운트 파일 시스템(342)에 저장되는 보안 엔진 바이너리 파일(344)을 저장 및 관리하는 구성에 해당될 수 있다.

도 2는 본 발명의 일 실시예에 따른 리눅스 기반 시스템의 외부 장치에 대한 보안 방법에 대한 흐름도에 해당될 수 있다.

리눅스 기반 시스템의 외부 장치에 대한 보안 방법을 수행하기 위해 응용 프로그램 인증 루틴부(122)는 먼저 시스템 초기 설정을 수행할 수 있다.(S200) 해당 단계는 본 발명의 도 4에서 보다 상세히 설명되는 구성으로, Power On 시점 단 한번 수행되는 단계와 동일한 단계에 해당될 수 있다.

이 때 응용 프로그램 인증 루틴부(122)는 제 1 해쉬 코드 값과 비교하기 위한 제 2 해쉬 코드를 생성할 수 있다.

본 발명에서 제 1 해쉬 코드 값은 Firmware(커널 및 루트 파일 시스템) 빌드 시에 생성된 해쉬 코드 값으로, 보안 엔진 응용 프로그램(312)에 대한 해쉬 코드 값에 해당될 수 있다. 본 발명의 일 실시예에 따라 제 1 해쉬 코드는 루트 파일 시스템(332)에 위치하는 해쉬 코드 파일(334)에 저장될 수 있다.

본 발명의 일 실시예에 따라 보안 엔진 응용 프로그램(312)의 바이너리 파일(344)은 마운트 파일 시스템(342)에 저장될 수 있다. 또한 보안 엔진 응용 프로그램(312)의 해쉬 코드 파일(334)은 루트 파일 시스템(332)에 저장될 수 있다. 이때 본 발명의 일 실시예에 따라 루트 파일 시스템(332)은 메모리 파일 시스템에 해당될 수 있다.

해당 단계에 대해 보다 상세하게는 시스템이 파워 온 되면 응용 프로그램 인증 루틴부(122)는 시스템 파워 온 시점에 루트 파일 시스템(332)에 놓여있는 보안 엔진 해쉬 코드 파일(334)을 읽어서 보안 엔진 해쉬 코드를 얻을 수 있다. 응용 프로그램 인증 루틴부(122)는 해쉬 코드를 얻는 것이 성공했으면 이 코드를 보안 엔진 해쉬 코드란 이름의 정적 변수에 저장할 수 있다.

그리고 의심 프로세스를 종료하는 단계가 수행될 수 있다.(S210) 해당 단계는 본 발명의 도 5에서 보다 상세히 설명되는 구성으로, 의심 프로세스 all kill단계와 동일한 단계에 해당될 수 있다. 본 발명의 일 실시예에 따라 리눅스 기반 시스템의 외부장치에 대한 보안 방법을 수행하기 위하여, 상기와 같은 시스템 초기 설정을 수행한 후tty(teletypewriter) 장치에 대해 수행되고 있는 프로세스들이 종료되는 과정이 수행될 수 있다.

이때 tty 장치는 과거 유닉스에서 중대형 호스트에 비동기 직렬통신 방식으로 연결된(주로, RS-232C 케이블 연결된) 문자 중심의 입출력 장치(터미널 또는 CRT)들을 지칭하는 용어에 해당될 수 있다. 이때 USB 기반 Serial 장치들은 리눅스 커널에 자신의 장치 클래스가 tty로 표시될 수 있다. 그 결과 리눅스 커널은 USB 기반 Serial 장치를 tty 장치로 등록할 수 있다.

본 발명에서 리눅스 기반 시스템에 연결되어 리눅스 커널에 등록된 외부 장치들을 tty 장치로 지칭할 수 있다. 다만, 이에 한정되는 것은 아니며, 본 발명에 적용되어 같은 기능을 제공하는 장치들을 지칭하기 위해 tty 장치를 사용할 수 있으며, 다른 시스템에 적용시에는 다른 용어로 사용될 수도 있다.

그 후 응용 프로그램 인증 루틴부(122)는 tty 장치를 열 수 있다.(S220) 해당 단계는 본 발명의 도 5에서 보다 상세히 설명되는 구성으로, 장치 파일 열기 단계와 동일한 단계에 해당될 수 있다.

본 발명의 일 실시예에 따라 응용 프로그램(312,314,316)이 tty 장치의 파일 열기를 요청하여 허용된 경우, 동적 할당 메모리 상에 tty 장치의 자료 구조가 할당될 수 있다.

그리고 응용 프로그램 인증 루틴부(122)는 배타적 모드를 적용할 수 있다.(S230) 해당 단계는 본 발명의 도 5에서 보다 상세히 설명되는 구성으로, 배타적 모드 적용 단계와 동일한 단계에 해당될 수 있다.

본 발명의 일 실시예에 따라 보안 엔진 응용 프로그램(312)은 배타적 모드를 수행하는 신호를 전송할 수 있다.

이때, 응용 프로그램부(110)는 보안 엔진 응용 프로그램(312)의 tty 장치의 파일 열기를 요청을 수신하여, 응용 프로그램 인증 루틴부(122)로 전달할 수 있다. 즉, 응용 프로그램부(110)가 tty 장치의 파일 열기를 요청하여 응용 프로그램 인증 루틴부(122)가 허용된다고 판단한 경우, 보안 엔진 응용 프로그램(312)은 배타적 모드 적용을 요청하여 다른 응용 프로그램(314,316)의 tty 장치의 파일 열기를 차단할 수 있다.

그 후 응용 프로그램 인증 루틴부(122)는 응용 프로그램에 대해 인증을 수행할 수 있다.(S240) 해당 단계는 본 발명의 도 5에서 보다 상세히 설명되는 구성으로, 인증 켜기 단계와 동일한 단계에 해당될 수 있다.

이때 응용 프로그램 인증 루틴부(122)는 응용 프로그램(312,314,316)의 인증 상태 정보를 결정하기 위한 인증 요청 신호에 기초하여 응용 프로그램의 보안성에 대해 판단할 수 있다.

이때 응용 프로그램(312,314,316)이 인증을 요청한 경우, 응용 프로그램 인증 루틴부(122)는 초기 설정된 시스템 정보에 기초하여 응용 프로그램의 보안성에 대해 판단하고, 응용 프로그램에 대한 인증 상태 정보를 결정할 수 있다.

이때 응용 프로그램 인증 루틴부(122)가 인증 상태 정보를 결정하는 경우, 제 1 해쉬 코드 값과 제 2 해쉬 코드 값을 비교하여 결정할 수 있다.

본 발명에서 제 2 해쉬 코드 값은 인증을 요청한 응용 프로그램에 대한 해쉬 코드 값에 해당될 수 있다. 이때 제 2 해쉬 코드 값은 응용 프로그램(312,314,316)의 바이너리 파일의 저장 위치를 파악하고, 바이너리 파일로부터 해쉬 코드를 도출한 값에 기초하여 생성될 수 있다.

본 발명의 일 실시예에 따라, 제 1 해쉬 코드 값과 제 2 해쉬 코드 값이 동일한 경우, 응용 프로그램 인증 루틴부(122)는 응용 프로그램(312)은 보안 엔진 응용 프로그램에 해당되는 것으로 판단하고, 응용 프로그램의 인증 상태 정보는 허용 상태로 결정될 수 있다. 이 경우는 본 발명에서 인증 상태를 On으로 결정한 것과 동일한 상태에 대응될 수 있다.

본 발명의 일 실시예에 따라, 제 1 해쉬 코드 값과 제 2 해쉬 코드 값이 동일하지 않은 경우, 응용 프로그램 인증 루틴부(122)는 응용 프로그램(314,316)의 인증 상태 정보는 불허 상태로 결정하고 응용 프로그램(314,316)은 종료될 수 있다. 이 경우는 본 발명에서 인증 상태를 Off으로 결정한 것과 동일한 상태에 대응될 수 있다.

보다 상세하게 해당 과정을 설명하면, 시스템 운용 중에 응용 프로그램 인증 루틴부(122)가 응용 프로그램으로부터 인증 켜기 요청을 받으면 리눅스 커널이 가지고 있는 프로세스 제어 블록(PCB: Process Control Block)을 사용하여 요청한 응용 프로그램의 작업 디렉토리 경로 이름과 파일 이름을 얻을 수 있다. 응용 프로그램 인증 루틴부(122)는 인증을 요청한 응용 프로그램의 작업 디렉토리 경로 이름과 파일 이름을 얻어 인증을 요청한 응용 프로그램의 바이너리 파일이 위치하는 절대 경로를 알아낼 수 있다. 그 후 응용 프로그램 인증 루틴부(122)는 상기의 방법으로 생성된 절대 경로상의 파일에 대해 해쉬 코드를 얻어서 초기 설정 시에 생성된 보안 엔진 해쉬 코드란 이름의 정적 변수에 저장된 값과 비교를 수행할 수 있다.

응용 프로그램 인증 루틴부(122)는 두 해쉬 코드가 완벽히 일치하면 요청한 응용 프로그램에 대해 보안 엔진 응용 프로그램(312)으로 판정하고 그렇지 않으면 가짜로 판정할 수 있다. 그리고 응용 프로그램 인증 루틴부(122)는 내부적으로 인증 상태를 On으로 설정을 바꿀 수 있다.

보안 엔진 응용 프로그램(312)은 본 발명의 일 실시예에 따라 내부에 인증 켜기/끄기 요청 코드가 추가 구현될 수 있다. 또한, 보안 엔진 응용 프로그램(312)이 인증을 요청한 경우, 항상 성공 결과를 받는다. 아울러 시스템 내부에서 인증 상태가 On/Off로 변경될 수 있다.

배포 응용 프로그램(314)은 인증 켜기/ 끄기 요청 코드가 포함되지 않는다.

본 발명의 일 실시예에 따를 때 보안 엔진 위변조 프로그램(316)이 인증 켜기/끄기 요청을 하면 응용 프로그램 인증 루틴(322)은 항상 실패 결과를 리턴할 수 있다.

본 발명의 일 실시예에 따를 때 공격자가 보안 엔진 위변조 프로그램(316)과 보안 엔진 해쉬 코드 파일(334)을 동시에 위변조하더라도 응용 프로그램 인증 루틴(322)은 실패 결과를 리턴할 수 있다.

그 후 외부 장치에 대한 보안 시스템(100)은 외부 장치를 사용할 수 있다.(S250) 해당 단계는 본 발명의 도 6에서 보다 상세히 설명되는 구성으로, 외부 장치를 사용하는 동안 Loop로 순환 반복 되는 단계와 동일한 단계에 해당될 수 있다.

응용 프로그램의 외부 장치에 대한 사용 요청을 수신한 경우, 인증 검사 매크로부(124)는 인증 상태 정보에 기초하여 응용 프로그램의 외부 장치 사용 여부를 결정할 수 있다. 본 발명의 일 실시예에 따라 외부 장치는 USB 시리얼 장치(352)에 해당될 수 있다.

보다 상세하게는 인증 검사 매크로부(124)는 USB 호스트 제어기(150)로부터 신호를 수신한 경우, 인증 상태 정보가 허용 상태로 결정된 것인지 판단할 수 있다. 이때, 인증 상태 정보가 허용 상태로 결정된 상태인 경우, 응용 프로그램 인증 루틴부(122)는 상기 신호로부터 도출된 문자열을 버퍼에 저장할 수 있다.

응용 프로그램부(110)가 외부 장치에 대한 문자열 읽기 시스템콜을 호출한 경우, 응용 프로그램 인증 루틴부(122)는 버퍼에 문자열이 저장되어 있는지 판단하고, 문자열이 저장되어 있는 경우 응용 프로그램부(110)로 문자열을 전송할 수 있다.

응용 프로그램부(110)가 외부 장치에 대한 문자열 쓰기 시스템콜을 호출한 경우, 인증 검사 매크로부(124)가 인증 상태 정보를 판단할 수 있다. 이때, 인증 된 상태인 경우, 인증 검사 매크로부(124)는 USB 호스트 제어기(150)로 문자열 쓰기 명령을 전송할 수 있다.

즉, 인증 검사 매크로부(124)는 응용 프로그램으로부터 쓰기 요청을 받거나 USB 벌크 인터럽트 신호를 받으면 인증 상태를 검사하여 On으로 설정된 경우에만 쓰기와 읽기를 수행할 수 있다. 또한, 인증 검사 매크로부(124)는 응용 프로그램으로부터 USB 시리얼 장치 사용 요청을 받았을 때 Off로 설정되어 있으면 해당 요청을 폐기할 수 있다.

그 후 응용 프로그램 인증 루틴부(122)는 인증 끄기 및 장치 파일 닫기 절차를 수행할 수 있다.(S260,S270) 해당 단계는 본 발명의 도 7에서 보다 상세히 설명되는 구성으로, 인증 끄기 단계 및 장치 파일 단계와 동일한 단계에 해당될 수 있다.

응용 프로그램이 인증 종료를 요청한 경우, 응용 프로그램 인증 루틴부(122)는 인증 종료 요청에 기초하여 인증 상태 정보를 변경할 수 있다.

도 3은 본 발명의 일 실시예에 따라 리눅스(Linux)에 기반한 외부 장치 보안 시스템의 특징을 설명하기 위한 도면이다.

본 발명에 따르면 USB 시리얼 장치에 강건하게 보안이 적용되기 위하여 루트 파일 시스템으로써 메모리 파일 시스템을 사용, 리눅스 커널 내 tty core에 응용 프로그램 인증을 수행하는 코드, 리눅스 커널 내 tty 디바이스 드라이버에 인증 여부를 검사하는 코드 등이 구현될 수 있다.

본 발명의 핵심적인 기능은 리눅스 커널에 인증(Authentication) 기능을 추가하여 USB 시리얼 장치를 사용하고자 시도하는 모든 응용 프로그램에 대해 인증을 수행하는 것이다.

본 발명에 따르면 시스템이 허용 하기로 결정한 특정 응용 프로그램 하나에 대해서만 리눅스 커널에서 인증이 성공되며, 인증이 성공된 응용 프로그램에 대해서는 권한(Authentication) 제어에 의해 USB 시리얼 장치를 독점적으로 사용할 수 있는 권한이 허용될 수 있다. 인증 된 응용 프로그램 외의 나머지 응용 프로그램들은 모두 인증에 실패될 수 있다. 인증 실패한 응용 프로그램에 대해서는 어느 한 순간도 USB 시리얼 장치에 대한 사용 권한이 허용되는 순간이 없도록 시스템이 수행될 수 있다. 또한 특정 응용 프로그램을 위변조한 응용 프로그램들도 가짜로 판정되어 인증이 실패될 수 있다.

본 발명이 제안하는 응용 프로그램 인증 능력은 다음의 세가지 핵심 기술에 의존될 수 있다.

첫째, 본 발명에 따르면 암호키 대신 해쉬 코드를 사용하며, 해쉬 코드를 공개하는 방법을 사용할 수 있다.

암호키를 사용하는 경우, 운용자가 암호를 기억해야 하는 점, 시스템과 운용자간에 상호 동작이 수반되어야 하는 점 등의 불편함이 존재하며, 이론적으로 암호를 시스템에 완벽히 숨겨서 저장하는 방법이 없는 것을 고려하여 암호키를 사용하는 방안은 USB 시리얼 장치에 보안 기능을 제공하는 시스템에 적합하지 않다.

반면에 해쉬 코드를 사용하는 방법은 운용자가 암호를 기억할 필요가 없고, 시스템과 운용자간에 상호 동작이 수반되지 않아 시스템이 보안 기능을 자동으로 수행할 수 있다.

또한 해쉬 코드는 숨기지 않고 공개해도 아무런 문제가 없다는 장점이 있다. 해쉬 코드를 공개 할 수 있는 이유는 공격자의 목표가 되는 특정 바이너리 파일을 공격자가 위변조하고자 할 때 동일 해쉬 코드를 생성하도록 하면서 위변조하는 것은 불가능하기 때문이다. 이와 같은 이유로 해쉬 코드를 공개할 수 있다. 즉 시스템이 허용하기로 결정한 바이너리 파일에 대한 해쉬 코드를 텍스트 파일 형태로 시스템 파일 시스템 내에 저장할 수 있다. 아울러 이 파일을 숨기지 않고 공개할 수 있다.

둘째, 본 발명에 따르면 초기 파일 시스템을 루트 파일 시스템으로 계속 사용할 수 있다.

응용 프로그램 바이너리 파일과 그의 해쉬 코드 텍스트 파일이 모두 공개된 경우 공격자가 이 둘을 동시에 위변조할 경우 공격자의 공격이 쉽게 성공하는 위험이 있다. 이와 같은 위험을 회피하기 위하여 본 발명은 두 파일을 저장하는 장소를 분리하고, 두 파일을 각기 다른 장소에 저장할 수 있다.

본 발명의 일 실시예에 따라 파일 크기가 작은 해쉬 코드 텍스트 파일을 메모리 파일 시스템에 저장하고 비교적 크기가 큰 응용 프로그램 바이너리 파일은 스토리지 파일 시스템에 저장할 수 있다.

이때 리눅스 시스템의 파일 시스템은 크게 메모리 파일 시스템과 스토리지 파일 시스템으로 구분될 수 있다.

스토리지 파일 시스템은 Flash, eMMC, SD, micro SD, SSD, 하드 디스크, 등과 같은 저장 장치를 기반으로 하는 파일 시스템 이다. 스토리지 파일 시스템은 운용 중에 디렉토리 혹은 파일에 변경이 가해지면 파워 오프 후에도 그 변경 사항이 그대로 남아 있는 특징이 있다. 리눅스 시스템이 사용하는 스토리지 파일 시스템으로써 ext2, ext3, ext4가 대표적이다.

메모리 파일 시스템은 메모리의 휘발성 특성으로 인해 시스템 파워 오프 시 메모리 파일 시스템에 가해진 모든 수정 사항을 깨끗이 잃어 버리는 특성이 있다. 따라서 본 발명에 따르면, 운용 중에 응용 프로그램 해쉬 코드 텍스트 파일에 대해 위변조가 있었더라도 파워 오프 시점에 모두 깨끗이 지워지는 효과가 있다. 메모리 파일 시스템 종류로는 RAM disk, ramfs, ramfs의 개선 버젼인 tmpfs가 있다. 리눅스 시스템은 부팅 중에 초기 파일 시스템을 사용하지 않는 시스템도 있지만 많은 경우 초기 파일 시스템을 사용한다.

초기 파일 시스템을 좀 더 자세히 설명하면 예를 들어 부팅 중 RAM disk 메모리 파일 시스템을 사용했다면 initrd이라 불리는 초기 파일 시스템이 반드시 존재하고, ramfs 혹은 tmpfs 메모리 파일 시스템을 사용했다면 initramfs이라 불리는 초기 파일 시스템이 반드시 존재한다. 즉, initrd 혹은 initramfs에 의해 초기의 파일 시스템이 구성되고 이를 통해 리눅스 커널 부팅이 진행된다. 초기 파일 시스템을 사용한 경우 리눅스 커널 부팅이 끝나기 전에 루트("/")에 어느 스토리지 파일 시스템을 마운트 하거나 아니면 사용하고 있던 초기 파일 시스템을 루트("/")에 마운트 한다.

루트에 마운트 된 시스템을 루트 파일 시스템이라 부른다. 초기 파일 시스템, 메모리 파일 시스템, 스토리지 파일 시스템, 루트에 파일 시스템 마운트, 루트 파일 시스템 등의 동작 원리를 활용하여 해쉬 코드 텍스트 파일을 악의적 공격으로부터 안전을 보장할 수 있는 방법이 있다. 그것은 initrd 또는 initramfs 초기 파일 시스템에 해쉬 코드 텍스트 파일을 두는 것이다. 그리고 초기 파일 시스템을 계속 루트 파일 시스템으로 사용하는 것이다. 필요한 스토리지 파일 시스템들은 루트 파일 시스템에 마운트하도록 한다. 메모리 파일 시스템을 사용하게 되면 악의적 위변조가 발생한 시점부터 파워 오프 시점까지 위협에 놓여지는데, 이것은 해쉬 코드를 파워 온 시점에 단 한번 얻은 다음에는 어떤 경우에도 더 이상 해쉬 코드를 얻는 수행이 전혀 일어나지 않도록 함으로써 해결된다.

initrd는 루프백 블록 디바이스가 압축된 압축 파일 형식이며 initramfs는 Kernel 바이너리 파일에 포함되는 아카이브 파일이다. 커널 바이너리 파일은 나중에 압축된다. 해쉬 코드 텍스트 파일은 이와 같은 initrd 혹은 initramfs에 저장된다. initrd 및 initramfs에 포함되는 파일을 해킹하는 것은 구조적으로 매우 어렵다는 특징이 있다. 압축된 루프백 블록 디바이스 파일 혹은 압축된 리눅스 커널 바이너리 파일 속 어디에 있는 아카이브 파일 속에 어떤 절대 경로상에 있는 어떤 파일의 내용을 공격자가 원하는 내용으로 위변조하는 것은 매우 어렵다. 초기 루트 파일 시스템의 원형이 되는 initrd와 initramfs는 Firmware(커널 + 루트 파일 시스템) 빌드 시점에 생성될 수 있다.

셋째, 본 발명에 따르면 시스템 콜의 인자를 이용한 공격이 불가능하도록 시스템을 구현할 수 있다.

시스템 공격자가 공격 프로그램을 개발하여 공격 시 시스템 콜의 인자를 공격의 경로로 악용하는 사례가 많다. 공격 프로그램이 시스템에 위협을 주는 값을 사용하거나 혹은 가짜 값을 사용할 경우 시스템의 안전을 위협한다. 이와 같은 점을 고려하여 시스템 콜 인자를 설계할 때 주의한다.

인증을 위해서 "해쉬 텍스트 파일 경로, 이름, 파일 크기, 해쉬 코드, 응용 프로그램 바이너리 파일 위치, 경로" 등 여러 정보가 필요하며 인증 모듈은 편의를 위해 이들 정보를 직접 받도록 설계할 수 있다. 그러나 이와 같은 설계는 공격자가 인자를 통해 진짜를 가장할 수단을 제공하게 된다. 이를 위해 리눅스 커널 상에 존재하는 본 발명의 인증 루틴은 필요한 모든 정보를 스스로 얻도록 하여 공격자가 인자를 통해 진짜를 가장할 수 없도록 할 수 있다.

이와 같은 설계를 갖춤으로써 본 발명의 소스 코드가 유출되거나, 시스템 콜 관찰 도구를 사용하여 동작 코드를 이해하거나, 혹은 리버스 엔지니어링을 통해 동작 코드를 이해하더라도 시스템 콜 인자를 이용한 공격은 불가능하도록 할 수 있다.

도 3(a)를 참고하여 상기와 같은 본 발명의 특징이 리눅스 기반 시스템에 구현된 방법을 확인할 수 있다. 보다 상세하게 도 3(a)은 일반 리눅스(Linux) 시스템에서 본 발명에 따른 USB 시리얼 장치에 안전한 보안을 제공하는 방법이 적용된 시스템 형상에 대한 도면에 해당될 수 있다.

본 발명의 일 실시예에 따라 외부 장치보안 시스템(100)은 리눅스 시스템에 기반하여 구현될 수 있다.

일반 리눅스(Linux) 시스템은 메인 메모리(330), 스토리지(340), USB 호스트 제어기(350) 등의 하드웨어, 리눅스 커널(320) 및 여러 응용 프로그램(312, 314, 316)등으로 구성될 수 있다.

일반 리눅스 시스템에는 오직 하나의 루트 파일 시스템만 존재할 수 있고 나머지 모든 파일 시스템은 루트 파일 시스템에 마운트 되어야 한다. 이때 루트 파일 시스템(332)은 메모리 파일 시스템 또는 스토리지 파일 시스템을 사용할 수 있다.

본 발명에서 메인 메모리(330)는 루트 파일 시스템(332)에 놓여질 수 있다. 본 발명의 일 실시예에 따라 가장 적절하게는 루트 파일 시스템(332)은 메모리 파일 시스템을 사용할 수 있다.

또한 본 발명에서 보안 엔진 해쉬 코드 파일(334)은 메모리 파일 시스템을 사용하는 루트 파일 시스템(332)에 저장될 수 있다. 이때 본 발명의 일 실시예에 의할 때 보안 엔진 해쉬 코드 파일(334)은 보안 엔진 바이너리 파일(344)에 대해 해쉬 코드를 얻어 얻어진 결과를 텍스트 파일로 저장한 것에 해당될 수 있다.

보다 상세하게는 보안 엔진 바이너리 파일(344)에 대해 해쉬 코드가 생성된 것을 이용하여 보안 엔진 해쉬 코드 파일(334)이 생성될 수 있다. 생성된 해쉬 코드는 보안 엔진 해쉬 코드 파일(334)이란 이름의 텍스트 파일로 생성되어 루트 파일 시스템(332)에 추가될 수 있다. 보안 엔진 해쉬 코드 파일(334)에 해당되는 텍스트 파일은 USB 시리얼 장치에 보안 기능을 제공하는 시스템의 동작을 수행하기 위하여 새로이 추가된 것에 해당된다. 보안 엔진 해쉬 코드 파일(334)는 초기 파일 시스템이 빌드 되는 시점에 만들어질 수 있다.

스토리지(340)는 마운트 파일 시스템(342)에 놓여질 수 있다.

또한 본 발명에서 보안 엔진 바이너리 파일(344)은 마운트 파일 시스템(342)에 저장될 수 있다. 본 발명에 의할 때 보안 엔진 바이너리 파일(344)이 저장된 스토리지 파일 시스템(340)은 반드시 루트 파일 시스템(332)에 마운트 되어야 한다.

일반적으로 USB 호스트 제어기(350)에는 여러 종류의 USB 기반 기기들이 플러그-인될 수 있다. 본 발명의 일 실시예에 따라 USB 호스트 제어기(350)는 USB 기반 기기들의 여러 종류들 중 USB 기반 시리얼 장치(352)와 플러그-인(plug -in)될 수 있다.

리눅스 커널(320)에는 tty core(321)와 tty 디바이스 드라이버(323)가 존재할 수 있다. 즉, 리눅스 커널(320)에서 tty 장치에 대한 처리는 상위의 tty core(321)와 하위의 tty 디바이스 드라이버(323)로 나눠질 수 있다.

모든 USB 시리얼 장치는 리눅스 커널(320)에 tty 장치로 등록될 수 있다. 보다 상세하게는 USB Serial 장치의 제조사 및 제품 모델별로 각기 다르게 수행되어야 하는 코드는 tty 디바이스 드라이버(323)에 놓여질 수 있다. 또한 제조사 및 제품 모델에 무관하게 공통적으로 수행되는 기능은 tty core(321)에 놓여질 수 있다.

본 발명의 일 실시예에 따라 리눅스 기반 시스템(100)의 USB 시리얼 장치에 대한 보안 방법을 수행하기 위하여, 일반 리눅스 시스템의 tty core(321)에 응용 프로그램 인증 루틴(332)이 새로이 추가되어 구현되고, tty 디바이스 드라이버(323)에 인증 검사 매크로(324)가 추가되어 구현될 수 있다.

본 발명의 일 실시예에 따라 응용 프로그램 인증 루틴(322)은 보안 시스템의 핵심적인 기능을 수행할 수 있다. 보다 상세하게는 tty core(321)는 보안 엔진 응용 프로그램(312)으로부터 인증 켜기 요청을 받았을 때만 인증 성공을 리턴할 수 있다. 또한, tty core(321)는 보안 엔진 응용 프로그램(312)을 제외한 다른 응용 프로그램으로부터 인증 켜기 요청을 받았을 경우는 인증 실패를 리턴할 수 있다.

또한 응용 프로그램 인증 루틴(322)에 따르면, 인증 시 암호를 사용하지 않고, 사용자와 상호적으로 수행하는 동작 없이 응용 프로그램에 대한 인증이 가능하다. 또한 공격의 경로가 될 수 있는 시스템 콜 인자도 전혀 사용하지 않을 수 있다. 오직 리눅스 커널이 갖고 있는 내부 정보를 사용하여 응용 프로그램에 대해서 인증을 수행할 수 있다.

인증 검사 매크로(324)는 특정 USB 시리얼 장치(352)에 문자열 읽기 요청, 쓰기 요청, USB 벌크 인터럽트 신호 수신 시 인증 상태를 얻어서 리턴하는 코드에 해당될 수 있다. tty 디바이스 드라이버(323)는 얻어진 값이 On이면 수행을 계속 진행할 수 있고, Off이면 요청을 폐기할 수 있다.

USB 시리얼 장치 보안 시스템(100)이 수행하는USB 시리얼 장치 보안의 관점에서 보면 응용 프로그램은 보안 엔진 응용 프로그램(312), 배포 응용 프로그램(314), 보안 엔진 위변조 프로그램(316)으로 분류될 수 있다.

이때 보안 엔진 응용 프로그램(312)은 상기의 정의와 같이 외부장치에 대한 독점 사용이 기 설정된 응용 프로그램에 해당될 수 있다.

본 발명의 일 실시예에 따를 때, 보안 엔진 응용 프로그램(312)은 인증 켜기를 요청하는 시스템 콜과 인증 끄기를 요청하는 시스템 콜 호출 기능이 추가되어 구현될 수 있다. 즉, 도 3(b)와 같이 보안 엔진 응용 프로그램(312)는 인증 켜기, 끄기 요청부(313)을 포함할 수 있다.

본 발명에서 배포 응용 프로그램(314)는 tty 사용 가능 사용자 명령어 및 응용 프로그램에 해당될 수 있다. 이때 배포 응용 프로그램(314)은 리눅스 시스템이 USB 시리얼 장치에 대한 사용 편의성을 제공하고자 사용자들에게 제공하는 프로그램에 해당될 수 있다. 즉, 배포 응용 프로그램(314)은 시스템 사용자가 자주 사용하는 잘 알려진 리눅스 명령어 및 응용 프로그램들에 해당될 수 있다. 또한 배포 응용 프로그램(314)은 이미 개발되어 배포되는 프로그램에 해당될 수 있다.

시스템 사용자들은 배포 응용 프로그램(314)을 바이너리 파일 형태로 배포된 그대로 사용할 수 있다. 따라서 배포 응용 프로그램(314)은 해킹이 되지 않은 이상 인증 켜기/ 끄기 요청 코드가 포함되지 않는다.

보안 엔진 위변조 프로그램(316)은 보안 엔진 응용 프로그램(312)을 위변조한 프로그램으로써 시스템 콜 모니터링 도구 혹은 리버스 엔지니어링을 통해 보안 엔진의 수행 코드를 이해하여 개발한 프로그램에 해당될 수 있다. 즉, 보안 엔진 위변조 프로그램(316)은 보안 엔진을 위변조하여 생성된 보안 엔진 응용 프로그램(312)을 가장하는 응용 프로그램에 해당될 수 있다. 보안 엔진 위변조 프로그램(316)은 내부적으로 인증 켜기/끄기 요청 코드를 내부에 구현하였을 수도 있고 없을 수도 있다.

도 4는 본 발명의 일 실시예로, USB 시리얼 장치 보안 시스템의 초기 설정 동작에 대한 흐름도를 나타낸 도면이다. 보다 상세하게는 도 4는 USB 시리얼 장치 보안 시스템에서 파워 온 시점에 한번만 수행되는, USB 시리얼 장치에 대해 안전한 보안을 제공 하기 위해 필요한 준비 과정을 순서도로 나타낸 도면에 해당될 수 있다.

먼저, tty core(321)내 응용 프로그램 인증 루틴(322)은 루트 파일 시스템(101)에 위치하는 보안 엔진 해쉬 코드 파일(334) 열기를 수행할 수 있다.(S201) tty core(321)는 파일 열기가 성공하면 파일 내 헥사 문자열을 읽어서 정적 변수에 저장한 후 파일을 닫을 수 있다.(S203) 만약 파일 열기가 실패하면 tty core(321)는 커널 경고 메시지를 남길 수 있다.(S203)

이 과정은 시스템 파워 온 시점에 단 한번만 수행하며 다시 수행하는 경우는 발생되지 않는다. 파워 온 시점에 상기 과정을 단 한번만 수행하는 이유는 정상 운용이 시작된 후 공격자가 보안 엔진 해쉬 코드 파일(334)을 공격하더라도 전혀 영향을 받지 않게 하기 위함이다. 아울러 공격자의 공격은 파워 오프 시점에 메모리의 휘발성 특성으로 모두 잃게 된다.

도 5는 본 발명의 일 실시예에 따라, 응용 프로그램이 USB 시리얼 장치를 본격 사용 하기에 앞서 수행 객체들이 수행되어야 할 올바른 절차를 순서도로 나타낸 것이다.

보안 엔진 응용 프로그램(312)은 특정 USB 시리얼 장치(352)를 사용하기에 앞서 의심 프로세스 all kill 과정(S210)을 수행할 수 있다.(S211) 이 과정에서 보안 엔진 응용 프로그램(312)은 특정 tty 장치를 열고 있는 모든 프로세스를 all kill하는 시스템을 호출할 수 있다.

C 프로그래밍 언어 관점에서 보면 시스템 콜 system("lsof -t /dev/ttyUSB0 | xargs kill -KILL")을 호출하는 것에 대응될 수 있다.

보안 엔진 응용 프로그램 관점에서 보면 자신에게만 사용권이 허용되어 있는데 다른 프로세스들이 사용되고 있는 경우, 이 프로세스들은 공격 프로그램으로 판단되어 즉시 모두 종료될 수 있다. 이 과정은 보안 엔진 응용 프로그램에 새로이 추가된 과정이다.

응용 프로그램(312,314,316)은 장치 파일 열기 과정을 수행한다.(S220) 하기의 내용은 장치 파일 열기 과정에 대한 상세한 설명에 해당될 수 있다.

먼저 응용 프로그램(312,314,316)이 열기 시스템 콜을 호출하면 tty core(321)는 파일 열기가 허용되는지 여부를 검사할 수 있다.(S221) 보다 상세하게는 tty core(321)는 응용 프로그램(312,314,316)의 종류 및 응용 프로그램(312,314,316)의 실행 여부에 따라 해당 응용 프로그램(312,314,316)이 파일을 열 수 있는지를 판단할 수 있다. 이때 보안 엔진 응용 프로그램(312)은 열기가 항상 허용될 수 있다. 그러나 배포 응용 프로그램(314)과 보안 엔진 위변조 프로그램(316)은 보안 엔진 응용 프로그램(312)이 현재 수행 중 인지 여부에 따라 허용될 수도 있고 불허될 수도 있다. 만약 보안 엔진 응용 프로그램(312)이 현재 수행이라면 불허되고 실패 결과가 리턴될 수 있다. 이때 실패 결과를 리턴 받는 배포 응용 프로그램(314) 또는 보안 엔진 위변조 프로그램(316)은 종료될 수 있다. 이때 파일 열기가 해당 응용프로그램에 대해 허용된 경우 tty core(321)는 동적 할당 메모리상에 tty 자료구조를 할당할 수 있다.(S222) 또한 tty core(321)는 이 자료구조상의 인증 상태를 디폴트 값인 Off로 설정할 수 있다. 그런 다음 tty core(321)는 성공 결과를 응용 프로그램(312,314,316)에 리턴할 수 있다.

장치 파일 열기 단계(S220)에서 성공 결과를 받으면 응용 프로그램(312,314,316)은 배타적 모드 적용 단계를 수행할 수 있다.(S230) 이 단계는 보안 엔진 응용 프로그램(312)에 새로이 추가된 단계에 해당될 수 있다. 보안 엔진 응용 프로그램(312)이 시스템 콜을 통해 배타적 모드 적용 요청을 하면 tty core(321)는 이후 이 장치를 열려는 시도가 있으면 모두 불허할 수 있다.(S231) tty core(321)는 성공 결과를 리턴할 수 있다.

응용 프로그램(312,314,316)은 배타적 모드 적용 단계(S230)가 끝나면 인증 켜기 단계(S240)를 수행할 수 있다. 이 단계는 보안 엔진 응용 프로그램(312)에 새로 추가된 단계이다. 배포 응용 프로그램 (314)에는 이 과정이 없다. 보안 엔진 위변조 프로그램(316)에서는 소스 코드 유출 여부, 시스템 콜 관찰 수준, 리버스 엔지니어링 수준에 따라 이 단계가 있을 수도 있고 없을 수도 있다.

응용 프로그램(312,314,316)이 인증 켜기 시스템 콜을 호출하면 tty core(321)내 응용 프로그램 인증 루틴(322)은 응용 프로그램 인증을 수행할 수 있다.(S241) 응용 프로그램 인증 루틴(322)은 리눅스 커널(320)이 가지고 있는 프로세스 제어 블록(PCB: Process Control Block)을 사용하여 요청한 응용 프로그램의 작업 디렉토리 경로 이름과 파일 이름을 얻어 이 응용 프로그램의 바이너리 파일이 위치하는 절대 경로를 알아낼 수 있다. 그런 이 절대 경로상의 파일에 대해 해쉬 코드를 얻어서 보안 엔진 해쉬 코드(334)란 이름의 정적 변수에 저장된 값과 비교할 수 있다.

이때, 두 해쉬 코드가 완벽히 일치하면 요청한 응용 프로그램은 보안 엔진 응용 프로그램(312)으로 판단될 수 있다. 만약, 두 해쉬 코드가 일치하지 않으면 해당 응용 프로그램은 가짜로 판단될 수 있다. 보안 엔진 응용 프로그램(312)으로 인증되면 인증 상태가 디폴트 값 Off에서 On으로 변경될 수 있다.(S242) 그 후 tty core(321)는 성공 결과를 응용 프로그램에 리턴할 수 있다. 해당 응용 프로그램이 인증을 받지 못한 경우, tty core(321)는 실패 결과를 응용 프로그램에 리턴할 수 있다. 실패 결과를 리턴 받은 응용 프로그램은 수행이 종료될 수 있다.

도 6은 본 발명의 일 실시예에 따라, 응용 프로그램이 외부 장치를 본격 사용시 수행 객체들이 수행해야 할 올바른 절차를 순서도로 나타낸 도면에 해당된다.

응용 프로그램이 본격 수행되면 USB 벌크 인터럽트 신호 핸들링 과정(S251), 문자열 읽기 과정(S253), 문자열 쓰기 과정(S256)이 각각 임의의 시간에 발생되는 것이 반복될 수 있다.

USB 벌크 인터럽트 신호 핸들링 과정(S251)은 tty 디바이스 드라이버(323)가 USB 호스트 제어기(350)로부터 임의 시점에 USB 벌크 인터럽트 신호를 수신하면 시작될 수 있다. tty 디바이스 드라이버(323)가 인터럽트 신호를 수신하면 tty 디바이스 드라이버(323)내 인증 검사 코드가 인증 상태를 검사하여 값이 On으로 설정되어 있으면(S252) 읽혀진 문자열을 tty core(321)에 버퍼링할 수 있다. 만약 값이 Off로 설정되어 있으면 문자열을 무시하고 되돌아 갈 수 있다.

문자열 읽기 과정(S253)은 임의 시점에 응용 프로그램(312,314,316)이 문자열 읽기 시스템 콜을 호출함으로써 시작될 수 있다. 읽기 시스템 콜이 호출되면 tty core(321)는 버퍼에 문자열이 존재하는지 여부를 검사할 수 있다.(S254) 검사 결과 버퍼에 내용이 있으면 버퍼에서 문자열 꺼내기를 수행할 수 있다.(S255) 꺼내진 문자열은 응용 프로그램(312,314,316)으로 전송될 수 있다. 버퍼에 내용이 존재하는 경우는 오직 보안 엔진 응용 프로그램이 읽기를 호출한 경우뿐 이다. 따라서 성공적으로 문자열이 리턴되는 곳은 보안 엔진 응용 프로그램(312)이 유일하다. 버퍼가 비어 있는 경우 실패 값이 리턴될 수 있다. 배포 응용 프로그램(314)이 실수로 읽기를 시도 했거나 보안 엔진 위변조 프로그램(316)이 악의적으로 공격한 경우에 실패값이 리턴될 수 있다.

문자열 쓰기 과정(S256)은 임의 시점에 응용 프로그램(312,314,316)이 문자열 쓰기 시스템 콜을 호출함으로써 시작될 수 있다. 쓰기 시스템 콜이 호출되면 tty core(321)에서 tty 디바이스 드라이버(323) 내 쓰기를 처리하는 함수가 콜백될 수 있다. 쓰기를 처리하는 함수는 인증 상태 값을 조사하여(S257) 값이 On으로 설정되어 있으면 USB 호스트 제어기(106)로 문자열 쓰기 명령을 전송할 수 있다. 인증이 성공하는 경우는 오직 보안 엔진 응용 프로그램(312)이 쓰기 시스템 콜을 호출한 경우뿐이다. 인증 상태가 Off이면 이면 tty 장치 드라이버(323)은 tty core(321)로 실패값을 리턴하고 이어서 응용 프로그램(312,314,316)으로 전달될 수 있다. 배포 응용 프로그램(314)이 실수로 쓰기를 시도 했거나 보안 엔진 위변조 프로그램(316)이 악의적으로 공격한 경우에 실패값이 리턴될 수 있다.

도 7은 본 발명의 일 실시예에 따라, 응용 프로그램이 외부 장치를 본격 사용이 끝난 뒤 수행 객체들이 수행해야 할 올바른 절차를 순서도로 나타내었다.

응용 프로그램(312,314,316)이 반복문에서 벗어나면 먼저 인증 끄기 과정(S260)을 수행할 수 있다. 인증 끄기 과정(S260)은 USB 시리얼 장치(352)의 안전한 보안을 위해 보안 엔진 응용 프로그램(312)에 새로이 추가된 단계에 해당될 수 있다.

이 단계는 보안 엔진 응용 프로그램(312)이 인증 끄기를 요청하는 시스템 콜을 호출하면서 시작될 수 있다. 시스템 콜을 받은 tty core(321)내 응용 프로그램 인증 루틴(322)은 인증 상태를 Off로 변경할 수 있다.(S261) 그 후 tty core(321)는 응용 프로그램(312)에 성공값을 리턴할 수 있다.

응용 프로그램(312)이 장치 파일 닫기 시스템 콜을 호출하면 파일 닫기 과정(S270)이 수행될 수 있다. 이 시스템 콜이 호출되면 tty core(321)은 이전에 동적 할당 메모리에 할당했던 tty 자료구조를 반납할 수 있다.(S271) 그 후 tty core(321)는 응용 프로그램(312)으로 성공 결과를 리턴할 수 있다.

본 개시의 예시적인 방법들은 설명의 명확성을 위해서 동작의 시리즈로 표현되어 있지만, 이는 단계가 수행되는 순서를 제한하기 위한 것은 아니며, 필요한 경우에는 각각의 단계가 동시에 또는 상이한 순서로 수행될 수도 있다. 본 개시에 따른 방법을 구현하기 위해서, 예시하는 단계에 추가적으로 다른 단계를 포함하거나, 일부의 단계를 제외하고 나머지 단계를 포함하거나, 또는 일부의 단계를 제외하고 추가적인 다른 단계를 포함할 수도 있다.

본 개시의 다양한 실시 예는 모든 가능한 조합을 나열한 것이 아니고 본 개시의 대표적인 양상을 설명하기 위한 것이며, 다양한 실시 예에서 설명하는 사항들은 독립적으로 적용되거나 또는 둘 이상의 조합으로 적용될 수도 있다.

또한, 본 개시의 다양한 실시 예는 하드웨어, 펌웨어(firmware), 소프트웨어, 또는 그들의 결합 등에 의해 구현될 수 있다. 하드웨어에 의한 구현의 경우, 하나 또는 그 이상의 ASICs(Application Specific Integrated Circuits), DSPs(Digital Signal Processors), DSPDs(Digital Signal Processing Devices), PLDs(Programmable Logic Devices), FPGAs(Field Programmable Gate Arrays), 범용 프로세서(general processor), 컨트롤러, 마이크로 컨트롤러, 마이크로 프로세서 등에 의해 구현될 수 있다.

본 개시의 범위는 다양한 실시 예의 방법에 따른 동작이 장치 또는 컴퓨터 상에서 실행되도록 하는 소프트웨어 또는 머신-실행 가능한 명령들(예를 들어, 운영체제, 애플리케이션, 펌웨어(firmware), 프로그램 등), 및 이러한 소프트웨어 또는 명령 등이 저장되어 장치 또는 컴퓨터 상에서 실행 가능한 비-일시적 컴퓨터-판독가능 매체(non-transitory computer-readable medium)를 포함한다.

100: 보안 시스템
110: 응용 프로그램부
120: 리눅스 커널부
122: 응용 프로그램 인증 루틴부
124: 인증 검사 매크로부
130: 보안 엔진 해쉬 코드 파일부
140: 보안 엔진 바이너리 파일부
150: USB 호스트 제어기
312: 보안 엔진 응용 프로그램
314: 배포 응용 프로그램
316: 보안 엔진 위변조 프로그램
320: 리눅스 커널
321: tty core
322: 응용 프로그램 인증 루틴
323: tty 디바이스 드라이버
324: 인증 검사 매크로
330: 메인 메모리
332: 루트 파일 시스템
334: 보안 엔진 해쉬 코드 파일
340: 스토리지
342: 마운트 파일 시스템
344: 보안 엔진 바이너리 파일
350: USB 호스트 제어기
352: USB 기반 시리얼 장치

Claims

리눅스 기반 시스템의 외부 장치에 대한 보안 방법에 있어서
상기 시스템에 대해 초기 설정을 수행하는 단계;
상기 초기 설정된 시스템 정보에 기초하여 응용 프로그램의 보안성에 대해 판단하고, 상기 응용 프로그램에 대한 인증 상태 정보를 결정하는 단계; 및
상기 응용 프로그램의 상기 외부 장치에 대한 사용 요청을 수신한 경우, 상기 인증 상태 정보에 기초하여 상기 응용 프로그램의 외부 장치 사용 여부를 결정하는 단계; 를 포함하되,
상기 인증 상태 정보를 결정하는 경우,
제 1 해쉬 코드 값과 제 2 해쉬 코드 값을 비교하여 결정하되,
상기 제 1 해쉬 코드 값은 상기 초기 설정 시에 생성된 보안 엔진 응용 프로그램에 대한 해쉬 코드 값이고,
상기 제 2 해쉬 코드 값은 상기 응용 프로그램에 대한 해쉬 코드 값에 해당되며,
상기 시스템 초기 설정을 수행한 후, tty(teletypewriter) 장치에 대해 수행되고 있는 프로세스들은 종료되는 것을 특징으로 하는, 보안 방법.
제 1항에 있어서
상기 제 2 해쉬 코드 값은 상기 응용 프로그램의 바이너리 파일의 저장 위치를 파악하고, 상기 바이너리 파일로부터 해쉬 코드를 도출한 값에 기초하여 생성되는 것을 특징으로 하는 보안 방법.
제 1항에 있어서
상기 제 1 해쉬 코드 값과 상기 제 2 해쉬 코드 값이 동일한 경우,
상기 응용 프로그램은 상기 보안 엔진 응용 프로그램에 해당되는 것으로 판단되어 상기 인증 상태 정보는 허용 상태로 결정되고,
상기 제 1 해쉬 코드 값과 상기 제 2 해쉬 코드 값이 동일하지 않은 경우,
상기 응용 프로그램의 상기 인증 상태 정보는 불허 상태로 결정되어 상기 응용 프로그램은 종료되는 것을 특징으로 하는 보안 방법.
삭제
제 1항에 있어서
상기 응용 프로그램이 상기 tty 장치의 파일 열기를 요청하여 허용된 경우,
동적 할당 메모리 상에 상기 tty 장치의 자료 구조가 할당되는 것을 특징으로 하는 보안 방법.
제 5항에 있어서
상기 보안 엔진 응용 프로그램은 배타적 모드 단계를 포함하되,
상기 tty 장치의 파일 열기를 요청하여 허용된 경우, 상기 보안 엔진 응용 프로그램은 배타적 모드 적용을 요청하여 다른 상기 응용 프로그램의 상기 tty 장치의 파일 열기를 차단하는 것을 특징으로 하는 보안 방법.
제 1항에 있어서
상기 보안 엔진 응용 프로그램의 바이너리 파일은 마운트 파일 시스템에 저장되고, 상기 보안 엔진 응용 프로그램의 해쉬 코드 파일은 루트 파일 시스템에 저장되는 것을 특징으로 하는 보안 방법.
제 7항에 있어서 상기 루트 파일 시스템은 메모리 파일 시스템에 해당하는 것을 특징으로 하는 보안 방법.
제 1항에 있어서
USB 호스트 제어기로부터 신호를 수신하고 상기 인증 상태 정보가 허용 상태로 결정된 경우, 상기 신호로부터 도출된 문자열이 버퍼에 저장되는 것을 특징으로 하는 보안 방법.
제 9항에 있어서
상기 응용 프로그램의 상기 외부 장치에 대한 문자열 읽기 시스템콜을 호출한 경우, 상기 버퍼에 상기 문자열이 저장되어 있는지 판단하고,
상기 문자열이 저장되어 있는 경우 상기 응용 프로그램으로 상기 문자열을 전송하는 것을 특징으로 하는 보안 방법.
제 1 항에 있어서
상기 응용 프로그램에서 상기 외부 장치에 대한 문자열 쓰기 시스템콜을 호출하고 상기 인증 상태 정보가 허용 상태로 결정된 경우, USB 호스트 제어기로 문자열 쓰기 명령을 전송하는 것을 특징으로 하는 보안 방법.
제 1항에 있어서
상기 응용 프로그램의 상기 인증 상태 정보를 결정하기 위한 인증 요청 신호에 기초하여 상기 응용 프로그램의 보안성에 대해 판단하는 것을 특징으로 하는 보안 방법.
제 1 항에 있어서
상기 응용 프로그램이 인증 종료를 요청한 경우, 상기 인증 종료 요청에 기초하여 상기 인증 상태 정보를 변경하는 것을 특징으로 하는 보안 방법.
외부 장치에 대한 리눅스 기반 보안 시스템에 있어서
보안 엔진 응용 프로그램에 대한 제 1 해쉬 코드 값에 대응되는 해쉬 코드 파일이 저장되는 보안 엔진 해쉬 코드 파일부;
상기 보안 엔진 응용 프로그램에 대한 바이너리 파일이 저장되는 보안 엔진 바이너리 파일부;
상기 외부 장치가 플러그-인(plug-in) 되는 USB 호스트 제어기;
초기 설정된 시스템 정보에 기초하여 응용 프로그램의 보안성에 대해 판단하고, 상기 응용 프로그램에 대한 인증 상태 정보를 결정하는 응용 프로그램 인증 루틴부; 및
상기 응용 프로그램의 상기 외부 장치에 대한 사용 요청을 수신한 경우, 상기 인증 상태 정보에 기초하여 상기 응용 프로그램의 외부 장치 사용 여부를 결정하는 인증 검사 매크로부; 를 포함하되,
상기 인증 상태 정보를 결정하는 경우,
제 1 해쉬 코드 값과 제 2 해쉬 코드 값을 비교하여 결정하되,
상기 제 2 해쉬 코드 값은 상기 응용 프로그램에 대한 해쉬 코드 값에 해당되며,
상기 초기 설정 후, tty(teletypewriter) 장치에 대해 수행되고 있는 프로세스들은 종료되는 것을 특징으로 하는, 보안 시스템.