보안 아키텍처: 전체 기술 스택

Vaultaire는 금고 인덱스, 래핑된 키, 파일 헤더, 콘텐츠, 썸네일, 메타데이터 전반의 인증 암호화에 AES-256-GCM을 사용합니다. PBKDF2-HMAC-SHA512는 패턴과 기기 전체 Keychain 솔트에서 로컬 금고 키를 파생합니다. 이 금고 키는 별도의 무작위 256비트 마스터 키를 래핑하며, 파일 암호화는 앱 프로세스 안에서 CryptoKit으로 이루어집니다.

암호화 스택

Vaultaire는 각각 특정 역할을 위해 고른 여러 암호화 메커니즘을 함께 사용합니다. PBKDF2는 사람이 입력하는 자격 증명을 금고 키나 복구 키로 바꿉니다. AES-256-GCM은 인덱스, 래퍼, 메타데이터, 썸네일, 파일 콘텐츠를 보호합니다. 무작위 마스터 키는 오래 유지되는 파일 암호화를 바꿀 수 있는 패턴과 분리합니다. Keychain과 iOS 데이터 보호는 기기가 잠겨 있는 동안 기기에 묶인 솔트와 복구 기록을 보호합니다. 공급자가 보유한 복호화 키가 없으므로 개발자는 평소에 금고의 일반 텍스트에 접근할 수 없습니다.

복잡함을 위한 복잡함이 아닙니다. 각 계층은 서로 다른 공격 표면을 다룹니다. AES-256-GCM 기밀성과 인증을 결합하므로 수정된 암호문은 검증에 실패합니다. PBKDF2 패턴이나 문구 하나를 시험하는 데 드는 비용을 높입니다. 무작위 마스터 키 덕분에 패턴을 바꿔도 모든 파일을 다시 암호화하지 않고 키 하나만 다시 래핑하면 됩니다. Keychain 데이터 보호 로컬 솔트와 복구 레코드를 보호하지만, 대칭 암호화가 프로세스 메모리에서 이루어진다는 점은 앱이 계속 인정합니다.

이러한 계층은 함께 심층 방어 아키텍처를 형성하지만 모두 독립적인 장벽은 아닙니다. 추측한 패턴은 인덱스 파일 이름과 AES-GCM 인증으로 확인할 수 있고, 잠금 해제된 상태에서 침해된 기기는 앱 프로세스 안의 키나 일반 텍스트를 관찰할 수 있습니다. 따라서 이 아키텍처는 AES 자체의 강도뿐 아니라 자격 증명 엔트로피, PBKDF2 비용, iOS 기기 보호, 올바른 인증 암호화 처리에도 달려 있습니다.

AES-256-GCM: 파일 암호화

Vaultaire에 저장된 모든 사진, 동영상, 문서는 256비트 키를 쓰는 고급 암호화 표준인 AES-256-GCM으로 암호화됩니다 갈루아/카운터 모드. Vaultaire는 금고 인덱스, 파일 헤더, 썸네일, 키 봉투에도 AES-GCM을 사용합니다. 알고리즘과 키 크기는 표준화되어 있지만, Vaultaire의 보안은 여전히 nonce 처리, 키 관리, 자격 증명 강도, 구현의 정확성에 달려 있습니다.

AES-256의 “256”는 키 길이(비트)를 나타냅니다. 256비트 키에는 2개의 키가 있습니다.²⁵⁶ 가능한 값입니다. 그 숫자를 관점에서 보면 대략 10개가 있습니다. 관측 가능한 우주의⁸⁰ 원자. 모든 원자가 빅뱅 이후 실행되는 초당 10억 개의 키를 테스트하는 슈퍼컴퓨터라면, 그들은 키 공간의 1% 미만을 탐색했을 것입니다.AES-256 업로드 전는 무차별 대입 공격을 받지 않습니다. 오늘은 아닙니다. 금세기는 아닙니다. 별이 다 타버리기 전에는 안돼.

GCM 모드가 중요한 이유

AES는 블록 암호, 로, 128비트 청크로 데이터를 암호화합니다. “mode”는 해당 청크가 결합되는 방식을 결정합니다. GCM(Galois/Counter 모드)은 CBC와 같은 단순한 모드가 제공하지 않는 두 가지 기능, 즉 병렬 암호화와 내장 인증을 제공합니다.

