검증된 내보내기

검증된 내보내기란

검증된 내보내기(인증된 내보내기라고도 해요)는 대화 하나, 또는 아카이브 전체를 .zip 하나로 묶어요. 나 아닌 다른 사람이 기록을 믿어야 할 때를 위한 거예요. 스크린샷과 다른 점은 변경 여부를 확인할 수 있고 독립적으로 검증할 수 있다는 거예요. 받은 사람은 표준 도구로 패키지가 바뀌지 않았고 특정 시점에 그대로 존재했다는 걸 확인할 수 있어요. 그 어느 것에도 Text2Store를 믿을 필요가 없어요.

Text2Store 구매에 포함돼 있어요. 만들려면 대화를 열고 내보내기를 고른 다음 검증된 내보내기(.zip)…를 고르세요.

인증된 백업에서 내보내면 더 강해져요. 내보내기의 증명이 내보낸 시점만이 아니라 백업을 만든 시점까지 거슬러 올라가요. 이 부분은 인증된 백업 페이지를 참고하세요.

패키지 안에 든 것

.zip을 풀면 스스로 설명이 되는 작은 파일 묶음이 나와요.

• transcript.pdf: 읽고 인쇄할 수 있는 기록으로서의 메시지.
• conversation.json: 같은 메시지를 데이터로. PDF가 표현하지 못하는 것까지 포함해요.
• attachments/: 대화의 모든 사진, 동영상, 파일을 원래 바이트 그대로.
• certificate.pdf: 사람이 읽는 표지. 기기, 대화, 기간, 개수, 검증 방법.
• manifest.json: 핵심 파일. 다른 모든 파일의 SHA-256 지문.
• VERIFY.txt: 모든 걸 직접 확인할 수 있는 쉬운 영어 명령어 목록.
• DECLARATION.txt: 사람이 서명할 수 있는 작성용 선언서(아래 참고).
• manifest.json.tsr: 온라인일 때 붙는 신뢰할 수 있는 타임스탬프.
• tsa/cacert.pem: 타임스탬프 기관의 인증서. 패키지만으로 시간을 검증할 수 있어요.
• source/backup-timestamp.tsr: 인증된 백업에서 내보낸 경우에만 들어 있어요. 백업 자체의 생성 시 타임스탬프를 이어받아, 내보내기의 증명이 백업을 만든 시점까지 거슬러 올라가게 해요.

증명하는 것

• 무결성. 모든 파일이 SHA-256 지문과 함께 manifest.json에 올라 있어요. 어떤 파일이든 지문을 다시 계산하면 내보냈을 때와 바이트 단위로 같다는 게 확인돼요. 사진 하나의 픽셀 하나만 바꿔도 검증은 실패해요.
• 백업에서 온 출처. 첨부 파일마다 가져온 기기 백업에서의 지문도 기록돼 있어서, 내보낸 파일을 손으로 입력한 무언가가 아니라 그 특정 백업과 연결해요. 첨부 파일 중 하나라도 더 이상 맞지 않으면 내보내기를 거부해요.
• 시간. 온라인일 때는 독립적인 타임스탬프 기관이 RFC 3161 표준(코드 서명 타임스탬프와 같은 방식)으로 패키지 전체에 타임스탬프를 붙여요. 그러면 패키지가 특정 시점에 바뀌지 않은 채 존재했다는 게 증명되고, "지난주에 고쳤잖아"라는 말에 답할 수 있어요.

왜 변경이 빠져나갈 수 없나

"변경 여부를 확인할 수 있다"는 엄밀한 주장이라, 왜 성립하는지 설명할게요. 파일을 고칠 수 없다는 뜻이 아니에요. 어떤 파일이든 고칠 수는 있어요. 어떤 수정이든 드러난다는 뜻이에요. 검증을 몰래 통과시키려는 사람은 세 개의 벽에 차례로 부딪혀요.

