KR20220164679A - 등록된 암호화된 전자 메시지 및 개정된 응답 시스템 - Google Patents

Abstract

수정된 내용을 갖는 수신된 이메일을 처리하기 위한 시스템이며, 및/또는 메시지 내용이 다시 포맷팅되고, 암호화되고 암호화로 기록되며, 메시지 헤더가 메시지의 보안 수준을 결정하도록 구문 분석되고, 보안 수준을 데이터 베이스에 저장하고, 보안 및/또는 수정된 메시지를 의도된 수신자에게 전달한다.

Description

등록된 암호화된 전자 메시지 및 개정된 응답 시스템

관련 출원에 대한 상호 참조

이 출원은 전체가 본 명세서 참조로서 포함된 “암호화된 전자 메시지 전달의 확인 및 답장에서 민감한 메시지 부분의 우발적인 공개 방지”를 제목으로 하는 2019년 4월 12일에 출원된, 먼저 출원된 미국 가출원 출원 번호 제62/833,022호에 대해 우선권을 주장한다.

기술 분야

이 공개는 전자 메시지의 개인 전달의 카테고리 및 프라이버시 준수(privacy compliance)의 하위 카테고리 내의 전자 메시지 보안에 관한 것이다. 보다 구체적으로, 본 개시는 발신 메시지가 프라이버시 측면에서 안전하게 전송되지 않았다는 주장으로 인한 데이터 침해(data breach)의 주장에 대해 발신자 또는 발신자 조직을 보호한다는 점에서 전자 메시지의 전달의 카테고리 및 프라이버시 준수의 하위 카테고리 내의 전자 메시지 보안에 관한 것이며; 데이터 프라이버시 준수 감사(privacy compliance audit)의 경우 전자 메시지의 안전한 전달을 확인하기 위해 감사 준비된 기록을 제공하는 것이다.

메일은 1965년에 전자 형식을 취했으며 “이메일”이라는 이름이 주어졌다. 이메일은 시분할 메인프레임 컴퓨터의 여러 사용자가 서로 통신하기 위한 방법으로 시작되었다. 이메일은 빠르게 “네트워크 이메일”로 확장되어 최소 1966년까지 사용자가 서로 다른 컴퓨터 간에 메시지를 전달할 수 있게 되었다. 오늘날 이메일은 개인의 기술적 지식의 수준이나 이메일이 작동하는 방법의 이해 수준에 관계 없이 사용할 수 있을 만큼 간단한 커뮤니케이션 도구가 되었다.

오늘날, 이메일(전자 메시지 전송 시스템 및 프로토콜)은 종종 사람들 간의 중요한 통신에 의지하며 발신자가 이메일 수신자 이외의 당사자가 사용할 수 있도록 원하지 않을 수 있는 민감한 금융, 건강 관련, 전략, 또는 법적 정보를 전송하거나 작업을 수행하도록 지시하는데 사용된다.

많은 주, 국가 및 산업에서, 표준 이메일 전송보다 더 사적인 방식으로 전자 메시지를 전송하는 시스템을 사용하여 특정 정보의 발신인에게 정보를 전송하도록 요구하는 규정이 있다. 일 예는 의료 정보 보호를 위한 데이터 프라이버시 및 보안 조항을 제공하는 1996년의 전자 의료 보험 청구법(Health Insurance Portability Accountability Act, HIPAA)이라는 제목의 미국 의료 프라이버시 규정이다. 다른 예는 이메일 프라이버시 준수를 위한 규정을 포함하는 유럽 일반 데이터 보호 규정(European General Data Protection Regulation, GDPR)이다. GDPR은 요구 사항을 충족해야 하는 방법보다 규정 준수를 통해 달성해야 할 사항을 정의한다. 결과적으로 이메일을 암호화하는 특정 방법을 사용하는 요구 사항은 언급되지 않지만 소비자 비공개 및 개인 정보 취급자는 해당 정보의 프라이버시를 유지 관리할 뿐만 아니라 프라이버시 요구사항의 준수를 입증할 수 있는 능력도 포함한다. 이러한 요구사항은 GDPR 5조 1(f) 및 2, 32조 1(a) 및 1(d)에 자세히 설명되어 있으며, 이는 개인 데이터 보호 사실을 입증할 수 있는 능력과 함께 전송 중에 개인 데이터를 보호해야 한다는 요구 사항에 중점을 둔다.

일반 이메일 및 전자 메시지 시스템 사용자는 전자 메시지(이메일은 전자 메시지 전송 프로토콜을 사용하여 전송되는 모든 전자 메시지 참조)를 보내고, 받고, 읽고, 회신하고, 전달하는 방법을 알지만, 일반 이메일 사용자는 더 안전하거나 사적인 방식으로 이메일을 전송하는 방법 및 표준 이메일과 비교하여 더 안전하거나 사적인 방식을 사용하여 메시지가 전송되는지 또는 전송되었는지 확인하는 방법을 모른다. 이메일을 수신하면 일반 이메일 사용자는 해당 이메일이 보안 전송 또는 암호화된 전송을 사용하여 수신되었는지 확인하는 방법을 모른다. 일반 이메일 사용자는 수신자가 보안 전송으로 보내진 내용의 수신을 보호하고 이메일 스레드(email thread)에 있을 수 있는 원래 보내진 내용을 노출하고 불안정하게 응답하는 것으로부터 이를 보호하는 방법을 모른다.

고급 이메일 사용자는 이메일을 자동으로 필터링하여 특징 폴더에 배치하거나 이메일에 다양한 중요도를 표시하도록 그 이메일 프로그램을 구성할 수 있다. 고급 이메일 사용자는 표준 이메일 전송보다 더 개인적인 방식으로 이메일을 전송하도록 시스템을 설정할 수 있으며; 표준 이메일 전송은 SMTP, ESMTP, SMS, SMPP, MMS, HTTP, HTTPS 및 SSL, TLS 등과 같은 조합을 사용하여 보내지는 전자 메시지 전송으로 정의된다.

이러한 이메일 사용자 또는 그 이메일 운영자 중 일부는 기존 이메일 프로그램 내에 제3자의 프로그램 또는 암호화 키를 설치하여 이메일과 관련된 다양한 알려진 일반적인 보안 위협을 처리하는데 도움을 줄 수 있다. 사용자(이메일의 발신자 및/또는 수신자) 또는 이메일 시스템 관리자는 이메일 서버, 이메일 게이트웨이 또는 이메일 사용자 인터페이스(일반적으로 “이메일 클라이언트”라고 함)에서 소프트웨어를 추가하거나 설정하게 할 수 있다. 이러한 추가 기능 소프트웨어 프로그램은 표준 메시지 프로토콜을 사용하는 것보다 더 개인적인 방식으로 메시지를 전송하는 옵션을 추가할 수 있다. 일부 사용자는 메시지를 검색하거나 보는 링크를 보내는 보안 서버에 메시지를 업로드하도록 선택될 수 있으며, 일부는 웹 브라우저에서 안전하게 액세스된 보안 프로그램에서 메시지를 작성한 다음 전송하도록 선택될 수 있다. 일부 시스템은 SOAP, REST, EDI 교환 프로토콜과 같은 프로토콜을 포함하는 보안 응용 프로그래밍 인터페이스를 사용하여 전송할 수 있다.

표준 이메일 전송 프로토콜을 사용하는 것보다 더 개인적인 방식으로 메시지를 전송하는 다양한 방법이 있다. 이러한 방법 중 일부는 TLS, SSL 또는 HTTPS와 같은 보안 연결을 사용하거나 사용하지 않고 PGP, PKI, AES 256 비트, PDF, 링크 검색(Link-Retrieval), HTML 래퍼(HTML Wrapper) 등을 사용한다. EDI, SMS, MMS 등을 포함하는 보안 메시지 시스템에는 다른 프로토콜이 있다.

필요한 것은 (1)발신 지점으로부터 수신 지점으로의 개인 전송 보장(송신 단부 및 수신 단부는 다른 상황에서 다를 수 있음), (2) 엔드 투 엔드(end-to-end) 개인 전송의 사실 기록, (3) 메시지 단위로, 엔드 투 엔드 개인 전송의 사실의 제3자 검증을 위한 수단을 제공, (4) 수신자 회신에 따라 메시지 내용 또는 메시지 내용의 일부를 수정하고 선택적으로 추가로 기록(예를 들어 수신자의 회신이 수신자 회신에 지정된 개인 정보를 전송하지 않도록)하는 수단을 갖는 발신자나 발신자 기관에 대한, 또는 수신자에 대한, 또는 발신자에게 회신하는 수신자에 대한 수단이다. 본 발명은 이들 및 다른 요구를 만족시킨다.

가장 일반적인 양태에서, 본 개시는 특정 메시지 또는 메시지의 특정 부분이 암호화된 방식으로 또는 개인 정보가 우발적으로 노출될 가능성을 최소화하는 방식으로 전송되도록 요구하는 정보 프라이버시 정책의 침해의 가능성으로부터 발신자 또는 발신자 조직을 보호하기 위한 시스템 및 방법을 제공한다. 다른 양태에서, 본 개시는 메시지 또는 메시지의 일부가 암호화된 방식으로 전송되지 않았다는 제3자 주장으로부터 발신자 또는 발신자 조직을 보호하기 위한 시스템 및 방법을 제공한다.

다른 양태에서, 본 개시는 프라이버시 준수 감사의 경우에 마음의 평화 또는 보호를 위해 암호화된 전달의 사실 증명 및 발신자 또는 발신자 조직 가시성, 및 발신자 또는 발신자 에이전트에서 암호화된 전달로 전송된 인바운드 메시지의 수신의 사실 증명 및 가시성을 제공하는 시스템 및 방법을 설명한다. 하나의 예시적인 양태에서, 발신자는 수신자가 메시지 스레드를 포함하고 안전한 전송 프로세스 없이 돌아오는 경우 원래 수신된 메시지 내용을 잠재적으로 노출하는 메시지에 수신자가 응답하도록 허용하는 안전한 메시지 전송 프로세스를 사용하는 메시지를 수신자가 수신할 때 보호될 수 있다.

또 다른 양태에서, 본 개시는 메시지 정책을 더 잘 관리하고 데이터 프라이버시 준수 감사의 경우 쉽게 액세스 가능한 정보를 제공하기 위해 전자 메시지의 안전한 전달을 확인하도록 감사 준비된 기록을 제공한다. 일 양태에서, 본 개시는 본 명세서에서 설명된 시스템 및 방법이 개별적으로 구현되거나, 각각이 부분적으로 구현되거나 함께 구현될 수 있는 3 개의 부분을 가질 수 있음을 제공한다.

다른 양태에서, 본 개시는 하나의 단부로부터 수신 단부로의 전자 메시지의 암호화된 전달의 사실의 기록을 발신자 또는 발신자 조직(또는 수신자 또는 수신자 응답)에 제공한다. 다른 양태에서, 본 개시는 암호화된 전달의 사실의 증거로서 의지할 수 있도록 개인 전달에 관련된 충분한 정보를 포함하는 기록을 생성하는 것을 추가로 제공한다.

또 다른 양태에서, 본 개시는 제3자가 개인 전달의 사실의 기록을 인증하는 수단을 제공한다. 또 다른 양태에서, 본 개시는 메시지의 발신자에게 보다 사적인 방식으로 복귀된 발신자의 메시지에 응답할 기회를 제공하는 기록을 생성한다(응답 메시지 스레드에 포함되는 경우 전송된 발신자의 원래 정보의 일부 또는 내용을 노출하지 않도록).

또 다른 양태에서, 본 개시는 발신자 또는 제3자가 수신자의 응답 메시지 스레드에서 수정되거나 제거된 전송된 특정 내용의 사실의 기록을 인증하는 수단을 제공한다.

다른 양태에서, 본 개시는 이메일 메시지에 대한 수정된 응답 서비스를 제공하기 위한 시스템을 제공하며, 상기 시스템은 수신자로부터 원격으로 떨어진 서버를 포함하며, 상기 서버는: 수정을 위해 발신자에 의해 표시된 내용을 포함하는 메시지를 수신하고, 수신된 메시지를 처리하는데 사용될 메시지의 발신자에 의해 설정되는 임의의 설정이 있는지 결정하고, 결정된 설정에 따라 수정을 위해 표시된 내용을 제거하고, 결정된 설정에 따른 메시지를 재포맷하고, 재포맷된 메시지, 그리고 수신자에게 제거된 내용과 관련된 정보를 전송하도록 프로그래밍된다. 다른 양태에서, 서버는 메모리에 저장된 데이터베이스에 제거된 내용을 저장하도록 추가로 프로그래밍된다. 또 다른 양태에서, 서버는 저장된 제거된 내용의 보기(viewing)와 연관된 다양한 파라미터를 제한하기 위해 제거된 내용에 보기 제한을 추가하도록 프로그래밍된다. 다른 양태에서, 제거된 내용과 연관된 전송된 정보는 데이터베이스에 저장된 제거된 내용에 대한 액세스를 제공하는 링크이다.

또 다른 양태에서, 서버는 전송된 재포맷된 메시지에 기초한 응답 메시지가 포함할 수 있는 내용을 제한하는 응답 제어 정보를 포함하는 전송된 재포맷된 메시지에 대한 링크를 추가하도록 더 프로그래밍된다. 일 양태에서, 제어 정보는 제거된 내용과 연관된 정보를 포함하는 것으로부터 응답을 보호한다. 다른 양태에서, 제어 정보는 발신자에 의해 설정된 정보를 포함한다.

또 다른 양태에서, 본 개시는 이메일 시스템을 위한 등록된 암호화 서비스를 제공하기 위한 시스템을 제공하며, 시스템은 발신자로부터 메시지를 수신하고, 수신된 메시지의 하나 이상의 헤더를 구문 분석하고(parse), 발신자에 의해 제공되는 보안 수준 또는 다른 데이터에 따른 데이터베이스의 하나 이상의 구문 분석된 헤더와 연관된 정보를 저장하고, 의도된 수신자로의 전송을 위한 수신된 메시지를 보안화하고, 보안화된 메시지 및 보안화된 메시지와 연관된 정보를 전송하고, 메시지의 보안 수준을 결정하기 위해 데이터베이스에 저장된 정보를 처리하고, 결정된 보안 수준의 표시를 포함하고 전송된 보안화된 메시지에 관한 리포트를 생성하도록 프로그래밍된 수신자로부터 원격으로 떨어진 서버를 포함한다. 일 양태에서, 생성된 리포트는 인증 준비 리포트(authentication-ready report)이다. 다른 양태에서, 인증 준비 리포트는 발신자에게 전송된다.

또 다른 양태에서, 서버는 메모리에 저장된 데이터베이스에 수신된 메시지를 보안화하는데 사용되는 방법의 기록을 저장하도록 추가로 프로그래밍 된다. 다른 양태에서, 서버는 메모리에 저장된 데이터페이스에서 수신자에게 보안화된 메시지를 전송하는데 사용되는 전송 프로토콜의 일부를 포함하는 기록을 저장하도록 추가로 프로그래밍된다. 또 다른 양태에서, 서버는 메모리에 저장된 데이터베이스에서 수신자에게 전달된 메시지를 보안화하는데 사용되는 방법의 기록을 저장하도록 추가로 프로그래밍된다. 또 다른 양태에서, 서버는 발신자로부터 수신된 메시지를 보안화하기 위해 발신자 또는 발신자 서버에 의해 사용되는 방법 및 메모리에 저장되는 데이터베이스에서 수신자에게 전송된 메시지를 보안화하는데 사용되는 방법의 기록을 저장하도록 추가로 프로그래밍된다. 다른 양태에서, 서버는 수신자에게 전송된 메시지로부터 내용의 수정의 활성화를 기록하도록 추가로 프로그래밍된다.

본 발명의 다른 특징 및 이점은 예로서 본 발명의 원리를 예시하는 첨부 도면과 함께 취해진 다음의 상세한 설명으로부터 명백해질 것이다.

다음의 상세한 설명 및 예는 본 개시의 예 또는 실시예의 전부는 아니지만 일부를 비포괄적으로 설명할 목적으로 제공되며, 어떤 식으로든 본 개시의 범위를 제한하지 않아야 한다.
도 1은 네트워크를 통해 발신자에 의해 수신자에게 전송된 메시지의 등록된 수정 또는 등록된 암호화를 수행하기 위해 본 개시의 다양한 실시예에 의해 구체적으로 수정될 수 있는 컴퓨터 또는 처리 시스템의 개략도이다.
도 2는 본 개시의 다양한 실시예에 따라 사용되는 네트워크의 개략도이다.
도 3은 고객이 이메일 암호화를 사용하는 이유를 묻는 설문조사 결과를 그래픽으로 나타낸 것이다.
도 4는 고객에게 이메일 암호화 서비스에서 기능의 중요성에 대한 순위를 매길 것을 요청하는 설문조사 결과를 그래픽으로 나타낸 것이다.
도 5는 전자 메시지의 수신자에 의해 수신될 수 있는 허용 가능한 암호화 수준을 결정하기 위한 프로세스의 일 실시예의 개략도이다.
도 6은 본 개시의 다양한 실시예에 따라 사용되는 예시적인 발신자 설정을 도시한다.
도 7은 본 개시에 따른 시스템의 일 실시예의 개략도이다.
도 8은 도 7의 실시예의 일 양태의 개략도이다.
도 9는 도 8의 실시예의 일 양태의 개략도이다.
도 10은 도 7의 실시예의 일 양태의 개략도이다.
도 11은 도 7의 실시예의 일 양태의 개략도이다.
도 12는 도 11의 실시예의 일 양태의 개략도이다.
도 13은 도 11의 실시예의 일 양태의 개략도이다.
도 14는 도 11의 실시예의 일 양태의 개략도이다.
도 15는 도 11의 실시예의 일 양태의 개략도이다.
도 16은 도 7의 실시예의 메시지의 수신자로부터 전송된 응답의 처리를 예시하는 본 개시의 실시예의 개략도이다.
도 17은 본 개시의 다양한 실시예에 따른 발신자 설정의 메뉴의 그래픽 도면이다.
도 18은 본 개시의 다양한 실시예에 따른 시스템에 사용되는 메뉴의 그래픽 도면이다.
도 19는 본 개시의 다양한 실시예의 특징을 보여주는 예시적인 스크린 샷의 그래픽 도면이다.
도 20은 본 개시의 수정된 응답 실시예의 단계를 예시하는 흐름도이다.
도 21은 본 개시의 하나의 등록된 암호화 실시예의 개략도이다.
도 22는 도 21의 실시예의 일 양태의 개략도이다.
도 23은 도 21의 실시예의 일 양태의 개략도이다.
도 24는 본 개시에 따라 생성된 리포트의 그래픽 도면이다.
도 25는 본 개시에 따라 생성된 리포트의 그래픽 도면이다.
도 26은 본 개시에 따른 등록된 암호화 프로세스의 실시예의 다양한 단계를 예시하는 흐름도이다.
도 27은 전자 메시지 헤더 부분의 배열을 도시하는 블록도이다.

