Zyrus SecuDrive Review

http://toolz.pe.kr

“국내 최초 하드웨어 방식 USB"

이 게시물의 저작권은 toolz.pe.kr에 있습니다.

Part 1 : 보안과 디자인, 두 마리 토끼를 잡는다

Part 2 : 많이 알고, 많이 쓰자

Part 3 : 마무리, 종합평가

=================================================

Part 1 : 보안과 디자인

두 마리 토끼를 잡는다

(1) Three-C USB

Clean

깨끗하며 순수한 느낌을 주는 흰색 바디

옆면을 두르고 있는 은색 플라스틱은 금속 자재인듯한 착각을 준다

전반적으로, 밟혀도 멀쩡할 듯한 내구도를 느낄 수 있었다.

(실제 내구도는... 모르겠다.)

Comfortable

슬라이딩 방식의 USB 단자 채용

뚜껑을 잃어버릴 확률은 헤드폰에서 아버지 목소리가 나올 확률과도 같으며, 극강의 편리함을 제공한다.

Complete

죽었다 깨도 해독되지 않을 데이터

컨트롤러 하부에 보안 칩을 내장하여, 하드웨어 레벨에서의 암호화를 제공한다. 소프트웨어 방식의 보안디스크와는 차원이 다르다.

(2) 제품 특징

슬라이딩 방식의 USB 단자 채용

USB 2.0 인터페이스 채택

읽기 12.51MB/s  쓰기 5.45MB/s

하드웨어 방식 AES 256bit 암호화

(3) Against Software Method..

1. 호환성에 대한 약간의 해결 확률 존재

커널 드라이버를 적재하여, 실제 디스크의 Unallocated 영역을 접근하여 데이터를 저장하거나 가상 파일에 저장하게 된다. 두 경우 모두 커널 드라이버에서 생성된 Device를 거치게 되며, Windows에서는 이 Device에 드라이브 링크를 만들어주는 셈이다. 커널 드라이버는 Windows 용으로만 제공한다. 따라서 Windows 이외에의 플랫폼에서는 사용할 수 없는 단점이 있다.

Hardware Method의 경우, 장치로 직접 SCSI Pass Through IOCTL을 보내면 되므로, 타 플랫폼에서도 이것을 지원하는 경우에는 보안 USB에 접근할 수 있는 확률이 존재한다. (Software는 확률이 0다. - 적어도 제조사가 해당 드라이버를 제공하거나 프로젝트가 크로스플랫폼을 염두해두고 개발되지 않는 이상.)

정리하면, 확률적으로 Hardware Method가 우위에 있다는 뜻이다. 물론 정식으로 업체에서 보장하는 부분은 Windows에 한하며, 이는 Software / Hardware Method 모두 같은 상황이다.

2. 속도 향상

로컬 머신에서 이루어지던 Software Method와는 달리, USB 장치 내부에서 이루어진다. 따라서 암호화 과정의 분리가 가능해진다. 물론 암호화 과정으로 인한 속도 저하를 막을 수는 없지만, 하드웨어 차원에서 이루어지는 것은 소프트웨어보다는 빠르므로 같은 목적을 가지는 SW에 비해 소폭 성능 향상이 있을 수 있다.

3. 호스트 독립적, 타 SW의 간섭을 피할 수 있음

위의 장점과 같은 이유로, 타 SW의 간섭을 피할 수 있다. 백신 프로그램의 핉터 드라이버 같은 것을 말한다. 또한 커널 드라이버 충돌이나 기타 이유에 따른 결과로 정상 작동이 불가능 할 수 있는 SW방식과 달리, HW방식에서는 일어날 리가 없는 상황들이다.

4. 관리자 권한 없이도 가능

SW 방식은 커널 드라이버를 적재해야 하므로 관리자 권한, SeLoadDriverPrivilege가 필요했다. 하지만 하드웨어 칩에서 암호화가 이루어지므로, 사용자는 여느 USB를 사용하듯이 하면 되며, 암호화는 컨트롤러와 NAND 메모리 사이에서 이루어진다. 따라서 관리자 권한 없이도 가능하다.

