KR20230031192A - 토큰 상환을 통한 익명 인증 - Google Patents

토큰 상환을 통한 익명 인증 Download PDF

Info

Publication number
KR20230031192A
KR20230031192A KR1020227038973A KR20227038973A KR20230031192A KR 20230031192 A KR20230031192 A KR 20230031192A KR 1020227038973 A KR1020227038973 A KR 1020227038973A KR 20227038973 A KR20227038973 A KR 20227038973A KR 20230031192 A KR20230031192 A KR 20230031192A
Authority
KR
South Korea
Prior art keywords
proof
token
user
proof token
application
Prior art date
Application number
KR1020227038973A
Other languages
English (en)
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 KR20230031192A publication Critical patent/KR20230031192A/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
    • H04L9/321—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 involving a third party or a trusted authority
    • H04L9/3213—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 involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • 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/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • 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/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • 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
    • H04L9/3247—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 involving digital signatures
    • H04L9/3249—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 involving digital signatures using RSA or related signature schemes, e.g. Rabin scheme
    • 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
    • H04L9/3247—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 involving digital signatures
    • H04L9/3255—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 involving digital signatures using group based signatures, e.g. ring or threshold signatures
    • 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
    • H04L9/3247—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 involving digital signatures
    • H04L9/3257—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 involving digital signatures using blind signatures
    • 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
    • H04L9/3297—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 involving time stamps, e.g. generation of time stamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/42—Anonymization, e.g. involving pseudonyms
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0421—Anonymous communication, i.e. the party's identifiers are hidden from the other party or parties, e.g. using an anonymizer

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)

Abstract

본 개시는 익명 증명 방법에 관한 것으로서, 클라이언트 디바이스에서 실행되는 애플리케이션에 의해, 제1 콘텐츠 제공자로부터, 제2 콘텐츠 제공자의 제2 도메인으로부터 콘텐츠를 수신하기 위해 사용자를 인증하기 위한 인증 요청을 수신하는 단계, 사용자의 인증을 상기 제2 콘텐츠 제공자에게 증명하는 익명 증명 토큰을 발행하는 증명 토큰 발행 시스템으로, 상기 익명 증명 토큰을 제2 요청과 함께 전송함으로써 상기 익명 증명 토큰을 상환하는 단계, 상기 증명 토큰이 성공적으로 상환되었고, 상기 증명 토큰이 디지털 서명을 사용하여 증명 토큰 발행 시스템에 의해 서명되었는지 여부를 나타내는 상환 결과를 수신하는 단계, 상기 상환 결과는 상기 사용자를 상기 제2 콘텐츠 제공자에 대해 식별하지 않고 상기 사용자가 상기 제2 콘텐츠 제공자에 대해 인증되었음을 상기 제2 콘텐츠 제공자에게 검증하도록 동작가능하며, 및 상기 상환 결과를 제1 콘텐츠 제공자에게 전송하는 단계를 포함한다.

Description