인증 부분이 중요합니다. GCM은 암호화된 모든 파일에 대해 암호화 태그를 생성합니다. 이 태그는 변조 봉인 역할을 합니다. 악의적인 행위자나 손상된 디스크 섹터, 에 의해 암호문의 단 한 비트라도 수정되면 인증 태그가 일치하지 않고 해독이 실패합니다. 손상된 데이터가 발생하지 않습니다. 뭔가 잘못되었다는 분명한 신호를 받습니다. 이 속성을 인증된 암호화라고 하며, 공격자가 암호화된 데이터를 수정하여 해독된 출력을 조작하는 전체 종류의 공격을 방지합니다.

PBKDF2: 키 파생

Vaultaire는 작업마다 다른 키를 파생합니다. 패턴과 기기 전체 Keychain 솔트를 PBKDF2-HMAC-SHA512에 넣어 600,000회 반복하면 로컬 금고 키가 만들어집니다. 결정적인 패턴 파생으로 별도의 클라우드 백업 키를 만듭니다. 정규화된 복구 문구는 PBKDF2를 800,000회 반복해 복구 봉투용 키를 만듭니다. 출력이 256비트라는 이유만으로 사람의 자격 증명이 256비트 엔트로피가 되지는 않습니다.

PBKDF2가 패턴을 보호하는 방법

PBKDF2의 핵심 아이디어는 의도적인 작업량입니다. 직렬화된 패턴이나 정규화된 문구를 HMAC-SHA512에 수십만 번 반복해 통과시킵니다. 정당한 사용자는 잠금 해제나 복구를 시도할 때 이 비용을 한 번 치릅니다. 공격자는 후보마다 이 비용을 치르지만, 실제 추측 속도는 병렬 하드웨어와 구현 선택에 따라 정해집니다.

Vaultaire는 패턴 파생 키에 PBKDF2 600,000회 반복을 설정합니다. 이 설정은 추측마다 비용을 높이지만, 책임 있는 공격 추정이라면 측정된 후보당 시간과 하드웨어 가정을 밝혀야 합니다. 후보당 정확히 1ms라면 연속 추측 1,000,000,000회에 몇 년이 아니라 약 11.6일이 걸립니다. 256비트 결과는 예측 가능한 패턴의 엔트로피를 늘리지 않습니다.

로컬 패턴 파생은 기기마다 무작위 솔트 하나를 쓰며, 이 솔트는 ThisDeviceOnly Keychain 항목에 암호화되어 저장됩니다. 솔트는 비밀이 아니며 그 기기의 모든 금고가 함께 씁니다. 이 방식은 한 기기용으로 만든 테이블을 솔트가 다른 기기에 그대로 적용하지 못하게 하지만, 같은 기기의 금고마다 공격자가 처음부터 다시 시작하도록 강제하지는 않습니다.

AES-256-GCM: 메타데이터 보호

파일 내용을 암호화하는 것만으로는 충분하지 않습니다. 파일 이름, 생성 날짜, 썸네일 크기 및 저장소 구조는 모두, 메타데이터이며 메타데이터는 데이터 자체만큼 드러날 수 있습니다. “tax-return-2025.pdf”라는 파일은 내용이 암호화되어 있어도 공격자에게 내부 내용을 정확하게 알려줍니다. 금고를 사용한 시간이 타임스탬프에 표시됩니다. 썸네일 크기를 보면 사진인지 동영상인지 알 수 있습니다.

Vaultaire는 이 메타데이터를 ChaCha20이 아닌 AES-256-GCM으로 보호합니다. 파일 이름과 MIME 유형은 암호화된 파일 헤더에 들어갑니다. 암호화된 금고 인덱스에는 파일 레코드, 날짜, 크기 정보, 저장소 배치, 래핑된 마스터 키가 들어 있습니다. 썸네일 데이터도 임의의 마스터 키로 암호화됩니다.

메타데이터에 인증된 암호화를 쓰는 이유는 무엇입니까?

메타데이터에는 기밀성과 무결성이 모두 필요합니다. AES-GCM은 암호화된 값마다 인증 태그를 만들어, Vaultaire가 공격자가 조작한 일반 텍스트를 받아들이지 않고 수정된 헤더, 인덱스, 썸네일, 봉투를 거부할 수 있게 합니다. 이 설계는 구현에 없는 암호 다양성을 내세우지 않고, 이런 저장 형식 전반에 인증된 암호화 구성 하나를 의도적으로 사용합니다.

