이메일 암호화

Email encryption

전자 메일 암호화는 전자 메일 메시지를 암호화하여 원하는 수신자가 아닌 다른 엔티티가 내용을 읽지 못하도록 보호하는 입니다.전자 메일 암호화에는 인증도 포함될 수 있습니다.

이메일은 정보가 노출되기 쉽습니다.대부분의 전자 메일은 전송 중에 암호화되지만 일반 텍스트로 저장되므로 전자 메일 [1]공급자와 같은 제3자가 읽을 수 있습니다.기본적으로 Gmail 및 Outlook과 같은 일반적인 이메일 서비스에서는 엔드[2]엔드 암호화를 사용할 수 없습니다.이용 가능한 툴에 의해, 지정된 수신자 이외의 사람이 전자 메일의 [3]내용을 읽을 수 있습니다.

전자 메일 암호화는 공개암호화에 의존할 수 있습니다.이 암호에서는, 유저는, 다른 유저가 메시지를 암호화하기 위해서 사용할 수 있는 공개 키를 공개하면서, 이러한 메시지의 복호화나 송신 메시지의 디지털 암호화 및 서명에 사용할 수 있는 개인 키를 비밀에 부칠 수 있습니다.

암호화 프로토콜

이메일 프로토콜의 원래 설계에서는 이메일 서버 간의 통신이 일반 텍스트로 이루어졌고, 이로 인해 보안에 큰 위험이 있었습니다.수년간 이메일 서버 간의 통신을 암호화하기 위한 다양한 메커니즘이 제안되어 왔습니다.암호화는 트랜스포트레벨(일명 홉 바이 홉) 또는 엔드 투 엔드로 실행할 수 있습니다.트랜스포트 레이어 암호화는 대부분의 경우 셋업과 사용이 용이합니다.엔드 투 엔드 암호화는 강력한 방어 기능을 제공하지만 셋업과 사용이 더 어려울 수 있습니다.

트랜스포트 레벨 암호화

가장 일반적으로 사용되는 전자 메일 암호화 확장 기능 중 하나는 STARTTLS입니다.일반 텍스트 통신을 통한 TLS(SSL) 계층이므로 전자 메일 서버가 일반 텍스트 통신을 암호화된 통신으로 업그레이드할 수 있습니다.송신측과 수신측의 양쪽의 전자 메일 서버가 암호화된 통신을 서포트하고 있는 경우, 메일 서버간의 통신을 도청하는 사람은, 전자 메일의 내용을 보기 위해서 스니퍼를 사용할 수 없습니다.E-메일 클라이언트와 E-메일 서버간의 통신에는, 같은 STARTTLS 확장이 존재합니다(RFC 2595에 기재된 IMAP4 및 POP3 참조).STARTTLS는 이메일 내용이 다른 프로토콜을 사용하여 암호화되었는지 여부에 관계없이 사용할 수 있습니다.

암호화된 메시지가 나타나고 중간 전자 메일 릴레이에 의해 변경될 수 있습니다.즉, 암호화는 송신자와 수신자 간에가 아니라 개개의 SMTP 릴레이 간에 이루어집니다.이것은 좋은 결과와 나쁜 결과를 모두 가지고 있다.트랜스포트 레이어 암호화의 중요한 장점은 사용자가 아무것도 하거나 변경할 필요가 없다는 것입니다.이 암호화는, E-메일을 송신할 때에 자동적으로 실행됩니다.또한 최종 사용자의 협조 없이 전자 메일을 해독할 수 있으므로 수신 조직은 전자 메일을 수신자에게 전달하기 전에 바이러스 스캐너와 스팸 필터를 실행할 수 있습니다.다만, 수신 조직과 그 조직의 전자 메일 시스템에 침입한 사람은(더 이상의 조치를 취하지 않는 한) 전자 메일을 쉽게 읽거나 수정할 수 있습니다.수신 조직이 위협으로 간주될 경우 엔드 투 엔드의 암호화가 필요합니다.

Electronic Frontier Foundation은 STARTTLS 사용을 권장하고 있으며, "모든 사람이 (이메일을 통한) 통신이 대량 [4]감시에 취약하지 않도록 간단하고 쉽게 도울 수 있도록" "STARTTLS Everywhere" 이니셔티브를 시작했습니다.STARTTLS에 대한 지원은 매우 보편화되어 있습니다.Gmail에서는 2018년 [5]7월 24일까지 수신 이메일의 90%와 발신 이메일의 90%가 STARTTLS를 사용하여 암호화되었다고 Google은 보고합니다.

