개인 공간의 Access Key를 더 안전하게 만드는 방법

저희가 직접 Senvra를 사용하면서 계속 마주친 단순해 보이는 질문이 있었습니다. 개인 공간을 만든 뒤 그 Access Key를 어디에 보관해야 할까요?

같은 휴대폰에만 남겨 두면 복구 자격 증명으로서의 의미가 약해집니다. 반대로 평문 키를 이메일, 메모, 비밀번호 관리자 또는 다른 드라이브에 두면 나중에 찾을 수 있지만, 개인 공간을 열 수 있는 중요한 자격 증명이 존재하는 위치도 늘어납니다.

실제로 키가 필요할 때의 경험도 좋지 않습니다. 저장 위치를 찾고, 키를 복사하고, 현재 휴대폰으로 옮긴 뒤 Senvra에 붙여 넣어야 합니다. 이 과정은 평문이 클립보드와 다른 시스템을 거칠 기회를 늘리고, 원래 간단해야 할 복구 작업을 번거롭게 만듭니다.

이처럼 반복되는 실제 사용 문제 때문에 Access Key의 저장 및 사용 흐름을 다시 설계했습니다. 다가오는 Senvra 업데이트는 별도의 6자리 PIN으로 보호된 Access Key 사본과 QR 전송이라는 두 가지 선택 기능을 추가합니다. 6자리 PIN을 고엔트로피 비밀처럼 표현하는 것이 아니라, 원본 256-bit Access Key가 평문으로 나타나는 횟수를 줄이고 불필요한 클립보드 전달을 없애는 것이 목표입니다.

문제는 일상적인 보관과 전달에서 나타난다

Senvra 내부에서 각 개인 공간은 무작위 256-bit 마스터 키와 인증된 키 래퍼로 보호됩니다. 여기서 다루는 약점은 Space Access Key를 외부에 저장한 뒤 시작됩니다.

흐름도 다이어그램 준비 중

좌우로 밀어 전체 다이어그램 보기

다이어그램 원본 보기

flowchart TB
    accTitle: Responsive flowchart
    subgraph R1[" "]
        direction LR
        A[평문 Access Key] --> B[이메일, 메모 또는 드라이브] --> C[현재 휴대폰으로 가져오기]
    end
    C --> D[접근과 복구]
    C --> E[자격 증명 관리]
    D --> F[개인 공간 열기]
    D --> G[백업 생성 또는 복원]
    E --> H[비밀번호 재설정 또는 변경]
    E --> I[Access Key 교체]
    style R1 fill:transparent,stroke:transparent

따라서 Access Key는 비밀번호를 잊었을 때만 쓰는 예비 문자열이 아닙니다. 개인 공간 열기, 백업 생성 또는 복원, 비밀번호 재설정 또는 변경, Access Key 자체 교체에 사용되는 복구 및 핵심 관리 자격 증명입니다. 이렇게 중요한 역할을 하므로 저장과 전달 방식에도 별도의 보안 설계가 필요합니다.

이메일 초안은 동기화될 수 있고, 메모는 검색 색인에 들어갈 수 있으며, 클립보드 관리 앱은 기록을 보관할 수 있습니다. 이는 보관함 내부 암호화가 실패했다는 뜻이 아니라, 복구 자격 증명이 원래 경계를 떠나 여러 시스템을 평문으로 통과했다는 뜻입니다.

첫 번째 설계 요구사항은 명확했습니다. 원본 Access Key를 모든 외부 저장 위치에서 읽을 수 있는 상태로 두지 않고도 이동 가능한 사본을 보관할 수 있어야 했습니다.

선택 가능한 PIN 보호 사본

새 흐름에서는 Access Key 사본에 별도의 6자리 PIN을 추가할 수 있습니다. 원본 Access Key는 균일하게 무작위인 32바이트 값으로 유지됩니다. Senvra는 16바이트 무작위 salt를 만들고, PIN에 PBKDF2-HMAC-SHA256 600,000회 반복을 적용한 뒤, 용도가 분리된 HKDF-SHA256으로 32바이트 마스크를 생성합니다.