Part 2 : 많이 알고 많이 쓰자

아는 만큼 보이는 법이다. SecuDrive에 대해 많이 알수록 더욱 효율적으로 사용할 수 있음은 자명한다. 번들 SW와 SecuDrive에 대한 간단한 분석을 통해 조금 자세히 알아보자.

장점에 대해서는 푸른색, 단점에 대해서는 붉은색으로 표기할 것이며, 제안 사항에 대해서는 하이라이팅을 사용한다.

번들 SW는 CD영역 루트의 SYSTEM 폴더 하부에 존재한다.

(1) SecuDrive

1. First Setup

처음 실행 시에는..

EULA 동의 창이 나온다. 일반적 사용자라고 하면, 위반할 사항이 없는 내용들이다.

개인정보를 입력할 수 있다. 이 정보는 USB에 로그인 한 이후,

정보>사용자 정보에서 ‘로그인 전 사용자 정보 표시’에 체크를 하면 USB에 로그인 전에 본인의 개인정보를 띄울 수 있다.

USB 분실 시 취득자가 연락을 취할 수 있는 방법을 제공하는 것이다. 찾아줄 수 있는 희망을 제공하는 셈인데..

그렇다면, 인터넷에 연결된 경우 접속된 PC에 대한 정보나 물리IP 등을 서버에 자동전송하여, 트래킹을 할수도 있지 않을까? 연락처 표기의 연장선상에서, 내 USB의 위치를 추적해볼 수 있는 근간을 제공할 수 있다.

2. 로그인부터 보안영역 접근까지

들어가기에 앞서, 한가지 전제를 깔아야 한다. USB 등 컨트롤러와 Co-operate하는 기능들에 대해서는

IOCTL_SCSI_PASS_THROUGH,

IOCTL_SCSI_PASS_THROUGH_DIRECT

가 사용된다. 이 경우 하드웨어에 직접 IOCTL을 날리게 되므로, 컨트롤러로부터 일련의 결과를 가져올 수가 있다. (물론 응답에 대한 설계는 컨트롤러 설계에 들어가있음은 자명한다.)

쉽게 정의하자면, IOCTL은 일종의 질의(Query)라고 보면 된다.

Step 1 : 실행 위치 검증

Login.exe는 프로세스가 실행되는 위치를 CD영역이라 가정한 상태에서 작동한다. 따라서 하드디스크에 Login.exe를 복사 후 실행을 한다면,

이런 창을 보게 된다.

하지만 이 오류 메시지들의 내용은, 하드디스크에서 실행이 불가능하다는 것이 아닌, 장치 인증 실패에 대한 내용일 뿐이다. 즉, 사용자에 현재 상태나 오류에 대한 충분한 정보를 전달하지 못하고 있다. ‘CD영역에서만 실행될 수 있습니다’와 같은 안내문구라도 있는 것이 충분한 정보전달이라 생각된다.

[+] 복수 장치 구별 문제

물론 한 컴퓨터에서 복수의 SecuDrive가 꽂혔을 경우를 처리하기 위해, CD영역을 기준으로 판별을 한다. 하지만, 타 장치에서 실행해야 하는 경우도 있다. CD영역을 안쓰려는 경우가 이에 해당한다.

로그인과 그 부가 모듈을 패키지로 묶어서 배포함으로서 CD영역 없이도 로그인을 하고, 복수 장치에 대해선 로그인할 장치를 선택하게 한다면, ‘활용성’도 높아질 뿐만 아니라 선택의 폭도 늘릴 수 있게 된다.

Step 2 : Password 검증, 로그인

위와같이 IOCTL 응답에 대해 모두 통과된 경우,

이런 로그인 창을 보게 되며, 이제 패스워드를 치고 맞을 경우, 통과된다.

[+] 패스워드 검증 과정

패스워드 체크 로직에 대해서 두가지 방식을 추론해볼 수 있다.

