KR20100017704A - 인증서 레지스트리, 인증서 레지스트리 시스템 및 방법 - Google Patents

인증서 레지스트리, 인증서 레지스트리 시스템 및 방법 Download PDF

Info

Publication number
KR20100017704A
KR20100017704A KR1020097025575A KR20097025575A KR20100017704A KR 20100017704 A KR20100017704 A KR 20100017704A KR 1020097025575 A KR1020097025575 A KR 1020097025575A KR 20097025575 A KR20097025575 A KR 20097025575A KR 20100017704 A KR20100017704 A KR 20100017704A
Authority
KR
South Korea
Prior art keywords
information
certificate
authentication
providers
checksum
Prior art date
Application number
KR1020097025575A
Other languages
English (en)
Other versions
KR101133829B1 (ko
Inventor
스탠리 츄
제프 스미스
크리스토프 구스타브
Original Assignee
알까뗄 루슨트
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 알까뗄 루슨트 filed Critical 알까뗄 루슨트
Publication of KR20100017704A publication Critical patent/KR20100017704A/ko
Application granted granted Critical
Publication of KR101133829B1 publication Critical patent/KR101133829B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer

Abstract

인증서 레지스트리 시스템은 복수의 정보 제공자 각각에 인증 증명서를 발행하고, 인증 증명서 모두에 상응하는 루트 인증서를 유지하도록 구성된다. 인증 증명서 각각은 자신의 각 인증 정보를 상응하는 정보 제공자의 식별 정보에 링크시킨다. 인증 증명서 각각은 상응하는 정보 제공자와 그의 도메인 네임 정보 사이의 연계성을 갖지 않는다. 인증서 레지스트리의 인증 증명서는, 정보 제공자가 제공하는 정보의 특정 타입, 정보 제공자가 관련된 특정 조직, 정보 제공자가 종사하는 특정 직업군 및 정보 제공자가 위치하는 특정 지리적 구역 중 적어도 하나에 적어도 부분적으로 의존한다.

Description

인증서 레지스트리, 인증서 레지스트리 시스템 및 방법{VERIFYING AUTHENTICITY OF WEBPAGES}
본 발명은 일반적으로 컴퓨터 네트워크 시스템에서의 인증 규정에 관한 것으로, 보다 구체적으로는 웹페이지의 신뢰성 입증에 관한 것이다.
다양한 이유로 인하여, 이메일 메시지 전송자의 신뢰성 입증에 대한 필요성은 줄어들지 않고 있다. 이러한 인증은 이메일 메시지에서 지정된 전송 엔티티의 식별 정보가 인증될 수 없을 때 경고를 제공해야 한다. 이메일 메시지에 제공되는 전송자 식별 정보의 예는 전송 엔티티의 네임, 로고, 가청 사운드 등을 포함하지만 이것으로 한정되지는 않는다. 불법적이고 부정한 이메일 메시지를 전송하는 엔티티가 누구인지를 아는 것이 유용할 수 있지만, 이메일 메시지에 제공된 전송자 식별 정보가 신뢰할 수 있는 인증 프로세스를 통과하였는지 또는 실패하였는지를 단순히 아는 데에는 엄청난 대가가 필요하다. 유사하게, 인증이 불법적이거나 부정한 이메일 메시지를 전송한 사람 또는 엔티티를 식별하지 않음에도 불구하고 이메일 메시지 전송자가 성공적으로 인증되었는지 여부를 아는 데에는 대가가 필요하다.
이러한 이메일 메시지 인증을 제공하는 효율적이고 실용적인 수단의 부재로 인하여 예컨대 "피싱(phishing)"과 같은 범죄 활동이 빠르게 증가하고 있다. 피싱에서, 범법자는 전형적으로 예를 들어 금융기관, 온라인 서비스 제공자 등과 같은 유명한 및/또는 신뢰할 수 있는 엔티티로부터 이메일 메시지가 전송된 것으로 가장하여 수신자에게 이메일을 전송한다. 이메일 메시지는 수신자가 기밀 정보를 응답하도록 한다(예를 들어, 기밀 정보가 입력될 수 있는 불법적인 웹사이트로의 링크를 통해). 만약 정보가 획득되면, 범법자는 이러한 금융 정보를 사용하여 이메일 메시지 수신자의 상응하는 계좌 또는 계좌들을 위태롭게 한다. 금융 정보의 예는 은행 계좌로의 접속에 사용되는 정보, 투자 계좌, 온라인 지불 서비스 계좌, 온라인 경매 계좌 등을 포함하지만 이것으로 한정되지 않는다. 이러한 정보를 이용하여, 범법자는 전형적으로 상응하는 계좌로부터 자금을 훔치거나 또는 수신자의 아이덴티티를 사용하여 다른 사람 또는 엔티티에 대한 금융 사기를 용이하게 하는 데에 이러한 계좌 정보를 사용한다. 불행히도, 피싱 기법이 매주 더욱 내밀해짐에 따라 피싱 문제도 점점 증가하고 있다.
이메일 메시지 전송자의 인증과 관련하여, 한가지 알려진 솔루션은 SPF(sender policy framework)이다. SPF는 해당 도메인으로부터 이메일 메시지를 전송하는 것이 허용된 것으로 지정된 장치로부터 온 이메일 메시지를 컨펌하고자 한다. 불행히도, 도메인의 합법성에 대한 검사는 존재하지 않는다. 따라서, 어느 누구나 'x-company-special-on-TV.com'과 같은 도메인을 등록할 수 있으며 x-company에서 이메일 메시지를 전송하는 것으로 주장할 수 있다.
혹스(Hoax) 이메일 메시지는 이메일 메시지의 전송자를 인증하는 것이 유리한 다른 상황을 나타낸다. 예를 들어, 다수의 혹스 이메일이 믿을만한 소스로부터 온 것으로 주장하지만 그들은 명백히 그렇지 않다. 그러나, 현재 이메일 메시지의 수신자를 위해 전송자 아이덴티티를 효율적이고 실질적으로 인증하는 방법은 존재하지 않는다. 실제의 믿을만한 소스로부터의 부인은 이러한 혹스 이메일 메시지를 거의 억제하지 못한다.
일반적으로 "스팸"으로 지칭되는 요구하지 않은 대량 이메일링이 광범위해졌다. 스팸을 제어하기 위한 모든 시도에도 불구하고, 이것의 발생 속도는 계속 증가하고 있으며 이제 모든 이메일 메시지의 대다수를 차지하는 것으로 예측된다. 따라서, 스팸의 빈도와 양을 감소시킬 것이 필요하다. 또한, 이러한 요구하지 않은 대량의 이메일링이 전형적으로 해당 이메일 메시지가 합법적인 및/또는 신뢰가능한 엔티티로부터 온 것이라 위장으로 나타내는 헤더 정보를 갖는다는 사실은 이상할 것이 없다. 헤더 정보의 인증은 사람들이 수신하는 스팸의 양을 제한하고 피싱과 같은 관련된 불법적인 사건을 겪을 가능성을 제한하는 수단을 제공할 수 있다.
불법적인 웹페이지가 종종 셋업되며 종종 이메일 메시지를 통해 개시된 피싱 활동을 지원하는 데에 사용된다. 이러한 불법 웹사이트는 그것이 신뢰할 수 있는 기관인 것처럼 나타내지만, 실제로는 범죄 활동을 하기 위한 특정 용도로 설정된 것이다. 따라서, 해당 엔티티가 웹페이지 및/또는 웹사이트의 제어하에 있음을 입증하는 것에 큰 대가가 존재한다.
이메일 메시지 및 웹페이지와 같이, IM(Instant Messaging) 시스템은 가짜 아이덴티티의 사용을 통해 범죄적 또는 사기 행각이 전형적으로 침투되는 또 다른 네트워크 기반의 통신 접근법이다. IM 스크린 네임이 특정한 기관으로부터 온 것이라는 인증과 같이, IM 메시지의 전송자로서 지정된 IM 스크린 네임의 인증이 요구된다. 이러한 인증 없이, 기밀 정보는 IM을 사용하여 통신을 통해 직접적 또는 간접적으로 쉽게 위험에 처할 수 있다.
현재, 이메일 메시지, 웹사이트/웹페이지 및/또는 IM 메시지를 수신자에게 제공하는 것을 담당하도록 의도된 엔티티를 인증하기 위한 완전한 및/또는 효과적인 솔루션은 존재하지 않는다. 피싱, 스팸 및 데이터 통신 네트워크 상에서 발생하며 위조된 아이덴티티 정보에 기반을 두는 범죄적인 사기 행각의 다른 유형은 지속되고 증가하고 있다. 위조 아이덴티티 정보에 기초하는 이러한 범죄적인 사기 행각의 문제점을 해결하는 것과 관련된 솔루션의 조각들 또는 부분적인 솔루션은 존재하지만, 이것은 이러한 문제점들을 완전하고 적절하게 해소하지 않는다.
웹페이지가 상응하는 URL의 실제 소유자로부터 온 것임을 컨펌하기 위한 알려진 일 솔루션은 SSL/TLS(Secure Socket Layer/Tranport Layer Security) 프로토콜과 조합된 DNS(Domain Name System)이며, 이는 HTTP(즉, SSL 보호를 갖는 하이퍼텍스트 전송 프로토콜)로서도 알려져 있다. 불행히도, 몇몇 요소가 이러한 솔루션을 부적절하게 하는데에 일조한다. 이러한 알려진 솔루션이 덜 효율적이게 하는 하나의 요소는 다수의 기업들이 복수의 도메인 네임을 사용하고 이러한 도메인 네임들은 일관적이지 않은 규칙으로 생성된다는 것이다. 예를 들어, x-company는 모든 중요한 탑-레벨 도메인에 "x-company"를 등록할 수 있고(예컨대, x-company.com, x-company.net, x-company.org, 등) 각 국가 도메인 내에 등록할 수 있다(예컨대, x-company.ca 등). 그러나, 특별한 프로모션을 위해, x-company는 x-company-TV.com 도메인 네임을 가질 수 있지만 x-company-TV.ca 도메인 네임을 갖지 않을 수 있다. 이것은 소비자가 x-companyTV.com, x-company-TV-special.com 등과 같이 표현되는 도메인 네임에서 쉽게 혼란을 가질 수 있음을 의미한다. 알려진 솔루션이 덜 효율적이게 하는 다른 요소는 기업들이 종종 거의 광고 없이 생성되는 부속 및 다른 법인 엔티티를 갖는다는 것이다. 보통의 소비자에게 있어서 이러한 모든 도메인 네임들을 알고 있기는 어렵다. 알려진 솔루션이 덜 효율적이게 하는 또 다른 요소는 합법적으로 동일한 네임을 갖는 복수의 기업들이 종종 존재한다는 것이다. 가장 흔한 경우는 두 개의 기업이 서로 다른 권한 내에서 운영하는 경우이다. DNS 오너쉽 모델은 본질적으로 first come-first serve 정책을 갖는다. 따라서, 본질적으로 소비자가 복수의 엔티티들 중 어느 것이 "가장 명백한" 도메인 네임을 갖는지, 또는 기업이 명백하지 않은 도메인 네임을 사용하길 원한다는 것을 알기는 불가능하다. 알려진 솔루션이 덜 효율적이게 하는 또 다른 요소는 다수의 숫자 및/또는 문자가 유사하게 보인다는 것이다. 위조된 아이덴티티 정보와 관련하여 사기의 목적으로 숫자 및 문자를 사용하는 하나의 고전적인 접근법은 숫자 "0"을 대문자 "O"로 대체하거나 숫자 "1"을 소문자 "L"로 대체하는 것이다. 최근에, 키릴 문자 또는 유니코드 문자를 사용하는 훨씬 정교화된 계략들이 존재한다. 이것은 범법자가 본질적으로 실제 도메인 네임으로부터 시각적으로 구별가능하지 않은 가짜 도메인 네임을 갖도록 한다. 이러한 가짜 도메인 네임을 식별하기 위한 발견적 방법뿐 아니 라 블랙리스트를 사용하고자 시도하는 홀 클래스의 소프트웨어가 존재한다. 그러나, 이러한 소프트웨어는 사기 도메인을 블랙리스트에 추가하는 데에 소비되는 시간뿐 아니라 네트워크 오버헤드의 문제도 겪는다. 알려진 솔루션이 덜 효율적이게 하는 또 다른 요소는 스팸 이메일이 커다란 문제점으로 성장하였다는 것이다. 대부분의 필터링 노력은 예를 들어 처방된 약의 온라인 구매와 같이 현재 인기있는 스팸 주제를 식별하기 위해 이메일 메시지 콘텐츠를 검색하는 접근법을 취해왔다. 최고 수준의 스팸은 이러한 필터를 통과하도록 오기를 할 뿐 아니라 이미지를 사용하기도 한다.
최근에, "EV 인증서"(Extended Validation Certificate)로 지칭되는 인증 방법이 소개되었다. 이름이 의미하듯이, 이것은 표준(즉, 비-EV) SSL/TLS 인증서와 동일한 기초를 갖지만 추가적인 유효성을 이용한다. 표준(즉, 비-EV) SSL/TLS 인증서와 관련하여 전술된 대부분의 문제는 여전히 적용된다. EV 인증서는 이러한 사기 행각을 방지하는 것과는 상반되게 이러한 사기 행각이 발생된 후에 사기 행각(예로서 피싱)의 가해자를 색출하는 것만을 도울 것이다. 명백하게, 가해자는 종종 불법적이거나 사기의 온라인 활동을 정찰하는 것에 대한 관심 또는 온라인 사기 정찰 예산이 거의 없거나 아예 없는 환경의 쉘 엔티티이다. 따라서, EV 인증서가 이러한 방식으로 돕는다고 해도, 이것은 피싱의 문제점을 실제로 해결하지는 않는다.
따라서, 네트워크 기반의 통신 접근법이 이메일, 웹페이지 및/또는 IM인지 여부와 무관하게, 위조된 또는 그외의 불법 아이덴티티 정보에 기초하여 네트워크 인에이블된 범죄 및 사기 행각을 없애기 위한 알려진 접근법과 관련된 단점의 적어 도 일부분을 극복하는 솔루션은 유용하고, 바람직하며 새로울 것이다.
본 발명의 실시예는 위조 또는 그외의 불법 아이덴티티 정보에 기초하여 네트워크 기반의 범법 및 사기 행각을 없애기 위한 알려진 접근법과 관련된 단점을 극복한다. 보다 구체적으로, 본 발명의 실시예는 이메일 메시지의 전송자로서 지정된 엔티티, IM 메시지의 전송자로서 지정된 엔티티 및/또는 웹페이지의 소유자를 갖는 엔티티에 상응하는 아이덴티티 정보의 인증을 제공한다. 이러한 인증을 통해, 아이덴티티 정보의 수신은 이것이 의도된 엔티티를 갖는 네트워크 기반 통신 세션에 실제로 연관된다는 것을 합리적으로 보장될 수 있으며, 그에 따라 불법 또는 사기 행각에 자신도 모르게 가담하게 되는 가능성을 감소시킨다.
본 발명은 본 명세서에서 "RealName 레지스트리"로 지칭되는 레지스트리 및 관련된 인증 증명서(즉, RealName 인증서)에 의존한다. 각 RealName 레지스트리는 식별 정보를 위한 인증 기관으로서의 기능을 한다. 본 발명에 따른 식별 정보의 예는 엔티티가 인식되는 네임, 엔티티에 대해 특정된 이미지, 엔티티에 대해 특정된 텍스트 및 엔티티에 대해 특정된 사운드를 포함하지만, 이것으로 한정되지는 않는다. "식별" 기능을 DNS 및 그외의 툴과 분리시킴으로써, RealName 레지스트리는 이메일 메시지, IM 메시지, 웹페이지 등의 인증 활성화의 복잡성과 관련된 유용한 기능성을 획득하는 데에 바람직하게 사용될 수 있다.
도메인 네임은 로드 공유, 조직 트래킹, 웹사이트 계층 등을 포함하는 다수의 기능에 사용된다. 이러한 기능들은 식별 기능을 조작하기 더욱 어렵게 만드는 서로 다른 필요사항을 갖는다. 식별을 위해서, 레지스트리는 복제(및 유사 복제) 식별 정보의 모든 문제를 분석해야 한다. 명백하게, 이것은 월드와이드 기반에서 실행될 수 없으며, 따라서 본 발명의 실시예는 바람직하게는 그들이 관할 경계를 존중하는 방식으로 구성된다. 다행히도, 이러한 기능에 대한 모델인 상표 레지스트리가 존재한다. 각 관할은 자신 고유의 상표 레지스트리를 가지며, 상표의 소유를 의결하기 위한 서로 다른 규칙 및 제안된 식별 정보(예컨대, 네임)가 현존하는 상표를 위반하는지 여부에 대한 결정을 위한 서로 다른 규칙을 갖는다. 본 명세서에는 RealName 레지스트리가 상표 레지스트리와 동일한 방식으로 효율적으로 운영한다. 사실, 상표 레지스트리보다 더 분산된 RealName 레지스트리도 바람직하다. 예를 들어, 각 관할은 자신 고유의 RealName 레지스트리를 운영할 수 있고, 각 직업은 그들 고유의 RealName 레지스트리를 운영할 수 있고, 각 무역 협회가 그들 고유의 RealName 레지스트리를 운영할 수 있다. 정보 수신자(예컨대, 이메일 수신자, IM 메시지 수신자, 웹페이지 수신자 등)는 어느 레지스트리를 임포트하기 원하는지 고르고 선택할 수 있다. 최소한, 정보 수신자는 전형적으로 정보 수신자를 다루는 로컬 관할 및 직업에 대한 RealName 레지스트리를 임포트할 것이다. 이러한 RealName 레지스트리의 구조는 DNS 시스템을 괴롭히는 다수의 법적 논쟁, 불법적인(그러나 동일하게 보이는) 도메인 네임, 도메인 네임 소유자에 대한 불명확한 규칙(예컨대, x-company Inc.가 x-company rocks.com site) 등을 포함하는 다수의 문제를 비켜간다.
적소의 레지스트리를 사용하여, 이메일 메시지, IM 메시지, 웹페이지 등의 인증을 진행할 수 있다. 각 레지스트리는 "승인된" 식별 정보(즉, 일반적으로 RealName)의 데이터베이스뿐 아니라 "승인된 네임의 인증서"의 발생자로서 동작한다. 인증서(즉, 인증 증명서)는 다수의 방법으로 획득될 수 있지만, 가장 간단한 방법은 현존하는 DNS/SSL. X.509에 사용되는 X. 509 인증 증명서가 표준화된 공용 키 인프라구조(PKI)인 것이다. X.509 담화에서, 각 레지스트리는 "인증 기관"으로서 동작하고 각 인증 증명서는 본질적으로 RealName 및 공용 키를 삽입한 패키지이다. 이러한 패키지는 인증 기관의 사설 키에 의해 서명된다. 동작시에, 인증 증명서는 엔티티의 아이덴티티를 강화하기에 유용한 임의의 유형의 식별 정보를 포함하도록 구성된다.
본 발명의 일 실시예에서, 웹페이지를 인증하는 방법은 복수의 동작들을 포함한다. 복수의 정보 제공자 각각에 발행된 인증 증명서를 포함하는 인증서 레지스트리 및 인증 증명서 모두에 상응하는 루트 인증서(root certificate)를 생성하는 동작이 제공된다. 인증 증명서 각각은 자신의 각 인증 정보를 상응하는 정보 제공자의 식별 정보에 링크시킨다. 인증 증명서 각각은 상응하는 정보 제공자와 그의 도메인 네임 정보 사이의 연계성을 갖지 않는다. 인증서 레지스트리의 인증 증명서는, 정보 제공자가 제공하는 정보의 특정 타입, 정보 제공자가 관련된 특정 조직, 정보 제공자가 종사하는 특정 직업군 및 정보 제공자가 위치하는 특정 지리적 구역 중 적어도 하나에 적어도 부분적으로 의존한다. 또한 루트 인증서를 정보 수신자에게 제공하는 동작이 제공된다. 또한 정보 수신자에 의해 액세스되고 자신과 관련된 인증 증명서를 갖는 웹페이지의 입증(verification)을 활성화하는 동작이 제공된다. 이러한 입증은, 루트 인증서에 포함된 인증 정보를 사용하여 관련된 인증 증명서의 신뢰성(authenticity)을 성공적으로 입증함으로써 관련된 인증 증명서가 인증서 레지스트리에 속함을 입증하는 단계와, 관련된 인증 증명서의 신뢰성을 성공적으로 입증한 후, 관련된 인증 증명서에 포함된 인증 정보를 사용하여 웹페이지의 지정된 소유자의 아이덴티티를 성공적으로 입증하는 것을 포함한다.
본 발명의 다른 실시예에서, 인증서 레지스트리는 복수의 정보 제공자 각각에 발행된 인증 증명서와, 인증 증명서 모두에 상응하는 루트 인증서를 포함한다. 인증 증명서 각각은 자신의 각 인증 정보를 상응하는 정보 제공자의 식별 정보에 링크시킨다. 인증 증명서 각각은 상응하는 정보 제공자와 그의 도메인 네임 정보 사이의 연계성을 갖지 않는다. 인증서 레지스트리의 인증 증명서는, 정보 제공자가 제공하는 정보의 특정 타입, 정보 제공자가 관련된 특정 조직, 정보 제공자가 종사하는 특정 직업군 및 정보 제공자가 위치하는 특정 지리적 구역 중 적어도 하나에 적어도 부분적으로 의존한다.
본 발명의 다른 실시예에서, 인증서 레지스트리 시스템은 복수의 정보 제공자 각각에 인증 증명서를 발행하고, 인증 증명서 모두에 상응하는 루트 인증서를 유지하도록 구성된다. 인증 증명서 각각은 자신의 각 인증 정보를 상응하는 정보 제공자의 식별 정보에 링크시킨다. 인증 증명서 각각은 상응하는 정보 제공자와 그의 도메인 네임 정보 사이의 연계성을 갖지 않는다. 인증서 레지스트리의 인증 증명서는, 정보 제공자가 제공하는 정보의 특정 타입, 정보 제공자가 관련된 특정 조직, 정보 제공자가 종사하는 특정 직업군 및 정보 제공자가 위치하는 특정 지리적 구역 중 적어도 하나에 적어도 부분적으로 의존한다.
본 발명의 상기 목적, 실시예, 장점 및/또는 차이점과 그외의 목적, 실시예, 장점 및/또는 차이점이 첨부된 특허청구범위와 도면을 참조로 하여 아래의 설명으로부터 명백해질 것이다.
도 1은 본 발명에 따른 정보 제공자 등록을 위한 등록 인프라구조의 개략도.
도 2는 본 발명에 따른 식별 정보 인증 애플리케이션을 실행하는 사용자 디바이스에 의해 수행되는 프로세스 및 정보 아이덴티티 인증 인프라구조의 개략도.
도 3(a)-3(c)는 본 발명에 따른 식별 정보 인증 메시지를 디스플레이하는 정보 수신자 디바이스의 개략도.
도 4(a)-4(d)는 정보 수신자 디바이스로 호출자 인증 표시를 전달하는 서로 다른 방법들을 도시한 개략도.
도 5는 본 발명에 따른 이메일 메시지 인증 방법의 실시예를 도시한 순서도.
도 6은 본 발명에 따른 HTTP 페이지(예컨대, 웹페이지) 인증 방법의 실시예를 도시한 순서도.
도 7은 본 발명에 따른 IM 메시지 인증 방법의 실시예를 도시한 도면.
본 발명은 관심 파티가 본 발명에 따라 프로그램된 데이터 통신 장비로 액세스하는 임의의 사람에게 인증된 식별 정보를 제공하도록 하는 것을 허용한다. 식별 정보의 예는 엔티티가 인식되는 네임, 엔티티에 대한 이미지 명세, 엔티티에 대한 텍스트 명세 및 엔티티에 대한 사운드 명세를 포함하지만, 이것으로 한정되지는 않는다. 보다 구체적으로, 식별 정보의 예는 엔티티의 보호 네임, 엔티티의 보호 이미지, 엔티티의 보호 텍스트 및 엔티티의 보호 사운드를 포함하지만, 이것으로 한정되지는 않는다. 본 명세서에서 보호(protected)는 예를 들어 상표, 카피라이트 및 식별 정보의 그외의 등록 형태와 같은 관리기구 수단에 의해 및/또는 브랜드화된 식별 정보(예컨대, 상표)를 생성함으로써 제공되는 보호를 포함한다. 데이터 통신 장비는 전자 통신 및/또는 컴퓨터 네트워크 상에서 데이터를 통신하도록 구성된 컴퓨터 및/또는 전화 통신 장비를 지칭한다. 이러한 데이터 통신 장비의 예는 이메일 메시지를 통해 통신하도록 구성된 컴퓨터, 인스턴트 메시징(Instant Messaging)을 통해 통신하도록 구성된 컴퓨터, 인스턴트 메시징을 통해 통신하도록 구성된 전화기, 웹페이지에 액세스하도록 구성된 컴퓨터, 이메일 메시지를 전송하도록 구성된 전화기 및 웹페이지에 액세스하도록 구성된 전화기를 포함하지만, 이것으로 한정되지는 않는다.
본 발명에 프로그램된 데이터 통신 장비는 하나 이상의 식별 정보 레지스트리(즉, 하나 이상의 RealName 레지스트리) 및 하나 이상의 정보 제공자 인증 애플리케이션을 포함한다. 각 식별 정보 레지스트리는 정보 제공자의 인증을 정보 수신 자에게 제공하길 원하는 정보 제공자와 관련된 고유한 식별 정보(예컨대, 네임, 텍스트, 이미지, 사운드 등)를 저장하도록 구성된다. 정보 제공자는 정보를 수신 및/또는 액세스하기 위해 정보 수신자가 통신하는 엔티티를 지칭한다. 정보 제공자의 예는 이메일 메시지의 전송자, IM 메시지의 전송자, 웹페이지의 오너(owner) 등을 포함할 수 있지만, 이것으로 한정되는 것은 아니다. 각 정보 제공자 인증 애플리케이션은 관심 파티에 의해 발송된 데이터 통신과 관련된 인증 증명서를 수신하고, 이 인증 증명서를 관심 파티의 식별 정보의 인증을 용이하게 하는 데에 사용한다. 식별 정보가 성공적으로 인증되었는지 여부를 나타내는 통지(notification)가 정보 수신자(들)에게 전달된다.
도 1은 본 발명에 따른 식별 정보의 등록을 위한 예시적인 등록 인프라구조 및 프로세스의 개략적인 도면이다. 이 예시에서, 등록자(110)는 세 개의 개별적인 레지스트리를 갖는 레지스터이며, 레지스트리(101)는 네트워크 서비스 제공자(100)인 등록 기관(RA; registration authority)에 의해 동작되고, 레지스트리(102)는 관심 그룹(trade association과 같은)인 RA에 의해 동작되며, 레지스트리(103)는 지리상의 또는 행정상의 지역(정부 또는 그외의 공무기관 엔티티일 수 있음)인 RA에 의해 동작된다. 즉, 등록자(110)는 정보 수신자가 하나 이상의 이용가능한 레지스트리, 이 예에서는 레지스트리(101, 201, 301)에 가입하면, 가입할 때에만 정보 수신자에게 인증될 수 있다.
각 레지스트리는 각각의 RA에 의해 동작된다. 레지스트리의 동작은 본 명세서에서 레지스트리에 포함된 정보를 유지하는 것으로 정의된다. RA는 식별 정보 레 지스트리를 제공하는 것에 관심을 갖는 임의의 공공 또는 사설 기관일 수 있다. RA는 동작을 위해 어떠한 기관으로부터의 승인도 필요로 하지 않지만, 이들 기관에 의한 보증을 획득할 수 있다. 실사용자, 서비스 공급자, 및/또는 장비 공급자는 임의의 주어진 레지스트리가 신뢰할만한 것인지를 결정할 수 있고, 신뢰할만한 것으로 결정된 레지스트리에만 가입할 수 있다. 각 레지스트리는 RA(X.509 표준의 인증 기관) 및 식별 정보의 데이터베이스의 두 메인 부분으로 이루어진다. 각 레지스트리는 사전결정된 가입자 그룹, 지역 및/또는 사전규정된 관심 그룹을 담당한다. 하나의 레지스트리에 의해 담당되는 지역은 다른 레지스트리에 의해 담당되는 지역과 오버랩될 수 있으며, 둘 이상의 레지스트리가 동일한 지역을 담당할 수도 있다. 유사하게, 둘 이상의 서로 다른 규정된 관심 그룹이 오버랩될 수 있다(예컨대 의사, 보다 작게 규정된 관심 그룹으로는 소아과 의사).
레지스트리(101)는 임의의 기업, 공공 기관 또는 정부 기관으로 인증된 정보 제공자 서비스를 제공하고자 하는 네트워크 서비스 제공자(100)에 의해 유지되거나, 또는 네트워크 서비스 제공자(100)에 의해 담당되는 정보 수신자에게 인증된 식별 정보를 제공하고자 하는 다른 등록자(110)에 의해 유지된다. 레지스트리(201)는 예를 들어 캐나다 은행인 연합®(Canadian Bankers Association®)과 같이 자신의 은행 고객에게 인증된 식별 정보 및/또는 관련된 서비스를 제공하기 위해 레지스트리(201)를 유지시키는 관심 그룹(200)에 의해 동작된다. 레지스트리(301)는 예를 들어 뉴욕 주, 온타리오 주, 토론토 씨티, 시카고와 같은 지리상 또는 행정상 지역 과 관련되며, 상응하는 행정부 또는 그외의 공무기관 엔티티(300)에 의해 유지된다.
일 실시예에서, RA(100, 200, 300)에 의해 지워지는 유일한 책임은 임의의 등록자(110)의 아이덴티티의 입증을 보장하고, 이것이 서로 다른 등록자(110)에 대한 이중 식별 정보를 등록하지 않음을 보장하는 것이다. 이러한 실시예에서, 레지스트리(101)(데이터베이스와 RA로 이루어짐)는 공용으로 자유롭게 점검될 수 있으며, 혼란스럽게 유사하거나 혼동을 야기하는 정보 제공자 아이덴티티가 다른 등록자(110)에 의해 등록되지 않는 것을 보장하기 위해 레지스트리(101, 201, 301)를 정찰하는 것이 적어도 부분적으로 등록자(110) 및 그외의 관심 파티의 책임이다. 등록자(110)가 등록되었을 때, RA는 인증 증명서(104)를 발행한다. 인증 증명서는 등록된 정보 제공자 아이덴티티(즉, 식별 정보)가 등록자의 사설 키와 내재적으로 쌍을 이루는 등록자의 공용 키로 바인드됨을 증명한다.
등록 프로세스
레지스트리에 의해서 각 등록자(110)에게 제공되는 인증 증명서(104)는 임의의 알려진 인증 시스템을 따를 수 있고, 각 레지스트리는 본 발명의 범주로부터 벗어나지 않는 한 서로 다른 인증 시스템을 사용할 수 있다. 등록자의 식별 정보가 레지스트리 내에 기록되어 있을 때, 인증 증명서는 수행될 정보 제공자 인증을 허용하도록 등록자(110)에게 제공된다. 인증 증명서는 X.509와 같은 임의의 공용 키 인프라구조 방안에 기초할 수 있다.
만약 X.509 인증서가 등록자(110)에게 제공되는 인증 증명서에 대해 사용된다면, 본 발명의 일 실시예에서, 등록 프로세스는 아래와 같이 진행한다(즉, 예로서 RA(100)을 사용함).
1) RA(100)는 자신의 공용 키를 자신의 루트 인증서 내에서 사용한다. 루트 인증서는 레지스트리(즉, 인증서) 기관의 공용 키를 갖는 인증서이다. 이러한 공용 키는 인증 증명서를 검증하는 데에 사용되며, 따라서 루트 인증서는 정보 제공자 인증을 수행할 각 디바이스로 임포트되어야 한다. 전형적으로, 데이터 통신 장비의 벤더(vendor) 또는 소유자는, 임의의 로컬 지역 레지스트리, 모든 인구 이동 및 프로페셔널 레지스트리 등을 포함하는 관심 루트 인증서를, 오늘날 웹 브라우저가 PKI 루트 인증서를 이용하여 사전 로딩하는 것과 거의 동일한 방식으로 사전 로딩할 것이다. 선택적으로, 실사용자가 복수의 지역에서 사업을 하거나 또는 특정화된 레지스트리 내에 관심이 있는 경우, 실사용자가 보다 많은 루트 인증서를 임포트하는 것을 허용하는 방법이 존재한다. 당업자에게 이해되는 바와 같이, 얼마나 많은 수의 루트 공용 키가 임포트될 수 있는지에 대한 제한이나 이러한 임포트를 가능케 하는 수단에 대한 제한은 존재하지 않는다.
2) 등록부(110)가 되기를 원하는 각각의 관심 파티(즉, 레지스트리 지원자)는 자신의 고유한 공용/사설 키 쌍을 생성하고, 자신의 식별 정보 및 임의의 다른 요청된 등록 정보 및/또는 문서에 따라 공용 키를 RA(100)로 제출한다.
3) 만약 RA(100)가 관심 파티가 식별 정보의 법적 소유권을 갖거나 또는 실제로 소유한다고 결정하면, RA(100)는 식별 정보를 데이터베이스(100)로 입력하고 RA(100)의 사설 키를 이용하여 등록자의 식별 정보 및 등록자의 공용 키를 포함하는 인증 증명서에 서명한다. 따라서 RA(100)는 등록자의 공용 키가 등록자의 식별 정보로 바인드되는 "바로 그" 공용 키이며, 등록자가 해당 식별 정보를 사용하도록 하는 권한이 주어졌음을 "보장"한다.
4) 등록자(110)는 이제 자신의 식별 정보를 입증하는 서명된 인증 증명서를 구비하고, 등록자(110)는 등록자(110)가 해당 인증 증명서를 확인하도록 하는 사설 키를 구비한다. 인증 증명서의 의미가 제한적이지 않음을 이해해야 한다. 인증 증명서는 사설 키의 홀더(등록자(110)가 되어야 함)가 등록자(110)가 등록된 특정한 등록 기관(100)의 관할권 내에 디스플레이된 자신의 식별 정보를 갖도록 권한이 주어졌다는 것만을 의미한다.
정보 제공자 인증
도 2는 본 발명에 따른 정보 제공자 인증 구성의 실시예를 도시한다. 정보 수신 사용자 디바이스(즉, 디바이스(120a))는 정보 제공자 인증을 수행한다. 디바이스(120a)의 예는, 이메일 메시지를 통한 통신, 인스턴트 메시징을 통한 통신 및/또는 웹페이지 액세스를 위해 구성된 개인 컴퓨터 또는 인터넷 프로토콜(IP) 전화기와 같은 디바이스를 포함하지만, 이것으로 제한되지는 않는다. 디바이스(120a)에는 본 발명에 따라 매우 안전한 정보 제공자 인증 형태를 제공하는 정보 제공자 인증 애플리케이션(122)이 구비된다. 이러한 보안은 인증 애플리케이션(122)의 직접 제어/감시를 갖는 정보 수신자로부터 유래하며, 이는 이 정보 수신자가 오직 자신 의 디바이스를 믿기만 하면 된다는 것을 의미한다. 다른 실시예에서, 서비스에 의존하여(웹/이메일/IM), 프록시에서 인증을 수행하는 것이 가능하다. 그러나, 이러한 구성은 공격할 다수의 경로를 개방하며, 보안을 더욱 어렵게 한다. 따라서, wd보 제공자 인증 애플리케이션(122)에 구현된 디바이스(120a)가 바람직하게는 "엔드-투-엔드" 방식으로 구현될 식별 정보 인증을 위해 제공된다는 것을 알 수 있다.
도 2를 계속 참조하면, 등록자(110)가 디바이스(120a)에 의한 수신을 위해 제공된 정보의 전송을 개시할 때, 이러한 정보 전송(1a)은 당업계에서 잘 알려진 방식으로 데이터 통신 네트워크(들)를 통해 진행한다. 이러한 정보 전송의 예는, 이메일 메시지의 전송, IM 메시지의 전송, 웹사이트 콘텐츠의 전송, 웹페이지의 전송 및 데이터 통신 또는 전자통신 네트워크를 통해 정보를 전송하는 그외의 형식을 포함하지만, 이것으로 한정되지는 않는다. 제안된 정보를 전송하는 것과 관련하여, 정보 제공자 인증 상호작용(2a)은 디바이스(120a)에 의한 수신을 위해 등록자 디바이스(110)가 자신의 인증 증명서를 전송하도록 개시된다. 정보가 웹페이지인 경우에, 상호작용은 디바이스들 사이의 대화이다. 이메일 또는 IM 메시지의 경우에, 상호작용은 정보의 전송을 포함하지만, 이메일 시스템 내의 하나 또는 두 개의 엔드포인트 디바이스들로서의 두 디바이스들 사이에서의 대화가 아닐 수 있거나 또는 IM 시스템이 오프라인일 수 있다. 제안된 정보 및 인증 증명서는 데이터 네트워크 또는 통신 네트워크 상에서의 데이터 통신을 위해 적절하게 구성된 알려진 통신 프로토콜 중 동일하거나 서로 다른 것을 사용하여 전송될 수 있다. 인증 증명서의 수신에 응답하여, 정보 제공자 인증 애플리케이션(122)은 등록자 디바이스(110)와의 인증 상호작용을 전달하고 인증 상호작용 중에 획득된 인증 증명서의 신뢰성을 검증한다. 정보 제공자 인증이 레지스트리(101, 201, 301)의 큐어리(query)를 필요로 하지 않는다는 것을 이해해야 한다. 본 명세서에는 등록자 디바이스(110)가 제안된 정보 또는 서로 다른 장비의 전송을 용이하게 하는 데에 사용되는 동일한 장비일 수 있다(예컨대, 동일한 서버 또는 서로 다른 서버). 한번 결정되면, 인증 프로세스의 결과는 도 3(a)-3(c) 및 4(a)-4(d)를 참조로 아래에서 기술되는 바와 같이 디바이스(120a)로 전달된다(3a).
본 발명에 따른 인증 애플리케이션은 바람직하게는 사용자 디바이스 상에 존재하지만, 반드시 그러한 것은 아니다. 이것은 사용자가 원격 디바이스에 상반되는 자신의 디바이스만 신뢰하면 된다는 것을 의미한다. 서비스에 따라서(예컨대, 웹, 이메일, IM 등), 프록시 내에서 인증을 수행하는 것이 가능하다. 그러나, 이것은 다수의 공격 경로를 개방하며 인증 프로세스의 보안을 지키는 것을 훨씬 더 어렵게 한다. 따라서, 본 명세서에 개시된 바와 같은 인증을 위한 "엔드-투-엔드" 접근법이 바람직하다.
도 3(a)-3(c)는 본 발명의 일 실시예에 따라 정보 수신자에게 전달되는 정보 제공자의 인증 메시지의 예시를 도시한다. 이러한 예시에서, 디스플레이된 정보 제공자 인증 메시지는 식별 정보가 성공적으로 인증되었는지, 정보가 식별 정보(선택적으로는 로고 등)를 나타내는지, 그리고 정보 제공자가 레지스트리(101, 201, 301) 중 어느 레지스트리에 등록되었는지를 정보가 지정하는지 여부를 나타내는 정보를 포함한다.
도 3(a)는 성공적으로 인증된 식별 정보에 대한 예시적인 디스플레이 포맷(130a)을 도시한다. 디스플레이 포맷(130a)의 제 1 라인은 식별 정보가 성공적으로 인증되었음을 나타낸다. 디스플레이 포맷(130)은 디바이스(120)의 비주얼 디스플레이(140) 상에 제공된다. 도시된 바와 같이, 디스플레이 포맷(130a)은 비주얼 디스플레이(140)의 상당한 영역을 포괄한다. 그러나, 다른 실시예에서(도시되지 않음), 디스플레이 포맷(130a)은 비주얼 디스플레이(140)의 제한된 영역을 포괄한다. 디스플레이(130a)의 제 2 라인은 인증된 식별 정보를 디스플레이한다. 디스플레이(130a)의 마지막 라인은 RA의 네임을 디스플레이하며, 이 예시에서는 캘리포니아 주와 관련된 레지스트리를 디스플레이한다.
도 3(b)는 인증이 실패했기 때문에 인증될 수 없는 정보 제공자를 위한 예시적인 디스플레이 포맷(130b)을 도시한다. 당업자에 의해 이해되는 바와 같이, 정보 제공자 인증은 다수의 이유 중 임의의 하나의 이유로 인해 실패할 수 있다. 예를 들어, 정보 제공자는 정보 제공자가 상응하는 사설 키를 갖지 않거나, 인증 증명서가 사용자 디바이스에게 알려져 있지 않은 레지스트리로부터 제공되거나, 인증 증명서가 CA의 공용 키를 사용하여 인가될 수 없거나, 통신 실패가 발생될 수 있거나, 인증 상호작용이 방해될 수 있는 등의 경우에 도용된 인증 증명을 나타낼 수 있다. 디스플레이(130b)의 제 1 라인은 정보 제공자 인증이 실패되었기 때문에 정보 제공자가 성공적으로 인증되지 않았음을 나타낸다. 디스플레이(130b)의 제 2 라인은 만약 이용가능하다면, 인증 증명서 내에 포함된 식별 정보를 디스플레이한다. 디스플레이(130c)의 마지막 라인은 만약 이용가능하다면, 인증 증명서 내에 포함된 레지스트리의 네임을 디스플레이한다. 인증이 실패하였다는 사실을 더 부각시키기 위해, 메시지는 예로서 적색 등과 같은 밝은 색상으로 디스플레이될 수 있다.
도 3(c)는 정보 제공자가 인증 증명서를 나타내지 않기 때문에 인증될 수 없는 정보 제공자에 대한 예시적인 디스플레이 포맷(130c)을 도시한다. 디스플레이(130c)의 제 1 라인은 정보 제공자가 인증을 시도하지 않았음을 나타내며 도시된 바와 같이 라인의 나머지 부분은 공백일 수 있거나 또는 식별 정보를 디스플레이할 수 있으며, 이 경우에 '인증 서비스 없음' 메시지를 부각시키거나 깜빡거리게 함으로써 인증이 시도되지 않았다는 사실이 강조되어야만 한다.
당업자에 의해 이해되는 바와 같이, 디스플레이 포맷(130a-130c)이 항상 실시될 수 없거나 정보 수신자가 원하지 않을 수 있다. 예를 들어, 개인 컴퓨터의 경우에, 시각 디스플레이의 크기는 전형적으로 인증 결과를 시각적으로 프레젠테이션하는 것과 관련된 제한 요인이 아닐 것이다. 그러나, 휴대폰, PDA, 휴대용 컴퓨터 등과 같은 휴대용 시각 디스플레이의 크기는 인증 결과의 시각적 디스플레이에 있어서 제한 요인일 수 있다. 따라서, 인증 프로세스를 나타내는 다른 형태가 이러한 결과를 전달하는 데에 사용될 수 있음이 이해될 것이다. 도 4(a)-4(d)는 이러한 결과를 정보 수신자에게 전달하기 위한, 인증 프로세스를 나타내는 다른 형태를 도시한다. 도 4(a)-4(d)가 특정한 유형의 디바이스(140)(즉, 휴대폰)를 도시하지만, 인증 프로세스 결과를 나타내는 다른 형태가 데이터 통신 디바이스의 가장 잘 알려진 유형으로 전달될 수 있음을 이해해야 한다.
도 4(a)에 도시된 바와 같이, 일 실시예에서, 정보 제공자 인증 또는 인증 실패는 메시지 수신 통지 신호가 디바이스(140a)로부터 출력됨과 동시에 또는 그 후에 출력된 아웃-오브-밴드 메시지를 이용하여 정보 수신자 디바이스를 통해 전달될 수 있다. 일 실시예에서, 시각적 메시지는 디바이스(140a)의 시각적 디스플레이(142a) 상에서 출력된다. 다른 실시예에서, SMS(short message service) 메시지는 인증 프로세스를 수행하는 서버로부터 디바이스(140a)로 전송되고, 그 SMS 메시지는 시각적으로 시각적 디스플레이(142a) 상에 디스플레이된다. 디스플레이된 시각적 메시지는 도 4(a)에 도시된 바와 같이 정보 제공자가 인증되었다(A) 또는 인증되지 않았다(NA)(도시되지 않음)는 표시(150) 및 정보 제공자 ID(예컨대, "캘리포니아의 은행")를 포함한다.
도 4(b)에 도시된 바와 같이, 다른 실시예에서, 정보 수신자가 상응하는 제공된 정보를 액세스할 때, 인-밴드 청각 메시지가 디바이스(140b)의 청각적 출력 수단을 통해 출력될 수 있다. 청각 메시지는 정보 제공자가 성공적으로 인증되었거나 인증되지 않았음을 나타낸다. 청각 메시지는 정보 제공자가 청각 메시지를 위조하지 않도록 정보 수신자가 이러한 액세스를 수행한 이후에, 그러나 제안된 정보가 표시되기 이전에 출력될 수 있다. 이러한 실시예에서, 정보 수신자는 정보 제공자가 인증될 수 있거나 인증될 수 없음을 나타내는 청각 메시지(152)를 수신한다.
도 4(c)에 도시된 바와 같이, 다른 실시예에서, 구별가능한 링 톤(ring tone)이디바이스(140c)의 청각 출력 수단에 의해 출력된다. 하나의 링 톤(154)은 인증된 정보 제공자를 나타내고 다른 링 톤(도시되지 않음)은 식별 정보가 인증되지 않았을 수 있음을 나타낸다.
도 4(d)에 도시된 바와 같이, 또 다른 실시예에서, 이미지(156)(예컨대, jpeg 이미지)는 식별 정보가 인증되었음을 나타내기 위해 디바이스(140d)로 전송된다. 이러한 실시예에서, 이미지(156)는 실패한 인증에 상응하는 사기/부정 행위(예컨대, 피싱)를 도시하는 이미지의 수단을 통해 인증되지 않았을 수도 있음을 나타낸다. 다른 이미지(도시되지 않음)는 식별 정보가 성공적으로 인증된 상황을 나타내는 데에 사용된다.
아래에서는, 특정 유형의 다양한 통신 매체에 적용되는, 본 발명에 따른 인증의 활성화에 대해 기술될 것이다. 이러한 통신 매체의 예는 IM 메시지 및 웹페이지를 포함하지만, 이것으로 한정되지는 않는다. 아래에는 이메일, IM 메시지 및 웹페이지의 측면에서 메시지 인증을 독립적으로 활성화하기 위한 특정한 접근법의 실시예가 기술되었다. 당업자는 사기 및 부정 행위가 통신 매체들의 조합을 통해 종종 침투된다는 것을 이해할 것이다. 예를 들어, 피싱 행위는 종종 위조되거나 전송자 정보를 혼란스럽게 하는 이메일 메시지를 통해 '미끼를 던지고', 웹페이지를 통해 '덫에 걸리게 한다'. 덫에 걸리게 하는 것은 종종 예를 들어 은행 계좌 정보와 같은 기밀 정보를 획득하는 것을 포함하며, 따라서 계좌로부터 권한받지 않은 자금 인출이 이루어지도록 한다. 따라서, 예를 들어 VoIP 상에서의 피싱, 사업 대 사업 인증, 스팸 필터링, 이메일 위조, 웹페이지 위조, 웹페이지 피싱, IM 세션 해킹 등과 같은 사기 및/또는 부정 행위를 타파하기 위해, 본 명세서에는 본 발명에 따라 메시지 인증을 활성화하는 접근법들이 개시되어 있으며, 서로 다른 통신 매체의 측면에서 이들이 독립적으로 또는 조합하여 바람직하게 실시될 수 있다.
이메일 인증
SMTP(Simple Mail Transfer Protocol, RFC 2821)는 현재 이메일 프로토콜을 압도적으로 장악하고 있다. 따라서, 본 명세서에서 이메일 메시지 인증은 SMTP의 측면에서 기술될 것이다. 그러나, 당업자에게 명백한 것처럼, 이메일 메시지 인증을 활성화하도록 특별히 구성된 본 발명의 실시예는 대부분의 이메일 메시징 프로토콜에 따라 구성될 수 있다.
본 발명에 따르면, 이메일 메시지 인증의 활성화는 인증 증명서를 사용하여 이메일에 서명해야만 하는 메시지 전송자(즉, 정보 제공자)를 포함한다. 보다 적절하게는, 메시지 전송자는 인증 증명서 내에 삽입된 공용 키에 해당하는 사설 키를 사용하여 이메일 메시지에 서명한다. 사설 키를 사용하여 서명된 이메일 메시지의 측면에서, 이러한 서명된 이메일 메시지의 수신자는 이메일 메시지 내에 포함된 식별 정보를 인증하기 위해 공용 키를 사용할 수 있다.
SMTP는 SMTP 도전을 사용하여 전송된 메시지 내에 포함된 콘텐츠의 인증을 활성화하는 다수의 고유한 기능성 계획을 갖는다. 이러한 하나의 계획은 이메일이 저장 및 포워드 시스템(store-and-forward system)이 되는 것이다. 이메일 메시지의 전송자와 수신자 사이에는 최고 두 개의 MTA(Mail Transfer Agent)가 존재하며, 이때 각 MTA는 서로 다른 프로그램의 서로 다른 버전을 실행한다. MTA는 기본적으로 센드메일(sendmail) 또는 첨부 애플리케이션을 실행하는 메일 서버이다. 이메일 메시지의 전송자와 수신자 사이에 1/2 다즌 이상의 MTA가 존재하는 것은 드문 일이 아니다. SMTP는 오직 각각의 홉(hop) 상의 MTA의 쌍들 사이의 상호작용을 허용한 다. 전공자와 제공자는 동시에 온라인에 존재할 수 없으며, 이것은 엔드-투-엔드 인증에 대한 선호도가 존재하는 경우 임의의 상호작용을 불가능하게 한다.
예로서 SMTP와 같은 이메일 메시징 프로토콜에 따른 각 이메일은 다수의 "헤더" 라인을 구비한다. STMP, MIME 등에 대한 표준에서 다수의 헤더가 명시되어 있다. 또한 누구나 어떤 이유로도 삽입할 수 있는 확장 헤더가 존재한다. 예를 들어, X-Scanned-By는 부정 소프트웨어 스캐너에 의해 추가되는 인기있는 헤더이고, X-Mailer는 소프트웨어가 전송자 MUA임을 나타내기 위한 다른 헤더이다. 당업자는 이러한 헤더의 존재가 이것을 포함하는 이메일 메시지가 불법적 요소가 없음을 보장하지 않음을 이해할 것이다. 예를 들어, 헤더는 부정적인 목적을 위한 엔티티에 의해 또는 스캐너의 구식 버전을 이용한 엔티티에 의해 추가되었을 수 있다. 우리는 X-RealName-Certificate 및 X-RealName-Checksum과 같은 두 개의 추가 헤더가 각각 인증서 및 서명된 체크섬을 포함할 것을 제안한다. 이들을 단일 헤더로 결합시키는 것도 가능하다.
각 MTA는 새로운 헤더 라인을 삽입하고 일부 헤더 라인들을 재입력하기로 되어있다. 이것은 체크섬이 원래 전송된 이메일보다 상위에 있을 수 없음을 의미한다. 보다 불리하게, 이메일 메시지 바디는 다수의 이유로 인하여 변경될 수도 있다. 이러한 변경의 일 예시는 라인의 시작에서의 "From"이 ">From"으로 변경되는 것이다. 다른 예시는 일부 MTA 및 일부 MUA(예컨대, 본래 Microsoft Outlook™와 같은 사용자 프로그램인 Mail User Agent)가 라인 길이 및 다른 이유로 인하여 부적절하게 메시지를 분리시키는 것이다.
MIME(Multipurpose Internet Mail Extensions)은 무엇보다도 "parallel" 및/또는 "alternative" 뷰를 포함할 수 있는 멀티-파트 메시지를 정의하는, SMTP로의 확장이다. 서로 다른 MUA는 메시지의 일부가 디스플레이되는 서로 다른 규칙들을 갖는다. 일부 스팸 이메일 메시지는 하나의 파트가 ASCⅡ에 있고 하나의 파트는 HTML 내에 있는 복수의 파트를 갖는 바디를 이용하여 계획적으로 전송된다. 그 목적은 ASCⅡ 부분에 기초하는 필터에 대한 스팸 필터 및 HTML 부분을 디스플레이하기 위한 이메일 프로그램(즉, MUA)을 위한 것이다.
따라서, 이메일 메시지 인증을 활성화하기 위해 구성된 본 발명의 실시예는 예를 들어 리플레이 및 중간자 공격(Man-in-the-Middle Attack)과 같은 위조 택틱(tactic)을 방지하는 강건한(robust) 이메일 메시지 인증을 수행하는 동시에 이러한 고유한 기능 계획을 처리해야 한다. 이를 위해, 본 발명의 일 실시예에서, 도 5에 도시된 이메일 메시지 인증 방법(200)은 이메일 인에이블된 정보 제공자 디바이스 및 이메일 인에이블된 정보 수신자 디바이스에 의해 함께 구현된다.
1. 도 5를 참조하면, 체크섬 동작(202)은 멀티-파트 이메일 메시지(즉, 원래의 이메일 메시지)의 각 부분 상에서 수행된다. 체크섬 동작은 이메일 메시지 콘텐츠의 일부 또는 전체에 종속적인 체크섬(즉, 컴퓨팅된 값)을 생성한다. 체크섬 동작은 바람직하게는 예를 들어 SHA-1(Secure Hash Algorithm-1)과 같은 암호적으로 강한 해쉬(hash)를 적용하는 것을 포함한다. 비-텍스트인 메시지의 일부는 자신들의 인코딩된 형태로 이러한 비-텍스트 부분 상에서 수행될 체크섬 동작을 적용하는 적절한 방식으로 인코딩된다.
단일-부분 이메일의 바디와 "텍스트"(HTML 등을 포함)인 부분을 포함하는 원래의 이메일 메시지의 텍스트 부분을 체크섬하기 위해, 바람직하게 수행되는 일부 프로세싱이 존재한다. 이러한 프로세싱은 본 명세서에서 "정규화(normalizaing)"으로 지칭된다. 정규화의 목적은 메일 프로그램에 의해 수행된 모든 변경 하에서 변하지 않지만 뷰된 바와 같은 메시지 내에서 보여지는 모든 텍스트를 소유하는 메시지 바디 부분을 생성하는 것이다. 이러한 메일 프로그램은 이메일 메시지를 생성, 전송 및 수신하는 데에 사용되는 예로서 Microsoft™ Outlook™과 같은 애플리케이션이다. 정규화는 추가적인 프로세싱을 수반하지만, 인증 애플리케이션의 로직을 바람직하게 단순화할 수 있다.
일 실시예에서, 정규화는 바람직하게는 블랭크, 탭, 백스페이스, 라인-엔드 캐릭터와 같은 모든 여백을 제거하는 것을 포함한다. 서로 다른 운영 시스템들은 서로 다른 라인-엔드 컨벤션을 가지며, 따라서 우리는 모든 <cr> 및 <linefeed>를 여백으로 간주한다. 라인의 시작에서의 어떠한 ">" 캐릭터도 제거된다. 다른 접근법은 공백의 각 인접하는 시퀀스를 압축하여 최소의 비용으로 인간 판독가능성을 향상시키는 것이다. 또한, 이메일 메시지 바디가 ASCⅡ 내에 있을 것이 필요하지 않다. 다른 캐릭터 인코딩 내의 이메일(예컨대, EBCDIC) 또는 임의의 2진 파일들이 그들이 ASCⅡ 내에 있는 것처럼 정규화될 수 있다. 이와 달리, 원래의 이메일 메시지(예컨대, 이미지 부분)의 인코딩된 부분은 필요하거나 적절할 때 정규화될 수 있다.
2. 헤더 추출 동작(204)은 원래의 이메일 메시지로부터 특정 헤더 정보를 추 출하도록 수행된다. 추출된 헤더 정보의 예는 "from:" 및 "reply-to:" 어드레스, "message-ID"를 포함하지만 이것으로 한정되지는 않는다. 이메일 메시지가 이러한 추출된 헤더 정보의 모든 카테고리를 갖지 않을 경우에, 단일 블랭크 또는 다른 적절한 표현이 손실된 것을 표시하는 데에 사용될 수 있다. "Date:" 헤더에 명시된 날짜는 추출되어야 하는 특정 헤더 정보의 다른 예이다. 날짜가 임의의 시간 구역 내에 있을 수 있기 때문에, 예를 들어 UCT 또는 로컬 시간과 같은 규정된 시간 구역으로 표준화하는 것이 유용하다.
3. (정규화를 이용하거나 또는 이용하지 않은) 임의의 필요한 체크섬 및 추출이 원래의 이메일 메시지의 다양한 부분들 상에서 수행된 후에, 동작(206)이 수행되어 모든 체크섬들과 헤더들을 단일 구조로 어셈블링한다(즉, 체크섬 수집). 이러한 단일 구조는 본 명세서에서 어셈플링된 체크섬 수집 구조이다. 어셈블링된 체크섬 수집 구조의 일 실시예는, "from: <thefromaddress>, reply-to: <thereplyaddress>, date: <data>, body: <bodychecksum>, part1: <part1checksum>, etc"과 같은 포맷을 갖는 콘텐츠 필드 스트링이다. 일부 부분들이 복수의 네임("Content-Type:" 내의 네임, "Content-Displosition" 내의 네임)을 가지고 다른 부분들은 네임을 갖지 않을 수 있기 때문에, MIME 멀티-파트 핸들링에 있어서, 부분들의 네이밍(naming) 및 순서화는 까다로워질 수 있다. 선택적으로, 메시지-id도 이러한 구조 내에 포함될 수 있다. 이러한 방식으로, 날짜 및 전송자 어드레스와 같이 멀티-파트 이메일 메시지의 일반적으로 볼 수 있는 모든 부분이 체크섬 수집 내에 포함된다(직접적으로 또는 간접적으로 체크섬을 통해). 이것은 시그니처가 다른 바디들에 대해 재사용될 수 없으며, 사실 리플레이 어택(replay attack)을 방지한다는 것을 의미한다.
4. 어셈블링된 체크섬 수집 구조 생성에 응답하여, 동작(208)이 수행되어 어셈블링된 체크섬 수집 구조에 대한 체크섬을 결정하고, 그에 따라 제 2 레벨 체크섬 구조를 생성한다(즉, 체크섬 수집 구조의 체크섬).
5. 제 2 레벨 체크섬 구조를 결정한 후에, 동작(210)이 수행되어 정보 제공자의 인증 증명서에 상응하는 사설 키를 갖는 제 2 레벨 체크섬 구조에 서명하고, 그에 따라 서명된 체크섬을 생성한다. 이러한 제 2 레벨 체크섬 구조는 대역폭을 최소화하기 위한 최적화를 제공한다. 체크섬 수집은 예를 들어 약 수백 바이트일 수 있다. 제 2 레벨 체크섬 구조는 예를 들어 약 20 바이트이다. 제 2 레벨 체크섬 구조를 전송함으로써, 체크섬 수집은 전송될 필요가 없으며, 그에 따라 대역폭 사용을 감소시킨다. RSA 공용 키 시그니처는 상대적으로 느리게 시작하며, 메시지가 길어질수록 시그니처는 더욱 느려진다. 체크섬 수집은 체크섬을 컴퓨팅하여 체크섬에만 서명하기 위해 더욱 빨라지기에 충분히 길다.
6. 서명된 제 2 레벨 체크섬 구조를 생성한 후에, 동작(212)이 수행되어 서명된 제 2 레벨 체크섬 구조 및 상응하는 인증 증명서를 원래의 이메일 메시지의 새로운 헤더로 삽입하며, 그에 따라 서명된 이메일 메시지를 생성한다(즉, 본 발명에 따라 인증 증명서에 의해 서명된 메시지). 원래의 이메일은 변경되지 않으며, 서명된 체크섬과 인증 증명서는 인증을 위해 추가의 헤더 라인으로서 삽입된다. 만약 수신자가 인증을 신경쓰지 않으면, 수신자 디바이스는 단지 추가의 헤더를 무시 한다.
7. 동작(214)은 정보 수신자 디바이스에 의한 수신을 위해 정보 제공자 디바이스로부터 서명된 이메일 메시지를 전송하도록 수행되고, 그에 상응하여 동작(216)은 서명된 이메일 메시지를 수신하기 위해 정보 수신자 디바이스에 의해 수행된다.
8. 수신자가 서명된 이메일 메시지를 수신하는 수신자 엔드에서, 동작(218)이 인증 증명서와 서명된 제 2 레벨 체크섬 구조에 액세스하도록(즉, 추출) 수행된다.
9. 인증 증명서에 액세스하는 것에 응답하여, 동작(220)은 인증 증명서의 유효성을 입증하도록 수행된다. 바람직하게는, 이러한 유효성은 X.509 PKI에 따라 검사된다. 보다 구체적으로, 이러한 입증은 수신자가 레지스트리의 루트 인증서를 갖는지를 컨펌하는 것과, 인증 증명서가 레지스트리에 의해 적절하게 서명되었음을 컨펌하는 것과, 인증서가 만료되지 않았음을 보장하도록 유효 기간을 검사하는 것과, 인증서가 취소되지 않았음을 보장하기 위한 취소 리스트를 검사하는 것을 포함한다.
10. 인증서가 입증된 후, 동작(221)은 서명된 제 2 레벨 체크섬 구조가 인증 증명서에 상응하는 사설 키에 의해 올바르게 서명되었음을 입증하도록 수행된다.
11. 제 2 레벨 체크섬 구조의 서명과 인증 증명서의 유효성을 성공적으로 입증하는 것과 관련하여(예로서, 그에 응답하여), 동작(222)은 이메일 메시지로부터 어셈블링된 체크섬 수집 구조를 재생성하도록 수행된다.
12. 어셈블링된 체크섬 수집 구조를 재생성한 후에, 동작(224)은 재생성된 어셈블링된 체크섬 수집 구조로부터 제 2 레벨 체크섬 구조를 결정하도록 수행된다. 이것은 동작(202-208)과 동일한 기능성을 수행하는 것을 수반한다.
13. 그 다음 동작(226)이 재생성된 어셈블링된 체크섬 수집 구조를 위해 체크섬에 대한 헤더로부터 검색된 체크섬을 비교하도록 수행된다. 만약 재생성된 체크섬 수집 구조에 대한 체크섬이 검색된 체크섬(즉, 서명된 체크섬)과 일치하면, 인증된 것으로 간주된다. 시그니처가 인증 증명서에 대해 입증되었고 수신자에 의해 검사되었기 때문에, 중간자 공격의 우려를 없애거나, 크게 감소시킬 수 있다.
14. 어셈블링된 체크섬 수집 구조의 시그니처를 입증하는 것에 응답하여(예로서, 인증 증명서 내에 포함된 식별 정보를 통해), 동작(228)은 시그니처가 성공적으로 입증되었는지 아닌지의 여부를 나타내는 인증 통보를 제공하도록 수행된다.
표면 상으로, 이러한 이메일 메시지 인증 방법은 어느 정도는 복잡한 것으로 보일 수 있다. 그러나, 이것은 전형적으로 메일을 전송 및 수신할 때 MUA/MTA에 의해 수행되는 이메일 바디의 복제와 동시에 복수의 체크섬 동작을 실행함으로써 최소의 프로세싱 시간으로 달성될 수 있다. 또한, 현대의 이메일 서버는 전형적으로 바이러스 스캐닝을 수행하며, 비교시에, 이러한 이메일 메시지는 인증 방법은 상대적으로 단순하다.
요약하면, 본 발명에 따른 이메일 메시지 인증은 전송자 기능, MTA 기능 및수신자 기능을 포함한다. 전송자 기능은 원래의 이메일 메시지의 내용에 대한 체크섬을 계산하는 것, 체크섬 수집 구조를 생성하기 위해 단일 구조로 이메일 메시지 콘텐츠 및 체크섬을 어셈블링하는 것, 어셈블링된 수집 구조에 대한 체크섬을 계산하는 것(즉, 제 2 레벨 체크섬 구조), 인증 증명서에 해당하는 사설 키를 이용하여 제 2 레벨 체크섬에 서명하는 것, 서명된 제 2 레벨 체크섬 구조를 각각의 헤더로 주입하는 것(예로서, x-RealName-checksum) 및 인증 증명서를 각각의 헤더로 주입하는 것(예로서, x-RealName-certificate)을 포함한다. MTA 기능은 대부분의 MTA 소프트웨어에 대한 디폴트 기능인 헤더를 홀로 남겨둘 것을 필요로 하는 각 MTA을 포함한다. 수신자 기능은, 각 헤더로부터 인증 증명서 및 서명된 제 2 레벨 체크섬 구조를 추출하는 것과, 서명된 제 2 레벨 체크섬이 올바르게 서명되었음을 검사하도록 인증서 내의 공용 키를 사용하여 인증서가 유효하다는 것(즉, CA에 의해 올바르게 서명되었으며, 만료되거나 취소되지 않았다는 것)을 검사하는 것과, 체크섬 수집 구조에 대한 체크섬의 고유의 버전을 계산하는 것과, 체크섬의 두 가지 버전을 비교하는 것을 포함한다. 서명된 제 2 레벨 체크섬 구조는 수용가능한 플레인 텍스트 내에서 나타나고, 이는 암호적으로 강한 해쉬 함수(예컨대, SHA-1)가 주어진 체크섬 수집 구조로 해쉬할 다른 스트링을 찾을 실행가능한 방법이 없음을 의미하기 때문이다. 이러한 인증 방법은 MTA 소프트웨어 변경이 없는 장점을 가지며(즉, 디플로이가 쉬움), 엔드-투-엔드 디플로이먼트는 엄격한 표준을 따르지 않는 MTA/MUA를 이용하여 보안 및 작업을 위한 등록에만 의존한다.
다른 일 구현에서, 체크섬의 레벨은 전송되는 더 큰(bulkier) 헤더 라인에서 절약된다. 대안은 제 2 레벨 체크섬 구조에 서명하는 것과 반대로 체크섬 수집 구조(예를 들어, 인증 증명서에 상응하는 사설 키를 사용)에 직접 서명하는 것이다. 이러한 다른 실시예에서, 정보 수신자 디바이스는 자신의 체크섬을 컨펌하는 것과 상반되게 체크섬 수집 구조를 복호화할 것이다(예를 들어, 인증 증명서 내의 공용 키를 사용). 따라서, 본 명세서에는 인코딩된 체크섬 수집 구조의 실시예가 인증 증명서에 상응하는 사설 키에 의해 서명된 어셈블링된 체크섬 수집 구조 및 암호화된 어셈블링된 체크섬 수집 구조를 포함하지만, 이것으로 제한되는 것은 아니다.
다른 대안적인 구현에서, 제 2 레벨 체크섬 구조의 서명은 생략되며 어셈블링된 체크섬 수집 구조가 서명된다.
다른 대안적인 구현에서, 인증 증명서는 이메일 헤더 내에 직접 제공되지 않지만 간접적으로 액세스된다. 인증 증명서가 보다 크고 각 전송자/수신자 디바이스 쌍이 시간에 따라 복수의 이메일을 전송하고자 할 수 있기 때문에, 필요한 유효화를 방지할 뿐 아니라 동일한 부피가 큰 인증서를 다수 전송하는 것을 방지하는 것이 바람직하다. 이것은 완전한 인증서 대신 포인터를 인증서(예로서, URL)로써 수행될 수 있다. 수신자 디바이스는 이후에 사용하기 위해 지정된 인증 증명서와 캐시를 페치할 수 있다. 따라서, 인증 증명서와 인증 증명서가 특정한 소스로부터 액세스될 것을 허용하는 포인터와 같은 수단은 모두 본 발명에 따른 인증 증명서 정보의 예시이다. 이러한 필수 인증 증명서를 지정하기 위한 "간접적인" 방법은 본 발명에 따른 웹페이지 인증에 유용함이 이해되어야 한다.
또 다른 대안적인 구현에서, 체크섬 구조(제 2 레벨 체크섬 구조 또는 어셈블링된 체크섬 수집 구조)는 서명되지 않고 암호화된다. 이러한 구현에서, 암호화된 체크섬은 헤더로 삽입되며 수신자는 시그니처를 검사하는 것과는 반대로 암호화 된 체크섬을 복호화해야만 한다. 서명 동작 후에도 볼 수 있도록 남아있는 메시지의 플레인 텍스트와는 상반되게, 메시지의 플레인 텍스트는 암호화 동작 후에도 판독가능하지 않다. 본 명세서에는 서명 및 암호화가 엔티티가 인증서에 상응하는 사설 키를 구비함을 증명하고, 그에 따라 그들의 아이덴티티를 증명하기 위한 인코딩 예이다. 시그니처 및 복호화의 유효성 입증은 이러한 인코딩된 정보를 해독하는 예이며, 권한이 주어진 파티에 의해 수행될 때, 인코딩된 정보의 안전한 통신을 제공한다. 따라서, 본 명세서에는 시그니처를 서명 및 입증하기 위해 수행된 본 명세서의 동작 및 관련된 기능이 각각 동작 및 암호화를 위한 관련된 기능으로 대체될 수 있음을 개시한다.
체크섬의 암호화 및 복호화를 더 참조하면, 오직 서명 동작 또는 암호화 동작만이 제 2 레벨 체크섬 서명에서 수행될 필요가 있다. 어떠한 동작도 전송자가 체크섬을 포함하는 이메일 메시지를 전송하였음을 증명할 것이다. 기본적으로, 제 1 동작은 체크섬을 컴퓨팅하기 위해 정보 제공자 디바이스에 대해 수행된다. 체크섬은 체크섬 수집 또는 제 2 레벨 체크섬 시그니처일 수 있다. 본 명세서에서 기술된 바와 같이, 요구되는 대역폭뿐 아니라 제 2 레벨 체크섬 시그니처의 구현은 CPU 사이클을 절약한다. 어셈블링된 체크섬 수집 구조 또는 제 2 레벨 체크섬 구조의 인코딩은 메시지를 식별할 것이다. 그러나, 동작은 메시지가 지정된 정보 제공자로부터 온 것임을 증명하기 위해 수행되어야만 한다. 따라서, 제 2 동작은 체크섬을 서명 또는 암호화함으로써 이러한 증명을 제공하기 위해 수행된다. 만약 이 증명이 서명되면, 각각의 암호문(cyphertext)이 정보 수신자 디바이스로 전송된다. 서명된 또는 암호화된 체크섬에 대해서, 정보 수신자 디바이스는 이것이 어셈블링된 체크섬 수집 또는 제 2 레벨 체크섬 수집이든 체크섬을 재생성하는 동일한 동작을 거친다. 만약 공급된 증명이 암호문이면, 정보 수신자 디바이스는 체크섬을 복호화하고 이것을 재생성된 체크섬에 대해 비교한다. 만약 공급된 증명이 시그니처이면, 정보 수신자 디바이스는 시그니처를 검사한다. 각 전송자는 독립적으로 제 1 및 제 2 동작의 네 가지 가능한 조합 중 어떤 것도 선택할 수 있다.
웹페이지 인증
웹페이지 인증을 위해, 다양한 측면의 HTTP/HTML이 본 발명에 따른 메시지 인증을 효과적으로 구현하도록 다루어져야 한다. 다루어져야만 하는 일 측면은 웹페이지가 단일 HTML 파일만이 아니라는 것이다. 대부분의 웹페이지는 예를 들어 서로 다른 URL을 가지는 이미지, 프레임(각각이 HTML 파일에 의해 특정됨), 자바스크립트와 같은 다수의 서로 다른 조각들로 이루어진다.
다루어져야 하는 다른 측면은 X.509 인증서가 프로세싱 리소스 견지로부터 매우 비용이 높은 동작이라는 것이다. 다수의 웹서버는 전용 하드웨어에 대해 동작을 이미 오프-로딩하며 임의의 추가된 워크로드는 바람직하게는 최소화된다. 다루어져야 할 다른 측면은 단일 웹페이지의 조각들이 종종 서로 다른 서버들로부터 온다는 것이다. 예를 들어, 다수의 웹사이트는 제 3자 웹사이트 엔티티(예로서, 광고 제공자)에 의해 제공 및 제어되는 콘텐츠 구성요소를 갖는다. 다루어져야 할 다른 측면은 다수의 웹서버가 복수의 도메인을 조작한다는 것이다. 예를 들어, 주어진 엔티티의 복수의 도메인들(예로서, www.x-company.com, www.x-company.org, www.x-company.tv 등)이 단일 서버로부터 서빙되는 것은 흔한 일이다. 이론적으로, 서버셋업은 복수의 도메인들을 분리해야만 한다. 그러나, 이들 도메인 모두의 서버 서빙은 종종 그들 모두를 동일한 어드레스로서 처리한다(예로서, www.x-company.com). 효율적인 인증 기능을 제공하여 해결되어야만 하는 이것의 뚜렷한 부장용은, 다수의 웹사이트가 잘못된 SSL 인증서를 사용하여 엔드업(end up)한다는 것이며, 이는 각 SSL 인증서가 상응하는 도메인을 지정하기 때문이다. 다루어져야 하는 다른 측면은 신뢰성을 위해서 대부분의 주요 웹사이트들이 로드 밸런싱 및 리플리케이션(replication)의 일부 종류를 필요로 한다는 것이다. 이것은 복수의 장치(즉, 서로 다른 OS 및 웹서버 버전)가 동일한 URL에 응답할 수 있음을 의미한다. 극단적인 경우에, 단일 페이지의 서로 다른 조각들 또는 단일 도메인 내의 조각들조차도 로드 밸런스 세트 내의 서로 다른 서버들로부터 올 수 있으며, 이는 인증 실행을 복잡하게 할 수 있다. 다루어져야 하는 다른 측면은 다수의 웹페이지가 안정적이지 않지만 동적으로 생성된다는 것이다. 이러한 동적 페이지는 종종 복잡한 시스템에 의해 생성되며, 웹페이지가 특별한 태그 등을 갖도록 수정되는 것은 바람직하지 않을 것이다. 다루어져야 하는 또 다른 측면은, SSL이 HTTP 하에서 동작하고 보다 높은 레벨의 프로토콜에 대한 지식이 없기 때문에, SSL 서버가 특정한 IP/포트 조합에 대한 하나의 인증 증명만을 나타낼 수 있다는 것이다. 이것은 대부분의 경우에 현재 HTTP를 갖는 네임 기반의 가상 호스팅을 사용하는 것이 실행가능하지 않음을 의미한다.
본 발명의 일 실시예에서, 이러한 고유한 기능 계획은 SSL/TLS를 무시하고 HTTP 레벨에서 동작함으로써 다루어진다. 바람직하게는, 이러한 접근법은 HTTP가 기밀 정보를 위해 SSL/TLS를 사용하는 것을 허용한다. 이러한 측면에서, 본 발명의 기반 기능은 현존하는 보안 규정에 부정적으로 영향을 미치지 않는다. 웹페이지는 브라우저에 의해 검사되는 인증 증명서를 참조할 것이며 브라우저의 개별적인 위조불가능한 영역 내에 디스플레이된다. 이를 위해, 본 발명의 일 실시예에서, 정보 수신자 사용자 디바이스의 브라우저는 도 6에 도시된 웹페이지 인증 방법(300)을 수행한다.
URL을 리콜하는 것은 흔히 URI에 대한 동의어로서 사용되며, 정확한 차이는 여기에서 고려되지 않는다. 사용자이름, 암호, 포트 넘버와 같은 다수의 복잡성을 무시한 단순한 URI는 "http://www.xxx.com/demo/page.html/"과 같으며 이는 다음의 세가지 부분으로 이루어진다:
1.이 경우에서는 "HTTP"인 프로토콜. FTP, 텔넷 및 HTTP와 HTTPS를 포함하는 몇몇 다즌의 프로토콜들이 지원된다. 이것의 조작은 브라우저에게 남겨두며, 우리는 단지 브라우저가 특정된 리소스를 검색하는 방법을 인지하기만을 기대한다.
2. 이 경우에서는 "www.xxx.com"인, 웹서버의 DNS 네임인 호스트.
3. 원하는 리소스를 특정하며, 이 경우에서는 "demo/page.html"인 경로. 리소스는 HTML 파일, gif 그래픽 이미지, 또는 그외의 것일 수 있다. 리소스는 정적으로 또는 동적으로 생성될 수 있다. 이러한 반환된 리소스는 HTML 파일 등으로서 참조한다.
HTTP를 리콜하는 것은 웹서버와 통신하기 위해 브라우저에 의해 사용되는 가장 인기있는 프로토콜이다. 브라우저는 서버와의 상호작용을 위해 URL 및 "방법"을 나타낼 것이고, 우리는 "GET" 및 "POST"라는 두 방법을 참조할 것이다. GET과 POST 모두 URL에 상응하는 "리소스"를 검색할 것이며, GET과 POST의 차이점은 여기에서 언급하지 않는다. GET과 POST 모두 검색된 리소스의 유형을 반환하며, 예를 들어 HTML 파일은 유형 "text/html"이고, gif 인코딩된 그래픽 이미지는 유형 "image/gif"이다. (이러한 HTTP 유형은 파일네임 또는 URL의 첨자에 의해 표시되는 파일유형에 대해 독립적이며, 타입의 복수의 표시를 일치시키는 것은 본 발명의 범주를 벗어난다) 본 발명은 주로 HTML 파일, RealName 인증서 및 체크섬과 같은 서로 다른 세 유형의 리소스와 관련된다.
또한 HTML을 리콜하는 것은 SGML로부터 이어지는 "마크업 언어"이다. 이것은 소정의 텍스트를 글머리, 문단, 리스트 등으로 표기함으로써 문서 내의 텍스트 기반의 정보의 구조를 기술하고, 이러한 텍스트를 상호작용 형태, 삽입된 이미지 등 다른 객체로 보충하기 위한 수단을 제공한다. HTML은 <와 >에 둘러싸인 라벨(태그로서 알려짐)의 형태로 기록된다. 예를 들어, "<title" Introduction </title>"은 <title> 태그의 예이고, 텍스트 "Introduction"을 페이지의 제목으로서 마크한다. 클로징 태그 "</title>"은 오프닝 태그에 슬래쉬가 추가된 것이다. HTML 파일은 페이지의 구조를 기술하는 네스트된(nested) 태그의 세트일 뿐이다. 우리는 웹페이지를 식별하는 데에 사용될 엑스트라 태그 <RealNameSerialNumber>를 추가할 것을 제안한다(동일한 URL이 동적으로 서로 다른 페이지를 생성할 수 있기 때문). 브라우 저가 그들에게 알려지지 않은 태그를 무시하기 때문에 HTML 표준을 변경하는 것이 바람직하나 그럴 필요는 없으며, 이것은 웹 브라우저가 항상 HTML 파일 내에 <RealNameSerialNumber> 태그를 포함하는 것이 해롭지 않음을 의미하고, RealName 가능 브라우저는 인증할 것이고 불가능 브라우저는 단지 그것을 무시할 것이다. 또한, HTML을 참조할 때, 우리는 XHTML과, 추가의 정보 태그를 지원할 수 있는 마크업 언어와 같은 다른 XML/SGML을 포함한다.
1. 웹페이지의 시작에서, 동작(302)은 HTTP GET/PUT을 사용하여 웹서버로부터 파일을 페칭하도록 수행된다. URL 및 파일은 본 명세서에서 "Top URL" 및 "Top file"로 각각 지칭된다. 우리는 대부분 탑 파일이 HTML 파일인 경우에 흥미가 있으며, 우리는 이것을 "Top HTML file"에서 지칭한다. (여기에서 "top"은 이러한 HTML 파일이 다수의 다른 HTML 파일이 이 페이지의 일부로서 페치되도록 함으로써 웹페이지의 설계를 제어한다는 사실을 일컫는다) RealName을 지원하는 웹서버는 각 Top HTML 파일이 시리얼 넘버 및 인증서 URL(이들 두 아이템들은 단일 태크 또는 복수의 태그 내에 있을 수 있다)을 지정하는 태그를 포함하도록 할 것이다. 시리얼 넘버는 이러한 페이지의 특정 예를 식별하는 데에 사용되며 연속적으로 증가하는 수로 제한되지 않고, URL의 형태가 되기 위한 대부분의 편리한 형태는 시리얼 넘버이다. 이러한 시리얼 넘버 구성은 탑 레벨 HTML에 대해서만 수행된다. 보다 낮은 레벨의 HTML에 대한 인증을 허용하는 것은 크로스-사이트 스크립팅 공격의 변화를 위한 기회를 제공하고 CPU 및 대역폭의 비용을 높인다.
2. Top HTML 파일을 페치에 응답하여, 동작(304)이 수행되어 HTTP 또는 URL 내에서 특정된 임의의 메커니즘을 사용하여 지정된 인증 증명서를 페치한다. 본 명세서에는 인증 증명서를 검색한 후에 인증 증명서를 캐시하는 동작이 개시되었으며, 그에 따라 원격 리소스로부터 인증 증명서를 후속하여 검색할 필요를 제거한다.
3. 인증 증명서를 페치한 후, 동작(306)이 수행되어 해당 레지스트리의 레지던트(즉, 사전-저장) 루트 인증서를 사용하여 인증 증명서를 유효화한다.
4. 인증 증명서의 성공적인 유효화에 응답하여, 동작(308)이 수행되어 Top HTML 파일에 대한 체크섬을 검색한다. 이것은 시리얼 넘버를 웹서버로 전송하고(바람직한 형태에서, 시리얼 넘버는 이미 체크섬을 검색하는 데에 사용될 수 있는 URL임), 웹서버로부터 상응하는 사설 키-인코딩된 체크섬을 검색하고(예를 들어, 사설 키-서명, 사설 키 암호화 등), 인증 증명서 내의 공용 키를 사용하여 체크섬을 해독(예를 들어, 공용 키-입증, 공용 키 복호화 등)함으로써 수행된다. 체크섬을 인코딩하는 데에 사용된 사설 키를 제공하는 것은 인증 증명서 내의 공용 키를 매칭하고, 웹서버로부터 사설 키-인코딩된 체크섬은 올바르게 해독된다. 만약 서로 다른 사설 키가 사용되면, 해독이 실패하거나 또는 해독된 체크섬이 잘못될 것이며, 그에 따라 인증이 실패할 것이다.
5. 성공적인 웹서버로부터의 체크섬 복호화에 응답하여, 동작(310)이 수행되어 Top HTML 파일의 체크섬을 컴퓨팅하고 체크섬을 웹서버로부터 복호화된 것에 비교함으로써 Top HTML 파일이 실제로 웹서버로부터 왔음을 입증한다. 만약 체크섬이 동일하다면, 웹페이지에 대한 식별 정보는 성공적으로 입증된다. 만약 그렇지 않으 면, 인증은 실패한다.
6. 웹페이지가 인증된 것으로 결정되었는지 아닌지의 판단에 응답하여, 동작(312)이 수행되어 웹페이지(즉, 그의 식별 정보)가 인증되었는지 여부를 나타내는 통지 정보를 표시한다. 일 실시예에서, 이러한 통지 정보는 웹페이지 콘텐츠가 아닌 브라우저 윈도우의 개별적인 영역 내에 표시된다. 또한, 일 실시예에서, 인증 증명서는 개별적인 영역의 디스플레이를 제어하기 위해 HTML 파일을 포함할 수 있다.
이러한 웹페이지 인증 방법의 장점은 탑 HTML 파일만이 변화될 필요가 있다는 점이다. 탑 HTML 파일만이 각각의 인증 증명서를 가질 필요가 충분한 "중요한" 것으로 간주되는 유일한 웹페이지로 가정하는 것이, 예를 들어 대역폭, 사이클 등과 같은 가치있는 네트워크 리소스를 잠정적으로 절약할 수 있다. 탑 HTML 파일이 어느 다른 조각들이 웹페이지 내에 포함되었는지를 제어하기 때문에 합당한 가정이다. 탑 HTML 파일을 인증함으로써, 명백하게 후속하는 조각들이 의도된 바와 같이 페치될 것이며, 위조가 합법적인 웹서버를 파괴할 것이 요구된다는 것이 확인된다. 이것은 본 발명의 범주를 넘는 서로 다른 보안 문제이다. 또한, 이러한 방법의 구현은 바람직하게 HTTP 버전 1.1을 필요로 하지 않는다. 일부 예에서, Top URL은 리디렉트 또는 기한만료를 포함하는 Top HTML을 반환할 수 있으며, 이러한 경우 브라우저는 두 페이지를 모두 인증할 것이 필요하다. 리디렉트는 긴 시간을 소비하거나 또는 발생하지 않을 수도 있다. 그러나, 반면에 리디렉트 페이지는 일부 디스플레이가능한 정보 및 클릭가능한 링크를 포함할 수도 있다. 탑 HTML 파일의 인증 결과 는 예로서 단일 이미지로 이루어진 페이지와 같은 다수의 페이지들이 인증하지 않을 것임을 나타내며, 이것은 HTML이 사용자에게 정보를 다시 서버로 전송할 것을 요구하기 때문에 심각한 문제가 아니다(임의의 피싱 시도가 HTML을 사용해야 함을 의미함).
시리얼 넘버 및 암호화된 체크섬의 사용 절차는 성가신 것으로 보여질 수 있다. 그러나, 이것은 서버가 Top HTML 파일이 실제로 의도된 웹서버로부터 온 것인지를 컨펌하는 데에 필요하다. 이메일 메시지 인증 방법과 유사한 방식으로 Top HTML 파일로 체크섬을 삽입하는 것이 바람직할 수 있다. 그러나, Top HTML 파일로 체크섬을 삽입하는 바로 그 동작이 체크섬을 변경시킬 수 있다. 삽입된 체크섬이 체크섬 계산에서 제외되어야만 한다는 것이 특정된다 할지라도, 그것의 존재는 체크섬 계산 문제에서 발생할 것이다. 이것은 동적 페이지에 있어서, 웹서버가 전체 파일이 생성되어 전송될 때까지 체크섬 컴퓨팅을 완료할 수 없기 때문이다. 선택적으로, 체크섬을 전체 Top HTML 파일이 </body> 태그 또는 </html> 태그의 일부로 하여 전송된 후에 암호화된 체크섬이 전송된다는 것이 명시될 수 있지만, 이것은 <html>과 </html> 쌍의 밖의 태그를 허용하거나, 또는 체크섬을 컴퓨팅할 때 완료된 편집을 수행하도록 HTML의 정의를 변경시킬 것을 필요로 한다.
시리얼 넘버를 통한 체크섬으로의 액세스를 허용함으로써, 본 발명에 따른 웹페이지 인증은 추가 방식으로 구현될 수 있다. 예를 들어, 이러한 추가 기능은 <RealNameSerialNumber> 태그를 갖는 HTML 파일을 검색하는 HTTP 응답을 찾는다. 이것이 발견될 때마다, 체크섬이 컴퓨팅되어 정보 수신자 디바이스가 후에 질문할 수 있도록 데이터베이스 내에 저장된다. 또한, 상대적으로 추가 기능을 웹사이트/브라우저 소프트웨어로 집적시키는 것이 쉽다.
다른 실시예에서, 체크섬은 HTML 파일의 일부와는 상반되게 HTTP 프로토콜의 일부로서 전송된다. 작업가능한 반면, 이것은 HTML 파일과 프로토콜의 콘텐츠 사이의 연결을 나타낸다. 또한, 서명 동작은 HTTP 요청의 완료에 대한 병목이다. 또한, 이러한 솔루션은 다수의 소프트웨어 개선이 수용가능한 결과를 획득하도록 이루어져야 하기 때문에 사용하기 어렵다. 다른 실시예에서, 체크섬은 HTML 파일의 마지막 일부로서 포함된다. 이것은 예를 들어 </html> 클로징 태그 후에 오는 새로운 HTML 태그 <RealNameChecksum>을 정의함으로써 구현될 수 있고, 체크섬이 <RealNameChecksum>을 제외하고 컴퓨팅되어야 함을 명시한다. 즉, HTML 파일을 획득하고, <RealNameChecksum> 태그를 편집하며, 체크섬을 컴퓨팅한다. 이러한 솔루션은 작업가능하지만, HTML 파일과 프로토콜의 콘텐츠 사이의 연결에 관련하여 전술된 상황을 발생시키며, 서명 동작은 병목이 되고, 실제 사용은 소프트웨어 개선에 의존하게 된다.
이와 달리, 본 발명에 따른 다른 웹페이지 인증 방법은 URL 및 HTML에 독립적인 인증 증명서의 조작을 포함한다. 바람직하게, 이러한 방법은 어떠한 웹페이지(정적 또는 동적)도 필요로 하지 않으며 단일 이미지로 이루어진 페이지를 포함하여 모든 페이지를 인증할 수 있다. 따라서, 대안으로서 바람직하다. 인증서 조작은 사전규정된 특정한 URL에 대한 정상 요청으로서 수행될 수 있다. 구체적으로 HTTP 1.1 접속은 보통 수행되는 것과 같이 (표준 SSL과 또는 이것 없이) 셋업되고, 브라우저는 표준 사전규정된 URL을 사용하여 인증 증명서를 페치하며, 증명서가 검사되고, 사설 키의 프로세션이 검사된다. 이것은 웹서버가 인증서의 소유자로서 정당하게 역할을 하고 있음을 컨펌한다. 당업자는 단일 코포레이트 엔티티에 대한 복수의 도메인 네임을 호스팅하는 웹서버가 부분적으로는 이러한 방법의 쉬운 구현을 인식함을 이해할 것이다.
본 명세서에는 전술된 웹페이지 인증 방법이 바람직하게는 결합될 수 있음이 기술되었다. 이러한 실시예에서, 제 1 기술된 방법이 적용될 수 있다. 만약 탑 HTML이 인증 증명서로 포인팅하는 태그를 포함하지 않으면, 제 2 기술된 솔루션이 적용될 수 있다. 선택적으로, 이러한 두 솔루션은 반대 순서로 적용될 수 있다. 만약 둘 중 하나의 방법이 인증된 식별 정보를 생성하면, 해당 효과에 대한 표시가 나타난다. 만약 둘 중 하나의 방법이 유효하지 않은 인증서 또는 불량한 사설 키 컨펌을 생성하면, 가능한 위조 시도의 표시가 표현되어야 한다. 만약 두 방법 모두 어떠한 메시지 인증도 생성하지 않으면(성공 또는 그외), 이러한 인증이 컨펌되지 않았다는 표시가 표현되어야만 한다.
"특별한 URL"은 웹서버가 인증을 위해 지원하는 표준화된 URL이다. 예를 들어, 이것은 탑-레벨 URL이 도메인(즉, "http://www.entity-name.com"으로 시작하는 URL) 내에 있을 때, 상응하는 RealName 인증서를 검색하기 위해(즉, 인증) 브라우저가 웹서버에게 ""http://www.entity-name.com/RealName"를 문의하도록 "http://www.entity-name.com/$$RealName$$"일 수 있다. 달러 표시는 다수의 웹 마스터들이 이러한 URL이 "일반적인 데이터 페이지가 아님"을 표시하는 데에 사용하 는 통상적인 것이며, 신중하게 변경되어야 한다. 이러한 접근법은 이들이 '404-페이지를 발견할 수 없음'과 같은 오류 메시지를 반환하는 반면 본 발명에 따라 인증 가능한 웹서버가 인증서를 반환할 것이라는 점에서 본 발명에 따라 구성된 인증 증명서로 구성되지 않은 서버와 작업함을 인지해야 한다.
IM 메시지 인증
인스턴트 메시징 인증에 있어서, 문제는 다시 달라진다. 그러나, 이들은 대부분 전술된 이메일 메시지 인증과 관련된 고유의 기능 계획의 서브세트이다. 이러한 하나의 계획은 대부분의 IM 시스템이 클라이언트들 사이에 "중간자(mediate)"인 중심 서버를 갖는다는 것이다. 따라서, 클라이언트들은 다른 클라이언트와 직접 통신하지 않는다. 이것은 본질적으로 이메일의 멀티-홉과 동일한 상황이다. 다른 계획은 전형적으로 각 벤더에 대해 하나씩인 서로 다른 복수의 IM 프로토콜이 존재한다는 것이며, 각 IM 프로토콜에 대해 다수의 서로 다른 사용자 에이전트가 존재한다는 것이다. 또 다른 계획은 클라이언트 쌍이 전형적으로 서로 모르는 이들이 서로 이메일할 수 있는 것과는 상반되게 스크린 네임 교환 프로토콜을 통해 자신의 권한된 콘택트 리스트로 서로를 추가해야만 한다는 것이다.
따라서, IM 메시지 인증을 활성화하도록 구성되는 본 발명의 실시예는 이러한 고유의 기능 계획을 해소해야하며, 전술된 이메일 메시지 인증 방법과 유사한 사상에서 구성된다. 이를 위해, 본 발명의 일 실시예에서, 도 7에 도시된 아래의 IM 메시지 인증 방법(400)이 IM 인에이블된 수신자 디바이스에 의해 구현된다. 당 업자는 구현의 세부사항이 필요에 따라 특정한 기본 IM 프로토콜에 의존할 수 있음을 이해할 것이다.
1. 동작(402)은 per-IM 대화 세션 또는 오직 IM 스크린 네임을 콘택트 리스트에 추가할 때 IM 클라이언트들 사이에서 인증 증명서를 교환하도록 수행된다. per-IM 대화 세션에서의 인증 증명서 교환은 IM 클라이언트가 서로 다른 챗(chat) 세션에 대해 서로 다른 인증된 스크린 네임을 사용하도록 한다는 장점을 갖는다. IM 스크린 네임을 콘택트 리스트로 추가할 때의 인증 증명서 교환은 IM 메시지 내의 인증 증명서의 전송을 절약하며, 이것은 인증 증명서가 상대적으로 부피가 크기 때문에 유리하며, IM 스크린 네임이 추가될 때 그것의 인증을 허용한다.
2. 인증 증명서의 교환 후에, 동작(404)이 수행되어 IM 스크린 네임을 검사한다. 이것은 IM 스크린 네임을 각 인증 증명서 내에 삽입된 네임에 대해 검사함으로써 수행될 수 있다. 이러한 접근은 스크린 네임이 증명서를 발행하는 시간에 고정된다는 것을 의미한다. 이와 달리, 스크린 네임은 증명서 내에 삽입되지 않고 검사가 스크린 네임에 서명함으로써 수행될 수 있으며, 이것은 복수의 스크린 네임들이 사용될 수 있다는 장점을 갖는다(증명서가 "Tech Support" 디파트먼트에 대한 것이고 각 기술자는 개별적인 스크린 네임을 가질 수 있다). 만약 인증 절차가 실패하면, 하나 이상의 상응하는 통지 액션이 발생할 수 있다. 이러한 통지 액션의 예는 부정될 수 있는 스크린 네임을 추가하는 것을 포함하지만 이것으로 제한되지는 않으며, 스크린 네임을 추가하기 위한 컨펌을 요청하는 사용자 대화 윈도우가 표시될 수 있고, 스크린 네임은 IM 콘택트 리스트 등의 특정 "비권한된" 그룹 내에 서 비인증 및 재디렉팅된 것으로서 플래그될 수 있다. 이러한 특정 액션은 IM 클라이언트 정책 설정의 특징으로서 지정될 수 있다.
3. IM 사용자가 챗 세션을 시작할 때, IM 메시지의 지정된 일부를 위해 체크섬을 생성하기 위해 동작(406)이 IM메시지가 전송된 디바이스로부터 수행된다. 일 실시예에서, 이러한 부분들은 실질적인 메시지, 전송자 스크린 네임 및 날짜/시간 정보를 포함한다.
4. 체크섬의 생성 후에, 동작(407)이 인코딩된 체크섬을 생성하기 위해 인증서에 상응하는 사설 키를 갖는 체크섬을 인코딩하도록 수행된다. 이러한 인코딩된 체크섬은 자신의 인증을 인에이블하기 위한 인증서에 상응하는 사설 키에 의해 암호화되거나 또는 서명된 체크섬이다.
5. 체크섬의 인코딩 후에, 동작(408)이 IM 메시지 내에 명시된 수신자 스크린 네임에 상응하는 디바이스에 의한 수신을 위해 인코딩된 체크섬과 IM 메시지를 전송하도록 수행된다(즉, 수신 사용자 디바이스).
6. 인코딩된 체크섬의 전송 후에, 동작(410)이 인코딩된 체크섬을 수신하기 위해 수신 사용자 디바이스에 의해 수행된다.
7. 인코딩된 체크섬을 수신한 후에, 동작(412)은 인코딩된 체크섬을 유효화하도록, 그리고 정보 제공자의 인증 증명서를 사용하여 체크섬을 복제 및 컨펌하기 위해 수행된다. 정보 제공자의 인증 증명서는 인코딩된 체크섬의 유효성을 입증하기 위해 사용된다. 인코딩된 체크섬의 유효성은 전술된 이메일 구현에서의 인코딩된 체크섬의 유효성과 같은 방식으로 수행된다(예를 들어, 시그니처 검사 또는 인 코딩된 체크섬 복호화, 정보 제공자의 인증 증명서를 사용한 체크섬의 복제 및 컨펌 등).
8. 동작(414)은 체크섬이 성공적으로 입증되었는지 아닌지 여부를 나타내는 통지 정보를 나타내도록 제공된다. 만약 체크섬의 입증이 실패하였다면, 전송자의 스크린 네임이 권한되지 않은 것으로 플래그될 것이며 통지가 표시된다. 그렇지 않으면, 스크린 네임이 추가되고 성공적인 인증의 통지가 표시된다. 전술된 바와 같이, 정책은 추가의 액션이 취해질지를 표기한다.
본 명세서에서 본 발명에 따른 정보 제공자 인증 애플리케이션이 다양한 기능과 관련하여 기능적으로 및/또는 물리적으로 구분될 수 있다. 예를 들어, 일 실시예에서, 식별 정보 식별 입증 기능은 정보 제공자 인증 애플리케이션의 제 1 부분을 통해 제공되고, 통신 매체 특정 기능은 정보 제공자 인증 애플리케이션의 하나 이상의 다른 부분을 통해 제공된다. 보다 구체적으로, 일 실시예에서, 식별 정보 식별 입증 기능은 정보 제공자 인증 애플리케이션의 제 1 부분을 통해 제공되고, 이메일 인증 특정 동작은 정보 제공자 인증 애플리케이션의 제 2 부분을 통해 제공되고, 웹페이지 인증 특정 동작은 정보 제공자 인증 애플리케이션의 제 3 부분을 통해 제공되며, IM 메시지 특정 동작은 정보 제공자 인증 애플리케이션의 제 4 부분을 통해 제공된다. 이를 위해 본 발명에 따른 인증 애플리케이션은 모듈 방식으로 설계 및 유지될 수 있다.
본 발명에 따른 데이터 통신 디바이스에 의해 프로세스할 수 있는 명령어를 참조하면, 본 명세서에서 기술된 식별 정보 기능 및/또는 메시지 콘텐츠 인증을 활 성화하기 위한 방법, 프로세스 및/또는 동작들이 이러한 기능을 실행하기 위해 구성된 명령어를 갖는 컴퓨터 판독가능한 매체에 의해 구현됨을 이해할 것이다. 일 특정 실시예에서, 명령어는 도 1-7을 참조로 하여 개시된 하나 이상의 방법을 실행하기 위해 명백하게 구현된다. 이 명령어는 메모리 장치(예를 들어, RAM, ROM, 가상 메모리, 하드 드라이브 메모리 등)로부터, 데이터 프로세싱 시스템의 드라이브 유닛에 의해 판독가능한 장치(예를 들어, 디스켓, CD, 테이프 카트리지 등)로부터 또는 둘 모두로부터의 하나 이상의 데이터 프로세싱 디바이스에 의해 액세스될 수 있다. 따라서, 본 발명에 따른 컴퓨터 판독가능한 매체의 실시예는 CD, 하드 드라이브, RAM 또는 본 발명에 따른 식별 정보 기능 및/또는 메시지 콘텐츠 인증의 실행을 활성화하는 명령어(예를 들어, 컴퓨터 프로그램)가 이미지된 다른 유형의 저장 장치를 포함한다.
전술된 상세한 설명에서, 본 명세서의 일부를 형성하는 첨부된 도면을 참조로 하였으며, 여기에는 본 발명이 실시될 수 있는 특정한 실시예들이 예시적으로 도시되었다. 이러한 실시예와 이들의 변수는 당업자가 본 발명의 실시예를 실시하는 것을 가능케 하도록 충분히 상세하게 기술되었다. 다른 적절한 실시예들이 사용될 수도 있으며, 논리적, 기계적, 화학적, 전기적 변경사항들이 본 발명의 사상 또는 범주로부터 벗어나지 않는 한 가능함을 이해할 것이다. 불필요한 세부사항을 없애기 위해, 설명에서 당업자에게 알려진 소정의 정보들이 생략되었다. 따라서 전술된 상세한 설명은 본 발명에서 설정된 특정한 형태만으로 제한하고자 하는 것이 아니며, 그와 반대로 첨부된 특허청구범위의 사상 및 범주 내에 포함될 수 있는 대 안, 수정 및 균등물을 포함하고자 한다.