Access Key 바이트와 이 마스크를 XOR합니다. 이동용 envelope에는 마스킹된 버전 헤더와 0–24바이트의 무작위 padding도 포함되며, 사용자 정의 64문자 전송 알파벳으로 인코딩됩니다. 결과에는 이메일 주소, 공간 이름, 계정 식별자 또는 읽을 수 있는 “Senvra Access Key” 라벨이 포함되지 않습니다.

흐름도 다이어그램 준비 중

좌우로 밀어 전체 다이어그램 보기

다이어그램 원본 보기

flowchart TB
    accTitle: Responsive flowchart
    subgraph R1[" "]
        direction LR
        A[Access Key + 별도 PIN] --> B[PBKDF2<br/>600,000회] --> C[HKDF<br/>32바이트 마스크]
    end
    subgraph R2[" "]
        direction RL
        D[XOR + 무작위 envelope] --> E[보호 문자열 또는 QR] --> F[PIN이 후보 키 생성]
    end
    subgraph R3[" "]
        direction LR
        G[대상 개인 공간 래퍼] --> H{AES-GCM을 열 수 있는가} --> I[허용 또는 거부]
    end
    R1 --> R2
    R2 --> R3
    style R1 fill:transparent,stroke:transparent
    style R2 fill:transparent,stroke:transparent
    style R3 fill:transparent,stroke:transparent

사용자 정의 알파벳과 무작위 padding은 전송 난독화일 뿐 암호 강도의 근원이 아닙니다. 보호는 PIN에서 파생된 마스크에서 나옵니다. 그러나 6자리 PIN은 가능한 값이 백만 개뿐이므로, 이 기능은 일상적인 평문 노출을 줄이는 추가 장벽이지 고엔트로피 비밀의 대체품이 아닙니다.

왜 보호 사본은 곧바로 “PIN 오류”라고 말하지 않는가

가장 단순한 구현은 인증 암호화로 Access Key를 감싸고 인증 태그로 복호화 성공 여부를 알려 주는 것입니다. 편리하지만, 유출된 보호 문자열 자체가 PIN 확인 장치가 됩니다. 공격자는 후보를 시도할 때마다 정답인지 즉시 알 수 있습니다.

Senvra는 이 성질을 의도적으로 피합니다. 형식상 유효한 모든 6자리 PIN은 그럴듯한 32바이트 Access Key 후보를 만듭니다. 수정된 보호 문자열도 외형상 유효한 후보를 만들 수 있습니다. 외부 보호 계층만으로는 후보가 맞는지 알 수 없습니다.

판단은 올바른 문맥을 가진 유일한 위치인 대상 개인 공간에 맡깁니다. 후보 Access Key에서 해당 공간의 복구 래핑 키를 파생하고, 공간 ID에 바인딩된 AES-256-GCM 인증 마스터 키 래퍼를 열어 봅니다. 이 작업이 성공해야만 Access Key가 실제로 그 공간에 속한다는 사실을 알 수 있습니다.

보호 문자열만 유출되면 자체적으로 완결된 정답 PIN 신호가 없습니다.
잘못된 PIN은 외부 계층에서 유용한 인증 오류를 반환하지 않고 잘못된 후보 키를 만듭니다.
대상 공간의 인증된 마스터 키 래퍼를 열 수 없을 때 공간이 후보를 거부합니다.
공격자가 대상 보관함 메타데이터까지 확보하면 그 데이터가 검증 대상이 될 수 있습니다. 따라서 6자리 PIN은 별도로 보관하고 제한된 강도의 보호로 다뤄야 합니다.

비용은 높아지지만 무차별 대입이 불가능해지는 것은 아니다

PBKDF2 600,000회 반복은 PIN 후보 하나를 시도할 때마다 명확한 계산 비용을 부과합니다. 대상 공간의 검증 데이터도 있는 경우 6자리 PIN 백만 개를 모두 확인하려면 최대 백만 번의 전체 파생, 현재 설정으로 약 6,000억 회의 PBKDF2 반복이 필요합니다. 평문 저장이나 빠른 해시보다 공격 비용을 크게 높이지만, 수학적으로 무차별 대입이 불가능해지는 것은 아닙니다.