메일은 1965년에 전자 형식을 취했으며 “이메일”이라는 이름이 주어졌다. 이메일은 시분할 메인프레임 컴퓨터의 여러 사용자가 서로 통신하기 위한 방법으로 시작되었다. 이메일은 빠르게 “네트워크 이메일”로 확장되어 최소 1966년까지 사용자가 서로 다른 컴퓨터 간에 메시지를 전달할 수 있게 되었다. 오늘날 이메일은 개인의 기술적 지식의 수준이나 이메일이 작동하는 방법의 이해 수준에 관계 없이 사용할 수 있을 만큼 간단한 커뮤니케이션 도구가 되었다.

오늘날, 이메일(전자 메시지 전송 시스템 및 프로토콜)은 종종 사람들 간의 중요한 통신에 의지하며 발신자가 이메일 수신자 이외의 당사자가 사용할 수 있도록 원하지 않을 수 있는 민감한 금융, 건강 관련, 전략, 또는 법적 정보를 전송하거나 작업을 수행하도록 지시하는데 사용된다.

많은 주, 국가 및 산업에서, 표준 이메일 전송보다 더 사적인 방식으로 전자 메시지를 전송하는 시스템을 사용하여 특정 정보의 발신인에게 정보를 전송하도록 요구하는 규정이 있다. 일 예는 의료 정보 보호를 위한 데이터 프라이버시 및 보안 조항을 제공하는 1996년의 전자 의료 보험 청구법(Health Insurance Portability Accountability Act, HIPAA)이라는 제목의 미국 의료 프라이버시 규정이다. 다른 예는 이메일 프라이버시 준수를 위한 규정을 포함하는 유럽 일반 데이터 보호 규정(European General Data Protection Regulation, GDPR)이다. GDPR은 요구 사항을 충족해야 하는 방법보다 규정 준수를 통해 달성해야 할 사항을 정의한다. 결과적으로 이메일을 암호화하는 특정 방법을 사용하는 요구 사항은 언급되지 않지만 소비자 비공개 및 개인 정보 취급자는 해당 정보의 프라이버시를 유지 관리할 뿐만 아니라 프라이버시 요구사항의 준수를 입증할 수 있는 능력도 포함한다. 이러한 요구사항은 GDPR 5조 1(f) 및 2, 32조 1(a) 및 1(d)에 자세히 설명되어 있으며, 이는 개인 데이터 보호 사실을 입증할 수 있는 능력과 함께 전송 중에 개인 데이터를 보호해야 한다는 요구 사항에 중점을 둔다.

일반 이메일 및 전자 메시지 시스템 사용자는 전자 메시지(이메일은 전자 메시지 전송 프로토콜을 사용하여 전송되는 모든 전자 메시지 참조)를 보내고, 받고, 읽고, 회신하고, 전달하는 방법을 알지만, 일반 이메일 사용자는 더 안전하거나 사적인 방식으로 이메일을 전송하는 방법 및 표준 이메일과 비교하여 더 안전하거나 사적인 방식을 사용하여 메시지가 전송되는지 또는 전송되었는지 확인하는 방법을 모른다. 이메일을 수신하면 일반 이메일 사용자는 해당 이메일이 보안 전송 또는 암호화된 전송을 사용하여 수신되었는지 확인하는 방법을 모른다. 일반 이메일 사용자는 수신자가 보안 전송으로 보내진 내용의 수신을 보호하고 이메일 스레드에 있을 수 있는 원래 보내진 내용을 노출하고 불안정하게 응답하는 것으로부터 이를 보호하는 방법을 모른다.

고급 이메일 사용자는 이메일을 자동으로 필터링하여 특징 폴더에 배치하거나 이메일에 다양한 중요도를 표시하도록 그 이메일 프로그램을 구성할 수 있다. 고급 이메일 사용자는 표준 이메일 전송보다 더 개인적인 방식으로 이메일을 전송하도록 시스템을 설정할 수 있으며; 표준 이메일 전송은 SMTP, ESMTP, SMS, SMPP, MMS, HTTP, HTTPS 및 SSL, TLS 등과 같은 조합을 사용하여 보내지는 전자 메시지 전송으로 정의된다.

이러한 이메일 사용자 또는 그 이메일 운영자 중 일부는 기존 이메일 프로그램 내에 제3자의 프로그램 또는 암호화 키를 설치하여 이메일과 관련된 다양한 알려진 일반적인 보안 위협을 처리하는데 도움을 줄 수 있다. 사용자(이메일의 발신자 및/또는 수신자) 또는 이메일 시스템 관리자는 이메일 서버, 이메일 게이트웨이 또는 이메일 사용자 인터페이스(일반적으로 “이메일 클라이언트”라고 함)에서 소프트웨어를 추가하거나 설정하게 할 수 있다. 이러한 추가 기능 소프트웨어 프로그램은 표준 메시지 프로토콜을 사용하는 것보다 더 개인적인 방식으로 메시지를 전송하는 옵션을 추가할 수 있다. 일부 사용자는 메시지를 검색하거나 보는 링크를 보내는 보안 서버에 메시지를 업로드하도록 선택될 수 있으며, 일부는 웹 브라우저에서 안전하게 액세스된 보안 프로그램에서 메시지를 작성한 다음 전송하도록 선택될 수 있다. 일부 시스템은 SOAP, REST, EDI 교환 프로토콜과 같은 프로토콜을 포함하는 보안 응용 프로그래밍 인터페이스를 사용하여 전송할 수 있다.

표준 이메일 전송 프로토콜을 사용하는 것보다 더 개인적인 방식으로 메시지를 전송하는 다양한 방법이 있다. 이러한 방법 중 일부는 TLS, SSL 또는 HTTPS와 같은 보안 연결을 사용하거나 사용하지 않고 PGP, PKI, AES 256 비트, PDF, 링크 검색, HTML 래퍼 등을 사용한다. EDI, SMS, MMS 등을 포함하는 보안 메시지 시스템에는 다른 프로토콜이 있다.

전자 메시지 전송을 암호화하는 일부 일반적인 방법은 다음과 같이 요약된다:

A. PKI: 메시지를 보내기 전에 발신자와 수신자 사이에 공유되는 발신자와 수신자 디지털 인증서에 의해 생성된 공개 암호화 키의 교환. 이들 “키”는 종종 Microsoft Outlook 프로그램에 저장된다. 사용하려면 일반적으로 Microsoft Outlook 전체 데스크톱 설치 또는 Lotus Note와 같은 고급 이메일 프로그램이 있는 발신자와 수신자가 필요하다; 일반적으로 Gmail, Outlook.com 또는 웹 이메일 프로그램이 아니다.

B. PGP: 발신자와 수신자에 의해 생성된 키의 교환. 일반적으로 발신자와 수신자는 이러한 유형의 암호화를 처리하기 위해 키 교환 또는 사용자 간의 정교함을 관리하도록 구성된 이메일 프로그램이 필요하다. 일부 서비스에서는 이를 보다 쉽게 사용할 수 있도록 시도한다.

C. PDF: AES 128 비트 또는 256 비트 PDF 암호화, 여기서 메시지는 PDF 포맷으로 인쇄되고, 첨부물은 기본 포맷으로 포함되며, PDF는 메시지 본문 및 모든 첨부물에 대한 암호화된 래퍼(wrapper) 역할을 한다. 암호화된 PDF 파일은 수신자에게 전달된 이메일에 첨부되며 메시지는 암호화된 PDF 파일 첨부물에 있는 동안 수신자 받은 편지함(recipient inbox) 내부에서 암호화된 상태로 유지된다.

D. TLS: 보안 암호화된 전송을 통해 발신자 서버에서 수신자 서버로 연결하는 전송 계층 보안. 이는 수신자 서버에 대한 메시지만 보안화되고 수신자 서버가 이 옵션(유비쿼터스하거나 확실하지 않음)으로 작동하도록 구성되어야 한다. 또한, 이전 프로토콜 보안 소켓 계층(Secure Sockets Layer, SSL), TLS 1.0, TLS 1.1, TLS 1.2 및 TLS 1.3 이상으로 시작하는 TLS의 다양한 반복이 있다.

E. 링크 검색: 발신자가 이메일을 보내는 저장 및 전달 시스템, 이는 중간 서버에 저장되고 중간 서버가 메시지를 검색하기 위한 링크가 포함된 이메일을 보낸다. 링크는 종종 수신자가 계정에 가입하고, 보낸 메시지를 보고 다운로드하는데 필요한 몇 가지 필수 단계를 거치는 요청을 포함한다. 이는 수신자가 다운로드하고 검색하는 단계를 거치기를 기다리는 동안 제3자가 메시지를 저장해야 한다.

F. HTML 래퍼: 발신자가 이메일을 보내며, 이는 중간 서버에 저장되고 중간 서버가 HTML 파일이 첨부된 이메일을 보내며, HTML 파일은 메시지와 모든 첨부물이 암호화되어 있으므로 크기가 크다. 수신자가 HTML 파일을 클릭하면, 수신자가 계정에 가입하기 위해 웹페이지로 이동하는 경우가 많다. 몇 가지 필수 단계를 거친 후, 메시지는 수신자(HTML 래퍼 파일로부터)에서 보내는 서버(또는 중간 서버)로 다시 전송된 다음 보내는 서버(또는 중간 서버)로부터 브라우저에 표시되며, 수신자가 원래 보낸 메시지를 보고 다운로드할 수 있다.

G. 파일 공유: 사용자/발신자가 문서를 온라인 저장 영역에 업로드한 다음 수신자에게 온라인 폴더에 대한 액세스 권한을 부여하여 필요한 수신자 암호 또는 계정 액세스 권한으로 자주 파일을 보고 다운로드하도록 하는 시스템.

표준 이메일 메시지보다 더 안전한 방식으로 전자 메시지를 전송하는 위의 방법은 사용된 다양한 방법의 간략한 요약이며 하나의 프로토콜이나 방법의 완전한 설명을 의도하지 않으며, 사용될 수 있는 다른 방법이 있다.

정보 프라이버시 침해에 대한 인식이 높아지고 민감한 비공개 소비자 정보를 보호하기 위한 정보의 관심과 함께 규제 기관은 발신자 또는 발신 조직이 의도하지 않은 수신자, 도청자(eavesdropper) 또는 인터넷 도둑에 우발적인 공개로부터 전송된 정보를 보호하는 전송 방법을 사용하도록 요구하는 프라이버시 규정을 만들었다.

이러한 규정은 일반적으로 특정 전달 방법을 지정하지 않지만 일반적으로 전송된 정보의 프라이버시를 보장하는 방법을 사용할 필요가 있음을 말하고 일부는 전송된 정보의 프라이버시를 보장하는데 사용된 방법을 입증하기 위해 감사 준비 기록을 유지할 필요가 있음을 말한다.

미국의 주요 연방 데이터 프라이버시 규정 중 하나는 HIPAA이다. 유럽에서는 일반 데이터 보호 규정(GDPR), 규정((EU) 2016/679)이 더 나아가 '데이터 프라이버시 준수의 증거'; 책임이 GDPR 지침의 중요한 요구사항이기 때문에 더 나은 메시지 단위로 자동화되고 입증 가능한 증거(GDPR 5조 1 & 2항 및 32조 1항에 설명된 바와 같음)의 중요성을 강조한다. 유럽 이외의 다른 국가에 있는 미국 주 규제 기관 및 의원이 유럽의 GDPR 규정을 모델로 한 새로운 프라이버시 규정을 채택하는 추세에 있다.

규정으로 인해, 점점 더 소비자 정보를 다루는 기업은 정보를 안전하게 전송할 뿐만 아니라 규정을 준수하고 안전한 이메일 전달에 대한 감사 가능한 증거를 유지해야 한다. 많은 기업의 경우, 새로운 요구사항에 따라 이메일 암호화 서비스를 완전히 변경해야 할 것이다. 규정 준수 감사 및 데이터 침해의 혐의 가능성을 처리하려면 암호화 규정 준수에 대한 감사 가능한 증거가 필요할 것이며; 특히 벌금이 규제 기관이 부과하겠다고 선언한 만큼 가파르게 판명될 때 더욱 그렇다.

인터넷 도청자 및 인터넷 범죄자가 고도로 정교해짐에 따라 마이크로 대상(micro-target) 사용자 또는 회사에 대한 능력에서 비공개 전략 또는 규제된 개인 정보(건강 관련 또는 재무)를 다루는 기업은 정보를 안전하게 전송할 뿐만 아니라 가시성과 추적을 유지하여 정보를 더 안전하게 전송하도록 설계된 시스템이 실제로 보안 이메일 전달로서 메시지를 전송하였는지 확인하고; 규정 준수 보안 전달의 감사 가능한 증거를 유지해야 한다. 사용자는 규정 준수 담당자 및 시스템 관리자와 마찬가지로 중요한 컨텐츠의 암호화된 전달, 수신 또는 수정 사실에 대한 가시성을 원할 것이다. 많은 기업의 경우 새로운 요구사항에 따라 이메일 암호화 서비스를 완전히 변경해야 할 것이다. 규정 준수 감사 및 데이터 침해의 혐의 가능성을 처리하려면 암호화 규정 준수에 대한 감사 가능한 증거가 필요할 것이며; 특히 벌금이 규제 기관이 부과하겠다고 선언한 만큼 가파르게 판명될 때 더욱 그렇다.

대상이 될 주요 산업은 제3자 소비자 금융 또는 건강 정보를 다루는 산업이다. 일반적으로 소비자 건강 관리 및 금융 서비스(은행, 대출, 투자 자문, 보험, 주거용 부동산 등)를 다루는 기업 및 인적 자원, 재무, 회계 및 고객 서비스와 같은 기능적 기업 영역이다. 또한, 변호사는 이메일 응답으로부터 내용 수정의 기능에 관심을 가져야 하는데 이는 민감한 정보의 노출로부터 보호하고 일반적으로 문서의 내용 수정을 사용하는 것으로부터 '수정'이라는 용어에 익숙하기 때문이다.

특히, GDPR의 일부는 암호화된 전달의 기록을 유지하는 중요성을 강조한다: 보안, 기밀성 및 책임에 대한 5조, 보안을 보장하기 위한 기술적 조치의 효율성 평가 및 암호화에 대한 32조.

5조 1(f)항은 “개인 데이터는 적절한 기술적 또는 조직적 조치('무결성 및 기밀성')를 사용하는 … 개인 데이터의 적절한 보안을 보장하는 방식으로 처리되어야 한다”를 언급하는 개인 데이터의 기밀성을 유지하는 것에 대해 말한다. 5조 2항은 “컨트롤러는 단락 1('책임')에 대해 책임을 지며 준수를 입증할 수 있어야 한다”를 언급하는 개인 데이터의 기밀 처리 준수에 대한 입증 가능한 증거를 유지해야 할 필요성을 생성한다.

32조 1(a)항은 “컨트롤러 및 프로세서는 특히 적절한 경우를 포함하여 위험에 적절한 보안 수준을 보장하기 위해 적절한 기술적 및 조직적 조치를 구현해야 한다: (a) 개인 데이터의 익명화 및 암호화”를 언급하는 개인 데이터를 보안화하기 위한 암호화의 사용을 지정한다. 32조 1(d)항은 처리의 보안을 보장하기 위한 기술적 및 조직적인 조치의 효과를 정기적으로 테스트 및 평가를 위한 프로세스”를 언급하는 처리의 보안을 보장하게 하는 정기적인 평가에 대해 말한다.

전송된 전자 정보의 프라이버시를 보호하는 측면에서 고려해야 할 많은 우려 사항이 있다:

A. 가로채기(interception)로부터의 보호 - 수신자의 서버, 공급자 또는 설정에 관계없이 인터넷을 통해 전송 중인 메시지를 보호한다. 이는 또한 수신자 서버가 항상 또는 간헐적으로 TLS 전송을 수락할 수 없다고 보고하는 경우 다른 암호화된 전달 방법으로 구축된 고장 시 조치(built-in fall back)가 없을 때 가장 성공적인 TLS 다운그레이드 공격과 같은 표준 TLS 서버 전송을 무력화하는 일반적인 가로채기 전술로부터 보호해야 한다.

B. 도청자로부터의 보호 - 메시지가 발신자 조직을 통해 발신자로부터 전송될 대 그리고 수신자 목적지로 통해 전송될 때 메시지를 보호하는 옵션. 도청자의 다양한 범주가 있다 - 이는 발신자 또는 수신자 조직 내부의 호기심 많은 직원, 인터넷 범죄자 또는 이메일에 액세스할 수 있는 아웃소싱 제공자의 관행이 될 수 있다. 후자의 예에서, 수신자가 Gmail을 사용하고 발산자의 메시지가 수신자의 이메일 제공자(이 경우에 Gmail)로 암호화되는지 고려한다. 이 예에서, 수신자의 제공자는 마케팅 사용자 정보에 의존하는 것으로 알려진 무료 이메일 서비스를 제공한다. 수신자에서의 메시지 내용은 Google에서 분석하여 요소를 기록하고 서비스를 “개선”하는 시점에서 프로필을 판매한다(수집된 다른 데이터 및 이메일 주소와 연관된 이메일의 내용을 기반으로 한 발신자 및/또는 수신자의 마케팅 프로필이라고도 함).

C. 사회 공학적 유출로부터의 보호 - 데이터 보호 계획은 또한 첨부된 민감한 데이터로 응답하도록 유혹하는 인적 자원, 금융 또는 고객의 민감한 정보를 다루는 다른 스태프가 수신한 사기 이메일로부터 보호하는 방법을 고려해야 한다. 일반적인 수법은 인터넷 범죄자가 직원인 척하여 급여나 세금 정보를 요청하는 이메일을 인사부에 보내고, 응답 이메일은 정보를 갖는 스태프의 응답이 모르게 인터넷 범죄자로 라우팅되도록 구성된다. 기술 산업에서는 이를 '스피어 피싱(spear-phishing)”에 대한 보다 사회적으로 설계된 접근 방식인 “포경(whaling)” 공격이라고 말한다. 연방 수사국(Federal Bureau of Investigation)은 이를 비즈니스 이메일 침해 공격이라고 말한다. 최상의 솔루션은 이렇나 유형의 사회 공학 데이터 유출을 감지한다.

D. 자동화된 규칙 - 일부는 제목 필드의 키워드와 같이 보내기 전에 메시지에 추가된 내용을 사용하거나 서버에 추가된 내용 정책에 메시지 내용의 일치를 기반으로 하는 메시지를 암호화하도록 서버에 직접 지시하는 옵션을 선호할 수 있다.