• 지문은 위조할 수 없어요. 각 파일의 SHA-256 지문은 그 바이트 그대로에서 계산한 64자 값이에요. 어디든 한 바이트만 바꿔도 지문이 완전히 달라져요. SHA-256을 유지한 채 파일을 바꾸는 방법은 알려진 게 없으니, 바뀐 파일은 기록된 지문과 더 이상 맞지 않아요. 이게 첫 번째 벽이에요.
• 목록에도 지문이 있어요. 다음으로 떠올릴 방법은 manifest.json 안의 지문을 바뀐 파일에 맞게 고치는 거예요. 그것도 실패해요. 매니페스트는 자기 목록에 대한 콘텐츠 루트 지문을 갖고 있고, 신뢰할 수 있는 타임스탬프는 매니페스트 전체에 대해 찍혀 있어요. 목록을 고치면 둘 다 깨져요. 두 번째 벽이에요.
• 타임스탬프에는 아무도 갖지 못한 키가 필요해요. 마지막 방법은 매니페스트를 다시 만들고, 고친 버전에 새 타임스탬프를 받는 거예요. 그러려면 타임스탬프 기관의 서명용 개인 키가 있어야 하는데, 그건 독립적인 제3자(DigiCert)가 갖고 있어요. 나도, Text2Store도, 공격자도 그 키 없이는 유효한 타임스탬프를 만들 수 없어요. 그래서 Text2Store 검증은 유효한 신뢰할 수 있는 타임스탬프가 있을 때만 검증됨이라고 알려 줘요. 타임스탬프는 그 아래의 모든 걸 다시 쓰고 다시 봉인하는 걸 불가능하게 만드는 기준점이거든요. 신뢰할 수 있는 타임스탬프가 없는 패키지는 바로 그 기준점이 없어서 검증됨이 아니라 검증되지 않음으로 표시돼요. 세 번째 벽이에요.
• 저희를 믿을 필요가 없어요. 이 모든 확인은 공개 표준(SHA-256, RFC 3161)을 쓰고, Mac과 Windows에 기본으로 있는 표준 도구로 재현할 수 있어요. 보안은 Text2Store의 말을, 심지어 Text2Store 앱을 믿는 데 기대지 않아요.

정직한 한계는 분명히 말해 둘 만해요. 이건 변경 여부를 확인할 수 있게 하는 것이지, 변경을 막는 게 아니에요. 누구든 여전히 파일을 바꾸거나 지울 수 있어요. 할 수 없는 건, 바꾼 뒤에도 검증을 통과하게 하는 거예요. 패키지가 검증을 통과하면 내보낸 그 파일이에요. 손을 댔다면 검증이 그렇다고 알려 줘요.

증명하지 않는 것(꼭 읽어 주세요)

한계에 대해 솔직한 것도 나머지를 믿을 수 있게 하는 요소예요. 검증된 내보내기는 다음을 증명하지 않아요.

• 메시지 내용이 사실이라는 것, 또는 백업 전에 휴대폰이 조작되지 않았다는 것. 증명하는 건 내보낸 뒤로 패키지가 바뀌지 않았다는 것이지, 그 전에 무슨 일이 있었는지가 아니에요.
• 어떻게 받아들여질지. Text2Store는 검증된 내보내기가 특정 수신자나 절차에서 받아들여진다고 절대 주장하지 않고, "법정에서 증거로 인정된다"거나 "인증되었다"고 표현하지도 않아요. 기록이 얼마나 무게를 갖는지는 늘 받는 쪽이 정하고, 소프트웨어는 기록을 확인 가능하게 만들 수 있을 뿐이에요.
• 완전성. 검증된 내보내기에는 아카이브할 때 휴대폰에 아직 있던 것만 담을 수 있어요. 가져오기 전에 삭제된 메시지는 그냥 없어요. 기기에서 삭제, 편집, 전송 취소된 메시지는 그 정보가 가져올 때까지 남아 있었다면 기록에 표시돼요.
• 각 메시지를 보낸 정확한 시각(절대적인 의미로). 신뢰할 수 있는 타임스탬프가 증명하는 건 내보낸 파일이 언제 존재했는지이지, 메시지를 언제 보냈는지가 아니에요. 메시지 시각은 기기에서 가져와요.

