백업이 정말 작동해야 하는 날: Senvra가 개인 데이터를 되찾는 방법

백업이 정말 필요한 날은 대개 좋은 날이 아닙니다.

iPhone을 잃어버렸거나, 앱을 실수로 삭제했거나, 기기가 더 이상 켜지지 않을 수 있습니다. 그 순간에는 예전에 설정 화면에서 봤던 초록색 체크 표시가 별 의미가 없습니다. 중요한 것은 손에 있는 파일을 지금도 검증할 수 있는지, 그리고 실제로 데이터를 되찾을 수 있는지입니다.

그래서 백업만을 위한 설명이 따로 필요합니다. 개인 데이터에는 “백업 파일이 있다”는 사실만으로 충분하지 않습니다. Senvra를 떠난 뒤에도 비밀이 유지되어야 하고, 손상을 조용히 받아들이지 않아야 하며, 사고가 나기 전에 복구를 시험할 수 있어야 합니다.

복구에 필요한 것을 두 가지로 줄였습니다

Senvra 백업을 만든 뒤 보관해야 할 것은 다음 두 가지입니다.

1. 암호화된 .senvrabackup 파일
2. 그 파일을 위해 생성된 Backup Key

추가 Backup Password는 없습니다. 원래 공간을 열 때 사용한 비밀번호를 기억하고 있을 필요도 없습니다.

Backup Key는 UUID가 아니며 시간, 기기 모델, 공간 정보를 조합한 문자열도 아닙니다. 시스템의 안전한 난수 생성기로 만든 20개의 무작위 바이트, 즉 160비트 엔트로피를 가집니다. 화면에서 8자리 16진수 다섯 묶음으로 보여 주는 것은 읽고 대조하기 쉽게 하기 위해서일 뿐입니다.

새 백업을 만들 때마다 새 Backup Key가 생깁니다. 그 키는 해당 백업 하나만 담당합니다.

flowchart LR
    V[현재 공간] --> B[새 백업 생성]
    B --> F[암호화 파일<br/>.senvrabackup]
    B --> K[독립 Backup Key<br/>160비트 무작위 엔트로피]
    F --> R[복구]
    K --> R

이것은 이중 인증 백업이 아니며 Senvra도 그렇게 표현하지 않습니다. 강하고 예측 불가능한 암호학적 비밀 하나를 사용합니다. 경계는 명확합니다. 파일만으로는 열 수 없고, Key만으로는 데이터가 없습니다. 누군가 둘 다 얻으면 백업을 열 수 있습니다.

따라서 중요한 습관은 비밀번호를 하나 더 만드는 것이 아니라 파일과 Key를 서로 다른 곳에 보관하는 것입니다.

Backup Password를 없앤 이유

처음 떠올리기 쉬운 방식은 Backup Key에 Backup Password를 하나 더 요구하는 것입니다. 입력란이 하나 늘면 보안 계층도 하나 늘어난 것처럼 보입니다.

하지만 백업은 일상적인 로그인과 실패 방식이 다릅니다. 로그인은 다시 시도하거나 재설정할 수 있는 경우가 많습니다. 몇 년 뒤 비밀 하나를 잊은 오프라인 백업에는 도움을 요청할 서버가 없습니다. 비밀이 하나 늘어날 때마다 유일하게 남은 사본을 영원히 못 쓰게 될 경로도 하나 늘어납니다.

더 중요한 점은 무작위로 만든 160비트 Backup Key가 사람의 비밀번호가 아니라는 사실입니다. 사전 단어, 생일, 키보드 패턴이 없으며 사용자가 강한 비밀번호를 잘 만드는지에 의존하지 않습니다. 공격자가 마주하는 것은 익숙한 짧은 비밀번호 문제가 아니라 2^160 규모의 무작위 공간입니다.

그래서 의도적으로 선택했습니다. 복잡해 보이기 위한 사람용 비밀번호를 더하지 않고, 백업마다 강한 무작위 Key 하나를 사용해 복구에 필요한 비밀을 하나로 남겼습니다.