토큰 상환을 통한 익명 인증
클라이언트 디바이스는 인터넷과 같은 공용 네트워크를 통해 요청 및 기타 데이터를 전송한다. 이러한 통신은 통신을 가로채는 당사자 및/또는 통신을 수신하여 다른 당사자에게 전달하는 중개자와 같은 다른 당사자에 의해 변경될 수 있다.
다른 당사자는 클라이언트 디바이스를 에뮬레이트하여 클라이언트 디바이스로부터 시작된 것처럼 보이지만 실제로는 다른 당사자의 디바이스에서 오는 요청을 보낼 수 있다.
다양한 인증 기법을 사용하여 공용 네트워크를 통해 트랜잭션을 수행하려는 클라이언트 디바이스의 신원을 검증할 수 있다. 동시에 이러한 인증 기법은 개인 정보 보호 문제를 내포할 수 있다. 예를 들어, 클라이언트 디바이스의 사용자는 클라이언트 디바이스 또는 이러한 클라이언트 디바이스의 사용자를 추적하는데 사용될 수 있는 정보(예: 안정적인 디바이스 식별자)를 공유하기를 원하지 않을 수 있으며, 데이터 제공자는 그러한 정보의 수신 또는 취급을 막는 프라이버시 보호 표준 하에서 동작할 수 있다.
본 명세서는 클라이언트 디바이스 또는 그 사용자를 추적하는데 사용될 수 있는 안정적인 디바이스 식별자의 사용을 피하는 동시에 클라이언트 디바이스의 무결성/진정성을 검증하기 위한 인증 기법을 설명한다.
일반적으로, 본 명세서에 기술된 발명의 일 혁신적 양태는 익명 증명을 위한 방법에 수록될 수 있고, 상기 방법은 클라이언트 디바이스에서 실행되는 애플리케이션에 의해, 제1 콘텐츠 제공자의 제1 도메인에서 호스팅되는 제1 서버로부터, 상기 제1 콘텐츠 제공자와 상이한 제2 콘텐츠 제공자의 제2 도메인으로부터 콘텐츠를 수신하기 위해 사용자를 인증하기 위한 인증 요청을 수신하는 단계; 인증 요청을 수신하는 것에 응답하여, 상기 애플리케이션에 의해, 사용자의 인증을 상기 제2 콘텐츠 제공자에게 증명하는 익명 증명 토큰을 발행하는 증명 토큰 발행 시스템으로, 상기 익명 증명 토큰을 제2 요청과 함께 전송함으로써 상기 익명 증명 토큰을 상환하는 단계, 상기 애플리케이션에 의해, 상기 제2 요청에 응답하여 상기 증명 토큰 발행 시스템으로부터, 상기 증명 토큰이 성공적으로 상환되었고, 상기 증명 토큰이 디지털 서명을 사용하여 증명 토큰 발행 시스템에 의해 서명되었는지 여부를 나타내는 상환 결과를 수신하는 단계, 상기 상환 결과는 상기 사용자를 상기 제2 콘텐츠 제공자에 대해 식별하지 않고 상기 사용자가 상기 제2 콘텐츠 제공자에 대해 인증되었음을 상기 제2 콘텐츠 제공자에게 검증하도록 동작가능하며; 상기 애플리케이션에 의해, 상기 증명 토큰 발행 시스템에 의해 서명된 상기 상환 결과를 상기 제1 콘텐츠 제공자에게 전송하는 단계를 포함한다.
일부 구현예에서, 상기 상환 결과는 상기 제1 콘텐츠 제공자에게 상기 사용자에 대한 자격증명들의 세트를 제공하지 않고 상기 사용자가 익명을 유지하게 하면서, 상기 사용자가 상기 제2 콘텐츠 제공자에 대해 인증되었음을 수신자에게 검증하도록 동작가능하다.
일부 구현예에서, 제2 콘텐츠 제공자는 뉴스 제공자이고, 제1 콘텐츠 제공자는 뉴스 수집 도메인이며, 상기 애플리케이션에 의해, 상기 증명 토큰 발행 시스템에 의해 서명된 상기 상환 결과를 상기 제1 콘텐츠 제공자에게 전송하는 단계는 상기 뉴스 제공자에 의해 호스팅되는 리소스에 대한 액세스를 요청하는 사용자 액션에 응답하여 수행된다.
일부 구현예에서, 제2 콘텐츠 제공자는 미디어 호스팅 플랫폼이고, 제1 콘텐츠 제공자는 소셜 미디어 플랫폼이며, 상기 애플리케이션에 의해, 상기 증명 토큰 발행 시스템에 의해 서명된 상기 상환 결과를 상기 제1 콘텐츠 제공자에게 전송하는 단계는 상기 미디어 호스팅 플랫폼에 의해 호스팅되는 리소스에 대한 액세스를 요청하는 사용자 액션에 응답하여 수행된다.
일부 구현예에서 상기 방법은 클라이언트 디바이스에서 애플리케이션에 의해, 상기 사용자의 인증을 상기 제2 콘텐츠 제공자에게 증명하는 익명 증명 토큰에 대한 제1 요청을 엔터티에 대해 사용자를 인증하는 상기 클라이언트 디바이스의 사용자의 자격증명에 액세스하는 신뢰 프로그램에 전송하는 단계, 상기 신뢰 프로그램에 의해, 익명 증명 토큰에 대한 제3 요청을 상기 증명 토큰 발행 시스템에 전송하는 단계, 상기 제3 요청은 상기 클라이언트 디바이스의 사용자에 대한 자격증명들의 세트를 포함하며; 및 상기 애플리케이션에 의해, 상기 증명 토큰 발행 시스템으로부터, (i) 익명 증명 토큰의 생성 시간을 나타내는 증명 토큰 생성 타임스탬프 및 (ii) 증명 토큰 발행 시스템의 제2 디지털 서명을 포함하는 익명 증명 토큰을 수신하는 단계를 포함한다.
일부 구현예에서, 방법은 상기 애플리케이션에 의해, 상기 제1 콘텐츠 제공자의 전자 리소스를 통해 제2 콘텐츠 제공자로부터, 제2 콘텐츠 제공자로부터의 콘텐츠를 요청하는 단계를 포함한다.
일부 구현예에서, 방법은 상기 애플리케이션에 의해, 상기 제2 콘텐츠 제공자로부터 콘텐츠를 수신하는 단계를 포함한다.
일부 구현예에서, 증명 토큰 발행 시스템의 디지털 서명은 블라인드 서명 방식에 따라 생성된다.
일부 구현예에서, 증명 토큰 발행 시스템의 디지털 서명은 그룹 서명 방식 및 상기 클라이언트 디바이스에 발행된 익명 인증서를 사용하여 생성되고, 그리고 방법은 클라이언트 디바이스의 보안 개인 키스토어에 상기 익명 인증서를 저장하는 단계를 포함한다.
일부 구현예에서, 증명 토큰 발행 시스템에 의해 서명된 상환 결과를 전송하는 단계는 (i) 상기 애플리케이션에 의해 서명되고 (ii) 상기 사용자를 자격증명들의 세트와 상관시키지 않는 추가 데이터를 제공하는 단계를 포함한다.
일부 구현예에서, 요청은 발행될 증명 토큰의 수를 나타낸다.
일부 구현예에서, 요청은 상기 애플리케이션에 의해 유지되는 개인 키를 사용하여 제3 디지털 서명으로 서명되고, 제3 디지털 서명은 (i) 상기 개인 키에 대응하고 (ii) 상기 애플리케이션에 의해 퍼블리시된 공개 키를 사용하여 검증될 수 있다.
일부 구현예에서, 제2 디지털 서명은 상기 증명 토큰 발행 시스템에 의해 유지되는 개인 키를 사용하여 생성되고, 상기 제3 디지털 서명은 (i) 상기 개인 키에 대응하고 (ii) 상기 증명 토큰 발행 시스템에 의해 퍼블리시된 공개 키를 사용하여 검증될 수 있다.
일부 구현예에서, 상기 상환 결과는 증명 토큰이 성공적으로 상환되었는지 여부를 나타내는 단일 비트를 포함한다.
이 양태들의 다른 실시예들은 상기 방법들의 액션들을 수행하도록 구성된 대응 시스템들, 장치들 및 컴퓨터 저장 디바이스들에 인코딩된 컴퓨터 프로그램들을 포함한다.
본 명세서에 기술된 본 발명은 다음의 이점들을 실현하도록 특정한 실시예들에서 구현될 수 있다.
증명 토큰을 사용하여 클라이언트 디바이스 또는 사용자를 인증하면 클라이언트 디바이스와 컴퓨터 또는 다른 엔터티의 다른 디바이스 간에 보안 통신 채널을 제공한다. 증명 토큰을 포함하면, 증명 토큰에 포함된 데이터의 디지털 서명은 엔터티로 하여금 증명 토큰이 생성된 후 증명 토큰의 데이터가 변경되지 않았는지 검증하게 할 수 있다. 또한, 증명 토큰에 토큰 생성 시간을 포함하면 수신자로 하여금 요청이 새로운 것인지 아니면 동작을 수행하기 위해 인증된 디바이스의 신원을 부정하게 사용하기 위해 서드파티에 의한 방식의 잠재적 일부인지 여부를 결정하게 할 수 있다.
예를 들어, 증명 토큰은 리소스에 대해 클라이언트 디바이스를 식별하지 않고 클라이언트 디바이스가 특정 리소스에 액세스할 수 있는 권한이 있음을 식별하는데 사용될 수 있고 리소스를 유지하는 당사자는 클라이언트 디바이스가 합법적인 권한이 부여된 사용자이고 클라이언트 디바이스가 리소스와 관련하여 익명성을 유지할 수 있도록 한다.
증명 토큰 시스템은 웹사이트 또는 플랫폼과 개인 식별 정보(PII)를 공유하지 않고 동일한 플랫폼 내 및 상이한 플랫폼에서 다른 웹사이트에서 디바이스 및/또는 사용자를 인증하는 기능을 제공한다. 예를 들어, 증명 토큰 시스템을 통해 사용자는 서드파티 콘텐츠 수집 플랫폼 및 웹사이트 또는 제공자에게 PII를 제공하지 않고 서드파티 콘텐츠 수집 플랫폼 및 웹사이트를 통해 인증이 필요한 플랫폼 또는 제공자의 리소스 및 콘텐츠에 액세스할 수 있다. 증명 토큰 시스템은 개인 정보를 보호하고 서로 다른 웹사이트와 플랫폼 간의 경계를 강화하며 편리하고 원활한 방식으로 리소스와 콘텐츠에 대한 액세스를 제공한다. 이러한 PII를 사용하여 리소스에 액세스하기 위해 사용자 이름 및 비밀번호와 같은 PII를 서드파티 콘텐츠 수집 플랫폼에 제공하는 대신, 클라이언트 디바이스는 클라이언트의 사용자가 리소스에 액세스하는 서드파티 콘텐츠 수집 플랫폼에 인증하는 상환 결과를 제공할 수 있다. 따라서 서드파티 콘텐츠 수집 플랫폼은 일반적으로 리소스에 액세스하는데 사용되는 사용자의 PII(예: 리소스에 직접 액세스하는데 사용되는 사용자의 사용자 이름 및 비밀번호)를 수신하고, 리소스의 퍼블리셔는 사용자가 서드파티 콘텐츠 수집 플랫폼을 통해 리소스에 액세스하고 있는지 결정할 수 없다. 이는 리소스에 대한 사용자의 PII와 관련하여 사용자의 프라이버시를 보호하고, 서드파티 콘텐츠 수집 플랫폼을 사용하는 사용자의 프라이버시를 보호한다.
증명 토큰 시스템은 사용자 마찰의 원인을 제거하여 사용자 경험을 개선한다. 예를 들어, 증명 토큰을 사용하면 사용자가 추가 인증 정보를 제공하지 않고도 제한된 리소스에 액세스하게 할 수 있다.
증명 토큰은 또한 증명 토큰을 전송한 클라이언트 디바이스의 무결성을 표시하는 디바이스 무결성 판정을 포함할 수 있으며, 이를 통해 증명 토큰의 수신자(들)로 하여금 데이터가 예를 들어 에뮬레이터나 손상된 디바이스가 아닌 신뢰할 수 있는 클라이언트 디바이스로부터 왔는지 검증하게 한다. 디바이스 무결성 판정은 신뢰 디바이스 분석기(예: 서드파티 디바이스 분석기)에 의해 생성되고 디지털 서명될 수 있으므로, 증명 토큰의 수신자는 클라이언트 디바이스가 신뢰 디바이스 분석기에 의해 평가되었고 데이터가 신뢰 디바이스 분석기에 의해 생성 후 디바이스 무결성 판정이 수정되지 않았다는 것을 검증하도록 할 수 있다.
증명 토큰은 클라이언트 디바이스로부터 전송된 통신의 무결성을 보호하지만 증명 토큰 사용과 연관된 잠재적인 프라이버시 문제가 있다. 제1 프라이버시 문제는 콘텐츠 퍼블리셔 또는 플랫폼과의 다수의 인터렉션 내에서 동일한 증명 토큰을 재사용하면 잠재적으로 증명 토큰 수신자가 동일한 클라이언트 디바이스에 의해 전송된 다수의 요청을 상관시키고, 그 상관관계에 기초하여 사용자 데이터를 수집하게 할 수 있다는 것이다. 본 문서에 설명된 기법은 클라이언트 디바이스의 고유한 공개 키를 포함하는 다수의 증명 토큰을 사용함으로써 이러한 상관 관계에 대한 프라이버시를 향상시킬 수 있다. 예를 들어, 클라이언트 디바이스는 N개의 공개/개인 키 쌍의 배치를 생성한 다음 N개의 공개 키를 서드파티 디바이스 분석기에 송신하여 N개의 대응하는 증명 토큰의 배치를 수신할 수 있다. 그러면, 클라이언트 디바이스는 예를 들어 각 요청에 대해 새 증명 토큰을 사용할 수 있다; 또는 클라이언트 디바이스가 특정 시간 간격 내에서 모든 요청에 대해 동일한 증명 토큰을 사용할 수 있다; 또는 클라이언트 디바이스가 클라이언트 디바이스의 동일한 애플리케이션으로부터 발생한 모든 요청에 대해 동일한 증명 토큰을 사용할 수 있다; 또는 이들의 일부 조합일 수 있다. 각 공개 키의 사용을 제한하면 수신자가 공개 키에 기초하여 상관시킬 수 있는 요청의 양이 제한되고, 애플리케이션 서버가 상환 기록을 소비할 때 보장하는 정도가 증가할 수 있다. 예를 들어, 애플리케이션 서버는 토큰이 오래될수록 클라이언트가 실수로 맬웨어에 토큰을 노출시켰을 가능성이 더 크다고 결정할 수 있다. 이 배치(batch) 접근법을 사용하면 프로세싱할 요청이 줄어들어 디바이스 분석기에 대한 부담을 감소시키고, 네트워크 대역폭 소비를 감소시키고, 클라이언트 디바이스가 증명 토큰이 필요할 때마다 증명 토큰에 대한 요청을 보내는 경우 도입될 증명 토큰을 포함할 요청을 전송하는 경우 클라이언트 디바이스에서의 지연을 감소시킨다.
제2 프라이버시 문제는 클라이언트 디바이스의 안정적인 공개 키를 디바이스 분석기와 공유하면 잠재적으로 디바이스 분석기가 클라이언트 디바이스를 추적할 수 있다는 것이다. 예를 들어, 다수의 개별 증명 토큰의 수신자는 디바이스 분석기가 동일한 디바이스로부터의 동일한 배치 요청에서 해당 증명 토큰을 수신했음을 알 수 있으면, 이러한 토큰의 수신자는 동일한 클라이언트 디바이스에 의해 전송된 다수의 요청을 상관시키고, 상기 상관관계에 기초하여 사용자 데이터를 집계할 수 있다. 수신자는 그러한 데이터를 얻기 위해 디바이스 분석기 데이터 저장소와 공모하거나 위반해야 한다. 이 문서에 설명된 기법은 디바이스 분석기에 공개 키의 원시 값이 아닌 공개 키의 블라인드 버전을 전송함으로써 이러한 추적에 대한 프라이버시를 향상시킬 수 있다. 예를 들어, 클라이언트 디바이스는 N개의 공개-개인 키 쌍의 배치를 생성하고, N개의 공개 키(또는 공개 키의 암호화 해시)를 블라인드화한 다음 N개의 블라인드된 키를 디바이스 분석기에 보낼 수 있다; 서드파티 디바이스 분석기는 클라이언트 디바이스 공개 키의 원시 값을 수신하지 않고 N개의 대응하는 블라인드 서명의 배치를 반환한다.
설명된 증명 토큰은 토큰 내에서 만료 시간을 인코딩하는 어려움을 높이고 토큰의 보안을 높이기 위해 설명된 블라인드 방식으로 인해 제한된 양의 정보만 인코딩할 수 있다. 예를 들어, 제한된 양의 정보가 있는 상태에서 토큰의 수명을 제한하는 한 가지 방법은 토큰을 생성하는데 사용되는 발급 키의 수명 동안에만 각 토큰이 유효하도록 정의하는 것이다.
제한된 콘텐츠 및/또는 리소스를 제공하는 증명 토큰을 요청하는 당사자 또는 사용자가 제한된 콘텐츠 및/또는 리소스에 액세스하는데 사용하는 당사자와 PII가 공유되는 것을 방지하는 토큰 생성 및 상환 프로세스는 데이터 흐름에 액세스하는 리소스 및/또는 콘텐츠의 일부로 기존 시스템과 통합될 수 있다. 이 프로세스는 중개 플랫폼 및 웹 사이트의 기능을 확장하고 사용자 측의 추가 노력 없이 증명 토큰을 요청하는 당사자의 도달 범위를 늘리는 동시에 리소스 및/또는 콘텐츠에 대한 사용자 프라이버시, 경험 및 액세스를 개선한다. 또한 이 프로세스에서 토큰을 요청하는 당사자는 인증되는 사용자가 누구인지 또는 토큰이 어떻게 생성되는지에 대한 어떠한 정보를 수신할 필요가 없다. 수신 당사자는 단순히 특정 리소스 및/또는 콘텐츠에 액세스하려는 사용자 또는 디바이스가 인증되었고, 해당 신원이가 인증된 당사자로 검증되었거나, 특정 레벨에서 신뢰할 수 있음을 나타내는 증명 토큰을 수신한다. 또한 수신 당사자는 요청하는 클라이언트 디바이스/사용자가 올바른 사용자/인증된 사용자인지 확인하기 위해 해당 클라이언트 디바이스/사용자의 신원을 확인한다.
전술한 주제의 다양한 구성 및 이점이 도면과 관련하여 아래에 설명된다. 추가 구성 및 이점은 본 명세서 및 청구 범위에 기술된 주제로부터 명백하다.
도 1a는 디지털 컴포넌트가 배포되는 환경의 블록도이다.
도 1b는 증명 토큰을 요청, 발행 및 상환하기 위한 예시적 프로세스의 데이터 흐름도이다.
도 2는 N개의 증명 토큰들의 배치를 요청하고 수신하기 위한 예시적 프로세스를 도시하는 흐름도이다.
도 3는 증명 토큰을 송수신하고 검증하기 위한 예시적 프로세스를 도시하는 흐름도이다.
도 4는 N개의 블라인드 서명된 증명 토큰의 배치를 요청하고 수신하기 위한 예시적 프로세스를 도시하는 흐름도이다.
도 5는 블라인드 서명된 증명 토큰을 송수신하고 검증하기 위한 예시적 프로세스를 도시하는 흐름도이다.
도 6는 예시적 컴퓨터 시스템의 블록도이다.
다양한 도면들에서 동일한 참조 번호 및 기호는 동일한 컴포넌트를 표시한다.
일반적으로 이 문서에 설명된 시스템 및 기법은 브라우저의 샌드박스 환경 내에서 액세스되는 웹 사이트와 같은 격리된 환경과 클라이언트 디바이스 및 콘텐츠 퍼블리셔와 같은 격리된 환경 외부의 기타 엔터티 간에 보안 통신 채널을 제공할 수 있다. 보안 샌드박스 환경 내에서, 격리된 환경 내에서 코드가 안전하게 실행될 수 있다. 그러나, 환경의 보안을 유지하기 위해, 환경 내부에서 실행되는 코드는 환경 외부의 정보에 액세스하지 못할 수 있다. 예를 들어, 웹 브라우저는 디바이스 및/또는 만들어지는 요청의 진위 여부와 같은 디바이스 레벨 정보에 액세스하지 못할 수 있다. 일부 구현예에서, 웹 브라우저가 별도의 온-디바이스 "디바이스 무결성 검증" 서브시스템이 액세스할 수 있는 동일한 원시 입력 정보에 액세스할 수 있지만, 해당 정보를 디바이스 무결성 판정으로 변환하는 실제 프로세스는 기술적으로 비실용적이거나 브라우저 자체 내에서 복제하기 위해 복제한다. 다음에서 설명하는 시스템 및 기법은 샌드박스 환경 외부에서 샌드박스 환경 내부로의 파이프라인을 제공한다. 이 프로세스는 데이터를 위조할 수 없기 때문에 보안을 보장하고, 데이터를 사용자 활동을 추적하는데 사용할 수 없기 때문에 프라이버시를 보장한다.
클라이언트 디바이스 및/또는 다른 콘텐츠 퍼블리셔 또는 제공자와 같은 외부 엔터티는 네트워크를 통한 요청 및 기타 데이터 전송과 함께 요청의 무결성과 클라이언트 디바이스의 무결성을 승인하기 위해 증명 토큰(또는 상환 토큰에 대한 상환 기록)을 제공할 수 있다. 요청은 예를 들어, 사용자의 데이터를 관리하기 위한 요청(예를 들어, 사용자 관련 데이터를 삭제하기 위한) 및/또는 콘텐츠에 대한 요청 및/또는 리소스에 대한 액세스를 포함할 수 있다. 증명 토큰을 사용하여 통신 채널을 보호하면 격리된 환경이나 증명 토큰이 제공되는 요청 당사자에게 데이터가 누출되는 것을 방지하여 사용자의 프라이버시 및 데이터 보안을 보장한다. 증명 토큰은 클라이언트 디바이스의 인증이 위조될 수 없도록 하고 PII가 전송되지 않도록 사용자 프라이버시가 보존되도록 하는 여러 검증 레이어들을 포함한다. 토큰 자체 대신, 액세스가 요청된 웹 사이트 또는 리소스가 요청되는 위치에 제공되는 보안 신호로서 상환 프로세스 및 서명된 사용 결과의 사용은 토큰이 클라이언트 디바이스/사용자 활동을 추적하거나 사용자의 신원을 결정하는데 사용될 수 없도록 한다.
일부 접근법에서, 증명 토큰은 신뢰 프로그램의 개인 키를 사용하여 디지털 서명될 수 있다. 신뢰 프로그램은 개인 키를 기밀로 유지할 수 있다. 증명 토큰은 무엇보다도 개인 키, 페이로드 및 증명 토큰에 대응하는 공개 키를 포함할 수 있다. 증명 토큰은 신뢰 디바이스 무결성 시스템, 예를 들어 클라이언트 디바이스의 사용자 및 증명 토큰의 수신자와 상이한 엔터티에 의해 유지 관리되는 서드파티 디바이스 무결성 시스템에 의해 결정되는 클라이언트 디바이스의 무결성 레벨을 표시하는 판정을 포함할 수 있다. 증명 토큰은 또한 증명 토큰을 클라이언트 디바이스에 바인딩하기 위해 클라이언트 디바이스의 공개 키(또는 공개 키의 암호해시)를 포함할 수 있다.
증명 토큰은 증명 토큰 발행 서버가 기밀로 유지하는 개인 키를 사용하여 증명 토큰 발행 서버에 의해 디지털 서명될 수 있다. 이 개인 키에 대응하는 공개 키는 수신 시스템에게 제공될 수 있으므로 예를 들어 공개 키를 사용하여 증명 토큰의 디지털 서명을 검증함으로써 클라이언트 디바이스가 증명 토큰 발행 시스템에 의해 평가되었음을 신뢰하도록 할 수 있다. 두 쌍의 키를 사용하는 이 조합은 수신자가 클라이언트 디바이스의 무결성과 클라이언트 디바이스로부터 수신된 통신의 무결성을 승인할 수 있도록 하는 보안 통신 채널을 제공하고, 다른 디바이스가 그 무결성을 위조하기 위해 증명 토큰을 사용할 수 없도록 증명 토큰을 클라이언트 디바이스에 바인딩한다.
일부 접근법에서 증명 토큰 발행 시스템은 증명 토큰에 포함시키기 위해 공개 키의 원시 데이터를 수신하지 않는다. 대신에, 신뢰 애플리케이션은 블라인드 서명 방식을 사용하여 공개 키 또는 그 파생물을 블라인드화함으로써 블라인드 공개 키 또는 공개 키의 블라인드 파생물(예를 들어, 공개 키의 블라인드 절단 암호화 해시)을 보낼 수 있다. 블라인드 서명 방식을 사용하면, 증명 토큰 발행 시스템은 클라이언트 디바이스의 공개 키의 원시 값을 수신하지 않고 클라이언트 디바이스의 무결성을 인증할 수 있으므로, 공개 키를 통한 잠재적인 추적 위험을 줄임으로써 클라이언트 디바이스 또는 사용자의 프라이버시를 강화할 수 있다. 증명 토큰 발행 시스템은 수신자가 블라인드 서명을 검증하는데 사용할 수 있는 블라인드 서명 확인 키를 퍼블리시할 수 있다.
다른 접근법에서, 증명 토큰 발행 시스템을 그룹 관리자로 사용하는 그룹 서명 방식이 사용될 수 있다. 예를 들어, 증명 토큰 발행 서버는 M개의 신뢰도 그룹에 대한 M개의 그룹 검증 키를 퍼블리시하고, M개의 신뢰도 그룹 중 하나에 클라이언트 디바이스를 할당하고, 클라이언트 디바이스에 익명 인증서를 전달할 수 있다. 클라이언트 디바이스는 익명 인증서를 사용하여 증명 토큰에 익명으로 서명할 수 있으며, 이러한 익명 서명은 퍼블리시된 그룹 검증 키를 사용하여 수신자에 의해 검증될 수 있다. 그룹 서명 방식을 사용하면, 증명 토큰 발행 서버나 증명 토큰 수신자가 클라이언트 디바이스의 공개 키 원시 값을 받을 필요가 없으므로, 공개 키를 통한 잠재적 추적 위험을 감소시킴으로써 클라이언트 디바이스 또는 사용자의 프라이버시를 더욱 강화한다.
도 1a 및 도 1b는 증명 토큰을 요청, 발행 및 상환하기 위한 시스템(100) 및 프로세스(190)의 예를 도시한다. 도 1a는 디지털 컴포넌트가 배포되는 환경(100)의 블록도이다. 도 1b는 예를 들어 도 1a에 도시된 환경(100)에서 증명 토큰을 요청, 발행 및 상환하기 위한 예시적 프로세스(190)의 데이터 흐름도이다. 예시적 환경(100)은 근거리 네트워크(LAN), 광역 네트워크(WAN), 인터넷, 모바일 네트워크 또는 이들의 조합과 같은 데이터 통신 네트워크(105)를 포함한다. 네트워크(105)는 클라이언트 디바이스(110), 퍼블리셔(130), 웹사이트(140), 콘텐츠 플랫폼(150), 증명 토큰 발행(ATI) 서버(170)(토큰 발행 시스템으로도 지칭될 수 있음) 및 디바이스 무결성 시스템(180)(디바이스 무결성 컴퓨팅 시스템으로도 지칭될 수 있음)을 연결한다. 예시적 환경(100)은 많은 상이한 클라이언트 디바이스(110), 퍼블리셔(130), 웹사이트(140), 콘텐츠 플랫폼(150) 및 증명 토큰 발행 시스템(170)을 포함할 수 있다.
하나의 특정 예에서, 클라이언트 디바이스의 사용자는 사용자 및/또는 클라이언트 디바이스(110)의 인증을 요청하는 웹사이트로부터 리소스 및/또는 콘텐츠에 액세스하거나 요청을 시도할 수 있다. 도 1a에 도시된 것과 같은 시스템 및 도 1b에 도시된 것과 같은 프로세스는 사용자가 리소스 및/또는 콘텐츠를 액세스하거나 요청할 수 있는 원활한 방식을 제공하는 동시에 리소스 및/또는 콘텐츠를 제공하는 엔터티에 사용자 및/또는 클라이언트 디바이스가 리소스에 액세스하거나 리소스를 요청할 수 있는 권한이 있는 합법적인 사용자라는 확인을 제공한다.
웹사이트(140)는 도메인 이름과 연관된 하나 이상의 리소스(145)이거나 이를 포함하며, 하나 이상의 서버들에 의해 호스팅된다. 예시적 웹사이트는 텍스트, 이미지, 멀티미디어 콘텐츠 및 스크립트들과 같은 프로그래밍 엘리먼트를 포함할 수 있는 HTML 형식의 웹페이지들의 집합이다. 각 웹사이트(140)는 웹사이트(140)를 제어, 관리 및/또는 소유하는 엔터티인 퍼블리셔(130)에 의해 유지관리될 수 있다.
리소스(145)는 네트워크(105)를 통해 제공될 수 있는 임의의 데이터이다. 리소스(145)는 리소스(145)와 연관된 리소스 주소, 예를 들어 URL(Universal Resource Locator)에 의해 식별된다. 리소스는 HTML 페이지, 워드 프로세싱 문서, PDF(portable document format) 문서, 이미지, 비디오 및 피드 소스 등을 포함한다. 리소스는 단어, 문구, 이미지 및 소리와 같은 콘텐츠를 포함할 수 있으며, 내장된 정보(예: 하이퍼링크의 메타 정보) 및/또는 내장된 명령어(예: 스크립트)를 포함할 수 있다.
콘텐츠 플랫폼(150)은 다양한 상이한 비계열 리소스 및/또는 도메인에 대한 액세스를 제공하는 플랫폼이다. 콘텐츠 플랫폼(150)은 서로 또는 콘텐츠 플랫폼(150)과 연관되지 않은 리소스에 대한 액세스를 제공할 수 있다. 예를 들어, 콘텐츠 플랫폼(150)은 비디오 호스팅 플랫폼, 이미지 호스팅 플랫폼, 블로그 등과 같은 다양한 다른 웹사이트로부터의 콘텐츠에 대한 액세스를 제공하는 소셜 미디어 플랫폼일 수 있다. 콘텐츠 플랫폼(150)은 다양한 콘텐츠 퍼블리셔 도메인과 통신 및/또는 통합될 수 있다. 예를 들어, 콘텐츠 퍼블리셔 도메인(160)은 콘텐츠 플랫폼(150)이 액세스를 제공하는 리소스를 포함하는 상이한 웹사이트일 수 있다. 일부 구현예에서, 콘텐츠 퍼블리셔 도메인(160)은 웹사이트(140)와 유사한 상이한 웹사이트일 수 있고, 리소스(145)와 유사한 리소스에 대한 액세스를 제공한다. 예를 들어, 콘텐츠 퍼블리셔 도메인(160-3)은 사용자가 업로드한 이미지에 대한 액세스를 제공하는 이미지 호스팅 웹사이트일 수 있다. 일부 구현예에서, 콘텐츠 플랫폼(150)은 디지털 컴포넌트 요청에 응답하여 디지털 컴포넌트 제공자(160)를 대신하여 디지털 컴포넌트를 선택하는 엔터티인 콘텐츠 퍼블리시 파트너(152)를 통해 리소스에 대한 액세스를 요청하고 제공할 수 있다.
클라이언트 디바이스(110)는 네트워크(105)를 통해 통신할 수 있는 전자 디바이스이다. 예시적 클라이언트 디바이스(110)는 퍼스널 컴퓨터, 모바일 통신 디바이스, 예를 들어, 스마트폰, 디지털 미디어 플레이어, 스마트 스피커, 웨어러블 디바이스(예: 스마트 시계) 및 네트워크(105)를 통해 데이터를 송수신할 수 있는 기타 디바이스를 포함한다. 클라이언트 디바이스(110)는 또한 게임 디바이스 또는 스트리밍 디바이스일 수 있다. 클라이언트 디바이스(110)는 네트워크(105)를 통한 데이터의 송수신을 용이하게 하기 위한 웹브라우저 또는 네이티브 애플리케이션과 같은 애플리케이션(111)을 일반적으로 포함한다. 네이티브 애플리케이션은 특정한 플랫폼 또는 특정한 디바이스용으로 개발된 애플리케이션이다. 퍼블리셔(130)는 네이티브 애플리케이션을 개발하고 클라이언트 디바이스(110)에 제공할 수 있다.
클라이언트 디바이스(110)는 하나 이상의 개인 키(들)(112) 및 하나 이상의 대응하는 공개 키(들)(113)를 포함할 수 있다. 개인 키(들)(112) 및 공개 키(들)(113)는 애플리케이션(111), 신뢰 프로그램(114) 및/또는 클라이언트 디바이스(110) 상의 다른 프로그램에 의해 유지될 수 있다. 클라이언트 디바이스(110)는 개인/공개 키 쌍의 하나 이상의 상이한 세트를 저장할 수 있다. 일부 구현예에서, 개인 키(들)(112) 및 공개 키(들)(113)는 보안 저장소(115)에 저장된다.
클라이언트 디바이스(110)는 또한 사용자 또는 클라이언트 디바이스(110)가 인증된 신뢰 프로그램(114)을 포함할 수 있다. 일부 구현예에서, 신뢰 프로그램(114)은 클라이언트 디바이스(110)의 네이티브 애플리케이션일 수 있다. 예를 들어, 신뢰 프로그램(114)은 디바이스의 운영 체제 또는 클라이언트 디바이스(110)가 인증되는 특정 엔터티와 연관된 클라이언트 디바이스(110)에서 실행하기 위한 애플리케이션일 수 있다.
예를 들어, 신뢰 프로그램(114)은 클라이언트 디바이스(110)로부터의 통신을 보호하는데 사용하기 위해 다른 애플리케이션에 증명 토큰을 발행할 수 있다. 일부 구현예에서, 신뢰 프로그램(114)은 클라이언트 디바이스(110)가 리소스 및/또는 콘텐츠를 요청하고 인증을 요구하는 엔터티에 의해 신뢰된다. 예를 들어, 신뢰 프로그램(114)은 증명 토큰을 요청하는 엔터티에 의해 신뢰되는 프로그램일 수 있다. 일 예에서, 신뢰 프로그램(114)은 애플리케이션(111)을 통해 액세스 가능한 엔터티에 대한 웹 기반 인터페이스일 수 있다. 일부 구현예에서, 신뢰 프로그램(114)은 증명 토큰을 요청하는 엔터티와 연관된다. 예를 들어, 신뢰 프로그램(114)은 Example News Organization에 의해 유지되는 모바일 애플리케이션일 수 있다. Example News Organization은 유료 구독자가 액세스할 수 있는 뉴스 콘텐츠와 모든 방문자가 액세스할 수 있는 뉴스 콘텐츠를 만들고 유지 관리할 수 있다.
증명 토큰 발행(ATI) 서버(170)는 신뢰 프로그램(114)에 의해 요청된 증명 토큰을 생성한다. 신뢰 프로그램(114)은 위조하기 어려운 신뢰할 수 있는 소스로부터의 신뢰 코드를 포함할 수 있다. 일 예시에서, 신뢰 프로그램(114)은 운영 체제, 운영 체제의 일부, 웹 브라우저 등일 수 있다. 일반적으로 신뢰 프로그램(114)은 침투하기 어렵고, 가해자가 신뢰 프로그램(114)을 변조하는데 드는 시간과 노력이 엄청나게 높다. 또한, 신뢰 프로그램(114)은 신뢰할 수 있는 소스에 의해 제공되고 유지되기 때문에 발생하는 모든 취약성은 소스에 의해 해결될 수 있다. 이러한 방식으로 신뢰 프로그램을 사용하면 신뢰 프로그램이 침투하기 어렵기 때문에 클라이언트 디바이스에서 보안이 강화된다는 기술적 이점이 있다. 또한 신뢰 프로그램은 신뢰할 수 있는 소스에서 프로그램을 유지 관리되기 때문에 신뢰 프로그램의 취약성을 완화하는 이점을 제공한다.
신뢰 프로그램(114)은 클라이언트 디바이스(110)에 로컬적일 수 있다. 예를 들어, 신뢰 프로그램(114)은 클라이언트 디바이스(110)의 운영 체제의 디바이스 드라이버일 수 있다. 일부 구현예에서, 신뢰 프로그램(114)은 클라이언트 디바이스(110)에 대해 전체적으로 로컬적으로 동작하여, 사용자 정보를 전송할 필요성을 감소시킨다. 일부 구현예에서, 신뢰 프로그램(114)은 클라이언트 디바이스(110)에 대해 로컬적으로 그리고 네트워크(105)와 같은 네트워크를 통해 동작할 수 있다. 예를 들어, 신뢰 프로그램(114)은 사용자 디바이스(110)에 설치되고 네트워크(105)를 통해 정보를 전송 및 수신하는 모바일 애플리케이션일 수 있다.
신뢰 프로그램(114)은 아래에 더 자세히 설명되는 바와 같이, 암호화 키(예를 들어, 공개/개인 키 쌍)를 생성하고, 보안 저장소(115)(예를 들어, 보안 캐시)에 암호화 키를 저장하고, 보안 저장소(115)에 증명 토큰을 저장하고, 증명 토큰을 생성하고, 암호화 키 및/또는 그 파생물의 블라인드 서명을 생성하고 및/또는 인증서를 가져오고 저장한다. 일부 구현예에서, 신뢰 프로그램(114)은 디바이스 무결성 시스템으로 데이터를 송수신하기 위해 디바이스 무결성 클라이언트와 인터렉션한다. 일부 구현예에서, 신뢰 프로그램(114)은 특정 유형의 요청, 예를 들어 사용자 프라이버시 설정을 변경하기 위한 요청의 세트 각각에 대한 증명 토큰(122)에 대한 요청을 생성하도록 구성된다.
증명 토큰은 요청의 무결성 및 클라이언트 디바이스(110)의 무결성을 승인하기 위해 엔터티에 의해 사용될 수 있다. 예를 들어, 일부 엔터티는 해당 엔터티들이 보통은 액세스를 가지지 않는 데이터에 대한 액세스를 획득하기 위해 예를 들면 콘텐츠가 제공될 상이한 리소스를 특정하기 위해 및/또는 콘텐츠가 제시될 상이한 사용자를 특정하기 위해 리소스 또는 콘텐츠 요청의 파라미터를 위조하려고 시도할 수 있다. 또한 일부 악의적 당사자는 악의적 목적으로 다른 사람의 클라이언트 디바이스를 에뮬레이트하려고 시도할 수 있다.
시스템(100)에 의해 수행되는 프로세스에서, 증명 토큰은 서명된 상환 결과(SRR)를 생성하기 위해 ATI 서버(170)로 상환된다. 서명된 상환 결과는 증명 토큰이 성공적으로 상환되었는지 여부를 나타내지만, 사용자 식별자, 토큰이 생성된 시간, 토큰이 상환된 시간, 신뢰 프로그램(114)에서 제공한 검증 정보 또는 사용자의 다른 PII와 같은 정보는 포함하지 않는다. 서명된 상환 결과는 또한 요청의 무결성 및 클라이언트 디바이스(110)의 무결성을 검증하기 위해 엔터티에 의해 사용될 수 있고, 증명 토큰 대신에 사용될 수 있다. 토큰 상환 및 확인 프로세스를 수행하는 대신 서명된 상환 요청을 검증으로 수락함으로써, 시스템(100)에 의해 수행되는 프로세스는 요청 및 사용자가 인증되었음을 보장하면서 사용자의 프라이버시를 보존한다. 일부 구현예에서, 서명된 상환 결과를 증명 토큰과 함께 사용하여 요청의 무결성을 검증할 수 있다.
이 시스템의 맥락에서, 증명 토큰과 서명된 상환 결과는 모두 엔터티에 의해 사용자가 요청된 콘텐츠 또는 정보와 같은 다른 데이터를 수신하도록 인증되었는지 검증하는데 사용된다. 서명된 상환 결과는 ATI 서버에 의해 서명되며, 요청 사용자를 식별하는 데이터 또는 사용자가 인증된 정도 또는 사용자 인증의 레벨과 같은 기타 정보를 제공하지 않고 사용자가 요청되는 특정 데이터를 수신하도록 인증되었음을 증명한다. 하나의 예에서, 엔터티는 상환을 위해 리소스 제공자에게 증명 토큰을 제공할 수 있고, 리소스 제공자는 증명 토큰을 상환하고, 상환 결과에 서명하고, 결과에 대한 서명은 엔터티에게 증명 토큰이 이전에 성공적으로 상환되었으므로 리소스를 요청하는 사용자는 요청된 리소스를 수신하도록 인증되었다고 알리는데 사용된다.
증명 토큰 및 서명된 상환 결과는 다른 사람이 요청을 변경하는 것을 방지하고 요청이 승인된 클라이언트 디바이스(110) 및 프록시, 인증된 사용자로부터 온 것임을 보장하는 중개자를 통해 클라이언트 디바이스(110)와 컴퓨터 또는 다른 엔터티의 다른 디바이스 사이에 보안 통신 채널을 제공한다.
매우 적은 양의 데이터(예: 2비트)일 수 있는 서명된 상환 결과는 웹 브라우저와 같은 샌드박스 환경과 샌드박스 환경 외부에서 실행되는 애플리케이션 간의 보안 통신 채널을 제공한다. 예를 들어 웹 사이트와 샌드박스 환경 외부에서 실행되는 애플리케이션 간에 전송되는 데이터의 양을 줄이는 것 외에도. 일부 구현예에서, 서명된 상환 결과는 2비트 이상일 수 있다. 예를 들어, 서명은 2비트 이상을 포함할 수 있다. 일부 구현예에서, 상환 결과와 증명 토큰 발행 서비스가 액세스할 수 있는 클라이언트 디바이스의 데이터 사이의 공통 비트 수(즉, "결합 가능한 비트")는 관찰자가 동일한 사용자 또는 디바이스와 증명 토큰 발행 서비스 및 SRR 수신자의 인터렉션을 링크할 수 있는 능력을 감소시키기 위해 제한된다.
예를 들어, 증명 토큰이 증명 서비스와 결합할 수 있는 2비트만 포함하는 경우, 이 제한된 정보량은 상환 결과와 같이 증명 토큰에서 도출된 모든 정보가 최대 2비트를 증명 서비스와 결합할 수 있음을 보장한다. 증명 데이터는 ATI 서버에서 검증 및 상환되기 때문에 웹 브라우저와 웹 브라우저 외부에서 실행되는 애플리케이션 간에 직접 전송되지 않는다. 이 프로세스 때문에, 웹 브라우저 외부에서 실행되는 애플리케이션과 웹 브라우저의 보안 환경 간에 전송되는 데이터는 증명 토큰이 제공하는 것과 동일한 정보(즉, 특정 엔터티 및/또는 요청이 인증되었으며 엔터티의 신원이 성공적으로 증명됨)를 통신하지만 노출이나 가로채기의 위험 없이 프로세스는 사용자의 프라이버시를 보호한다.
ATI 서버(170)는 다른 형식을 갖거나 다른 콘텐츠를 포함하는 다른 유형의 증명 토큰(122)을 생성할 수 있다. 일부 구현예에서, 증명 토큰(122)은 ATI 서버(170)의 공개 키(173), 증명 토큰(122)이 생성된 시간을 표시하는 토큰 생성 시간, 페이로드 데이터 및 클라이언트 디바이스(110)로부터 수신된 데이터를 사용하여 디바이스 무결성 시스템 또는 신뢰 프로그램(114)에 의해 생성된 무결성의 판정을 포함하는 데이터 세트를 포함한다. 증명 토큰(122)은 또한 증명 토큰(122) 및 데이터 세트에 포함된 공개 키(173)에 대응하는 개인 키(172)를 사용하여 ATI 서버(170)에 의해 생성된 디지털 서명을 포함할 수 있다. 즉, ATI 서버(170)는 개인 키(172)를 사용하여 데이터 세트를 디지털 서명할 수 있고, 결과 디지털 서명을 데이터 세트와 함께 증명 토큰(122)에 포함시킬 수 있다. 일부 구현예에서, 증명 토큰은 페이로드 내에 사용자의 자격증명을 포함한다.
도 1a 및 도 1b와 관련하여 기술된 프로세스에서, ATI 서버(170)는 증명 토큰을 생성 및 상환하여, 각 엔터티가 증명 토큰 시스템을 생성 및 유지하도록 요구하지 않고 증명 토큰의 보안 이점을 제공하고 사용자에게 추가적인 프라이버시 이점을 제공한다. 증명 토큰이 생성되는 프로세스는 도 2 내지 도 7을 참조하여 후술된다. 또한, 요청 프로세스는 토큰 상환 프로세스를 포함하기 때문에, 사용자의 PII에 대한 전송 및 액세스를 제한하면서 사용자의 프라이버시를 보호하고 증명 토큰의 이점을 제공하는 검증 데이터만 증명 토큰 시스템이 필요하도록 한다.
일부 구현예에서, 증명 토큰은 보안 조치로서 미리 결정된 기간 내에 만료되도록 설정될 수 있다. 증명 토큰이 만료될 때 증명 토큰을 요구함으로써, ATI 서버(170)는 토큰이 정기적으로 요청되어야 하고 따라서 신원이 증명되는 엔터티가 정기적으로 인증되는 것을 보장할 수 있다.
증명 토큰이 만료되면, ATI 서버(170)의 대응하는 데이터가 업데이트되어 증명 토큰이 나중에 상환될 수 없도록 할 수 있다. 일부 구현예에서, ATI 서버(170)는 토큰을 상환하고 서명된 상환 결과를 생성할지 여부를 결정하기 전에 증명 토큰의 나이와 같은 데이터를 평가한다.
일부 구현예에서, 증명 토큰(122)은 페이로드 데이터를 포함하는 데이터 세트, 증명 토큰(122)이 생성되는 시간을 표시하는 증명 토큰 생성 시간 및 데이터 세트의 디지털 서명을 포함한다. 이 예에서, ATI 서버(170)는 그룹 서명 방식 및 디바이스 무결성 시스템(170) 또는 ATI 서버(170)에 의해 클라이언트 디바이스(110)에 발급된 인증서를 사용하여 디지털 서명을 생성할 수 있다.
일반적으로, 증명 토큰의 수신자는 증명 토큰 및/또는 증명 토큰에 포함된 무결정 판정(적절한 경우)을 승인한다. 증명 토큰이 성공적으로 승인되면, 수신자는 클라이언트 디바이스(110)가 신뢰 디바이스인지 여부를 결정하고, 그에 따라 요청을 프로세싱할 수 있다. 증명 토큰이 성공적으로 승인되지 않은 경우, 수신자는 예를 들어 요청에 응답하지 않거나 또는 요청에 응답하여 데이터를 변경하지 않고 요청을 무시하거나 삭제할 수 있다.
증명 토큰 생성 시간은 증명 토큰(122)이 생성된 시간을 표시한다. 신뢰 프로그램(114)은 신뢰 프로그램(114)이 증명 토큰을 생성할 때 생성 시간을 기록할 수 있다. 이 증명 토큰 생성 시간은 고해상도 타임스탬프일 수 있다(예: 초, 밀리초 또는 마이크로초까지 정확함). 증명 토큰 생성 시간은 증명 토큰(122)을 포함하는 요청(120)이 새로운 요청인지 또는 최근 요청인지를 결정하는데 사용될 수 있다. 예를 들어, 증명 토큰(122)을 수신하는 엔터티는 토큰 생성 시간을 현재 시간 또는 증명 토큰(122)이 수신된 시간과 비교할 수 있다. 두 시간 간의 차이가 임계값을 초과하는 경우, 엔터티는 아래에 자세히 설명된 대로 요청이 새롭지 않거나 유효하지 않다고 결정할 수 있다.
증명 토큰 생성 시간은 재생 공격을 탐지하는데 사용될 수 있다. 예를 들어, 동일한 증명 토큰 생성 시간을 포함하여 동일한 데이터 세트를 가진 다수의 요청이 수신되는 경우, 요청을 수신하는 엔터티는 요청이 중복인지 및/또는 요청이 재생 공격의 일부인지 결정할 수 있다.
증명 토큰 생성 시간은 다른 데이터와 함께 요청에 대한 트랜잭션 식별자 역할을 할 수 있다. 예를 들어, 트랜잭션 식별자는 증명 토큰(122)이 공개 키(113)를 포함하는 구현예에서 증명 토큰(122)의 증명 토큰 생성 시간과 증명 토큰(122)의 공개 키(113) 중 둘 이상의 조합일 수 있다. 트랜잭션 식별자를 사용하여 다수의 채널로부터 수신된 동일한 요청(120)의 여러 버전을 중복 제거할 수 있다. 예를 들어, ATI 서버(170)는 신뢰 프로그램(114) 및 연관 웹사이트(140) 둘 모두로부터 동일한 요청을 수신할 수 있다. 다른 예에서, ATI 서버(170)는 콘텐츠 플랫폼(150)과 콘텐츠 퍼블리싱 파트너(152) 둘 모두로부터 동일한 요청을 수신할 수 있다. 이 예에서, 트랜잭션 식별자는 증명 토큰(122)의 토큰 생성 시간과 증명 토큰(122)의 공개 키(113)에 기초할 수 있다. ATI 서버(170)는 요청이 중복되는지 여부를 결정하기 위해 둘 이상의 요청에서 두 데이터 조각을 비교할 수 있다.
페이로드는 개별 요청(120)에 대한 데이터를 포함할 수 있다. 예를 들면, 페이로드는 요청된 리소스에 관한 정보(예를 들어, 리소스의 주제), 리소스의 컨텍스트에 관한 정보(예를 들어, 슬롯의 수, 슬롯의 유형, 슬롯의 크기 등), 사용자가 이 기능을 활성화한 경우 클라이언트 디바이스(110)에 관한 정보(예: 디바이스의 유형, 디바이스의 IP 주소, 클라이언트 디바이스(110)의 지리적 위치) 및/또는 기타 적절한 정보를 포함할 수 있다.
어느 예에서든, 증명 토큰은 상환될 수 있고, 상환 결과는 애플리케이션(111)이 웹사이트(140)에 제공하는 콘텐츠에 대한 요청에 포함될 수 있어서 웹사이트는 요청이 유효하고 및/또는 승인된 사용자로부터의 것임을 보장하고, 그러나 사용자의 PII에 액세스할 수 없도록 한다. 애플리케이션(111)은 리소스(145)에 대한 액세스를 위해 웹사이트(140)와 같은 콘텐츠 플랫폼(150) 또는 다른 수신자에게 전송된 요청에 SRR을 포함할 수 있다.
요청(120)이 퍼블리셔(130), 콘텐츠 플랫폼(150), 콘텐츠 퍼블리싱 파트너(152), 콘텐츠 퍼블리셔 도메인(160) 또는 다른 엔터티에서 사용자 데이터를 관리하는 것이라면, 요청(120)은 요청된 변경을 특정하는 데이터를 포함할 수 있다. 예를 들어, 사용자가 콘텐츠 퍼블리셔 도메인(160-2)으로부터의 사용자의 모든 데이터를 제거하기로 선택한 경우, 페이로드는 이러한 데이터의 제거 및 콘텐츠 퍼블리셔 도메인(160-2)를 특정하는 데이터(예를 들어, 콘텐츠 퍼블리셔 도메인(160-2)에 대한 식별자 또는 네트워크 주소)를 포함할 수 있다.
디바이스 무결성 시스템(180)은 추가적으로 클라이언트 디바이스(110), 예를 들어 신뢰 프로그램(114)으로부터 수신된 디바이스 레벨 사기 탐지 신호를 평가하고, 디바이스 레벨 사기 탐지 신호에 기초하여 클라이언트 디바이스(110)의 신뢰도(또는 무결성) 레벨을 결정할 수 있다. 디바이스 레벨 사기 탐지 신호는 클라이언트 디바이스가 손상되었는지 여부 또는 클라이언트 디바이스가 일반 클라이언트 디바이스 또는 에뮬레이트된 클라이언트 디바이스로서 작동하는지 여부를 결정하는데 사용될 수 있는 클라이언트 디바이스의 동작 특성 또는 메트릭을 나타내는 데이터를 포함할 수 있다. 특정 동작 특성 및 메트릭은 에뮬레이터에 비해 진짜 클라이언트 디바이스에 대대 종종 상이하다. 일부 구현예에서, 디바이스 레벨 사기 탐지 신호는 증명 토큰을 요청하는 애플리케이션(111)의 동작 특성 및 메트릭을 포함하는 애플리케이션 레벨 사기 탐지 신호들을 포함한다. 신뢰 프로그램(114)은 이러한 디바이스 레벨 사기 탐지 신호를 수집하고 증명 토큰에 대한 요청에 신호를 포함할 수 있다.
디바이스 무결성 시스템(180)은 클라이언트 디바이스(110)의 신뢰도(또는 무결성)의 레벨을 표시하는 판정을 발급할 수 있다. 수신자는 판정을 사용하여, 판정을 포함하는 요청(120)을 신뢰할지 여부를 결정한다. 예를 들어, 판정이 클라이언트 디바이스(110)가 신뢰할 수 없다는 것을 표시하면, 수신자는 요청을 무시할 수 있고, 예를 들어 요청에 응답하지 않을 수 있다.
일부 구현예에서, 도 1 내지 도 7과 관련하여 설명된 바와 같은 프로세스가 수행되어 신뢰 프로그램(114)이 사용자가 인증된 웹사이트이고, 웹사이트(140)가 사용자가 액세스를 요청하거나 사용자가 리소스를 요청하는 프로그램 또는 애플리케이션이도록 한다.
애플리케이션(111)이 특정 리소스(145) 또는 다른 콘텐츠에 대한 액세스를 위해 네트워크(105)를 통해 요청을 보낼 때, 애플리케이션(111)은 사용자의 신원, 진위성 및/또는 승인 상태를 증명하기 위해 프라이버시 보호 기법을 사용할 수 있다. 이 프라이버시 보호 기법을 사용하면 리소스 또는 기타 콘텐츠가 요청되는 웹사이트(140) 또는 애플리케이션(111) 중 하나에 사용자를 식별하거나 추적하는데 사용될 수 있는 정보를 제공하지 않고 증명 토큰이 생성되고 상환되게 할 수 있다. 프라이버시 보호 기법을 수행하기 위한 예시적(190) 프로세스가 도 1b에 도시되어 있다.
단계 A에서, 애플리케이션(111)은 하나 이상의 증명 토큰들에 대한 요청(120)을 생성하고, 토큰 요청(120)을 신뢰 프로그램(114)에 제공할 수 있다. 예를 들어, 애플리케이션(111)은 클라이언트 디바이스(110)의 사용자가 웹사이트(140)와 같은 다양한 웹사이트에 액세스하고 및/또는 다른 엔터티들 중에서도 특히, 리소스(145), 퍼블리셔(130) 및 콘텐츠 플랫폼(150)과 같은 다양한 리소스로부터 콘텐츠에 대한 액세스를 요청하는 웹브라우저일 수 있다. 이 예에서, 신뢰 프로그램(114)은 애플리케이션(111)이 리소스를 요청하거나 애플리케이션(111)이 액세스를 요청하는 엔터티에 의해 신뢰되는 클라이언트 디바이스(110) 상의 애플리케이션일 수 있다. 일 예에서, 신뢰 프로그램(114)은 스마트폰용으로 Example News Organization에 의해 생성되고 호스팅되는 애플리케이션일 수 있고, 사용자는 Example News Organization에 의해 호스팅되는 웹사이트(140) 상의 뉴스 기사에 대한 웹 브라우저(111) 상의 뉴스 수집기를 통해 액세스를 요청할 수 있다.
클라이언트 디바이스(110)의 사용자는 사용자가 신뢰 프로그램에 인증되도록 로그인 자격증명을 신뢰 프로그램(114)에 제공할 수 있다. 예를 들어, 사용자는 Example News Organization 계정의 사용자 이름과 비밀번호를 사용하여 Example News Organization에 로그인할 수 있다. 계정은 무료 계정 또는 유료 구독 계정일 수 있으며, 로그인 자격증명이 없는 사용자는 보기, 액세스 및/또는 수신 권한이 없는 특정 콘텐츠 및/또는 리소스에 대한 추가 권한이 사용자에게 부여될 수 있다. 예를 들어, Example News Organization은 로그인 자격증명이 없는 사용자에게 기사의 특정 서브세트에 대한 액세스를 제공하고, 유료 구독이 없는 계정에 대한 로그인 자격증명이 있는 사용자에게 기사의 더 큰 서브세트에 대한 액세스를 제공할 수 있고, 유료 구독 계정에 대한 로그인 자격증명이 있는 사용자에게 전체 기사 및 콘텐츠 아카이브를 제공할 수 있다.
애플리케이션(111)은 웹사이트(140), 콘텐츠 플랫폼(150) 및/또는 다른 엔터티로부터 증명 또는 무결성 정보에 대한 요청을 수신하지 않고 단계 A를 수행할 수 있다. 예를 들어, 애플리케이션(111)은 증명 토큰을 갱신하기 위해 정기적인 간격으로 증명 토큰 요청(120)을 신뢰 프로그램(114)에 전송할 수 있다. 일부 구현예에서, 증명 토큰은 미리 결정된 기간 후에 만료되어, 증명 데이터가 정확히 남아있음을 보장하고, 서드파티 또는 악의적인 행위자가 권한 없이 증명 데이터에 액세스하고 증명 데이터를 사용할 가능성을 줄일 수 있다. 증명 토큰이 만료되면, 애플리케이션(111)은 만료된 증명 토큰을 삭제하고, 증명 토큰에 대한 요청(120)을 자동으로 생성하고, 신뢰 프로그램(114)에 요청을 제공할 수 있다.
단계 B에서, 신뢰 프로그램(114)은 증명 토큰에 대한 서명된 요청을 생성할 수 있으며, 이를 통해 ATI(증명 토큰 발행) 서버(170)와 같은 토큰 발행 서버가 신뢰 프로그램(114)에 의해 제공된 정보에 기초하여 사용자의 신원을 증명하는 증명 토큰을 생성하게 한다.
예를 들어, Example News Organization에 의해 생성되고 호스팅되는 스마트폰 애플리케이션(114)은 증명 토큰에 대한 요청(121)을 생성하고, ATI 서버(170)에 요청을 제공할 수 있다. 이 요청은 요청에 관한 무결성 정보를 나타내기 위해 Example News Organization 애플리케이션(114)에 의해 서명될 수 있다. 예를 들어, 요청은 로그인 자격증명 및/또는 로그인 자격증명의 유형(즉, 무료 계정, 첫 번째 티어 유료 구독 계정, 공유 가족 요금제 계정 등)을 갖는 사용자를 대신하여 이루어지는지 여부를 표시하기 위해 Example News Organization 스마트폰 애플리케이션(114)에 의해 서명될 수 있다. 일부 구현예에서, 요청에 대한 서명은 요청 및/또는 엔터티가 인증되었는지 여부에 대한 판정을 제공할 수 있다. 예를 들어, Example News Organization 애플리케이션은 요청이 합법적인지 및/또는 사용자가 유효한 자격증명을 사용하여 애플리케이션을 통해 Example News Organization에 인증되었는지 결정할 수 있다. 그러면 Example News Organization 애플리케이션(114)은 요청(121)과 함께 인증의 판정을 포함할 수 있다.
일부 구현예에서, 요청(121)은 요청(121)을 생성하기 위해 애플리케이션(111)으로부터의 요청(120)을 사용하여 신뢰 애플리케이션(114)에 의해 생성된 새로운 요청이다. 일부 구현예에서, 요청(120)은 요청 및/또는 사용자의 유효성을 나타내기 위해 신뢰 애플리케이션(114)에 의해 서명되고, 서명된 요청(120)은 요청(121)으로서 전송된다. 일부 구현예에서, 요청(120) 및 신뢰 애플리케이션(114)에 의해 제공되는 유효성 정보는 요청(121)으로서 함께 전송된다.
애플리케이션(111)이 증명 토큰을 직접 요청하지 않기 때문에 애플리케이션(111)은 증명 토큰에 대한 요청에 포함된 정보에 대한 액세스를 요구하지 않으므로, 사용자의 PII에 대한 액세스 없이 특정 리소스에 대한 액세스 및/또는 콘텐츠 전달을 용이하게 할 수 있다. 이를 통해 사용자의 프라이버시를 보호하는 원활한 방식으로 증명 프로세스가 수행될 수 있다. 도 1a 및 도 1b의 단계 C-I와 관련하여 아래에서 설명되는 바와 같이, 비록 애플리케이션(111)이 증명 토큰을 수신, 저장 및 상환할 수 있지만, 애플리케이션(111)은 사용자가 애플리케이션(111)에 액세스 권한을 부여한 PII외에 사용자가 신뢰 프로그램(114)에 제공한 PII를 직접 수신하거나 액세스하지 않는다. 따라서, 사용자의 프라이버시를 보호하는 것 외에도, 설명된 증명 토큰 생성 및 상환 프로세스는 추가로 애플리케이션(111)이 사용자로부터 PII 정보를 요구하지 않고 콘텐츠 수집과 같은 기능을 제공하게 할 수 있다. 이 프로세스는 시스템의 기능을 향상시켜, 보다 안전한 정보 흐름을 생성하고 사용자에게 필요한 입력의 양을 감소시킨다.
도 1a 및 도 1b와 관련하여 설명된 바와 같은 프로세스는 신뢰 체인에서 두 단계를 제공하는 두 개의 서로 다른 서명 세트를 포함한다. 증명 토큰 발행자는 증명 토큰 및/또는 서명된 상환 결과에 서명하고, 웹 브라우저는 웹사이트 및/또는 리소스의 일부에 액세스하기 위한 요청에 서명을 포함한다.
위에서 논의된 바와 같이, 일부 접근 방식에서, 신뢰 프로그램(114), 애플리케이션(111), 또는 클라이언트 디바이스(110)는 증명 토큰 요청(및 디바이스 공개 키와 연관된 디바이스 무결성 판정)과 함께 하나 이상의 개인/공개 키 쌍을 포함할 수 있다. 일부 구현예에서, 개인/공개 키 쌍은 여러 증명 토큰에 걸쳐 변경될 수 있어서, 증명 토큰 수신자에 의한 추적에 대해 클라이언트 디바이스 또는 사용자의 프라이버시를 향상시킬 수 있다. 예를 들어, 클라이언트 디바이스는 개인/공개 키 쌍의 배치를 생성하고 증명 토큰 발행 서버로부터 증명 토큰의 대응하는 배치를 검색하여, 증명 토큰의 재사용을 줄이거나 제거할 수 있다. 이러한 배치 프로세스의 예시가 도 2에 도시되어 있다.
단계 C에서, ATI 서버(170)는 증명 토큰을 발행한다. 이 토큰 발행 단계는 많은 상이한 부분을 포함할 수 있다. 일반적으로, ATI 서버(170)는 요청하는 클라이언트 디바이스 및/또는 사용자의 신원을 증명하는 매우 적은 수의 비트를 운반하는 증명 토큰을 발행한다. 증명 토큰을 발행하기 전에, ATI 서버(170)는 웹사이트(140), 리소스(145), 콘텐츠 퍼블리셔 도메인(160) 및/또는 SRR이 제공되는 임의의 다른 엔터티에 대한 추가 보안 레이어를 제공하여 요청이 유효한지 검증할 수 있다.
예를 들어, ATI 서버(170)는 요청(121)에 대한 서명을 검증할 수 있다. 일부 구현예에서, 위에서 설명된 바와 같이, 신뢰 프로그램(114)은 요청(121)에 대한 블라인드 서명을 제공할 수 있다. 일부 구현예에서, 증명 토큰 발행 서버는 증명 토큰에 포함시키기 위해 공개 키의 원시 데이터를 수신하지 않는다. 대신에, 클라이언트 디바이스는 블라인드 서명 방식을 사용하여 공개 키 또는 그 파생물을 블라인드화함으로써 블라인드 공개 키 또는 공개 키의 블라인드 파생물(예를 들어, 공개 키의 블라인드 절단 암호화 해시)을 보낼 수 있다. 블라인드 서명 방식을 사용하면, 증명 토큰 발행 서버는 클라이언트 디바이스의 공개 키의 원시 값을 수신하지 않고 클라이언트 디바이스의 무결성을 인증할 수 있으므로, 공개 키를 통한 잠재적인 추적 위험을 줄임으로써 클라이언트 디바이스 또는 사용자의 프라이버시를 강화할 수 있다. 증명 토큰 발행 서버는 수신자가 블라인드 서명을 검증하는데 사용할 수 있는 블라인드 서명 확인 키를 퍼블리시할 수 있다.
ATI 서버(170)가 요청의 유효성을 검증하면, ATI 서버(170)는 신뢰 프로그램(114) 및/또는 신뢰 프로그램(114)과 연관된 엔터티와 관련된 클라이언트 디바이스(110) 및/또는 사용자의 신원을 증명하는 증명 토큰(122)을 발행할 수 있다.
단계 C에서 발행된 증명 토큰(들)의 수는 단계 A 및/또는 단계 B에서 요청된 증명 토큰의 수에 직접적으로 대응할 수 있다. 예를 들어, 애플리케이션(111)은 단계 A에서 5개의 증명 토큰을 요청할 수 있고, 신뢰 프로그램(114)은 5개의 증명 토큰에 대한 요청을 ATI 서버(170)에 제공한다. 요청 및/또는 발행될 증명 토큰의 수는 애플리케이션(111), 신뢰 프로그램(114), 클라이언트 디바이스(110) 및/또는 ATI 서버(170)에 의해 결정될 수 있다.
일부 구현예에서, ATI 서버(170)는 요청된 증명 토큰의 수로부터 발행된 증명 토큰의 수를 변경할 수 있다. 예를 들어, ATI 서버(170)는 다양한 소스로부터 요청된 증명 토큰의 평균 수에 기초하여, 요청에 응답하여 발행할 증명 토큰의 수를 자동으로 결정할 수 있다. ATI 서버(170)는 보안과 트래픽 감소의 균형을 조정함으로써 요청에 대한 응답으로 발행할 증명 토큰의 수를 결정할 수 있다: 더 많은 토큰을 발행하면 토큰을 요청하고 발행해야 하는 횟수가 줄어들지만, 요청의 유효성 및 애플리케이션(111)의 사용자의 신원이 검증되는 빈도가 감소한다.
일부 구현예에서, C 단계에서 발행된 증명 토큰의 수는 발행될 수 있는 최대 증명 토큰 수에 따라 다르다. 예를 들어, 증명 토큰 수신자는 (1) 선택된 시간 프레임 내에 각 개별 클라이언트 디바이스 또는 애플리케이션으로부터 수신자의 선택된 목적지 도메인으로 보낼 수 있는 토큰 수에 대한 제한(예: Y초, 분 또는 시간 내 요청 X개 이하); (2) 선택된 시간 프레임 내에 개별 클라이언트 디바이스의 하나 이상의 선택된 애플리케이션으로부터 수신자의 선택된 목적지 도메인으로 보낼 수 있는 토큰 수에 대한 제한(예: Y초, 분 또는 시간 내 애플리케이션 A로부터 또는 애플리케이션 A가 아닌 임의의 애플리케이션으로부터 요청 X개 이하); (3) 선택된 시간 프레임 내에 개별 클라이언트 디바이스로부터 수신자의 선택된 목적지 도메인 내에 선택된 엔드포인트로 보낼 수 있는 토큰 수에 대한 제한; (4) 선택된 시간 프레임 내에 클라이언트 디바이스 상의 하나 이상의 선택된 애플리케이션으로부터 선택된 목적지 도메인 내의 선택된 엔드포인트로 보낼 수 있는 토큰 수에 대한 제한; 또는 (5) 그러한 제한 중 둘 이상의 조합을 퍼블리시할 수 있다.
증명 토큰(122) 자체는 베어러가 인증되었는지 여부를 나타내는 단일 비트의 정보일 수 있다. 예를 들어, 값 0은 베어러가 인증되지 않았음을 나타낼 수 있고 값 1은 베어러가 인증되었음을 나타낼 수 있다.
ATI 서버(170)가 애플리케이션(111)에 발행하는 응답은 증명 토큰(122) 자체를 포함할 수 있고, 추가로 1개 이상의 암호화된 정보 비트를 포함할 수 있다. 일부 구현예에서, 정보의 추가 비트(들)는 증명 토큰(122)에 포함될 수 있어서, 증명 토큰(122)이 베어러가 인증되었는지 여부를 나타내는 1비트 및 추가 정보의 1비트 이상을 포함하도록 한다. 예를 들어, 발급시, ATI 서버(170)는 검증된 사용자 자격증명 또는 기타 데이터와 같이 애플리케이션(111)의 보안 샌드박스 환경 외부로부터 애플리케이션(111)의 보안 샌드박스 환경 내부로 전달될 1비트의 개인 메타데이터를 포함할 수 있다.
ATI 서버(170)는 추가로 다수의 개인 서명 키를 사용하여 증명 토큰에 서명할 수 있다. ATI 서버(170)에 의해 사용가능하게 된 대응하는 검증 키를 사용하여 검증될 수 있는 이러한 개인 서명 키는 신뢰 체인의 일부인 서명의 역할을 한다. 증명 토큰의 수신자가 ATI 서버(170)에 의해 제공되는 대응하는 검증 키를 사용하여 서명 키를 검증할 수 있는 경우, 수신자는 ATI 서버(170)가 증명 토큰을 발행했다고 신뢰할 수 있다. 증명 토큰에 서명하는 이 프로세스는 예를 들어 블라인드 서명 방식을 사용하여 수행될 수 있으므로 증명 토큰 발행 서버가 클라이언트 디바이스의 공개 키 원시 데이터를 볼 수 없도록 한다. 예를 들어, 클라이언트 디바이스는 개인/공개 키 쌍의 배치를 생성한 다음 증명 토큰의 대응하는 배치를 검색하기 위해 공개 키를 증명 토큰 발행 서버에 보내기 전에 블라인드 서명 방식을 사용하여 공개 키를 블라인드화할 수 있다(또는 공개 키의 암호화 해시 또는 디바이스 모델 번호와 연결된 공개 키의 암호화 해시와 같이 블라인드 서명 방식의 커밋 페이즈에 대한 값으로 사용될 수 있는 이들 공개 키의 적절한 파생물). 이 예에서, 증명 토큰은 공개 키를 사용하여 블라인드로 서명된다. 이러한 배치 프로세스의 예시가 도 4에 도시되어 있다.
추가적으로, ATI 서버(170)는 ATI 서버(170)에 의해 사용 가능하게 된 대응하는 검증 키와 함께 다수의 개인 서명 키를 사용하여, 단계 C에서 증명 토큰에 서명하는 것과 관련하여 위에서 설명된 프로세스와 유사한 프로세스에서 SRR에 서명할 수 있다.
n개의 검증 키와 단일 정보 비트의 조합은 n*2개의 다른 조합을 제공하고, 이러한 조합은 애플리케이션(111)에서 검증 가능한 소량의 정보를 토큰으로 추가로 암호화한다. 암호화된 정보의 양은 추가 정보가 토큰으로 암호화되지 않았음을 보장하기 위해 웹 브라우저와 같은 애플리케이션(111)에 의해 검증 가능하며, 이는 암호화의 결과가 암호화된 비트 수를 나타낼 것이기 때문이다. 애플리케이션(111)이 추가 데이터가 증명 토큰으로 암호화되었다고 결정하면 애플리케이션(111)은 토큰을 저장하거나 이를 상환할 필요가 없다. 예를 들어, 애플리케이션(111)이 토큰을 저장하기 전에 증명 토큰을 검증하는 경우, 애플리케이션(111)은 단순히 토큰을 폐기할 수 있다. 예를 들어, 애플리케이션(111)이 상환 전에 증명 토큰을 검증하는 경우, 애플리케이션(111)은 토큰을 폐기하고 토큰 상환 시도를 자제할 수 있다.
예를 들어, ATI 서버(170)가 예상된 비트 수보다 많은 비트를 증명 토큰으로 암호화하려고 시도하는 경우, 증명 토큰은 애플리케이션(111)에 의해 수행된 검사에 실패할 것이다. 애플리케이션(111)은 예를 들어 ATI 서버(170)에 의해 제공되는 공개 키 및/또는 검증 키를 주기적으로 확인할 수 있다. 애플리케이션(111)은 그 다음 ATI 서버(170)의 디지털 서명을 검증하기 위해 공개 키를 사용할 수 있다. 그러나 검증 키 중 어느 것도 증명 토큰을 검증하지 않으면 애플리케이션(111)은 토큰을 상환하려고 시도하지 않고 증명 토큰을 폐기할 수 있다.
단계 D에서, 애플리케이션(111)은 ATI 서버(170)로부터 수신된 증명 토큰(들)을 저장한다. 예를 들어, 애플리케이션(111)은 ATI 서버(170)로부터 증명 토큰(122)을 수신한 다음 보안 저장소에 토큰을 저장한다. 예를 들어, 애플리케이션(111)은 애플리케이션(111) 또는 클라이언트 디바이스(110)에 의해 유지되는 보안 캐시에 증명 토큰(122)을 저장할 수 있다.
단계 E에서, 증명 토큰 상환을 위한 트리거 이벤트가 발생한다. 일부 구현예에서, 웹사이트(140)는 액세스를 제공하거나 리소스를 전송하기 전에 애플리케이션(111)으로부터 검증을 요청할 수 있다. 예를 들어, 클라이언트 디바이스(110)의 사용자가 Example Social Media Website(140)의 프로필에 맞춤 배경을 추가하기 위해 기능에 액세스하려고 시도하는 경우, Example Social Media Website(140)는 해당 기능에 대한 액세스를 허용하기 전에 애플리케이션(111)으로부터 검증을 요청할 수 있다. 일부 구현예에서, 애플리케이션(111)은 사용할 SRR의 저장소를 생성하기 위해 증명 토큰을 자동으로 상환할 수 있다. 예를 들어, 애플리케이션(111)의 사용자는 매일 오전 7시에 작업하기 전에 예시 Example News Aggregation Website(140)에 액세스하는 패턴을 가질 수 있고, 애플리케이션(111)은 기사가 Example News Aggregation Website(140)에 보여지는 다양한 Example News Website(140a, 140b, 140c)에 대한 증명 토큰을 자동으로 상환할 수 있다.
사용자의 프라이버시를 보호하기 위해, 시스템(100)은 ATI 서버(170) 자체에 대한 토큰의 세부 사항을 비공개로 유지하면서 사용자의 신원을 증명하는, 증명 토큰이 상환될 수 있게 하는 토큰 상환 프로세스를 구현한다. 토큰 상환 프로세스는 애플리케이션(111)에 의해 증명 토큰을 상환하기 위한 요청을 생성하는 것을 포함한다. 토큰 상환 요청 및 증명 토큰은 서명된 상환 결과(SRR)를 생성하는 ATI 서버(170)에 제공된다. 증명 토큰이 성공적으로(또는 비성공적으로) 상환되지 않았음을 나타내고 사용자의 PII 또는 상환 또는 사용 패턴을 추적하는데 사용될 수 있는 정보를 제공하지 않는 이 서명된 상환 결과는 토큰 상환 요청에 응답하여 애플리케이션(111)에 제공된다. 그 다음, 애플리케이션(111)은 사용자의 신원 및/또는 요청의 진위를 증명하기 위해 웹사이트(140)로부터 리소스 또는 다른 콘텐츠에 액세스하기 위한 요청에 SRR을 포함할 수 있다. SRR은 증명 토큰이 아니라 웹사이트(140)에 제공되기 때문에, 웹사이트(140)는 사용자가 리소스에 액세스할 수 있는 권한 및/또는 사용자의 PII에 대한 액세스 권한 없이 콘텐츠를 수신할 수 있는 권한이 있다는 확신을 가질 수 있다.
일부 구현예에서, ATI 서버(170)는 특정 발행자에 대한 임의의 유효한 증명 토큰이 있는지 여부를 결정한다. 주어진 발행자에 대해 사용 가능한 토큰이 없는 경우, ATI 서버(170)는 오류와 함께 요청을 거부한다. 주어진 발행자에 대해 사용 가능한 토큰이 있는 경우, ATI 서버는 요청 엔터티에 증명 토큰을 발행한다. 발행자는 토큰을 소비하고 신원이 증명되는 엔터티의 자격증명이나 사용자 정보를 노출하지 않고 상환 증명이 다른 당사자에게 전달될 수 있도록 SRR 응답 헤더를 포함하여 결과에 기초하여 동작할 수 있다. 추가로, 발행자는 상환 기록이 얼마나 오래(예를 들어, 초 단위로) 캐시되어야 하는지를 나타내기 위해 증명 토큰 및/또는 SRR 내에 정보를 포함할 수 있다. 일부 구현예에서, 정보가 포함되지 않은 경우, SRR의 수명은 상환된 토큰의 발행을 확인하는 증명 토큰 정보의 수명과 연결된다. 일부 구현예에서, SRR은 발행자의 임의의 바이트 덩어리로 취급된다.
토큰 상환 프로세스 및 SRR을 사용하여 요청 및/또는 사용자를 인증하는 프로세스는 또한 애플리케이션(111)의 샌드박스 환경 외부로부터 샌드박스 환경으로 정보를 전송하기 위한 보안 메커니즘을 제공한다. 전통적으로, 웹브라우저와 같은 애플리케이션(111)의 경우, 애플리케이션은 샌드박스 환경 내에서 실행되고 보안 환경을 제공하기 위해 다른 엔터티 및 정보로부터 격리된다. 도 1 내지 도 8에 대해 설명된 시스템 및 프로세스는 샌드박스의 보안을 유지한다.
또한 SRR의 수신자는 토큰의 검증 및 상환을 수행하지 않기 때문에, SRR의 수신자는 증명 토큰 정보와 같은 정보를 요청하거나 프로세싱할 필요가 없다. 이것은 사용자가 신뢰 프로그램(114)에 자격증명을 제공했을 때 추가 정보를 요청하지 않고, 증명 토큰이 애플리케이션(111)의 사용자에게 발행될 수 있기 때문에, 프로세스가 사용자의 프라이버시를 보호하고 전송되는 데이터의 보안을 개선할 수 있도록 한다.
일부 구현예에서, ATI 서버(170)는 신뢰 프로그램(114), 웹사이트(140), 콘텐츠 플랫폼(150) 및/또는 하나 이상의 콘텐츠 퍼블리셔 도메인(160)과 연관된다. 예를 들어, ATI 서버(170)는 Example News Organization 모바일 애플리케이션(114) 및 Example News Organization 웹사이트를 운영하는 Example News Organization에 의해 유지될 수 있다. 일부 구현예에서, ATI 서버(170)는 신뢰 프로그램(114), 웹사이트(140), 콘텐츠 플랫폼(150) 및/또는 하나 이상의 콘텐츠 퍼블리셔 도메인(160)과 별개의 엔터티이고, 증명 토큰을 프로세싱하기 위한 인프라를 개발할 필요가 없다. 예를 들어, ATI 서버(170)는 사용자가 신뢰할 수 있는 증명 토큰 발행 시스템으로서 액세스를 얻으려고 시도하는 웹사이트(140)에 의해 지정된 서버일 수 있다. 웹사이트(140)는 증명 토큰을 프로세싱하기 위한 인프라를 개발하거나 유지할 필요가 없으며, 대신 ATI 서버(170)로부터 서명된 상환 결과를 수락한다. 도 1a 내지 도 1b에 대해 설명된 시스템 및 프로세스는 웹사이트, 콘텐츠 퍼블리셔, 기타 콘텐츠 제공자 및 리소스가 요청이 진짜인지 및/또는 사용자가 토큰이 요청, 생성 및/또는 상환되는 방법을 알 필요 없이 콘텐츠에 액세스/수신할 권한이 있는지 검증할 수 있다.
예를 들면, 애플리케이션(111)이 다른 엔터티(예를 들어, 퍼블리셔(130), 콘텐츠 플랫폼(150), 콘텐츠 퍼블리싱 파트너(152) 또는 콘텐츠 퍼블리셔 도메인(160))에게 해당 엔터티에 의해 저장된 데이터를 관리, 예를 들어 삭제하라는 요청을 보내는 경우, 이 요청은 증명 토큰(122)을 포함할 수 있다.
일부 구현예에서, 애플리케이션(111)은 특정 유형의 요청에 SRR들을 자동적으로 송신하도록 구성된다. 예를 들어, 증명 토큰을 요청하고 SRR들을 송신하는 각 애플리케이션(111)은 애플리케이션(111)이 증명 토큰에 액세스 및/또는 상환하고, SRR들을 액세스 및/또는 송신하게 하는 소프트웨어 개발 키트(SDK) 또는 애플리케이션 프로그래밍 인터페이스(API)를 포함할 수 있다. API는 SRR이 포함될 요청들의 세트, 예를 들어 사용자 데이터를 관리하기 위한 요청, 사용자가 승인을 필요로 하는 리소스 및/또는 콘텐츠에 대한 액세스 요청 등을 지정할 수 있다. 예를 들어, 유료 가입자를 위한 뉴스 웹 페이지 요청과 같은 콘텐츠 또는 특정 리소스에 대한 액세스에 대한 특정 유형의 요청에는 SRR이 필요할 수 있다.
단계 F에서, 애플리케이션(111)은 ATI 서버(170)에 토큰 상환 요청(123)을 송신한다. 토큰을 발행한 ATI 서버(170)로 토큰을 상환하는 이 단계는 증명 토큰 대신에 SRR이 제공되게 한다. 증명 토큰의 발행 및 상환과 연관된 데이터는 사용자 활동을 추적하기 위해 추적가능한 신호로서 사용될 수 있고, 다른 정보 중에서도 특히, 토큰이 상환되었다는 컨텍스트, 토큰이 상환된 시간 및/또는 토큰이 발행되기 전에 제공된 인증 정보와 같은 서명된 상환 결과는 SRR의 베어러가 증명 토큰을 성공적으로 상환했다는 정보만 제공하고, 잠재적으로 민감한, 식별가능한 또는 추적가능한 정보를 제공하지 않는다.
애플리케이션(111)은 토큰 상환 요청(123)과 함께 상환을 위한 증명 토큰을 나타내는 데이터를 전송한다. 일부 구현예에서, 토큰 상환 요청(123)은 상환을 위한 증명 토큰을 포함한다. 일부 구현예에서, 애플리케이션(111)은 토큰 상환 요청(123)과 함께 증명 토큰을 전송한다. 일부 구현예에서, 애플리케이션(111)은 증명 토큰의 성공적인 발행을 나타내는 데이터를 클라이언트 디바이스(110)의 사용자에게 전송한다.
상환 시간에, ATI 서버(170)가 토큰 상환 요청(123)을 수신할 때, ATI 서버(170)는 또한 증명 토큰을 수신한다. 증명 토큰이 합법적이고 검증 가능한 경우, 증명 토큰은 ATI 서버(170)가 이전에 발행하고 애플리케이션(111)에 의해 저장되었던 토큰이다. ATI 서버(170)는 토큰 상환 요청(123)과 함께 증명 토큰을 수신하고, 정보 비트와 암호화 키의 가능한 조합 중 하나를 추출한다. 위에서 설명한 비트는 증명 토큰의 베어러가 검증되었는지 여부를 나타낸다. 일부 구현예에서, 사용 가능한 여러 개의 다른 암호화 키가 증명 토큰 및 인증 레벨에 관한 추가 정보를 제공할 수 있다. 예를 들어, 다른 공개 키는 다른 레벨의 권한 또는 다른 레벨의 인증을 나타낼 수 있다. 일부 구현예에서, 토큰 정보는 저장 전에 애플리케이션(111)에 의해 검증되고, 토큰이 ATI 서버(170) 자체에 의해 발행되었음을 검증하고 애플리케이션(111)이 토큰을 수정하지 않았음을 보장하기 위해 상환 이전에 ATI 서버(170)에 의해 검증될 수 있다.
단계 G에서, ATI 서버(170)는 서명된 상환 결과(124)를 생성하고 애플리케이션(111)에 전송한다. ATI 서버(170)가 토큰 상환 요청(123)에 표시된 증명 토큰이 유효하고 및/또는 ATI 서버(170) 자체에 의해 발행되었음을 검증하면, ATI 서버(170)는 상환 결과를 생성하고 서명할 수 있다. ATI 서버(170)로부터의 서명은 신뢰 체인에 추가 링크를 추가하고, 서명된 상환 결과의 수신자가 사용자의 활동 또는 신원을 추적하는데 사용될 수 있는 추가 정보를 수신자에게 제공하지 않고 증명 토큰이 ATI 서버(170)로 상환되었음을 신뢰할 수 있게 한다.
ATI 서버(170)는 예를 들어, 증명 토큰과 연관된 하나 이상의 디지털 서명이 위조되지 않았는지 검증함으로써 토큰 상환 요청(123)에 표시된 증명 토큰을 검증한다. 예를 들어, ATI 서버(170)는 ATI 서버(170) 자체가 단계 C에서 설명된 바와 같이 증명 토큰에 서명한 하나 이상의 디지털 서명이 위조되지 않았는지 검증할 수 있다. ATI 서버(170)는 자신의 개인 키를 사용하여 증명 토큰을 복호화함으로써 이 검사를 수행할 수 있다.
일부 구현예에서, ATI 서버(170)는 예를 들어, 토큰 상환 요청(123)이 적법하다는 것을 보장하기 위해 애플리케이션(111)으로부터의 하나 이상의 디지털 서명이 위조되지 않았는지 검증할 수 있다. 예를 들어, ATI 서버(170)는 서명 데이터를 애플리케이션(111)에 의해 공개된 하나 이상의 공개 키와 비교할 수 있다. 일부 구현예에서, 디지털 서명은 단순히 요청이 애플리케이션(111)에 의해 생성되었음을 나타내는 토큰 상환 요청(123)과 함께 제공된 메타데이터일 수 있다.
일부 구현예에서, ATI 서버(170)는 다른 메트릭 및 특성 중에서 상환 시간, 상환을 위한 컨텍스트 및/또는 증명 토큰이 발행된 시간과 같은 추가 토큰 데이터를 검증할 수 있다. 일부 구현예에서, ATI 서버(170)는 특정 유형의 증명 토큰이 상환될 수 있는 특정 컨텍스트를 식별할 수 있고, 현재 컨텍스트가 증명 토큰이 상환될 수 있는 유효한 컨텍스트인지 여부를 검증할 수 있다. 예를 들어, ATI 서버(170)는 가입자 전용 낱말 게임에 액세스하기 위한 증명 토큰이 낱말 게임에 액세스하려고 시도할 때만 상환될 수 있다는 정보를 특정 웹사이트(140)로부터 수신할 수 있다. 그러나, 토큰 상환 요청(123)은 가입자 전용 낱말 게임에 액세스하려는 시도가 있었음을 나타내는 데이터 없이 구독자 전용 낱말 게임에 액세스하기 위한 증명 토큰이 상환되고 있음을 나타낼 수 있다. 그러면 ATI 서버(170)는 상환에 대한 컨텍스트가 충족되지 않는다고 결정할 수 있고, 다른 액션들 중에서 거부 또는 성공하지 못한 상환 표시를 전송하고, 증명 토큰을 무효화하고 및/또는 단순히 토큰 상환 요청에 응답하지 않음으로써 토큰 상환 요청을 거부할 수 있다.
일부 구현예에서, ATI 서버(170)는 토큰 상환 요청(123)이 수신된 시간에 증명 토큰이 만료되었는지 여부를 결정할 수 있다. 예를 들어, ATI 서버(170)는 증명 토큰과 연관된 생성 시간에 기초하여, 증명 토큰이 얼마나 오랫동안 미해결 상태였는지, 그리고 증명 토큰이 만료되었는지 여부를 결정할 수 있다. 일 예에서, ATI 서버(170)는 연구 데이터베이스에 대한 검색을 수행하기 위한 액세스를 위한 증명 토큰이 상환되기 위해서는 25분 미만이어야 한다고 결정할 수 있다. 나중에, ATI 서버(170)가 1주일이 지난 연구 데이터베이스에 대한 검색을 수행하기 위한 액세스를 위한 증명 토큰을 나타내는 토큰 상환 요청(123)을 수신하는 경우, ATI 서버(170)는 증명 토큰이 만료되었다고 결정할 수 있고, 다른 액션들 중에서 거부 또는 성공하지 못한 상환 표시를 전송하고, 증명 토큰을 무효화하고 및/또는 단순히 토큰 상환 요청에 응답하지 않음으로써 토큰 상환 요청을 거부할 수 있다. 증명 토큰의 만료 기간은 10초, 15분, 3시간, 6일, 2주 등과 같이 임의의 시간이 될 수 있다.
ATI 서버(170)가 증명 토큰 및/또는 토큰 상환 요청의 검증을 완료하면, ATI 서버(170)는 서명된 상환 결과를 생성한다. SRR(124)은 증명 토큰이 성공적으로 상환되었는지 여부를 나타내는 데이터를 포함하며, 사용자 활동을 추적하거나 상환된 증명 토큰을 생성하는데 사용된 자격증명과 연관된 사용자를 식별하는데 사용될 수 있는 추가 데이터는 포함하지 않는다.
증명 토큰이 성공적으로 상환되었는지 여부만 표시하는 서명된 상환 결과를 생성하는 프로세스는 서명된 상환 결과의 수신자에 대한 보안과 서명된 상환 결과가 생성된 사용자에 대한 프라이버시를 보장한다.
예를 들어, 서명된 상환 결과를 생성하고 서명된 상환 결과를 증명 토큰을 제공하는 대신 웹사이트(140)에 제공함으로써, 웹사이트(140)는 증명 토큰에 대한 원래 요청을 추적하고 증명 토큰을 특정 사용자와 상관시킬 수 없다. 도 4에 대해 아래에 설명된 바와 같이, 증명 토큰이 블라인드 서명 방식을 사용하여 서명되었기 때문에, 토큰을 발행한 ATI 서버(170)는 ATI 서버(170) 자체가 토큰에 서명했고 토큰이 수정 및/또는 이전에 상환되지 않았다는 것만 검증할 수 있다. ATI 서버(170)는 언제 증명 토큰이 서명되었는지 또는 임의의 추가 파라미터가 증명 토큰에 대한 초기 요청과 연관되었는지 확인할 수 없으므로, 증명 토큰을 요청하는 사용자의 프라이버시를 보호한다.
단계 H에서, 애플리케이션(111)은 SRR을 보안 저장소에 저장한다. 예를 들어, 애플리케이션(111)은 증명 토큰(122)이 저장된 저장소와 유사한 보안 캐시 위치에 SRR(125)을 저장할 수 있다.
단계 I에서, 애플리케이션(111)은 웹사이트(140)에 대한 액세스 요청(125)을 생성하고 전송한다. 액세스 요청(125)은 SRR 및 다른 파라미터를 포함하는 것과 같은 파라미터를 추가로 포함할 수 있다. 애플리케이션(111)은 신뢰 체인의 추가 링크로서 디지털 서명을 사용하여 액세스 요청(125)에 서명할 수 있다. 예를 들어, 애플리케이션(111)은 액세스 요청(125)에서 키 파라미터에 서명할 수 있다. 일부 구현예에서, 모든 파라미터가 민감하거나 중요한 경우, 모든 파라미터는 액세스 요청(125)에 서명될 수 있다.
일부 구현예에서, 단계 I은 웹사이트(140)에 의해 트리거된다. 예를 들어, 애플리케이션(111)은 리소스(145) 또는 웹사이트(140)의 특정 섹션에 액세스를 시도할 수 있고 웹사이트(140)는 애플리케이션(111)으로부터 인증을 요청할 수 있다.
일부 구현예에서, 단계 I은 애플리케이션(111)이 웹사이트(140)로부터 검출한 정보에 기초하여 애플리케이션(111)에 의해 자동으로 수행된다. 예를 들어, 애플리케이션(111)은 인증이 필요할 수 있음을 웹사이트(140)와 연관된 데이터로부터 검출할 수 있다. 데이터는 애플리케이션(111)에 의해 저장되거나 웹사이트(140)에 의해 제공되거나 애플리케이션(111)에 액세스할 수 있다. 예를 들어, 데이터는 중앙 데이터베이스와 같이 다수의 상이한 디바이스에 설치된 다수의 상이한 애플리케이션(111)이 액세스할 수 있는 중앙의 공유 위치에 저장될 수 있다. 일부 구현예에서, 애플리케이션(111)은 저장된 데이터에 기초하여 웹사이트(140)가 인증을 필요로 한다고 결정할 수 있다. 예를 들어, 애플리케이션(111)이 웹사이트(140)에 액세스하려고 처음으로 시도할 때, 애플리케이션(111)은 인증 요청을 나타내는 데이터를 수신할 수 있다. 웹사이트(140)에 액세스하려는 후속 시도에서, 애플리케이션(111)은 웹사이트(140)에 액세스하기 위해 인증이 요청될 것임을 자동으로 결정할 수 있고, 웹사이트(140) 및/또는 리소스(145)에 액세스하려고 시도할 때 SRR을 제공할 수 있다.
단계 J에서, 웹사이트(140)는 액세스 요청에 제공된 SRR을 검증하려고 시도한다. 웹사이트(140)가 SRR을 검증할 수 있는 경우, 웹사이트(140)는 액세스 요청(125)에 표시된 웹사이트(140)의 부분에 대한 액세스를 제공하거나 요청된 리소스(145)에 대한 액세스를 제공할 수 있다.
도 1a 및 도 1b에 대해 위에서 설명된 바와 같은 프로세스는 안전하고 비공개이다. 일부 구현예에서, 위에서 설명된 블라인드 방식 또는 그룹 서명 방식이 증명 토큰을 발행하기 위해 구현될 때, 프로세스는 다른 플랫폼, 콘텐츠 제공자 및 퍼블리셔가 사용자의 프라이버시를 보호하면서 사용자가 특정 콘텐츠에 액세스할 권한이 있는지 검증하게 하여, 프로세스의 한 당사자는 사용자 활동을 추적하거나 활동을 특정 사용자 또는 사용자 정보에 링크하도록 한다.
일부 구현예에서, 증명 토큰이 블라인드 또는 그룹 서명 없이 발행되는 경우, 토큰은 다른 잠재적으로 민감한 정보 또는 증명 토큰 발행 서버와 콘텐츠 퍼블리셔 간에 충돌이 있는 경우 특정 디바이스에 후속 웹 활동을 링크하는데 사용될 수 있는 정보 중에서 고해상도 타임스탬프 또는 자세한 애플리케이션 정보를 포함할 수 있다.
하나의 특정 예에서, 신뢰 프로그램(114)은 사용자의 스마트폰인 클라이언트 디바이스(110)에 설치된 모바일 애플리케이션이고, Example News Organization의 공식 신뢰 애플리케이션이다. 애플리케이션(111)은 클라이언트 디바이스(110)에 설치된 웹 브라우저이고, 웹사이트(140)는 Example News Organization의 공식 웹사이트이다. Example News Organization의 가입자이고 Example News Organization의 애플리케이션(114)에 서명하고 클라이언트 디바이스(110)에서 Example News Organization의 공식 웹사이트(140)의 콘텐츠에 액세스하기를 원하는 사용자는 원활한 브라우징 경험을 가질 수 있다. 예를 들어, 웹 브라우저(111)는 토큰 요청을 생성하고, 이 요청을 Example News Organization 애플리케이션(114)에 제공할 수 있다. 사용자가 이미 자신의 로그인 자격증명을 제공하고 인증된 Example News Organization 애플리케이션(114)은 ATI 서버(170)에 대한 서명된 토큰 요청(121)을 생성할 수 있다. 이 특정 예에서, ATI 서버(170)는 Example News Organization에 의해 유지되는 증명 토큰 발행 서버일 수 있다. 일부 구현예에서, ATI 서버(170)는 Example News Organization이 토큰 발행 작업을 위임하는 신뢰 서버일 수 있다. 서명된 토큰 요청(121)은 ATI 서버(170)에 의한 검증을 위한 사용자의 자격증명을 포함할 수 있다. 사용자의 자격증명 및/또는 요청(121)을 수신하고 검증할 때, ATI 서버(170)는 웹 브라우저(111)에 증명 토큰(122)을 발행할 수 있다. 증명 토큰(122)은 사용자의 자격증명 및/또는 요청(121)이 인증되었는지 여부를 나타내는 적어도 하나의 비트를 포함할 수 있다. 증명 토큰(122)은 웹 브라우저(111)의 보안 캐시에 저장될 수 있다. 그 다음, 애플리케이션(111)은 저장된 증명 토큰(122)을 나타내는 토큰 상환 요청(123)을 생성하고 ATI 서버(170)에 전송할 수 있다. ATI 서버(170)가 토큰 상환 요청(123)에 표시된 증명 토큰을 검증할 수 있는 경우, ATI 서버(170)는 서명된 상환 결과(124)를 생성하고 SRR(124)을 웹 브라우저(111)에 전송한다. 이전 단계들 각각은 사용자가 특정 리소스(145) 또는 웹사이트(140)의 일부에 대한 액세스를 요청하기 전에 수행될 수 있다. 클라이언트 디바이스(110)의 사용자가 Example News Organization의 웹사이트(140)에서 새로운 낱말 퍼즐에 대한 액세스를 요청할 때, 웹 브라우저(111)는 액세스 요청(125)을 생성하고 Example News Organization의 웹사이트(140)에 전송할 수 있다. 액세스 요청(125)은 SRR(124) 및 웹사이트(140)에 의해 요청된 필수 메타데이터 또는 기타 정보와 같은 다른 키 파라미터를 포함한다. 이 특정 예에서, 증명 토큰 자체를 생성하는데 사용되는 블라인드 또는 다른 프라이버시 보호 기법은 프라이버시 보호 방식으로 토큰을 생성하기 때문에 Example News Organization 웹사이트(140)는 사용자가 구독을 가지지만 사용자의 신원에 대한 액세스 권한이 없고 사용자의 활동을 추적할 수 없다고 결정할 수 있다. 프라이버시 보호 기법을 사용하여 증명 토큰을 생성하는 경우, 증명 토큰을 사용하면 콘텐츠 퍼블리셔가 사용자가 인증되었음을 결정하게 할 수 있지만 발행자가 토큰을 서명된 상환 결과로 변환하지 않는 경우라도 사용자의 신원에 대한 액세스를 갖지 않으며 사용자의 활동을 추적할 수 없다.
다른 예에서, 웹사이트(140)가 대신에 Example News Aggregation Platform을 위한 모바일 애플리케이션 또는 웹 인터페이스이고, 여기서 Example News Aggregation Platform은 Example News Organization과 별개이고, 토큰 상환 프로세스 및 토큰 자체 대신에 SRR의 사용은 Example News Aggregation Platform으로 하여금, Example News Aggregation Platform 또는 Example News Organization이 당사자들 간 사용자 정보 또는 활동을 연결하거나 외삽하게 하는 능력 없이 액세스를 요청하는 사용자가 Example News Organization에 인증된 사용자라는 것만 학습함으로써 Example News Organization에 의해 유지된 정보에 대한 액세스를 제공하게 한다. 이러한 방식으로 Example News Aggregation Platform은 Example News Aggregation Platform의 도메인 내에서 사용자의 활동을 인식하고, Example News Organization은 Example News Organization 도메인 내에서 사용자의 활동을 인식하지만 Example News Aggregation Platform은 Example News Organization의 도메인 내의 사용자의 활동을 인식하지 못한다(또는 그 반대). 어느 플랫폼도 도 1a 및 도 1b와 관련하여 전술한 바와 같은 프로세스를 통해 이 사용자 활동 또는 데이터를 결정할 수 없다.
플랫폼 전반에 걸쳐 일반적으로 사용되는 인증 방법은 사용자에게 다른 도메인 또는 엔터티를 통해 한 도메인 또는 엔터티에 대한 자격증명을 제공하도록 요청하고, 다른 도메인 또는 엔터티에 사용자 정보에 액세스할 수 있는 권한을 부여하는 것을 포함한다. 도 1a 및 1b와 관련하여 설명된 바와 같은 프로세스는 특정 웹사이트 또는 리소스에 액세스하는 프로세스에서 로그인 프로세스를 제거함으로써 한 엔터티가 다른 엔터티에 대한 사용자 데이터에 대한 액세스를 요청하는 기능을 제거한다. 토큰 발행 및 상환 프로세스를 사용하여, 프로세스를 통해 사용자는 정보가 이미 제공된 신뢰 프로그램 및 사용자 인증을 증명해야 하는 증명 토큰 발행 서버를 제외하고 당사자 중 누구에게도 이해할 수 있는 원시 형식의 데이터를 제공하지 않고 인증을 전달할 수 있다.
도 1a 및 도 1b와 관련하여 설명된 바와 같은 프로세스는 상이한 웹사이트(140) 및 상이한 플랫폼들에 걸쳐 인증을 전송하는 능력을 제공하여 사용자 마찰을 줄이고 더 나은 사용자 경험을 제공한다.
다른 예에서, Example Video Streaming Service에 대한 유효한 구독이 있는 사용자에게 SRR로 상환될 수 있는 증명 토큰이 발행될 수 있다. SRR을 사용하여 사용자가 매번 로그인할 필요 없이 소셜 미디어 게시물에 내장된 Example Video Streaming Service에 가입한 사용자에게 제공되는 비디오에 액세스 및/또는 비디오를 시청할 수 있다. 특히, 설명된 프로세스는 사용자가 비디오 스트리밍 서비스의 애플리케이션에 로그인한 한 사용자가 소셜 미디어 게시물을 호스팅하는 애플리케이션 내에서 로그인할 필요 없이 콘텐츠에 액세스하게 할 수 있다.
일부 방법은 사용자가 호스팅 애플리케이션 내에서 한 번 로그인할 수 있게 하고, 인증이 애플리케이션의 수명 동안 지속되게 하지만, 프라이버시 보호 기능 변경으로 인해 향후 사용할 수 없는 "서드파티 쿠키"와 같은 데이터에 의존하는 이러한 접근 방식이 렌더링될 수 있다.
설명된 증명 토큰 기반 인증 프로세스는 더 나은 프라이버시 보호 특성을 제공하고 서드파티에 필요한 로그인 수를 줄이며 다른 접근 방식이 없는 미래 시나리오에서 계속 작동할 수 있다.
다른 예에서 Example Music Hosting Platform에 대한 유효한 구독이 있는 사용자는 자신의 디바이스에 Example Music Hosting Platform 애플리케이션을 설치할 수 있다. 사용자는 Example Music Hosting Platform 애플리케이션에 자신을 인증하고 자신의 활동을 자신의 히스토리에 추가하지 않고도 다양한 웹사이트에서 Example Music Hosting Platform에 가입한 사용자에게 제공되는 음악에 액세스할 수 있다.
또 다른 예에서, Example Video Streaming Service에 대한 유효한 구독이 있는 사용자는 소셜 미디어 플랫폼의 친구로부터 채팅 메시지로 전송된 Example Video Streaming Service 구독이 있는 사용자에게 제공되는 비디오에 액세스할 수 있다. 사용자는 비디오에 액세스하여 계정 정보를 제공하지 않고도 사용자가 인증된 사용자임을 Example Video Streaming Service에서 확인할 수 있다.
위에서 논의한 바와 같이, 일부 접근법에서, 개인/공개 키 쌍(및 공개 키와 연관된 판정)은 여러 증명 토큰에 걸쳐 변경될 수 있어서, 추적에 대해 클라이언트 디바이스 또는 사용자의 프라이버시를 향상시킬 수 있다. 예를 들어, 클라이언트 디바이스는 개인/공개 키 쌍의 배치를 생성하고 증명 토큰 발행 서버로부터 증명 토큰의 대응하는 배치를 검색하여, 증명 토큰의 재사용을 줄이거나 제거할 수 있다. 이러한 배치 프로세스의 예시가 도 2에 도시되어 있다.
이 예에서, 애플리케이션(200)은 N개의 공개/개인 키 쌍(201)을 생성한다. 예를 들어, 애플리케이션(200)에 설치된 웹브라우저는 공개/개인 키 쌍을 생성할 수 있다. 공개/개인 키 쌍은 비대칭 키 쌍일 수 있다. 각 공개/개인 키 쌍은 개인 키 및 상기 개인 키에 대응하고 수학적으로 연결된 공개 키를 포함한다. 개인 키를 사용하여 디지털 서명된 데이터는 대응 공개 키를 사용해야만 검증될 수 있다. 마찬가지로 공개 키를 사용하여 암호화된 데이터는 대응 개인 키를 사용해야만 복호화될 수 있다.
애플리케이션(200)은 N개의 증명 토큰들(202)에 대한 요청을 증명 토큰 발행 서버(230)에 전송한다. 숫자 N은 2보다 크거나 같은 정수일 수 있다. 이 예에서 요청은 N개의 공개/개인 키 쌍들에 대응하는 N개의 증명 토큰들에 대한 것이다. 애플리케이션(200)은 애플리케이션(200)이 요청에서 서명된 상환 결과를 사용하는 빈도에 기초하여 요청할 증명 토큰들의 수 N을 결정할 수 있다. 애플리케이션은 요청된 각 증명 토큰에 대해 공개/개인 키 쌍을 생성하고, 요청에 공개 키 데이터를 포함할 수 있다. 이 예에서, 공개 키 데이터는 공개 키 자체일 수 있다. 따라서, 요청은 애플리케이션(200)의 N개의 공개 키(211)를 증명 토큰 발행 서버(230)에 전달하는 것을 포함한다. 이 예에서, N개의 공개 키(211)는 실제 공개 키, 예를 들어 N개의 공개 키(211)의 원시 데이터를 포함한다. 요청은 디바이스 레벨 사기 탐지 신호를 포함할 수 있다. 예를 들어, 신뢰 프로그램은 디바이스 레벨 사기 탐지 신호를 수집하고 요청에 신호를 포함할 수 있다.
요청은 도 1a 및 도 1b와 관련하여 위에서 설명된 단계 A 및 B의 프로세스와 유사하게 애플리케이션(200)으로부터 신뢰 프로그램(220)으로 전달될 수 있다. 요청은 사용자 자격증명과 같은 정보를 포함할 수 있다.
증명 토큰 발행 서버(230)는 요청을 수신한다(231). 신뢰 프로그램(220)으로부터 수신된 사용자 자격증명에 기초하여, 증명 토큰 발행 서버(230)는 클라이언트 디바이스의 인증 레벨을 결정한다(232). 예를 들어, 증명 토큰 발행 서버는 M개의 가능한 인증 레벨들이 있을 수 있다. 이 예에서, 증명 토큰 발행 서버(230)는 위에서 설명된 바와 같이 사용자 자격증명에 기초하여 이러한 M개의 가능한 인증 레벨 중 하나를 선택할 수 있다. 인증 레벨은 예를 들어 특정 서명을 통해 인코딩될 수 있다.
증명토큰 발행 서버(230)는 N개의 증명토큰들을 생성한다(233). 즉, 증명 토큰 발행 서버(230)는 수신된 각각의 공개 키에 대한 각각의 증명 토큰을 생성한다.
각 증명 토큰은 인증 판정, 인증 판정을 대한 타임스탬프 및 애플리케이션(200)의 N개의 공개 키(211) 중 하나를 포함할 수 있다. 타임스탬프는 증명 토큰이 생성된 시간을 표시한다. 증명 토큰 발행 서버는 N개의 공개 키(211) 중 하나에 기초하여 각 증명 토큰을 생성할 수 있다. 예를 들어, 증명 토큰 발행 서버(230)는 애플리케이션(200)의 공개 키, 인증 판정 및 타임스탬프를 포함하는 데이터 세트를 조합할 수 있다. 인증 판정이 단 두 가지 가능한 판정(인증됨 및 인증되지 않음)만을 포함하는 일부 접근법에서, 인증 판정은 증명 토큰에서 생략될 수 있다. 다시 말해, 이러한 접근법에서, 증명 토큰 발행 서버는 인증된 사용자에 대한 증명 토큰을 생성할 수 있고(인증에 대한 묵시적 판정을 생략한 토큰으로) 인증되지 않은 사용자에 대한 증명 토큰 생성을 단순히 거부할 수 있다.
증명 토큰 발행 서버(230)는 N개의 증명 토큰(234) 각각에 디지털 서명을 한다. 예를 들어, 증명 토큰 발행 서버(230)은 자체의 개인 키를 사용하고, 증명 토큰의 다른 데이터(예를 들어, 인증 판정, 애플리케이션(200)의 공개 키 및 타임스탬프)에 기초하여 디지털 서명을 생성할 수 있다.
증명 토큰 발행 서버(230)는 N개의 증명 토큰들을 애플리케이션에 전송한다(235). 애플리케이션(200)은 나중에 사용하기 위해 증명 토큰의 배치를 수신하고 저장한다(203). 애플리케이션(200)은 증명 토큰을 로컬적으로, 예를 들어, 애플리케이션에 의해 유지되는 캐시 또는 보안 저장소에 저장할 수 있다. 각각의 캐시된 증명 토큰은 예를 들어: (1) 증명 토큰 발행 서버(230)에 의해 결정된 신뢰도의 판정; (2) 증명 토큰 생성에 대한 타임스탬프; (3) 애플리케이션의 공개 키; 및 (4) 증명 토큰 발행 서버(230)의 개인 키를 사용하여 서명된, 토큰 컴포넌트의 디지털 서명을 포함할 수 있다.
도 2의 예에 도시된 바와 같이, 증명 토큰의 배치를 획득하면, 클라이언트 디바이스는 위에서 논의된 바와 같이 웹사이트, 콘텐츠 퍼블리셔 도메인, 또는 다른 증명 토큰 수신자를 향하는 다양한 요청의 일부로서 증명 토큰을 조합하고 보내기 위해 증명 토큰을 사용할 수 있다. 그러한 요청의 예시가 도 3의 프로세스 흐름도로서 도시된다.
요청을 준비하기 위해, 애플리케이션(300)은 애플리케이션의 로컬 저장소로부터 증명 토큰을 검색할 수 있다(301). 다양한 접근 방식에서, 애플리케이션(300)은 예를 들어, (1) 각 요청에 대해 새로운 증명 토큰을 사용; 또는 (2) 선택된 시간 간격(예: 연속 H 시간) 동안 동일한 증명 토큰을 사용하고 해당 간격이 경과하면 다른 증명 토큰을 사용; 또는 (3) 동일한 애플리케이션 또는 웹사이트에서 발생한 모든 요청에 대해 동일한 증명 토큰을 사용(예: 각 애플리케이션 또는 웹사이트에 대해 다른 증명 토큰이 사용되는 경우); 또는 (4) 이러한 토큰 재사용 접근 방식 중 둘 이상의 조합을 사용(예: 선택된 시간 간격 내에서 동일한 애플리케이션 또는 웹사이트에서 발생한 모든 요청에 대해 동일한 증명 토큰 사용)할 수 있다. 따라서, 애플리케이션(300)은 요청이 생성된 애플리케이션 또는 웹사이트 또는 요청이 생성된 현재 시간에 기초하여 증명 토큰을 검색할 수 있다.
애플리케이션(300)은 증명 토큰을 상환하기 위한 요청을 생성한다(302). 요청(311)은 예를 들어 페이로드 데이터(위에서 논의됨), 요청 생성 타임스탬프, 검색된 증명 토큰, 증명 토큰에 대응하는 디바이스 공개 키 및 요청 컴포넌트의 디지털 서명을 포함할 수 있다. 일부 구현예에서, 클라이언트 디바이스의 신뢰 프로그램 또는 클라이언트 디바이스의 운영 체제의 신뢰 컴포넌트는 페이로드 데이터 및 증명 토큰에 액세스하여 증명 토큰을 포함하거나 그 형태일 수 있는 요청(311)을 생성할 수 있다. 또한 애플리케이션은 요청 생성 타임스탬프로서 현재 시간을 결정할 수 있다. 애플리케이션은 애플리케이션의 개인 키(예: 요청에 포함된 공개 키에 대응하는 개인 키)를 사용하여 페이로드 데이터, 공개 키 및 타임스탬프의 디지털 서명을 생성할 수 있다. 일부 접근법에서, 증명 토큰 크기를 줄이기 위한 간단한 최적화로, 공개 키가 이미 증명 토큰의 컴포넌트로서 포함된 증명 토큰에 존재하기 때문에, 증명 토큰에서 디바이스 공개 키를 생략한다.
일부 구현예에서, ATI 서버(170)는 토큰을 상환하는 것을 지원하고, 결정하기 위해 액세스가 요청되는 웹사이트와 연관된다. 일부 구현예에서, 블라인드 또는 그룹 서명과 같은 프라이버시 보호 기법을 사용하여 토큰이 발행되는 경우, ATI 서버(170)가 토큰 상환을 관찰함으로써 학습하는 유일한 정보는 이 제2 콘텐츠 제공자를 방문했지만 증명 토큰의 프라이버시 보호 속성으로 인해 특정 사용자 또는 디바이스를 결정할 수 없으므로 이전에 토큰을 발행한 대략적인 사용자 또는 디바이스의 수이다.
그런 다음, 애플리케이션(300)은 요청(311)을 증명 토큰 발행 서버(320)에 전송한다(303).
증명 토큰 발행 서버(320)는 요청을 수신한다(321). 증명 토큰 발행 서버(320)는 요청을 검증한다(322). 예를 들어, 증명 토큰 발행 서버(320)는 요청에 포함된 공개 키를 사용하여 요청의 디지털 서명을 검증함으로써 요청을 승인할 수 있다. 증명 토큰 발행 서버(320)는 공개 키와 애플리케이션(300)에 의해 서명된 요청의 콘텐츠, 예를 들어 페이로드 데이터, 타임스탬프, 공개 키 및 증명 토큰을 사용하여 디지털 서명을 검증하려고 시도할 수 있다. 디지털 서명이 생성된 후 이 내용 중 어느 것이라도 변경되면 검증에 실패한다. 예를 들어, 악의적인 당사자가 다른 요청에 증명 토큰을 삽입하거나 요청에 더 높은 인증 판정을 받은 다른 증명 토큰을 삽입한 경우 서명 검증은 실패한다. 이는 예를 들어 중개자에 의해 요청 전송 중에 요청의 내용이 변경되지 않았음을 보장한다.
증명 토큰 발행 서버(320)는 증명 토큰을 승인한다(323). 예를 들어, 증명 토큰 발행 서버(320)은 증명 토큰 발행 서버의 공개 키를 사용하여 증명 토큰의 서명을 검증함으로써 증명 토큰을 승인할 수 있다. 이것은 유사하게 증명 토큰이 증명 토큰 발행 서버에 의해 발행된 이후 증명 토큰의 내용이 변경되지 않았음을 보장한다. 증명 토큰이 디바이스 공개 키를 포함하는 경우, 증명 토큰의 검증은 증명 토큰에 포함된 디바이스 공개 키가 증명 토큰 내에 포함된 디바이스 공개 키와 일치한다는 확인을 포함할 수 있다.
증명 토큰 발행 서버(320)는 예를 들어, 증명 토큰이 최근에 생성되었는지(즉, 요청이 이루어진 시간의 H 시간 또는 D일 전(H, D = 1, 2, 3, …)과 같이, 선택된 시간 간격을 초과하여 생성되지 않음) 확인하고 증명 토큰에서 인증 판정이 요청을 따르는 충분한 판정인지 확인하기 위해 증명 토큰의 적시성 및 클라이언트 디바이스의 인증을 승인한다(324).
이러한 유효성 검사들 모두가 통과하면, 증명 토큰 발행 서버(320)는 도 1a, 1b 및 2와 관련하여 위에서 논의된 바와 같이, 예를 들어 서명된 상환 결과 등을 생성하기 위해 증명 토큰(325)을 상환함으로써 요청에 응답할 수 있다. 유효성 검사 중 하나라도 실패하면, 증명 토큰 발행 서버(320)는 요청을 무시할 수 있다. 예를 들어, 증명 토큰 발행 서버(320)는 요청에 응답하지 않을 수 있고, 요청된 동작을 수행하지 않을 수 있다.
애플리케이션(300)은 SRR을 수신한다(304). 그런 다음, 애플리케이션(300)은 액세스 요청(313)을 수신자 컴퓨팅 시스템(330)에 전송할 수 있다(313). 액세스 요청(313)은 SRR(312) 및 사용자 데이터, 컨텍스트 데이터 또는 타임스탬프를 포함하는 다른 파라미터들을 포함할 수 있다. 위에서 설명된 바와 같이, 수신자는 특히 다른 엔터티들 중에서도 특히, 액세스가 요청된 웹사이트, 콘텐츠 제공자 또는 퍼블리셔일 수 있다. 예를 들어, 애플리케이션(300)은 액세스 요청 및 SRR을 콘텐츠 플랫폼(150)에 보낼 수 있고, 콘텐츠 플랫폼은 요청을 하나 이상의 콘텐츠 퍼블리셔 도메인에 보낼 수 있다.
수신자 컴퓨팅 시스템(330)은 서명된 상환 결과를 수신할 수 있고, 모든 유효성 검사가 통과하면 요청에 응답할 수 있다(331).
위에서 논의된 바와 같이, 일부 접근법에서, 블라인드 서명 방식은 증명 토큰을 생성하는 프로세스에서 사용될 수 있으므로, 증명 토큰 발행 서버는 애플리케이션의 공개 키의 원시 데이터를 볼 수 없다. 예를 들어, 애플리케이션은 개인/공개 키 쌍의 배치를 생성한 다음 증명 토큰의 대응하는 배치를 검색하기 위해 공개 키를 증명 토큰 발행 서버에 보내기 전에 블라인드 서명 방식을 사용하여 공개 키를 블라인드화할 수 있다(또는 공개 키의 암호화 해시 또는 디바이스 모델 번호와 연결된 공개 키의 암호화 해시와 같이 블라인드 서명 방식의 커밋 페이즈에 대한 값으로 사용될 수 있는 이들 공개 키의 적절한 파생물). 이 예에서, 증명 토큰은 블라인드화된 공개 키로 블라인드로 서명된다. 이러한 배치 프로세스의 예시가 도 4에 도시되어 있다.
이 예에서, 증명 토큰 발행 서버(420)는 애플리케이션에 대한 M개의 서로 다른 인증 레벨을 정의하고, 대응하는 M개의 인증 레벨에 대해 M개의 서로 다른 블라인드 서명 검증 키(411)를 퍼블리시할 수 있다(421). 예를 들어, M개의 레벨은 인증됨과 인증되지 않음의 두 가지 레벨을 포함할 수 있다. 다른 예에서, M개의 레벨은 의심스러움, 만족스러움, 완전히 인증됨의 세 가지 레벨을 포함할 수 있다. 다른 예에서, M개의 레벨은 사기, 의심, 구독자 및 특수 구독자인 4개의 레벨을 포함할 수 있다. 다른 수의 레벨도 사용될 수 있다. 따라서 M은 2보다 크거나 같은 정수일 수 있다. 일부 접근법에서, 가장 낮은 레벨의 인증도(예: "인증되지 않음" 또는 "사기" 수준의 인증도)에 대해 블라인드 서명 검증 키를 할당하는 대신, M개의 레벨의 인증에서 가장 낮은 레벨의 인증을 생략할 수 있으며, 증명 토큰 발행 서버는 단순히 인증도가 가장 낮은 디바이스에 대해 블라인드 서명 제공을 거부할 수 있다. 따라서 이러한 접근법에서 M은 1보다 크거나 같은 정수가 될 수 있다.
증명 토큰 발행 서버(420)는 블라인드 서명 방식을 사용하여 인증도의 각 레벨에 대해 각각의 블라인드 서명 검증 키(411)를 생성할 수 있다. 블라인드 서명 방식은 IETF(Internet Engineering Task Force) VOPRF(Verifiable Oblivious Pseudorandom Functions) 블라인드 서명 방식과 같은 개인적으로 검증가능한 블라인드 서명 방식일 수 있다. 다른 접근법에서, 블라인드 서명 방식은 RSA(Rivest-Shamir-Adleman) 블라인드 서명 방식과 같이 공개적으로 검증가능한 블라인드 서명 방식일 수 있다.
증명 토큰 발행 서버(420)는 애플리케이션(400)을 포함하는 애플리케이션이 블라인드 서명 검증 키(411)를 획득할 수 있도록 블라인드 서명 검증 키(411)를 퍼블리시할 수 있다. 예를 들어, 증명 토큰 발행 서버(420)는 블라인드 서명 검증 키(411)를 웹사이트 또는 모바일 앱 스토어에 퍼블리시할 수 있다.
애플리케이션(400)은 이러한 블라인드 서명 검증 키(401)를 수신할 수 있다. 예를 들어, 애플리케이션(400)은 블라인드 서명 검증 키(411)를 다운로드하고, 블라인드 서명 검증 키(411)를 로컬적으로, 예를 들어 보안 저장소 또는 캐시에 저장할 수 있다. 애플리케이션(400)은 아래에서 더 논의되는 바와 같이 나중에 증명 토큰 발행 서버(420)로부터 수신된 블라인드 서명을 검증하기 위해 블라인드 서명 검증 키(411)를 보유할 수 있다. 일부 접근법에서, 증명 토큰 발행 서버(420)는 새로운 블라인드 서명 검증 키(411)를 주기적으로 퍼블리시할 수 있고(예를 들어, 매시간, 매일, 매주 또는 다른 적절한 기간마다), 블라인드 서명 검증 키의 세트의 이러한 리프레시는 아래에서 자세히 설명하는 것처럼 증명 토큰의 적시성을 승인하는데 사용될 수 있다.
N개의 증명 토큰의 배치를 획득하기 위해, 애플리케이션(400)은 N개의 공개/개인 키 쌍을 생성한다(402). 예를 들어, 웹브라우저는 각 증명 토큰에 대해 각각의 비대칭 공개/개인 키 쌍을 생성할 수 있다.
애플리케이션(400)은 블라인드 서명 검증 키를 생성하는데 사용되는 블라인드 서명 방식에 따라 각 공개 키 또는 각 공개 키의 파생물을 블라인드화한다(403). 즉, 애플리케이션(400)은 각각의 공개 키에 대한 공개 키 데이터를 블라인드화하고, 여기서 공개 키 데이터는 공개 키 또는 공개 키의 파생물이다. 공개 키를 블라인드화하는 것은 공개 키의 원시 값에 블라인드 팩터를 적용하여 공개 키의 원시 값을 숨기는 것을 포함할 수 있다. 이러한 방식으로, 증명 토큰 발행 서버(420)는 애플리케이션(400)으로부터 수신된 공개 키의 원시 값에 액세스할 수 없으며, 이러한 값을 사용하여 예를 들어 추가 데이터를 가진 공개 키의 원시 값을 수신한 다른 엔터티로부터 수신된 데이터를 사용하여, 사용자 또는 애플리케이션(400)을 추적할 수 없다.
증명 토큰 발행 서버(420)에 의해 블라인드 서명될 필요가 있는 데이터의 양을 줄이기 위해, 각각의 전체 디바이스 공개 키를 블라인드화하는 대신에, 애플리케이션(400)(예를 들어, 그것의 신뢰 프로그램)은 공개 키의 파생물을 생성할 수 있고, 공개 키의 파생물을 블라인드화한다. 파생물은 공개 키의 암호화 해시일 수 있다. 예를 들어, 애플리케이션(400)은 암호화해시 함수를 사용하여 각 공개 키의 암호화 해시를 생성한 후, 블라인드 서명 방식을 사용하여 공개 키의 암호화 해시를 블라인드화할 수 있다. 일부 구현예에서, 암호화 해시 알고리즘은 SHA256일 수 있다.
일부 구현예에서, 클라이언트 디바이스(420)는 암호화 해시를 절단함으로써 블라인드 공개 키 데이터의 데이터 크기를 추가로 감소시킬 수 있고, 그 다음 절단된 암호화 해시를 블라인드화할 수 있다. 예를 들어, 이 절단은 데이터 크기가 더 큰 원본 암호화 해시로부터 암호화 해시를 16바이트로 제한할 수 있다. 이러한 절단은 애플리케이션(400)이 블라인드 서명 방식을 사용하여 블라인드화하는 더 짧은 암호화 해시를 초래한다.
이러한 방식으로 블라인드적으로 서명된 데이터의 양을 줄이는 것은 데이터를 블라인드로 서명할 때 증명 토큰 발행 서버(420)에 가해지는 부담을 줄여(예를 들어, CPU 사이클, 데이터 저장 요구사항, 메모리 소비 등) 증명 토큰 발행 서버(420)가 블라인드 서명을 더 빠르고 효율적으로 생성하고 전체 공개 키의 블라인드 버전이 제공되는 경우보다 더 많은 요청을 처리하게 한다. 이것은 또한 요청이 송신되는 네트워크의 대역폭 소비를 줄이고 많은 양의 블라인드 공개 키 데이터를 단일 요청으로 송신되게 한다.
애플리케이션(400)은 N개의 증명 토큰들(404)에 대한 요청(412)을 증명 토큰 발행 서버(420)에 전송한다. 숫자 N은 2보다 크거나 같은 정수일 수 있다. 요청은 애플리케이션(400)에 의해 생성된 각각의 공개 키(411)에 대한 블라인드 공개 키 데이터를 포함할 수 있다. 예를 들어, 요청은 N개의 블라인드 공개 키, 공개 키의 N개의 블라인드 암호화 해시 또는 공개 키의 N개의 블라인드 절단 암호화 해시를 포함할 수 있다. 요청은 또한 예를 들어 애플리케이션(400)의 신뢰 프로그램에 의해 수집되는 디바이스 레벨 사기 탐지 신호를 포함할 수 있다. 일부 구현예에서, 애플리케이션(400)은 도 1a, 1b, 2 및 3과 관련하여 도시된 프로세스와 유사한 신뢰 프로그램(도시되지 않음)을 통해 요청(412)을 전송한다.
증명 토큰 발행 서버(420)는 요청을 수신한다(422). 증명 토큰 발행 서버(420)는 신뢰 프로그램에 의해 제공되었을 수 있는 요청에 표시된 사용자 자격증명에 기초하여 애플리케이션(400)의 인증 판정을 결정한다(423). 예를 들어, 증명 토큰 발행 서버(400)는 (동작(421)에서 퍼블리시된 M개의 블라인드 서명 검증 키에 대응하는) M개의 가능한 인증도 판정을 가질 수 있다. 증명 토큰 발행 서버(420)는 디바이스 레벨 사기 탐지 신호에 기초하여 M개의 가능한 판정 중 하나에 애플리케이션(400)을 할당할 수 있다.
애플리케이션(400)의 인증 판정을 결정하면, 증명 토큰 발행 서버(420)는 증명 토큰의 배치를 생성한다(424). 예를 들어, 증명 토큰 발행 서버(400)는 위의 동작(402)에서 생성된 각각의 공개 키에 대한 증명 토큰을 생성할 수 있다. 각 증명 토큰은 예를 들면, (1) 증명 토큰이 생성되는 애플리케이션의 공개 키; (2) 증명 토큰 발행 서버에 의해 결정된 인증 판정; 및 (3) 블라인드 공개 키의 블라인드화되지 않은 블라인드 서명 또는 공개 키의 암호화 해시(예: 잘림)를 포함할 수 있다. 일부 접근법에서, 증명 토큰은 비-블라인드화된 블라인드 서명에서 암시될 수 있으므로 인증 판정을 생략할 수 있다. 블라인드 서명이 공개적으로 검증가능하지 않은 경우, 블라인드 서명을 검증하기 위해 증명 토큰 발행 서버가 호출될 때(예를 들어, 아래에서 논의되는 도 5의 541 참조), 증명 토큰 발행 서버는 또한 판정을 반환할 수 있다. 블라인드 서명이 공개적으로 검증가능한 경우, 블라인드 서명을 검증하는 공개 키는 또한 디바이스의 인증도에 대한 판정을 의미한다.
애플리케이션(400)의 인증도에 대한 판정을 결정하고 증명 토큰을 생성한 후, 증명 토큰 발행 서버(400)는 블라인드 서명 개인 키를 사용하여 블라인드 공개 키 데이터(예를 들어, 각각의 N개의 블라인드 공개 키 또는 각각의 블라인드 암호화 해시) 및 증명 토큰의 각 부분에 서명한다(425). 예를 들어, 증명 토큰 발행 서버(420)는 애플리케이션(400)에 대해 결정된 인증도의 판정에 대응하는 블라인드 서명 개인 키(예: 결정된 인증도 판정에 대한 공개 블라인드 서명 검증 키에 대응하는 블라인드 서명 개인 키)를 획득한다(424). 이러한 방식으로 블라인드 서명 방식을 사용하여, 증명 토큰 발행 서버(420)는 공개 키 데이터의 실제 값을 알지 않고도 블라인드 공개 키 데이터의 디지털 서명을 생성할 수 있다.
증명 토큰 발행 서버(420)는 N개의 블라인드 서명(413) 및 증명 토큰을 클라이언트 디바이스(426)에 반환한다. 일부 구현예에서, 증명 토큰은 블라인드 서명 방식을 사용하여 서명되고, N개의 블라인드 서명(413)은 블라인드 서명된 증명 토큰을 포함한다. 애플리케이션(400)은 증명 토큰 발행 서버로부터 블라인드 서명을 수신한다.
일부 구현예에서, 애플리케이션(400)은 블라인드 서명 방식을 사용하여 블라인드 서명을 비-블라인드화할 수 있다. 예를 들어, 애플리케이션(400)은 블라인드 서명이 생성된 블라인드 공개 키 데이터 및 증명 토큰 발행 서버(420)에 의해 퍼블리시된 블라인드 서명 검증 키를 사용하여 각 블라인드 서명을 검증하여, 토큰의 유효성을 확인하고, 인증 판정 외에 추가 사용자 데이터가 증명 토큰에 인코딩되지 않음을 보장한다. 이를 위해, 애플리케이션(400)은 예를 들어 각각의 인증도 판정에 대해 다수의 블라인드 서명 확인 키를 사용하여 블라인드 서명을 승인하려고 시도할 수 있다. 판정이 애플리케이션(400)에 할당된 판정과 일치하지 않는 경우, 블라인드 서명은 해당 판정에 대한 블라인드 서명 검증 키를 사용하여 승인되지 않을 것이다. 애플리케이션은 블라인드 서명을 성공적으로 승인하는 블라인드 서명 검증 키에 기초하여 애플리케이션(400)의 인증도에 대한 할당된 판정을 결정할 수 있다. 예를 들어, 블라인드 검증 키에 대응하는 인증도의 판정은 애플리케이션(400)에 할당된 판정이다. 승인되면, 애플리케이션은 블라인드 서명 방식을 사용하여 블라인드 서명을 비-블라인드화할 수 있다.
애플리케이션(400)은 증명 토큰을 저장한다(405). 예를 들어, 애플리케이션(400)의 신뢰 프로그램은 증명 토큰을 포함해야 하는 요청을 보낼 때 나중에 사용하기 위해 증명 토큰을 보안 저장소에 저장할 수 있다. 보안 저장소는 애플리케이션(400)의 토큰 캐시일 수 있다. 위에서 설명된 바와 같이, 일부 구현예에서, 애플리케이션(400)은 저장 전에 증명 토큰을 검증하려고 시도할 것이다. 일부 구현예에서, 애플리케이션(400)은 저장 전에 증명 토큰을 검증하려고 시도하지 않을 것이고, 수신 시 증명 토큰을 저장할 것이다.
도 4의 예에 도시된 바와 같이, 증명 토큰의 배치를 저장한 경우, 애플리케이션은 증명 토큰 발행 서버에 증명 토큰을 상환할 수 있다. 상환되면, 증명 토큰 발행 서버는 증명 토큰이 성공적으로 상환되었음을 나타내는 서명된 상환 결과만 제공하며, 사용자 활동을 추적하는데 사용될 수 있는 추가 사용자 정보 또는 기타 정보를 제공하지 않는다.
서명된 상환 결과를 수신하면, 애플리케이션은 위에서 논의한 바와 같이 다른 요청 중에서 콘텐츠 퍼블리셔 도메인, 웹사이트의 특정 부분 및/또는 특정 콘텐츠에 대한 액세스에 대한 요청의 일부로 전송될 서명된 상환 결과를 저장할 수 있다. 그러한 요청의 예시가 도 5의 프로세스 흐름도로서 도시된다.
요청을 준비하기 위해, 애플리케이션(500)은 예를 들어 애플리케이션의 보안 캐시로부터 서명된 상환 결과를 검색할 수 있다(501). 다양한 접근 방식에서, 애플리케이션은 예를 들어, (1) 각 요청에 대해 새로운 서명된 상환 결과를 사용; 또는 (2) 선택된 시간 간격(예: H 연속 시간) 동안 동일한 서명된 상환 결과를 사용; 또는 (3) 동일한 애플리케이션 또는 웹사이트에서 시작된 모든 요청에 대해 동일한 서명된 상환 결과를 사용; 또는 (4) 이러한 상환 결과 재사용 접근 방식 중 둘 이상의 조합을 사용(예: 선택된 시간 간격 내에서 동일한 애플리케이션 또는 웹사이트에서 발생한 모든 요청에 대해 동일한 서명된 상환 결과를 사용)할 수 있다. 따라서, 애플리케이션(500)은 요청이 생성된 애플리케이션 또는 웹사이트 또는 요청이 생성된 현재 시간에 기초하여 서명된 상환 결과를 검색할 수 있다.
애플리케이션(500)은 요청 페이로드(위에서 설명됨)를 포함하는 콘텐츠 세트, 요청이 생성된 시간을 표시하는 요청 생성 타임스탬프, 서명된 상환 결과 및 서명된 상환 결과에 대응하는 디바이스 공개 키(예: 공개 키 데이터가 블라인드로 서명되고, 비블라인드화된 블라인드 서명과 함께 서명된 상환 결과에 포함된 공개 키)를 포함하는 요청(511)을 조합할 수 있다. 요청은 또한 애플리케이션의 개인 키(예를 들어, 요청에 포함된 공개 키에 대응하는 개인 키)를 사용하여 서명된(502) 콘텐츠 세트의 디지털 서명을 포함할 수 있다. 예를 들어, 애플리케이션(500)의 신뢰 프로그램은 개인 키를 사용하여 콘텐츠 세트에 기초하여 디지털 서명을 생성할 수 있다. 요청은 서명된 상환 결과를 포함하거나 서명된 상환 결과의 형식일 수 있다. 예를 들어, 요청은 콘텐츠 세트(예: 서명된 상환 결과 포함) 및 디지털 서명을 포함할 수 있다.
애플리케이션(500)은 요청(511)을 수신자의 컴퓨팅 시스템(520)에 전송한다(503). 수신자는 예를 들어 액세스가 요청된 웹사이트 또는 액세스가 요청되거나 콘텐츠가 요청되는 콘텐츠 호스팅 플랫폼일 수 있다.
수신자 컴퓨팅 시스템(520)은 요청을 승인한다(522). 수신자 컴퓨팅 시스템(520)은 요청에 포함된 디바이스 공개 키를 사용하여 요청의 디지털 서명을 검증함으로써 요청을 승인할 수 있다. 수신자 컴퓨팅 시스템(520)은 또한 요청의 타임스탬프를 요청이 수신된 시간과 비교함으로써 요청을 승인할 수 있다. 서명이 성공적으로 승인되고 타임스탬프가 현재 시간의 임계 기간 내에 있으면 애플리케이션(500)은 요청이 승인된 것으로 간주할 수 있다.
수신자 컴퓨팅 시스템(520)은 또한 서명된 상환 결과를 승인한다. 이 승인 프로세스는 블라인드 서명을 생성할 때 증명 토큰 발행 서버(540)에 의해 사용되는 블라인드 서명 방식에 따라 다를 수 있다. 블라인드 서명 방식이 공개적으로 검증가능한 방식(예: RSA)인 경우, 수신자 컴퓨팅 시스템(520)은 증명 토큰 발행 서버를 호출하지 않고 서명된 상환 결과를 승인할 수 있다(523a). 이 예에서, 수신자 컴퓨팅 시스템(520)은 블라인드 서명 방식을 사용하여 서명된 상환 결과에 포함된 공개 키 데이터의 비블라인드화된 블라인드 서명을 검증할 수 있다. 공개 키의 암호화 해시가 사용되는 경우, 수신자 컴퓨팅 시스템(520)은 애플리케이션(500)과 동일한 암호화 해시 함수를 사용하여 요청에 포함된 공개 키의 암호화 해시를 생성하고(적절한 경우 이를 자를 수 있음) 블라인드 서명 방식을 사용하여 암호화 해시의 비블라인드화된 블라인드 서명을 검증한다.
블라인드 서명 방식이 개인 검증가능한 방식(예를 들어, IETF VOPRF)인 경우, 수신자 컴퓨팅 시스템(520)은 비블라인드화된 블라인드 서명을 검증하기 위해 증명 토큰 발행 서버(540)를 호출할 수 있다(523b). 이 예에서, 수신자 컴퓨팅 시스템(520)은 비블라인드화된 블라인드 서명 및 공개 키 또는 공개 키의 암호화 해시를 증명 토큰 발행 서버(540)에 보낼 수 있다.
증명 토큰 발행 서버(540)는 블라인드 서명 방식을 사용하여 블라인드되지 않은 블라인드 서명 검증을 시도할 수 있다(541). 응답은 검증의 성공 여부 및 비블라인드화된 블라인드 서명을 검증하는 블라인드 서명 검증 키에 대응하는 클라이언트 디바이스의 신뢰도를 표시할 수 있다.
수신자 컴퓨팅 시스템(520)은 예를 들어, 서명된 상환 결과가 최근에 생성되었는지 확인하고 서명된 상환 결과의 신뢰도 판정이 요청을 따르는 충분한 판정인지 확인하기 위해 서명된 상환 결과의 적시성 및 클라이언트 디바이스의 신뢰도를 승인한다(524). 증명 토큰 발행 서버(540)는 새로운 블라인드 서명 검증 키를 주기적으로 재퍼블리시할 수 있기 때문에, 적시성 승인은, 예를 들어 서명된 상환 결과가 만료된 블라인드 서명 확인 키로 검증되었다고 결정함으로써, 서명된 상환 결과의 블라인드 서명이 무효 도난 키로 서명되지 않았음을 확인하는 것을 포함할 수 있다. 하나의 접근법에서, 수신자 컴퓨팅 시스템은 블라인드 서명 검증 키의 유효 날짜가 퍼블리시된 키에 대한 URL의 일부로 인코딩되었기 때문에 블라인드 서명 확인 키가 만료되었다고 결정할 수 있다. 다른 접근법에서, 수신자 컴퓨팅 시스템은 검증 키가 검증 키의 만료 날짜를 인코딩하는 메타데이터와 함께 퍼블리시되기 때문에 블라인드 서명 검증 키가 만료되었다고 결정할 수 있다.
이들 유효성 검사를 모두 통과하면, 수신자 컴퓨팅 시스템(520)은 예를 들어 위에서 논의된 바와 같이, 리소스에 대한 액세스를 제공하거나 리소스를 전달하는 등의 요청에 응답할 수 있다(525). 유효성 검사 중 임의의 것이 실패하면, 수신자 컴퓨팅 시스템(520)은 요청을 무시할 수 있으며, 예를 들어 요청, 업데이트 설정 등에 대한 응답을 전송하지 않도록 선택할 수 있다.
상기 기술에 더하여, 사용자가 본 명세서에 기술된 시스템들, 프로그램들 또는 구성들이 사용자 정보의 수집(예를 들어, 사용자의 소셜 네트워크에 관한 정보, 사회적 액션들 또는 활동들, 직업, 사용자의 선호들 또는 사용자의 현재 위치)을 하는 경우 및 콘텐츠 또는 서버로부터 통신에 사용자가 전송되는 경우에 관한 선택을 하게 하는 제어들이 사용자에게 제공될 수 있다. 추가로, 특정 데이터는 그것이 저장되거나 사용되기 전에 하나 이상의 다양한 방식들로 취급되어, 개인적으로 식별가능한 정보는 제거된다. 예를 들면, 사용자의 신원은 사용자에 관한 개인적으로 식별가능한 정보(예: 전화번호, IMEI, 디바이스 시리얼 번호)가 결정될 수 없도록 취급되거나 또는 사용자의 지리적 위치는 위치 정보가 획득된 곳에서 일반화되어(시, 우편번호 또는 주 수준으로), 사용자의 특정한 위치가 결정될 수 없도록 한다. 따라서, 사용자는 사용자에 관한 어떤 정보가 수집될지, 정보가 어떻게 사용될지, 정보 보유 정책 그리고 어떤 정보가 사용자에게 제공될지에 관한 제어를 가질 수 있다.
도 6는 상기 기술된 동작들을 수행하는데 사용될 수 있는 예시적 컴퓨터 시스템(600)의 블록 다이어그램이다. 시스템(600)은 프로세서(610), 메모리(620), 저장 디바이스(630) 및 입력/출력 디바이스(640)를 포함한다. 컴포넌트들(610, 620, 630 및 640) 각각은 예를 들면, 시스템 버스(650)를 사용하여 상호 연결될 수 있다. 프로세서(610)는 시스템(600) 내에서 실행하기 위한 명령어들을 프로세싱할 수 있다. 일부 구현예에서, 프로세서(610)는 단일-스레드 프로세서이다. 다른 구현예에서, 프로세서(610)는 멀티-스레드 프로세서이다. 프로세서(610)는 메모리(620) 또는 저장 디바이스(630)에 저장된 명령어들을 프로세싱할 수 있다.
메모리(620)는 시스템(600) 내에 정보를 저장한다. 일 구현예에서, 메모리(620)는 컴퓨터 판독가능 매체이다. 일부 구현예에서, 메모리(620)는 휘발성 메모리 유닛이다. 다른 구현예에서, 메모리(620)는 비휘발성 메모리 유닛이다.
저장 디바이스(630)는 시스템(600)에 대한 대형 저장소를 제공할 수 있다. 일부 구현예에서, 저장 디바이스(630)는 컴퓨터 판독가능 매체이다. 다양한 상이한 구현예에서, 저장 디바이스(630)는 예를 들면, 하드 디스크 디바이스, 광학 디스크 디바이스, 다수의 컴퓨팅 디바이스들(예를 들면, 클라우드 저장 디바이스)에 의해 네트워크를 통해 공유되는 저장 디바이스 또는 일부 기타 대용량 저장 디바이스를 포함할 수 있다.
입력/출력 디바이스(640)는 시스템(600)에 대한 입력/출력 동작들을 제공한다. 일부 구현예에서, 입력/출력 디바이스(640)는 네트워크 인터페이스 디바이스 예를 들어, 이더넷 카드, 직렬 통신 디바이스(예를 들어, RS-232 포트) 및/또는 무선 인터페이스 디바이스(예를 들어, 802.11 카드) 중 하나 이상을 포함할 수 있다. 다른 구현예에서, 입력/출력 디바이스는 입력 데이터를 수신하고 출력 데이터를 다른 외부 디바이스들(660) 예를 들어, 키보드, 프린터 및 디스플레이 디바이스들에 송신하도록 구성된 드라이버 디바이스들을 포함할 수 있다. 그러나, 모바일 컴퓨팅 디바이스들, 모바일 통신 디바이스들, 셋톱 박스 텔레비전 클라이언트 디바이스들 등과 같은 다른 구현예들도 사용될 수 있다.
예시적 프로세싱 시스템이 도 6에서 기술되었지만, 본 발명의 구현예들 및 본 명세서에 기술된 기능적 동작들은 본 발명에 개시된 구조들 및 그들의 구조적 균등물들 또는 그들 중 하나 이상의 조합들을 포함하는 다른 유형의 디지털 전자 회로에서, 또는 컴퓨터 소프트웨어, 펌웨어 또는 하드웨어에서 구현될 수 있다.
본 발명의 실시예들과 본 명세서에 기술된 동작들은 본 발명에 개시된 구조들 및 그들의 구조적 균등물들 또는 그들 중 하나 이상의 조합들을 포함하는 디지털 전자회로 또는 컴퓨터 소프트웨어, 펌웨어 또는 하드웨어에서 구현될 수 있다. 본 명세서에 기술된 본 발명의 실시예들은 하나 이상의 컴퓨터 프로그램들로서 구현될 수 있다. 즉, 데이터 프로세싱 장치에 의해 실행 또는 데이터 프로세싱 장치의 동작을 제어하기 위한 컴퓨터 저장 매체(또는 매체들)에 인코딩된 컴퓨터 프로그램 명령어들의 하나 이상의 모듈들. 대안적으로 또는 추가로, 프로그램 명령어들은 데이터 프로세싱 장치에 의해 실행하기 위한 적절한 수신기 장치에 전송하기 위한 정보를 인코딩하기 위해 생성된 인공적으로 생성된 전파된 신호 즉, 기계-생성 전기, 광학 또는 전자기적 신호에 인코딩될 수 있다. 컴퓨터 저장 매체는 컴퓨터 판독가능 저장 디바이스, 컴퓨터 판독가능 저장 기판, 랜덤 또는 직렬 액세스 메모리 어레이 또는 디바이스 또는 그들 중 하나 이상의 조합이거나 그에 포함될 수 있다. 또한, 컴퓨터 저장 매체는 전파된 신호가 아니지만, 컴퓨터 저장 매체는 인공적으로 생성된 전파된 신호에 인코딩된 컴퓨터 프로그램 명령어들의 소스 또는 목적지일 수 있다. 또한, 컴퓨터 저장 매체는 하나 이상의 별개의 물리적 컴포넌트들 또는 매체(예를 들면, 다수의 CD들, 디스크들, 또는 다른 저장 디바이스들)이거나 또는 그에 포함될 수 있다.
본 명세서에 기술된 동작들은 하나 이상의 컴퓨터 판독가능 저장 디바이스들에 저장된 또는 다른 소스들로부터 수신된 데이터에서 데이터 프로세싱 장치에 의해 수행되는 동작들로서 구현될 수 있다.
용어 "데이터 프로세싱 장치"는 예시로서 프로그래머블 프로세서, 컴퓨터, 시스템 온 칩 또는 앞서 언급된 것들 중 다수의 것들 또는 조합들을 포함하는 데이터를 프로세싱하기 위한 모든 종류의 장치, 디바이스들 및 기계들을 포함한다. 상기 장치는 특수 목적 논리 회로, 예를 들어 FPGA(field programmable gate array) 또는 ASIC(application specific integrated circuit)을 포함할 수 있다. 또한, 장치는 하드웨어 이외에 문제의 컴퓨터 프로그램에 대한 실행 환경을 생성하는 코드, 예를 들어 프로세서 펌웨어, 프로토콜 스택, 데이터베이스 관리 시스템, 운영 체제, 크로스-플랫폼 런타임(cross-platform runtime) 실행 환경, 가상 머신 또는 그들 중 하나 이상의 조합을 구성하는 코드를 포함할 수 있다. 장치 및 실행 환경은 웹 서비스들, 분산 컴퓨팅 및 그리드 컴퓨팅 인프라와 같은 다양한 컴퓨팅 모델 인프라를 실현할 수 있다.
컴퓨터 프로그램(프로그램, 소프트웨어, 소프트웨어 애플리케이션, 스크립트 또는 코드로도 알려져 있음)은 컴파일된 또는 인터프리트된 언어들, 선언적 또는 절차적 언어들을 포함하는 임의의 형태의 프로그래밍 언어로 작성될 수 있으며, 독립 실행형 프로그램으로서 또는 모듈, 컴포넌트, 서브루틴, 객체로서 또는 컴퓨팅 환경에서 사용하기에 적합한 기타 단위를 포함하는 임의의 형태로 배포될 수 있다. 컴퓨터 프로그램은 파일 시스템의 파일에 대응할 수 있지만, 반드시 그런 것은 아니다. 프로그램은 다른 프로그램들이나 데이터, 예를 들어, 마크업 언어 문서에 저장된 하나 이상의 스크립트들을 가지는 파일의 부분에, 문제되는 프로그램 전용 단일의 파일에 또는 다수의 조정된 파일들, 예를 들어, 하나 이상의 모듈들, 서브프로그램 또는 코드의 일부를 저장하는 파일들에 저장될 수 있다. 컴퓨터 프로그램은 하나의 컴퓨터 또는 하나의 사이트에 위치되어 있거나 다수의 사이트들에 걸쳐서 분산되어 있고 통신 네트워크에 의해 상호연결된 다수의 컴퓨터들에서 실행되도록 배포될 수 있다.
본 명세서에 기술된 프로세스들 및 논리 흐름들은 입력 데이터를 동작하고 출력을 생성함으로써 액션들을 수행하기 위해 하나 이상의 컴퓨터 프로그램들을 실행하는 하나 이상의 프로그래머블 프로세서들에 의해 수행될 수 있다. 프로세스들 및 논리 흐름들은 또한 FPGA 또는 ASIC와 같은 특수 목적 논리 회로에 의해 수행될 수 있고, 장치는 또한 특수 목적 논리 회로로서 구현될 수 있다.
컴퓨터 프로그램의 실행에 적절한 프로세서들은, 예시로서, 범용 및 전용 마이크로프로세서들을 포함한다. 일반적으로, 프로세서는 읽기-전용 메모리 또는 랜덤 액세스 메모리 또는 둘 모두로부터 명령어들 및 데이터를 수신할 것이다. 컴퓨터의 필수 엘리먼트들은 명령어들에 따라 액션들을 수행하기 위한 프로세서 및 명령어들 및 데이터를 저장하기 위한 하나 이상의 메모리 디바이스들이다. 일반적으로, 컴퓨터는 데이터를 저장하기 위한 하나 이상의 대형 저장 디바이스들 예를 들면, 자기적, 자기-광학 디스크들 또는 광학적 디스크들 또한 포함하거나 또는 그로부터 데이터를 수신하거나 그에 데이터를 전송하기 위해 동작적으로 결합될 수 있다. 그러나, 컴퓨터는 상기 디바이스들을 반드시 가져야하는 것은 아니다. 추가로, 컴퓨터는 다른 디바이스, 예를 들어, 몇 가지만 나열하면, 모바일 전화, 개인 휴대 정보 단말기(PDA), 모바일 오디오 또는 비디오 플레이어, 게임 콘솔, GPS 수신기 또는 휴대용 저장 디바이스 예를 들어, 범용 직렬 버스(USB) 플래시 드라이브에 내장될 수 있다. 컴퓨터 프로그램 명령어들 및 데이터를 저장하기에 적합한 디바이스들은 예를 들어, EPROM, EEPROM 및 플래시 메모리 디바이스들과 같은 반도체 메모리 디바이스들; 예를 들어, 내부 하드 디스크들 또는 이동식 디스크들과 같은 자기 디스크들; 및 CD-ROM 및 DVD-ROM 디스크들을 포함하는 모든 형태의 비휘발성 메모리, 매체 및 메모리 디바이스들을 포함한다. 프로세서 및 메모리는 특수 목적 논리 회로에 의해 보충되거나 그 안에 통합될 수 있다.
사용자와의 인터렉션을 제공하기 위해, 본 명세서에서 기술된 본 발명의 실시예들은 사용자에게 정보를 디스플레이하기 위해 예를 들어, CRT(cathode ray tube) 또는 LCD(liquid crystal display) 모니터와 같은 디스플레이 디바이스 및 사용자가 컴퓨터에 입력을 제공할 수 있는 키보드 및 포인팅 디바이스 예를 들어, 마우스 또는 트랙볼을 갖는 컴퓨터에서 구현될 수 있다. 다른 종류의 디바이스들도 사용자와의 인터렉션을 제공하는데 사용될 수 있다. 예를 들어, 사용자에게 제공되는 피드백은 시각 피드백, 청각 피드백 또는 촉각 피드백과 같은 임의의 형태의 감각적 피드백일 수 있고, 사용자로부터의 입력은 음향, 음성 또는 촉각 입력을 포함하는 임의의 형태로 수신될 수 있다. 추가로, 컴퓨터는 사용자에 의해 사용되는 디바이스에 문서를 송수신함으로써 예를 들어, 웹브라우저로부터 수신된 요청에 응답하여, 사용자의 사용자 디바이스상의 웹브라우저에 웹페이지를 전송함으로써 사용자와 인터렉션할 수 있다.
본 명세서에서 기술된 발명의 실시예는 예를 들어 데이터 서버와 같은 백엔드 컴포넌트, 어플리케이션 서버와 같은 미들웨어 컴포넌트 또는 그래픽 사용자 인터페이스를 가지는 사용자 컴퓨터 또는 사용자가 본 명세서에 기술된 본 발명의 구현예와 인터렉션할 수 있는 웹 브라우저와 같은 프론트엔드 컴포넌트 또는 하나 이상의 상기 백엔드, 미들웨어 또는 프론트엔드 컴포넌트들의 임의의 조합을 포함하는 컴퓨팅 시스템에서 구현될 수 있다. 시스템의 컴포넌트들은 디지털 데이터 통신의 임의의 형태 또는 매체, 예를 들어 통신 네트워크에 의해 상호연결될 수 있다. 통신 네트워크들의 예는 근거리 통신망("LAN") 및 광역 통신망("WAN"), 인터-네트워크(예를 들어, 인터넷) 및 피어투피어 네트워크(예를 들어, 애드혹 피어투피어 네트워크)를 포함한다.
컴퓨팅 시스템은 사용자들 및 서버들을 포함할 수 있다. 사용자와 서버는 일반적으로 서로 멀리 떨어져 있으며, 일반적으로 통신 네트워크를 통해 인터렉션한다. 사용자와 서버의 관계는 각각의 컴퓨터에서 실행되고 서로 사용자-서버 관계를 갖는 컴퓨터 프로그램에 의해 발생한다. 일부 실시예에서, 서버는(예를 들어, 사용자 디바이스와 인터렉션하는 사용자에게 데이터를 디스플레이하고 사용자 입력을 수신하기 위해) 사용자 디바이스에 데이터(예를 들어, HTML 페이지)를 전송한다. 사용자 디바이스에서 생성된 데이터(예를 들어, 사용자 인터렉션의 결과)는 서버에서 사용자 디바이스로부터 수신될 수 있다.
본 명세서는 많은 특정 구현 세부내용을 포함하지만, 이들은 임의의 발명의 범위 또는 청구될 수 있는 범위에 대한 제한으로서 해석되어서는 안되며, 오히려 특정한 발명의 특정한 실시예에 특정한 구성들에 대한 설명으로 해석되어야 한다. 별개의 실시예의 컨텍스트에서 본 명세서에서 기술되는 일정 구성들은 또한 단일 실시예에서 조합하여 구현될 수 있다. 반대로, 단일 실시예의 컨텍스트에서 기술된 다양한 구성들은 또한 다수의 실시예에서 개별적으로 또는 임의의 적절한 서브 조합으로 구현될 수 있다. 게다가, 구성들은 일정 조합으로 동작하고 심지어 초기적으로 그렇게 청구되는 것으로서 상기에서 기술될 수 있지만, 청구된 조합으로부터의 하나 이상의 구성들은 일부 경우, 조합으로부터 제거될 수 있고, 청구된 조합은 서브 조합 또는 서브 조합의 변형으로 안내될 수 있다.
유사하게, 동작들이 특정한 순서로 도면에서 도시되었지만, 이는 상기 동작들이 도시된 특정한 순서로 또는 시계열적 순서로 수행되어야 함을 요구하는 것으로서 또는 모든 도시된 동작들이 수행되어야 하는 것으로 이해되어서는 안된다. 특정 환경에서, 멀티태스킹과 병렬 프로세싱은 이점이 있다. 게다가, 상기 기술된 실시예에서 다양한 시스템 컴포넌트들의 분리는 모든 실시예에서 그러한 분리가 필요한 것으로서 이해되어서는 안되며, 일반적으로 기술된 프로그램 컴포넌트들 및 시스템들은 단일의 소프트웨어 제품에 함께 통합되거나 다수의 소프트웨어 제품들에 패키징될 수 있다고 이해되어야 한다.
따라서, 본 발명의 특정한 실시예들이 기술되었다. 다른 실시예들도 다음의 청구항들의 범위 내에 있다. 일부 경우에, 청구항들에서 기재된 액션들은 상이한 순서로 수행되고 여전히 원하는 결과들을 달성할 수 있다. 추가로, 첨부 도면들에 도시된 프로세스들은 원하는 결과들을 달성하기 위해 특정한 도시된 순서, 또는 시계열적 순서를 반드시 필요로 하지 않는다. 특정 구현예에서, 멀티태스킹과 병렬 프로세싱은 이점이 있다.