첫 번째 방법은, 체크가 한번 이루어지고, Login.exe에서 판단 후에 Login IOCTL을 보내는 형식이다. 이 경우, Pwd 체크 후 조건 분기점을 코드 패칭함으로서 무조건 로그인되게 할 수 있다.

두 번째 방법은, 장치에 패스워드를 IOCTL로 보낸 상태에서 맞으면 컨트롤러에서 자동으로 로그인을 하는 방식이다. 이 과정에서는호스트PC가 개입할 수 없으므로, 코드 패칭이 불가능하다. 따라서 패스워드 우회가 약간 어려워지게 된다.

SecuDrive는 경우, 패스워드 실패 시 10번의 IOCTL 무더기로 검증 과정이 끝나지만, 패스워드 검증 성공 시 10번 이후 또다른 루틴을 통과하므로, 첫 번째 방법이 맞을 것으로 생각되나, 이 경우 패스워드가 컨트롤러에 저장되는 이유가 설명되지 못한다.

(어떤 방법을 택했을지..)

SecuDrive의 기본 기능은 여기까지이다. 이는 여느 보안USB와 크게 다를 바가 없다. (하드웨어 보안 칩이 존재하는 것을 제외하면 말이다.)

[+] Global Solution

Login.exe는 4개국어를 지원한다. 한국어, 영어, 일본어, 중국어. 아마 해당 솔루션의 수출을 염두해두고 개발한 듯 하다.

3. Beyond the GUI

GUI 뒤쪽, 즉 보이지 않는 부분에서의 분석/비교를 해볼까 한다. 성능도 보이지 않는 부분이라 할 수 있다.

#1 : 하드웨어 암호화 칩

vs 소프트웨어 암호화

앞에서 언급한 바와 같이, 소프트웨어 방식과 비교했을 때 속도, 호환성 등의 면에서 우세한 점이 존재하였다. 여기에 리버싱이 어렵다는 점도 더할 수 있다.

암호화 작동과정 비교

아래 플로차트는 SW/HW 레벨에서의 암호화 과정을 보여주고 있다. 좌측이 HW, 우측이 SW이며 [NOR]는 평문, [ENC] 는 암호문을 뜻한다.

결과적으로 NAND 메모리에 저장되는 데이터는 같다. (같은 Enc. Function을 가지면.)

하드웨어 레벨의 암호화가 속도면에서 우위에 있으며, 오동작이나 코드 패칭 등의 이슈에 대해서도 안전하다.

#2 : NAND 메모리

사용자가 가장 손쉽게 느낄 수 있는 ‘보이지 않는 부분’은 바로 NAND 메모리의 속도이다.

일반USB 모드와 보안USB 모드 두 개를 측정해보고, 대조군으로 타 업체의 제품을 설정해보았다.

동일한 용량을 가지는 SecuDrive와 T3, Swing Gold 제품과의 속도차이가 확연히 난다. 가격대의 경우, 23000원인 Swing Gold에 비해, SecuDrive는 64500원의 가격대를 형성하고 있다. 3~4만원 더 비싼 상태에서, HW방식의 암호화라는 타이틀이 있다 할지라도, Swing Gold에 SW방식 암호화를 하는 것이 싸면서 제기능을 할 것으로 보인다. 즉, 가격 대비 성능비가 낮으며, HW방식의 암호화의 처리속도 이점을 살리지 못하였다. 이는 SW방식의 암호화 내지는 간단한 보안 파티셔닝 툴에만 안주하던 기존의 사용자들에 Attracting Point가 되지 못하며, 따라서 이들의 구매력 감소로 이어질 가능성이 높다. 또 자체 컨트롤러를 사용하므로, CD영역 등 UFD의 고급 기능들을 사용하지 못하게 되는 일이 생긴다.

(2) BundleSW : FileSync

1. FileSync 분석하기

우선 FileSync가 남기는 정보를 종합해보았다.

"F:\SYSTEM\FileSync.exe" BRAINZSQUARE-SH Start K: Utility 1042