그리고 사적으로 정보를 전송하는 수단의 사회적 요소도 고려되어야 한다:

A. 사용하는 만큼 간편함 - 발신자에게 서비스가 너무 복잡하면 발신자가 궁극적으로 서비스를 사용하지 않을 수 있다. 예를 들어 발신자가 의도한 수신자와 암호화 키 또는 인증서 교환에 참여해야 하는 경우 서비스 사용이 크게 제한된다. 사용의 단순성은 오늘날의 기업 환경에 필수적이다.

B. 불만을 피하는 수신자에 대한 간편함 - 서비스가 수신자에게 번거로운 경우, 예를 들어 메시지를 검색하기 위해 계정을 설정하는데 수많은 단계를 요구하는 경우, 수신자는 자연스럽게 발신자에게 불평하거나 발신자의 중요한 메시지를 받지 못할 수 있다. 이는 발신자가 전달의 증거가 필요한 개인 정보, 예를 들어 고객 계정, 투자 리스크 공개 등과 관련된 정보를 보낼 때 매우 중요하다. 이러한 경우 포털에 업로드하거나 검색할 복잡한 프로세스가 포함된 링크를 보내는 것은 수신자에게 정보를 전달하지 않을 가능성이 높을 것이며 전달 또는 알림 요구 사항을 성공적으로 준수하지 않을 수 있다.

C. 안심(peace of mind) - 발신자에게 전달 증거, 암호화된 전달 사실의 증거를 제공하고; 발신자가 민감한 정보로 취급하고 이를 수신자에게 안전하게 전송하도록 선택된 사실의 가시적 표시를 수신자에게 제공함. 예를 들어, TLS를 단순하게 사용하면 이 중 어느 것도 수행하지 않는다.

D. 저장 없음 - 대부분의 회사는 메시지가 침해될 수 있는 다른 위험을 생성하기 때문에 전송 중에 메시지가 저장되는 다른 위치가 없는 것을 선호한다. 중간 저장 서버 보안은 모니터링 되어야 하며, 이는 중간 서버의 데이터 보존 및 삭제 기술에 따라 후속 데이터 액세스에 대한 잠재적인 지점을 생성한다. 예를 들어, 파일 공유 서비스를 사용하여 민감한 문서를 전송하는 경우 사용자는 전송 후 문서를 삭제하기 위해 거의 돌아오지 않는다. 문서는 공유된 링크에서 장기간 액세스할 수 있다. 또한, 링크 검색 보안 e-전달 시스템은 장기간 동안 문서가 검색될 때까지(그리고 절대 그렇지 않을 수 있음) 또는 검색하더라도 최적의 삭제 프로세스가 없을 때까지 중간 서버에 사본을 종종 저장한다. 이는 민감한 데이터를 불필요하게 노출시킬 수 있다.

E. 사용자 부주의 - 수신된 민감한 정보에 응답하는 수신자로부터의 보호. 민감한 데이터는 이메일 스레드에 남겨 놓고 응답은 안전하지 않게 전송되거나 발신자가 해당 유형의 메시지 또는 메시지 내용 부분에 대해 원하는 보안 수준 없이 전송된다.

보다 안전한 방식으로 메시지를 전송하는 것을 고려하고 준수 이유(데이터 프라이버시 규칙 준수)를 위해 그렇게 하는 경우 암호화된 전달 사실의 기록을 유지할 수 있는 방법; 발신자가 감사 준비 데이터 프라이버시 준수 증거를 유지할 수 있는 방법을 고려해야 한다. 일반 데이터 보호 규정(GDPR), 규정((EU) 2016/679), 예를 들어 최대 2천만 유로의 전 세계 매출의 최대 4%의 벌금을 부과한다. 전 세계 매출의 퍼센티지와 관련된 벌금의 가능성을 고려하여, 규정 준수 컨설턴트는 '데이터 프라이버시 준수의 증거'; 책임이 GDPR 지침의 중요한 요구사항이기 때문에 더 나은 메시지 단위로 자동화되고 입증 가능한 증거(GDPR 5조 1 & 2항 및 32조 1항에 설명된 바와 같음)의 기록 유지의 중요성에 대해 고객에게 교육해야 한다. 미국 및 다른 주 및 국가 규제 기관은 향후 이러한 가이드라인을 따를 가능성이 높다. 산업 그룹은 안전한 데이터 전송 및 증명을 위한 산업 모범 사례를 개발할 가능성이 높다.

데이터 침해에 대한 GDPR 벌금의 중요성으로 인해 발신자 조직은 메시지 단위로 암호화된 전달 사실의 감사 준비 증거를 확보해야 한다. 단순히 “정책”을 가지고 있다고 해서 정책이 제대로 작동하는 것을 의미하지는 않는다. 예를 들어, 정책은 TLS를 통해 전송을 자동화할 수 있지만 이것이 메시지가 TLS를 통해 갔다는 것을 의미하지는 않는다(TLS 다운그레이드 공격 고려). 이는 몇 달 또는 몇 년 후 분쟁이나 침해를 조사할 때 서버가 제대로 작동했다는 것을 의미하지 않는다. 규정 준수 검토, 규정 준수 감사에서 쉽게 입증되거나 발신자가 데이터 침해를 고발하는 경우(수신자의 시스템에 데이터 침해가 있거나 수신자가 메시지를 전달한 후 일어날 수 있음) 메시지별로 감사 준비 증거가 가장 바람직하다.

많은 회사가 보안 전송을 위해 TLS 전달에 의존하지만 많은 회사와 이메일 서비스 제공자는 그렇지 않거나 TLS의 안전하지 않은 버전으로 간주되는 것(즉, TLS 1.0)을 사용한다. 2019년 1월 14일 블로그에서 Microsoft는 2018년 10월 31일부로 Office 365는 더 이상 TLS 1.0 및 1.1을 지원하지 않을 것이다” 그리고 “클라이언트, 장치 또는 서비스에서 발견되는 새로운 문제를 수정하지 않을 것”이라고 보고했다. 그러나, 이러한 수준의 TLS로 수신자에게 계속해서 전달할 것이다라고 언급했다. https://docs.microsoft.com/en-us/office365/secu ritycompliance/technical-reference-details-about-encryption#TLS11and12deprecation를 참조한다.

Microsoft는 2018년 8월 16일에 “인사이트는 커넥터에 대한 잠재적인 TLS 암호화 문제에 대한 주의를 환기시키는데 도움이 되는 커넥터를 가리킨다. 인사이트는 25%를 초과하는 TLS가 없거나 50%를 초과하는 TLS 1.0이 없다. 이러한 인사이트가 보이면 커넥터와 연관된 이메일 서버를 조사하거나 파트너 조직에 연락해야 한다”라고 보고했다. https://docs.microsoft.com/en-us/office365/securitycompliance/mfi-outbound-and-inbound-mail-flow(2019년 3월 6일)

Microsoft는 2019년 8월 6일에 아웃바운드 및 인바운드 메일 흐름 위젯을 사용하여 결정된 결과에 대해 논의했다. 위젯을 예시적인 기업으로 적용하여, 위젯은 8458 아웃바운드 및 6292 인바운드 메시지가 TLS 1.2 이상에 의해 보호되는 것으로 보고했다. Microsoft는 이와 같은 데이터를 활용하여 TLS 1.0 및 1.1에 대한 지원 중단을 지원했다.