많은 증명서를 검증할 수 없고, [6]이 경우 전자 메일 전송에 실패하기를 원하는 사람은 거의 없기 때문에 추가 정보가 없는 인터넷 메일 전송에는 필수 증명서 검증이 적용되지 않습니다.따라서 TLS를 통해 배달되는 대부분의 전자 메일은 기회성 암호화만 사용합니다.DANE은 인터넷 메일 전달을 위해 검증된 암호화로 점진적으로 이행할 [7]수 있도록 하는 제안된 표준입니다.STARTTLS Everywhere 프로젝트에서는 다운그레이드 공격을 탐지하고 방지하는 데 도움이 되는 STARTTLS 지원을 약속한 전자 메일 서버의 "프리로드 목록"을 지원합니다.

엔드 투 엔드 암호화

엔드엔드 암호화에서는 데이터는 엔드 포인트에서만 암호화 및 복호화됩니다.즉, 엔드 투 엔드 암호화로 송신된 이메일은 소스에서 암호화되어 전송 중인 Gmail과 같은 서비스 프로바이더가 읽을 수 없게 되어 엔드 포인트에서 복호화됩니다.중요한 것은 이메일은 컴퓨터 상의 최종 사용자에 대해서만 해독되고 Gmail과 같은 이메일 서비스에서는 읽을 수 없는 암호화된 형태로 유지된다는 것입니다.Gmail은 이를 [8]해독할 수 있는 키를 가지고 있지 않습니다.일부 이메일 서비스는 엔드 투 엔드 암호화를 자동으로 통합합니다.

엔드 투 엔드 이메일 암호화의 주요 프로토콜은 다음과 같습니다.

OpenPGP는 최종 사용자가 이메일 내용을 암호화할 수 있는 데이터 암호화 표준입니다.사용자가 메시지를 보내기 전에 수신인의 공용 키를 사용하여 메시지를 암호화할 수 있는 다양한 소프트웨어 및 전자 메일 클라이언트 플러그인이 있습니다.OpenPGP는 기본적으로 각 전자 메일 주소가 공개/비밀 키 쌍과 관련지어지는 공개암호화 방식을 사용합니다.

OpenPGP를 통해 최종 사용자는 서버의 지원 없이 전자 메일을 암호화하고 원하는 수신자만 읽을 수 있습니다.단, OpenPGP에는 조작성 문제가 있습니다.사용자는 공개키/비밀키 쌍을 설정하고 공개키를 널리 사용할 수 있도록 해야 합니다.또한 메타데이터가 아닌 전자 메일의 내용만 보호하므로 신뢰할 수 없는 당사자는 전자 메일을 보낸 사용자를 계속 관찰할 수 있습니다.서버에 복호화 키가 없는 엔드 투 엔드 암호화 방식의 일반적인 단점은 서버 측 검색이 거의 불가능하여 사용성에 영향을 미친다는 것입니다.

전자 메일의 내용은 암호화된 파일(모든 종류의 파일 암호화 도구를 사용하여)에 저장하고 암호화된 파일을 전자 메일 [9]첨부 파일로 전송함으로써 엔드 투 엔드로 암호화할 수도 있습니다.

데모

인터넷을 통한 서명암호화 이메일 데모에서는 조직이 안전한 이메일을 사용하여 효과적으로 협업할 수 있음을 알 수 있었습니다.PKI 브릿지를 사용하여 확장 가능한 PKI(Public Key Infrastructure)를 제공하는 것, 기업 네트워크 경계를 드나드는 암호화된 콘텐츠를 체크하는 것 등 기존의 채택 장벽은 극복되었습니다.

이메일 암호화 설정 및 사용

STARTTLS를 사용한 트랜스포트층 암호화는, 수신측 조직이 설정할 필요가 있습니다.이것은 일반적으로 간단합니다.수신하는 조직의 전자 메일서버에서 유효한 증명서를 취득하고 STARTTLS를 유효하게 할 필요가 있습니다.다운그레이드 공격을 방지하기 위해 조직은 도메인을 'STARTTLS 정책 목록'[10]으로 전송할 수 있습니다.

대부분의 풀기능 전자 메일클라이언트는 S/MIME 보안 전자 메일(인증서를 사용디지털 서명 및 메시지 암호화)을 기본적으로 지원합니다.기타 암호화 옵션에는 PGP 및 GNU Privacy Guard(Gnu Privacy Guard)가 있습니다.무료 및 상용 소프트웨어([11]데스크탑 애플리케이션, 웹 메일 및 애드온)도 사용할 수 있습니다.