라는 인자를 넘겨준다. 여기서 BRAINZSQUARE-SH는 인증키로 추정되며, Start는 ‘시작’을 뜻하는 인자,  K:는 SecuDrive 중 데이터 영역을, 1042는 언어 코드이다. 각 국가별로 언어 코드가 존재하는데, 한국어의 경우 1042(0x0412)이며, 영어는 1033(0x0409) 이다.

2. 속도 테스트

VC++ 프로젝트 파일과, 보관중인 Archive 파일이 담긴 Laboratory 폴더를 USB로 그냥 복사하는 시간과, 리스팅 후 비교만하는 시간을 나누어 측정해보았다.

※ 이하 언급되는 모든 ‘속도’는 평균속도이다.

소형 파일이 많이 존재하는 실험데이터의 특성상, 속도가 다소 저조할 수 밖에 없었던 것으로 보인다.

동기화 여부를 결정하기 위해 사용되는 리스팅과 내부 루틴에 소요되는 시간은 다음과 같다.

이번에는 Windows Driver Kit ISO 이미지 파일만 들어있는 폴더를 백업하여 위와 같은 방법으로 측정해보았다.

위 결과를 종합하면..

➀ SecuDrive 자체의 성능이 매우 느리다.

➁ Windows 기본 복사 함수의 성능보다 ‘약간’ 우세하다.

3. 사용 편의

#1 : 폴더만 동기화를 해야 한다?

[문제점]

단위 파일이 동기화되어야 할때도 있다.

특히 소용량의 파일이 대량으로 동기화되어야 하지만, 그 부모 폴더에는 다른 파일들도 많이 있는 경우에는

동기화 될 필요가 없는 경우임에도 불구하고 동기화 루틴을 타야 한다.

[해결책]

위와 같이, 파일이나 폴더를 Drag&Drop 식으로 추가할 수 있게 하는 방안이 존재한다. 사용하기에도 직관적일테고 말이다.

(3) BundleSW : FileCrypto

1. 분석

FileCrypto.exe BRAINZSQUARE-SH Start K: 1 1042

FileCrypto 역시 커맨드 라인으로 BRAINZSQUARE-SH가 있어야만 실행이 되며, 이외의 경우에는 그냥 리턴한다.

암호화된 파일은 끝에 .enc 확장명이 붙게 되며

다음과 같은 데이터를 헤더로 가지게 된다.

87 A0 13 29 C0 CA 73 8B EC ED F2 1D F6 D0 D8 78

즉, 위와 같은 Hex 코드로 시작한다면, SecuDrive를 통해 암호화되었다고 판단할 수 있다.

암호화 과정은

원본에서 24576Byte를 읽고 암호화를 한 이후 대상에 4096Byte를 기록 한 후, 20480Byte를 기록하며 이 과정에서 걸리는 시간은 대략 590 ns (나노 초) 정도 된다. 나누어 기록하는 것은 블록화 알고리즘의 특성으로 보인다.

폴더 선택 시 폴더 내부의 모든 파일을 암호화하게 된다. 따라서 많은 수의 파일 선택 시 (같은 폴더에 전부 속해있다면) 고생을 줄일 수 있다.

2. 성능

FileCrypto는 SecuDrive를 ‘키’로 설정하여, 이 키가 있어야만 자료의 접근이 가능한 암호화 도구이다. 키를 이용해 암호화와 복호화를 한다.

따라서 여기서는 암호화 속도에 대해서만 비교할 수 있다.

(워짜피 일반적 경우에서는.. 암호화 알고리즘의 강도에 대해서는 거의 의미가 없기 때문.)

아래의 측정은 내장 하드디스크에서 이루어졌다.

3. 사용 편의/의견 제안

#1 : Drag&Drop이 더 편하다.

FileSync와 마찬가지로 Drag&Drop이 필요하다. 꼭 일일이 찾아서 선택할 필요는 없기 때문이다.

#2 : 다중 장치 삽입 시 ‘키’ 설정 창