암호로 보호하기(선택)

검증된 내보내기는 일반 .zip이라, 파일을 가진 사람은 누구나 메시지를 읽을 수 있어요. 소프트웨어 없이 어디서든 열리니 보통은 그게 원하는 바예요. 하지만 파일을 보내야 할 때는 잠글 수 있어요. 내보내기를 만들 때 이 .zip을 암호로 보호를 체크하면 내용이 AES-256으로 암호화돼요. 기본으로 꺼져 있고, 내보내기마다 고를 수 있어요.

암호화와 변경 확인은 별개예요. 암호는 다른 사람이 메시지를 읽는 걸 막아요. 아무것도 바뀌지 않았다는 걸 증명하는 건 지문과 타임스탬프이고, 둘 다 어느 경우에나 똑같이 작동해요. 암호를 건다고 검증이 더 잘 되는 것도, 안 건다고 덜 되는 것도 아니에요.

안에 든 건 모두 암호화돼요. VERIFY.txt도 포함이라, 보호된 내보내기는 암호 없이는 아무것도 드러내지 않아요. 숨길 수 없는 게 하나 있어요. zip은 파일 이름 목록을 절대 암호화하지 않아서, 패키지에 기록, 매니페스트, 몇몇 첨부 파일이 있다는 건 누구나 볼 수 있어요. 이름은 일반적인 것이라, 누구와 이야기했는지나 무슨 말을 했는지는 전혀 알 수 없어요.

보호된 내보내기를 Text2Store에서 검증하려면 평소처럼 고르세요. 앱이 잠겨 있다는 걸 알아채고 암호를 물어봐요. 직접 검증하려면 위 도구 중 하나로 먼저 푼 다음, 아래의 일반 단계를 따르세요.

저희를 믿지 않고 검증하는 방법

방법은 두 가지이고, 둘 다 같은 지문과 같은 타임스탬프를 확인해요.

앱에서: 파일 메뉴에서 내보내기 검증…을 고르고 .zip을 선택하세요. Text2Store가 모든 지문과 타임스탬프를 다시 확인하고 검증됨, 변경됨, 검증되지 않음 중 하나를 알려 줘요. "검증됨"은 파일이 일치하고 신뢰할 수 있는 타임스탬프가 패키지가 바뀌지 않았음을 증명한다는 뜻이에요. "변경됨"은 무언가가 더 이상 맞지 않는다는 뜻이에요. "검증되지 않음"은 파일끼리는 일관되지만 패키지에 신뢰할 수 있는 타임스탬프가 없어서, 그것만으로는 바뀌지 않았다고 증명할 수 없다는 뜻이에요(믿을 수 있는 사본과 매니페스트 지문을 비교해 보세요). 인터넷도 설치도 필요 없고, Mac과 Windows에서 똑같이 작동해요. 독립성을 위해 패키지 안의 것이 아니라 앱이 직접 고정해 둔 타임스탬프 기관 인증서를 써요.

직접: 함께 들어 있는 VERIFY.txt에 정확한 명령어가 있어요. macOS와 Linux에서는 shasum, Windows에서는 PowerShell의 Get-FileHash를 쓰세요. 신뢰할 수 있는 시간까지 확인하려면 openssl을 쓰세요. VERIFY.txt 자체에 적힌 솔직한 주의점이 하나 있어요. macOS에 들어 있는 LibreSSL은 이 타임스탬프의 인증서 체인을 검증하지 못하니, 전체 OpenSSL(Homebrew)을 설치하거나 앱의 검증 도구를 쓰세요. Windows에서는 Git for Windows에 들어 있는 OpenSSL이 돼요. VERIFY.txt는 타임스탬프 기관 인증서의 SHA-256도 보여 주니, 증명된 시간에 기대기 전에 cacerts.digicert.com에 공개된 DigiCert 루트와 대조해 볼 수 있어요.

