TLSNotary와 MPC-TLS의 역할과 데이터 흐름

Notary는 TLS 계산에 참여하지만 commitment에 담긴 평문과 서버 식별 정보를 직접 알지 않도록 설계됩니다.

온라인 복호화에서는 Prover와 Notary가 각자의 키 지분으로 record 인증과 복호화 연산을 함께 수행합니다. 지연 복호화에서는 연결이 인증되고 닫힌 뒤 Notary가 키 지분을 공개하고, Prover가 저장한 응답 암호문을 로컬에서 복호화합니다. 연결 중에는 어느 한쪽의 키 지분만으로 전체 세션 키를 얻을 수 없습니다.

Notarization 단계에서도 Notary는 평문을 받아 읽고 서명하지 않습니다. Prover가 만든 평문 commitment와 서버 식별 자료 commitment를 담은 Session Header에 서명합니다.

별도 Notary 없이 최종 Verifier가 Prover와 MPC-TLS를 수행하고 곧바로 공개 내용을 검사할 수 있습니다.

직접 방식에서는 세션 당시의 Verifier와 나중에 자료를 검사하는 Verifier가 같습니다. 일반 목적 Notary의 서명을 신뢰 목록과 대조하는 단계가 줄어듭니다.

대신 그 Verifier가 세션 시간에 온라인이어야 합니다. 제출 자료를 다른 서비스로 옮겨 쓰기도 본편의 notarization 흐름보다 어렵습니다.

2026-09-09 확인: alpha.13에서 notary-server/client가 제거됐으며 tlsn-attestation은 유지보수 대상으로 남았습니다. 본문은 Notarization 개념 모델로, 현재 SDK의 실행 절차가 아닙니다. 관련 릴리스는 글 끝 기술 출처에 정리했습니다.

아래는 기존 원고의 2026-08-25 확인 기록입니다. “최신”이라는 표현도 당시 시점을 뜻합니다.

2026-08-25 공식 문서는 TLS 1.2 지원을 명시하고 TLS 1.3은 로드맵으로 둡니다. 최신 GitHub 릴리스는 사전 릴리스(pre-release)인 v0.1.0-alpha.15입니다.

앞 글이 설명한 TLS 1.3 메시지 흐름과 이 글의 TLSNotary 실행 예시는 같은 버전이 아닙니다. 그래서 세션 ID도 trace_tlsn12_001로 구분했습니다.

알파 릴리스의 자료 형식과 API는 바뀔 수 있습니다. 본문은 참여자와 데이터 흐름처럼 안정적인 개념만 다루고, 릴리스와 지원 버전은 이 심화 설명과 참고문헌에 확인 날짜를 함께 남깁니다.

MPC 모드는 계산 자원을 미리 준비하므로 보내고 받을 데이터와 record의 최대치를 설정합니다.

한도는 애플리케이션 정책이 아니라 실행 자원 계획입니다. 응답이 예상보다 커지면 데이터가 거짓인 것이 아니라 준비한 세션 범위를 넘은 것입니다.

예제의 4 KiB 전송, 32 KiB 수신 값은 교육용 예시값입니다. 실제 배포 값은 대상 API 응답과 성능 측정을 보고 정합니다.

세부 암호식 대신 키 지분 준비, 암호화 요청 생성, 응답 인증과 복호화의 순서를 봅니다.

Prover가 Server와 실제 소켓을 유지합니다. Notary는 그 소켓으로 들어온 TLS 메시지에 필요한 암호 연산을 Prover와 공동으로 수행합니다.

둘 중 한쪽이 가진 키 지분만으로는 전체 세션 키를 얻지 못합니다. 키 지분 분리와 공동 record 인증은 Prover가 임의 응답을 끼워 넣는 일과 Notary가 평문을 읽는 일을 각각 제한합니다.

Proxy mode에서는 Verifier가 암호화된 TLS 트래픽을 전달하고, 이후 ZKP로 관찰한 트래픽이 정상 TLS 세션에서 나온 것인지 검증합니다.

