전반에 적용되는 Signal Protocol 종단 간 암호화와 AES-256
Tosh Defence의 Sanket (Sanket.Chat)은 독립적인 감사를 거친 Signal의 공식 libsignal을 통해 Signal Protocol을 적용하여 모든 메시지, 반응 및 암호화된 일대다 전송을 종단 간 암호화합니다. 이때 PQXDH 키 합의와 SPQR을 적용한 Double Ratchet을 사용합니다. 파일, 통화 프레임, 통화 전송, 로컬 저장소 및 설치 환경에서 종료되는 모든 TLS 세션에는 AES-256을 사용하며, AES-128 대체 방식이나 호환 모드는 제공하지 않습니다.
AES-256을 적용할 수 없으면 작업을 수행하지 않는 것이 SANKET의 엔지니어링 정책이며, 코드로 강제됩니다. 설계된 방식 그대로 암호화를 수행할 수 없다면 보안 수준을 낮추는 대신 작업을 거부합니다.
메시지: 수정되지 않은 Signal Protocol
SANKET은 모든 메시지 암호화에 Signal 공식 libsignal 라이브러리의 동일한 릴리스를 iOS, Android, 데스크톱 및 서버에서 사용합니다. Signal Protocol을 재구현하거나 대체 메시지 암호를 사용하지 않습니다.
세션은 X3DH의 포스트 양자 확장인 PQXDH로 설정되며, X25519 키 합의와 카이버 키 캡슐화를 결합합니다. 이후 메시지는 Double Ratchet으로 암호화됩니다. 각 메시지 키에서 AES-256 키, HMAC-SHA256 키, 초기화 벡터를 도출하고, 메시지를 AES-256으로 암호화하고 HMAC-SHA256으로 인증한 뒤 사용한 키를 삭제합니다. 모든 세션에서 Signal의 희소 포스트 양자 래칫도 함께 작동합니다.
설계상 대체 방식 없음
libsignal 암호화를 수행할 수 없으면 클라이언트는 메시지 전송을 거부합니다. libsignal 신원 키를 게시하지 않는 기기에는 평문을 보내는 대신 전송을 건너뛰고, 기존 평문 표시자는 거부하며, 서버는 libsignal 형식을 따르지 않는 키 묶음을 거부합니다. 메시지 내용에는 평문 경로나 대체 암호화 경로가 없습니다.
공유 키가 없는 그룹
그룹 메시지는 각 수신자에게 개별 전송하는 방식으로 암호화됩니다. 발신 기기는 각 구성원의 신뢰할 수 있는 모든 기기에 대해, 각 기기 고유의 libsignal 세션을 통해 메시지를 별도로 암호화합니다. 구성원 변경 시 키를 다시 설정할 필요가 없으며, 제외된 구성원은 개별 전송 대상 목록에서 빠집니다.
암호화하기 전에 발신자는 각 수신자 계정의 자체 키로 서명된 기기 목록을 확인하고, 목록에 없는 기기에는 아무것도 보내지 않습니다.
파일 및 통화
첨부파일의 내용, 이름, 유형은 파일마다 생성한 임의의 256비트 키로 기기에서 AES-256-GCM 암호화되며, 해당 키는 libsignal 메시지 안에 포함되어 전송됩니다.
음성 및 영상은 두 겹으로 보호됩니다. 각 참가자의 프레임은 발신자별 키를 사용해 AES-256-GCM으로 종단 간 암호화됩니다. 이 키는 200밀리초마다 갱신되어 발신자마다 초당 5개의 새 프레임 키가 생성되며, 참가자가 입장하거나 퇴장할 때마다 새로운 무작위 키가 생성됩니다. 각 기기와 미디어 서버 사이에서는 SRTP가 AEAD_AES_256_GCM만 허용합니다. 미디어 서버는 복호화할 수 없는 암호화된 프레임을 전달하며, 이 설계에서는 서버 측 통화 녹음이 불가능합니다.
- 파일마다 AES-256-GCM 적용
- 발신자별 통화 키 사용, 대화방 공용 키 미사용
- 발신자당 초당 프레임 키 5개
- SRTP는 AES-256-GCM만 사용
전송 및 저장
모든 클라이언트 연결은 TLS_AES_256_GCM_SHA384를 사용하는 TLS 1.3을 사용하며, 플랫폼의 네트워크 스택에서 필요한 경우 ECDHE와 AES-256-GCM을 사용하는 TLS 1.2를 사용합니다. AES-128, ChaCha20, CBC 모드 암호 스위트 및 정적 RSA는 제외하며, 하이브리드 양자 내성 그룹 X25519MLKEM768을 우선 제안합니다. 승인된 모든 기기는 상호 인증 TLS를 통해 자체 클라이언트 인증서로 신원을 증명할 수도 있습니다.
기기에서는 로컬 데이터베이스를 AES-256으로 암호화하고 HMAC-SHA256으로 인증하며, 휴대전화에서는 프로토콜 저장소와 기기 비밀정보를 보안 엔클레이브, 스트롱박스 또는 신뢰 실행 환경의 하드웨어 기반 키로 암호화합니다.
기술적 근거
SANKET 백서에서 자세한 내용 확인
이 페이지의 모든 설명은 공개된 SANKET 기술 보안 및 아키텍처 백서에 상세히 수록되어 있으며, 등록 없이 무료로 읽을 수 있습니다.
SANKET은 Signal Protocol을 사용하나요?
예. SANKET는 모든 플랫폼에서 Signal의 공식 libsignal 라이브러리로 모든 메시지를 암호화하며, PQXDH 키 합의와 SPQR을 결합한 Double Ratchet을 사용합니다. 프로토콜을 자체적으로 재구현한 코드는 포함하지 않습니다.
SANKET은 AES-256으로 암호화된 메시징 서비스인가요?
예. 메시지는 libsignal 내부에서 HMAC-SHA256과 함께 AES-256-CBC를 사용합니다. 파일, 통화 프레임, 통화 전송, 로컬 저장소 및 TLS에는 AES-256-GCM을 사용합니다. AES-128로 대체하는 기능은 없습니다.
음성 및 영상 통화에 종단 간 암호화가 적용되나요?
예. 통화 프레임에는 libsignal을 통해 전달되는 발신자별 키로 AES-256-GCM 종단 간 암호화를 적용합니다. 발신자마다 초당 5개의 새 프레임 키가 생성되며, 이를 전달하는 SRTP는 AES-256-GCM만 허용합니다.
반응과 브로드캐스트는 암호화되나요?
예. 반응과 암호화된 일괄 전달 메시지는 libsignal 메시지이며 다른 모든 메시지처럼 종단간 암호화됩니다. 일괄 전달 메시지의 우선순위, 기한 및 만료 시점도 암호화 범위에 포함됩니다.
SANKET은 그룹에 발신자 키를 사용하나요?
아니요. SANKET은 각 구성원의 신뢰할 수 있는 기기마다 고유한 libsignal 세션을 통해 그룹 메시지를 별도로 암호화하므로 공유 그룹 키가 없습니다.
Sanket은 어떤 TLS 버전을 허용하나요?
TLS 1.3을 우선 사용하며, TLS_AES_256_GCM_SHA384만 허용합니다. TLS 1.2는 ECDHE와 AES-256-GCM을 사용하는 경우에만 허용합니다. TLS 1.2 미만은 허용하지 않으며, 하이브리드 양자내성 키 교환 방식인 X25519MLKEM768을 우선 제안합니다.
libsignal은 감사를 받았나요?
예. Sanket은 독립적인 보안 감사를 받은 Signal의 libsignal 라이브러리를 기반으로 구축되었으며, PQXDH 프로토콜은 정형 분석을 거쳤습니다.
당사 엔지니어와 함께 Sanket의 암호화 기술을 검토하세요
Tosh Defence는 보안 설계자와 평가위원회에 암호 설계를 계층별로 설명하며, 비밀유지계약에 따라 접근 제한판 백서를 제공합니다.