기술 세부 사항

요약을 믿기보다 원리를 확인하고 싶은 분을 위해: 아래의 모든 내용은 공개된 표준(SHA-256, RFC 3161, CMS)을 쓰고, 표준 도구로 재현할 수 있어요. 독점적이거나 비밀인 건 없어요. 그 개방성이 핵심이에요. 직접 확인할 수 있는 주장이 믿어야만 하는 주장보다 가치 있으니까요.

지문과 매니페스트

패키지의 모든 파일은 바이트 그대로에 대해 SHA-256으로 해시돼요. manifest.json은 각 파일을 경로와 SHA-256으로 나열해요.

{
  "format": "text2store/verified-export",
  "artifacts": [
    { "path": "transcript.pdf", "sha256": "9f2c..." },
    { "path": "conversation.json", "sha256": "4a1e..." },
    { "path": "attachments/0001.jpg", "sha256": "b7d0...",
      "source_backup_sha256": "b7d0..." }
  ],
  "content_root_sha256": "e3b1..."
}

content_root_sha256은 목록 전체에 대한 지문 하나로, 목록 자체도 변경 여부를 확인할 수 있게 해요. 결과물마다 path:sha256 줄을 하나씩 만들고, 그 줄들을 정렬하고, 줄바꿈으로 이은 다음, 결과를 SHA-256으로 해시해서 구해요. 누구나 매니페스트에서 다시 계산해 일치하는지 확인할 수 있어요.

첨부 파일을 기기 백업에 연결하기

첨부 파일마다 source_backup_sha256도 기록돼요. 그 파일이 가져온 iPhone이나 iPad 백업에서 갖고 있던 지문이에요. 내보내기는 그 백업 자체의 체크섬 기준에 맞춰 만들어지고, 첨부 파일 중 하나라도 더 이상 맞지 않으면 만들기를 거부해요. 그래서 내보낸 사진은 손으로 넣은 무언가가 아니라 그 특정 기기 백업과 연결돼요.

지문 목록 밖에 있는 것

구조적인 이유로 결과물 목록에 오르지 않는 파일은 두 개뿐이에요. manifest.json은 자기 지문을 담을 수 없고, manifest.json.tsr(타임스탬프)은 매니페스트의 지문으로부터 만들어지니 매니페스트를 봉인한 뒤에 생겨요. 그 밖의 모든 것, 사람이 읽는 certificate.pdf, VERIFY.txt, DECLARATION.txt와 기관의 tsa/cacert.pem까지 다른 파일처럼 매니페스트에 해시돼요. 검증하는 쪽은 매니페스트 자체의 SHA-256을 다시 계산하고, 그걸 패키지 지문으로 다뤄요.

신뢰할 수 있는 타임스탬프

manifest.json.tsr은 RFC 3161 타임스탬프 토큰으로, messageImprint가 manifest.json의 SHA-256인 CMS SignedData 구조예요. 받아들이려면, 토큰 서명이 유효한지, 서명자 인증서가 DigiCert 루트까지 이어지는지(토큰에는 최종 인증서에서 중간 인증서, 루트까지 전체 서명 체인이 들어 있어요), 증명된 시각에 유효 기간 안이었는지, RFC 3161이 요구하는 중요 확장 키 용도 id-kp-timeStamping이 있는지, 임프린트가 이 매니페스트의 SHA-256과 같은지 확인해요. Text2Store의 앱 내 검증 도구는 이 모든 걸 네트워크 없이 코드만으로 하고, 패키지 안의 cacert.pem을 믿는 대신 직접 고정해 둔 DigiCert 루트 사본을 쓰기 때문에, 바꿔치기한 인증서에 속지 않아요. VERIFY.txt가 그 인증서의 SHA-256을 보여 주니, cacerts.digicert.com에 공개된 DigiCert 루트와 대조할 수 있어요.