사용 흐름은 가벼워졌지만 보관 책임은 가벼워지지 않습니다. Senvra는 Backup Key의 복구 가능한 사본을 보관하지 않습니다. 사용자가 저장했다고 확인해야 백업 생성을 계속합니다. Key를 잃으면 Senvra도 그 파일을 열 수 없습니다.

Space Access Key와 Backup Key는 서로 다른 문을 엽니다

가장 혼동하기 쉽고 가장 중요한 차이입니다.

비공개 공간이 열려 있다고 해서 그 iPhone을 들고 있는 사람이 모든 내용을 내보낼 권한까지 가져서는 안 됩니다. 비공개 공간 백업을 만들기 전에 Senvra는 원래의 Space Access Key를 다시 요구하고, 현재 공간의 키가 맞는지 기기 안에서 확인합니다.

설정 화면은 이 작업을 위한 Backup Key도 별도로 생성하지만, 소유권 확인이 통과하기 전에는 어떤 백업 파일도 만들지 않습니다.

승인 후 Space Access Key의 역할은 끝납니다. 백업 암호화에 참여하지 않고, 파일에 기록되지 않으며, 나중에 복구할 때도 필요하지 않습니다. 파일 자체는 독립적으로 생성된 Backup Key가 보호합니다.

flowchart TB
    A[Space Access Key] --> O[기기 안에서 소유권 확인]
    K[독립 Backup Key 생성] --> C[백업 자격 증명 준비]
    O -->|승인| E[암호화 파일 생성 허용]
    C --> E
    E --> R[나중에 Backup Key만으로<br/>검증 또는 복구]
    A -. 파일에 저장하지 않음<br/>파일 암호화에 사용하지 않음 .-> E

이 분리에는 실제 이점이 있습니다.

• iPhone과 비공개 공간이 열려 있어도 올바른 Space Access Key 없이는 전체 내보내기를 할 수 없습니다.
• Backup Key가 유출되어도 현재 비공개 공간을 열거나 비밀번호를 재설정하는 자격 증명이 되지 않습니다.
• 나중에 Space Access Key를 교체해도 이미 올바르게 저장한 백업은 무효가 되지 않습니다.

Everyday 공간에는 소유권 재확인이 없지만, 각 백업은 여전히 독립 Backup Key를 받습니다.

Backup Key가 파일을 보호하는 방식

Backup Key는 원래의 무작위 20바이트로 해석됩니다. HKDF-SHA256이 이 값과 백업마다 새로 만든 32바이트 솔트를 사용해 256비트 래핑 키를 파생합니다.

Senvra는 새로운 무작위 256비트 Archive Key도 생성합니다. 실제 콘텐츠를 암호화하는 것은 Archive Key입니다. Backup Key에서 파생한 래핑 키는 키 검사값을 인증하고 Archive Key를 감쌉니다.

이 과정이 160비트를 “256비트 자격 증명 강도”로 바꾼다는 뜻은 아닙니다. 자격 증명의 강도는 원래 160비트 무작위 엔트로피가 상한입니다. 계층을 나눈 이유는 사용자 자격 증명, 아카이브 키, 콘텐츠 암호화가 각각 하나의 분명한 책임을 갖고 모든 백업이 새로운 무작위 문맥을 사용하도록 하기 위해서입니다.

파일 내부에는 AES-256-GCM 인증 암호화를 사용합니다. Manifest, 항목 메타데이터, 썸네일, 컬렉션, 태그, 콘텐츠는 모두 암호화 계층 안에 있습니다. 외부 Header에는 형식 버전, 생성 시각, 무작위 컨테이너 ID, 솔트, 기능 플래그처럼 파일을 안전하게 해석하는 데 필요한 최소 정보만 남습니다.

저장소 제공자는 파일이 존재한다는 사실, 대략적인 크기, .senvrabackup 확장자를 볼 수 있습니다. 콘텐츠 암호화는 안에 무엇이 있는지 보호할 수 있지만, 주변 파일 시스템에서 파일의 존재 자체를 지울 수는 없습니다.

큰 동영상을 먼저 평문 ZIP으로 만들지 않습니다

나중에 암호화할 평문 ZIP을 백업 도중 디스크에 남기고 싶지 않았습니다.

