2011년 9월 30일부터 개인정보보호법(제정 2011.3.29.) 법률 제0465호가 전면 시행됨에 따라 CCTV에 대한 불법사용 및 불법해킹의 방지 필요성이 대두됐다[1]. 현재인터넷 등에서 아무 제재 없이 돌아다니고 있는 CCTV 화면 카메라 촬영 동영상, 블랙박스 동영상 등은 그 안에 고화질로 촬영된 사람들의 얼굴이 아무런 가림 작업없이 유통되고 있어 또다른 피해자를 양산할 수 있다. 이러한 이유로 CCTV에서 촬영되고 압축된 동영상을 저장장소로 전송하거나 유통시킬 때, 동영상을 암호화해 유통시킬 필요가 강력하게 제기되고 있다.
황 선 철 │ 인덕대학교 방송영상 미디어과 교수(sthwang@induk.ac.kr)
CCTV나 WebCam 등은 대개의 경우 임베디드 시스템(Embedded System)으로 제작돼서 매우 제한적인 리소스를 가지고 있다. 즉 연산능력이 일반적인 컴퓨터나 스마트기기 등에 비해 현저하게 떨어진다. 여기에 H.264 코덱이 필요한데 H.264 코덱만으로도 임베디드 시스템의 연산능력은 한계에 도달한다. 그러므로 제한된 리소스를 갖는 임베디드 시스템에서는 매우 제한된 연산만으로 암호화 과정을 수행해야 한다[8].
H.264 코덱은 데이터 전송을 위해 NAL 구조를 사용하고 있으며 NAL 구조에서 접근하면 코덱에 접근하지 않아도 압축된 동영상 데이터를 변환시킬 수 있게 된다[2][3][4]. 이번 원고에서는 연산능력이 상대적으로 낮은 임베디드 시스템에서 암호화 알고리즘을 수행하기 위해 코덱 외부에서 NAL 데이터를 접근해 암호화 하는 방안을 제시하고자 한다.
또 한 암호화를 위해 블록암호화(Block Cipher) 알고리즘을 사용하고자 한다. 블록암호화를 위해 개발된 알고리즘으로는 SEED, AES, TDES 등이 있으며[5][6], 최근 제한된 연산능력을 갖는 임베디드 시스템이나 스마트폰 등을 위해 HIGHT 알고리즘이 인터넷진흥원(KISA)에 의해 표준으로 제정됐다[7][8]. 이번 원고에서는 CCTV 또는 블랙박스 등과 같이 제한된 시스템에서 고속으로 효율적인 암호화를 위해 NAL 단위 레벨에서 블록암호화 알고리즘을 제안하고자 한다.
보안 CCTV 구성요소
이번 원고에서는 기존의 CCTV의 H/W를 직접 변경하지 않고 H.264 코덱으로 압축된 바이트스트림을 외부에서 Hooking 해 암호화를 처리하는 방식으로 개발했다. 그림 1은 이번 원고에서 제안하는 보안 CCTV의 개요도다. 일반적인 CCTV는 카메라 내부 또는, 외부에 H.264 코덱이 H/W 형태 또는, S/W 형태로 존재한다.
이때 코덱에서 압축된 결과인 바이트스트림을 외부에서 접근하는 방식을 사용해 데이터를 보안했다. 일반적인 경우 카메라의 코덱을 바꾸는 것은 대량생산을 전제로 하지 않으면 불가능하다. 이번 원고에서는 기존에 생산됐거나 소량생산 되는 카메라에서 데이터를 보안할 수 있는 기능을 제공한다.
H.264 바이트스트림 전송을 위한 NAL 구조
H.264로 압축돼 전송되는 데이터는 일렬로 전송되는 bytestream 형태로 전송된다. 이 때bytestream은 여러 부분으로 구분돼 각각 중요한 정보를 담아서 전송된다. H.264 bytestream의 구조는 다음 그림 2와 같다.
암호화 대상 바이트 검출
H.264는 MPEG-2와 달리 데이터를 바이트 단위로 구성해 전송 또는, 저장하기 때문에 Bytestream의 구조를 갖는다. 또한, 각 기능에 맞게 데이터를 구분해 포매팅 했으며 각 부분은 NAL unit으로 구분지어 놓았다. 그런데 이번 원고에서는 이들 모든 부분을 암호화 하지 않고 화면에 영향을 주어 화면이 보이지 않게 하는 방식이므로 NAL unit 중에서 화면관련 부분만을 검출해 암호화 대상 바이트로 정한다. 다음 과정은 암호화 대상 바이트를 검출하는 알고리즘이다.
- NAL unit 시작패턴을 검출한다.
- NAL unit 시작패턴
3bytes start pattern : 00000000 00000000 000000XX
4bytes start pattern : 00000000 00000000 00000011 000000XX
4bytes start pattern : 00000000 00000000 00000000 000000XX
- 일반적인 패턴은 세 번째 패턴이며 특히 00000000 00000000 00000000 00000001 이다
- 시작패턴이 검출되면 다음 1 byte를 읽어서 16진수 0x1f와 AND 시켜 nal_unit_type에 저장하고 이를 근거로 NAL unit이 화면 관련 데이터인지 판단한다.
- nal_unit_type 결과가 1~5이면 화면 관련 데이터이므로 암호화 과정을 수행한다.
2.3 HIGHT 알고리즘
HIGHT 알고리즘은 하드웨어 사양이 낮은 시스템에 사용하기 위해 한국인터넷진흥원(KISA)에서 개발해 배포하고 있는 암호화 알고리즘이다. 이 알고리즘은 스마트폰이나 임베디드 시스템처럼 낮은 사양의 하드웨어에 맞게 개발됐는데 64비트 블록 암호방식을 사용한다. 사용하는 마스터키는 128비트 암호화 대상 평문은 64비트로 64비트 암호문을 생성한다.
8비트 단위의 기본적인 산술연산만으로 이루어지기 때문에 기존의 블록 암호화 알고리즘보다 간단한 특징을 갖는다. 이번 원고에서는 다양하게 존재하는 블록 암호화 알고리즘 중에 모바일 기기에 특화된 HIGHT 알고리즘을 블록 암호화에 차용하기로 했다.
HIGHT의 전체구조는 일반화된 Feistel 변형구조로 이루어져 있으며, 64비트의 평문과 128비트 마스터키로부터 생성된 8개의 8비트 화이트닝 키와 128개의 8비트 서브키를 입력으로 사용해 총 32라운드를 거쳐 64비트 암호문을 출력한다. 다음 그림 4는 KISA에서 제공하는 알고리즘의 전체 구조도이다.
2.3.1 키스케쥴
HIGHT의 라운드키는 화이트닝 키(WKi)와 LFSR(leftfeedback shift register)을 사용해 생성한 서브키(WKj)들로 이루어진다. 화이트닝 키는 마스터키에 의해 생성되며 총8바이트64비트로 구성되고 서브키는 LFSR 연산에 의해 총128바이트로 이루어진다. 모든 라운드 키는 8바이트 단위로 구성돼 평문 8바이트와 연산돼 암호문 8바이트를 산출한다.
화이트닝 키 : WK0 ~ WK7
서브키 : SK0 ~ SK127
2.3.2 암호화
HIGHT 암호화는 첫 번째 네 개의 화이트닝 키로 평문을 첫 번째 라운드 함수입력을 만들어 낸다. 그 이후 서브키를 이용해 32번의 라운드 함수를 거쳐 나머지 화이트닝 키로 최종변환을 해 암호문을 만들어낸다. HIGHT가 평문을 암호화하는 전체구조는 다음 그림과 같다.
2.4 제안된 동영상 암호화 알고리즘
이번 원고에서는 상기 NAL 구조를 분석해 VCL인 경우를 다시 세분해 다음과 같이 암호화했다
(1) VCL class의 RBSP(raw byte sequence payload)의 크기가 8바이트 미만의 경우: 암호화 하지 않음.
(2) VCL class의 RBSP의 크기가 8~1024바이트인 경우 : 최초 8바이트 64비트 암호화.
(3) VCL class의 RBSP의 크기가 8~2048바이트인 경우 : 최초 8바이트 64비트와 1025번 1째부터 8바이트 암호화.
(4) VCL class의 RBSP의 크기가 8~3072바이트인 경우 : 최초 8바이트 64비트와 1025번 1째부터 8바이트와 2049번 4째부터 8바이트 암호화.
실험결과 및 고찰
암복호화 프로그램 개발결과
이번 원고에서는 암호화 및 복호화를 수행하는 프로그램을 MS Visual Studio 2010으로 개발했다. 개발 형태는 Dialog Box 외관으로 개발했으며, 암호화 및 복호화를 선택하는 버튼과 사용자 계정 및 패스워드를 입력하는 부분 대상파일을 열 수 있는 버튼과 입력파일에 따른 출력파일명을 나타내는 부분 및 암복호 과정을 보여주는 부분으로 구성했다.
프로그램 수행 순서는 암호복호를 선택하면 사용자 계정 및 패스워드가 활성화된다. 여기에 정보를 입력하면 ‘파일열기’ 버튼이 활성화되고 이 버튼을 누르면 그림과 같이 열기대화창이 나타난다. 여기서 원하는 파일을 선택하고 ‘열기’ 버튼을 누르면 ‘암복호 시작’ 버튼이 활성화되고 이 버튼을 누르면 암호화 또는, 복호화가 수행된다. 원본파일은 암호화 되면 파일명 앞에 ‘Enc_’라는 이름이 붙게 되고 암호화 된 파일을 복호하면 ‘Dec_’라는 이름이 원본파일명 앞에 붙게 된다. 프로그램의 예시는 다음과 같다.
3.2 암호화 성능분석
이번 원고에서는 1GByte(1,000MByte) 크기의 동영상과 0.5GByte(500MByte) 크기의 동영상을 이용해 암호화 성능을 비교했다. 암호화 성능비교는 편의상 통신단계에서 하지 않고 버퍼 Hooking과 처리 및 재삽입 단계로 실시했다. 그러므로 실제전송에 따른 시간지연은 고려되지 않은 점을 밝혀둔다. 이유는 암호화 시간에 따른 성능비교에 집중했기 때문이다. 실험은 재부팅돼 버퍼 상황이 비교적 깨끗한 상황에서 실시됐으며 총 5차례 각각의 경우에 대해 실시했다.
또한, 가장 표준화돼 있는 FFPLAY.EXE 동영상플레이어를 사용해 플레이 결과를 실험했다. 이는 FFMPEG이라는 단체에서 세계각처의 개발자들에게 표준의 고속코덱을 제공하는 일환으로 플레이어를 제공하고 있는데 영리를 목적으로 하는 회사의 제품은 그들만의 품질개선에 의해 객관적인 평가를 제공할 수 없다는 판단에서다.
암호화 성능 결과 및 고찰
이번 원고에서는 실시한 실험방법은 (1) 데이터 전체를 암호화 하는 단계와 (2) 제안된 알고리즘과 같이 일부 데이터를 암호화 하는 단계 및 (3) 암호화 하지 않고 데이터 전체 버퍼만 Hooking한 후 다시 삽입하는 단계 등 세 부분으로 나누어 실험해 다음과 같은 결과를 도출했다.
실제 전송로에서는 동영상이 동기에 맞춰서 전송되기 때문에 암호화 안하는 세 번째 결과와는 다른 결과를 도출한다. 이번 실험에서는 다만 버퍼링 시간을 제외한 순수 암호화에 필요한 시간만을 얻기 위한 실험임을 밝혀둔다. 결과에서 보는 바와 같이 전체 데이터를 암호화하는 경우는 버퍼를 Hooking해 삽입하는 단계에 비해 약 694%의 연산시간이 필요했다.
여기에 비해 이번 원고에서 제안된 방법에서 최대한의 경우인 모든 VCL이 24바이트를 암호화 한다는 전제에 따르면 약 111%의 연산시간이 필요한 것으로 나타났다. 다시 말해 순수 암호화 시간만을 계산하면 전체 암호화 소요시간÷부분 암호화 소요시간=약 18%에 불과한 것으로 나타났다.
실제 시스템에서 VCL의 경우 non-IDR(움직임 보상을 실시하는 부분영상)은 IDR 기준이 되면서 화면전체를 움직임 보상없이 압축하는 화면에 비해 데이터 량이 현저히 낮기 때문에 24바이트를 모두 암호화 할 가능성은 다소 떨어진다. 그러므로 이번 원고에서 제안한 부분 암호화를 이용하면 코덱을 직접 변형하지 않아도 되고 암호화 시간도 현저히 줄어들기 때문에 연산능력이 떨어지는 임베디드 시스템의 동영상 암호화에 매우 적합할 것으로 판단된다.
또한, 다음 그림에서는 (1) 원영상 플레이 결과와 (2) 암호화된 영상의 플레이 결과 및 (3) 복호화된 영상의 플레이 결과를 나타내고 있다. 이번 실험에서는 MPEG-2 형식으로 만들어진 방송 스트림을 TS(Transport Stream) 형태로 저장된 것을 음성 데이터를 제거하고 순수동영상만 분리해 H.264 코덱으로 변환된 파일을 사용했다. 파일명은 ‘test_on.264’이다
이번 원고에서는 실생활에 널리 사용되고 있지만 데이터가 유출됐을 때 치명적인 개인정보 유출로 이어질 수 있는 CCTV나 WebCam 등과 같은 동영상에 대한 보안방안에 대한 방안을 제시했다. 이번 원고에서 제시한 방안은 CCTV 등에서 널리 사용되고 있는 H.264 코덱에 대해 데이터를 암호화 하는 방안으로 본 알고리즘은 코덱을 직접변형하지 않고 압축된 데이터를 외부에서 Hooking해 VCL을 분류해 이들 데이터에 대해서 암호화를 수행하는 방안이다. 본 알고리즘을 이용하면 화면전체를 암호화하는 것에 비해 암호화 시간이 18%에 불과해 기존의 CCTV 시스템을 변경하지 않아도 되는 이점뿐만 아니라 낮은 연산리소스를 갖는 임베디드 시스템에 부담을 주지않고 기존 시스템을 향상시킬 수 있게된다. 이번 연구·개발을 통해 다음과 같은 결론을 얻었다.
1) 이번 원고에서 제안한 부분 암호화 알고리즘을 사용하면 전체 암호화 대비 18% 이하로 줄일 수 있다.
2) 제안된 알고리즘을 사용하면 기존의 CCTV 등의 내부변경 없이 암호화가 가능하다.
3) 제안된 알고리즘은 NAL 구조를 사용하는 모든 시스템에 확장시킬 수 있다.
이번 원고를 통해 개발된 성과를 향후 NAL 구조를 사용하는 시스템으로 확장하는 연구를 지속적으로 진행하고자 한다. 또한, 블록 암호화 알고리즘은 상대적으로 고사양의 모바일용이 아닌 CCTV 등 저사양 시스템에 특화해 보완하는 연구가 필요하므로 이 분야에서도 심도있는 연구를 필요할 것으로 보인다.
참고문헌
[1] 국가법령정보센터 www.law.go.kr, “개인정보보호법”, 2011.
[2] Iain E.G Richardson, H.264 and MPEG-4, Wiley, 2004.
[3] 호요성외 H.264/AVC 표준의 소스코드 분석 두 양사 2007.
[4] ITU-T, Recommendation ITU-T H.264 : Advanced video coding for generic audiovisual services, 2011.
[5] 박창섭 암호이론과 보안 대영사 1999.
[6] 하제철 외 “SEED에 대한 오류분석 공격”, 한국정보보호학회동계정보보호 학술대회논문집 제3권 제호 pp.39-44, 2003
[7] 한국인터넷정보원 HIGHT 블록 암호 알고리즘 사양 및 세부명세서 2009
[8] 한양대학교 산학협력단 외 경량 암호 알고리즘(HIGHT)의 하드웨어적 구현방안 연구 한국인터넷진흥원 2011
[9] S.Wenger et.al. RTP Payload Format for H.264 Video, The Internet Engineering Task Force(IETF), 2005
2013년 6월 전기학회논문지 62P권 2호 게재.
본 원고과 관련된 기술은 현재 네오테닉 사에서 연구개발을 통해 특허출원 중에 있음.
[월간 시큐리티월드 통권 제202호(sw@infothe.com)]
[2024-06-17] 
.jpg)
.jpg)