직접, 정확하게 확인하기

아무 파일이나 해시해서 매니페스트의 sha256과 비교하세요.

# macOS / Linux
shasum -a 256 transcript.pdf

# Windows (PowerShell)
Get-FileHash transcript.pdf -Algorithm SHA256

신뢰할 수 있는 타임스탬프가 바로 이 매니페스트를 다루고 기관까지 이어지는지 확인하세요.

openssl ts -verify -data manifest.json -in manifest.json.tsr -CAfile tsa/cacert.pem

패키지의 VERIFY.txt에는 콘텐츠 루트를 다시 계산하는 방법까지 이 명령어들이 적혀 있어서, 복사해서 붙여 넣기만 하면 돼요.

통과로 보는 조건

검증하는 쪽이 검증됨이라고 알려야 하는 건 다음이 모두 성립할 때뿐이에요. 목록의 모든 파일이 있고 지문과 일치하며, 콘텐츠 루트가 다시 계산해도 맞고, 여분이나 중복 파일이 없으며, 신뢰할 수 있는 타임스탬프가 manifest.json에 대해 검증을 통과할 때요. 신뢰할 수 있는 타임스탬프가 없는 패키지는 검증되지 않음이에요. 내부적으로는 일관되지만 독립적인 기준점이 없어요. 매니페스트는 그 외부 서명 없이는 스스로의 무결성을 증명할 수 없으니까요. 불일치, 여분 파일, 검증을 통과하지 못하는 타임스탬프가 하나라도 있으면 변경됨이에요.

서명된 선언서

어떤 절차는 기록과 함께 사람의 증언을 원해요. 기록이 어떻게 만들어졌는지 사람이 글로 밝히는 거예요. 소프트웨어는 그런 증언을 할 수 없고, 사람만 할 수 있어요. 그래서 패키지에 DECLARATION.txt가 들어 있어요. 사람(나, 또는 기록 관리자)이 고쳐 쓰고, 직접 계산한 매니페스트 지문을 채워 완성할 수 있는 간단한 작성용 양식이에요.

양식일 뿐이에요. 법률 자문이 아니고, 공식 절차를 위해 무언가를 준비한다면 먼저 변호사에게 검토받으세요.

시간과 시간대

사람이 읽는 PDF에서는 메시지 시각을 내보낸 컴퓨터의 현지 시간에 UTC 시차를 명시해서 보여 줘요(예: 2026-06-30 21:14 -08:00). 시간대는 맨 위에 적혀 있어서 휴대폰에서 보던 시각과 같고 헷갈릴 일이 없어요. 기계가 읽는 데이터(conversation.json)와 신뢰할 수 있는 타임스탬프는 모두 UTC로 유지하니, 전문가는 언제든 정확한 시각을 재구성할 수 있어요.

정직한 한계

검증된 내보내기는 그 바탕이 된 백업만큼만 완전해요. Text2Store는 아카이브할 때 휴대폰에 아직 있던 것만 담을 수 있어요. 가장 좋은 습관은 간단해요. 정기적으로 백업하세요. 그래야 필요해지기 한참 전에 대화가 안전하게 담겨 있어요. iOS는 삭제한 메시지를 몇 주 동안 복구 가능한 상태로 두니까, 최근 백업에는 생각보다 많은 게 담겨 있는 경우가 많아요. 자세한 내용은 자주 묻는 질문을 참고하세요.

관련 항목

eDiscovery 검토용 RSMF, PDF로 내보내기, 백업 속 WhatsApp 채팅.

궁금한 점이 있나요?

hello@text2store.com으로 이메일을 보내 주시면 도와드릴게요.