암호 민첩성은 명확한 보안 약속을 유지하면서 프로토콜을 한 암호 스위트에서 다른 스위트로 옮길 수 있는 능력입니다. 메시징에서 이는 새로운 알고리즘 이름을 추가하는 것 이상의 의미를 갖습니다. 기존 클라이언트, 오프라인 수신자, 저장된 메시지, 연결된 기기가 모두 전환 과정에서 예측 가능하게 동작해야 합니다.
IETF의 RFC 7696은 알고리즘 민첩성을 식별자, 구현, 운영상의 변화가 얽힌 마이그레이션 문제로 설명합니다. 버전 번호는 무엇이 사용 중인지 식별하는 데 도움이 되지만, 그것만으로 마이그레이션이 안전해지는 것은 아닙니다.
혼동하기 쉬운 세 가지 버전
메신저에는 앱 버전, 통신 프로토콜 버전, 암호 스위트 식별자가 있을 수 있습니다. 이들은 서로 다른 질문에 답합니다.
| 식별자 | 검토자에게 알려 주는 것 | 입증하지 못하는 것 |
|---|---|---|
| 앱 릴리스 | 설치된 소프트웨어 빌드 | 모든 대화가 최신 프로토콜을 사용한다는 사실 |
| 프로토콜 버전 | 적용되는 메시지 형식과 상태 규칙 | 구현이 그 규칙을 올바르게 따른다는 사실 |
| 알고리즘 또는 스위트 식별자 | 선택된 암호 구성요소 | 협상을 다운그레이드할 수 없다는 사실 |
릴리스 노트는 이들의 관계를 명확히 밝혀야 합니다. 새로 만든 대화에만 새 방식이 적용되거나 이전에 연결된 구형 클라이언트 때문에 폴백이 발생한다면, “새 암호화가 출시되었다”는 표현은 모호합니다.
안전한 마이그레이션에서 명시해야 할 사항
구체적인 상황부터 생각해 봅시다. Alice는 오늘 업데이트했지만 Bob은 구형 휴대전화에서 오프라인 상태로 남아 있습니다. Alice가 메시지를 보내고 나중에 두 번째 기기를 추가합니다. 각 기기는 무엇을 수락하고, 저장하고, 표시해야 할까요?
검토 가능한 설계라면 적어도 다음 질문에 답해야 합니다.
- 각 당사자는 상대방이 지원하는 버전을 어떻게 알아내나요?
- 선택된 버전은 세션의 일부로 인증되나요?
- 양측에 공통으로 허용되는 버전이 없으면 어떻게 되나요?
- 악의적인 중계자가 기능 정보를 제거하여 더 약한 모드로 유도할 수 있나요?
- 이전 메시지를 계속 읽을 수 있나요? 어떤 이전 키가 여전히 필요한가요?
- 백업 복원이 낡은 프로토콜 상태를 되살리나요?
- 사용 중단이 예고된 알고리즘은 단순히 사용을 자제하도록 권고하는 것을 넘어 언제 비활성화되나요?
사용자가 의도하지 않은 모드로 조용히 전환하는 것보다 눈에 보이는 실패가 더 안전할 때가 많습니다. 다만 사람들이 문제를 우회하려고 보호되지 않는 채널로 옮기지 않도록 구체적인 실패 및 복구 동작을 문서화해야 합니다.
실용적인 업그레이드 테스트 매트릭스
보안 업그레이드는 새로 설치한 두 클라이언트 사이에서 채팅이 성공하는 것만으로 충분하지 않습니다. 민감하지 않은 데이터로 다음 사례를 테스트하세요.
| 테스트 | 기록할 증거 |
|---|---|
| 새 클라이언트에서 구형 클라이언트로 통신 | 선택된 프로토콜 또는 명확한 비호환 결과 |
| 업그레이드 중 수신자가 오프라인 | 재연결 후 전달 및 복호화 동작 |
| 이전에 연결된 구형 기기의 복귀 | 읽기, 전송 또는 예상치 못한 모드 강제가 가능한지 |
| 그룹에 호환되지 않는 구성원 추가 | 명시적인 그룹 정책과 사용자에게 보이는 상태 |
| 지원 중단 후 백업 복원 | 지원되지 않는 상태를 거부하는지, 마이그레이션하는지 |
| 버전 메타데이터 변조 | 알아차리지 못한 다운그레이드가 아니라 인증 실패가 발생하는지 |
이는 평가 기준이지, 특정 제품이 해당 테스트를 통과했다는 주장이 아닙니다. 이후의 회귀 문제와 문서 변경을 구분할 수 있도록 빌드 식별자와 관찰 결과를 보관하세요.
Livara의 프로토콜 이름을 이해하는 법
Livara는 보안 문서에서 직접 채팅에 LVR1, 비공개 그룹에 LGS1이라는 이름을 사용합니다. 이 이름은 각 역할을 구분하기 위한 것이며, 독립적인 표준화나 감사를 거쳤다는 증거로 해석해서는 안 됩니다. 해당 페이지는 암호화 모드의 전제 조건을 충족하지 못하는 클라이언트나 그룹의 동작도 설명합니다.
다음으로 유용한 증거는 버전이 명시된 사양, 테스트 벡터, 호환성 규칙, 특정 릴리스와 연결된 검토 결과입니다. Proof Lab은 시연 범위가 더 좁다는 점을 명확히 밝힙니다. 브라우저에서 암호 프리미티브를 실행하는 것은 앱의 모든 마이그레이션 경로를 테스트하는 것과 다릅니다.
암호화 업그레이드 중 사용자가 해야 할 일
지원되는 클라이언트를 최신 상태로 유지하고, 기기 호환성에 관한 보안 공지를 읽으며, 신원 또는 암호화 상태 표시의 변화에 주의하세요. 앱 아이콘이 새로 바뀌었다고 해서 모든 기존 그룹과 백업에 새로운 보호가 적용되었다고 가정하지 마세요. 어떤 데이터의 보호가 달라졌는지 제품 측이 설명하지 못한다면 민감한 자료를 공유하기 전에 문의하세요.
좋은 암호 민첩성은 변화를 점검할 수 있게 합니다. 무엇이 바뀌었는지, 통신 당사자가 어떻게 합의하는지, 무엇이 잘못될 수 있는지, 기존 메커니즘이 언제부터 허용되지 않는지를 명확히 합니다.
