SHARE THE PERSPECTIVE
패킷 무결성, 메시지 최신성, 편집 기록은 서로 다른 세 가지 속성입니다. 하나를 다른 속성이 존재한다는 증거로 삼지 마세요.

메신저에는 편집이나 삭제 기능이 있을 수 있습니다. 하지만 인증 암호화를 사용하는 시스템에서 서버가 암호문을 몰래 바꾸고도 유효한 메시지로 전달할 수 있어서는 안 됩니다. 메신저의 메시지 무결성이란 수신자가 암호화 이후 데이터가 바뀌었음을 감지할 수 있다는 뜻입니다. 이는 전체 기록의 보존이나 대화의 법적 입증과는 다릅니다.

핵심 내용

  • 인증 암호화는 암호문 변조를 드러내지만 편집 및 삭제 기록을 반드시 보존하지는 않습니다.
  • Livara 기술 문서에 따르면 AES-256-GCM은 인증 태그와 함께 비공개 메시지를 보호하며, 변조된 패킷은 유효하게 복호화되어서는 안 됩니다.
  • 허가된 편집은 새로운 종단간 암호화 이벤트여야 하며, 서버가 이전 패킷을 몰래 덮어쓰는 것이어서는 안 됩니다.
  • 안전 번호는 상대방의 키를 확인하는 데 도움을 주지만, 상대의 정직함이나 스크린샷의 법적 효력을 판단하지는 않습니다.
  • 민감한 분쟁에서는 원본 파일, 시간, 편집 상태, 독립적인 증거를 대화 스레드 밖에도 보관하세요.

메신저의 메시지 무결성이란 정확히 무엇인가요?

메시지 무결성은 수신자가 암호화된 데이터의 무단 변경을 감지할 수 있다는 뜻입니다. 기밀성은 ‘누가 내용을 읽을 수 있는가’를 묻고, 무결성은 ‘발신자가 암호화했던 바로 그 데이터가 도착했는가’를 묻습니다. 종단간 암호화와 그 경계에 관한 설명에서 이 차이를 더 자세히 다룹니다.

화면에 두 개의 색상 상자와 자물쇠 아이콘이 있는 휴대전화 일러스트.

설명용 레이블을 넣은 개념 이미지이며, 실제 Livara 화면이나 변조 메시지 거부 테스트의 결과가 아닙니다.

Livara 기술 문서에 따르면 직접 메시지는 LVR1으로, 호환되는 비공개 그룹은 LGS1으로 종단간 암호화됩니다. Livara 보안 페이지에 따르면 호환되지 않는 기존 그룹은 E2EE 밖에 있음을 명확히 표시하며, 새 그룹은 모든 구성원이 준비되기 전까지 암호화된 그룹이라는 표시로 생성되지 않습니다. 해당 대화의 상태를 확인하세요. 문서는 LVR1이 메시지 키를 도출할 때 ECDH P-256과 ML-KEM-768을 사용한다고 설명합니다. 구성 요소가 표준이라는 사실은 전체 조합이나 제품에 대한 독립적인 승인이 아닙니다. 그다음 Livara는 AES-256-GCM으로 내용을 보호합니다.

제품 문서에 따르면 이 보호는 비공개 대화의 텍스트, 편집과 첨부 파일을 포함합니다. 하지만 Livara 채널은 종단간 암호화되지 않습니다. 서버는 악용 콘텐츠 삭제 등의 작업을 위해 의도적으로 내용을 읽을 수 있습니다. 그룹 구성원 관리도 서버가 통제합니다. 통화 보안과 녹음 모드 역시 텍스트 메시지와 별도로 살펴봐야 합니다.

암호화된 메시지의 변조 감지와 메신저의 AES-256-GCM

AES-GCM은 내용을 암호화할 뿐 아니라 인증 태그도 생성합니다. 암호문이나 인증된 데이터가 바뀌면 태그 검증이 실패해야 합니다. NIST SP 800-38D는 GCM 모드를 정의하며 같은 키로 nonce를 재사용하면 보안이 크게 약화될 수 있다고 경고합니다.

