숨겨진 암호화 금고를 품은 오픈소스 USB 드라이브

“평범한 8GB USB”처럼 보이는 숨김 저장장치

• Phantomdrive는 처음 꽂으면 그냥 8GB USB 드라이브처럼 보이는 오픈소스 하드웨어 프로젝트임

  • 운영체제는 디스크의 나머지 영역을 감지할 방법이 없다고 설명함
  • 사용자가 평문 파일에 password:PUTYOURPASSWORDHERE 같은 내용을 쓰면, 장치가 스스로 언마운트했다가 두 번째 숨김 영역으로 다시 마운트됨
  • 숨김 영역은 AES-256으로 제자리 암복호화되는 구조임

• 목표는 “암호화된 볼륨이 있다는 사실” 자체를 덜 드러내는 것에 가까움

  • 작성자는 VeraCrypt hidden volume이 어떤 상황에서는 유용하지만, 암호화 매체를 갖고 있다는 이유만으로 의심받는 상황에는 부족하다고 봄
  • 그래서 Phantomdrive는 아예 OS가 나머지 저장공간을 못 보게 하는 방향을 택함

• 하드웨어와 펌웨어, 기구 설계까지 전부 오픈소스로 공개했다고 함

  • 설계 도구도 오픈소스 도구를 사용했다고 밝힘
  • 핵심 칩은 WCH의 CH569이고, 흔한 저가 Arduino 클론에서 보이는 CH340 USB-시리얼 칩을 만든 회사의 칩이라고 소개함

설계는 단순하지만, 보안 타협점도 꽤 노골적임

• 저장장치는 eMMC 대신 SD 카드를 선택함

  • AI 수요 때문에 eMMC 메모리 가격이 unusually high 상태라 SD 카드를 골랐다고 함
  • 누군가 장치를 뜯으면 SD 카드를 찾을 수 있지만, 데이터는 암호화돼 있다는 전제
  • 케이스는 epoxy로 붙여서 내부에 접근하려면 장치를 파괴해야 한다고 함
  • eMMC 가격이 내려가면 eMMC 버전도 만들 계획이라고 밝힘

• 부품 구성은 비교적 간단함

  • CH569, USB 포트, buck 전원 2개, 펌웨어 업데이트용 버튼, SD 카드, 보조 부품들로 구성됨
  • 펌웨어 개발을 돕기 위한 UART 테스트 포인트도 있음

암호화는 KDF, salt, AES 모드 선택까지 직접 설명함

• 작성자는 GitHub 이슈와 Reddit 반응에서 한 번 얻어맞은 이야기도 숨기지 않음

  • AI가 생성한 것으로 보이는 GitHub 이슈들이 열렸는데, 이미 패치된 문제, 환각, 작은 문제를 과장한 내용이 섞여 있었다고 함
  • 다만 AES-XTS 관련 지적은 예외적으로 의미 있었다고 인정함
  • 암호화 동작은 OpenSSL의 AES 구현과 대조하는 functional test로 확인했다고 설명함

• KDF 설명은 “최악의 방식”부터 시작함

  • 비밀번호 뒤에 0을 붙여 32바이트 AES-256 키를 만드는 방식은 password1234 같은 약한 비밀번호면 몇 분 안에 brute force될 수 있다고 함
  • 기기마다 고유한 salt를 넣으면 사전 계산 테이블 공격을 기기별 계산 문제로 바꿀 수 있음
  • Phantomdrive는 여기에 SHA-256을 100,000회 반복해서 공격 비용을 더 올림
  • 이 설정에서 잠금 해제는 약 3초 걸리고, 5초를 넘기지 않는 선에서 현재 장치의 compute limit에 가깝다고 봄

• Argon2 같은 memory-hard 알고리즘은 쓰지 못했다고 함

  • 장치 메모리 제약 때문에 선택지에서 빠짐
  • 더 높은 보안이 필요하면 SHA-256 반복 횟수를 늘리거나, 다른 장치를 쓰거나, 소프트웨어 암호화를 한 번 더 얹는 방식을 제안함
  • 아예 장치 암호화를 끄고 소프트웨어 기반 암호화만 쓰는 것도 가능하다고 함

AES-CTR과 AES-XTS 사이의 선택이 이 글의 핵심 기술 논점임

