암호학적 신원 복구, 계정 재로그인, 채팅 기록 복원은 서로 다른 세 가지 작업입니다. Livara 보안 문서에 따르면 v7 형식은 암호학적 신원을 복구하는 데 사용됩니다. 이 형식 자체가 채팅 기록을 복원하지는 않습니다.
또한 이 아키텍처를 “클라우드 백업이 전혀 없다”고 설명해서는 안 됩니다. 현재 문서에는 신원 자료가 기기에서 암호화된 뒤 암호화된 백업으로 업로드된다고 나옵니다. 중요한 차이는 읽을 수 있는 키를 서버에 저장하는 것과, 열려면 복구 키가 필요한 암호화된 사본을 저장하는 것 사이에 있습니다.
같은 열쇠로 열리지 않는 세 개의 문
| 작업 | 목적 | 왜 이것만으로 부족한가요? |
|---|---|---|
| 계정 로그인 | 서비스 계정에 접근할 권한을 입증 | 이전 메시지의 복호화 키를 반드시 제공하지는 않음 |
| 신원 복구 | 암호학적 신원 자료에 다시 접근 | 모든 메시지의 존재나 복원을 그 자체로 입증하지는 않음 |
| 기록 복원 | 필요한 메시지와 첨부 파일을 되돌림 | 키 외에도 데이터 자체와 지원되는 복원 방식이 필요 |
이 구분은 로그인 비밀번호만 알면 모든 대화를 되돌릴 수 있다고 생각해 이전 휴대전화를 지우는, 큰 손실을 부르는 실수를 예방합니다.
v7 문서는 정확히 무엇을 말하나요?
Livara 보안 페이지는 P-256 키 합의 및 서명 키와 ML-KEM 시드가 무작위 256비트 복구 키로 기기에서 암호화된다고 설명합니다. v7 형식 설명에서는 알고리즘 모음, 신원 에포크, 세대도 인증됩니다. 이는 공급자의 문서이며, 그 자체가 구현에 대한 독립 감사인 것은 아닙니다.
Livara 위협 모델은 키 백업을 열려면 복구 문구가 필요하다고 명시합니다. 이 설명만으로 문구를 키로 변환하는 정확한 알고리즘이나 모든 키의 직접 재구성을 추측해서는 안 됩니다. 실제 세부 절차는 앱 버전 및 해당 버전의 안내와 일치하는지 확인해야 합니다.
파생 함수가 약한 문구를 강하게 만들지 못하는 이유는?
함수의 출력 길이는 입력을 추측하기 어려운 정도와 같지 않습니다. RFC 5869는 HKDF가 기존 엔트로피를 집중시키지만 증가시키지는 않는다고 명시합니다. 따라서 임의의 문구를 HKDF에 통과시키면 자동으로 완전한 256비트 보안 강도를 얻는다고 주장할 수 없습니다.
앱의 공식 절차에서 생성된 문구를 임의로 줄이거나 고쳐 쓰거나 추측하기 쉬운 문장으로 바꾸지 마세요. 누구에게도, 지원 봇이나 알 수 없는 양식에도 보내지 마세요.
휴대전화를 교체하거나 초기화하기 전에
- 앱에서 무엇이 백업되었는지 확인하세요. 신원인지, 기록인지, 아니면 별도 방식으로 둘 다 백업했는지 확인해야 합니다.
- 복구 문구는 해당 휴대전화와 독립된 안전한 장소에 보관하세요. 다른 사람이 접근하는 것을 심각한 위험으로 여기세요.
- 현재 버전의 복구 안내를 읽으세요. “로그인 성공” 메시지만 보고 완전히 복구되었다고 판단하지 마세요.
- 복구 테스트 방법이 지원된다면 먼저 민감하지 않은 데이터로, 유일하게 남아 있는 사본을 지우지 않고 시험하세요.
- 이전 후 필요한 대화와 파일을 확인하고, 그다음 이전 기기를 처분할지 결정하세요.
복구 문구가 없다면 어떻게 하나요?
아직 승인된 기기를 가지고 있다면 해당 앱에 있는 공식 경로만 확인하세요. 버전을 확인하지 않은 채 새 백업을 만들 수 있다고 가정해서는 안 됩니다. 기기와 문구를 모두 잃었다면 Livara 문서는 키 복구를 약속하지 않습니다. “복호화 보장” 서비스가 이러한 한계를 대신 해결해 준다고 생각하지 마세요.
계정 이전 계획은 “어떤 데이터가, 어떤 키로, 어떤 백업에서 복원되는가?”라는 질문에서 시작하세요. 다시 로그인하면 모든 채팅이 돌아온다고 가정해서는 안 됩니다.
