KR20140102688A - 보안 통신 시스템 및 방법 - Google Patents

보안 통신 시스템 및 방법 Download PDF

Info

Publication number
KR20140102688A
KR20140102688A KR20147016330A KR20147016330A KR20140102688A KR 20140102688 A KR20140102688 A KR 20140102688A KR 20147016330 A KR20147016330 A KR 20147016330A KR 20147016330 A KR20147016330 A KR 20147016330A KR 20140102688 A KR20140102688 A KR 20140102688A
Authority
KR
South Korea
Prior art keywords
data
command
response
user
packet
Prior art date
Application number
KR20147016330A
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 KR20140102688A publication Critical patent/KR20140102688A/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H04W12/033—Protecting confidentiality, e.g. by encryption of the user plane, e.g. user's traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes
    • 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/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/73—Access point logical identity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/12—Setup of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks
    • H04W84/12—WLAN [Wireless Local Area Networks]

Abstract

실시예에서, 사용자 단말기로부터 데이터를 제한된 접속 환경에서 통신 네트워크를 통하여 복호화 컴포넌트로 전송하는 방법은, 사용자 단말기에서 사용자로부터 데이터를 사용자 단말기에서 수신하는 단계를 포함한다. 데이터가 민감 데이터라고 판단된 경우, 민감 데이터는 보안 암호화 키를 이용하여 암호화된다. 패킷은 터널링 프로토콜에 기초하여 생성되고, 그 패킷은 커맨드 데이터 및 암호화된 민감 데이터를 포함한다. 커맨드 데이터는 네트워크 컴포넌트의 주소, 커맨드 및 커맨드 식별자를 포함한다. 커맨드는 보안 암호화 키가 민감 데이터를 암호화하는데 이용되어진 것을 식별한다. 주소로 식별된 네트워크 컴포넌트에서, 패킷은 제 1 포트에서 수신하며; 커맨드는 판독되고; 패킷은 복호화를 위한 복호화 컴포넌트로 제 2 포트를 통해 전송되며, 그리고 응답 패킷은 응답 및 커맨드 식별자를 포함하여 사용자 단말기로 전송된다.

Description