Livara 기술 사양에 따르면 비공개 메시지는 AES-256-GCM을 사용합니다. 서버가 보호된 패킷 일부를 바꾸면 메시지 키 없이 새로운 인증 태그를 만들 수 없으므로, 수신자는 그 패킷을 정상으로 받아들여서는 안 됩니다. ‘서버가 메시지를 바꿀 수 있나요?’라는 질문의 짧은 답은 이렇습니다. 서버는 데이터를 삭제하거나 보류하거나 차단하거나 늦게 전달할 수 있지만, 변조된 내용을 유효하게 보이도록 만들 수 있어서는 안 됩니다.

이 보장은 무제한이 아닙니다. 암호 기술은 기기의 악성코드, 열린 화면에 대한 공격자의 접근, 사용자의 허가된 편집을 무력화하지 못합니다. 내용의 무결성이 메타데이터를 반드시 숨기는 것도 아닙니다. 메신저 메타데이터와 그로 인해 드러나는 정보를 다룬 가이드에서 이 경계를 설명합니다.

서버의 메시지 변경과 편집은 다른 것인가요?

서버가 이전 암호화 패킷을 몰래 덮어쓸 수 있어서는 안 되지만, 발신자가 만든 편집 이벤트를 전달할 수는 있습니다. 메시지 편집의 보안은 서버가 저장된 텍스트를 직접 바꾸는 것이 아니라, 편집도 원래 메시지처럼 인증되고 종단간 암호화되는지에 달려 있습니다.

Livara 문서에 따르면 직접 채팅의 편집은 LVR1으로, 호환되는 비공개 그룹의 편집은 LGS1으로 보호됩니다. 인터페이스를 평가할 때 앱이 ‘편집됨’ 상태를 표시하는지 확인하세요. 다만 암호화만으로 이전 버전이 모든 기기에 영원히 보존되지는 않습니다.

‘모두에게서 삭제’ 역시 내용을 버려 달라는 요청이지 모든 사본이 파괴되었다는 증거가 아닙니다. 수신자는 이미 메시지나 알림을 읽었거나 파일을 저장했거나 스크린샷을 찍었을 수 있습니다. 사라지는 메시지는 보존을 줄이지만 모든 사본의 삭제를 보장하지 않습니다.

채팅 메시지 인증은 무엇을 증명하나요?

채팅 메시지 인증은 메시지가 세션 키로 만들어졌고 전송 중 변조되지 않았음을 보여 줍니다. 계정 소유자가 직접 기기를 들고 있었는지, 내용이 사실인지, 수신자가 나중에 제삼자에게 확정적으로 입증할 수 있는지는 증명하지 않습니다.

Livara 기술 문서는 안전 번호를 키 변경을 감지하는 방법으로 소개합니다. 두 사람은 독립된 경로로 키 지문을 비교할 수 있습니다. 안전 번호로 채팅을 검증하는 가이드에서 실제 절차를 설명합니다. 이 확인은 연락 상대의 키가 공격자의 키로 대체될 위험을 줄이지만 감염된 기기를 안전하게 만들지는 않습니다.

계정 인증도 별개의 문제입니다. 아무리 강력한 로그인 방식이라도 메시지 무결성, 상대 키 확인, 기기 보안을 대신할 수 없습니다.

내용 무결성은 메시지 순서 및 최신성과 다릅니다

오래된 패킷도 유효한 인증 태그를 가질 수 있습니다. 이를 다시 받아들이지 않으려면 프로토콜 설계, 카운터, 세션 식별자, 수신자 상태 유지가 필요합니다. AES-GCM만으로 전체 대화의 순서를 기록하는 장부가 되지는 않습니다. 이 차이는 재전송 공격, 늦게 도착한 메시지, 여러 기기의 동기화를 평가할 때 중요합니다.

실제로 어떤 데이터가 인증 태그의 보호를 받는지도 명확해야 합니다. 대화 식별자나 이벤트 유형이 인증된 맥락 밖에 있다면 본문만 보호하는 것으로 전체 문제가 해결되지 않습니다. 해당 버전의 코드 검토와 테스트가 이 연결 관계를 밝혀야 합니다.