같은 암호를 쓴다고 해서 같은 키나 nonce를 무작정 재사용한다는 뜻은 아닙니다. 금고 키는 인덱스를 보호하고 무작위 마스터 키를 래핑하며, 마스터 키는 파일 자료를 보호합니다. CryptoKit은 새 nonce로 인증된 봉인 상자(sealed box)를 만들고, Vaultaire의 스트리밍 형식은 순서가 정해진 청크마다 고유한 nonce를 파생합니다. 관련 보장은 두 번째 메타데이터 암호가 아니라 키 분리, nonce 규칙, 인증에서 나옵니다.

영지식 아키텍처

다음은 보안 앱에 대해 물어볼 가치가 있는 질문입니다. 해당 앱을 배후에 있는 회사가 해킹당하거나 소환장을 받거나 단순히 악의적인 것으로 변하면 어떻게 될까요?

대부분의 앱에서는 대답이 불편합니다. 그들은 귀하의 데이터, 키 또는 둘 다를 보유합니다. 법원 명령에 따라 문서를 넘겨야 합니다. 데이터 침해로 인해 노출됩니다. 불량 직원이 액세스합니다. 앱’의 보안은 회사’의 운영 보안, 만큼 강력하며 기록에 따르면 회사는 정기적으로 침해를 당합니다.

Vaultaire는 사용자의 패턴, 복구 문구, 복호화 키, 읽을 수 있는 금고 콘텐츠를 받는 계정이나 저장 서비스를 운영하지 않습니다. 암호화와 복호화는 기기의 앱 프로세스에서 이루어집니다. iCloud 백업이 켜져 있으면 앱은 인증된 암호문을 Vaultaire가 제어하는 금고 서비스가 아닌 사용자의 비공개 CloudKit 데이터베이스로 보냅니다.

실제로 영지식의 의미

수사 기관이 금고의 일반 텍스트를 요구하는 영장을 Vaultaire에 보내더라도, 회사는 이를 해독하는 데 필요한 패턴, 복구 문구, 금고 키, 백업 키, 마스터 키를 보유하지 않습니다. 암호화된 iCloud 레코드는 사용자의 CloudKit 개인 데이터베이스에 있습니다. 다만 기기에서는 복구 자료가 암호화된 Keychain 데이터베이스에 보관되며, CryptoKit이 열린 금고를 암호화하거나 해독하는 동안 대칭 키가 앱 메모리에 있습니다.

이 공급자 경계는 클라이언트 환경의 모든 부분이 신뢰 모델 외부에 있다는 약속이 아니라 아키텍처 속성입니다. Vaultaire는 일상적인 금고 복구를 위해 넘겨줄 수 있는 서버 측 복호화 키를 보유하지 않습니다. 배포된 앱, iOS, 잠금 해제된 기기, 암호화 구현은 여전히 읽을 수 있는 데이터를 처리할 수 있으므로 그만큼 신뢰할 수 있어야 합니다.

Keychain 및 앱 프로세스 경계

Apple의 Secure Enclave는 지원되는 개인 키를 보호하고 플랫폼 보안 아키텍처의 일부를 맡을 수 있지만, 공개 API로는 PBKDF2에서 파생한 임의의 대칭 키를 넣어 Vaultaire의 AES-GCM 파일 작업을 그 보조 프로세서 안에서 수행할 수 없습니다. 따라서 Vaultaire는 금고 암호화를 Secure Enclave AES라고 설명하지 않습니다.

Vaultaire는 무작위 기기 솔트, 암호화된 복구 데이터베이스, 그리고 이 데이터베이스를 보호하는 무작위 키를 일반 iOS Keychain에 일반 비밀번호 항목으로 저장합니다. 이 항목들은 WhenUnlockedThisDeviceOnly 접근성 클래스를 사용합니다. Keychain과 데이터 보호는 특히 전화기가 잠겨 있을 때 의미 있는 기기 경계를 만들지만, 이 구조는 내보낼 수 없는 Secure Enclave 키와는 다릅니다.

패턴을 그리면 CommonCrypto가 앱 프로세스에서 금고 키를 파생합니다. 그런 다음 CryptoKit과 Vaultaire의 CryptoEngine이 해당 프로세스에서 대칭 키 바이트를 사용하여 인덱스를 인증 및 해독하고, 마스터 키를 풀고, 파일을 처리합니다. 앱이 잠기면 활성 상태가 지워지지만 충분한 권한으로 잠금 해제된 세션을 관찰하는 공격자에게는 잠긴 기기의 암호문만 가진 검사관과는 다른 기회가 있습니다.