FileCrypo 암호화 과정에 따르면, SecuDrive를 ‘키’로 설정하여서 암호화에 사용한다고 한다. 물론 FileCrypto 실행 시에는 대상 장치의 인덱스가 넘어가므로 프로그램 작동 상 문제가 발생할 경우는 거의 없지만, 사용자는 알 수가 없다.

다중 장치 환경을 생각한다면 키로 설정할 장치를 세팅하는 콤보박스 쯤은 있는 것이 좋을 듯 싶다.

#3 : 암호화 된 파일을 다시 암호화?

암호화된 파일을 다시 암호화하게 된다.

논리적으로, 암호화된 파일이 다시 암호화되어야 할 필요는 없는 듯 하다. 더군다나 같은 ‘키’로 암호화를 한다고 하면 말이다.

WDK iso 파일을 1번,2번,3번 암호화한 파일의 앞 64Byte이다.

0~16바이트가 256비트 암호화 키 인 듯 하다. (제조사 측에서는 AES 256Bit 암호화를 사용했다고 한다.) 이후 16비트가 달라지며 다시 6바이트가 23 26 00 00 00 00 으로 동일하다.

#4 : 파일 선택은 항상 ‘내 문서’에서 시작해야 하는가?

매번 내 문서에서 시작하게 된다면, 깊숙한 곳까지 찾아갔을 때 얼마나 짜증이 날까. 적어도 한 세션에서만큼은 마지막으로 탐색한 시점이 저장되었으면 한다.

#5 : 경로 직접 입력 지원

이미 열려있는 탐색창의 주소를 그대로 긁어쓰는 것이 현실적이다. 굳이 찾아 들어갈 필요 또한 없다고 본다.

#6 : 프로그레스 바 정확도 향상

파일 개수에 비례한 프로그레스 설정이 아닌, 처리된 바이트에 따라 처리하는 것이 더 ‘현실적’인 완료 현황을 보여준다. 지금과 같은 상태에서는, 대다수의 소용량 파일이 앞쪽에 포진되어있고 대용량 파일이 뒤에 있는 경우, 프로그레스는 50%를 넘어야겠지만 (대용량 처리 전) 현실은 20%도 처리하지 못했을 수도 있다.

#7 : 재암호화 전 검증

암호화된 파일을 다시 암호화 하는 짓을 할 사람은 없다.

첫 16바이트가 87 A0 13 29 C0 CA 73 8B EC ED F2 1D F6 D0 D8 78 와 일치한다면, 메시지 박스를 띄워서 정말로 암호화할 것인지 다시 한번 묻는다면, 쓸데없는 고생을 줄일 수 있지 않을까.

(4) BundleSW : FullEraser

1. 분석

FullEraser는 다음과 같은 알고리즘을 지원한다.

- 상수/랜덤 Overwrite

- US DoD 알고리즘 3/7회 덮어씌우기

- Gutmann 알고리즘

일반적인 환경에서 쓰기에는 충분하다.

선택 창에서 폴더를 선택할 경우 폴더 내에 속해있는 모든 파일에 대해 제거 루틴을 진행하게 된다. 따라서 폴더 선택 시 주의해야 한다.

역시나 프로그램 인자로 FullEraser.exe BRAINZSQUARE-SH Start 1 1042를 가진다. 인증코드, 명령, SecuDrive Index, 언어코드의 순으로 추정된다.

단순한 프로그램 UI는 직관적이면서도 깔끔한 모습이다.

2. 개선 사항 / 의견 제안

#1 : Drag&Drop 지원

앞의 두 개의 유틸리티에서도 말했던 바와 같은 이유다.

또한 UI 소형화에도 영향을 줄 수 있다.

#2 : 프로그레스 바 정확도 향상

앞에서 말했던 바와 같다. 사용자에게 알려주는 정보가 조금 정확해야 할 필요가 있다.

#3 : Current Status에 대한 구체적 정보 제공