메시지 내용이나 상태가 예상과 다를 때

앱 버전, 관찰 시간, 관련 기기, 편집 표시 유무를 기록하세요. 독립된 경로로 상대에게 허가된 편집을 했는지 확인하세요. 증거 없이 동기화 차이를 서버 변조로 단정하지 마세요. 그렇다고 인증 오류나 키 변경을 이유 없이 무시해서도 안 됩니다.

기술 보고에는 민감하지 않은 테스트 메시지를 사용하고 공개 보고서에 상대의 개인 데이터를 넣지 마세요. 대화를 법적 사안에 사용할 예정이라면 암호화나 스크린샷만으로 법적 효력이 결정되지는 않습니다. 증거를 변경하기 전에 자격을 갖춘 전문가의 도움을 받으세요.

메신저의 무결성 주장을 어떻게 평가하나요?

‘암호화됨’이라는 표현만으로 만족하지 말고 다음을 물어보세요.

  • 어떤 대화와 파일이 종단간 암호화되나요?
  • 서비스는 어떤 AEAD 알고리즘을 사용하나요?
  • 편집과 삭제는 어떻게 기록하고 표시하나요?
  • 사용자는 상대의 키 변경을 어떻게 감지하나요?
  • 서버가 통제하는 메타데이터, 내용 또는 구성원 정보는 무엇인가요?
  • 통화에도 메시지와 같은 보장이 있나요?
  • 프로토콜이 독립 감사를 받았나요?

Livara는 일부 주장을 확인할 수 있는 사양과 도구를 공개하며, Android 사용자는 앱을 오프라인으로 확인하는 Proof Lab에서 SHA-256으로 APK 파일의 체크섬을 비교할 수 있습니다. 다만 이 글은 현재 버전의 독립 감사에 대한 증거를 제시하지 않습니다. 사양과 테스트 벡터 공개는 검증에 도움이 되지만 독립 감사를 대신하지는 못합니다.

비공개 대화에 대한 Livara의 핵심 주장은 제한적이고 명확합니다. AES-256-GCM은 패킷 변조를 드러내야 하고 편집도 암호화되어야 한다는 것입니다. 이것은 불변의 기록, 모든 사본의 확실한 삭제 또는 자동적인 법적 증거를 의미하지 않습니다.

자주 묻는 질문

서버 관리자가 암호화된 메시지의 내용을 바꿀 수 있나요?

AES-256-GCM을 올바르게 사용하는 설계에서는 서버 관리자가 메시지 키 없이 암호문을 바꾸고 유효한 인증 태그를 만들 수 없습니다. 다만 패킷 삭제, 차단, 지연 전달은 여전히 가능합니다. 이 보장은 감염된 기기나 발신자의 허가된 편집을 포함하지 않습니다.

‘편집됨’ 표시는 이전 내용이 무엇인지 증명하나요?

아닙니다. 앱이 버전 기록까지 보관하지 않는 한 이 표시는 현재 표시된 내용이 전송 후 바뀌었다는 것만 알려 줍니다. 암호화는 편집 이벤트의 진위를 확인할 수 있지만 이전 텍스트를 자동으로 보존하지는 않습니다.

안전 번호는 모든 메시지의 진위를 보장하나요?

아닙니다. 안전 번호는 암호 키가 연락 상대의 것인지 확인하고 변경을 감지하는 데 도움이 됩니다. 전송 당시 누가 기기를 들고 있었는지, 메시지가 사실인지, 기기에 악성코드가 없는지는 알려 주지 않습니다.

모두에게서 삭제하면 모든 곳에서 메시지가 사라지나요?

아닙니다. 이 기능은 앱 안의 사본을 버릴 수 있지만 저장한 파일, 알림, 스크린샷, 이전 기록을 회수하지는 못합니다. 모두에게서 삭제는 보존을 줄일 뿐, 수신자 기기나 다른 시스템에서의 삭제를 보장하지 않습니다.

Livara의 보안 경계 확인
CONTINUE THE THREADPrivate messaging ↗
YOU’VE REACHED THE ENDBack to the reading room ↗