Claims (22)

  1. 복수의 정보 제공자 각각에 발행된 인증 증명서(authentication certificate)를 포함하는 인증서 레지스트리(certificate registry) 및 상기 인증 증명서 모두에 상응하는 루트 인증서(root certificate)를 생성하는 단계와,
    상기 루트 인증서를 정보 수신자에게 제공하는 단계와,
    상기 정보 수신자에 의해 액세스되고 자신과 관련된 인증 증명서를 갖는 웹페이지의 입증(verification)을 활성화하는 단계를 포함하되,
    상기 인증 증명서 각각은 자신의 각 인증 정보를 상응하는 정보 제공자의 식별 정보에 링크시키고, 상기 인증 증명서 각각은 상기 상응하는 정보 제공자와 그의 도메인 네임 정보 사이의 연계성을 갖지 않으며, 상기 인증서 레지스트리의 상기 인증 증명서는, 상기 정보 제공자가 제공하는 정보의 특정 타입, 상기 정보 제공자가 관련된 특정 조직, 상기 정보 제공자가 종사하는 특정 직업군 및 상기 정보 제공자가 위치하는 특정 지리적 구역 중 적어도 하나에 적어도 부분적으로 의존하며,
    상기 입증은, 상기 루트 인증서에 포함된 인증 정보를 사용하여 상기 관련된 인증 증명서의 신뢰성(authenticity)을 성공적으로 입증함으로써 상기 관련된 인증 증명서가 상기 인증서 레지스트리에 속함을 입증하는 단계와, 상기 관련된 인증 증명서의 신뢰성을 성공적으로 입증한 후, 상기 관련된 인증 증명서에 포함된 인증 정보를 사용하여 상기 웹페이지의 지정된 소유자의 아이덴티티를 성공적으로 입증하는 단계를 포함하는
    방법.
  2. 제 1 항에 있어서,
    상기 식별 정보는, 상기 정보 제공자 각각이 인식되는 네임, 상기 정보 제공자 각각에 대해 특정된 이미지, 상기 정보 제공자 각각에 대해 특정된 텍스트 및 상기 정보 제공자 각각에 대해 특정된 사운드 중 적어도 하나를 포함하는
    방법.
  3. 제 1 항에 있어서,
    상기 식별 정보는, 상기 정보 제공자 각각의 보호 네임(protected name), 상기 정보 제공자 각각의 보호 이미지, 상기 정보 제공자 각각의 보호 텍스트 및 상기 정보 제공자 각각의 보호 사운드 중 적어도 하나를 포함하는
    방법.
  4. 제 1 항에 있어서,
    상기 정보 수신자에게 상기 루트 인증서를 제공하는 단계는 상기 루트 인증 서를 명백하게 요청하는 상기 정보 수신자에 응답하여 수행되고,
    상기 루트 인증서는 특정 정보 타입, 특정 조직, 특정 직업군 및 특정 지리적 구역 중 적어도 하나에 해당하는
    방법.
  5. 제 4 항에 있어서,
    상기 식별 정보는, 상기 정보 제공자 각각의 보호 네임(protected name), 상기 정보 제공자 각각의 보호 이미지, 상기 정보 제공자 각각의 보호 텍스트 및 상기 정보 제공자 각각의 보호 사운드 중 적어도 하나를 포함하는
    방법.
  6. 제 4 항에 있어서,
    상기 정보 수신자에 의해 액세스된 상기 웹페이지의 입증을 활성화하는 단계는,
    웹서버로부터 상기 관련된 인증 증명서를 검색하는 단계와,
    상기 웹서버가 상기 인증 증명서에 대한 매칭 키(matching key)를 구비함을 입증하는 단계와,
    상기 인증 증명서가 유효하며 상기 웹서버가 상기 매칭 키를 구비한다는 판 단에 응답하여 상기 웹페이지의 신뢰성을 승인하고, 그에 따라 상기 웹서버와 상기 정보 수신자 사이에서 채널 통신하는 웹페이지가 인증되었음을 입증하는 단계를 포함하는
    방법.
  7. 제 4 항에 있어서,
    상기 정보 수신자에 의해 액세스된 상기 웹페이지의 입증을 활성화하는 단계는 웹서버로부터 상기 웹페이지를 나타내는 파일을 검색하는 단계를 포함하고,
    상기 파일은 상기 웹페이지의 시리얼 넘버 및 상기 관련된 인증 증명서를 포함하고,
    상기 파일이 상기 웹서버로부터 전송되었음과 상기 웹서버가 상기 인증 증명서에 대한 매칭 키를 가짐을 입증하는 단계는,
    상기 웹서버로 상기 시리얼 넘버를 전송하는 단계와,
    상기 인증 증명서의 사설 키로 서명된 상기 서버로부터 상기 파일의 체크섬(checksum)을 수신하는 단계와,
    상기 서버로부터 수신된 상기 비준(confirmation) 체크섬이 상기 수신된 파일을 사용하여 생성된 체크섬과 매칭하는지를 결정하는 단계와,
    상기 인증 증명서가 상기 루트 인증서의 상기 사설 키에 의해 서명되었는지를 결정하는 단계
    를 포함하는
    방법.
  8. 제 7 항에 있어서,
    상기 파일은 상기 웹페이지와 관련된 인증 증명서를 지정하는
    방법.
  9. 제 8 항에 있어서,
    상기 관련된 인증 증명서를 검색한 후 상기 관련된 인증 증명서를 캐싱(caching)하고, 그에 따라 상기 인증 증명서의 반복적인 검색을 방지하는
    방법.
  10. 인증서 레지스트리로서,
    복수의 정보 제공자 각각에 발행된 인증 증명서와,
    상기 인증 증명서 모두에 상응하는 루트 인증서를 포함하되,
    상기 인증 증명서 각각은 자신의 각 인증 정보를 상응하는 정보 제공자의 식별 정보에 링크시키고,
    상기 인증 증명서 각각은 상기 상응하는 정보 제공자와 그의 도메인 네임 정보 사이의 연계성을 갖지 않으며,
    상기 인증서 레지스트리의 상기 인증 증명서는, 상기 정보 제공자가 제공하는 정보의 특정 타입, 상기 정보 제공자가 관련된 특정 조직, 상기 정보 제공자가 종사하는 특정 직업군 및 상기 정보 제공자가 위치하는 특정 지리적 구역 중 적어도 하나에 적어도 부분적으로 의존하는
    인증서 레지스트리.
  11. 제 10 항에 있어서,
    상기 식별 정보는, 상기 정보 제공자 각각이 인식되는 네임, 상기 정보 제공자 각각에 대해 특정된 이미지, 상기 정보 제공자 각각에 대해 특정된 텍스트 및 상기 정보 제공자 각각에 대해 특정된 사운드 중 적어도 하나를 포함하는
    인증서 레지스트리.
  12. 제 10 항에 있어서,
    상기 식별 정보는, 상기 정보 제공자 각각의 보호 네임, 상기 정보 제공자 각각의 보호 이미지, 상기 정보 제공자 각각의 보호 텍스트 및 상기 정보 제공자 각각의 보호 사운드 중 적어도 하나를 포함하는
    인증서 레지스트리.
  13. 복수의 정보 제공자 각각에 인증 증명서를 발행하고, 상기 인증 증명서 모두에 상응하는 루트 인증서를 유지하도록 구성된 인증서 레지스트리 시스템으로서,
    상기 인증 증명서 각각은 자신의 각 인증 정보를 상응하는 정보 제공자의 식별 정보에 링크시키고, 상기 인증 증명서 각각은 상기 상응하는 정보 제공자와 그의 도메인 네임 정보 사이의 연계성을 갖지 않으며, 상기 인증서 레지스트리의 상기 인증 증명서는, 상기 정보 제공자가 제공하는 정보의 특정 타입, 상기 정보 제공자가 관련된 특정 조직, 상기 정보 제공자가 종사하는 특정 직업군 및 상기 정보 제공자가 위치하는 특정 지리적 구역 중 적어도 하나에 적어도 부분적으로 의존하는
    인증서 레지스트리 시스템.
  14. 제 14 항에 있어서,
    상기 식별 정보는, 상기 정보 제공자 각각이 인식되는 네임, 상기 정보 제공자 각각에 대해 특정된 이미지, 상기 정보 제공자 각각에 대해 특정된 텍스트 및 상기 정보 제공자 각각에 대해 특정된 사운드 중 적어도 하나를 포함하는
    인증서 레지스트리 시스템.
  15. 제 14 항에 있어서,
    상기 식별 정보는, 상기 정보 제공자 각각의 보호 네임, 상기 정보 제공자 각각의 보호 이미지, 상기 정보 제공자 각각의 보호 텍스트 및 상기 정보 제공자 각각의 보호 사운드 중 적어도 하나를 포함하는
    인증서 레지스트리 시스템.
  16. 제 14 항에 있어서,
    상기 루트 인증서를 명백하게 요청하는 정보 수신자에 응답하여 상기 정보 수신자에게 상기 루트 인증서를 제공하도록 추가로 구성되고,
    상기 루트 인증서는 특정 정보 타입, 특정 조직, 특정 직업군 및 특정 지리적 구역 중 적어도 하나에 해당하는
    인증서 레지스트리 시스템.
  17. 제 17 항에 있어서,
    상기 식별 정보는, 상기 정보 제공자 각각의 보호 네임, 상기 정보 제공자 각각의 보호 이미지, 상기 정보 제공자 각각의 보호 텍스트 및 상기 정보 제공자 각각의 보호 사운드 중 적어도 하나를 포함하는
    인증서 레지스트리 시스템.
  18. 제 17 항에 있어서,
    상기 정보 수신자에 의해 액세스되고 자신과 관련된 인증 증명서를 갖는 웹페이지의 입증을 활성화하도록 추가로 구성되며,
    상기 입증은, 상기 루트 인증서에 포함된 인증 정보를 사용하여 상기 관련된 인증 증명서의 신뢰성을 성공적으로 입증함으로써 상기 관련된 인증 증명서가 상기 인증서 레지스트리에 속함을 입증하는 것과, 상기 관련된 인증 증명서의 신뢰성을 성공적으로 입증한 후, 상기 관련된 인증 증명서에 포함된 인증 정보를 사용하여 상기 웹페이지의 지정된 소유자의 아이덴티티를 성공적으로 입증하는 것을 포함하는
    인증서 레지스트리 시스템.
  19. 제 18 항에 있어서,
    상기 정보 수신자에 의해 액세스된 상기 웹페이지의 입증을 활성화하는 단계는,
    웹서버로부터 상기 관련된 인증 증명서를 검색하는 단계와,
    상기 웹서버가 상기 인증 증명서에 대한 매칭 키를 구비함을 입증하는 단계 와,
    상기 인증 증명서가 유효하며 상기 웹서버가 상기 매칭 키를 구비한다는 판단에 응답하여 상기 웹페이지의 신뢰성을 승인하고, 그에 따라 상기 웹서버와 상기 정보 수신자 사이에서 채널 통신하는 웹페이지가 인증되었음을 입증하는 단계를 포함하는
    인증서 레지스트리 시스템.
  20. 제 18 항에 있어서,
    상기 정보 수신자에 의해 액세스된 상기 웹페이지의 입증을 활성화하는 단계는 웹서버로부터 상기 웹페이지를 나타내는 파일을 검색하는 단계를 포함하고,
    상기 파일은 상기 웹페이지의 시리얼 넘버 및 상기 관련된 인증 증명서를 포함하고,
    상기 파일이 상기 웹서버로부터 전송되었음과 상기 웹서버가 상기 인증 증명서에 대한 매칭 키를 가짐을 입증하는 단계는,
    상기 웹서버로 상기 시리얼 넘버를 전송하는 단계와,
    상기 인증 증명서의 사설 키로 서명된 상기 서버로부터 상기 파일의 체크섬을 수신하는 단계와,
    상기 서버로부터 수신된 상기 비준 체크섬이 상기 수신된 파일을 사용하여 생성된 체크섬과 매칭하는지를 결정하는 단계와,
    상기 인증 증명서가 상기 루트 인증서의 상기 사설 키에 의해 서명되었는지를 결정하는 단계
    를 포함하는
    인증서 레지스트리 시스템.
  21. 제 20 항에 있어서,
    상기 파일은 상기 웹페이지와 관련된 인증 증명서를 지정하는
    인증서 레지스트리 시스템.
  22. 제 20 항에 있어서,
    상기 관련된 인증 증명서를 검색한 후 상기 관련된 인증 증명서를 캐싱하도록 추가로 구성되고, 그에 따라 상기 인증 증명서의 반복적인 검색을 방지하는
    인증서 레지스트리 시스템.
