모든 글

읽는 데 6분

파일을 봉인하기 전에 수신자를 확인하십시오

수신 주소는 이름이 아니라 공개 키입니다. 민감한 파일을 봉인하기 전에 신뢰할 수 있는 채널을 통해 수신자의 주소를 확인하십시오. 암호화가 완벽하게 동작하더라도 엉뚱한 사람에게 전달될 수 있습니다.

민감한 파일을 봉인하기 전에, 공격자가 통제하기 어려운 채널을 통해 수신자의 수신 주소를 확인하십시오. 수신 주소는 이름이 아니라 공개 키입니다. 엉뚱한 키로 암호화하면 그 키를 가진 엉뚱한 사람이 파일을 열 수 있고, 정작 전달하려던 사람은 열지 못할 수 있습니다.

이것은 암호화 워크플로에서 가장 흔히 발생하는 사람의 실수입니다. 암호 기술은 완벽한데도 전송 자체가 틀릴 수 있습니다. 문자열 하나만으로는 그 키가 누구의 것인지 전혀 증명되지 않기 때문입니다. 암호화는 "이 바이트를 누가 열 수 있는가?"에 답합니다. "내가 올바른 사람을 골랐는가?"에는 답하지 않습니다.

수신 주소란 무엇입니까?

수신 주소는 발신자가 레코드를 봉인할 때 사용하는 암호화 공개 키입니다. CardanoWall에서는 두 가지 형태로 제공됩니다.

  • age1... — 클래식 X25519 수신 주소.
  • age1pqc... — 하이브리드 포스트 양자 수신 주소.

발신자는 수신자가 공개한 주소로 봉인합니다. 수신자는 신원 시드에서 파생되는 일치하는 개인 키로 레코드를 엽니다. 주소는 공유하기 위한 것이며, 개인 키와 시드는 비밀로 유지해야 합니다. (주소가 무엇이고 수신자가 주소를 어떻게 건네는지에 대한 자세한 내용은 수신 주소란 무엇인가를 참고하십시오.)

키를 확인하는 일이 왜 그토록 중요합니까?

공개 키는 신원이 아니기 때문입니다.

누구나 수신 주소처럼 보이는 문자열을 보낼 수 있습니다. 누구나 익숙한 표시 이름 옆에 키를 붙여 넣을 수 있습니다. 문자열 자체는 일치하는 개인 키를 누가 통제하는지 전혀 증명하지 못합니다. 단지 어떤 키 보유자가 통제한다는 사실만 알려 줄 뿐입니다. 공격자가 자신의 주소를 슬쩍 건네면, 사용자가 연락처에게 "보낸다"고 생각하며 봉인한 모든 것을 공격자가 읽게 되고, 정작 연락처는 아무것도 받지 못합니다.

일회용 테스트 파일이라면 그것이 문제가 되지 않을 수도 있습니다. 그러나 법적 증거, 사고 데이터, 개인정보, 미공개 작업물, 내부고발 자료라면 봉인하기 전에 키를 확인하십시오. 주소록은 그 확인을 한 번으로 끝내기 위해 존재합니다. 키를 한 번 확인하고 저장한 다음, 매번 다시 신뢰해야 하는 문자열을 다시 붙여 넣는 대신 저장된 항목을 재사용하면 됩니다.

좋은 확인 채널이란 무엇입니까?

공격자가 통제하기 어려운 경로를 사용하고, 키를 전달한 채널과는 별개의 채널을 통해 키를 확인하십시오. 합리적인 선택지를 대략 신뢰도 순으로 정리하면 다음과 같습니다.

  • 직접 만나 전달하기(예: QR 코드를 함께 스캔하기).
  • 이미 알고 있는 번호로 전화를 걸어 키 지문을 소리 내어 읽기.
  • 수신자의 공식 도메인에 있는 .well-known 키 페이지.
  • 해당 도메인의 DNS TXT 레코드.
  • 수신자의 공식 사이트에서 연결되는 서명된 프로필.
  • 이미 신뢰하고 있는 기존의 종단 간 암호화 대화.
  • 조직이 승인한 키 디렉터리.
  • 신뢰하는 절차를 통해 전달된, 인쇄된 키 지문.

올바른 방법은 무엇을 보내는지에 따라 달라집니다. 가치가 높은 파일은 독립적인 두 채널을 통해 확인하십시오. 이메일로 받은 키를 전화 통화로 다시 읽어 대조하면, 둘 중 어느 하나만 쓰는 경우보다 위조하기가 훨씬 어렵습니다.

그 자체만으로는 부족한 것은 무엇입니까?

익숙한 이름만으로는 부족합니다. 두 번째 채널이 확인해 주기 전까지는 다음을 검증되지 않은 것으로 취급하십시오.

  • 완전히 새로운 이메일 스레드로 도착한 키.
  • 검증하지 않은 계정에서 온 다이렉트 메시지.
  • 키의 스크린샷.
  • 본인에게로 연결되는 신뢰할 수 있는 링크가 없는 공개 프로필.
  • 제삼자가 전달해 준 주소.
  • 두 번째 채널 확인이 없는 "제 새 키입니다" 메시지.

