메신저 서버가 해킹되었다고 해서 반드시 모든 메시지를 읽을 수 있는 것은 아닙니다. 결과는 저장된 데이터, 키의 위치, 공격자의 접근 권한에 따라 달라집니다. 채팅 본문에 종단 간 암호화가 올바르게 적용되어 있어도 계정 정보, 시각, 그룹 구성원 정보, 전달 경로는 민감할 수 있습니다.
사고를 평가할 때는 먼저 공격자가 무엇을 확보했는지 물어야 합니다. 데이터베이스 사본, 인프라 키, 가동 중인 서버, 소프트웨어 배포 시스템 중 무엇인가요? 이 시나리오들의 결과는 같지 않습니다.
데이터베이스 탈취와 서버 장악은 다르다
과거 데이터베이스 사본만 가진 공격자는 그 안에 기록된 데이터로 접근 범위가 제한됩니다. 운영 중인 서비스를 장악하면 새로운 데이터 기록, 세션 탈취, 응답 변경, 상대방 키 교체 시도가 가능할 수 있습니다. 소프트웨어 배포 체계 접근은 또 다른 위험입니다. 엔드포인트의 악성 코드는 암호화 전이나 복호화 후의 본문을 볼 수 있습니다.
따라서 “데이터베이스에는 메시지 본문 키가 없다”는 주장은 중요하지만, 모든 침해 유형에 대한 완전한 답은 아닙니다.
다섯 가지 아키텍처 패턴 비교
이는 설명을 위한 패턴이지, 다섯 제품의 순위가 아닙니다. 하나의 서비스가 기능별로 여러 패턴을 사용할 수도 있습니다.
| 패턴 | 데이터베이스에서 접근 가능한 데이터 | 중요한 경계 |
|---|---|---|
| 평문 메시지와 비밀번호 | 콘텐츠와 자격 증명을 바로 읽을 수 있음 | 두 종류 데이터 모두 적절한 보호가 없음 |
| 해시된 비밀번호와 평문 메시지 | 콘텐츠를 읽을 수 있고 비밀번호 추측을 시험할 수 있을 수 있음 | 비밀번호 저장 방식의 품질이 채팅 본문을 보호하지는 않음 |
| 서버 키로 암호화한 콘텐츠 | 암호문이며, 읽기 가능 여부는 키 접근에 달림 | 키와 데이터의 실질적인 분리가 중요 |
| E2EE 채팅과 제공자가 접근 가능한 백업 | 실시간 채팅은 보호될 수 있지만 기록 사본에는 별도 노출 경로가 있음 | 백업 정책과 키를 확인해야 함 |
| E2EE 채팅과 독립 키를 사용하는 암호화 복구 | 암호문과 운영 데이터이며, 콘텐츠 보호는 설계와 키 보호에 달림 | 기기, 복구 문구, 상대방 인증이 여전히 중요 |
서버 디스크 암호화는 디스크 자체를 도난당했을 때 유용합니다. 공격자가 가동 중인 서비스나 복호화 키까지 확보했다면 같은 보호를 가정해서는 안 됩니다. E2EE는 중간 서비스가 보호된 콘텐츠를 읽는 데 필요한 키를 갖지 않는 것을 목표로 합니다.
메타데이터는 무엇을 보여 줄까?
메타데이터는 어떤 계정들이 통신했는지, 언제 활동했는지, 어느 그룹에 속하는지, 얼마나 많은 데이터를 전송했는지 보여 줄 수 있습니다. 메시지 본문은 아니지만 관계망이나 활동 패턴을 파악하는 데 가치가 있습니다.
Livara 보안 페이지는 라우팅, 구성원 정보, 시각, 암호문 크기, 전달 상태를 포함한 운영 데이터의 저장과 처리를 명시적으로 설명합니다. 비공개 콘텐츠의 기밀성을 완전한 익명성이나 서버에 어떤 데이터도 없다는 뜻으로 해석해서는 안 됩니다.
SRP가 계정 데이터의 추측 공격 위험을 없애지는 않는다
SRP는 비밀번호 자체를 직접 보내지 않고도 그것을 알고 있음을 증명하는 방식입니다. 서버에는 여전히 verifier라는 검증 데이터가 저장됩니다. RFC 5054의 보안 절은 verifier 탈취가 비밀번호를 추측하는 사전 공격을 가능하게 할 수 있다고 설명합니다.
따라서 “비밀번호를 네트워크로 보내지 않는다”와 “탈취할 비밀번호 관련 데이터가 없다”는 다릅니다. 고유하고 강력한 비밀번호, 기기 보호, 적절한 사고 대응이 여전히 필요합니다. SRP는 콘텐츠 암호화나 로그인 세션 보호도 대신하지 못합니다.
Livara는 어떤 경계를 공개했을까?
Livara 보안 문서는 다이렉트 메시지에 LVR1을, 보호된 그룹에 LGS1을 설명합니다. 그룹 보호는 실제 상태에 달려 있으며, 호환되지 않는 기존 그룹에는 E2EE 표시를 붙여서는 안 됩니다. 공개 채널은 이러한 기밀성의 경계 밖에 있습니다.
같은 문서는 v7 복구를 업로드 전에 보호되는 암호화된 신원 패키지로 소개합니다. 이 과정은 채팅 기록이 아니라 암호학적 신원을 복구합니다. 복구 문구가 노출되거나 키를 보유한 기기가 침해되는 것은 데이터베이스만 탈취되는 상황과 다릅니다.
이는 제품이 공개한 설명이지, 이 글에서 수행한 독립 감사의 결과가 아닙니다. AES나 ML-KEM을 언급하는 것만으로 올바른 키 관리와 앱 구현이 입증되는 것도 아닙니다.
사고 발표 시 무엇을 물어야 할까?
- 어떤 기간과 시스템이 영향을 받았나요? “사용자 정보”라는 모호한 표현만으로는 부족합니다.
- 평문, 파일, 키, verifier, 로그인 세션에 접근할 수 있었나요, 아니면 암호문뿐이었나요?
- 공격자가 서비스나 사용자에게 배포되는 소프트웨어를 변경할 수 있었나요?
- 세션 로그아웃, 비밀번호 변경, 업데이트, 상대방 신원 확인 등 공식 경로로 어떤 조치를 해야 하나요?
- 권장 복구 조치가 로컬 기록을 없앨 수 있나요? 앱을 삭제하기 전에 제한 사항을 읽으세요.
알 수 없는 메시지의 “긴급 계정 확인” 링크를 사용하지 마세요. 공식 주소를 독립적으로 열어 공지를 확인하세요. Livara 위협 모델은 일반적인 경계를 이해하는 데 유용하지만, 실제 사고의 범위는 해당 사고의 증거로 밝혀야 합니다.