KR1020097025575A 2007-06-07 2008-06-05 인증서 레지스트리, 인증서 레지스트리 시스템 및 방법 KR101133829B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US11/811,235 2007-06-07
US11/811,235 US7877784B2 (en) 2007-06-07 2007-06-07 Verifying authenticity of webpages
PCT/IB2008/053482 WO2008149331A2 (en) 2007-06-07 2008-06-05 Verifying authenticity of webpages

Publications (2)

Publication Number Publication Date
KR20100017704A true KR20100017704A (ko) 2010-02-16
KR101133829B1 KR101133829B1 (ko) 2012-04-24

Family

ID=40094267

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020097025575A KR101133829B1 (ko) 2007-06-07 2008-06-05 인증서 레지스트리, 인증서 레지스트리 시스템 및 방법

Country Status (6)

Country Link
US (1) US7877784B2 (ko)
EP (1) EP2156646A2 (ko)
JP (1) JP2010530097A (ko)
KR (1) KR101133829B1 (ko)
CN (1) CN101711472B (ko)
WO (1) WO2008149331A2 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022059914A1 (ko) * 2020-09-18 2022-03-24 삼성전자주식회사 전자 장치 및 그 제어 방법

Families Citing this family (81)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9400589B1 (en) 2002-05-30 2016-07-26 Consumerinfo.Com, Inc. Circular rotational interface for display of consumer credit information
US9710852B1 (en) 2002-05-30 2017-07-18 Consumerinfo.Com, Inc. Credit report timeline user interface
US7131003B2 (en) 2003-02-20 2006-10-31 America Online, Inc. Secure instant messaging system
US8001383B2 (en) * 2007-02-01 2011-08-16 Microsoft Corporation Secure serial number
WO2008147918A2 (en) 2007-05-25 2008-12-04 Experian Information Solutions, Inc. System and method for automated detection of never-pay data sets
US9990674B1 (en) 2007-12-14 2018-06-05 Consumerinfo.Com, Inc. Card registry systems and methods
US8127986B1 (en) 2007-12-14 2012-03-06 Consumerinfo.Com, Inc. Card registry systems and methods
US8312033B1 (en) 2008-06-26 2012-11-13 Experian Marketing Solutions, Inc. Systems and methods for providing an integrated identifier
US9256904B1 (en) 2008-08-14 2016-02-09 Experian Information Solutions, Inc. Multi-bureau credit file freeze and unfreeze
US8060424B2 (en) 2008-11-05 2011-11-15 Consumerinfo.Com, Inc. On-line method and system for monitoring and reporting unused available credit
US20100180121A1 (en) * 2009-01-09 2010-07-15 Alcatel-Lucent Method and apparatus for enhancing security in network-based data communication
US9955352B2 (en) 2009-02-17 2018-04-24 Lookout, Inc. Methods and systems for addressing mobile communications devices that are lost or stolen but not yet reported as such
US9652802B1 (en) 2010-03-24 2017-05-16 Consumerinfo.Com, Inc. Indirect monitoring and reporting of a user's credit data
EP2385679B1 (en) * 2010-05-07 2014-08-20 BlackBerry Limited Locally stored phishing countermeasure
WO2011143542A1 (en) * 2010-05-13 2011-11-17 Ramakant Pandrangi Systems and methods for identifying malicious domains using internet-wide dns lookup patterns
US9147042B1 (en) 2010-11-22 2015-09-29 Experian Information Solutions, Inc. Systems and methods for data verification
AU2012217565B2 (en) 2011-02-18 2017-05-25 Csidentity Corporation System and methods for identifying compromised personally identifiable information on the internet
US9607336B1 (en) 2011-06-16 2017-03-28 Consumerinfo.Com, Inc. Providing credit inquiry alerts
US9483606B1 (en) 2011-07-08 2016-11-01 Consumerinfo.Com, Inc. Lifescore
US9106691B1 (en) 2011-09-16 2015-08-11 Consumerinfo.Com, Inc. Systems and methods of identity protection and management
US20150128218A1 (en) * 2011-09-26 2015-05-07 Brett R Vogel System and method for restricting internet access
US8738516B1 (en) 2011-10-13 2014-05-27 Consumerinfo.Com, Inc. Debt services candidate locator
US11030562B1 (en) 2011-10-31 2021-06-08 Consumerinfo.Com, Inc. Pre-data breach monitoring
US20130179768A1 (en) * 2012-01-05 2013-07-11 International Business Machines Corporation Differentiated Information Display For Certified and Uncertified Web Page Versions
US20130254553A1 (en) * 2012-03-24 2013-09-26 Paul L. Greene Digital data authentication and security system
US9853959B1 (en) 2012-05-07 2017-12-26 Consumerinfo.Com, Inc. Storage and maintenance of personal data
US9083696B1 (en) * 2012-05-30 2015-07-14 Google Inc. Trusted peer-based information verification system
US9407443B2 (en) 2012-06-05 2016-08-02 Lookout, Inc. Component analysis of software applications on computing devices
US9589129B2 (en) 2012-06-05 2017-03-07 Lookout, Inc. Determining source of side-loaded software
CN103516693B (zh) * 2012-06-28 2017-10-24 中国电信股份有限公司 鉴别钓鱼网站的方法与装置
US8655307B1 (en) 2012-10-26 2014-02-18 Lookout, Inc. System and method for developing, updating, and using user device behavioral context models to modify user, device, and application state, settings and behavior for enhanced user security
US9654541B1 (en) 2012-11-12 2017-05-16 Consumerinfo.Com, Inc. Aggregating user web browsing data
US9178862B1 (en) * 2012-11-16 2015-11-03 Isaac S. Daniel System and method for convenient and secure electronic postmarking using an electronic postmarking terminal
US9916621B1 (en) 2012-11-30 2018-03-13 Consumerinfo.Com, Inc. Presentation of credit score factors
US10255598B1 (en) 2012-12-06 2019-04-09 Consumerinfo.Com, Inc. Credit card account data extraction
US9208215B2 (en) 2012-12-27 2015-12-08 Lookout, Inc. User classification based on data gathered from a computing device
US9374369B2 (en) 2012-12-28 2016-06-21 Lookout, Inc. Multi-factor authentication and comprehensive login system for client-server networks
US10102570B1 (en) 2013-03-14 2018-10-16 Consumerinfo.Com, Inc. Account vulnerability alerts
US8812387B1 (en) 2013-03-14 2014-08-19 Csidentity Corporation System and method for identifying related credit inquiries
US9870589B1 (en) 2013-03-14 2018-01-16 Consumerinfo.Com, Inc. Credit utilization tracking and reporting
US9406085B1 (en) 2013-03-14 2016-08-02 Consumerinfo.Com, Inc. System and methods for credit dispute processing, resolution, and reporting
US10664936B2 (en) 2013-03-15 2020-05-26 Csidentity Corporation Authentication systems and methods for on-demand products
US9633322B1 (en) 2013-03-15 2017-04-25 Consumerinfo.Com, Inc. Adjustment of knowledge-based authentication
US10685398B1 (en) 2013-04-23 2020-06-16 Consumerinfo.Com, Inc. Presenting credit score information
US9307412B2 (en) 2013-04-24 2016-04-05 Lookout, Inc. Method and system for evaluating security for an interactive service operation by a mobile device
US9721147B1 (en) 2013-05-23 2017-08-01 Consumerinfo.Com, Inc. Digital identity
US9276855B1 (en) 2013-07-16 2016-03-01 Google Inc. Systems and methods for providing navigation filters
US9443268B1 (en) 2013-08-16 2016-09-13 Consumerinfo.Com, Inc. Bill payment and reporting
US9642008B2 (en) 2013-10-25 2017-05-02 Lookout, Inc. System and method for creating and assigning a policy for a mobile communications device based on personal data
US10325314B1 (en) 2013-11-15 2019-06-18 Consumerinfo.Com, Inc. Payment reporting systems
US9477737B1 (en) 2013-11-20 2016-10-25 Consumerinfo.Com, Inc. Systems and user interfaces for dynamic access of multiple remote databases and synchronization of data based on user rules
US9753796B2 (en) 2013-12-06 2017-09-05 Lookout, Inc. Distributed monitoring, evaluation, and response for multiple devices
US10122747B2 (en) 2013-12-06 2018-11-06 Lookout, Inc. Response generation after distributed monitoring and evaluation of multiple devices
US9378276B1 (en) 2014-01-03 2016-06-28 Google Inc. Systems and methods for generating navigation filters
USD759689S1 (en) 2014-03-25 2016-06-21 Consumerinfo.Com, Inc. Display screen or portion thereof with graphical user interface
USD759690S1 (en) 2014-03-25 2016-06-21 Consumerinfo.Com, Inc. Display screen or portion thereof with graphical user interface
USD760256S1 (en) 2014-03-25 2016-06-28 Consumerinfo.Com, Inc. Display screen or portion thereof with graphical user interface
US9892457B1 (en) 2014-04-16 2018-02-13 Consumerinfo.Com, Inc. Providing credit data in search results
US10373240B1 (en) 2014-04-25 2019-08-06 Csidentity Corporation Systems, methods and computer-program products for eligibility verification
US10339527B1 (en) 2014-10-31 2019-07-02 Experian Information Solutions, Inc. System and architecture for electronic fraud detection
EP3257221B1 (en) * 2015-02-13 2022-03-09 Yoti Holding Limited Digital identity
EP3289510B1 (en) 2015-05-01 2020-06-17 Lookout Inc. Determining source of side-loaded software
US11151468B1 (en) 2015-07-02 2021-10-19 Experian Information Solutions, Inc. Behavior analysis using distributed representations of event data
US11552923B2 (en) 2015-12-30 2023-01-10 Donuts, Inc. Whitelist domain name registry
CN107306251B (zh) * 2016-04-20 2020-03-17 中国移动通信有限公司研究院 一种信息认证方法及网关设备
US10440053B2 (en) 2016-05-31 2019-10-08 Lookout, Inc. Methods and systems for detecting and preventing network connection compromise
CN108259406B (zh) * 2016-12-28 2020-12-29 中国电信股份有限公司 检验ssl证书的方法和系统
US10218697B2 (en) 2017-06-09 2019-02-26 Lookout, Inc. Use of device risk evaluation to manage access to services
CN108055227B (zh) * 2017-08-08 2020-10-20 西安交大捷普网络科技有限公司 基于站点自学习的waf未知攻击防御方法
US10699028B1 (en) 2017-09-28 2020-06-30 Csidentity Corporation Identity security architecture systems and methods
US10896472B1 (en) 2017-11-14 2021-01-19 Csidentity Corporation Security and identity verification system and architecture
US10911234B2 (en) 2018-06-22 2021-02-02 Experian Information Solutions, Inc. System and method for a token gateway environment
US20200074100A1 (en) 2018-09-05 2020-03-05 Consumerinfo.Com, Inc. Estimating changes to user risk indicators based on modeling of similarly categorized users
US11315179B1 (en) 2018-11-16 2022-04-26 Consumerinfo.Com, Inc. Methods and apparatuses for customized card recommendations
US11238656B1 (en) 2019-02-22 2022-02-01 Consumerinfo.Com, Inc. System and method for an augmented reality experience via an artificial intelligence bot
EP3997855A1 (en) * 2019-07-11 2022-05-18 Castelão Soares, Marco António Method and system for reliable authentication of the origin of a website
US11941065B1 (en) 2019-09-13 2024-03-26 Experian Information Solutions, Inc. Single identifier platform for storing entity data
US11269994B2 (en) 2020-02-07 2022-03-08 KnowBe4, Inc. Systems and methods for providing configurable responses to threat identification
US11444781B2 (en) * 2020-02-20 2022-09-13 Lenovo (Singapore) Pte. Ltd. Distributed trust authentication
CN111565172B (zh) * 2020-04-13 2022-07-12 北京天融信网络安全技术有限公司 劫持检测方法、装置、电子设备及存储介质
CN114915623B (zh) * 2022-07-11 2022-11-22 万商云集(成都)科技股份有限公司 一种文件同步的方法和系统

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6615350B1 (en) * 1998-03-23 2003-09-02 Novell, Inc. Module authentication and binding library extensions
GB2338381A (en) * 1998-06-10 1999-12-15 Barclays Bank Plc Cryptographic authentication for internet using two servers
US20020124172A1 (en) 2001-03-05 2002-09-05 Brian Manahan Method and apparatus for signing and validating web pages
US7130999B2 (en) 2002-03-27 2006-10-31 Intel Corporation Using authentication certificates for authorization
JP2003338815A (ja) * 2002-05-21 2003-11-28 Nec Corp 電子署名システムおよび電子署名方法
JP3888273B2 (ja) * 2002-09-25 2007-02-28 日本電気株式会社 外部プログラムの動作制御方法、動作制御プログラム、動作制御装置、及び、動作制御プログラム提供装置
JP3928589B2 (ja) * 2003-06-12 2007-06-13 コニカミノルタビジネステクノロジーズ株式会社 通信システムおよび方法
US7664948B2 (en) * 2004-05-21 2010-02-16 Bea Systems, Inc. Certificate lookup and validation
CN1835434B (zh) * 2006-04-10 2012-07-18 北京易恒信认证科技有限公司 一种基于cpk安全认证的电子邮件系统和方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022059914A1 (ko) * 2020-09-18 2022-03-24 삼성전자주식회사 전자 장치 및 그 제어 방법