% 수치라던가, 처리된 데이터 양이라던가, 속도, 예상 시간 등의 정보를 ‘전체 진행 상태’ 밑의 남는 공간에 제공한다면, 현 상황에 대한 구체적인 모니터링이 가능할 것으로 보인다. 앞의 번들SW에도 해당되는 사항이다.

#4 : UI 크기 축소 (or 미니모드)

트레이 아이콘 위쪽에.. 알림 창 형식으로

조그마하게 뜨는 팝업 창처럼 나와서 위와같이 간편하게 쓸 수 있게 하는 것이다.

혹은 SW_TOPMOST 속성을 가진 상태에서 드래그하면 바로 파쇄하는 기능 추가하는 것도 활용성과 편의를 높인다는 점에 일조할 듯 하다.

(5) BundleSW : HideFolder

1. 분석

HideFolder는 이 솔루션 중에서 유일하게 관리자 권한이 필요한 SW이다. 커널 드라이버를 로드하여 파일을 숨겨야 하기 때문이다.

hffsd.sys는 32bit 시스템용, hffsd64.sys는 64비트 시스템 용이다. 이 드라이버는 커널에 로드되면

1. \FileSystem\hffsd 라는 드라이버를 생성한다.

2. 언로드 루틴이 없다. 따라서 제거가 불가능하다.

숨김 후에는 바탕 화면의 Refresh를 한다.

또한 서비스 파라미터의 값 변경을 막기 위해

값을 주기적으로 변경하고 있다.

1. HKLM\SYSTEM\CurrentControlSet\Services\hffsd

의 Start. 0으로 고정. 4로 바꾸면 DISABLED로 파일 숨김을 무력화 할 수 있음.

2. HKLM\SYSTEM\CurrentControlSet\Services\hffsd\Parameters\essential의

count, process(n) 값. 이들은 접근 제한이나 리스팅 시 예외적으로 허용할 시스템 프로세스의 풀 패스와 개수를 적어놓은 듯 하다.

프로세스 생성 notify routine을 생성하여서 프로세스 생성을 감시한다.

추가 함수 후킹은 없는 듯 하며, 필터 드라이버로 작동하면서 IRP를 중간에서 가로채 미존재 처리를 하는 듯 하다.

따라서 이 프로그램이 무력화 될 수 있는 경우는 2가지 이다.

1. hffsd로 보안 해재시 보내는 IOCTL을 가로채 이를 추후에 재활용해먹는 방법.

2. 레지스트리 관련 함수를 후킹해놓은 상태에서 hffsd의 변경을 제한하고, 이 상태에서 Service Start Type을 Disabled로 바꾸는 방법.

예외목록에 추가하게 되면, 일단 드라이버가 로드되게 되며 나중에 값이 바뀌게 되므로 이 방법으로는 불가능하다.

중간에서 아무리 후킹을 하고 조작을 할지라도, 결국 디스크를 Low-Level 분석을 한다면 숨겨진 파일이 그대로 나온다.

숨겨진 폴더와

그 아래에 속해진 파일의 리스트가 포렌식 분석을 했을 때 발견되었다. 내부의 자료를 접근하고 조작하는 것은 어려운게 아니다.

2. 개선 사항 / 의견 제안

#1 : 세부 권한 설정

HideFolder을 조금 더 쓸만한 보안프로그램으로 만들 수 있다.

워짜피 hffsd.sys가 필터 드라이버로 존재하여서 파일/폴더의 접근제한을 한다고 하면, 조금 더 세부적인 기능을 넣을 수도 있다.

현재는..

[             경로            ]

만 나와있지만

Read,Write,Execute 등의 설정을 하는 것이다.

즉

[             경로            ] [R] [W] [X] [H]

Path                            [ ] [  ] [ ]  [ ]

이렇게 만드는 것이다. 물론 디렉토리는 eXecute가 불가능하다.

이러한 기능의 추가는 USB를 ‘키’로 설정하여 특정 폴더에 대한 접근 제한 등을 할려는 유저들을 끌어들일 수 있다.