Senvra는 각 항목을 제한된 메모리 버퍼로 읽고 4 MiB 데이터 프레임으로 나눈 뒤, 무작위 Archive Key로 즉시 봉인합니다. 큰 동영상도 완전한 평문 백업 형태로 임시 폴더에 먼저 존재할 필요가 없습니다.

각 암호화 프레임은 형식 버전, 컨테이너 ID, 인증 대상 Header 문맥, 프레임 순서 번호, 프레임 유형에 묶입니다. 읽을 때는 각 항목의 바이트 수, 청크 수, SHA-256 콘텐츠 다이제스트뿐 아니라 전체 항목 수, 총 바이트 수, Manifest 다이제스트도 확인합니다.

청크 변경, 프레임 순서 교체, 파일 잘림, 프레임 유형 바꾸기, 끝에 예상하지 않은 데이터 추가는 모두 검증 실패로 이어집니다.

진행률 100%가 끝은 아닙니다

설계에서 특히 중요하게 본 부분입니다.

Senvra는 먼저 파일 보호가 적용된 pending 파일에 기록합니다. 암호화가 끝나도 바로 사용자에게 건네지 않습니다. 전체 컨테이너를 처음부터 다시 읽고 모든 암호화 프레임을 인증하며, 복호화된 Manifest가 쓰려고 했던 내용과 정확히 같은지 확인합니다. 이 단계를 통과해야 pending 파일을 완성된 백업으로 원자적으로 게시합니다.

그다음 사용자가 파일 앱이나 다른 위치에 저장합니다. 복사 과정도 실패할 수 있으므로 Senvra는 앱 안의 검증된 파일과 외부 사본의 Header, 바이트 수, 전체 파일 SHA-256을 비교합니다. 두 파일이 일치한 뒤에만 Security Center가 현재 백업으로 기록합니다.

sequenceDiagram
    participant D as 현재 데이터
    participant P as Pending 암호문
    participant F as 사용자가 저장한 파일
    participant S as Security Center

    D->>P: 프레임 단위로 읽고 즉시 암호화
    P->>P: 전체를 다시 읽어 인증
    P->>F: 사용자가 외부 사본 저장
    F->>S: Header, 크기, 전체 파일 다이제스트 비교
    S-->>D: 일치한 뒤에만 현재 백업으로 기록

“파일이 생성됨”과 “안전한 사본이 저장됨”은 다른 상태입니다. 하나의 초록색 체크 표시로 둘을 섞고 싶지 않았습니다.

복구 훈련은 Header만 보는 검사가 아닙니다

백업이 실패하는 이유는 만들지 않았기 때문만은 아닙니다. 가장 나쁜 날이 올 때까지 누구도 복구를 시도하지 않았기 때문일 수 있습니다.

Senvra는 아무 항목도 가져오지 않고 복구 훈련을 실행할 수 있습니다. 해당 Backup Key로 래핑된 Archive Key를 열고, Header를 인증하고, 모든 프레임을 읽고, Manifest와 항목 관계, 모든 콘텐츠 다이제스트, 아카이브 종료 표시를 확인하며 뒤에 추가 데이터가 있으면 거부합니다.

암호화된 Manifest에는 원본 콘텐츠 지문도 들어 있습니다. 이를 통해 Senvra는 두 상태를 구분합니다.

• 암호학적으로 유효하고 지금도 열 수 있는 이전 백업
• 유효하면서 현재 공간 콘텐츠와도 일치하는 최신 백업

둘 다 가치가 있을 수 있지만 같은 상태는 아닙니다. 두 번째만 현재 공간의 최신 복구 훈련으로 기록됩니다.

복구는 공간을 교체하지 않고 검증된 콘텐츠를 추가합니다

Senvra 복구는 “기기를 예전 스냅샷으로 되돌리기”보다 “검증된 콘텐츠를 이 공간으로 가져오기”에 가깝습니다.

백업은 같은 유형의 현재 공간에만 가져올 수 있습니다. 원본 공간 목록을 다시 만들지 않고, 비공개 공간이 몇 개 있었는지도 드러내지 않습니다. 현재 공간의 이름, 스킨, 비밀번호, Space Access Key, Face ID, 제스처 설정도 바꾸지 않습니다.