공격자는 키 교환의 순간에 집중합니다. 그 순간이 바로 바꿔치기된 키가 완전히 정상으로 보이는 유일한 단계이기 때문입니다. 일단 엉뚱한 키가 저장되면, 이후의 모든 전송이 조용히 계속 엉뚱한 곳으로 향할 수 있습니다.

주소록은 어떻게 사용해야 합니까?

키를 확인한 다음에 저장하고, 그 전에는 절대 저장하지 마십시오. 신뢰하는 각 연락처에 대해 주소록은 다음을 기록합니다.

  • 표시 이름.
  • 연락처의 Ed25519 서명 공개 키(해당 연락처의 레코드를 그 사람과 연결 짓는 식별자).
  • age1... 수신 주소(있는 경우).
  • age1pqc... 포스트 양자 수신 주소(있는 경우).
  • 키를 어떻게, 언제 확인했는지.
  • 자유 형식 메모 — 어떻게 확인했는지를 정확히 적어 두십시오.

이후 봉인된 레코드를 작성할 때는 주소를 다시 붙여 넣는 대신 주소록에서 연락처를 고르십시오. 그렇게 하면 신중한 한 번의 확인이 여러 번의 더 안전한 전송으로 이어집니다. 주소록을 만드는 과정에 대한 안내는 주소록 만들기주소록은 어떻게 작동하는가를 참고하십시오.

포스트 양자 주소를 선호해야 합니까?

여러 해 동안 민감한 상태로 남을 수 있는 파일이라면, 그렇습니다. 수신자가 포스트 양자 주소를 제공한다면 그것을 사용하십시오.

하이브리드 age1pqc... 주소는 클래식 주소보다 훨씬 길지만, 오늘 봉인된 암호문을 기록해 두었다가 훗날 양자 컴퓨터로 복호화하려는 공격자("지금 수집하고 나중에 복호화하기")로부터 보호해 줍니다. 레코드가 가까운 미래 동안만 비밀로 유지되면 되는 경우라면, 보통 클래식 age1... 주소만으로 충분합니다.

어느 쪽을 선택하든 규칙은 바뀌지 않습니다. 주소를 먼저 확인하십시오. 확인하지 않은 포스트 양자 키는 확인하지 않은 클래식 키보다 조금도 더 안전하지 않습니다.

수신자가 키를 교체하면 어떻게 합니까?

새 키를 새 연락처처럼 확인하십시오. 어떤 메시지가 키가 바뀌었다고 주장한다는 이유만으로 저장된 수신 주소를 덮어쓰지 마십시오. 그것이 바로 키 바꿔치기 공격이 취하는 전형적인 형태입니다. 신뢰할 수 있는 채널을 통해 새 키를 확인하고, 항목을 갱신하며, 키가 바뀐 이유를 기록해 두십시오.

팀과 조직의 경우, 키 교체는 예측 가능한 위치에서 공지되어야 합니다. 공식 도메인, 서명된 프로필, 또는 문서화된 내부 절차가 그 예입니다. 키가 침해되었다고 의심되면 즉시 옛 주소로 봉인하기를 중단하고, 새 주소가 확인될 때까지 기다리십시오.

봉인된 레코드는 온체인에 무엇을 드러냅니까?

읽을 수 있는 수신자 목록은 드러내지 않습니다. Label 309 봉인된 레코드는 콘텐츠 키를 수신자별로 하나씩 암호화된 슬롯에 감싼 다음 그 슬롯들을 뒤섞으므로, 공개 레코드에는 평문 "수신자" 필드가 담기지 않습니다. 받은편지함은 각 슬롯을 자신의 키로 로컬에서 시험 복호화하여 사용자를 위한 레코드를 찾아냅니다. 관찰자가 볼 수 있는 것은 봉인된 레코드가 존재한다는 사실, 그것이 언제 게시되었는지, 그리고 슬롯이 몇 개인지뿐이며, 수신자가 누구인지는 결코 볼 수 없습니다.

이러한 수신자 비공개성은 온체인 프라이버시를 보호하지만, 키 확인에는 아무 도움이 되지 않습니다. 체인은 사용자가 누구에게 봉인했는지는 숨겨 주지만, 올바른 키로 봉인했는지는 검사해 줄 수 없습니다. 올바른 주소를 고르는 일은 여전히 전적으로 발신자의 몫입니다. 그리고 반대편의 한계도 유념하십시오. 봉인은 평문을 키 보유자에 한해 암호화된 상태로 유지해 주지만 익명성을 보장하지는 않으며, 어떤 수신자든 일단 복호화하고 나면 평문을 유출할 수 있습니다. (증명이 무엇을 입증할 수 있고 무엇을 입증할 수 없는지에 대해서는 증명이 증명하지 않는 것을 참고하십시오.)

요약

좋은 암호화에 부실한 키 확인이 더해지면 결국 부실한 전송입니다. 그러므로 다음과 같이 하십시오.

  • 민감한 것을 봉인하기 전에 수신 주소를 확인하되, 가급적 두 채널을 통해 확인하십시오.
  • 확인한 키는 주소록에 저장하고, 각각을 어떻게 확인했는지 기록하십시오.
  • 키가 바뀌면 다시 확인하십시오 — 새 키를 완전히 새로운 연락처처럼 취급하십시오.

암호 기술은 쉬운 부분입니다. 확인은 사용자가 책임지는 부분입니다.

더 읽을거리

securitysealed-poeaddress-book