#2 : 패스워드 입력을 통한 인증

반드시 USB만을 이용해 인증을 하기에는 사용자의 선택의 폭이 줄어드는 듯 하다. 패스워드를 통해서도 인증을 할 수 있게 수정한다면, USB 분실에 따른 데이터 접근 불가 문제 (물론 포렌식 분석하면 다 되지만.)를 해결할 수 있다.

Part 3 : 마무리, 종합평가

Strengths_____________________

(1) SecuDrive 제품

- ZTEIC 사의 Z8HM2 컨트롤러를 사용하였다.

이 컨트롤러는 비-관리자 상태에서의 암호화를 지원하며

별도의 PKI App.를 지원할 수 있고

유저 인증과 데이터 암호화가 암호화 칩에서 모두 이루어지고

16비트 ECC 체크 함수를 지원한다.

- 암호화가 컨트롤러에서 이루어지므로 데이터 탈취를 목적으로 하는 SW들로부터 안전하다.

- Samsung K9HCG08U1M 64Gb 낸드메모리를 사용하여 높은 성능을 낼 수 있다.

- 로그인 유틸리티가 CD영역으로 상주하고 있어 로그인 유틸리티의 감염이나 불법적인 삭제 작업에 대해 안전하다.

- 왠지 모르게 견고해보이는 바디는 사용자에게 충격에도 강한 ‘인상’을 준다.

(2) Login, 번들SW

- 관리자 권한 없이도 보안 영역에 접근하고 암호화를 수행할 수 있다.

- USB 사용에 유용한 여러 유틸리티들을 제공하여 USB 활용도를 증가시켜준다.

- USB 주인에 대한 정보를 입력하고, 보안영역 접근 시 이를 노출시킬 수 있어 분실 시 되돌려받을 확률을 증가시킬 수 있다.

- 컨트롤러로 패스워드 전송 시 triple-DES를 사용하는 것으로 추정된다. 중간에 생길 수 있는 잠재적인 스니핑 이슈도 해결할 수 있다.

Weaknesses___________________

(1) SecuDrive 제품

- 암호화를 거치지 않더라도 속도가 너무 느리다. NAND 보다는 컨트롤러의 성능이 낮은 것으로 추정된다.

- 타 제품에 비해 가격이 다소 비싸다. 속도가 느린 것을 감안하면 하드웨어 방식의 USB라 할지라도 유저들의 관심을 끌기에는 어려울 것으로 보인다.

(2) Login, 번들SW

- Login 모듈의 크래시, 혹은 Termination 후에도 보안영역은 여전히 멀쩡하게 살아있다. SW방식이라면 키를 매번 다르게 발급하여 커널 드라이버에서 인증을 통해 세션이 다름을 이용해 검증을 할 수 있지만, HW방식에서는 불가능하다.

- SecuDrive 없이도 번들SW의 실행이 가능하다. 번들의 개념이 흔들리는 부분이다.