PGP는 메시지를 보호할 수 있지만 올바른 방법으로 사용하기 어려울 수도 있습니다.카네기 멜론 대학의 연구원들은 1999년에 대부분의 사람들이 현재 버전의 [12]PGP를 사용하여 메시지를 서명하고 암호화하는 방법을 알아내지 못했다는 논문을 발표했다.8년 후, 카네기 멜론 연구팀의 또 다른 연구진은 새로운 버전의 PGP로 인해 메시지 복호화가 쉬워졌지만, 대부분의 사람들은 여전히 메시지를 암호화하고 서명하고, 다른 사람의 공용 암호화 키를 찾아 검증하고, 자신의 [13]키를 공유하는 데 어려움을 겪고 있다는 후속 논문을 발표했다.

암호화는 사용자에게 어려울 수 있기 때문에 기업 및 정부 기관의 보안 및 컴플라이언스 관리자는 암호화를 자동화하는 암호화 어플라이언스와 서비스를 사용하여 직원과 임원에게 프로세스를 자동화합니다.자동 암호화는 자발적인 협력에 의존하지 않고 정의된 정책에 따라 결정과 프로세스를 사용자의 손에서 벗어나게 됩니다.전자 메일은 규제 및 보안 정책을 준수하도록 구성된 게이트웨이 어플라이언스를 통해 라우팅됩니다.필요한 전자 메일은 자동으로 암호화되어 전송됩니다.[14]

수신자가 동일한 암호화 게이트웨이 어플라이언스를 사용하는 조직에서 작업하는 경우 전자 메일이 자동으로 해독되어 프로세스가 사용자에게 투명해집니다.암호화 게이트웨이의 배후에 없는 수신자는 공개 키를 입수하거나 온라인 포털에 [14][15]로그인하여 메시지를 취득하는 추가 절차를 수행해야 합니다.

암호화된 이메일 공급자

2000년 이후 사용 가능한 암호화된 이메일 공급자의 수가 [16]크게 증가했습니다.주목할 만한 프로바이더는 다음과 같습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "Email encryption in transit". Gmail Help. Google. Retrieved 2020-06-15.
  2. ^ "Enable hosted S/MIME for enhanced message security". GSuite Admin Help. Google. Retrieved 2020-06-15.
  3. ^ SMEmail 모바일 환경의 안전한 전자 메일을 위한 새로운 프로토콜, 호주 전기통신 네트워크 및 애플리케이션 회의(ATNAC'08) 진행, 페이지 39-44, 호주 애들레이드, 2008년 12월.
  4. ^ "Announcing STARTTLS Everywhere: Securing Hop-to-Hop Email Delivery". EFF. 2018-06-25. Retrieved 2018-07-14.
  5. ^ "Email encryption in transit".
  6. ^ "Postfix TLS Support". Postfix.org. Retrieved 2014-04-16.
  7. ^ Dukhovni; Hardaker (2015-10-14). SMTP Security via Opportunistic DANE TLS. IETF. doi:10.17487/RFC7672. RFC 7672.
  8. ^ "End-to-end encryption". How To Geek. Retrieved 9 April 2015.
  9. ^ "Secure email attachments with 7-Zip". Columbia College Information Technology, Columbia University. Retrieved 16 July 2018.
  10. ^ STARTTLS FAQ 2018-07-24가 검색되었습니다.
  11. ^ Eric Geier, PCWorld 씨"이메일 암호화 방법"2012년 4월 25일2014년 5월 28일 취득.
  12. ^ WIRED의 클린트 핀리 "구글의 개량된 지메일은 암호화의 주류를 차지할 수 있다"2014년 4월 23일2014년 6월 4일 취득.
  13. ^ 보안 및 조작성:사람들이 사용할 수 있는 안전한 시스템 설계, ed. L. Cranor 및 G.심슨.오라일리, 2005, 679-702페이지."조니가 암호화할 없는 이유"
  14. ^ a b 루이스 리베라 지음, SC 매거진"이메일 암호화를 통한 고객 사생활 보호"2014년 3월 11일2014년 7월 18일
  15. ^ Stan Gibson 지음, Search HealthIT.com. "[1]." 2010년 4월2014년 7월 22일
  16. ^ Sparrow, Elijah; Halpin, Harry; Kaneko, Kali; Pollan, Ruben (2016). Foresti, Sara; Persiano, Giuseppe (eds.). "LEAP: A Next-Generation Client VPN and Encrypted Email Provider". Cryptology and Network Security. Lecture Notes in Computer Science. Cham: Springer International Publishing: 176–191. doi:10.1007/978-3-319-48965-0_11. ISBN 978-3-319-48965-0.