Claims (16)

  1. 익명 증명을 위한 방법으로서,
    클라이언트 디바이스에서 실행되는 애플리케이션에 의해, 제1 콘텐츠 제공자의 제1 도메인에서 호스팅되는 제1 서버로부터, 상기 제1 콘텐츠 제공자와 상이한 제2 콘텐츠 제공자의 제2 도메인으로부터 콘텐츠를 수신하기 위해 사용자를 인증하기 위한 인증 요청을 수신하는 단계;
    인증 요청을 수신하는 것에 응답하여, 상기 애플리케이션에 의해, 사용자의 인증을 상기 제2 콘텐츠 제공자에게 증명하는 익명 증명 토큰을 발행하는 증명 토큰 발행 시스템으로, 상기 익명 증명 토큰을 제2 요청과 함께 전송함으로써 상기 익명 증명 토큰을 상환하는 단계;
    상기 애플리케이션에 의해, 상기 제2 요청에 응답하여 상기 증명 토큰 발행 시스템으로부터, 상기 증명 토큰이 성공적으로 상환되었고, 상기 증명 토큰이 디지털 서명을 사용하여 증명 토큰 발행 시스템에 의해 서명되었는지 여부를 나타내는 상환 결과를 수신하는 단계, 상기 상환 결과는 상기 사용자를 상기 제2 콘텐츠 제공자에 대해 식별하지 않고 상기 사용자가 상기 제2 콘텐츠 제공자에 대해 인증되었음을 상기 제2 콘텐츠 제공자에게 검증하도록 동작가능하며; 및
    상기 애플리케이션에 의해, 상기 증명 토큰 발행 시스템에 의해 서명된 상기 상환 결과를 상기 제1 콘텐츠 제공자에게 전송하는 단계를 포함하는, 방법.
  2. 청구항 1에 있어서, 상기 상환 결과는 상기 제1 콘텐츠 제공자에게 상기 사용자에 대한 자격증명들의 세트를 제공하지 않고 상기 사용자가 익명을 유지하게 하면서, 상기 사용자가 상기 제2 콘텐츠 제공자에 대해 인증되었음을 수신자에게 검증하도록 동작가능한, 방법.
  3. 청구항 1 또는 2에 있어서, 상기 제2 콘텐츠 제공자는 뉴스 제공자이며,
    상기 제1 콘텐츠 제공자는 뉴스 수집 도메인이고, 그리고
    제1항에 있어서, 상기 애플리케이션에 의해, 상기 증명 토큰 발행 시스템에 의해 서명된 상기 상환 결과를 상기 제1 콘텐츠 제공자에게 전송하는 단계는 상기 뉴스 제공자에 의해 호스팅되는 리소스에 대한 액세스를 요청하는 사용자 액션에 응답하여 수행되는, 방법.
  4. 청구항 1 또는 2에 있어서, 상기 제2 콘텐츠 제공자는 미디어 호스팅 플랫폼이며,
    상기 제1 콘텐츠 제공자는 소셜 미디어 플랫폼이고, 그리고
    제1항에 있어서, 상기 애플리케이션에 의해, 상기 증명 토큰 발행 시스템에 의해 서명된 상기 상환 결과를 상기 제1 콘텐츠 제공자에게 전송하는 단계는 상기 미디어 호스팅 플랫폼에 의해 호스팅되는 리소스에 대한 액세스를 요청하는 사용자 액션에 응답하여 수행되는, 방법.
  5. 청구항 1 내지 4 중 어느 한 항에 있어서,
    클라이언트 디바이스에서 애플리케이션에 의해, 상기 사용자의 인증을 상기 제2 콘텐츠 제공자에게 증명하는 익명 증명 토큰에 대한 제1 요청을 엔터티에 대해 사용자를 인증하는 상기 클라이언트 디바이스의 사용자의 자격증명에 액세스하는 신뢰 프로그램에 전송하는 단계;
    상기 신뢰 프로그램에 의해, 익명 증명 토큰에 대한 제3 요청을 상기 증명 토큰 발행 시스템에 전송하는 단계, 상기 제3 요청은 상기 클라이언트 디바이스의 사용자에 대한 자격증명들의 세트를 포함하며; 및
    상기 애플리케이션에 의해, 상기 증명 토큰 발행 시스템으로부터, (i) 익명 증명 토큰의 생성 시간을 나타내는 증명 토큰 생성 타임스탬프 및 (ii) 증명 토큰 발행 시스템의 제2 디지털 서명을 포함하는 익명 증명 토큰을 수신하는 단계를 더 포함하는, 방법.
  6. 청구항 1 내지 5 중 어느 한 항에 있어서,
    상기 애플리케이션에 의해, 상기 제1 콘텐츠 제공자의 전자 리소스를 통해 제2 콘텐츠 제공자로부터, 제2 콘텐츠 제공자로부터의 콘텐츠를 요청하는 단계를 더 포함하는, 방법.
  7. 청구항 6에 있어서,
    상기 애플리케이션에 의해, 상기 제2 콘텐츠 제공자로부터 콘텐츠를 수신하는 단계를 더 포함하는, 방법.
  8. 청구항 1 내지 7 중 어느 한 항에 있어서, 상기 증명 토큰 발행 시스템의 디지털 서명은 블라인드 서명 방식에 따라 생성되는, 방법.
  9. 청구항 1 내지 8 중 어느 한 항에 있어서, 상기 증명 토큰 발행 시스템의 디지털 서명은 그룹 서명 방식 및 상기 클라이언트 디바이스에 발행된 익명 인증서를 사용하여 생성되고; 그리고
    클라이언트 디바이스의 보안 개인 키스토어에 상기 익명 인증서를 저장하는 단계를 더 포함하는, 방법.
  10. 청구항 1 내지 9 중 어느 한 항에 있어서, 상기 증명 토큰 발행 시스템에 의해 서명된 상환 결과를 전송하는 단계는 (i) 상기 애플리케이션에 의해 서명되고 (ii) 상기 사용자를 자격증명들의 세트와 상관시키지 않는 추가 데이터를 제공하는 단계를 더 포함하는, 방법.
  11. 청구항 1 내지 10 중 어느 한 항에 있어서, 상기 요청은 발행될 증명 토큰들의 수를 나타내는, 방법.
  12. 청구항 1 내지 11 중 어느 한 항에 있어서, 상기 요청은 상기 애플리케이션에 의해 유지되는 개인 키를 사용하여 제3 디지털 서명으로 서명되고, 상기 제3 디지털 서명은 (i) 상기 개인 키에 대응하고 (ii) 상기 애플리케이션에 의해 퍼블리시된 공개 키를 사용하여 검증될 수 있는, 방법.
  13. 청구항 5 또는 청구항 6 내지 11 중 어느 한 항이 청구항 5를 인용하는 경우에 있어서, 상기 제2 디지털 서명은 상기 증명 토큰 발행 시스템에 의해 유지되는 개인 키를 사용하여 생성되고, 상기 제3 디지털 서명은 (i) 상기 개인 키에 대응하고 (ii) 상기 증명 토큰 발행 시스템에 의해 퍼블리시된 공개 키를 사용하여 검증될 수 있는, 방법.
  14. 청구항 1 내지 13 중 어느 한 항에 있어서, 상기 상환 결과는 증명 토큰이 성공적으로 상환되었는지 여부를 나타내는 단일 비트를 포함하는, 방법.
  15. 시스템으로서,
    하나 이상의 프로세서; 및
    상기 하나 이상의 프로세서로 하여금 청구항 1 내지 14 중 어느 한 항의 방법을 수행하게 하도록 구성된 컴퓨터 판독가능 명령어가 저장되어 있는 하나 이상의 메모리를 포함하는, 시스템.
  16. 명령어가 저장된 비일시적 컴퓨터 판독가능 매체로서, 상기 명령어는 하나 이상의 컴퓨터에 의해 실행될 때, 상기 하나 이상의 컴퓨터로 하여금 청구항 1 내지 13 중 어느 한 항의 방법을 수행하게 하는, 비일시적 컴퓨터 판독가능 매체.