보안 통신 시스템 및 방법{SECURE COMMUNICATION SYSTEM AND METHOD}
본 발명은 통신 시스템 및 방법에 관한 것이다.
패킷-기반(packet-based) 통신 시스템은 개인용 컴퓨터와 같은 디바이스(device)의 사용자가 인터넷과 같은 컴퓨터 네트워크를 통해 통신할 수 있도록 한다. 패킷-기반 통신 시스템은 인터넷 프로토콜을 통한 음성("VoIP") 통신 시스템을 포함한다. 이들 시스템은 유선(fixed line) 또는 이동(mobile) 네트워크 보다 종종 상당히 저렴하기 때문에 사용자에게 이익이 된다. 이는 특히 장거리 통신의 경우에 그럴 수 있다. VoIP 시스템을 이용하기 위하여, 사용자는 자신의 디바이스상에 클라이언트 소프트웨어(client software)를 설치하여 실행시켜야 한다. 클라이언트 소프트웨어는 등록 및 인증과 같은 다른 기능들 뿐만 아니라 VoIP 연결도 제공한다. 음성 통신에 추가하여, 클라이언트는 비디오 통화, 인스턴트(instant) 메시지("IM"), SMS 메시지, 및 음성 메일과 같은 추가적 특징 또한 제공할 수 있다.
패킷-기반 통신 시스템의 한 유형은 사설 프로토콜(proprietary protocol)에 기반한 피어-투-피어(peer-to-peer)("P2P") 토폴로지(topology)를 이용한다. 피어-투-피어 시스템에 액세스하기 위하여, 사용자는 P2P 소프트웨어 제공자에 의해 제공된 P2P 클라이언트 소프트웨어를 자신의 컴퓨터에서 실행시켜 P2P 시스템에 등록하여야 한다. 사용자가 P2P 시스템에 등록하면, 클라이언트 소프트웨어는 서버로부터 디지털 인증서를 제공받는다. 일단 클라이언트 소프트웨어가 인증서를 제공받게 되면, 뒤이어 서버의 추가 이용 없이 P2P 시스템의 사용자들간에 통신이 개통되어 라우팅될 수 있다. 특히, 사용자들은 하나 이상의 디지털 인증서(또는 사용자 신원 인증서, "UIC")의 교환에 기초한 P2P 시스템을 통해 그들 자신의 통신 루트를 수립할 수 있어 P2P 시스템에 액세스할 수 있다. 사용자들간의 디지털 인증서의 교환은 사용자의 신원 증명을 제공하고 사용자들은 P2P 시스템에서 적합하게 인가되어 인증된다. 따라서, 디지털 인증서의 제시는 사용자의 신원에 신뢰를 제공한다. 그러므로 통신이 서버를 이용하여 전송되지 않고 최종-사용자(end-user)에서 최종-사용자로 직접 전송된다는 사실이 피어-투-피어 통신의 특성이다. 이러한 P2P 시스템에 대한 더 상세한 것은 WO 2005/009019에 개시되어 있다.
패킷-기반 통신 시스템이 갖는 문제점은 충분한 대역폭을 갖는 인터넷과 신뢰할 만한 연결이 필요하다는 점이다. 이는 사용자가 알려진 고정 위치(자기 집과 같은)에 있을 때에는 일반적으로 문제가 되지 않지만, 이는 사용자가 여행중에 있을 때에는 특히 문제가 될 수 있다. 무선 근거리 통신망("WLAN") 액세스 포인트(access point) 및 적합한 핫스팟(hotspot) 소프트웨어에 의해 제공되는 무선 인터넷 핫스팟(hotspot)은 사용자가 여행중에 널리 이용할 수 있다. 이들은 종종 공항, 카페 및 정류장과 같은 공공 장소에서 이용될 수 있다. 그러나, 이들 핫스팟은 빈번하게 열려있지 않고 액세스가 제한되고 차단된다. 이들 핫스팟은 사용자가 핫스팟 운영자로부터 지불의 대가로 로그인 크리덴셜(login credential)을 얻도록 요구한다.
무선 인터넷 서비스 제공자 로밍("WISPr") 프로토콜과 같은 프로토콜은 핫스팟에 액세스하는데 이용될 수 있다. WISPr 프로토콜이 이용될 때, 한정된-액세스 핫스팟을 이용하여 인터넷에 연결하기 위해 시도중인 사용자는 핫스팟 운영자의 로그인 서버로 재전송(redirect)된다. 이러한 재전송은 사용자에게 로그인 페이지로 보여진다. 이 로그인 페이지는 사용자에게 사용자 이름 및 패스워드(password)(예컨대 이것이 사용자에 의해 이미 구매되었거나 미리 정해진 지불 합의의 일부로서 제공되었다면)를 입력하거나 또는 신용카드(또는 다른 지불수단) 내역을 입력하도록 촉구한다. 요구된 정보를 입력함으로써 사용자는 핫스팟과의 액세스를 획득하여 인터넷에 액세스할 수 있으며, 그에 따라서 과금된다.
이러한 방식으로 핫스팟에 액세스하는 것은 문제가 있다. 첫째, 사용자가 지불 내역을 핫스팟의 로그인 서버에 입력하면서 보안 문제가 존재한다. 사용자는 자신의 지불 내역 또는 개인 데이터를 핫스팟 제공자가 노출시키지 않는다고 충분히 신뢰하지 않으면 안된다. 둘째, 사용자에게 자신의 지불 내역을 직접 손으로 입력하도록 요구하기 때문에, 사용자가 지불 내역을 핫스팟 로그인 서버에 입력하는 것은 불편하다. 셋째, 이러한 정보를 수동으로 로그인하고 입력하는 것은 처리가 느리며 사용자가 패킷-기반 통신 시스템을 이용하기 위하여 인터넷에 신속히 액세스하기를 원하는 경우에 비효율적이다.
GB 2464553은 사용자가 패킷-기반 통신 시스템의 이용을 위해 이미 구매한 크레딧(credit)을 이용하여 사용자가 핫스팟에 액세스하기 위한 지불을 가능케 함으로써 한정된 WLAN 핫스팟에 액세스할 때 갖는 전술한 일부 문제들을 다룬다. 사용자가 이미 패킷-기반 통신 시스템을 이용하고 있기 때문에, 사용자는 패킷-기반 통신 소프트웨어의 제공자와 이미 빈번하게 지불 관계를 갖고 있다. 통상적으로, 이는 예컨대 인터넷과 공중교환전화망("PSTN") 사이에 전화를 걸기 위해 사용자가 구매해온 선불 크레딧의 형태로 존재한다.
사용자가 기존의 지불 합의를 가지고 있기 때문에, 사용자는 패킷-기반 통신 소프트웨어의 제공자와 신뢰를 갖고 있다. 따라서, 사용자는 개인 데이터 또는 로그인 크리덴셜을 핫스팟의 운영자에게 보다는 오히려 패킷-기반 통신 소프트웨어의 제공자에게 제공하는 것이 더욱 수월하다.
선불 크레딧을 이용하는 경우, 사용자는 핫스팟에 액세스하기를 원할 때마다 지불 내역을 입력할 필요가 없다. 대신에, 사용자는 기존의 지불 관계로 인해 자신의 로그인 크리덴셜을 패킷-기반 통신 네트워크에 제공하기만 하면 된다. 핫스팟에 액세스하기 위한 메커니즘은 통신 클라이언트 소프트웨어로 밀접하게 통합되어 핫스팟을 통해 패킷-기반 통신 시스템과 액세스를 획득하여 사용자의 처리 속도를 크게 올릴 수 있다.
그러나, 핫스팟에 액세스를 원하는 많은 사용자들은 자신들의 계정에 크레딧이 없기 때문에 상기 선불 크레딧을 이용할 수 없다.
선불 크레딧이 미리 얻어질 수 없는 핫스팟에 액세스를 위한 지불을 사용자에게 가능케 하는 것에는 여러 문제점들이 있다. 사용자는 인터넷 액세스를 여전히 이용할 수 없기 때문에 이때에는 크레딧을 얻을 수 없고, 따라서 표준 웹-기반 지불 방법들이 이용될 수 없다.
핫스팟은 패킷-기반 통신 소프트웨어 제공자의 제어하에 있지는 않지만 대신에 제3자에 의해 운영되기 때문에 보안 문제가 있다. 제3자는 적법한 것처럼 보이지만 사용자 크리덴셜 및/또는 지불 수단 내역을 수집할 목적으로 단지 존재하는 핫스팟을 개설한 악의적인 사용자일 수도 있다. 따라서, 제3자인 핫스팟 운영자에게 패킷-기반 통신 네트워크에서 사용자의 로그인 크리덴셜 및 지불 내역들을 노출시키는 것은 적절하지 않다.
게다가, 사용자는 크레딧을 얻기 위하여 지불 또는 유효한 크리덴셜의 제시 없이 인터넷에 액세스할 수가 없다.
본 발명의 일 양태에 따라, 제한된 접속 환경에서 통신 네트워크를 통하여 사용자 단말기(user terminal)에서 복호화 컴포넌트로 데이터를 전송하는 방법으로서,
상기 방법은 사용자 단말기에서, 사용자로부터 사용자 단말기에서 데이터를 수신하는 단계와, 상기 데이터가 민감(sensitive) 데이터라고 판단되면, 보안 암호화 키를 이용하여 상기 민감 데이터를 암호화하는 단계와, 터널링 프로토콜에 따라 패킷을 생성하는 단계 -상기 패킷은 네트워크 컴포넌트의 주소, 커맨드 데이터 및 암호화된 민감 데이터를 포함하고, 상기 커맨드 데이터는 커맨드 및 커맨드 식별자를 포함하며, 상기 커맨드는 보안 암호화 키가 상기 민감 데이터를 암호화하는데 이용되었음을 식별함- 패킷을 생성하는 단계를 포함하는, 데이터를 전송하는 방법이 제공된다.
본 발명은, 주소에서 확인된 네트워크 컴포넌트에서, 제 1 포트에서 패킷을 수신하는 단계와, 커맨드를 판독하는 단계와, 상기 패킷을 제 2 포트를 통하여 복호화를 위한 복호화 컴포넌트로 전송하는 단계와, 응답 및 커맨드 식별자를 포함하는 응답 패킷을 사용자 단말기로 전송하는 단계를 포함할 수 있다.
본 발명의 다른 양태에 따르면, 복호화 컴포넌트 및 네트워크 컴포넌트를 포함하는 통신 시스템이 제공되는데, 이 복호화 컴포넌트는 커맨드 데이터 및 암호화된 민감 데이터를 갖는 패킷들을 수신하기 위한 입력부와, 보안 키를 저장하는 메모리와, 암호화된 민감 데이터를 포함하는 수신된 패킷들을 복호화하고 상기 민감 데이터를 유효화하며 유효 응답을 생성하기 위한 보안 키와, 상기 복호화 컴포넌트에 연결되어 상기 보안 키와 상이한 세션(session) 키를 저장하는 메모리를 가지고 각각의 수신된 패킷에서 커맨드 데이터를 판독하여 상기 커맨드 데이터로부터 암호화 키를 식별하고 암호화 키가 세션 키인 경우 패킷들을 복호화하며 암호화 키가 보안 키인 경우 패킷들을 복호화 컴포넌트로 전송하도록 구성된 프로세서를 포함한 네트워크 컴포넌트를 이용하는 컴퓨터 프로그램을 실행하도록 구성된 프로세서를 포함한다.
상기 민감 데이터는 지불 데이터일 수 있다.
세션 암호화 키는 쌍을 이룬 키(paired key)가 네트워크 컴포넌트에 저장된 키 쌍(key pair) 중 하나일 수 있다. 보안 암호화 키는 쌍을 이룬 키가 복호화 컴포넌트에 저장되어 네트워크 컴포넌트에는 알려지지 않은, 키 쌍 중 하나일 수 있다.
본 발명의 또다른 양태는, 사용자가 적어도 보안 데이터 또는 세션 데이터를 입력하게 하도록 구성된 사용자 인터페이스와, 상기 데이터를 수신하고, 상기 데이터가 보안 데이터인지 또는 세션 데이터인지를 판단하며, 보안 암호화 키로 보안 데이터를 암호화하거나 세션 키로 세션 데이터를 암호화하고, 평문으로 된 커맨드 데이터 및 상기 암호화된 데이터를 포함하는 패킷을 생성하는 컴퓨터 프로그램을 실행하도록 구성된, 프로세서를 포함하되, 상기 커맨드 데이터는 커맨드 및 커맨드 식별자를 포함하며, 상기 커맨드는, 상기 보안 키가 이용되었는지 상기 세션 키가 이용되었는지 여부를 식별하는, 사용자 단말기를 제공한다.
컴퓨터 프로그램은 통신 네트워크에서 통신 이벤트(event)를 수립하는, 스카이프(Skype) TM과 같은 통신 클라이언트일 수 있다. 그러나, 기능성은 독립형 애플리케이션(application)으로, 또는 윈도우(Windows) TM과 같은 운영 시스템의 부분인 WIFI 네트워크와 같은 임의의 다른 관련 애플리케이션의 특징으로 구현될 수도 있다.
커맨드 데이터를 평문(plaint text)으로 제공함으로써, 커맨드를 수신하는 네트워크 컴포넌트가 복호화 컴포넌트를 위해 만들어진 데이터를 복호화할 수 없는 경우, 그럼에도 불구하고 커맨드가 복호화 컴포넌트에 전송되어야 하는지 여부를 판단할 수 있다.
본 발명의 추가적인 양태는, 통신 네트워크에 이용하기 위한 네트워크 컴포넌트로서, 상기 통신 네트워크와 패킷들을 교환하기 위한 제 1 포트; 보안 환경에서 복호화 컴포넌트와 패킷들을 교환하기 위한 제 2 포트; 컴퓨터 프로그램을 실행하도록 구성된 프로세서로서, 상기 제 1 포트로부터 패킷을 수신하고 -상기 패킷은 커맨드 및 커맨드 식별자를 포함한 커맨드 데이터 및 암호화된 데이터를 포함함-, 상기 커맨드를 판독하여 상기 데이터를 암호화하기 위해 보안 키가 이용되었는지 세션 키가 이용되었는지 여부를 판단하고, 세션 키가 이용된 경우 상기 데이터를 복호화하여 그 복호화된 데이터에 따르고, 보안 키가 이용된 경우 상기 패킷을 상기 제 2 포트로 전송하고 상기 제 1 포트를 통하여 응답 및 상기 커맨드 식별자를 포함하는 응답 패킷을 송신하는, 프로세서를 포함하는, 네트워크 컴포넌트를 제공한다.
이러한 맥락에서, 보안 환경은 제한된 접속 환경 및/또는 신용카드 처리 환경을 포괄한다.
본 발명의 또 다른 양태는, 통신 네트워크에서 네트워크 컴포넌트를 운영하는 방법으로서, 이 방법은 통신 네트워크, 암호화된 데이터를 포함한 패키징 및 커맨드 및 커맨드 식별자를 포함하는 커맨드 데이터를 갖는 네트워크 컴포넌트의 제 1 포트로부터 패킷을 수신하는 단계; 상기 커맨드를 판독하여 보안 키 또는 세션 키가 상기 데이터를 암호화하는데 사용되어졌는지 여부를 판단하며, 세션 키가 사용되어진 경우 상기 데이터를 복호화하여 그 복호화된 데이터에 따르고, 보안 키가 사용되어진 경우 패킷들을 복호화 컴포넌트와 교환하기 위하여 제 2 포트로 송신하며 응답 및 커맨드 식별자를 포함하는 응답 패킷을 송신하는 단계를 포함한다.
또한 본 발명은 프로세서에 의해 실행될 때 상기 방법을 구현하는 컴퓨터 프로그램 제품을 제공한다.
본 발명에 대한 더 나은 이해를 위해 그리고 그 동일한 것이 어떻게 실행될 수 있는지를 보이기 위해, 이제, 한 예로서, 다음 도면을 참조하여 이루어질 것이다:
도 1은 패킷-기반 통신 시스템을 도시한 도면;
도 2는 통신 클라이언트를 실행하는 사용자 단말기를 도시한 도면;
도 3은 통신 시스템에서 컴포넌트들의 개략적인 블록도;
도 4는 보안 데이터를 송신하기 위한 신호 보안 차트(signalling chart)를 도시한 도면;
도 4a는 WLAN 핫스팟에 액세스 처리를 위한 신호 보안 차트를 도시한 도면; 및
도 4b는 상태 질의를 위한 신호 보안 차트를 도시한 도면.
상술한 바와 같이, 본 발명의 실시예들은 제한된 접속 환경에서, 특히 인터넷의 액세스가 여전히 허여되지 않는 환경에서 데이터 전송 문제를 해결하기 위한 해법을 제공하는데 유용하다. 인터넷 액세스가 개시되기 훨씬 전에, 데이터를 백엔드(backend) 서버들과 교환하기 위해 DNS 터널링을 이용한 액세스(access) 프로토콜이 GB 2464553에 개시되어 있다. 여기서, 프로토콜은 클라이언트에서 백엔드 서버들로 지불 내역을 옮기도록 확장되며, 그 결과 사용자들은 크레딧을 구입할 수 있고 핫스팟을 통하여 인터넷 액세스를 할 수 있다.
우선, 도 1을 참조하면, 도 1은 패킷-기반 통신 시스템(100)을 도시한다. 여기서 도시한 실시예는 P2P 통신 시스템을 참조하여 기재되어 있지만, 비-P2P, VoIP 또는 IM 시스템과 같은 다른 유형의 통신 시스템도 역시 이용될 수 있음에 유의하자. 통신 시스템의 제 1 사용자("톰 스미스(Tom Smith)(102)로 지칭함)는 인터넷과 같은 네트워크(106)에 연결할 수 있는 사용자 단말기(104)를 조작한다. 예컨대, 사용자 단말기(104)는 네트워크(106)에 연결할 수 있는 개인용 컴퓨터("PC")(예컨대, 윈도우(WindowsTM), 맥(Mac OSTM) 및 리눅스(LinuxTM) PC), 개인 휴대용 정보 단말기("PDA"), 이동 전화(mobile phone), 게임 디바이스 또는 다른 임베디드(embedded) 디바이스일 수 있다. 사용자 단말기(104)는 정보를 수신하여 디바이스를 갖는 사용자(102)에게 정보를 출력하도록 구성된다. 본 발명의 바람직한 실시예에서, 사용자 디바이스는 스크린(screen)과 같은 디스플레이(display), 및 키보드(keyboard), 마우스(mouse), 조이스틱(joystick) 및/또는 터치-스크린(touch-screen)과 같은 입력 디바이스를 포함한다.
도 1에 도시된 예에서, 사용자 단말기(104)는 WLAN 액세스 노드(access node)(107)에 연결할 수 있는 네트워크 인터페이스(interface)를 포함한다. 액세스 노드는 액세스 노드(107)에 무선 연결을 제공하는 액세스 포인트(access point)("AP")(108), 및 사용자 단말기가 액세스 노드(107)에 연결가능한 지 여부를 제어하는 핫스팟 포털(hotspot portal)(109)을 포함한다. AP(108) 및 핫스팟 포털(109)은 단일체로 결합될 수 있거나 또는 다른 분리체로 제공될 수 있다. 그러나, 구조적인 레이아웃(layout)에 상관없이, 두 요소의 기능성은 동일한 것이어서 핫스팟 포털(109)은 사용자 단말기가 AP(108)를 통해 네트워크(106)(그래서 인터넷)에 연결될 수 있는지 여부를 제어한다. 핫스팟 포털(109)은 인증 및 지불에 대한 재전송(redirection)과 같은 기능성을 제공한다.
사용자 단말기(104)는 통신 클라이언트(110)를 운영하며 이는 소프트웨어 제공자에 의해 제공된다. 통신 클라이언트(110)는 사용자 단말기(104)내 로컬 프로세서(local processor)상에서 실행되는 소프트웨어 프로그램이다. 또한 사용자 단말기(104)는 송수화기(112)에 연결되고, 이는 사용자가 음성 통화에서 듣고 말할 수 있도록 하는 스피커 및 마이크로폰(microphone)을 포함한다. 마이크로폰 및 스피커는 반드시 통상적인 전화 송수화기의 형태이어야 하는 것은 아니지만, 사용자 단말기(104)에 독립적으로 연결되거나 또는 사용자 단말기(104) 자체에 통합된 개별적인 확성기 및 마이크로폰으로서, 통합된 마이크로폰을 갖는 헤드폰 또는 이어폰의 형태일 수 있다.
사용자(102)가 WLAN 액세스 노드(107)를 통하여 네트워크(106)에 대한 액세스를 얻을 수 있다고 가정하면, 연락처 리스트내 사용자들로의 VoIP 통화는 마우스와 같은 포인팅 디바이스(point device)를 이용하여 사용자 인터페이스상의 연락처(contact)를 선택하여 "통화(call)" 버튼을 클릭(click)함으로써 통신 시스템을 통하여 개시될 수도 있다. 다시 도 1을 참조하면, 통화 셋-업(set-up)은 사설 프로토콜을 이용하여 실행되며, 송화 사용자와 수화 사용자 사이에 네트워크(106)를 통한 루트(route)는 서버들을 이용함이 없이도 피어-투-피어 시스템에 의해 결정된다. 예컨대 제 1 사용자인 "톰 스미스"(102)는 제 2 사용자인 "케빈 잭슨(Kevin Jackson)"을 호출할 수 있다.
디지털 인증서의 제시를 통한 인증 후에(사용자들이 통신 시스템의 진실한 가입자인 사실을 증명하기 위해 - WO 2005/009019에 더 상세히 기재되어 있음), 통화는 VoIP를 이용하여 이루어질 수 있다. 클라이언트(110)는 VoIP 패킷들의 인코딩(encoding) 및 디코딩(decoding)을 수행한다. 사용자 단말기(104)로부터의 VoIP 패킷들은 액세스 노드(107)를 통하여 네트워크(106)로 송신되어 네트워크 인터페이스(118)를 통하여 수화자(114)의 컴퓨터 단말기(116)로 보내질 수 있다. 수화 사용자(114)의 사용자 단말기(116)에서 운영하는 클라이언트(120)(클라이언트(110)와 유사)는 송수화기(122)를 이용하여 수화 사용자가 들을 수 있는 오디오(audio) 신호를 생성하기 위하여 VoIP 패킷들을 디코딩한다. 반대로, 제 2 사용자(114)가 송수화기(122)로 통화하는 경우, 사용자 단말기(116)상에서 실행되는 클라이언트(120)는 오디오 신호들을 VoIP 패킷들로 인코딩하여 이들을 네트워크(106)를 통하여 사용자 단말기(104)로 송신한다. 사용자 단말기(104)상에서 실행되는 클라이언트(110)는 VoIP를 디코딩하여 송수화기(112)를 갖는 사용자가 들을 수 있는 오디오 신호를 생성한다.
상술된 바와 같이 사용자들(102 및 114와 같은) 사이의 통화를 위한 VoIP 패킷들은 네트워크(106)만을 통하여 전달되며, 공중교환전화망("PSTN")(124)은 관여하지 않는다. 게다가, 시스템의 P2P 성질로 인하여, 통신 시스템의 사용자들간의 실제 음성 통화는 중앙 서버가 이용되지 않은 채로 이루어질 수 있다. 이는, 네트워크 규모를 용이하게 조정하여 높은 음성 품질을 유지하며 통화가 사용자들에게 무료로 이루어질 수 있는 이점을 가진다. 부가적으로, 또한 PSTN 네트워크(124)에 호출을 라우팅(routing)함으로써, 패킷-기반 통신 시스템을 이용하여 클라이언트(110, 122)로부터 유선 전화(fixed-line) 또는 이동 전화(mobile telephone)(126)로 통화가 이루어질 수 있다. 유사하게, 유선 전화 또는 이동 전화(126)로부터의 통화는 PSTN(124)을 통하여 패킷-기반 통신 시스템에서 이루어질 수 있다.
음성 통화에 부가하여, 클라이언트(110)를 갖는 사용자는 또한 여러 다른 방법들, 예컨대 인스턴트 메시지(또한 채팅 메시지로도 알려진), 파일 전송, 연락처로 음성메일 전달 또는 비디오 통화 설정에 의해 사용자들과 통신할 수 있다.
도 2는 클라이언트(110)가 실행되는 사용자 단말기(104)의 상세도를 도시한다. 사용자 단말기(104)는, 디스플레이 인터페이스(305)를 통해 스크린과 같은 디스플레이(304)와 연결되고 USB와 같은 인터페이스(309)를 통해 키보드(306)와 같은 입력 디바이스 및 마우스(308)와 같은 포인팅 디바이스와 연결되는 중앙 처리 유닛("CPU")을 포함한다. 대안적인 단말기에서, 키패드(keypad), 터치-스크린 및/또는 조이스틱과 같은, 입력 디바이스와 포인팅 디바이스는 단말기에 통합될 수 있다. 오디오 출력 디바이스(310)(예컨대 스피커) 및 오디오 입력 디바이스(312)(예컨대 마이크로폰)는 오디오 인터페이스(313)를 통해 연결된다. 오디오 출력 디바이스(310) 및 오디오 입력 디바이스(312)는 송수화기(112) 또는 헤드셋(headset)과 통합되거나, 또는 분리될 수도 있다. CPU(302)는 WLAN AP에 연결하기 위하여 네트워크 인터페이스(311)에 연결된다.
또한 도 2는 CPU(302)상에서 실행되는 운영 시스템("OS")(314)을 도시한다. OS(314) 상부에 클라이언트(110)를 위한 소프트웨어 스택(stack)(316)이 위치한다. 소프트웨어 스택은 프로토콜 층(318), 클라이언트 엔진 층(320) 및 클라이언트 사용자 인터페이스 층("UI")(322)을 나타낸다. 각각의 층은 특정 기능을 맡고 있다. 각 층은 보통 두 개의 다른 층과 통신하기 때문에, 이들은 도 3에 도시된 바와 같이 스택으로 배열되는 것으로 여겨진다. 운영 시스템(314)은 컴퓨터의 하드웨어 자원을 관리하고 네트워크 인터페이스(108)를 통하여 네트워크로 또는 네트워크로부터 송신되는 데이터를 처리한다. 클라이언트 소프트웨어의 클라이언트 프로토콜 층(318)은 운영 시스템(314)과 통신하며 통신 시스템을 통한 연결들을 관리한다. 보다 높은 레벨 처리를 필요로 하는 프로세스들은 클라이언트 엔진 층(320)을 통과한다. 또한 클라이언트 엔진(320)은 클라이언트 사용자 인터페이스 층(322)과 통신한다. 클라이언트 엔진(320)은 클라이언트의 사용자 인터페이스를 통하여 사용자에게 정보를 제공하고(도 2에 도시된 바와 같이) 사용자 인터페이스를 통하여 사용자로부터의 정보를 수신하기 위하여 클라이언트 사용자 인터페이스 층(322)을 제어하도록 배열될 수도 있다.
또한 도시된 바와 같이, 액세스 관리자(324)가 클라이언트(110)에 통합된다. 액세스 관리자(324)는 WLAN 핫스팟에의 액세스 관리를 담당한다. 바람직한 실시예에서, 액세스 관리자(324)는 클라이언트(110)에 통합되어 사용자에게 정보를 디스플레이(display)하기 위하여 클라이언트 UI 층(322)을 이용하며 통신 시스템에 연결하기 위하여 클라이언트 프로토콜 층(318)을 이용한다. 대안적인 실시예에서, 액세스 관리자(324)는 OS(314)상에서 실행되는 독립형 소프트웨어로서 구현될 수 있지만, 클라이언트(110)와 통신하고 있다.
도 3은 도 1의 통신 시스템에서의 이용을 위한 보안 액세스 시스템의 컴포넌트(component)를 도시하는 개략적인 블록도이다. 또한 도 1에 도시된 일부 컴포넌트가 도 3에 도시되어 동일한 참조부호로 표시된다. 도 1에 도시된 컴포넌트에 부가하여, 도 3은 포털(portal)(109)에 연결된 월드와이드 웹 서버(world wide web server)(200) 및 도메인 네임 서버(domain name server)(202)를 도시한다.
도 1 및 도 3은 통신 클라이언트 소프트웨어 제공자 도메인 네임 서버("DNS")(128)를 추가로 도시한다. DNS 프로토콜은 공지기술인 DNS 터널링(tunnelling)을 이용하여 핫스팟(109)의 액세스 제한을 우회(bypass)하는데 사용된다. 통신 클라이언트 소프트웨어 제공자 도메인 서버("DNS")(128)는 실제 도메인 네임 서버를 반드시 필요로 하지는 않지만, DNS 프로토콜을 이용하여 통신하도록 구성된 특별히 구성된 백엔드 서버(backend server)일 수 있다는 것에 유의하자. 이미 GB 2464553에서 알려진 방식으로 핫스팟에 액세스를 제공하는데 사용될 수 있고 이후에 간결히 기술되는 액세스 검색 데이터베이스(130)는 도 1 및 도 3에 추가로 도시된다.
도 3에 도시된 보안 액세스 시스템은 보안 환경, 예컨대 DNS 백엔드 서버(128)및 보안 웹 지불 API(212)를 연결하는 암호서비스 컴포넌트(213)를 포함하는 지불 제어 산업 환경(210)을 포함한다. 지불 취급자 통합 서비스(216)는 암호서비스 컴포넌트(214)에 연결된 주문 및 카드 데이터를 위한 데이터베이스(218)에 연결된다. 암호서비스 컴포넌트(214)는 API(212)를 통하여 액세스 데이터베이스(220)에 연결된다.
데이터베이스(220)는 본 명세서에서 논의된 지불 프로세스에서 사용자 크리덴셜을 유효화하도록 제공한다.
신용카드 번호 처리는 PCI 규정준수를 위한 한 세트의 엄격한 규칙에 부합하여야 하며, 카드 번호 및 다른 민감 데이터가 클라이언트 단말기로부터 보안을 고려한 PCI 규정준수 환경(210)에 엔드 투 엔드(end-to-end) 암호화되어야 한다는 주된 요건에 부합하여야 한다.
이를 달성하기 위해 새로운 패킷 유형들이 세션(이후에 기재된)을 수립하는데 사용되는 액세스 프로토콜을 확장하도록 도입된다. 백엔드 서버가 복호화할 수 없는 지불 트래픽(traffic)의 경우, 새로운 패킷 유형들은 민감 데이터의 암호화된 페이로드(payload)를 이송한다. 서버(128)는 암호서비스 컴포넌트(214)에 지불 트래픽을 전송한다.
보안은 세션 패킷들 및 보안 지불 패킷들을 암호화하기 위한 상이한 공중 키 암호화 키 쌍을 이용함으로써 유지된다.
이제 도 4를 참조하면, 도 4는 인터넷 액세스를 수립하지 않은 상태로 지불이 이루어질 수 있는 수단에 의해 클라이언트 및 PCI 환경 사이의 보안 통신을 달성하기 위한 프로세스를 기술한다.
이 지불 방법은 단계들(S412 및 S414) 사이의 도 4a와 관련하여 이후에 기재된 세션 수립 프로세스와는 독립적이다.
이하에서, 지불 메시지는 AP(108)의 DNS 포털을 경유하여 네트워크(106)를 통해 통신 클라이언트 소프트웨어 제공자 도메인 네임 서버("DNS")(128)로 보내지는 DNS 질의(query)로서 인코딩된다. DNS 프로토콜은 공지기술인 DNS 터널링을 이용하여 핫스팟(109)의 액세스 제한을 우회하는데 사용된다.
이는 기본형 이름(Canonical name)("CNAME") 기록 DNS 질의를 이용하여 달성된다. 질의 및 응답 형식(format) 모두 엄격한 규칙에 부합해야만 한다. 온전히 자격이 부여된 도메인 네임의 전체 길이("FDQN")는 63 문자까지의 라벨들이 길이 바이트(byte)와 혼합하는 내부 형식으로 나타낼 때 255 바이트를 초과할 수 없다. 최대 길이 라벨을 이용할 때, 페이로드를 이송하기 위한 250 문자가 존재한다. Base32 인코딩은 사전어휘 abcdefghjklmnopqrstuvwxyz0123456과 함께 사용될 수 있다. 각 문자는 이진법 페이로드의 5비트를 이송할 수 있는데, 이는 각 응답 및 질의가 1248 비트를 이송할 수 있음을 의미한다. 1152 비트 리베스트 샤미르 아들만(Rivest Shamir Adleman)("RSA") 키는 암호화를 위해 사용된다. 질의의 판독가능한 형태는 "data.data.data.access.skype.com"과 동일한 형태일 수 있다. 각 DNS 터널링 패킷은 백엔드 DNS 서버와 같이, 패킷의 수신처를 식별하는 주소를 가진다.
S441에서, 개시 지불 요청이 단말기(104)내의 클라이언트(110)에서 전송된다. 개시 지불 요청은 다음과 같은 형태이다.
필드 길이 표현
커맨드(command) 1 커맨드＿개시 트랜잭션=6
(CMD＿BEGINTRANSACTION=6)
커맨드 ID(cmdid) 1 클라이언트 커맨드 ID 할당, 서버는 커맨드들 및 응답들의 일치에 응답하여 이것을 되돌려 보낼 것이다.
챌린지(challenge) 16 임의의 클라이언트 챌린지
스카이프 이름
(skypename)		 32 스트링, 스카이프 이름이 정확히 32 문자길이일 경우 비-제로 종료될 수 있다.
pwdhash 16 패스워드 해시(password hash)
본 명세서에서 "스카이퍼(Skyper)" 및 "스카이프(Skype)(TM)" 이름의 참조부호는 스카이프 통신 시스템에 한정되는 것은 아니라는 점을 알려둔다 - 즉 임의의 사용자 이름 또는 로그인 크리덴셜이 사용될 수 있다.
커맨드 및 CMD ID 필드들(평문으로 존재하는)을 제외하고, 요청내 잔여 필드들 각각은 보안 RSA 개인 키와 함께 암호화되는 점에 유의하자. 지불 RSA 개인 키는 본 명세서에서 지불 목적을 위해 배타적으로 사용되는 11552 비트의 리베스트, 샤미르, 아들만 키이다. 이후에 기재된 바와 같이, 상이한 RSA 키는 세션들을 수립하는데 사용된다. DNS 서버(128)는 보안, 지불 RSA 키에 대한 액세스를 갖지 않으므로 이 요청을 복호화할 수 없다. DNS 서버(128)는 이 요청을 암호 서비스 컴포넌트(214)로 전송한다. 보안 키가 사용되었다는 사실은 COMMAND 필드에 의해 식별된다. 사실상, 서버(128)는 암호화 필드들을 블롭(blob)으로서 취급한다. 서버(128)는 요청 페이로드와 같이 변경되지 않은 보안 웹 지불 API(212)를 통해 요청을 암호서비스 컴포넌트(214)로 전송한다.
지불 RSA 키의 개인적인 부분은 보안 환경내에서 암호서비스 컴포넌트에게만 알려져 있으며, 암호컴포넌트는 사용자를 인증하기 위하여 키의 사적인 부분을 이용한다. 본 실시예에서 인증은 보안 웹.api를 이용하지만 인증 방법은 다른 유형의 사용자에 대해 상이할 수 있다. 트랜잭션(transaction) 기록은 임의의 트랜잭션 ID 번호로 데이터베이스 내에 생성된다. 이는 S442로서 표시된다. 암호서비스 컴포넌트(214)는 다음 형태의 계속적인 트랜잭션 메시지(S443)를 리턴한다.
필드 길이 표현
커맨드(command) 1 커맨드＿계속 트랜잭션=7
(CMD＿CONTINUETRANSACTION=7)
rc4 초기화 벡터 4 이진값
결과 코드 1 바이트 결과＿계속(RESULT＿CONTINUE),
결과＿안됨＿인증(RESULT＿NOT＿AUTHENTICATED),
결과＿무효＿트랜잭션(RESULT＿INVALID＿TRANSACTION),
결과＿지불＿실패(RESULT＿PAYMENT＿FAILED)
커맨드ID(Cmdid) 1 클라이언트 커맨드 ID 할당, 서버는 커맨드들 및 응답들의 일치에 응답하여 이것을 되돌려 보낼 것이다.
트랜잭션 ID 16
상기 메시지에서, 트랜잭션 ID는 MD5(클라이언트＿R 챌린지, "암호화", 초기화＿벡터)로 설정된 RC4 키를 이용하여 RC4 초기화 벡터를 포함하는 필드로 암호화된다. 다른 대칭 암호화 알고리즘은 상이한 구현, 예컨대 AES, DES 등에서 사용될 수 있다는 점에 유의하자. cmdid 필드는 클라이언트에 의해 할당된 커맨드 ID를 포함한다. 결과 코드 필드는 상태 정보를 클라이언트에게 제공하는 응답을 수용한다. 계속적인 트랜잭션 메시지는 서버(128)로 리턴되고 그 후 클라이언트(110)로 리턴되며 클라이언트가 S444에서 다음 형식의 제품 상세 메시지를 리턴한다.
필드 길이 표현
커맨드(command) 1 커맨드＿제품 상세=8
(CMD＿PRODUCTDETAILS=8)
커맨드 ID(cmdid) 1 클라이언트 커맨드 ID 할당, 서버는 커맨드들 및 응답들의 일치에 응답하여 이것을 되돌려 보낼 것이다.
챌린지(challenge) 16 임의의 클라이언트 챌린지
트랜잭션 ID 16
제품(product) 1 제품 ID(0=스카이프 크레딧, 1=자동-톱업을 갖는 스카이프 크레딧)
총액(amount) 4 지불 통화 총액(유닛32 네트워크 바이트 주문)
국가(country) 2 ISO 2 문자 코드. 결제 국가(VAT를 결정하기 위한)
제품 상세가 수락되면, 서버(128)는 S445에서 계속적인 트랜잭션 메시지로 응답한다. 제품 상세 메시지에서, 커맨드 및 CMD ID를 제외한 모든 필드는 지불 RSA 키를 이용하여 암호화된다. 따라서 이들은 복호화 및 검증을 위해 암호서비스 컴포넌트(214)에 공급된다.
계속적인 트랜잭션 메시지는 클라이언트(104)에서 수신된다. 지불 상세는 클라이언트에 의해 S416에서 암호서비스 컴포넌트(214)에 송신된 지불 상세 메시지로 표현된다. 커맨드들 및 응답들의 전체 흐름은 사용자가 사용자 인터페이스에서 자신에게 디스플레이된 스크린에 모든 상세를 입력하고 난 이후에 발생한다는 점에 유의하자. 그 후 3개 커맨드의 시퀀스(sequence)가 클라이언트에 의해 자동으로 발행된다.
필드 길이 표현
커맨드(command) 1 커맨드＿지불 내역=9
(CMD＿PAYMENTDETAILS=9)
커맨드 ID(cmdid) 1 클라이언트 커맨드 ID 할당, 서버는 커맨드들 및 응답들의 일치에 응답하여 이것을 되돌려 보낼 것이다.
챌린지(challenge) 16 임의의 클라이언트 챌린지
트랜잭션 ID 16
카드 종류 1 0=알수없음, 1=비자, 2=마스터카드
카드 번호 10 최대 19 디지트, 인코딩된 BCD , 종료를 추가하는데 사용된 0xf
만료일(expdate) 2 MM/YY, 인코딩된 BCD, 최초 바이트에서 월, 두번째 바이트에서 년
카드홀더＿이름 26 이름 길이가 26 문자 이하이면 0을 추가
유효 번호 2 3 또는 4 디지트 유효 번호. 추가를 위한 0xf
커맨드 및 CMD ID 필드(평문으로 존재하는)를 제외한 지불 내역 메시지내의 필드들은 지불 RSA 키를 이용하여 인코딩된다. 지불 내역을 수신하면, 암호서비스 컴포넌트(214)는 지불 내역을 복호화하고 트랜잭션 ID에 기초하여 트랜잭션을 위한 미리 저장된 데이터를 찾고 지불을 인증하기 위하여 PCI 데이터베이스(218)를 이용하는 웹 지불 API(212)를 위한 요청 메시지를 생성한다. S448에서, 지불 응답은 바람직하게는 임의의 번호 또는 약간의 다른 예측할 수 없는 파라미터(parameter) 형태로, 지불 ID를 포함하는 보안 웹 API(212)에 의해 생성된다. 지불 ID는 암호서비스 컴포넌트(214)에 의해 지불 응답으로 표현되며, 그 응답은 DNS 서버(128)로 리턴되고 그곳에서 클라이언트로 리턴된다. 지불 응답의 형식은 아래에 주어진 바와 같다.
필드 길이 표현
커맨드(command) 1 커맨드＿지불＿응답=10
(CMD＿PAYMENT＿RESPONSE=10)
rc4 초기화 벡터 4 이진값
결과 코드 1 바이트 결과＿무효＿트랜잭션(RESULT＿INVALID＿TRANSACTION),
결과＿지불＿계류(RESULT＿PAYMENT＿PENDING),
결과＿지불＿완료(RESULT＿PAYMENT＿COMPLETED),
결과＿지불＿실패(RESULT＿PAYMENT＿FAILED)
커맨드ID(cmdid) 1 클라이언트 커맨드 ID 할당, 서버는 커맨드들 및 응답들의 일치에 응답하여 이것을 되돌려 보낼 것이다.
트랜잭션 ID 16
지불 ID 16 Sec웹 제출 지불 응답의 id 주문, 지불 Id len이 16보다 작을 경우 제로(zero) 종료된 C 스트링
이제 개시 트랜잭션 메시지(S442)에 대한 응답(S443) 및 제품 상세 메시지에 대한 응답(S445)으로서 제공되는 계속적인 트랜잭션 메시지로 돌아간다. 이들 응답 모두에서, 결과 코드 필드는 4개의 가능한 응답들 중 하나를 수용할 수 있다:
ㆍ 결과＿계속(RESULT＿CONTINUE)
ㆍ 결과＿안됨＿인증(RESULT＿NOT＿AUTHENTICATED)
ㆍ 결과＿무효＿트랜잭션(RESULT＿INVALID＿TRANSACTION)
ㆍ 결과＿지불＿실패(RESULT＿PAYMENT＿FAILED)
대부분의 경우에, 이들 결과 선택은 복호화 및 인증의 결과에 의존하는 암호서비스 컴포넌트(214)에 의해 DNS 서버에 제공된다. 그러나, 암호서비스 컴포넌트(214)가 응답에 실패하면, 네트워크 컴포넌트는 네번째 결과 선택(RESULT＿PAYMENT＿FAILED) 자체를 생성할 수 있다. DNS 서버는 평문으로 되돌려 전송된 커맨드 코드, RC4 초기화 벡터 코드, 커맨드 ID 및 결과 코드와 함께 표 2에 주어진 형식을 갖는 메시지를 생성한다. 트랜잭션 ID가 존재하지 않기 때문에, 암호화될 페이로드의 어떤 부분도 필요하지 않다. 또한, 암호화할 부분이 없기 때문에, RC4 초기화 벡터 코드도 관련이 없다.
일단 클라이언트가 지불 ID(S448에서 생성된 지불 응답 메시지에 제공된)를 갖는다면, 아래에 주어진 형식(도 4B를 참조)을 갖는 지불 상태 질의 메시지를 이용하여 지불 상태에 대해 질문할 수 있다.
필드 길이 표현
커맨드(command) 1 커맨드＿지불＿상태＿질의=11
(CMD＿PAYMENT＿STATUS＿QUERY=11)
커맨드 ID(cmdid) 1 클라이언트 커맨드 ID 할당, 서버는 커맨드들 및 응답들의 일치에 응답하여 이것을 되돌려 보낼 것이다.
챌린지(challenge) 16 임의의 클라이언트 챌린지
스카이프 이름
(skypename)		 32 스트링, 스카이프 이름이 정확히 32 문자길이라면 비-제로 종료될 수 있다.
pwdhash 16 패스워드 해시(password hash)
지불 ID 16
상태 질의 메시지는 이를 복호화를 위한 암호서비스 컴포넌트(214)로 전달하는 DNS 서버(128)에 제공된다. 암호서비스 컴포넌트(214)는 PCI 데이터베이스(218)에 액세스하여 지불 상태를 확인하기 위하여 보안 웹 지불 API를 이용한다. 지불 상태는 보안 웹 API(212)에 의해 암호서비스 컴포넌트(214)로 리턴되며, 암호서비스 컴포넌트는 DNS 서버(128)에서 단말기(104)의 클라이언트(110)로 전달된 아래에 명시한 바와 같은 형식을 갖는 지불 상태 결과 메시지를 생성한다.
필드 길이 표현
커맨드(command) 1 커맨드＿지불＿상태＿응답=12
(CMD＿PAYMENT＿STATUS＿RESPONSE=12)
rc4 초기화 벡터 4 이진값
결과 코드 1 바이트 결과＿지불＿완료(RESULT＿PAYMENT＿COMPLETED),
결과＿무효＿지불(RESULT＿INVALID＿PAYMENT),
결과＿지불＿실패(RESULT＿PAYMENT＿FAILED),
결과＿지불＿계류(RESULT＿PAYMENT＿PENDING)
커맨드ID(cmdid) 1 클라이언트 커맨드 ID 할당, 서버는 커맨드들 및 응답들의 일치에 응답하여 이것을 되돌려 보낼 것이다.
지불 ID 16
상기 방법은 제한된 접속 환경에서 보안 데이터를 전송하는 문제를 해결한다. 일단 지불이 이루어지면, 사용자는 크레딧을 수신할 수 있고 따라서 이때 이들은 예컨대 GB 2464553에 주어진 바와 같은 기술을 이용하여 선불 크레딧으로 핫스팟에 액세스할 수 있으며 도 4A에 관련하여 이하 더욱 상세히 기술된다. 다음에서, 질의 및 응답 형식 또한 상술한 바와 같은 DNS에 대해 명시된 규칙을 준수해야 한다. 게다가, RSA 키는 암호화를 위해 사용되지만, 이는 지불 내역을 교환하기 위한 암호서비스 컴포넌트를 갖는 보안 교환을 위해 사용되는 RSA 키와는 상이하다. 즉, 크레딧을 이용하여 핫스팟에 액세스할 목적으로 DNS 서버에 액세스하기 위해 그리고 지불할 목적으로 암호서비스 컴포넌트에 액세스하기 위해 패킷을 암호화하기 위한 상이한 공중 키 암호화 키 쌍이 존재한다.
지불 흐름이 세션 수립과 독립적이지만, 이제 세션 수립 방법이 설명된다. 일 실시예에서, SSID 요청 및 토큰(token) 요청(이하 기술되는 바와 같은)은 사용자가 지불 스크린을 제공받기 전에 수행되며, 따라서 지불 커맨드 흐름은 도 4A에 도시된 단계들을 따르며, 그 후 토큰은 일시 중단되기 때문에 세션 수립 프로세스가 반복된다.
이제 도 4A로 돌아가면, 제 1 단계로서(도면에는 도시되지 않은), 클라이언트가 설치된 운영 시스템(314)은 이용가능한 무선 네트워크를 스캔(scan)한다. 운영 시스템은 기억된 액세스 포인트에 자동으로 연결될 수 있거나 또는 사용자가 액세스 포인트를 선택하도록 촉구할 수 있다. OS(314)에 의해 실행된 스캐닝 동작은 사용중인 사용자 단말기(104) 및 운영중인 OS에 의존한다.
액세스 관리자(324)(도 2에서)는 네트워크 인터페이스(311)에서 발생하는 변화들을 감지한다. 이는 액세스 관리자(324)가 네트워크 인터페이스 이벤트를 알리는 것 또는 액세스 관리자에 의해 주기적으로 질문하는 것 중 어느 하나에 의해 달성될 수 있다. 이를 위해 사용된 메커니즘은 해당 사용자 단말기(104)에 의존한다.
네트워크 인터페이스에서의 변화가 감지될 경우 액세스 관리자(324)는 OS(314)의 스캔에 의해 발견된 AP(108)의 서비스 세트 식별자("SSID")를 판독한다. 이것에 반응하여, 액세스 관리자(324)는 SSID 정보 질의를 생성한다. 이러한 질의는 액세스 관리자가 해당 핫스팟(109)에 로그인하는 것이 가능한지 여부를 탐색하여 기존의 지불 크레딧을 이용한 액세스 비용을 계산하는데 이용된다. 이를 실행하기 위하여, 액세스 관리자(324)는 승인 가능한 SSID들의 데이터베이스를 수용한 서버에 네트워크(106)를 통하여 SSID 정보 질의를 전송하는 것이 필요하다. 그러나, 일반적인 네트워크(106)와의 액세스는 핫스팟(109)에 의해 제한된다. 대안적인 실시예에서, 승인 가능한 SSID들의 데이터베이스는 사용자 단말기에서 유지될 수 있지만, 이는 관리하는데 있어 훨씬 어렵다. 지불 메시지 때문에 SSID 정보 질의는 DNS 질의로서 인코딩된다.
액세스 관리자(324)로부터 통신 클라이언트 소프트웨어 제공자 DNS 서버(128)로 전송된 SSID 정보 질의는, 무선 LAN AP(108)를 식별하는 SSID, (AP(108)의 물리적인 네트워크 인터페이스를 식별하는)매체 액세스 제어("MAC") 주소 및 선택적으로 클라이언트(110)에 로그인된 사용자(102)의 사용자 이름(스카이프 이름)을 포함한다.
보다 구체적으로, SSID 정보 질의의 페이로드는 다음 데이터를 포함한다.
ㆍ커맨드(command) - 1 바이트(byte), 페이로드가 SSID 정보 요청임을 나타낸다.
ㆍ커맨드 ID(cmdid) - 1 바이트, 클라이언트 할당 커맨드 ID. DNS 서버는 커맨드들 및 응답들의 일치에 응답하여 이것을 되돌려 보낼 것이다.
ㆍ사용자 이름(user name) - 32 바이트, 스트링(string), 사용자 이름이 정확하게 32 바이크 길이일 경우 비-제로(non-zero) 종료될 수 있다.
ㆍ액세스 포인트 SSID - 32 바이트, 스트링, SSID가 정확하게 32 바이트 길이일 경우 비-제로 종료될 수 있다.
ㆍ액세스 포인트 MAC - 6 바이트, 이진수, 이용가능하지 않은 경우 모두 제로.
ㆍ임의의 클라이언트 챌린지 - 16 바이트, 이진수
ㆍ사용자 이름이 32 문자보다 긴 경우의 사용자 이름 해시, 이진수 - 20 바이트(SHA1)(이는 사용자 이름이 제로로 종료되지 않는 경우에만 의미가 있다)
페이로드의 커맨드 부분은 암호화되지 않은 채 전송된다. 잔여 페이로드는 보안을 위해 RSA 암호화된다. 그 후 페이로드는 Base32 인코딩되며, 그 결과, 도메인 네임을 갖는 개별 라벨들로 분할되는데, 패킷-기반 통신 시스템 제공자가 이 도메인 네임에 추가된 DNS 서비스, 예컨대 ".access.skype.com"을 실행한다.
그 후 클라이언트(110) 내 액세스 관리자(324)는 회귀적 CNAME 질의를 만든다. 전술한 바와 같이, 이는 (DNS 터널링을 이용한)DNS 질의이므로, 비록 핫스팟(109)이 네트워크(106)에의 액세스를 제한하더라도 메시지는 전송될 수 있다.
SSID 질의를 수신하면, 통신 클라이언트 소프트웨어 제공자 DNS 서버(128)는 모든 라벨들을 연결하고 사전어휘에 존재하지 않는 임의의 문자를 생략함으로써, 그 결과가 Base32 인코딩이 제거되는 231 문자 길이가 될 때까지, 이진수 페이로드를 추출하며 그 결과 144 바이트 이진수 페이로드가 생성된다. 그 다음에 이진수 페이로드가 RSA 복호화된다.
통신 클라이언트 소프트웨어 제공자 DNS 서버(128)는 핫스팟(109) 운영자 및 지불 파트너(즉 결제 계약이 존재하는 신뢰할만한 파트너)간에 합의가 존재하는지를 판단한다. 이는 SSID를 갖는 액세스 데이터베이스(130)에 질의함으로써 결정된다. 응답은 액세스 DB(130)로부터 수신된다. 또한 이러한 핫스팟(109)에 대한 가격 정보 역시 검색된다. 사용자의 위치(사용자의 프로필 정보에 설정된)는 사용자 이름을 갖는 사용자 데이터베이스(132)에 질의하여 응답을 수신함으로써 선택적으로 결정될 수 있다. 이러한 데이터를 이용하여, 가격 정보는 사용자의 지역 통화로 주어질 수 있다.
도 1에서 데이터베이스는 선택적 DB 액세스 노드(129)를 통하여 액세스된다는 점에 유의하자.
SSID 정보 질의가 MAC 주소를 포함하지 않는 경우에 DNS 서버(128)는 바로 SSID를 검색하여 MAC를 무시한다. 질의가 소정의 MAC을 특정한다면, 이때 서버는 일치점을 찾으려고 시도한다. 일치점이 발견되지 않는 경우, 이때 서버는 응답에 있어 MAC 주소 밖에서 찾으며 일반적인 SSID 정보로 응답한다.
통신 클라이언트 소프트웨어 제공자 DNS 서버(128)는 DNS 응답으로서 인코딩된 SSID를 생성한다. 사용자(102)가 자신의 크레딧(패킷-기반 통신 시스템에서 이용하기 위해 구입된 것으로서)을 이용하여 AP(108)를 통하여 인터넷에 액세스하기 위한 지불을 할 수 있다는 것이 판단되는 경우, SSID 응답은 클라이언트(110)가 액세스 관리자(324)를 이용하여 핫스팟에 액세스를 위한 지불을 할 수 있다는 사실을 표시할 것이다. 특히 SSID 응답은 사용자의 지역 통화로 핫스팟(109)에 대한 가격 정보를 포함할 수 있다.
사용자가 크레딧을 가지고 있지 않다면, 사용자는 크레딧을 구입할 수 있음을 표시하는 팝-업(pop-up) 메시지를 보여줄 것이며, 도 4의 지불 과정이 시작된다. 일 실시예에서, 크레딧의 이용가능성이 토큰 요청 질의의 실패에 의해 결정되지만, 이러한 정보는 다른 수단에 의해 제공될 수 있다.
통신 클라이언트 소프트웨어 제공자 DNS 서버에 의해 생성된 SSID 정보 응답 페이로드는 다음을 포함한다:
ㆍ커맨드 ID(cmdid) - 1 바이트, 이러한 응답이 대응하는 SSID 요청 커맨드의 커맨드 ID
ㆍ액세스 포인트 SSID - 32 바이트, 스트링, SSID가 정확하게 32 바이트 길이라면 비-제로 종료될 수 있다.
ㆍ액세스 포인트 MAC - 6 바이트, 이진수, 이용할 수 없는 경우 모두 제로.
ㆍ가격 - 4 바이트, 빅엔디언(big endian) 비서명 정수
ㆍ가격＿정확도 - 4 바이트, 가격 십진수 정확도, 빅엔디언 비서명 정수
ㆍ통화(currency) - 4 바이트, 제로 종료된 3-문자 통화 코드
ㆍ제공자 ID - 2 바이트, 빅-엔디언 정수
통신 클라이언트 소프트웨어 제공자 DNS 서버(128)는 질의에서 제공된 '클라이언트 챌린지'로부터 도출된 암호화 키를 이용하여 SSID 정보 응답을 암호화한다. 암호화 이후 페이로드는 Base32 인코딩된다.
SSID 정보 응답은 DNS 터널링을 이용하여 단계(S412)에서 클라이언트(110)에 전송된다.
SSID 정보 질의에 긍정적인 응답의 수신에 응답하여, 액세스 관리자(324)는 토큰 요청을 생성하여 단계(S414)에서 통신 클라이언트 소프트웨어 제공자 DNS 서버(128)에 DNS 프로토콜(터널링)을 이용하여 그 토큰 요청을 전송하도록 구성된다.
토큰 요청 메시지의 페이로드는 다음을 포함한다:
ㆍ커맨드 - 1 바이트
ㆍ커맨드 ID(cmdid) - 1 바이트, 클라이언트-할당된 커맨드 ID.
ㆍ사용자 이름 - 32 바이트, 스트링(string), 사용자 이름이 정확하게 32 바이크 길이라면 비-제로(non-zero) 종료될 수 있다
ㆍ액세스 포인트 SSID - 32 바이트, 스트링, SSID가 정확하게 32 바이트 길이라면 비-제로 종료될 수 있다
ㆍ패스워드 해시(password hash) - 16 바이트(MD5), 이진수
ㆍ임의의 클라이언트 챌린지 - 16 바이트, 이진수
ㆍ사용자 이름이 32 문자보다 긴 경우 사용자 이름 해시, 이진수 - 20 바이트(SHA1)(이는 사용자 이름이 제로로 종료되지 않지 않아야만 의미가 있다)
1-바이트 커맨드는 암호화되지 않고 전송되며, 117 바이트의 잔여 전체 페이로드는 RSA 암호화된다. 패스워드 해시는 부가적으로 최초 16 바이트의 공중 RSA 키가 해시된(hashed) 사용자 이름/패스워드 해시가다. 이는 패킷을 암호화하는데 이용된 만큼만 해시가 이용되도록 하여 RSA 키가 무효화된 경우 해시값을 전송한 이전의 모든 것을 무효화한다.
그 후 결과적인 1160 비트는 Base32 인코딩되며, 그 결과는 개별 라벨들 및 패킷-기반 통신 시스템 제공자가 부가된 DNS 서비스, 예컨대 ".access.skype.com"을 운영하는 도메인 네임으로 분할된다. 그 후 클라이언트(110)는 단계(S414)에서 통신 클라이언트 소프트웨어 제공자 DNS 서버(128)에 IN 분류의 회귀적 CNAME 질의를 만든다. 각 질의가 상이하기 때문에, 각 질의는 특정된 도메인을 위한 믿을만한 해답들을 주는 DNS 서버에 도달한다.
'클라이언트 챌린지'는 응답 패킷들을 암호화하기 위한 키를 생성하는데 이용되며, 또한 토큰(이하 기술된)으로부터 세션 ID 값을 생성하기 위한 키를 생성하는데 이용된다. 예컨대, 스트림 모드에서 임의의 대칭 암호가 이용될 수도 있지만, RC4-드롭(drop)(768) 대칭 암호화 알고리즘이 이용될 수 있다.
토큰 요청 수신에 응답하여 통신 클라이언트 소프트웨어 제공자 DNS 서버는 토큰 요청을 복호화하여 사용자 이름 및 패스워드 해시를 추출하도록 구성된다. 단계(S416 및 S418)에서, DNS 서버는 사용자 데이터베이스(132)에 목록화된 크리덴셜에 관한 사용자 이름 및 패스워드를 검증한다. 단계(S420)에서, 사용자가 핫스팟(109) 액세스에 지불할 수 있는 충분한 크레딧을 가지고 있다는 것을 보증하기 위하여, 사용자의 크레딧 잔고가 계정 DB(134)로부터 요청되어 응답이 S422에서 수신된다.
사용자가 검증되어 충분한 크레딧을 가진다면, 이때 통신 클라이언트 소프트웨어 제공자 DNS 서버(128)는 임의의 16-바이트 토큰을 생성하여 Base32-인코딩된 응답과 함께 클라이언트(110)에 응답할 것이다.
토큰 응답 메시지의 페이로드는 다음을 포함한다:
ㆍ커맨드(command) - 1 바이트
ㆍrc4 초기화 벡터 - 4 바이트, 이진값
ㆍ결과 코드 - 1 바이트
ㆍ커맨드 ID(cmdid) - 1 바이트, 이러한 응답이 대응하는 SSID 요청 커맨드의 커맨드 ID
ㆍ토큰 - 8 바이트
ㆍ틱(tick) 서버 주소들 - 8 바이트, 바람직하게는 틱을 전송하는 장소의 두 개의 IP 주소들(이하 기술된)
ㆍ로그인 이름 형식 특정기 - 83 바이트까지.
결과 코드로부터 시작하는 전체 페이로드는 클라이언트 챌린지로부터 생성된 키를 이용하여 암호화된다. 암호화 이후 페이로드는 Base32 인코딩된다. 이때 토큰 응답 메시지는 DNS 터널링을 이용하여 단계(S424)에서 클라이언트(110)로 전송된다. 이때 클라이언트(110)는 응답을 디코딩한 후 복호화한다.
또한 통신 클라이언트 소프트웨어 제공자 DNS 서버(128)는 단계(S425)에서 액세스 DB(130)내 사용자 이름 및 클라이언트 챌린지와 함께 생성된 토큰을 저장한다. 또한 통신 클라이언트 소프트웨어 제공자 DNS 서버(128)는 토큰(이하에 기술되는 것으로서)으로부터 일시적인 사용자 이름을 생성하여 이를 세션 ID로서 저장한다. 사용되지 않는다면, 토큰은 미리 결정된 시간 이후에 서버로부터 만료될 것이다.
단계(S424)에서 토큰 및 형식 특정기 수신에 응답하여, 액세스 관리자(324)는 응답을 디코딩하고 복호화한다. 이때 액세스 관리자(324)는 사용자에게 그들의 패킷-기반 통신 시스템 크레딧을 이용하여 연결을 위해 지불할 수 있는 선택권을 제공하기 위하여 클라이언트 UI(322)를 제어한다. 예시적인 사용자 인터페이스 메시지가 도 5에 도시된다. 사용자(102)는 "개시(start)" 버튼(502)을 선택함으로써 AP(108)에 연결하도록 선택할 수 있거나 또는 "취소(cancel)" 버튼을 선택함으로써 연결하지 않도록 선택할 수 있다.
사용자로부터 사용자가 AP(108)에 연결하기를 원하는 것을 표시하는 선택 신호의 수신에 응답하여, 일시적인 사용자 이름(토큰 및 클라이언트 챌린지로부터 도출된) 및 일시적인 패스워드(사용자의 패스워드의 해시 기능 및 클라이언트 챌린지로부터 도출된)를 이용하여 단계(S426)에서 핫스팟(109)에 도착 서명한다.
일시적인 사용자 이름은 토큰 응답에 포함된 형식 특정기에 따라 포맷된다. 일시적인 사용자 이름의 형식은 핫스팟(109) 제공자가 결제 파트너의 식별을 결정하도록 허용한다.
클라이언트(110)는 WISPr 추천에 따라 핫스팟(109)에 서명한다. 액세스 관리자(324)는 알려진 콘텐트의 미리 결정된 파일을 검색하기 위하여 AP(108)를 통해 http 요청을 전송하려고 시도한다. 핫스팟(109)은 그 요청을 핫스팟 제공자의 로그인 서버(도시되지 않음)에 재전송(redirect)한다. 로그인 서버로의 재전송에 응답하여, 액세스 관리자(324)는 서명될 일시적인 사용자 이름 및 패스워드를 로그인 서버에 제공하도록 구성된다.
핫스팟(109)은 일시적인 사용자 이름의 형식(예컨대, 이것이 결제 파트너를 표시하는 접두어를 갖는다)으로부터 로그인 요청이 패킷-기반 통신 시스템 결제 파트너와 관련된다는 사실을 결정하여 단계(S428)에서 그 결제 요청을 핫스팟의 사용자 서비스내 원격 인증 다이얼("RADIUS")에 전송한다.
핫스팟 RADIUS 서버(136)에서 로그인 요청의 수신에 응답하여, 핫스팟 RADIUS 서버(136)는 일시적인 사용자 이름의 형식으로부터 그 로그인 요청이 패킷-기반 통신 네트워크와 관련된다는 사실을 결정한다. 핫스팟 RADIUS 서버(136)는 단계(S430)에서 통신 클라이언트 소프트웨어 제공자 RADIUS 서버(138)의 일시적인 사용자 이름 및 패스워드를 포함하는 인증 질의를 전송한다.
통신 클라이언트 소프트웨어 제공자 RADIUS 서버(138)는 일시적인 사용자 이름 및 패스워드를 수신한다. 일단 통신 클라이언트 소프트웨어 제공자 RADIUS 서버(138)가 단계들(S431 및 S432)에서 액세스 DB(130)에 저장된 크리덴셜을 검증하였다면, 이는 "액세스 승인" 또는 "액세스 거절" 메시지와 함께 단계(S433)에서 핫스팟 RADIUS 서버(136)에 응답한다. "액세스 승인" 메시지는 일시적인 사용자 이름을 사용하여 세션을 식별하여 최소 30분에서 계산된 허용 세션 시간의 길이 또는 분당 비용으로 나눈 크레딧을 한정한다.
"액세스 승인" 메시지가 수신되었다고 가정하면, 핫스팟 RADIUS 서버(136)는 단계(S434)에서 핫스팟(109)에 인증 메시지를 전송한다. 인증 메시지 수신에 응답하여, 핫스팟(109)은 클라이언트(110)가 인터넷에 액세스할 수 있도록 허용하여 단계(S436)에서 로그인이 성공하였음을 클라이언트(110)에게 알린다.
액세스 관리자(324)는 클라이언트(110)에게 로그인이 성공되었음을 알린다. AP(108)와 연결된 동안, 액세스 관리자(324)는 사용자에게 단말기가 네트워크에 연결된 사실을 알리기 위하여 클라이언트(322) UI를 제어한다.
상기 설명에서, 지불 패킷들은 약간의 중요 차이점과 함께, 세션 생성 패킷들과 동일한 패턴에 따른다:
ㆍ상이한 RSA 키가 사용된다
ㆍ커맨드에 부가하여, 커맨드 ID(cmdid)또한 평문으로 전송된다
ㆍ응답은, 암호 컴포넌트가 응답하지 않는다면, 작성된 커맨드, 커맨드 ID(cmdid), 및 결과 코드만으로 도착할 수 있다
패스워드 해시는 토큰 요청에 이용된 동일한 해싱(hashing) 방식을 이용한다. 패스워드 해시는 부가적으로 최초 16 바이트의 공중 RSA 키가 해시된, 이중-해시된 사용자 이름/스카이퍼/패스워드 해시일 것이다. 이는 이용되어온 RSA 키가 유효한 경우에만 해시를 이용가능케 한다.
다른 요청에도 마찬가지로, 지불 메시지에서 응답의 나머지는 암호화되는 반면 커맨드 코드, 초기화 벡터, 커맨드 ID, 및 결과 코드는 평문으로 되돌려 전송된다.

Claims (10)

  1. 제한된 접속 환경(limited connectivity environment)에서 통신 네트워크를 통하여 사용자 단말기에서 복호화 컴포넌트로 데이터를 전송하는 방법으로서,
    사용자 단말기에서,
    사용자로부터 사용자 단말기에서 데이터를 수신하는 단계;
    상기 데이터가 민감(sensitive) 데이터라고 판단되면, 보안 암호화 키를 이용하여 상기 민감 데이터를 암호화하는 단계;
    터널링 프로토콜에 따라 패킷을 생성하는 단계 -상기 패킷은 네트워크 컴포넌트의 주소, 커맨드(command) 데이터 및 상기 암호화된 민감 데이터를 포함하고, 상기 커맨드 데이터는 커맨드 및 커맨드 식별자를 포함하며, 상기 커맨드는 상기 보안 암호화 키가 상기 민감 데이터를 암호화하는데 이용되었음을 식별함-
    를 포함하는, 데이터 전송 방법.
  2. 제 1 항에 있어서,
    상기 데이터가 세션(session) 데이터라고 판단되면, 상기 세션 데이터는 세션 암호화 키를 이용하여 암호화되며, 상기 커맨드는 상기 세션 암호화 키가 상기 세션 데이터를 암호화하는데 이용되었음을 식별하는,
    데이터 전송 방법.
  3. 제 1 항 또는 제 2 항에 있어서,
    상기 커맨드 데이터는 평문(plain text)인,
    데이터 전송 방법.
  4. 제 1 항 내지 제 3 항 중 어느 한 항에 있어서,
    상기 민감 데이터는 액세스 데이터 또는 지불(payment) 데이터를 포함하는,
    데이터 전송 방법.
  5. 사용자 단말기로서,
    사용자가 적어도 보안 데이터 또는 세션 데이터를 입력하게 하도록 구성된 사용자 인터페이스와,
    상기 데이터를 수신하고, 상기 데이터가 보안 데이터인지 또는 세션 데이터인지를 판단하며, 보안 암호화 키로 보안 데이터를 암호화하거나 세션 키로 세션 데이터를 암호화하고, 평문으로 된 커맨드 데이터 및 상기 암호화된 데이터를 포함하는 패킷을 생성하는 컴퓨터 프로그램을 실행하도록 구성된, 프로세서를 포함하되,
    상기 커맨드 데이터는 커맨드 및 커맨드 식별자를 포함하며, 상기 커맨드는 상기 보안 키가 이용되었는지 상기 세션 키가 이용되었는지 여부를 식별하는,
    사용자 단말기.
  6. 통신 네트워크에 이용하기 위한 네트워크 컴포넌트로서,
    상기 통신 네트워크와 패킷들을 교환하기 위한 제 1 포트;
    보안 환경에서 복호화 컴포넌트와 패킷들을 교환하기 위한 제 2 포트;
    컴퓨터 프로그램을 실행하도록 구성된 프로세서로서, 상기 제 1 포트로부터 패킷을 수신하고 -상기 패킷은 커맨드 및 커맨드 식별자를 포함한 커맨드 데이터 및 암호화된 데이터를 포함함-, 상기 커맨드를 판독하여 상기 데이터를 암호화하기 위해 보안 키가 이용되었는지 세션 키가 이용되었는지 여부를 판단하고, 세션 키가 이용된 경우 상기 데이터를 복호화하여 그 복호화된 데이터에 따르고, 보안 키가 이용된 경우 상기 패킷을 상기 제 2 포트로 전송하고 상기 제 1 포트를 통하여 응답 및 상기 커맨드 식별자를 포함하는 응답 패킷을 송신하는, 프로세서
    를 포함하는, 네트워크 컴포넌트.
  7. 제 6 항에 있어서,
    상기 프로세서는 복호화 컴포넌트로부터 응답을 수신하여 상기 수신된 응답을 상기 응답 패킷에 포함하도록 구성된,
    네트워크 컴포넌트.
  8. 제 6 항에 있어서,
    상기 프로세서는 상기 네트워크 컴포넌트에 의해 생성된 응답을 포함하는 응답 패킷을 생성하도록 구성된,
    네트워크 컴포넌트.
  9. 제 8 항에 있어서,
    상기 프로세서는 복호화 컴포넌트로부터 수신된 응답이 없을 경우 상기 네트워크 컴포넌트에서 응답을 생성하도록 구성된,
    네트워크 컴포넌트.
  10. 프로세서에 의해 실행될 때, 제 1 항 내지 제 4 항 중 어느 한 항에 따른 방법의 단계들을 수행하는 프로그램 코드 수단을 포함하는 컴퓨터 프로그램 제품.
KR20147016330A 2011-12-15 2012-12-15 보안 통신 시스템 및 방법 KR20140102688A (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
GB1121585.2 2011-12-15
GB201121585A GB201121585D0 (en) 2011-12-15 2011-12-15 Communication system and method
US13/363,023 2012-01-31
US13/363,023 US20130159711A1 (en) 2011-12-15 2012-01-31 Communication System and Method
PCT/US2012/069966 WO2013090866A1 (en) 2011-12-15 2012-12-15 Secure communication system and method

Publications (1)

Publication Number Publication Date
KR20140102688A true KR20140102688A (ko) 2014-08-22

Family

ID=45560517

Family Applications (1)

Application Number Title Priority Date Filing Date
KR20147016330A KR20140102688A (ko) 2011-12-15 2012-12-15 보안 통신 시스템 및 방법

Country Status (7)

Country Link
US (1) US20130159711A1 (ko)
EP (1) EP2777308A1 (ko)
JP (1) JP2015503303A (ko)
KR (1) KR20140102688A (ko)
CN (1) CN104247481A (ko)
GB (1) GB201121585D0 (ko)
WO (1) WO2013090866A1 (ko)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2464553B (en) 2008-10-22 2012-11-21 Skype Controlling a connection between a user terminal and an access node connected to a communication network
US8825814B1 (en) * 2013-05-23 2014-09-02 Vonage Network Llc Method and apparatus for minimizing application delay by pushing application notifications
US10726405B2 (en) 2014-08-22 2020-07-28 Fan Wu System and method for implementing networking transfer service
CN104219737B (zh) * 2014-08-22 2018-06-05 欧阳聪星 一种实现联网转接服务的系统及其方法
US9876783B2 (en) * 2015-12-22 2018-01-23 International Business Machines Corporation Distributed password verification
KR20180000582A (ko) * 2016-06-23 2018-01-03 삼성전자주식회사 결제 방법 및 이를 사용하는 전자 장치
US10778684B2 (en) * 2017-04-07 2020-09-15 Citrix Systems, Inc. Systems and methods for securely and transparently proxying SAAS applications through a cloud-hosted or on-premise network gateway for enhanced security and visibility
US10949486B2 (en) 2017-09-20 2021-03-16 Citrix Systems, Inc. Anchored match algorithm for matching with large sets of URL
WO2019220310A1 (en) * 2018-05-14 2019-11-21 Terrence Keith Ashwin A financial transaction wireless communication authentication sensor
CN112291504B (zh) * 2020-03-27 2022-10-28 北京字节跳动网络技术有限公司 信息交互方法、装置和电子设备
CN112054909A (zh) * 2020-09-19 2020-12-08 黑龙江讯翱科技有限公司 一种基于RSA算法的Radius认证方法
CN113411328B (zh) * 2021-06-17 2023-03-24 国网福建省电力有限公司信息通信分公司 一种基于数据预辨识敏感数据高效传输系统
CN113747438A (zh) * 2021-09-12 2021-12-03 胡忠南 Wlan接入管理方法、装置及系统

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6954793B2 (en) * 2002-05-13 2005-10-11 Thomson Licensing S.A. Pre-paid data card authentication in a public wireless LAN access system
US7487264B2 (en) * 2002-06-11 2009-02-03 Pandya Ashish A High performance IP processor
KR100747756B1 (ko) 2003-07-16 2007-08-09 스카이프 리미티드 피투피 전화 시스템
GB2437791A (en) * 2006-05-03 2007-11-07 Skype Ltd Secure communication using protocol encapsulation
US8374165B2 (en) * 2008-06-09 2013-02-12 Nokia Corporation Method, apparatus, and computer program product for communication routing
GB2464552B (en) * 2008-10-22 2012-11-21 Skype Authentication system and method for authenticating a user terminal with an access node providing restricted access to a communication network
GB2464553B (en) 2008-10-22 2012-11-21 Skype Controlling a connection between a user terminal and an access node connected to a communication network

Also Published As

Publication number Publication date
CN104247481A (zh) 2014-12-24
JP2015503303A (ja) 2015-01-29
GB201121585D0 (en) 2012-01-25
EP2777308A1 (en) 2014-09-17
WO2013090866A1 (en) 2013-06-20
US20130159711A1 (en) 2013-06-20

Similar Documents

Publication Publication Date Title
US8091116B2 (en) Communication system and method
KR20140102688A (ko) 보안 통신 시스템 및 방법
US9210729B2 (en) Communication system and method
US8130635B2 (en) Network access nodes
US20020169966A1 (en) Authentication in data communication
US20060005033A1 (en) System and method for secure communications between at least one user device and a network entity
EP2547051B1 (en) Confidential communication method using vpn, a system and program for the same, and memory media for program therefor
US10986501B2 (en) Secure telephone identity (STI) certificate management system
US9648650B2 (en) Pairing of devices through separate networks
JP2010503318A (ja) ネットワーク・アクセスを獲得するためのシステムおよび方法
US10893414B1 (en) Selective attestation of wireless communications
JP5388088B2 (ja) 通信端末装置、管理装置、通信方法、管理方法及びコンピュータプログラム。
KR100463751B1 (ko) 무선통신을 위한 패킷데이터 생성 방법과, 이를 이용한무선통신 방법 및 그 장치
CN114513299B (zh) 基于开放式授权的数据传输方法及电子设备
JP7139635B2 (ja) 認証システム
KR20180099304A (ko) 존 통신 시스템 및 방법

Legal Events

Date Code Title Description
WITN Application deemed withdrawn, e.g. because no request for examination was filed or no examination fee was paid