- SecuDrive를 위해 만든 SW라면, 실행 시에 기본적으로 SecuDrive를 경로로 설정하는 정도는 필요한 듯 싶다. (FileSync의 경우, 백업 위치를 SecuDrive Secure Zone으로 한다던가..

Oppertunities___________________

(1) SecuDrive 제품

- 관리자 권한이 제한된 사용자 층의 지갑을 열 수 있다.

- 보안 프로그램의 취약점을 우려하는 사람들의 관심을 끌 수 있다. PC에서 암호화가 이루어지는 SW방식에 비해서는 HW가 몇 만배 안전하다고 할 수 있다.

- ‘보안 USB'라는 카테고리 하에서 SW방식의 타 업체들과의 경쟁에서 우위를 가져올 수 있다. 암호화 성능이나 안전성은 SW방식에 비해 HW가 우세하다.

(2) Login, 번들SW

- 로그인 모듈을 이용한 USB 위치 추적 기능 구현이 가능하다.

- USB 리셋 시, 사용자 데이터 추가 기능 지원으로 ‘보존이 되어야 하는’ 데이터의 보존 목적으로 쓸 수 있다.

- 비록 호스트 PC의 커널 드라이버 가 그 기반이긴 하지만, SecuDrive를 하드웨어 키로서 폴더에 대한 액세스 컨트롤, PC 상태 조정 등의 작업이 가능하다.

Threats______________________

(1) SecuDrive 제품

- 타 업체에서 속도가 빠른 하드웨어 차원의 USB를 출시한다면, 경쟁에서 밀릴 가능성이 있다.

- 로그인 기능 사용 유무와 암호화 칩 사용 유무가 분리되지 못하여, ‘기본 인증 절차’만 사용하려는 유저들의 선택이 제한되어있다. 일종의 보안 강도 설정인데 말이다.

(2) Login, 번들SW

- 비-SecuDrive 유저가 번들SW를 마음껏 활용할 수 있다.

마무리

처음 ZyRUS 제품을 받았을 때, 하드웨어 방식 보안 USB라 하여 신기하였다. 써본 USB중에선 이런 제품이 없었고, 국내 업체 중에서는 처음으로 양산한 제품이기 때문이다.

암호화가 별도의 칩이 아닌, 컨트롤러에서 이루어진다는 점은 흥미로웠다. 보드를 아무리 봐도 암호화 로직이 실행될만한 곳이 없고 여느 USB랑 똑같았기 때문이다.

다만, UFD 속도의 문제가 NAND가 아닌 컨트롤러에 있다면, SMI 등 유명 컨트롤러를 채용하고, 암호화를 수행하는 칩을 컨트롤러 <-> NAND 사이에 배치하는 것도 좋을 듯 하다. 하드웨어 방식이면서도 기존 USB의 장점을 그대로 가져가는 셈이니깐 말이다.

디자인          ★★★★★     안전성           ★★★★★

속도            ★★☆☆☆     번들SW         ★★★☆☆

Appendix A : 반도체에 새겨진 글자

잘 보이게 하기

위와 같이 반도체에 새겨지는 글자는, 레이저로 새겨지는지라

파여진다. 그렇지만, 사람이 보기에는 쉬운 일이 아니다.

손쉽게 할 수 있는 방법 중 좋은 방법이 있어 소개한다.

리뷰쓰다 생각해봤다.

(1) 수정액을 파인 글자 위에 바른다.

잘 보면, 파인 글씨가 있다.

(2) 이제 여기에 수정액을 칠하면

위에 파인 흔적이 살짝 보인다.

(3) 적당히 굳힌 뒤에

자 등을 이용해 살살살 긁어낸다. 약간의 흔적이 남기는 하지만,

잘 벗겨내면

(4) 완성

글씨를 쉽게 알아볼 수 있다.

Appendix B : 번들SW, 로컬에서

사용하자

SecuDrive의 번들 SW의 취약점을 알아보면서, 로컬에서 한번 사용해보자.

우선 각 프로그램의 실행 인자는 다음과 같다.

FileSync.exe BRAINZSQUARE-SH Start K: Utility 1042

FileCrypto.exe BRAINZSQUARE-SH Start K: 1 1042

FullEraser.exe BRAINZSQUARE-SH Start 1 1042

만약, SecuDrive 제품에서 실행되는지를 인증한다면, 실행이 되지 않아야 할 것이다.

실험을 한 컴퓨터에는 SecuDrive를 꽂지 않은 상태이다. K:도 존재하지 않는 문자이다.

정상적으로 실행된다.

이 경우 비-SecuDrive 유저가 번들SW를 너무나도 쉽게 사용할 수 있는 취약점이 있다.

번들SW 실행 시 SecuDrive의 드라이버 문자를 인자로 넣게 된다.

여기에 SecuDrive 검증 과정만 넣는다면, SecuDrive 일반모드에서도 번들SW를 사용하게 할 수 있다. 비록 보안영역은 아닐지라도, IOCTL에서는 같은 결과를 가져올 것이기 때문이다.