KR1020227038973A 2021-08-26 2021-08-26 토큰 상환을 통한 익명 인증 KR20230031192A (ko)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2021/047736 WO2023027709A1 (en) 2021-08-26 2021-08-26 Anonymous authentication with token redemption

Publications (1)

Publication Number Publication Date
KR20230031192A true KR20230031192A (ko) 2023-03-07

Family

ID=77897737

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020227038973A KR20230031192A (ko) 2021-08-26 2021-08-26 토큰 상환을 통한 익명 인증

Country Status (6)

Country Link
US (1) US20230308277A1 (ko)
EP (1) EP4162647B1 (ko)
JP (1) JP7564244B2 (ko)
KR (1) KR20230031192A (ko)
CN (1) CN116034596A (ko)
WO (1) WO2023027709A1 (ko)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12075248B2 (en) * 2022-01-20 2024-08-27 Verizon Patent And Licensing Inc. Systems and methods for application-anonymous slice selection in a wireless network
US20230394150A1 (en) * 2022-06-03 2023-12-07 International Business Machines Corporation Attestation Of Logic Loader Code And Integrity Checking Service Logic Code In A Trusted Execution Environment (TEE)
US20240250835A1 (en) * 2023-01-23 2024-07-25 Dell Products L.P. Role-based permissions in a distributed permissions network

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8281149B2 (en) * 2009-06-23 2012-10-02 Google Inc. Privacy-preserving flexible anonymous-pseudonymous access
EP2438707B1 (de) 2009-07-07 2013-04-03 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Pseudonymisierte authentifizierung
EP2747369A1 (en) * 2012-12-21 2014-06-25 Gemalto SA A system and method of dynamic issuance of privacy preserving credentials
US20140282984A1 (en) 2013-03-14 2014-09-18 Microsoft Corporation Service relationship and communication management
CN105308897B (zh) 2013-06-25 2019-09-13 诺基亚技术有限公司 用于渗透式社交联网中的匿名和可信认证的方法和装置

Also Published As

Publication number Publication date
EP4162647B1 (en) 2024-05-01
EP4162647A1 (en) 2023-04-12
WO2023027709A1 (en) 2023-03-02
JP7564244B2 (ja) 2024-10-08
CN116034596A (zh) 2023-04-28
JP2023542578A (ja) 2023-10-11
US20230308277A1 (en) 2023-09-28

Similar Documents

Publication Publication Date Title
JP7282982B2 (ja) グループ署名による匿名イベント証明
JP7564244B2 (ja) トークン償還による匿名認証
JP7376727B2 (ja) 暗号学的に安全な要求の検証
EP4007964A1 (en) Secure media delivery
EP4022845B1 (en) Cryptographically secure data protection
JP7189372B2 (ja) デバイスおよびアプリケーションの完全性の検証
JP7389235B2 (ja) 匿名イベント認証
CN110445744B (zh) 一种数据处理方法及装置
CN114731273B (zh) 以密码方式安全的数据保护
GB2612217A (en) Secure media delivery