Verifier는 Prover와 Server 사이의 네트워크 proxy로서 암호화된 패킷을 전달하고 기록합니다. 평문을 직접 읽지는 않지만 Server로 가는 경로에 놓입니다.

MPC-TLS보다 대역폭과 검증 지연을 줄이는 대신 Verifier에서 Server까지의 네트워크 경로가 올바르다는 가정이 추가됩니다. 공식 문서도 MPC-TLS를 기본 모드로 둡니다.

일반 목적 Notary가 어느 서비스에서 자료를 가져왔는지까지 알 필요가 없도록 서버 식별 정보(Server identity)도 commitment로 다룹니다.

은행 응답 본문을 숨겨도 접속한 도메인이 드러나면 민감한 서비스 이용 사실이 노출될 수 있습니다. TLSNotary의 notarization 흐름은 이 이름도 Notary에게 숨깁니다.

나중의 애플리케이션 Verifier에게는 서버 식별 정보와 이를 확인할 TLS 전용 자료(TLS-specific data)를 열어 출처를 검사하게 할 수 있습니다. 숨김 대상은 참여자마다 다릅니다.

평문 commitment와 TLS-specific data commitment, Notary 서명이 이후 presentation의 기준점이 됩니다.

Session Header는 HTTP header가 아니라 TLSNotary가 정의한 자료 구조 이름입니다. Prover가 저장했다가 나중에 애플리케이션 Verifier에게 presentation의 일부로 보냅니다.

Verifier는 허용한 Notary인지 확인하는 정책 검사와 Session Header 서명 검증을 따로 수행합니다. 이어서 opening과 TLS-specific data가 Session Header 안의 commitment에 맞는지 검사합니다.

정확한 잔액을 열지 않고 비교 결과만 보이려면 TLS 통신 기록의 출처와 판정 조건 계산을 연결하는 별도 회로나 검증 절차가 필요합니다.

ZKP의 비공개 입력에는 원문 응답의 잔액과 이를 출처 commitment에 연결하는 증인값(witness)이 들어갈 수 있습니다. 공개 입력에는 기준 금액, 통화, 잔액 유형(balance type), challenge 같은 맥락을 둘 수 있습니다.

이 글은 실제 회로나 증명을 실행하지 않습니다. UI에서 premiumEligible가 만들어지는 장면은 어떤 관계를 추가로 증명해야 하는지 설명하는 교육용 모델입니다.

허용한 Notary 정책, 서명, opening, 서버 식별 정보, JSON 해석, 판정 조건을 각각 다른 실패 원인으로 처리합니다.

Notary가 허용 목록에 있어도 서명이 틀리면 Session Header를 받아들이지 않습니다. 서명이 맞아도 opening이 commitment와 다르면 공개된 값은 세션에 묶이지 않습니다. opening이 맞아도 서버 식별 정보가 기대한 api.bank.example과 다르면 기대한 출처의 자료라고 확인할 수 없습니다.

암호 검사를 모두 통과한 뒤에야 HTTP와 JSON을 해석하고 premiumEligible를 서비스 정책에 넣습니다. 이 순서대로 결과를 기록하면 어느 검사에서 멈췄는지 알 수 있어, 오류를 한 덩어리의 “검증 실패”로 다루지 않아도 됩니다.

서명 계산, commitment 결합, 서버 식별 정보, 서비스 신뢰 목록이 서로 다른 검사임을 짧게 비교합니다.

Notary가 허용 목록 밖에 있어도 서명 계산 자체는 맞을 수 있습니다. 서명 검증과 별개로 premium.example이 그 운영자를 세션 검증자로 받아들이지 않는다는 정책 결정입니다.

commitment 불일치와 잘못된 서버 식별 정보는 제출 자료가 해당 세션·출처에 결합됐음을 확인할 수 없게 합니다. 같은 거절 화면을 보여 주더라도 내부 원인은 구분해서 기록해야 합니다.