Zafar Khan이 작성한 RPost 블로그는 Microsoft Insight와 유사한 결론을 갖는 Google 이메일 투명 보고 데이터(https://transparencyreport.google.com/safer-email/overview?hl=en)의 통계를 인용하여 “Not All TLS is Created Equal”이라는 제목의 이것을 2018년 12월 7일에 논의했다(https://www.rpost.com/news/not-tls-created-equal/).

Google은 TLS 암호화와 그 문제에 대한 설명을 다음과 같이 요약한다: “이메일이 전송 계층 보안(TLS)이라고 하는 보안 프로토콜로 전송 중에 암호화될 때, 다른 사람이 너가 보낸 것을 읽기 더 힘들어질 것이다. 점점 더 많은 수의 이메일 제공자가 전송 중인 이메일 메시지를 암호화하기 위해 일한다. 여기에 있는 데이터는 전송 중인 이메일 암호화의 현재 상태를 보여준다. 많은 이메일 제공자는 전송 중인 메시지를 암호화하지 않는다. 이러한 공급자 중 하나를 통해 이메일을 보내거나 받을 때 너의 메시지는 메일의 포스트카드로서 스누퍼(snooper)에게 공개된다. 점점 더 많은 수의 이메일 공급자는 전송 계층 보안(TLS)을 사용하여 그들의 서비스에서 주고 받는 메시지를 암호화하여 이를 변경하기 위해 일한다. 일반적으로 더 많은 공급자가 지원을 활성화하고 유지함에 따라 전송 중 암호화 사용은 시간이 지나면서 계속 증가한다. 변하는 이메일 양과 같은 요인이 이러한 암호화 통계의 다른 변동을 설명할 수 있다”. https://transparencyreport.google.com/safer-email/overview?hl=en을 참조한다.(2019년 3월 6일)

암호화 작동 방법:

당신이 친구에게 편지를 보낸다면, 당신은 그녀가 편지를 읽는 유일한 사람이 되기를 바랄 것이다. 그러나 당신으로부터 그녀에게 가는 도중에 편지에 많은 일이 일어날 수 있고 그것을 읽으려고 하는 엿보는 눈이 있을 수 있다. 그렇기 때문에 중요한 메시지는 포스트카드 뒷면이 아닌 봉투에 밀봉하여 보낸다. 이메일 보내기 받기도 비슷한 방식으로 작동한다. 그러나 보안 연결을 통해 메시지를 전송하지 않는 이메일 공급자와 메시지를 보내거나 받으면 이메일이 스누핑(snooping)에 공개될 수 있다.

전송 계층 보안(TLS)

전송 계층 보안을 사용한 암호화는 메시지가 전송되는 동안 메시지에서 엿보는 눈이 멀어지게 유지한다. TLS는 인바운드 및 아웃바운드 메일 트래픽 모두에 대해 메일을 안전하게 암호화하고 전달하는 프로토콜이다. 이는 메일 서버 사이의 도청을 방지하여 이메일 공급자 사이에 이동하는 동안 메시지를 비공개로 유지한다. TLS는 보안 이메일의 표준으로 채택된다.

암호화는 모든 사람에게 달려 있다.

당신 및 당신과 이메일을 교환하는 사람이 모두 전송 계층 보안을 지원하는 이메일 제공자를 사용하는 경우에만 당신의 메시지는 암호화된다. 모든 이메일 제공자가 TLS를 사용하는 것은 아니며, 그렇지 않은 제공자로부터 메시지를 보내거나 받으면 도청자가 당신의 메시지를 읽을 수 있다. TLS가 완벽한 솔루션은 아니지만 모든 사람이 TLS를 사용한다면 이메일 스누핑이 오늘날보다 더 어렵고 비용이 많이 들 것이다.

Microsoft 보고와 마찬가지로 Google은 호스팅된 이메일 서비스(예를 들어, Microsoft Office 365, Google Gmail 및 Google G-Suite)의 모든 메시지 인바운드 및 아웃바운드 트래픽에 대한 집계 통계를 추적한다. 예를 들어, Google은 처리한 인바운드 및 아웃바운드 트래픽의 92%가 2019년 12월 6일부터 2019년 3월 6일의 기간 동안 암호화되었다고 보고했다. 또한, Microsoft와 Google은 도메인당 집계에서 인바운드 및 아웃바운드 메시지의 암호화를 추적하는 기능을 제공한다.

많은 소프트웨어 서비스 영업 전문가는 사이버 보안을 단순하게 만들기 위해 보안 문구를 사용한다. 오늘날 기술이 발전하고 위협이 점점 더 정교해짐에 따라 프라이버시 규정 준수를 위해 이메일을 암호화하는 것이 더 이상 간단하지 않다. 해커는 세부 사항에 주의를 기울인다.

여기에서는 보안을 위해 일반적으로 참조되는 모든 것, TLS를 캐치하도록 해독하고, 세부 정보가 중요한 이유를 설명하려고 할 것이다. “모든 TLS가 동일하게 생성되는 것은 아니다. 생각하는 모든 이메일이 TLS를 통해 전송되는 것은 아니지만 실제로는 안전하게 전송된다”고 보험 기술 전문가이자 33만명 초과의 팔로워를 보유한 LinkedIn 인플루언서인 Steve Anderson이 언급한다.

먼저, TLS란 무엇인가? TLS는 전송 계층 보안을 나타낸다. 이는 간단히 말해서 두 참여 장치 간의 통신을 암호화하는 수단이다. 이는 주로 웹 브라우저에서 웹 서버로 통신할 때 사용된다. 브라우저에서 “안전하지 않은” 연결, 팝업 경고를 표시하거나 페이지 표시를 비활성화하는 것은 간단하다.

그러나, 이메일에는 더 많은 문제가 있다. Chrome 브라우저를 통해 Gmail에 로그인하면 장치로부터 Google 이메일 서버로의 연결이 이러한 방식으로 보호된다. 그러나 보내기를 누른 후 이메일이 Google의 Gmail 서버로부터 수신자에게 향할 때 이메일은 어떠한가? 이것은 “기회적 TLS(Opportunistic TLS)”가 사용되거나 사용되지 않을 수 있다. 이는 기본적으로 많은 주요 이메일 공급자(Microsoft Hosted Exchange Office 365, Gmail 등)에서 사용된다.

먼저 대부분의 사용자에게 이메일의 가장 중요한 부분인 이메일이 의도된 수신자에게 전달된다는 사실을 상기해보자. 전통적으로, 그 수신자에게 “오직 보이는지 여부는 나중에 고려되었다.

기회적 TLS를 입력한다. 여기서 발신 서버인 Gmail은 “기회”가 나타나면 보안 TLS 이메일 전송(SMTP)으로 먼저 전송을 시도하고, 두 번째로 안전하게 전송할 수 없으면 덜 안전하거나 안전하지 않은 자동 및 보이지 않는 전송으로 되돌아간다.

꽤 좋게 들린다; 이메일을 수신하는 사람은 누구나 같은 마음가짐을 갖고 있으며 보안 연결을 통해 Gmail에서 보내는 이메일을 수락할 것이다. 그런가? 아니다.

현재 지속적으로 업데이트되는 Gmail 투명성 보고서에 따르면 Gmail로 들어오고 나가는 이메일의 88 내지 91%가 TLS를 사용하여 전송된다. 이는 일반적으로 10% 초과가 보안 없이 전송 및 수신됨을 의미한다. 따라서 Gmail을 통해 보내거나 받을 수 있는 메시지 10 개 중 1 개는 보안 없이 그냥 나가게 된다. 이는 Office 365 호스팅된 이메일과 유사할 수 있다.

안전하지 않은 10 개 중 1개는 나쁘지 않다고 생각할 수 있다. 그러나 훨씬 더 나쁠 수 있음을 고려한다. 위의 보고에 따르면, 미국의 Charter.net 호주의 Bigpond, 캐나다의 Bell을 통한 Videotron과 같은 많은 수신자 이메일 도메인의 경우; 이러한 도메인에서 Gmail로 주고받는 이메일은 암호화되지 않으며(0%) Amazon과 같은 회사의 경우 57%가 보호된다. 수많은 소규모 회사는 어떤가? 그들은 아마존보다 더 나은 보안을 가지는가? (2018년 12월 Google의 투명성 보고서에서 보고된 데이터).

여기에 오류가 있다. 이러한 투명성 보고서 중 어느 것도 안전하지 않은 TLS로 간주되는 많은 TLS 연결을 구분하지 않는다. 일반적으로 보안이 다양한 버전이 있다; TLS 1.0, TLS 1.1, TLS 1.2 및 현재 TLS 1.3.

TLS 1.0에 초점을 맞추면 알려진 위험이 있다. 특히 TLS 다운그레이드 공격. 간단히 말해서, 해커는 서버간 통신에 앞서 TLS 1.0 검사를 가로채서 보내는 서버가 안전하지 않은 방식으로 메시지를 보내도록 속일 수 있다. 보안 전문가는 10년 이상 IT 관리자가 TLS 1.0으로부터 업그레이드하도록 노력해왔다; 그러나 이것의 사용은 여전히 대체로 지속된다; 일반적으로 모든 TLS 이메일 연결의 15% 초과를 차지한다. 따라서 10%는 비보안(TLS 없음)으로 전송되고 15%는 알려진 보안 문제가 있는 TLS 버전으로 전송될 수 있다. 이제 최소한 이메일의 25%(4 개 이메일 중 1 개)에 문제가 있다. 소규모 회사의 고객, 개인과 통신하는 경우 비율이 더 높을 수 있다. 문제는 무엇을 할 것인가? 이다.

Microsoft는 2018년 블로그 게시물에서 더 이상 TLS 1.0을 지원하지 않을 것이라고 하면서, “이는 Office 365가 TLS 1.0 및 1.1 연결을 막는 것을 의미하는 것은 아니다. 고객 [이메일] 연결을 위한 TLS 서비스에서 TLS 1.0 및 1.1을 비활성화하거나 제거하는 공식 날짜는 없다”라고 언급했다. 그리고 기억하면, TLS 1.0은 일부 서클(즉, PCI 금융 규정 준수 표준)의 규정을 준수하지 않는 것으로 알려져 있다. HIPAA는 어떻습니까? PII는? NPI는? GDPR은 프라이버시를 준수합니까? TLS 1.0에 알려진 취약점이 있는 경우 “프라이버시 규정을 준수하는” 전송 수단으로 간주되지 않을 수 있다. 시간이 말해줄 것이다.

결론은 Microsoft Office 365, G-suite 및 다른 “기회적 TLS” 시스템이 이메일의 최소 25%를 보안 없이 또는 (프라이버시) 규정 준수 방식보다 적은 불안정한 방식으로 보낼 가능성이 있다는 것이다. (Microsoft가 바람직하지 않다고 지적한 것과 같이) 이메일을 전혀 전달하지 않는 옵션이 있기 때문에 이러한 시스템에 대한 쉬운 수정은 없으며, 이는 발신자와 수신자에 대해 혼란을 야기할 것이다. 블로그 게시물에서 그들은 전혀 전달하지 않는 것보다 안전하지 않은 전달을 선호하는 것으로 보인다.

해야할 일: 자동 대체 기능이 있는 기회적 TLS

필요한 것은 Gmail, Office 365, Zimbra 또는 임의의 이메일로의 애드 온(Add on)이다. 이는 사용하기 간단한 서비스로 TLS를 사용할 수 없거나 TLS의 안전하지 않은 버전이 있는 경우 발신자나 수신자를 귀찮게 하거나 부담을 주지않고 동적으로 통신이 자동으로 이메일 전송 암호화의 대안적인 방법으로 되돌아간다.

제3자 확인 가능한 증거의 중요성은 특히 수신자가 데이터 침해가 발생했다고 주장하는 경우 발신자 조직을 보호한다. 도 3에 도시된 바와 같이 2017-2018 RPost 조사는 RPost 서비스 구독자를 대상으로 Khan에 의해 행해졌으며, 대다수의 사용자는 프라이버시 규정 준수를 위해 이메일 암호화를 사용했다.

설문 응답자에 따르면 가장 중요한 기능 중 하나는 도 4에 도시된 그래프에 의해 설명되는 바와 같이 전달의 증거 및 프라이버시 규정 준수를 제공하는 수신이다. RPost 시스템 수신은 전달의 증거가 있는 수신을 제공한다. RPost 시스템 수신은 또한 메시지가 특정 암호화 서비스와 함께 전송되도록 선택되었음을 나타낸다. RPost 시스템 영수증은 특정 전송과 관련된 서버 전송 기록의 일부를 포함한다.

발신자 조직이 전 세계적으로 의미있는 수익을 창출하고 규지 기관이 데이터 침해에 대한 벌금의 퍼센티지로 “내부 고발자(whistleblower)” 보상을 제공하는 경우, 발신자는 모든 침해 주장이 메시지가 수신자의 시스템에서 안전하게 수신된 후(또는 메시지를 전달한 후) 발생했다는 입증하기 쉬운 제3자 증거를 보유해야 한다. 내용이 암호화되어 성공적으로 전달되었음을 인증할 수 있고 데이터 침해 혐의의 위험을 완화하는 증거를 제공할 수 있는 메시지 기반의 기록을 갖는 것이 바람직하다. 이는 보내는 조직이 대상이 되는 것을 최소화할 수 있다.

설명의 목적을 위해, 본 개시의 완전한 이해를 제공하기 위해 특정 명명법이 제시된다. 특정 애플리케이션 및 방법의 설명은 예로서만 제공된다. 실시예에 대한 다양한 수정은 당업자에게 용이하게 명백할 것이며, 본 명세서에 정의된 일반적인 원리는 본 개시의 사상 및 범위를 벗어나지 않고 다른 실시예 및 애플리케이션에 적용될 수 있다. 따라서 본 개시는 도시된 실시예로 제한되도록 의도되지 않고, 본 명세서에 개시된 원리 및 단계와 일치하는 가장 넓은 범위가 부여되어야 한다.

다음 설명에서, 본 개시의 완전한 이해를 제공하기 위해 다수의 특정 세부사항이 제시된다. 그러나, 본 개시는 이렇나 특정 세부사항 없이 실시될 수 있다는 것이 당업자에게 명백할 것이다. 다른 예에서, 잘 알려진 구성요소 또는 방법은 본 개시를 불필요하게 모호하게 하는 것을 피하기 위해 블록도 또는 개략도로 설명되었다. “제1 드라이버”와 같은 추가 특정 숫자 참조 번호가 만들어질 수 있다. 그러나, 특정 숫자 참조 번호는 문자 그대로의 순차 순서로 해석되어서는 안되며 오히려 “제1 드라이버”가 “제2 드라이버”와 다른 것으로 해석되어야 한다. 따라서, 설명된 특정 세부사항은 단지 예시일 뿐이다. 특정 세부사항은 본 개시의 사상 및 범위 내에서 변경될 수 있고 여전히 고려될 수 있다. “결합된”이라는 용어는 구성요소에 직접 연결되거나 다른 구성요소를 통해 구성요소에 간접적으로 연결된 의미로 정의된다.

설명 전체에 걸쳐 본 개시의 다양한 실시예의 특징 및 기능을 제공하고 수행하는 다양한 소프트웨어 프로그램 및 하드웨어 구성요소에 대한 참조가 이루어질 것이다. 소프트웨어 프로그램은 기계 판독 가능 매체에 내장될 수 있다. 기계 판독 가능 매체는 예를 들어 컴퓨터, 서버 또는 다른 그러한 장치와 같은 기계에 의해 판독 가능한 형태로 정보를 제공, 저장 또는 전송하는 임의의 메커니즘을 포함한다. 예를 들어, 기계 판독 가능한 매체는 ROM(read only memory); RAM(random access memory); 자기 디스크 저장 매체; 광학 저장 매체; 플래시 메모리 장치; 디지털 비디오 디스크(DVD); EPROM; EEPROM; 플래시 메모리; 자기 또는 광학 카드; 또는 전자 명령을 저장하기에 적합한 임의의 유형의 매체를 포함한다.

상세한 설명의 일부 부분은 컴퓨터 메모리 내의 데이터 비트에 대한 연산의 알고리즘 및 기호 표현 측면에서 제공된다. 이러한 알고리즘 설명 및 표현은 데이터 처리 기술 분야의 기술자가 자신의 작업 내용을 기술 분야의 다른 사람에게 가장 효과적으로 전달하기 위해 사용하는 수단이다. 알고리즘은 본 명세서에서 일반적으로 원하는 결과로 이어지는 자체 일관된 단계 시퀀스로 간주된다. 단계는 물리량의 물리적 조작이 필요한 것이다. 일반적으로 반드시 그런 것은 아니지만 이러한 양은 저장, 전송, 결합, 비교 및 조작될 수 있는 전기 또는 자기 신호의 형태를 취한다. 주로 일반적인 사용을 위해 이러한 신호를 비트, 값, 요소, 기호, 문자, 용어, 숫자 등으로 지칭하는 것이 때때로 편리한 것으로 입증되었다. 이러한 알고리즘은 다양한 소프트웨어 프로그래밍 언어로 작성될 수 있다. 또한, 알고리즘은 소프트웨어의 코드 라인, 소프트웨어의 구성된 논리 게이트 또는 이 둘의 조합으로 구현될 수 있다.

그러나 이렇나 모든 용어 및 유사한 용어는 적절한 물리량과 관련되어야 하며 이러한 양에 적용되는 편리한 레이블일 뿐이라는 점을 염두에 두어야 한다. 상기 논의로부터 명백하게 달리 구체적으로 언급되지 않는 한, 설명 전체에 걸쳐 “처리” 또는 “계산” 또는 “결정” 또는 “표시” 등과 같은 용어를 사용하는 논의는 범용 컴퓨터 시스템 또는 유사한 전자 컴퓨팅 장치의 작업 및 프로세스를 언급하지 않는 다는 것을 이해한다. 오히려, 아래 설명의 맥락에서, 그러한 용어는 컴퓨터 시스템의 레지스터 및 메모리 내에서 물리적(전자적) 양으로 표시된 데이터를 본 발명의 다양한 실시예의 특정 기능을 수행하도록 설계된 임베디드 또는 소프트웨어 프로그래밍 명령의 제어 하에 컴퓨터 시스템 메모리 또는 레지스터 또는 다른 이러한 정보 저장, 전송 또는 디스플레이 장치 내의 물리량으로 유사하게 표현되는 다른 데이터로 조작하고 변환하는 컴퓨터 또는 유사한 전자 컴퓨팅 장치에 의해 실행되는 프로세스에 관련된다.

일 실시예에서, 로직은 Boolean Logic의 규칙을 따르는 전자 회로, 명령의 패턴을 포함하는 소프트웨어 또는 이 둘의 임의의 조합으로 구성된다.

“서버”라는 용어는 다음 설명 전체에서 사용된다. 당업자는 서버가 서버 애플리케이션이 실행되는 것과 동일한 컴퓨터 또는 프로세서에서 실행되는 다른 컴퓨터 프로그램 및/또는 실행 중인 컴퓨터 또는 프로세서와 다른 컴퓨터 프로그램 또는 프로세서에 서비스를 제공하는 컴퓨터 프로그램이라는 것을 이해한다. 다른 프로그램 및 애플리케이션이 동일한 컴퓨터 또는 프로세서에서 실행될 수도 있지만, 종종 서버 프로그램이 실행되는 컴퓨터 또는 프로세서를 서버라고 지칭한다. 서버가 서버/클라이언트 모델의 일부를 형성한다는 것을 이해할 것이다. 이와 같이 서버 프로그램을 실행하는 프로세서는 다른 프로그램에 서비스를 요청하는 클라이언트일 수도 있고 요청에 따라 다른 프로그램에 서비스를 제공하는 서버로도 작동할 수 있다. 서버 프로그램이 실행되는 컴퓨터 또는 프로세서는 메모리, 저장 매체, 입/출력 장치, 통신 모듈 등과 같은 다른 리소스에 액세스할 수 있음을 이해한다.

마찬가지로 클라우드 서버는 로컬 영역 네트워크 및 인터넷과 같은 네트워크를 통한 클라우드 서버에 액세스하는 다양한 클라이언트에게 공유 서비스를 제공하는 서버이다. 클라우드 기반 시스템에서 서버는 클라이언트와 멀리 떨어져 있으며 다양한 클라이언트가 클라우드 서버의 리소스를 공유한다. 정보는 클라이언트에 의해 서버로 전달되고 네트워크, 일반적으로 인터넷을 통해 클라이언트로 다시 반환된다.

도 1은 예를 들어 서버 또는 클라이언트 컴퓨터 시스템일 수 있는 본 발명의 일부 실시예와 함께 사용될 수 있는 예시적인 컴퓨터 시스템(10)을 도시한다. 컴퓨터 시스템(10)은 임베디드 컴퓨터 시스템, 시스템 온 칩(SOC), 단일 보드 컴퓨터 시스템(SBC)(예를 들어, 컴퓨터 온 모듈(COM) 또는 시스템 온 모듈(SOM)), 랩톱 또는 노트북 컴퓨터 시스템, 스마트 폰, 개인 휴대 정보 단말기(PDA), 서버, 태블릿 컴퓨터 시스템, 키오스크, 터미널, 메인프레임, 컴퓨터 시스템의 메시 등을 포함하지만 이에 제한되지 않는 임의의 적절한 형태를 취할 수 있다. 컴퓨터 시스템(10)은 여러 형태의 조합일 수 있다. 컴퓨터 시스템(500)은 하나 이상의 컴퓨터 시스템을 포함하거나, 단일 또는 분산되거나, 여러 위치에 걸쳐 있거나, 여러 시스템에 걸쳐 있거나 또는 클라우드(하나 이상의 네트워크에 하나 이상의 클라우드 구성요소를 포함할 수 있음)에 상주할 수 있다.

일 실시예에서, 컴퓨터 시스템(10)은 하나 이상의 프로세서(11), 메모리(12), 스토리지(13), 입/출력(I/O) 인터페이스(14), 통신 인터페이스(15) 및 버스(16)를 포함할 수 있다. 이 개시는 특정 배열에서 특정 수의 특정 구성요소를 갖는 특정 컴퓨터 시스템을 설명하고 예시하지만, 이 개시는 임의의 적절한 배열에서 임의의 적절한 수의 구성요소를 갖는 다른 형태의 컴퓨터 시스템을 고려한다.

일 실시예에서, 프로세서(11)는 소프트웨어를 구성하는 것과 같은 명령을 실행하기 위한 하드웨어를 포함한다. 여기에서, 소프트웨어에 대한 언급은 하나 이상의 애플리케이션, 바이트 코드, 하나 이상의 컴퓨터 프로그램, 하나 이상의 실행 가능한 모듈 또는 API, 하나 이상의 명령, 로직, 기계 코드, 하나 이상의 스크립트, 또는 소스 코드 등을 포함할 수 있다. 예로서 제한 없이 명령을 실행하기 위해 프로세서(11)는 내부 레지스터, 내부 캐시, 메모리(12) 또는 스토리지(13)로부터 명령을 검색하고; 이를 디코딩하고 실행하고; 그 다음 내부 레지스터, 내부 캐시, 메모리(12) 또는 스토리지(13)에 하나 이상의 결과를 기록한다. 일 실시예에서, 프로세서(11)는 어드레스 명령 또는 데이터를 위한 하나 이상의 내부 캐시를 포함할 수 있다. 메모리(13)는 랜덤 액세스 메모리(RAM), 정적 RAM, 동적 RAM 또는 임의의 다른 적절한 메모리일 수 있다. 스토리지(15)는 하드 드라이브, 플로피 디스크 드라이브, 플래시 메모리, 광학 디스크, 자기 테이프 또는 데이터를 저장할 수 있는 스토리지 장치의 임의의 다른 형태(프로세서에 의한 실행을 위한 명령을 포함)일 수 있다.

일 실시예에서, 스토리지(13)는 HDD, 솔리드 스테이트 드라이브, 디스크 드라이브, 플래시 메모리, 광학 디스크(DVD, CD, 블루레이 등과 같은), 광자기 디스크, 자기 테이프 또는 컴퓨터 판독 가능 미디어, 데이터 및/또는 이들의 조합을 저장하는 임의의 다른 하드웨어 장치를 포함하지만 이에 제한되지 않는 데이터 또는 명령을 위한 매스 스토리지(mass storage)일 수 있다. 스토리지(13)는 컴퓨터 시스템(10) 내부 또는 외부에 있을 수 있다.

일 실시예에서, 입/출력(I/O) 인터페이스(304)는 컴퓨터 시스템(10) 및 하나 이상의 I/O 장치 사이의 통신을 위한 하나 이상의 인터페이스를 제공하기 위한 하드웨어, 소프트웨어 또는 둘 모두를 포함한다. 컴퓨터 시스템(10)은 적절한 경우 이러한 I/O 장치 중 하나 이상을 가질 수 있다. 예로서 제한 없이, I/O 장치는 하나 이상의 마우스, 키보드, 키패드, 카메라, 마이크로폰, 모니터, 디스플레이, 프린터, 스캐너, 스피커, 카메라, 터치 스크린, 트랙볼, 트랙패드, 생체 입력 장치 또는 센서 등을 포함할 수 있다.

또 다른 실시예에서, 통신 인터페이스(15)는 하나 이상의 컴퓨터 시스템 또는 하나 이상의 네트워크 사이의 통신을 위한 하나 이상의 인터페이스를 제공하는 하드웨어, 소프트웨어 또는 둘 모두를 포함한다. 통신 인터페이스(15)는 네트워크 인터페이스 컨트롤러(NIC) 또는 이더넷 또는 다른 유선 기반 네트워크와 통신하기 위한 네트워크 어댑터 또는 무선 NIC 또는 Wi-Fi 네트워크와 같은 무선 네트워크와 통신하기 위한 무선 어댑터를 포함할 수 있다. 일 예에서, 버스(16)는 컴퓨터 시스템(1)의 구성요소를 서로 결합하는 임의의 하드웨어, 소프트웨어 또는 둘 모두를 포함한다.

도 2는 본 발명의 다양한 실시예를 용이하게 하기 위해 사용될 수 있는 예시적인 네트워크(100)의 그래픽 표현이다. 서버(105)는 서비스 조직에 의해 운영되며, 일반적으로 도 1과 관련하여 위에서 논의된 바와 같이 적어도 하나의 프로세서, 입력 및 출력 장비 또는 장치, 메모리, 스토리지 및 통신 인터페이스를 포함한다. 서버는 또한 위에서 설명한 다양한 프로세스를 수행하도록 설계된 특수 소프트웨어 프로그래밍 커맨드의 제어 하에 작동한다. 예시적인 네트워크(100)가 서비스 조직에 의해 운영되는 서버의 관점에서 설명되지만, 서버는 서비스 조직에 의해 고용된 제3자에 의해 또는 서비스 조직의 제어 하에 운영될 수 있다는 것을 이해해야 한다. 서버는 또한 서비스 조직이 서비스 조직의 클라이언트에게 서비스를 제공할 수 있는 서비스 조직에 정보 및/또는 데이터를 제공하는 서비스 조직과 독립적인 제3자에 의해 작동될 수 있다.

서비스와 분리될 수 있지만 반드시 그런 것은 아닌 데이터 스토리지 장치(110)는 서버(105)에 액세스할 수 있고 정보와 관련된 날짜 및 위에서 설명한 시스템 및 방법의 다양한 실시예의 작동과 관련된 임의의 다른 데이터를 저장하는데 사용될 수 있다. 데이터 스토리지 장치(110)는 서버에 직접 연결되거나 네트워크 또는 인터넷(115)을 통해 서버에 액세스할 수 있다. 데이터 스토리지 장치는 클라우드에 위치된 가상 스토리지 장치 또는 메모리일 수도 있다. 또한 하나 이상의 제공자(120) 또는 클라이언트(125)가 네트워크 또는 인터넷(115)을 통해 연결된다.

위로부터, 여기에 개시된 다양한 실시예가 종래의 분산 처리 시스템 아키텍처로 조직화되는 것으로 보이는 컴퓨터, 서버 또는 다른 프로세서에 의해 구현될 수 있음이 명백할 수 있지만, 여기에 기재된 다양한 실시예는 통상적이지 않으며, 이는 레거시 컴퓨터 애플리케이션, 레거시 스토리지 미디어 및 미디어 및 워크스테이션 스토리지에 상주하는 데이터와 같은 여러 원격 정보 소스를 브릿지하고 이메일 메시지의 다양한 부분의 정교한 분석 및 이메일 메시지의 전송 및 수신에 사용되는 방법, 프로토콜 및 통신 경로를 포함하기 때문이다. 실제로, 본 개시의 다양한 실시예가 컴퓨터, 서버 및 프로세서를 사용하여 작동될 때, 이러한 실시예는 이러한 컴퓨터, 서브 및 프로세서를 다양한 하드웨어 및 소프트웨어 구성요소의 작동을 개선할 뿐만 아니라 이메일 메시지의 전송, 수신 및 처리를 크게 향상시키는 방식으로 특별히 프로그래밍된 컴퓨터, 서버 및 프로세서로 변환시킨다.

본 발명의 목적을 위해, 당업자에게 공지된 기술이 있고 본 발명을 구현하는 방법은 당업자에 의해 일반적으로 사용되는 기술 구성요소를 사용할 것이며, 따라서 본 발명의 이 설명은 이러한 구성요소 기술을 설명하지 않는다. 여기에는 다음의 사용을 포함한다:

1. 발신자 메일 클라이언트

2. 발신자 메일 서버

3. 발신자 메일 게이트웨이

4. 이메일 내용 필터링

5. 보안 메시지 서비스 서버

6. 보안 전송 프로토콜

7. 이메일 암호화 방법 및 프로토콜

8. 데이터베이스 로깅 및 연결

9. RPost 등록 이메일 서비스 기술(특허)

10. RPost 등록 수신 인증 서비스 기술(특허)

11. 해싱, 디지털 서명 및 블록체인 기술

12. RPost 사이드노트 서비스 기술(특허)

13. 수신자 메일 게이트웨이

14. 수신자 메일 서버

15. Microsoft Outlook 또는 Gmail과 같은 수신자 메일 클라이언트

16. 메시지의 일부

a. 메시지 헤더

b. 메시지 내용

17. 보안 메시지 전송 프로토콜을 포함하는 메시지 전송 프로토콜

18. 이메일로 제공되는 데이터 보고

19. 데이터 보고의 웹 뷰

20. 암호화 및 인증 프로세스 및 프로토콜

21. 수신된 전자 메시지에 대한 응답

22. 소프트웨어 도구를 사용하여 내용 추출 및 내용의 이미지 생성

23. 도구를 사용하여 HTML 링크와 연관될 수 있는 내용을 생성하고 이메일에 삽입된 HTML 링크 자기 추출

24. 데이터베이스의 정보 연결

25. 웹 및이메일 서버의 소프트웨어 작동

여기에 사용된 용어 “이메일”은 모든 전자 메시지 유형을 지칭할 수 있다; 용어 “이메일 프로토콜”은 모든 전자 데이터 교환 프로토콜을 지칭할 수 있으며, 용어 “전자 파일”은 모든 파일 유형을 지칭할 수 있다.

본 명세서에 설명된 다양한 실시예는 전체로서 또는 선택된 부분에서만 구현될 수 있다. 본 개시의 목적을 위해, 일 실시예에서 각 부분에 대한 구현을 고려하고 그 중 숙련된 실무자가 본 발명의 사상 내에서 식별할 수 있는 다른 부분이 있다.

A. 등록된 암호화(REGISTERED ENCRYPTION)

등록된 암호화는 RPOST Communications Limited의 상표이다. 암호화된 메시지 전달 추적 및 증명: 의도된 수신자에게 보안 전달 사실의 가시성과 감사 가능한 증거를 통해 암호화된 메시지를 전달한다. 이는 Tomkow 미국 7966372 특허에 기술된 발명을 기반으로 하며 이 특허는 전체가 본 명세서에 포함된다.

발신자로부터 RPost로 메시지의 안전한 인바운드 전송 기록

1. 수신 시스템에서 수신된 메시지 헤더 분석 사용

개시된 시스템의 실시예는 수신된 메시지 헤더의 검토를 포함한다. 이 실시예에서 “RPost”는 메시지가 송신자로부터 수신자로 가는 도중이 지시되는 중간 서버 및 수신자의 메시지를 수신자에게 중계하는 중간 서버를 지칭한다.

이 실시예에서, RPost 시스템은 수신된 메시지의 헤더에 정보를 기록함으로써 메시지가 TLS를 통해 RPost 서버 중 하나에 도착했는지 여부를 기록한다. 해당 헤더가 수신된 메시지의 사본에 있기 때문에 사실상 이메일을 수신하는 시스템은 수신 서버 또는 전문 지식이 있는 개인이 수신자의 각 헤더를 검사하는 경우에 수신된 서버에 대한 마지막 전송이 TLS를 통해 수행되었는지 여부에 대한 정보를 이미 얻는다. 이 실시예에서, RPost 중간 서버 시스템은 RPost 중간 서버에서 발신자로부터 수신된 메시지의 메시지 헤더에로부터 TLS에 의해 수신되었음을 나타내는 데이터를 추출하고, 이 메시지 헤더의 일부는 수신 기록 또는 보고에 추가하여 나중을 위해 데이터베이스에 저장된다.

RPost 서버에 도착한 메시지가 RPost 서버에 도착하기 전에 여러 서버를 거쳐서 이동하는 경우, RPost에 대한 마지막 홉(hop)(또는 서버)이 TLS였더라도 그 과정에서 비-TLS 서버를 통해 전달됐을 수 있다. 각 홉이 TLS인지 여부에 대한 표시를 포함하여 전체 기록은 메시지가 RPost 중간 서버에 수신될 때 메시지 헤더의 일부일 수 있지만 본 발명이 없으면 발신자로부터 중간 서버로의 연결이 보안 TLS 연결이었다는 기록의 표준 방법이 없다.

일 실시예에서, 수신된 메시지의 정보는 각각 송신 또는 중계 MTA 서버에 따라 다른 포맷으로 기록될 수 있기 때문에, 알려진 모든 MTA 서버의 모든 목록이 구축될 수 있으며, 시스템이 알려지지 않은 포맷의 헤더의 배치로 인해 TLS를 감지할 수 없는 경우에, 시스템은 해당 서버에 대한 TLS 보안 연결을 기록하지 않는다. 시스템은 알려지지 않은 헤더 포맷이 있을 때 검토 및 학습을 위해 또는 새로운 메시지 헤더 유형의 머신 러닝 분석을 위해 메시지롤 조사 대기열(investigation queue)에 넣은 다음 목록을 동적으로 구축하고 업데이트하기 위해 해당 유형의 보안 연결 프로토콜 요소를 알려진 것의 목록에 추가하는 프로세스를 포함한다.

종종, 메시지가 내부 메일 서버로부터 경계 게이트웨이 서버로 전달될 때 실제로 일반적으로 메시지가 TLS를 전송하지 않을 것이며, 이는 TLS가 없을 때보다 TLS가 전송이 느리기 때문이다. 그것이 반드시 안전하지 않은 것은 아니지만, 그것이 진행되고 있는지 알기 위해서는 특정 전송이 내부적이라는 것을 알려주는 어떤 방법이 필요하다. 그것은 일반적으로 알아낼 수 있지만 항상 쉽거나 완벽한 증거는 아니다. 마지막으로 알려진 서버 및 서버의 시퀀스 및 헤더로부터 식별될 수 있는 다양한 서버로부터의 전송 프로토콜에 대한 정보는 학습을 기반으로 동적으로 업데이트되는 규칙으로 분석될 수 있다.

일 실시예에서, 시스템은 적어도 TLS를 통해(또는 다른 보안 프로토콜을 통해) RPost 중간 서버에서 수신된 발신자의 게이트웨이로부터 RPost로의 마지막 홉을 기록할 것이다. 이는 RPost에 마지막 홉의 발신 게이트웨이 서버 이름 + IP 주소를 기록하는 것을 수반할 수 있다. 수신된 메시지에 암호화 옵션이 표시된 경우, 시스템은 메시지가 암호화되어 수신되었는지 여부를 기록할 수 있다(그리고 예를 들어 어떤 방법, TLS, TLS 버전 또는 PKI에 의해). 메시지가 TLS를 통해 RPost에 의해 수신되었는지 결정하는데 필요한 모든 감사 정보는 사람이 분석하면 사용할 수 있지만 의미 있는 자동화된 실시간 분석을 수행하는 것은 매우 어려울 수 있으며 특수하고 비 전통적인 시스템이 필요할 수 있다. 또한, 메시지가 다른 방법(즉, PKI)을 통해 안전하게 수신되었지만 TLS 없이 전달되었는지 결정하는 것이 분석의 일부가 될 것이다.

실시예:

굵은 텍스트는 구문 분석되어 RPost의 데이터베이스로 복사되는 RPost 중간 서버의 발신자로부터 수신된 인바운드 메시지의 이메일 헤더의 요소이다.

Received: from abc.luxsci.com ([1.1.1.1])

by def.luxsci.com (8.14.4/8.13.8) with ESMTP id r7JEfLgH003867

(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)

for <user-xyz@def.luxsci.com>; Mon, 19 Aug 2013 10:41 :21 -0400

Received: from abc.luxsci.com (localhost.localdomain [127.0.0.1])

by abc.luxsci.com (8.14.4/8.13.8) with ESMTP id r7JEfK0Z030182

for <user-xyz@def.luxsci.com>; Mon, 19 Aug 2013 09:41 :20 -0500

Received: (from mail@localhost)

by abc.luxsci.com (8.14.4/8.13.8/Submit) id r7JEfKXD030178

for user-xyz@def.luxsci.com; Mon, 19 Aug 2013 09:41 :20 -0500

RPost 서버의 발신자로부터 인바운드로 수신된 이메일에는 마지막 홉의 순서로 일련의 헤더가 있을 것이다. 즉, 발신자에서 교환 서버로 게이트웨이 서버로 경계 서버 서비스로 RPost 중간 서버로 - 각각은 TLS 보안 전송 수준을 가질 수도 있고 가지지 않을 수도 있고 다른 TLS 보안 프로토콜 수준(즉, TLS 1.0, 1.1, 1.2, 1.3)을 가질 수 있다. RPost 서버는 이 헤더를 기록하고 프로그램을 실행시켜 이전 홉을 볼 수 있는 옵션과 함께 적어도 “Last Received From Server Name/ Secure by TSL (protocol level)”을 구문 분석하며, 수신된 메시지 수준이 암호화되는 경우(즉, 발신자에서 RPost로 PKI 암호화) 분석이 무시된다(재정의됨). 발신자 조직은 마지막 홉만 똔느 모든 홉에 대한 보안 결정으로 보기 수준(라스트 홉, 모든 홉)을 선택할 수 있다.

RPost 서버의 발신자로부터 인바운드로 수신된 메시지의 이메일 헤더의 구문 분석은 프로세서 집약적일 수 있으므로 이 그문 분석은 메시지가 프로세스에서 수신자에게로 이동한 후에 수행될 수 있다.

헤더로부터 구문 분석/복사된 내용은 데이터베이스에 배치되고 발신자 보안에 중요한 것(즉, 최상, 수용 가능한, 실패)의 계층 구조를 기반으로 분류된다.

메시지는 발신자 보안 전송 기본 설정에 따라 수신자에게 전송된다.

메시지가 메시지 레벨 보안을 위해 처리되는 경우 메시지 ID 및 재암호화 방법, 타임스탬프 등과 연고나된 RPost 서버에서 메시지를 재암호화한다는 사실이 기록된다.

메시지가 보안 전송(즉, TLS)을 위해 처리된 경우 전송 후 SMTP/ESMTP 또는 다른 프로토콜의 경우(즉, HTTP) 메시지 전송 프로토콜 정보가 전송에 성공적으로 사용된 보안 전송 프로토콜(즉, TLS 1.2)에 대한 세부사항 및 RPost에서 수신자에게 보안 전송의 사실을 결정하는 부분에 대해 기록 및 구문 분석된다. 이 프로토콜 정보의 구문 분석은 이 실시예의 메시지를 수신자에게 전송한 후에 발생하는데 이는 전송 후 다른 전송 데이터 및 헤더를 구문 분석하는데 필요한 추가 처리로 인해 발생한다.

이 프로토콜 정보는 메시지 ID 및 수신된 보안 전송 정보와 관련된 데이터베이스에 저장된다.

데이터베이스에 배치된 구문 분석/복사된 메시지 발신 프로토콜 부분은 발신자보안에 중요한 계층(즉, 최상, 수용 가능한, 실패)에 따라 분류된다. 예를 들어 “최상”은 TLS 1.2 또는 메시지 수준 암호화(즉, PKI)를 의미할 수 있다. “수용 가능한”은 발신자 조직에서 설정하여 예를 들어 TLS 1.1을 의미할 수 있다. “실패”는 발신자 조직에서 설정하여 예를 들어 TLS 1.0 또는 TLS 없음을 의미할 수 있다.

(발신자로부터 수신된) 그리고 (수신자에게 보내진) 분류는 결과(해석) 및 프로토콜/방법 데이터와 함께 발신자 및/또는 발신자 조직이 사용할 수 있도록 표시할 차트와 일치하며, 보안 수준의 합은 (발신자로부터 수신된) 그리고 (수신자에게 보내진) 수준의 합 중 더 높은 것으로 설정될 수 있다.

Example 1. If:

(received from sender) = Best

(sent to recipient) = Acceptable

Result = Acceptable

Example 2. If:

(received from sender) = Best

(sent to recipient) = Fail

Result = Fail

Example 3. If:

(received from sender) = Acceptable

(sent to recipient) = Acceptable

Result = Acceptable

Bob@comopany.com으로부터 Sue@network.com 및 Jin@home.com으로 보내진 이메일에 대한 데이터베이스 기록의 위의 예를 고려하는 것은 다음과 같이 요약될 수 있으며 메시지 ID, 보낸 메시지의 해시, 헤더로부터 추출된 추가 발신자 홉 및 각 기록된 추가 홉에서의 보안 전송 수준에 대한 추가 필드가 있다. 예를 들어 Bob이 Jim에게 보낸 예의 경우 RPost 발신자 앱에 의해 적용된 RPost 서버 공개 키 PKI를 통해 RPost 서버에서 메시지를 수신하는 것은 검출되었으며, 따라서 시스템은 메시지가 발신자 Bob 메일 클라이언트(vs. 발신자 도메인 또는 서버 IP 어드레스)로부터 Jim에게 가는 도중에 RPost로 안전하게 전송되었음을 알며 RPost 서버에서 PKI 메시지 전송을 수신한 후 RPost 서버에서 PKI를 통해 해독하기 위한 처리 사실을 기록한다.

발신자에서 RPOST로

메시지 자체가 HTTP 프로토콜(REST, SOAP 또는 다른 API 프로토콜을 통해)에서 수신되는 경우 수신 RPost 메시지 게이트웨이 서버에서 HTTP 프로토콜에서 수신된 메시지와 사용된 HTTP 프로토콜 버전을 식별한다. RPost 메시지 게이트웨이 서버가 메시지를 수락한 메시지와 논리적으로 연관된 데이터베이스에 기록하고 서버 정보와 논리적으로 연관되어 어떤 HTTP 수준의 전송이 사용되었는지 기록한다.

메시지 자체가 HTTP 프로토콜(웹 서버 또는 다른 웹 전송 또는 메시징 프로토콜을 통해)에 의해 수신되는 경우, 수신 RPost 메시지 게이트웨이 서버에서 HTTP 프로토콜에서 수신된 메시지와 사용된 HTTP 프로토콜 버전을 식별한다. RPost 메시지 게이트웨이 서버가 메시지를 수락한 메시지와 논리적으로 연관된 데이터베이스에 기록하고 서버 정보와 논리적으로 연관되어 어떤 HTTP 수준의 전송이 사용되었는지 기록한다.

위의 모든 항목에 대해 메시지 ID, RPost 서버의 수신 타임 스탬프, 보안 전송을 나타내는 메시지 전송 프로토콜 다이얼로그의 적어도 일부 또는 서버가 특정 보안 전송 프로토콜 또는 RPost 서버에서 수신된 PKI 암호화된 메시지를 해독하는 RPost 서버의 사실(“보안 전송 포렌식”)을 사용하여 수신된 인바운드 메시지만을 수락함을 확인하는 서버 구성 메타데이터의 일부를 포함하며; 논리적으로 연관되고, 함께 해시되거나 그리고/또는 별도로 해시되는 데이터베이스에 기록한다.

보안 전송 포렌식을 기록하고 선택적으로 수신된 메시지 내용의 해시와 함께 데이터베이스에 기록한다.

2. RPost에서 수신자로의 메시지의 안전한 아웃바운드 전송을 기록

메시지가 RPost 서버에 수신되면 메시지가 의도된 수신자에게 안전한 방식으로 전달되는 방법에 대한 결정이 필요하다.

다음을 기반으로 한다:

A. 발신자의 특징 요청 (메시지가 수신자에게 안전하게 전송되어야 하는 방법(보안 전송 방법, 시스템 또는 프로토콜 사용)을 결정하는 발신자 또는 발신자 설정), 메시지는 전송됨, 또는

B. 특정 유형의 보안 전송을 수락하는 수신자의 가용성, 선택된 보안 전송 프로토콜 중 하나의 메시지, 메시지는 수신자에게 안전하게 전송되어야 한다(보안 전송 방법, 시스템 또는 프로토콜 사용).

일 실시예의 예에서, (A)인 경우 RPost 서버는 발신자 또는 발신자 관리자가 설정한 특징을 기반으로 하는 메시지 수준 암호화로 메시지를 전송하고 메시지는 256비트 암호화된 PDF 파일 내부에 캡슐화되어 전송된다.

다른 메시지에 대해, (B)인 경우 RPost 서버는 사용 불가능한 경우가 아니면 TLS 1.2 전송의 요구 사항과 함께 발신자 또는 발신자 관리자가 설정한 특징을 기반으로 하는 메시지 수준 암호화로 메시지를 전송하고, 사용 불가능한 경우 전송된 256 비트 암호화된 PDF 파일 안에 캡슐화되어 전송된다. 다른 메시지에 대해, (B)인 경우 RPost 서버는 TLS 1.0 이상의 보안 요구사항과 함께 발신자 또는 발신자 관리자가 설정한 특징을 기반으로 하는 메시지 수준 암호화로 메시지를 전송하지만 수신자가 TLS 1.2를 수락할 수 있는 경우 TLS 1.2 프로토콜이 보안 전송에 사용되었다.

사용 가능한 TLS 전송 수준은 RPost MTA에 저장된 캐시, 데이터베이스 또는 RPost MTA와 연관된 서버에서 유지될 수 있으며, 해당 프로토콜을 사용할 수 없는 경우에만 사용 가능한 프로토콜을 결정하기 위해 다시 테스트하고 원하는 프로토콜을 사용할 수 없는 경우 대체 메시지 수준 암호화 전송(즉, AES 256 비트 PDF 암호화)으로 되돌린다. RPost에서 수신자로의 암호화의 사실, 유형 및/또는 수준이 데이터베이스의 Rpost에 기록된다.

도 5는 어떤 레벨의 보안 전송 프로토콜이 특정 수신자에 의해 수신될 수 있는지를 결정하는 일 실시예(200)를 도시하고, 이는 그 후에 메시지의 수신자에게 메시지를 전송하기 위해 어떤 암호화의 유형 또는 수준이 사용될 지를 결정한다. 이 실시예에서, 메시지는 서버 Trans X(205), Trans Y(210) 또는 Trans Z(215)와 같은 등록된 중앙 서버(RCS)(220)에 있는 서버에 의해 수신된다. 이 예는 Trans X(205)가 메시지를 수신했다고 가정한다. RCS 서버 Trans X는 1단계에서 MTA(메시지 전송 에이전트) 서버 MTAXX에서 “get API”를 호출한다. 단계 2에서 API는 메시지에 존재하는 프로토콜의 유형을 분석하기 위해 시스템 호출을 수행한다. 메시지가 특정 TLS 프로토콜로 암호화된 경우 API는 3단계에서 시스템이 수신자를 아는지 확인하기 위해 TLS 로컬 캐시(230)와 같은 메모리에서 확인한다. 수신자가 서버에 알려진 경우, API는 RCS 서버 Trans X(205)와 통신하고 메시지를 수신자에게 전송할 적절한 TLS 또는 MLE 프로토콜을 서버에 지시하고 Trans X는 그 후에 메시지를 수신자에게 전송한다.

수신자가 시스템에 대해 모르는 경우, API는 4단계에서 수신된 메시지에 포함된 어드레스를 기반으로 도메인을 찾기 위해 MXLookup을 수행한다. 도메인이 결정되면 수신자의 정보의 사본이 TLS 로컬 캐시(230)에 저장되며, 메시지를 전송하기 위한 적절한 프로토콜의 사용을 위한 명령이 서버 Trans X(205)로 통신되고, 메시지는 적절한 암호화 프로토콜을 사용하여 수신자에게 전송된다.

그러나 어떤 경우에는 수신자가 TLS 프로토콜을 사용하여 메시지를 수신하지 못할 수 있다. 이 경우 수신자가 수신할 수 있는 적절한 프로토콜이 결정될 때까지 메시지가 전송되지 않을 것이다. 이러한 경우 메시지는 예를 들어 pdf 암호화를 사용하여 전송된다.

공개된 시스템을 사용하도록 고객을 설정할 때, 수신자에게 전자 메시지를 보내는 고객은 메시지 전달을 위해 최소 지원 TLS 프로토콜을 설정할 수 있다. 이러한 예에서 공개된 시스템이 수신자의 암호화 프로토콜을 지원하더라도 고객의 설정이 수신자의 서버 설정보다 우선할 수 있다. 이러한 경우 메시지가 수신자 암호화 프로토콜에 의해 수신될 수 없는 경우, 예를 들어 pdf 암호화 프로토콜을 사용하여 수신자에게 전송될 수 있다.

RPost 서버는 각 의도된 수신자에 대한 실제 전송에 사용된 전달 방법을 기록한다. 이는 암호화된 전송 요청이 있었음을 나타내는 것과 다르다. 여기서 차이점은 보안 포렌식 메타데이터가 기록된 각 의도된 수신자에게 보안 전송 기록이 있다는 것이다.

Bob@comopany.com으로부터 Sue@network.com 및 Jin@home.com으로 보내진 이메일에 대한 데이터베이스 기록의 위의 예를 고려하는 것은 다음과 같이 요약될 수 있으며 메시지 ID, 보낸 메시지의 해시, 헤더로부터 추출된 추가 발신자 홉 및 각 기록된 추가 홉에서의 보안 전송 수준에 대한 추가 필드가 있다. 예를 들어 Bob이 Jim에게 보낸 예의 경우 RPost 발신자 앱에 의해 적용된 RPost 서버 공개 키 PKI를 통해 RPost 서버에서 메시지를 수신하는 것은 검출되었으며, 따라서 시스템은 메시지가 발신자 Bob 메일 클라이언트(vs. 발신자 도메인 또는 서버 IP 어드레스)로부터 Jim에게 가는 도중에 RPost로 안전하게 전송되었음을 안다.

RPOST에서 수신자로

이러한 기록은 공통 메시지 ID를 통해 데이터베이스에서 결합하고, 내용의 해시와 논리적으로 연관된 전체 포렌식 메타데이터의 해시를 포함하며, Tomkow 패밀리 특허 및 선행기술에 개시된 다양한 방법을 사용하여 원래 전송, 수신되는 내용, 전송 타임 스탬프, 발송, 전달, PKI의 경우 암호 해독, 개방을 증명할 수 있는 방식으로 디지털 서명된 “보안 인증서”로 생성될 수 있다.

발신자에서 RPOST로

RPOST에서 수신자로

보고에서는 공식을 사용하거나 보안 점수를 생성하여 위의 요약을 포함할 수 있다. 예를 들어,

발신자에서 RPost인 경우 = PKI를 통한 보안, 4 점

발신자에서 RPost인 경우 = 보안 TLS 1.2, 3 점

발신자에서 RPost인 경우 = 보안 TLS 1.1, 2 점

발신자에서 RPost인 경우 = 보안 TLS 1.0, 1 점

RPost에서 수신자인 경우 = PDF AES-256을 통한 보안, 4 점

RPost에서 수신자인 경우 = TLS 1.2를 통한 보안, 3 점

RPost에서 수신자인 경우 = TLS 1.1을 통한 보안, 2 점

RPost에서 수신자인 경우 = TLS 1.0을 통한 보안, 1 점

발신자에서 RPost로 또는 RPost에서 수신자로에 0점이 있는 경우 발신자 관리자에게 경고하는 플래그를 생성한다.

위의 점수는 발신자 관리자가 특정 전송 프로토콜에 대한 보안 전송 지점을 제외하도록 선택할 수 있는 기능을 추가로 허용하는 관리 인터페이스에서 발신자 조직에 중요한 보안 수준에 따라 조정될 수 있다.

“기밀 증명서” 또는 “보안 증명서” 또는 “보안 인증” 기록은 전달 상태 정보를 포함할 수 있으며, 메시지 전송 프로토콜의 일부가 수행된 특정 처리(즉, 메시지를 PDF AED-256 래퍼로 변환)의 데이터베이스 기록과 결합될 수 있으며, 발신자와 발신자 조직에 눈에 띄는 방식으로 전송이 인증된 보안이라는 표시를 발신자 조직이 표시하는 표준에 따라 제공할 수 있으며, 선택적으로 보안 점수를 표시할 수 있다. 이 보안 증명서는 예를 들어 전송 애플리케이션(SMTP, HTTP 또는 다른 프로토콜을 통해)으로부터 처리 허브로, 수신자로의 그리고 그 후에 (수신자로부터의 전자 서명, 회신 또는 응답의 예로서) 발신자 및 임의의 복사된 또는 발송된 증거가 없는 복사된(blind copied) 수신자로 다시 보내는 제출을 포함하여 여러 통신 스레드를 확인하기 위해 컴파일될 수 있다. 이 예에서, 회신, 응답 및 전자 서명 기록의 사실 또는 발신 또는 응답으로부터 수정되는 메시지 부분의 사실의 정보(여기에 추가로 설명됨)는 유사한 방식으로 기록된다.

메시지는 발신자 관리 규칙(예를 들어 링크 검색 대용량 파일 전송)에 따라 HTTP 또는 HTTPS를 통해 의도된 수신자에게 전송될 수 있으며, HTTPS는 허용되고 HTTP는 허용되지 않는다는 것이 이해된다. 이 정보는 유사하게 캡쳐된다. 또한 메타데이터는 HTTPS와 필요한 수신자 암호 또는 단순히 HTTPS로 전송되었는지 여부를 캡쳐한다.

보안 증명서의 다른 실시예에서, 시스템은 메시지를 분석할 것이며 다음 단계를 포함할 수 있다:

1. RPost 시스템은 발신자의 Outlook에서 보낸 수신된 암호화된 메시지를 해독한다(즉, PKI 암호 해독, RPost 코드가 RPost 앱에서 실제로 암호화된 PKI를 수신했음을 확인/기록하는 방법).

2. RPost 시스템은 TLS를 통해 발신자 SMTP로부터의 인바운드 메시지의 수신을 기록한다(핵심 포인트는 RPost 코드가 발신자로부터 TLS 전송에 의해 RPost 시스템에서 수신 사실을 확인/기록하는 방법이다).

3. RPost 시스템은 (HTTPS를 통해) API 연결로부터의 인바운드 메시지의 수신을 기록한다(핵심 포인트는 RPost 코드가 발신자로부터의 보안 웹 서비스 HTTPS 전송에 의한 수신 사실을 확인/기록하는 방법이다)[두 시나리오 모두, 보안 응답의 수신 또는 보안 대용량 메일의 전송 시]

4. RPost 시스템은 TLS를 통해 수신자 게이트웨이로 아웃바운드 메시지의 전달을 기록한다(핵심 포인트는 RPost 코드가 수신자 게이트웨이로의 성공적인 TLS 전송 사실을 확인/기록하는 방법이다).

5. RPost 시스템은 수신자에게 전송하기 전에 PDF 메시지를 보호하는 암호 및 256 비트 암호화 사실을 기록한다.

위의 내용은 RPost의 데이터베이스에 기록된다.

인증 시 표시되는 텍스트 파일의 등록된 수신 내부에 추가된 기록과 함께 그리고 1+4, 2+4, 3+4 또는 1+5, 2+5 또는 3+5가 수신에서 암호화된 전송의 확인을 제공하기 위해 수행된다는 사실과 함께 RPost 데이터베이스에 기록된다.

암호화된 인바운드 메시지 수신 추적 및 증명: 최초 발신자로부터의 보안 전달 사실의 감가시성 및 감사 가능한 증거를 갖는 인바운드 메시지의 수신. 수신자는 또한 발신자로부터의 보안 전송을 통해(RPost를 통해) 메시지 수신의 사실을 확인하는 기록과 함께 발신자로부터의 보안 전송을 보고하는 기록을 볼 수 있다.

보안 게이트웨이 서버는 TLS 또는 메시지 수준 암호화 데이터를 추출하기 위해 메시지 헤더를 분석하는 관점에서 인바운드 메시지 트래픽을 기록하기 위해 언급된 것과 동일한 요소를 사용하고 보안 수신을 인증하기 위해 메시지 헤더, 제목 또는 본문에 표시를 배치할 수 있다.

B. 수정된 응답(REDACTED REPLY) ^TM

수정된 응답은 Rpost Communication Limited의 상표이다.

응답 메시지 부분의 등록된 수정: 발신자에 대한 수정 사실을 등록하는 발신자의 옵션을 사용하여 수신자가 응답하면 발신자 메시지 내용의 전자 메일 스레드로부터 메시지 부분을 수정.

응답의 일부를 수정하는 방법은 다음 중 하나일 수 있다:

1. 고도의 기밀 메시지 부분 지정

발신자 메일 클라이언트의 사용자 인터페이스 텍스트 상자는 발신자가 특정 매우 민감한 텍스트, 예를 들어 신용 카드 번호 또는 의료 기록 정보를 추가할 수 있는 위치일 수 있다.

대안적으로, 발신자는 ^여기에 매우 민감한 내용^과 같은 특정 유형의 브라켓 구조 내부에 매우 민감한 정보를 삽입할 수 있다.

2. 수신자에게 안전하게 전송

발신자가 보안 메시지를 안전하게 전송하기 위한 조치를 취했음을 확신하면서 보안 메시지를 TLS를 통해 수신자에게 전송할 때 문제가 심각하다. 그러나 놀랍게도 수신자가 응답을 할 때 아무렇지 않게 “고맙습니다!”라고 말할 수 있으며, 그의 매우 민감한 정보는 보안 없이(모든 홉과 서버를 통해) 그에게 반환되어 발신자의 매우 민감한 정보를 노출시킨다.

메시지는 발신자로부터 안전하게 RPost 서버(PKI, TLS 등)로 전송되고 RPost 서버에서 서버는 지정된 고도의 기밀 내용을 제거하며, 또한

A. 내용의 작은 이미지 및 동일한 크기의 대응하는 검은색 이미지를 생성한다.

B. 대체 텍스트(Alt-Text) 태그 이름이 발신자에 의해 지정되거나, 발신자와 연관되거나 기본적으로 “발신자 이메일 주소 민감한 내용을 위한 클릭”을 말하는 이미지 파일에 추가된다. 이는 스패머(spammer)에 의해 쉽게 스푸핑되지(sppofed) 않는 텍스트여야 한다.

C. 수신자에서 자동으로 추출하도록 구성된 링크를 통해 메시지 본문의 지정된 영역에 이미지를 배치한다.

D. 발신자는 민감한 내용의 보기 수 및/또는 제1 보기 후 사용 가능한 시간을 선택할 수 있다. 이는 서버에 저장된다.

E. 민감한 내용의 이미지와 연관된 위치에 블랙 이미지를 놓아서 민감한 내용이 있는 이미지가 한계까지 표시된 후(D에 언급된 바와 같이), 이미지 링크는 대응하는 블랙 이미지에 대한 링크에 다시 보내진다(redirect).

3. 수신자에서

수신자는 TLS에 의해 안전하게 전송된 이메일을 열고 링크에 민감한 내용이 자동으로 표시되지 않으면 대체 텍스트 태그를 본다. 표시되지 않는 경우 링크를 클릭하거나 이미지를 표시하기 위해 클릭하면 민감한 내용이 나타난다.

4. 회신 시

수신자는 내용을 보지만 응답할 때 내용이 응답 후에 표시되지 않는다(링크는 제1 보기 후 타임아웃 또는 제1 보기 후 및/또는 전송 후에 특정 시간을 갖는다).

민감한 내용이 타임 아웃되면, 내용 공간이 “수정된 내용”(위의 E에서 언급된 바와 같음)이라는 블랙 박스로 대체된다.

추가 옵션

특정 수신자에게 보내는 일부 발신자는 하이퍼링크를 볼 수 없도록 하는 수신자 보안 정책으로 인해 하이퍼링크가 포함된 이메일을 보내고 싶지 않을 것으로 예상된다.

발신자 또는 발신자 관리자의 설정은 저장된 이미지로부터의 보안 내용 이미지를 이메일에 첨부된 텍스트 상자에 배치된 추출된 컨텐츠로 대체할 수 있으며 제거된 내용은 “^텍스트 파일에 첨부된 수정된 내용^”이라고 말하는 검은색 텍스트로 대체된다. 첨부된 파일은 대체 실시예에서 또는 발신자 설정의 옵션에서 텍스트 파일, HTML 파일, PDF 암호화된 PDF 등이 될 수 있다.

수신자가 응답하면, 테스트 파일이 응답을 따르지 않으므로 응답 시 또는 응답 후에 수신된 매우 민감한 정보의 부주의한 공개를 방지하는 목표가 달성된다.

보안 증명서

보안 인증서 스코어링에 추가된 점수는 이 수정된 응답 시스템을 사용한다. 또한 보안 이미지가 표시되는 횟수에 대한 표시가 있을 수 있으며 “한번에 표시”=”가장 안전함”, 또는 “첫 표시 후 10분 만료됨”=”가장 안전함”, 또는 우발적으로 제2 시간을 표시하지 않을 일부 설정.

이 특징은 수신자가 응답할 때 수신자에 의해 발신자의 민감한 정보를 우발적으로 공개하는 것을 방지하기 위한 것이다. 민감한 정보의 표시를 추가로 제어하거나 제한하기 위해 추가로 알려진 방법이 구현될 수 있지만, 이 실시예에서 수신자가 내용의 스크린샷을 전달, 복사 또는 찍는 것을 방지하려는 의도는 아니다.

보안 증명서 인증

보안 증명서를 인증하기 위해 필요한 경우 메시지를 다시 해시하고(rehash) 블록 체인에서 해시와 비교할 수 있어 개인 메시지가 제3자에 의해 저장되거나 수신으로 반환될 필요가 없도록 함께 해시된 증명서의 해시와 메시지의 해시를 둘 중 하나 또는 둘 다를 블록 체인에 게시할 수 있다.

대안적으로, Tomkow 특허 패밀리에 공개된 등록된 수신 시스템은 포렌식 보안 메타데이터, 보안 증명서 및 기본 메시지 전송 프로토콜을 포함하는 다른 요소와 메시지 수준 암호화(256비트 AES PDF 파일로 변환) 사실을 확인하는 시스템 처리 포렌식 및 또는 수신 및 또는 TLS 및 TLS 수준 번호에 의한 전송을 포함할 수 있다.

확인의 일부로 블록 체인을 사용하는 경우 실시예는 다음과 같다:

블록 체인에 보안 증명서(“수신”) 데이터의 해시를 저장하는데 약간의 가치가 있을 수 있다.

수신은 메시지 및 연관된 DSN, MUA, 전송 프로토콜, 암호화 및 해독 등에 관한 서버 시스템 데이터, 수신 등을 나타내는 base64 인코딩 문자열과 함께 모든 전달 상태 정보 및 메시지 메타 데이터를 포함하는 JSON 객체일 수 있다. 블록 체인에 대한 해시는 직렬화된 JSON 객체의 정규화된 표현일 수 있다.

JSON 객체는 템플릿 엔진을 통해 HTML 형식으로 지정되어 이메일 수신을 생성하거나 웹 후크를 통해 실시간 푸시 기반으로 고객 시스템에서 액세스될 수 있다.

블록 체인에 게시된 해시는 문서화된 RPost 어드레스로 디지털 서명된다. 변조하면 수신이 무효화되므로 수신 데이터를 암호화할 필요가 없다.

정규화된 JSON 객체를 해싱하고 블록 체인에서 트랜잭션 해시를 검색하여 확인 프로세스를 수행하는 간단한 도구는 다양한 언어(Node, Ruby, Python 등)로 쉽게 생성되어 GitHub 공개 저장소 및 패키지 관리자(npm, gem, pip 등)에 게시될 수 있다. 또한 도커 컨테이너(docker container)를 도커 허브에 게시할 수 있다.

그런 식으로 기업 사용자(IT 부서)는 몇 가지 커맨드로 자체 확인기(verifier)를 설치하고 실행할 수 있다. 그런 다음 확인기는 비즈니스 프로세스에 쉽게 통합될 수 있다. RPost는 여전히 확인기를 추가로 실행한다.

블록 체인을 확인기로 사용한다는 것은 수신을 확인하는 모든 정보가 공개되고 블록 체인이 배포되고 변경 불가능하기 때문에 RPost가 수신 확인에 대한 지속적인 지원을 위해 키 에스크로 및/또는 제3자 보증이 필요하지 않음을 의미한다.

트랜잭션 비용은 블록 체인에 쓰기 위해 해시 당 약 $0.02(중요하지 않음)이다. 트랜잭션을 읽는 데는 비용이 들지 않는다. 이것이 구현되면 RPost는 미지불 고객 및 테스트를 위한 프라이빗 블록 체인을 원하고 특정 블록 체인 비용을 지불하기로 선택한 유료 사용자에 대해서만 퍼블릭 블록 체인을 구현할 것이다.

블록 체인 솔루션은 서비스에 대한 핵심 가치가 수신의 영구 유효성과 독립적인 확인으로 판매 및 마케팅에 약간의 이점이 있을 수 있다.

도 6은 수정된 응답 시스템을 사용하여 메시지의 발신자가 사용할 수 있는 다양한 설정의 목록이다. 옵션 1에서, 시스템은 선택된 수정된 응답 내용을 텍스트 파일로 수신자에게 보내는 아웃바운드 메시지에 첨부한다. HTML 파일 등의 파일 형식을 선택하는 옵션이 있으며, 필요한 경우 첨부물을 별도로 암호화하는 옵션이 있다.

옵션 2에서, 시스템은 이메일 본문 내부에 수정된 응답 텍스트에 대한 링크를 삽입한다. 일 실시예에서, 브라우저 옵션은 수정된 응답 텍스트 링크가 클릭될 때 새로운 브라우저 창이 열리거나 링크가 활성화될 때 표시되는 수정된 응답 텍스트와 함께 링크가 활성화된다. 이 단계를 위한 다수의 옵션도 제시되며, 이는 예시적인 것이며 제한적인 것이 아님을 이해할 것이다. 예를 들어, 발신자가 링크를 클릭할 때 수정된 응답 텍스트가 포함된 브라우저 창을 열도록 링크를 갖도록 선택한 경우 발신자는 링크를 클릭할 때 발생하는 상황을 제어하기 위해 다양한 설정을 구성할 수도 있다. 예를 들어, 발신자는 수정된 응답 텍스트를 복사할 수 없도록 잠겨 있도록 링크를 구성할 수 있다. 대안적으로, 텍스트를 복사할 수 있도록 링크를 구성할 수 있다. 다른 실시예에서, 발신자는 브라우저가 열릴 때 브라우저에 고객 로고를 추가할 수 있다. 수신자가 수정된 응답 텍스트를 볼 수 있는 횟수는 입력 가능한 필드 또는 드롭 다운 목록을 사용하여 발신자가 구성할 수도 있다.

또 다른 실시예에서, 발신자는 수정된 응답 텍스트가 보여질 수 있는 시간을 제한하도록 링크를 구성할 수 있다. 또한 발신자는 링크를 클릭할 때 브라우저 창에 나타나는 텍스트를 제공할 수 있다. 예를 들어, 브라우저 창은 “다음 정보는 비공개입니다. 이 메일에 포함된 기밀 및 특권 정보의 수신자가 아닌 경우 즉시 삭제하십시오. 이 정보를 유포하지 마십시오”와 같은 메시지를 표시할 수 있다.

다른 옵션에서는 수정된 내용이 제거되어 이메일 내부에 이미지로 표시된다. 이미지 파일은 웹 링크와 연관된 임시 저장 영역에 저장되며, 링크 또한 저장된다. 일 실시예에서, 시스템은 “수정된 내용”으로 레이블이 붙은 흰색 텍스트와 함께 검은색인 동일한 크기의 제2 이미지 파일을 생성할 수 있다. 그런 다음 시스템은 “수정됨: 해당 보기를 클릭”이라는 이미지 파일에 대체 택스트를 추가할 수 있다. 일 실시예에서, 이미지 파일의 보기는 뷰어가 제1 보기의 원래 IP 주소를 사용할 때 및/또는 특정 수의 디스플레이에 대해서만 및/또는 발신자에 의해 구성될 수 있는 특정 기간 동안에만 허용된다.

일 실시예에서, 시스템은 컨텐츠를 제거하고 이메일 내부의 이미지, 예를 들어 수정을 위해 표시된 텍스트를 이미지 파일로 변환하는 소프트웨어 명령을 구현함으로써 수정된 내용을 포함하는 이미지를 표시하며; 웹 링크와 연관된 보안 임시 저장 영역에 이미지 파일을 저장하가ㅗ 이미지 파일의 링크를 생성한다. 발신자는 또한 흰색 텍스트 “수정된 내용”이 있는 검은색인 동일한 크기(높이, 폭)의 제2 이미지 파일을 생성하고; 예를 들어 “수정됨: 보기 위해 클릭”과 같은 이미지 파일에 대체 택스트를 추가하고; 제1 보기의 IP 어드레스를 기록하고; 이미지 파일의 보기를 (i) 원래 IP 어드레스로부터만, 및/또는 (ii) 디스플레이의 특정 수에 대해서만 및/또는 (iii) 특정 기간 동안에만 허용하는 시스템을 구성할 수 있으며 (i), (ii) 및 (iii)은 발신자 회사에 의해 구성 가능하다.

도 7은 수정된 응답 실시예에 대한 워크플로우를 도시한다. 상자(1)의 발신자는 상자(3)의 RPost 서버로 보낸 아웃바운드 이메일(상자(2))을 생성한다. RPost 네트워크에서의 처리 후에 아웃바운드 이메일은 상자(4)의 RPost에서 상자(5)의 수신자에게 전송된다. 이러한 실시예에서, RPost 네트워크는 상자(3)에서 식별된 바와 같이 도 7에 도시된 바와 같이 발신자, 발신자 이메일 서버, 발신자 게이트웨이 또는 중간 서버일 수 있다.

도 8은 수정된 응답 특징을 사용하여 이메일 메시지를 준비할 때 발신자가 이용할 수 있는 두 가지 옵션을 도시한다. 이 예시적인 실시예에서, 제1 옵션에서 발신자는 수정된 응답 텍스트를 위의 캐럿(carrot) 기호 내에 삽입한다(이동(6)). 대신 다양한 기호가 사용될 수 있다. 또한 수정된 응답 텍스트는 많은 줄, 공간 및 줄 바꿈(line break)으로 구성될 수 있다.

도 9는 수정된 응답 특징을 사용하는 이메일 메시지를 준비할 때 발신자가 이용 가능한 제2 옵션을 도시한다. 이 옵션에서 사용자는 RPost 서비스를 위해 사용되는 발신자 앱의 수정된 응답 특징 내에 수정된 응답 텍스트를 삽입할 수 있다. 일 실시예에서, 도 9에 도시된 바와 같이, 사용자는 RPost 애플리케이션(250)으로부터 메뉴를 활성화하여 수정 응답 입력 상자(255)를 활성화하고 수정될 텍스트를 상자(260)에 도시된 바와 같이 표시된 상자에 삽입한다.

도 10은 이메일이 처리를 위해 발신자(또는 발신자 서버)로부터 RPost 네트워크로 아웃바운드되는 경로를 도시한다. 이메일은 수정된 응답 텍스트와 함께 RPost 네트워크로 안전하게 전송된다. 텍스트는 2 개의 업 캐럿(up carrot) 기호 안에 있는 이메일 본문에 포함되거나 RPost 애플리케이션에 의해 보내진 암호화된 데이터 파일에 포함된다.

도 11에 도시된 바와 같이, RPost 네트워크 서비스는 2 개의 업 캐럿 기호 또는 RPost 애플리케이션에서 보낸 데이터 파일에서 수정된 응답 텍스트를 추출하고 고객 또는 사용자 설정에 따라 이메일을 처리한다. 발신자는 수정된 응답 텍스트를 아웃바운드 파일에 첨부된 텍스트 파일로 보내거나 수정된 응답 텍스트와 연관된 링크를 메시지에 추가하도록 RPost 시스템을 구성할 수 있다. 시스템은 다음 옵션으로 링크를 구성하도록 사용될 수 있다: 1) 사본이 될 수 없도록 수정된 응답 텍스트를 잠근다(예/아니오); 2) 수정된 응답 텍스트의 복사를 허용한다(예/아니오); 3) 브라우저 창(탐색)에 고객 로고를 추가한다; 4) 드롭 다운 메뉴를 사용하여 설정될 수 있는 수정된 응답 텍스트의 횟수를 볼 수 있다; 5) 드롭 다운 메뉴를 사용하여 설정될 수 있는 보기 당 수정된 응답 텍스트를 볼 수 있는 시간; 그리고 6) 예를 들어 “다음의 정보는 비공개입니다. 이 이메일에 포함된 기밀 및 특권 정보의 의도된 수정자가 아닌 경우 즉시 삭제하십시오. 이 정보를 유포하지 마십시오”와 같이 브라우저 창에 선택된 텍스트를 표시한다.