탈옥되었거나 손상된 운영 체제는 패턴 입력, 앱 메모리, 복호화된 미리 보기, 내보내기, 화면을 노릴 수 있습니다. Vaultaire는 설계가 iOS 프로세스 격리, Keychain, 데이터 보호에 기대고 있으므로 탈옥하지 않은 최신 iPhone을 권장합니다. 루트 권한이 탈취되어도 열린 금고의 대칭 키에 접근할 수 없다고 주장하지는 않습니다.

파일별 초기화 벡터

동일한 키로 두 개의 동일한 파일을 암호화하면 순진한 구현으로 동일한 암호문이 생성됩니다. 이것은 문제입니다. 두 개의 동일한 암호화된 blob을 본 공격자는 이를 해독하지 않고도 두 개의 원본 파일이 동일하다는 것을, 알 수 있습니다. 사진이 가득한 금고에서 이런 패턴 분석을 하면 암호화를 통해서도 정보를 드러낼 수 있다.

Vaultaire는 AES-256-GCM 봉인 작업마다 새로운 암호화 논스를 생성해 결정적 암호문을 피합니다. 파일 헤더와 파일 콘텐츠는 따로 봉인되며, 대용량 파일은 무작위 기본 논스와 순서가 매겨진 청크마다 고유한 논스를 쓰는 인증 스트리밍 형식을 사용합니다. 그래서 같은 사진의 두 사본이 같은 암호화 결과를 만들지 않습니다.

nonce는 암호문과 함께 저장되며 비밀이 아닙니다. 보안상 요구되는 것은 같은 키에서 nonce가 고유해야 한다는 점입니다. Vaultaire는 단일 암호화에 Apple의 암호학적 난수 생성기로 96비트 nonce를 생성하고, 스트리밍 헤더에는 기본 nonce를 기록합니다. 충돌 위험은 하나의 키로 수행하는 암호화 횟수에 따라 달라지므로, 구현은 매번 새 값을 생성하며 96비트 크기를 수명 전체에 걸친 고정된 2⁹⁶분의 1 보장으로 제시하지 않습니다.

메모리 관리: 활성 키 상태 지우기

보안 소프트웨어의 일반적인 오류는 더 이상 필요하지 않은 중요한 데이터를 메모리에 남겨 두는 것입니다. 암호화 키, 파생된 비밀번호, 해독된 데이터는 앱이 사용을 마친 후에도 오랫동안 RAM에 남아 있을 수 있습니다. 포렌식 도구는 콜드 부팅 공격 또는 메모리 덤프 분석으로 알려진 기술을 사용하여 장치 메모리를 덤프하고 이러한 잔재, 를 검색할 수 있습니다.

Vaultaire는 활성 키 상태와 복호화된 UI 데이터가 남아 있는 시간을 제한합니다. 앱이 잠기거나 세션이 끊기면 코드가 여러 정리 경로를 거칩니다.

• 활성 금고 상태가 삭제됩니다. 앱은 현재 금고 키 세션을 지우고, 금고 콘텐츠를 보여 주기 전에 다시 잠금 해제를 요구합니다.
• 키 래퍼는 소유된 버퍼를 지웁니다. Vaultaire의 보안 바이트 컨테이너는 해제될 때 자신이 소유한 버퍼를 덮어씁니다.
• 캐시된 마스터 키 상태가 무효화되었습니다. 열린 인덱스를 위해 보관된 해독된 마스터 키는 관련 잠금 및 캐시 초기화 경로에서 삭제됩니다.
• Vaultaire가 제어하는 범위에서 복호화된 UI 캐시를 지웁니다. 썸네일과 미리보기 정리는 앱에 남는 상태를 줄여 주지만, Swift, iOS, 다른 프로세스가 만든 모든 사본을 통제한다고 주장하지는 않습니다.

다음에 Vaultaire가 잠긴 상태로 열리면, 패턴을 그렸을 때 앱이 금고 키를 다시 파생한 뒤 인덱스를 인증하고 마스터 키를 풉니다. 이것은 세션 정리일 뿐, 모든 임시 메모리 사본이 확실한 다중 패스 삭제를 거쳤다거나 Secure Enclave 키 참조가 파기되었다는 주장이 아닙니다. 충돌 시 iOS가 프로세스를 회수하지만, 갑작스러운 종료마다 정리 코드가 실행될 수는 없습니다.