• AES-ECB는 왜 안 되는지도 짚고 넘어감

  • 같은 평문 블록이 같은 암호문 블록으로 나오기 때문에 패턴이 남음
  • 공격자가 암호문 일부를 제거했을 때 복호화된 평문이 예측 가능한 방식으로 바뀔 수 있음

• AES-CTR은 빠르지만 counter reuse 문제가 있음

  • 공격자가 한 번 암호문을 얻고, 사용자가 새 데이터를 쓴 뒤 다시 암호문을 얻는 시나리오를 제시함
  • 한쪽 평문을 추측할 수 있으면 다른 쪽 정보도 복구될 수 있다는 설명
  • 그래도 작성자는 자기 용도에서는 AES-XTS의 보안상 이득보다 속도 손실이 더 크다고 판단함

• AES-XTS는 디스크 암호화 표준으로 소개됨

  • 두 개의 키를 사용하고, sector 번호에서 tweak key를 만들어 각 16바이트 블록에 적용함
  • 식으로는 T_n = AES(K_2, S), C_n = AES(K_1, (P_n xor T_n)) xor T_n 형태로 설명함
  • counter reuse 문제는 해결하지만, 이 장치에서는 읽기·쓰기 성능이 꽤 내려감

펌웨어는 파일시스템을 모른 채 raw write를 감시함

• Phantomdrive는 파일시스템을 이해하는 장치가 아님

  • USB WRITE10/READ10 명령을 받아 SD 카드 CMDx 명령으로 옮기는 식으로 동작한다고 함
  • 잠금 해제를 위해 locked 상태에서 모든 write 전에 raw data를 훑고 password: 문자열을 찾음

• 이 구조는 단순하지만 오탐 가능성이 있음

  • 안전하지 않은 평문 영역에 많은 데이터를 넣다가 우연히 password: 문자열이 들어가면 의도치 않은 매칭이 생길 수 있음
  • 작성자는 요구사항에 맞지 않으면 직접 바꾸거나 다른 장치를 보라고 말함

• 펌웨어는 외부 프로젝트 두 개를 기반으로 함

  • 칩용 BSP 라이브러리로 wch-ch56x-lib를 사용함
  • ISP 프로그래밍 라이브러리로 wch-ch56x-isp를 사용함

---

기술 맥락

• Phantomdrive의 핵심 선택은 “암호화된 파티션을 숨기는 소프트웨어”가 아니라 “운영체제에 애초에 나머지 디스크를 안 보여주는 USB 장치”를 만드는 거예요. 그래서 보안 경계가 PC의 파일시스템이나 OS 도구가 아니라 USB 펌웨어와 저장장치 매핑 쪽으로 내려가요.

• SD 카드를 쓴 이유는 보안적으로 가장 단단해서가 아니라, eMMC 가격이 AI 수요 때문에 올라간 현실적인 제약 때문이에요. 대신 케이스를 epoxy로 붙여 물리 접근을 어렵게 하고, SD 카드가 발견돼도 내용은 암호화돼 있다는 전제로 설계를 맞춘 거예요.

• KDF에서 Argon2를 못 쓰고 SHA-256 100,000회 반복을 고른 것도 같은 맥락이에요. 메모리 여유가 큰 서버가 아니라 작은 USB 장치라 memory-hard 알고리즘을 감당하기 어렵고, 잠금 해제 시간이 약 3초를 넘기지 않는 선에서 계산 비용을 올린 선택이에요.

• AES-CTR과 AES-XTS의 비교는 속도와 디스크 암호화 안전성 사이의 트레이드오프예요. AES-XTS가 디스크 암호화 표준에 더 가깝지만 이 장치에서는 쓰기 6MB/s, 읽기 10MB/s로 느려지고, AES-CTR은 쓰기 9MB/s, 읽기 20MB/s로 빠른 대신 counter reuse 같은 설계 리스크를 더 신경 써야 해요.

• password: 문자열을 raw write에서 감시하는 방식은 구현을 단순하게 만들어요. 파일시스템을 파싱하지 않아도 되니까 펌웨어 부담은 줄지만, 반대로 평문 영역 데이터에 우연히 같은 문자열이 들어가는 상황까지 완전히 구분하진 못해요.