도 12는 RPost 네트워크로부터 수신자로의 예시적인 아웃바운드 이메일 경로를 도시한다. RPost 네트워크는 고객 또는 사용자 설정에 따라 수신자에게 이메일을 보낸다. 하나의 선택적인 실시예에서, 시스템은 상자(280)에 도시된 바와 같이 수정된 응답 내용을 아웃바운드 메시지에 텍스트 파일로 첨부한다. 텍스트 파일은 예를 들어 HTML, PDF, 암호화된 PDF, TIFF, JPG 등과 같이 다른 포맷일 수 있다. 파일은 다양한 방법을 사용하여 암호화될 수 있거나 파일은 암호화되지 않을 수 있다. 도 12에 도시된 바와 같이, 수신자는 첨부물에 수정된 텍스트를 포함하는 것을 나타내는 이메일의 메시지(상자(285))를 포함하여 상자(280)에 도시된 바와 같이 수정된 응답 텍스트 첨부물을 포함하는 전자 메시지(이메일)을 제공받는다. 첨부물을 클릭하면 상자(290)에 도시된 바와 같이 수정된 응답 텍스트를 포함하는 창이 열린다.

제2 예시적인 실시예에서, 시스템은 도 13에 도시된 바와 같이 이메일 본문 내부에 수정된 응답 텍스트에 대한 링크를 삽입한다. 이 옵션에서, 사용자는 링크를 클릭하여 브라우저 창을 열어 수정된 응답 텍스트를 볼 수 있다. RPost 네트워크 시스템은 수신자에게 전송되는 아웃고잉 이메일에 대한 링크를 추가한다. 이메일이 상자(300)에서 수신자에 의해 열릴 때, 수정된 응답 텍스가 링크를 클릭함으로써 볼 수 있음을 수신자에게 알리는 텍스트를 포함하는 메시지(305)가 수신자에게 제공된다. 링크를 클릭하면 상자(310)에 도시된 바와 같이 수정된 응답 텍스트가 수신자에 표시되게 한다.