Also Published As

Publication number Publication date
WO2008149331A3 (en) 2009-05-28
KR101133829B1 (ko) 2012-04-24
JP2010530097A (ja) 2010-09-02
EP2156646A2 (en) 2010-02-24
CN101711472A (zh) 2010-05-19
US20080307222A1 (en) 2008-12-11
WO2008149331A2 (en) 2008-12-11
US7877784B2 (en) 2011-01-25
CN101711472B (zh) 2016-01-20

Similar Documents

Publication Publication Date Title
KR101133829B1 (ko) 인증서 레지스트리, 인증서 레지스트리 시스템 및 방법
US7975290B2 (en) Verifying authenticity of instant messaging messages
US9002018B2 (en) Encryption key exchange system and method
US10516662B2 (en) System and method for authenticating the legitimacy of a request for a resource by a user
Ramzan Phishing attacks and countermeasures
US20080307226A1 (en) Verifying authenticity of e-mail messages
US10063545B2 (en) Rapid identification of message authentication
JP5179471B2 (ja) データを安全に伝送するための装置および方法
US8756289B1 (en) Message authentication using signatures
JP2011501578A (ja) セキュア通信の信頼性を示すための方法及びシステム
JP2006520112A (ja) セキュリティ用キーサーバ、否認防止と監査を備えたプロセスの実現
US20130103944A1 (en) Hypertext Link Verification In Encrypted E-Mail For Mobile Devices
Ollmann The phishing guide
Bojjagani et al. PhishPreventer: a secure authentication protocol for prevention of phishing attacks in mobile environment with formal verification
Herzberg et al. Protecting (even) Naive Web Users, or: preventing spoofing and establishing credentials of web sites
US20100180121A1 (en) Method and apparatus for enhancing security in network-based data communication
US20090208020A1 (en) Methods for Protecting from Pharming and Spyware Using an Enhanced Password Manager
CA2793422C (en) Hypertext link verification in encrypted e-mail for mobile devices
Jøsang et al. PKI seeks a trusting relationship
WO2005094264A2 (en) Method and apparatus for authenticating entities by non-registered users
Zhao et al. An add-on end-to-end secure email solution in mobile communications
Draper-Gil et al. My email communications security assessment (MECSA): 2018 results
Schwarz et al. Security challenges, threats and countermeasures version 1.0
Sedaghat Web authenticity
AU2005236499B2 (en) Electronic message authentication process

Legal Events

Date Code Title Description
A201 Request for examination
AMND Amendment
E902 Notification of reason for refusal
AMND Amendment
E601 Decision to refuse application
J201 Request for trial against refusal decision
AMND Amendment
B701 Decision to grant
GRNT Written decision to grant
LAPS Lapse due to unpaid annual fee