항목을 쓰기 전에 Senvra는 전체 백업을 검증합니다. 이후 각 항목은 파일 보호가 적용된 pending 디렉터리로 들어가며, 현재 공간에 속하는 새 항목 키로 다시 암호화되고, 다시 읽어 검증한 뒤 원자적으로 게시됩니다.

가져오기가 중단되어도 기존 콘텐츠는 손상되지 않습니다. 같은 백업을 다시 선택하면 완료된 원본 항목을 알아보고 중복 복사 없이 건너뜁니다.

클립보드에도 잠깐만 머뭅니다

긴 Key를 현실적으로 저장할 수 있도록 Space Access Key와 Backup Key를 임시 복사할 수 있습니다. 복사 내용은 이 기기에만 한정되어 Universal Clipboard로 전달되지 않으며 120초 뒤 만료됩니다.

그 2분 동안 다른 내용을 복사했다면 Senvra는 새 내용까지 지우지 않습니다. 해당 복사 작업의 Key가 여전히 남아 있을 때만 직접 정리합니다.

이 기능이 클립보드를 금고로 만드는 것은 아닙니다. 민감한 텍스트의 노출 시간을 줄이는 조치입니다. Key를 저장할 때는 클립보드나 키보드 입력을 업로드하는 타사 도구를 피해야 합니다.

실제로 지킬 수 있는 백업 습관

실용적인 방법은 단순합니다.

1. 백업 생성을 확정하기 전에 Backup Key를 신뢰할 수 있는 위치에 저장합니다.
2. Key를 파일명에 쓰거나 .senvrabackup 파일과 같은 채팅 메시지, 이메일, 암호화되지 않은 폴더에 함께 두지 않습니다.
3. 검증된 백업 파일을 서로 독립된 위치에 최소 두 개 보관합니다.
4. 중요한 콘텐츠 변경 후 새 백업을 만들고 외부 사본 확인까지 완료합니다.
5. 정기적으로 복구 훈련을 실행하고 새 사본이 검증되기 전에 마지막 정상 백업을 삭제하지 않습니다.

Senvra 자체는 네트워크 접근이 필요하지 않으며 사용자를 대신해 백업을 업로드하지 않습니다. 파일 앱에서 선택한 위치는 다른 제공자의 규칙에 따라 동기화될 수 있습니다.

선택적 Apple Recovery Copy도 Backup Key 없이는 열 수 없는 암호화 컨테이너입니다. Senvra는 사본을 검증하고 시스템 백업 경로에 포함될 수 있게 하지만, Apple 기기 백업의 존재, 보관 기간, 최종 복구 성공을 보장할 수는 없습니다.

마지막으로, 솔직한 경계

백업 파일이 있어도 Backup Key를 잃으면 Senvra도 복구할 수 없습니다.

Backup Key가 있어도 파일 사본을 모두 잃으면 복구할 데이터가 없습니다.

둘이 함께 유출되면 백업의 기밀성도 사라집니다. 이 설계는 잘못된 보관, 탈옥된 기기, 이미 타인의 통제 아래 있는 운영체제까지 해결한다고 가장하지 않습니다.

Senvra가 할 수 있는 것은 모든 단계를 검증 가능한 엔지니어링 사실로 만드는 것입니다. 비공개 공간을 내보내기 전에 소유권을 다시 확인하고, 백업마다 독립된 무작위 Key를 만들고, 평문 중간 파일을 남기지 않고, 모든 프레임을 인증하고, 완성된 결과를 다시 읽고, 외부 사본을 대조하고, 필요해지기 전에 복구를 연습하게 합니다.

이것이 “백업이 암호화되었습니다”라는 한 문장보다 더 중요하다고 생각합니다.

전체 보안 모델은 Senvra가 iPhone의 개인 데이터를 보호하는 방법과 Senvra 제품 가이드에서 확인할 수 있습니다.

참고 자료

• RFC 5869: HKDF
• NIST SP 800-38D: GCM 인증 암호화
• Apple Platform Security
• OWASP MASVS-STORAGE-1