도 14는 수신자가 링크를 활성화할 때 링크(도 13)의 동작을 구성하기 위해 발신자가 구성할 수 있는 다양한 브라우저 창 설정을 도시한다. 예를 들어, 링크는 다음 옵션으로 구성될 수 있다: 1) 복사될 수 없도록 수정된 응답 텍스트를 잠근다(예/아니오); 2) 수정된 응답 텍스트가 복사되는 것을 허용한다(예/아니오); 3) 브라우저 창(탐색)에 고객 로고를 추가한다; 4) 드롭 다운 메뉴를 사용하여 설정될 수 있는 수정된 응답 텍스트의 횟수를 볼 수 있다; 5) 드롭 다운 메뉴를 사용하여 설정될 수 있는 보기 당 수정된 응답 텍스트를 볼 수 있는 시간; 그리고 6) 예를 들어 “다음의 정보는 비공개입니다. 이 이메일에 포함된 기밀 및 특권 정보의 의도된 수정자가 아닌 경우 즉시 삭제하십시오. 이 정보를 유포하지 마십시오”와 같이 브라우저 창에 선택된 텍스트를 표시한다(상자(320)).

도 15는 사용자 설정에 따른 수정된 응답 텍스트 창의 하나의 다른 실시예를 도시한다. 이 실시예에서, 수신자는 박스(300)에 도시된 바와 같이 이메일 또는 브라우저 창에 포함된 수정된 응답 텍스트를 포함하는 이메일을 수신한다.