일반적인 사용에서는 Senvra 앱이 대상 개인 공간을 열면서 최종 검증을 수행합니다. 그러나 암호학적으로 필요한 것은 대상 공간의 인증된 래퍼 데이터이지 공식 앱에서만 실행할 수 있는 비밀 로직이 아닙니다. 보호 사본과 대상 보관함 메타데이터를 모두 확보한 사람은 동등한 오프라인 검증기를 구현할 수 있습니다. 보호 사본만 유출된 경우에는 그 문자열만으로 PIN 후보의 정답 여부를 확인할 수 없습니다. 따라서 보호 사본과 PIN을 서로 다른 곳에 보관해야 합니다.

짧은 PIN을 강력한 비밀번호라고 부르는 대신, 더 좁지만 정확한 보안 속성을 선택했습니다.

QR은 취급 단계를 줄이지만 키를 공개 정보로 만들지 않는다

다음 업데이트에서는 Access Key 사본을 QR 이미지로 표시하고 저장할 수 있습니다. 다른 기기에서 카메라로 스캔하거나 사용자가 선택한 이미지에서 읽어 Access Key 입력란을 로컬로 채울 수 있습니다.

이 방식은 복사와 붙여넣기 단계를 줄입니다. 보호된 QR 이미지를 원하는 저장소에 보관하고, 필요할 때 스캔한 뒤 별도로 보관한 PIN을 입력할 수 있습니다. 보호 문자열과 QR 이미지는 같은 자료를 담으므로 QR은 추가 암호화 계층이 아니라 전송 형식입니다.

QR 이미지를 스캔하거나 저장할 수 있는 사람은 그 내용을 복사할 수 있습니다. 평문 Access Key QR은 평문 키와 똑같이 보호해야 합니다. 더 안전한 흐름은 PIN으로 보호된 QR을 저장하고 6자리 PIN은 다른 곳에 보관하는 것입니다.

스캐너는 정규화된 평문 Access Key 또는 유효한 보호 envelope만 허용하고, 임의 URL과 관련 없는 QR을 거부합니다. 가져오는 이미지 크기를 제한하고, 앱이 활성 상태를 벗어나면 진행 중인 PIN 입력을 지웁니다.

기존 키를 교체할 필요는 없다

보호 사본은 Access Key의 저장 및 전송 표현을 바꿀 뿐, 개인 공간 자체의 Access Key를 회전시키지 않습니다. 기존 평문 키도 계속 호환됩니다.

다음 버전에서는 새 Access Key를 저장하기 전에 보호하고, Security → Password & Access Key에서 기존 평문 Access Key를 로컬로 변환하며, 결과를 문자열이나 QR 이미지로 보관할 수 있습니다. 나중에 스캔하거나 붙여 넣은 뒤 별도의 6자리 PIN을 입력해 사용할 수 있고, 필요할 때는 명시적으로 평문 표현으로 돌아갈 수도 있습니다.

변환 도구는 키를 다른 공간에 추가하지 않으며 업로드하지도 않습니다. 보호 사본을 만든 뒤 Senvra는 평문 키와 PIN을 도구의 임시 UI 상태에서 지웁니다.

실제 보안 사용 모델

이 기능은 노출 면적을 줄이기 위한 것이지 사용자의 보관 책임을 없애는 기능이 아닙니다.

보호 사본과 PIN은 서로 다른 곳에 보관하세요. 이메일, 사진 또는 메모 앱이 편리하다고 해서 자동으로 비공개 저장소가 되는 것은 아닙니다. 보호 사본이 작동하는지 확인한 뒤 기존 평문 사본을 삭제하고, 실제로 의존하기 전에 복구 테스트를 수행하세요. 사용 가능한 Access Key와 비밀번호를 모두 잃으면 개인 공간은 복구할 수 없습니다. Senvra에는 서버 측 복구 백도어가 없습니다.

더 넓은 키 모델은 Senvra가 비밀번호 변경 시 모든 파일을 다시 암호화하지 않는 이유에서 설명합니다.

다가오는 릴리스는 과거의 평문 전용 복구 흐름을 선택 가능한 방식으로 바꿉니다. 호환성이 필요하면 기존 형식을 사용하고, 평문 노출을 줄이는 것이 더 중요하면 별도의 PIN과 QR 전달을 사용할 수 있습니다.