도 16은 수신자가 발신자에게 다시 응답하는 경우 발생하는 프로세스의 예시적인 실시예를 도시한다. 이 경우 수정된 텍스트는 상자(340, 350)에 도시된 바와 같이 응답에 첨부되지 않거나 여전히 수정되어 있기 때문에 응답 메시지에 보이지 않는다. 수정된 텍스트를 보기 위한 링크는 위에 설명된 바와 같이 IP 및/또는 인스턴트 콜(instance call) 제한을 갖도록 구성될 수 있어 링크가 나중에 클릭되면 브라우저 창에 예를 들어 “수정된 텍스트가 만료되었습니다. 자세한 정보는 발신자에게 문의하십시오” 텍스트를 표시할 것이다.

도 17은 발신자 또는 발신자의 조직의 요구에 부응하도록 시스템을 구성하는데 사용될 수 있는 본 발명의 일 실시예의 예시적인 설정 메뉴를 도시한다. 예를 들어, 수정 옵션은 수정된 텍스트를 암호화할 암호화 옵션을 미리 선택하도록 설정될 수 있다. 도 18에 도시된 바와 같이, 수정될 원본 텍스트를 발신자 시스템에서 추출하여 암호화하여 첨부물로 전송하거나, 대안적으로 메시지의 헤더에 전송하여 RPost 네트워크로 전송될 수 있다.

도 19는 DLP 또는 필터링 규칙을 사용하여 아웃바운드 이메일 게이트웨이 서버에서 메시지를 처리하기 위해 내용 표시자를 기반으로 텍스트를 미리 선택하도록 수정 옵션이 선택될 수 있는 다른 실시예를 도시한다.

도 20은 수정된 응답 시스템(400)을 포함하는 시스템의 일 실시예를 도시하는 흐름도이다. 이 시스템은 RPost 서버에 의해 제공된 서비스를 사용하도록 허가되고 등록된 발신자에 의해 사용된다. 메시지 내용은 상자(405)에서 수정을 위해 발신자에 의해 표시된다. 박스(410)에서 메시지는 서버 또는 소프트웨어에 의해 수정된 처리를 위해 식별되며, 이 소프트웨어는 서버에 또는 사용자의 클라이언트 시스템에 위치될 수 있다. 상자(415)에 도시된 바와 같이 선택될 수 있는 하나의 옵션은 메시지가 보안 전송에 의해 RPost 서버에 전송될 수 있다는 것이다.

상자(420)에서 메시지는 수정 서버로 라우팅된다. RPost 서버에서 수신된 메시지는 RPost 서버에서 실행 중인 프로세스에 의해 처리되며 이는 그 후에 상자(430)에서 발신자에 의해 설정된 수정 설정을 결정하기 위해 조회한다. 상자(435)에서 수정된 내용이 상자(430)에서 결정된 설정에 따른 메시지로부터 제거된다. 일 실시예에서, 수정된 내용은 상자(440)의 메모리에 일시적으로 저장된다. 다른 실시예에서, 수정된 내용의 저장은 박스(445)의 수정된 내용을 보기 원하는 수신자 또는 사용자의 시청 권한을 제한하도록 구성될 수 있다.

다른 실시예에서, 수정된 메시지는 박스(430)의 시스템에 의해 결정된 포맷 설정에 따라 상자(450)에서 재포맷팅 된다. 수정된 메시지는 상자(455)에서 수산자에게 전송되며, 이 전송은 상자(460)에 나타나는 것과 같이 보안 전송 루트를 통해 달성될 수 있다. 수신자는 상자(465)에서 수정된 메시지를 열고 상자(470)의 발신자 설정에 따라 수정된 내용을 본다. 도 19에 도시된 바와 같이, 수신자는 메모리에 임시로 저장된 수정된 내용을 수신자에게 제공하기 위해 시스템을 활성화하는 메시지에 저장된 링크를 클릭함으로써 상자(470)에서 수정된 내용을 대안적으로 볼 수 있다.

다른 실시예에서, 프로세스는 박스(440)에서 박스(470)로 직접 분기될 수 있으며, 수신자는 발신자 설정에 따라 수정된 내용을 볼 수 있다. 다른 실시예에서 위에 설명된 바와 같이, 수신자는 상자(475)에서 메시지에 응답할 수 있으며, 응답 메시지는 수정된 내용을 포함하지 않고 위에 설정된 설정에 따라 도 20의 상자(480)에서 구성 및 포맷팅될 수 있다.

도 21은 위에 설명된 공개된 등록된 암호화 실시예를 수행하는데 이용되는 워크플로우(400)의 예시적인 실시예를 도시한다. 예시적인 실시예에서, 발신자(505)는 등록된 암호화 서비스를 제공하는 서버(515)에 아웃바운드 이메일(510)을 전송한다. 처리 후, 아웃바운드 이메일(520)은 수신자(525)에 전송된다. 처리된 이메일을 수신자에게 전송하기 전, 동시에 또는 전송한 후, 시스템은 530에서 등록된 암호화 기록 이메일을 발신자에게 전달하고 발신자의 조직(535)을 위해 의도된 보고서의 등록된 암호화된 기록 또한 전송할 수 있다.

발신자(505)가 메시지(510)를 보내고 이메일이 수신자에게 안전하게 전송되거나 암호화된 경우, 발신자 측(또는 발신자)의 서버는 암호화 형태로 메시지를 전송하도록 의도되며, 이는 HTTPS, TLS 또는 다른 프로토콜을 사용하는 보안 전송 또는 PKI, PGP 또는 다른 암호화 시스템을 사용하는 메시지 수준에서 보안되는 메시지일 수 있다. RPost 네트워크 서버(515)는 발신자의 시스템, 발신자의 이메일 서버, 발신자의 게이트웨이 또는 중간 서버에서 소프트웨어로 구현될 수 있다.

발신자의 이메일(510)이 RPost 네트워크 서버(515)에서 수신될 때, 서버는 메시지가 메시지 수준 암호화로 암호화 되었는지 식별한다. 그렇다면, 서버(515)는 적절한 해독 방법으로 메시지를 해독하고, 해독이 수행되었다는 사실, 해독 방법을 서버 운영자에 의해 프로그래밍된 바와 같이 타임 스탬프 및 메시지 ID 및 다른 식별자와 함께 기록한다. 서버는 그런 다음 발신자의 원하는 수준과 암호화 방법으로 수신자에게 전달하기 위한 메시지를 처리한다.

메시지가 메시지 수준 암호화되는 경우, 서버(515)는 발신자의 원하는 수준 및 암호화 방법으로 수신자에게 전달하기 위한 메시지를 처리한다. 메시지가 수신될 때 또는 메시지가 수신자에게 계속된 후에 서버(515)는 마지막 홉의 메시지 히터 데이터(message heater data)로부터의 식별자 및 인바운드 메시지 헤더 데이터를 구문 분석하고 보안 전송 정보(즉, TLS v1.2)를 검색하고, 보안 전송 프로토콜 정보의 식별 사실을 기록하고 메시지 식별자 및 홉 서버 식별자와 함께 서버와 통신하는 데이터베이스에 식별자를 배치하며, 가장 최근에 수신된 홉으로부터 계층적으로 보안 전송 정보를 기록한다. 도 22는 서버가 구문 분석되고 데이터베이스로 복사될 수 있는 발신자로부터의 인바운드 메시지 헤드로부터 수신하는 정보의 유형을 도시한다.

서버의 발신자로부터 인바운드로 수신된 이메일에는 마지막 홉의 순서로 일련의 헤더가 있다(즉, 송산자에서 교환 서버로 게이트웨이 서버로 경계 서버 서비스로 처리 서버 게이트로 - 각각은 전송의 TLS 보안 수준을 갖거나 갖지 않을 수 있으며 상이한 TLS 보안 수준을 가질 수 있다). 처리 서버는 이 헤더를 기록하고 여기에서 프로그램을 실행하여 이전 홉을 보기 위한 옵션과 함께 적어도 “마지막으로 수신된 서버 이름/ TSL에 의한 보안(프로토콜 수준)”을 구문 분석하고 수신된 메시지가 메시지 수준으로 암호화되는 경우 분석이 무시된다(재정의됨). 대안적인 실시예에서, 발신자 조직은 마지막 홉 단독 또는 모든 홉에 대한 보안 결정으로 보기 레벨(마지막 홉, 모든 홉)을 선택할 수 있다. 처리 서버의 발신자로부터 인바운드로 수신된 메시지의 이메일 헤더 구문 분석은 프로세서 집약적일 수 있으므로, 이 구문 분석은 메시지가 프로세스에서 수신자에게로 이동한 후에 수행될 수 있다. 헤더에서 구문 분석/복사된 내용은 데이터베이스에 배치되고 발신자 보안에 중요한 계층에 따라 분류된다(즉, 최상, 수용 가능한, 실패).

이메일(510)의 처리가 서버(515)에 의해 완료된 후, 서버(515)는 처리된 메시지를 아웃바운드 이메일(520)로서 고객 또는 사용자 보안 설정에 따라 수신자에게 전송한다. 메시지(520)는 발신자의 보안 전송 선호도에 따라 수신자(525)에게 전송된다. 메시지가 메시지 수준 보안을 위해 처리되는 경우 RPost 서버에서 메시지를 재암호화한 사실이 메시지 ID 및 암호화 방법, 타임스탬프 등과 연관되어 기록된다. 메시지가 보안 전송(즉, TLS)을 위해 처리된 경우, 전송 후 SMTP/ESMTP 또는 다른 프로토콜의 경우(즉, HTTP) 메시지 전송 프로토콜 정보가 전송에 성공적으로 사용된 보안 전송 프로토콜에 관한 세부사항(즉, TLS 1.2) 및 보안 전송의 사실을 결정하는 부분에 대해 기록되거나 구문 분석된다. 이 프로토콜 정보는 메시지 ID 및 수신된 보안 정보와 연관된 데이터베이스에 저장된다. 데이터베이스에 배치된 구문 분석/복사된 메시지 전송 프로토콜 부분은 발신자 보안에 중요한 계층에 기초하여 분류된다(즉, 최상, 수용 가능한, 실패).

다시 도 21을 참조하면, 상자(530, 535)에서 서버(515)는 이메일의 암호화 기록을 발신자 및/또는 발신자의 조직에 제공하도록 구성될 수 있다. 이 프로세스에서 구문 분석/복사된 메시지 전송 프로토콜 부분은 데이터베이스에 배치되고 발신자 보안에 중요한 계층(즉, 최상, 수용 가능한, 실패)에 따라 분류된다. (발신자로부터 수신된) 그리고 (수신자로 보내진) 범주가 일치하여 결과(해석) 및 프로토콜/방법 데이터를 표시하는 차트와 함께 (발신자로부터 수신된) 그리고 (수신자로 보내진) 레벨의 합계보다 더 높은 것으로 설정될 수 있는 보안 수준의 합계가 표시된다.

도 23은 발신자 또는 발신자의 서버에 의해 제공되는 이메일에 대해 등록된 암호화 분석을 수행하기 위한 프로세스의 하나 이상의 실시예의 다양한 예를 도시한다. 예를 들어, 발신자로부터 수신된 파라미터가 “최상”과 동일하고, 수신자로 보내진 파라미터가 “수용 가능한”과 동일한 경우 전체 결과는 “수용 가능한”이다. 다른 예에서, 발신자로부터 수신된 파라미터가 “최상”이지만 수신자로 보내진 파라미터가 “실패”인 경우 전체 결과는 “실패”이다. 다른 예에서, 발신자로부터 수신된 파라미터가 “수용 가능한'이고 수신자에게 보내진 파라미터가 “수용 가능한”인 경우 전체 결과는 “수용 가능한”이다.

도 24는 본 발명의 다양한 실시예에서 서버에 의해 발신자에게 제공될 수 있는 발신자로부터 다양한 수신자(610)로 전송된 메시지의 상태(615)를 보여주는 발신자와 연관된 다양한 파라미터를 포함하는 테이블(600)을 도시한다. 제1 예에서, Bob이 Sue에게 보낸 메시지의 분석은 다음과 같은 결과를 제공한다: (발신자로부터 수신된)=최상; (수신자로 보내진)=최상; 결과적으로 최상의 전체 결과가 나타난다. 표 의 3 행에 도시된 제2 예에서, Bob이 Jimdprp 보낸 이메일의 결과는 다음과 같다: (발신자로부터 수신된)=실패; (수신자로 보내진)=최상; 결과적으로 실패의 전체 결과가 나타난다. 도 28에 도시된 바와 같은 보고서는 나중에 인증을 위해 제출될 수 있는 데이터를 포함할 수 있다.

도 25는 발신자(605)와 연관된 다양한 파라미터를 포함하고 본 발명의 다양한 실시예에서 메시지에 관련된 보안 보고서(650)를 포함하여 서버에 의해 발신자에게 제공될 수 있는 발신자로부터 다양한 수신자(601)에게 보내진 메시지의 상태를 보여주는 테이블을 도시한다.

도 26은 등록된 암호화 프로세스에 의해 수행될 수 있는 프로세스 워크플로우(700)의 실시예를 도시하는 흐름도이다. 상자(705)에서, 메시지가 처리 서버를 통해 발신자로부터 수신자로 보내진다. 메시지는 상자(710)의 처리 서비스에서 수신된다. 프로세스는 그 다음 상자(715)로 분기할 수 있고, 수신된 메시지는 처리 서버에서 분석되고 메시지 헤더는 상자(720)에서 구문 분석되고 수신된 메시지 헤더 정보는 상자(725)의 보안 수준 및 다른 파라미터에 따른 데이터베이스에 저장된다.

다시 상자 (710)로 돌아가면, 처리 서버가 수신자에게 전송하기 위해 메시지를 준비하는 상자(735)에서 메시지가 추가로 처리된다. 박스(740)에서 처리 서버는 수신자로의 전송을 위해 메시지를 보안화한다. 프로세스는 처리 서버가 메시지를 보안화하는 사실 및 방법을 기록하는 상자(745)로 분기할 수 있다.

상자(740)의 프로세스 후에 메시지는 상자(750)에서 수신자에게 전송되고, 수신자는 상자(760)에서 메시지를 수신한다.

상자(740)로 돌아가서, 시스템은 또한 메시지를 수신자에게 전송하는데 사용되는 전송 프로토콜의 적어도 일부를 기록하고 상자(755)에서 서버와 연관된 데이터베이스에 이를 저장할 수 있다.

이제 상자(765)를 참조하면, 데이터베이스는 메시지의 보안 수준을 결정하기 위해 데이터베이스 데이터를 처리할 수 있고, 상자(770)의 보안 수준을 참조하는 보고서가 생성될 수 있다. 인증 준비 보고서는 이메일로 보내지거나 그렇지 않으면 상자(775)에서 발신자 또는 발신자 조직에게 이용 가능하게 될 수 있다. 다른 실시예에서, 보고서 데이터는 박스(780)의 인증을 위해 제출될 수 있다.

AMP HTML 이메일 포맷 실시예를 갖는 수정된 응답

대안적인 실시예는 이메일의 MIME 부분의 Plaintext 버전 및 HTML 버전에서 링크/이미지로부터 보여지는 수정을 위해 표시된 텍스트와 함께 이메일의 메시지 AMP 버전, text/x-amp-html의 본문의 수정을 위해 식별된 내용을 표시하는 방식으로 AMPHTML 이메일 포맷을 사용하는 것이다. 도 27의 개략도에 의해 도시된 바와 같이, 이메일은 메시지 본문과 이메일에 대한 첨부물을 포함하는 MIME 트리로 구성된다. 이메일에 AMP를 포함하면 내용 유형이 text/x-amp-html(815)인 새 MIME 부분이 multipart/alternative(800)의 하위 항목으로 추가된다. 기존의 text/html(805) 또는 tex/plain 부분(810) 옆에 있다. 이는 이메일 메시지가 모든 클라이언트에서 작동하도록 한다. 이 실시예에서, text/x-amp-html 부분은 multipart/alternative 노드 아래에 있어야 하고 text/x-amp-html MIME 부분은 text/html MIME 부분 전에 배치되어야 한다. 이 배열의 예는 아래에 설명된 코드에 도시된다:

이 실시예에서, AMP 이메일 부분을 읽을 수 있는 이메일 클라이언트는 사용자가 AMP 이메일 메시지에 응답하거나 전달할 때 MIME 트리의 text/x-amp-html 부분을 제거해야 하므로, 이 전체 메시지 내용은 응답할 때 수정되기 때문에(메시지의 AMP 부분은 응답에 포함되지 않음) 수정을 위한 목표화된 내용은 이메일의 AMP 부분만의 메시지 본문에서 볼 수 있으며 메시지의 HTML 및/또는 TEXT 부분은 응답에서 수정을 위해 지정된 텍스트를 수정하기 위해 이전 실시예에서 설명된 그대로 유지된다.

이것이 이 실시예에의 이메일이 수정을 위해 태그된 내용의 이미지 보기에 대한 링크를 포함하는 HTML 및 TEXT 부분에 대응하는 컨텐츠를 제공하는 것 또는 수정을 위해 태그된 내용이 (설명된 다른 실시예에 따라) 메시지의 HTML 및 TEXT 부분이 아닌 첨부물에 추가로 배치될 필요가 있다는 것이 중요한 이유이다.

또한, 이 실시예에서 메시지의 AMP 부분에서 수정을 위해 표시된 컨텐츠는 동적 속성으로 설정될 수 있으며, 예를 들어 내용을 한번 보고 메시지 새로고침 시 대체 내용으로 교체되거나 내용을 보고 사용자가 메시지 내용을 읽거나 수락 했음을 동적 AMP 내용에 표시하도록 허용하고 그 후에 동적 내용이 수신자에 대해 표시되지 않는다.

AMP는 모바일 클라이언트에서 초고속 웹 페이지를 개발하는 것으로 알려진 기술이다. AMP는 성능 및 보안에 추가로 중점을 둔 기능성을 쉽게 활성화하는 JavaScript로 지원되는 HTML 태그의 세트이다.

AMPHTML 이메일 포맷은 이메일 메시지에서 사용할 수 있는 AMP 구성요소의 하위 집합을 제공한다. AMP 이메일의 수신자는 이메일에서 직접 AMP 구성요소를 보고 상호작용할 수 있다.

AMP 포맷을 갖는 추가 실시예

또한 이 실시예에서 수신자 메일 클라이언트가 AMP 보기를 수락할 수 있는지 여부를 검출할 수 있으며, 그렇다면 메시지의 AMP 버전만 사용하고 MIME 메시지 포맷의 텍스트 및 HTMP 부분에서 수정된 내용을 완전히 제외한다.

AMP 포맷팅된 메시지를 볼 수 있는 수신자의 지식은 AMP 개방 검출 픽셀 추적(AMP open detection pixel tracking)을 사용함으로써 수행될 수 있으며, AMP 내용이 픽셀/이미지를 호출하는 경우 서버는 이 사용자가 AMP 보기 능력이 있다는 것을 데이터베이스에 저장할 수 있으며 향후 메시지를 위해 메시지의 AMP 버전에서 수정을 위한 컨텐츠 마켓을 표시하고 수정된 내용을 메시지의 MIME 메시지 포맷의 텍스트 및 HTMP 부분에서 완전히 제외한다.

등록된 암호화 실시예에 더하여, 서버는 전달된 개인 내용이 AMP 메시지 포맷이고 HTML 및 텍스트 MIME 부분에서 제외되었는지 여부를 메시지와 연관된 데이터베이스에 기록하여 응답 내용이 자동적으로 수정되는 것이 기록될 수 있다.

개시된 열 교환 시스템이 특정 예 또는 실시예를 참조하여 위에서 설명되었지만, 다양한 추가, 삭제, 변경 및 수정이 응답의 민감한 메시지 부분의 우발적인 공개를 방지하고 암호화된 전자 메시지 전달의 확인을 위해 개시된 시스템 및 방법의 의도된 사상 및 범위를 벗어나지 않고 설명된 예 및 실시예에 대해 이루어질 수 있다. 예를 들어, 일 실시예 또는 예의 임의의 요소, 단계, 부재, 구성요소, 조성, 반응물, 부분 또는 일부가 달리 명시되지 않는 한 또는 그렇게 하는 것이 그 실시예 또는 예를 그 의도된 사용을 위해 부적절하게 만들지 않는 한 다른 실시예 또는 예에 통합되거나 사용될 수 있다. 또한, 방법 또는 프로세스의 단계가 특정 순서로 설명되거나 나열되는 경우, 달리 명시되지 않는 한 또는 그렇게 하면 방법 또는 프로세스가 의도한 목적에 적합하지 않게 되지 않는 한 그러한 단계의 순서가 변경될 수 있다. 추가로, 본 명세서에 기재된 임의의 실시예 또는 예의 요소, 단계, 부재, 구성요소, 조성, 반응물, 부분 또는 일부는 달리 명시되지 않는 한 임의의 다른 요소, 단계, 부재, 구성요소, 조성, 반응물, 부분 또는 일부의 부재 또는 실질적인 부재로 선택적으로 존재하거나 또는 사용될 수 있다. 모든 합리적인 추가, 삭제, 수정 및 변경은 설명된 예 및 실시예의 등가물로 간주되어야 하며 다음 청구범위의 범위 내에 포함되어야 한다. 본 개시는 첨부된 청구범위에 의해서만 제한된다.

Claims (15)

1. 이메일 메시지에 대한 수정된 응답 서비스를 제공하기 위한 시스템으로서,
   수정을 위해 발신자에 의해 표시된 메시지 포함 컨텐츠를 수신하고,
   메시지가 수정을 위해 표시된 컨텐츠를 함유하는지 결정하고,
   수신된 메시지를 처리하는데 사용될 메시지의 발신자에 의해 설정되는 임의의 설정이 있는지 결정하고,
   결정된 설정에 따라 수정을 위해 표시된 내용을 제거하고,
   결정된 설정에 따라 메시지를 다시 포맷팅하고(reformat),
   다시 포맷팅된 메시지 및 제거된 내용과 연관된 정보를 수신자에게 전송하도록,
   프로그래밍되는 수신자로부터 원격으로 떨어진 서버를 포함하는,
   이메일 메시지에 대한 수정된 응답 서비스를 제공하기 위한 시스템.
2. 제1항에 있어서,
   상기 서버는 메모리에 저장된 데이터베이스에 제거된 내용을 저장하도록 추가로 프로그래밍되는,
   이메일 메시지에 대한 수정된 응답 서비스를 제공하기 위한 시스템.
3. 제2항에 있어서,
   상기 서버는 저장된 제거된 내용을 보는 것과 연관된 다양한 파라미터를 제한하기 위해 제거된 내용에 대해 보기 제한을 추가하도록 프로그래밍되는,
   이메일 메시지에 대한 수정된 응답 서비스를 제공하기 위한 시스템.
4. 제2항에 있어서,
   상기 제거된 내용과 연관된 전송된 정보는 데이터베이스에 저장된 제거된 내용에 액세스를 제공하는 링크인,
   이메일 메시지에 대한 수정된 응답 서비스를 제공하기 위한 시스템.
5. 제1항에 있어서,
   상기 서버는 전송된 다시 포맷팅된 메시지에 기초하여 응답 베시지가 포함할 수 있는 내용을 제한하는 응답 제어 정보를 포함하는 전송된 다시 포맷팅된 메시지에 대한 링크를 추가하도록 더 프로그래밍되는,
   이메일 메시지에 대한 수정된 응답 서비스를 제공하기 위한 시스템.
6. 제6항에 있어서,
   제어 정보는 응답이 제거된 내용과 연관된 정보를 포함하는 것을 방지하는,
   이메일 메시지에 대한 수정된 응답 서비스를 제공하기 위한 시스템.
7. 제6항에 있어서,
   상기 제어 정보는 발신자에 의해 설정되는 정보를 포함하는,
   이메일 메시지에 대한 수정된 응답 서비스를 제공하기 위한 시스템.
8. 이메일 시스템을 위해 등록된 암호화 서비스를 제공하기 위한 시스템으로서,
   발신자로부터 메시지를 수신하고,
   수신된 메시지의 하나 이상의 헤더를 구문 분석하고,
   발신자에 의해 제공된 다른 데이터 또는 보안 수준에 따라 데이터베이스의 하나 이상의 구문 분석된 헤더와 연관된 정보를 저장하고,
   의도된 수신자로의 전송을 위해 수신된 메시지를 보안화하고,
   수신자에게 보안 메시지 및 보안 메시지와 연관된 정보를 전송하고,
   메시지의 보안 수준을 결정하기 위해 데이터베이스에 저장된 정보를 처리하고,
   결정된 보안 수준의 표시를 포함하고 전송된 보안 메시지에 관련되는 보고서를 생성하도록,
   프로그래밍되는 수신자로부터 원격으로 떨어진 서버를 포함하는,
   이메일 시스템을 위해 등록된 암호화 서비스를 제공하기 위한 시스템.
9. 제8항에 있어서,
   생성된 보고서는 인증 준비 보고서인,
   이메일 시스템을 위해 등록된 암호화 서비스를 제공하기 위한 시스템.
10. 제9항에 있어서,
    상기 인증 준비 보고서는 발신자에게 전송되는,
    이메일 시스템을 위해 등록된 암호화 서비스를 제공하기 위한 시스템.
11. 제8항에 있어서,
    상기 서버는 메모리에 저장된 데이터베이스의 수신된 메시지를 보안화하는데 사용되는 방법의 기록을 저장하도록 추가로 프로그래밍되는,
    이메일 시스템을 위해 등록된 암호화 서비스를 제공하기 위한 시스템.
12. 제8항에 있어서,
    상기 서버는 메모리에 저장된 데이터베이스에서 수신자에게 보안 메시지를 전송하도록 사용되는 전송 프로토콜의 부분을 포함하는 기록을 저장하도록 추가로 프로그래밍되는,
    이메일 시스템을 위해 등록된 암호화 서비스를 제공하기 위한 시스템.
13. 제8항에 있어서,
    상기 서버는 메모리에 저장되는 데이터베이스에서 수신자에게 전달되는 메시지를 보안화하는데 사용되는 방법의 기록을 저장하도록 추가로 프로그래밍되는,
    이메일 시스템을 위해 등록된 암호화 서비스를 제공하기 위한 시스템.
14. 제8항에 있어서,
    상기 서버는 메모리에 저장된 데이터베이스에서 수신자에게 보내지는 메시지를 보안화하는데 사용되는 방법 및 발신자로부터 수신되는 메시지를 보안화하기 위한 발신자 또는 발신자 서버에 의해 사용되는 방법의 기록을 저장하도록 추가로 프로그래밍되는,
    이메일 시스템을 위해 등록된 암호화 서비스를 제공하기 위한 시스템.
15. 제8항에 있어서,
    상기 서버는 수신자에게 보내지는 메시지로부터의 내용 수정의 활성화를 기록하도록 추가로 프로그래밍되는,
    이메일 시스템을 위해 등록된 암호화 서비스를 제공하기 위한 시스템.

Images