KR20090089394A - 네트워크의 클라이언트 장치로의 보안 패스워드 분배 - Google Patents

Abstract

패스워드는, 제1 암호화 메시지 - 제1 메시지는 클라이언트 장치에 의해 생성된 논스, 클라이언트 장치의 사용자명, 클라이언트 장치의 네트워크 어드레스를포함함 - 를 클라이언트로부터 네트워크의 서버로 송신하고, 제2 메시지 - 제2 메시지는 클라이언트 장치에 의해 생성된 논스와 서버에 의해 생성된 패스워드를 포함함 - 를 서버로부터 클라이언트 장치의 네트워크 어드레스로 송신함으로써, 트워크의 클라이언트 자치에 안전하게 분재된다. 만약, 서버로부터 수신된 논스가 서버에 송신된 논스와 일치한다는 것을 클라이언트 장치가 증명한 경우, 패스워드 및 사용자명은 클라이언트 장치가 서버의 정보에 액세스할 수 있도록 사용될 수 있을 것이다. 제1 암호호 메시지는 HTTPS 메시지일 수 있으며, 제2 메시지는 SMS 메시지일 수 있다.

클라이언트, 메시지, 패스워드, 네트워크 어드레스, 논스

Description

네트워크의 클라이언트 장치로의 보안 패스워드 분배{SECURE PASSWORD DISTRIBUTION TO A CLIENT DEVICE OF A NETWORK}

본 발명은 전반적으로 네트워크의 클라이언트 장치와 서버 사이의 통신에 관한 것이다.

때로는 클라이언트 장치(가령, 셀룰러 핸드셋, 개인용 컴퓨터, PDA, 또는 랩탑 등)로부터 계좌(account)와 관련된 온라인 개인 정보(on-line personal information)를 액세스하는 것이 바람직하다. 일례로는, 개인 정보가 사용자의 잔고, 현재의 특판(specialized sales), 미결제 주문(outstanding orders) 등을 포함할 수 있는, 상가(merchandise store)에서의 고객 계좌가 있다. 이 정보에 대한 액세스를 관리하는 통상의 방법은, 클라이언트 장치가 등록 단계(enrollment phase) 동안에 몇몇 형식의 사용자명 및 패스워드(즉, 자격증명(credential))를 서빙 엔티티(가령, 상가의 웹 서버)와 공유하도록 하는 것이다. 후속하여, 사용자명 및 패스워드는, 전형적으로 HTTPS(HTTP over a Secure Sockets Layer) 또는 다이제스트 액세스 인증(digest access authentication)과 같은 보안 채널을 통한 기본 인증을 갖는 HTTP(Hypertext Transfer Protocol)를 이용하여, 사용자의 온라인 정보에 액세스하는 것을 가능하게 한다.

클라이언트 장치(가령, 이동 전화기, PDA 등)로부터의 개인 정보(일반적으로 "콘텐츠"라 지칭됨)에 대한 액세스를 관리하는 것은 매우 어렵다. 일반적으로, 액세스를 관리하는 것은, 계좌용 사용자명 및 패스워드의 생성과, 클라이언트 및 서빙 엔티티 사이의 정보의 안전한 공유를 포함하는 등록 단계를 필요로 한다. 보안을 위해, 서빙 엔티티가 등록 클라이언트를 콘텐츠에 액세스하도록 권한을 부여받은 엔티티로서 인증하는 것이 필수적이다. 유사하게, 클라리언트가 인증 서버 엔티티에 등록하고 있다는 것을 확인하는 것이 필수적이다. 즉, 상호 인증의 특성을 갖는 솔루션이 바람직하다. 가짜 클라이언트가 다른 클라이언트의 콘텐츠에 액세스하기 위해 다른 클라이언트처럼 행세하는 공격(attacks)과, 가짜 서버가 인증 클라이언트의 자격증명을 얻기 위해 인증 서버처럼 행세하는 공격은 실행불가능하여야 한다. 따라서, 자격증명이, 추후에 서버로부터 콘텐츠를 액세스하는데 사용될 수 있도록, 클라이언트 장치와 서버간에 자격증명(가령, 사용자명/패스워드 쌍), 예컨대 HTTP 기본 인증에 사용될 자격증명을 안전하게 생성하고 공유하는 몇몇 방법이 필요하다.

일 방법은 서버 엔티티가 SMS(Short Message Service)를 이용하여 패스워드 및 사용자명을 특정 셀룰러 핸드셋(cellular handset)에 송신하는 것이다. 패스워드를 포함하는 SMS 메시지는 네트워크의 네트워크 서비스 관리 액세스 포인트로부터 핸드셋으로 송신된다. 이 방법에서는, 특정 MSISDN(Mobile Station Integrated Services Digital Network Number)을 갖는 핸드셋만이 패스워드를 수신한다는 보증을 캐리어가 서버 엔티티에 제공한다. 이 방법의 단점은 SMS 메시지 내의 송신자 어드레스 정보가 쉽게 위조될(spoofed) 수 있다는 것이다(즉, 누군가가 가짜 송신자 어드레스를 전달하는 SMS 메시지를 송신하는 것이 상대적으로 용이하다.). 통상적으로, SMS 메시지의 콘텐츠는 (암호화를 통해) 네트워크 액세스 포인트(가령, 셀룰러 베이스 사이트)와 핸드셋 사이의 무선 송신(over-the air transmission) 동안 도청(eavesdropping)에 대해 보호된다. 그러나, 클라이언트는 수신된 SMS 메시지를 메시지에 표시되는 서버 엔티티로부터 발신한 것으로서 확실하게 인증할 수 없다. 따라서, 상호 인증은 달성될 수 없으며, 클라이언트에서는 수신된 패스워드 및 사용자명이 진정한 것임을 보장받지 못한다.

다른 방법은 클라이언트 엔티티가 패스워드 및 사용자명을 SMS를 통해 디지털적으로 또는 전화 호출(phone call)을 통해 구두로 특정 서버 엔티티에 송신하는 것이다. 그러한 SMS 메시지 내의 송신자 어드레스 정보에 대한 위조의 용이성, 또는 전화 호출의 경우에서 호출자 ID에 대한 보안의 결핍(즉, 호출자 ID도 위조될 수 있다)때문에, 문제가 발생한다. 서버에서는 수신된 패스워드 및 사용자명이 확실하다는 것을 보장받지 못한다.

또한, 이메일 및 SMS는 계좌 활성화(account activation)와 같은 활동에 대해 대중화되어 가고 있다. 계좌 활성화는 일반적으로 한번만 수행되며, 정보를 참조하는데 사용되지 않는다.

따라서, 위 모든 방법들에서는, 상호 인증이나, 패스워드 및 사용자명을 안전하게 공유하는 목적이 달성되지 않는다. 또한, 클라이언트에서의 사용자에 의한 수동적 개입은, 패스워드 및 사용자명이 수신 및 승낙되는 것을 확인하는 것을 필 요로 한다. 클라이언트의 자격증명이 서버와 공유되고, SMS 내의 호출자 ID 또는 송신자 어드레스와 같은 쉽게 위조되는 정보의 신빙성(authenticity)에 의존하지 않고 달성될 수 있는 방법이 여전히 필요하다.

다른 관련된 기술이 이메일 분배 리스트(E-mail distribution lists)를 관리하는 어플리케이션에서 사용되는데, 여기서는 개인이 소정의 서비스에 가입하지 않아도 된다. 이 경우, 서버는 논스(nonce)(랜덤 심볼)을 생성하고, 이를 이메일을 통해 전달되는 URL에서 인코딩한다. 이 유형의 시스템은 단일 방향 인증만을 제공할 뿐(서비스는 클라이언트를 인증할 수 있음), 다른 방향으로의 인증은 제공하지 않는다(클라이언트가 송신자의 이메일 어드레스를 인증할 방법이 없음). 따라서, 서버는 미가입 요구가 유효하다는 것을 증명할 수 있다하더라도, 클라이언트는 수신된 요구가 실제로 원하는 서버로부터의 것인지 증명할 수 없다. 이로 인해, 단일 방향 인증은, "룩-라이크(look-like)" 메시지를 누군가가 URL을 트리거(trigger)할 것이라는 기대로 여러 클라이언트에 송신하는 "피싱" 공격을 받기 쉽다.

마지막으로, 상호 인증을 달성하고 사용자명 및 패스워트 정보를 통신하기 위한 보안 채널을 셋업(set up)하기 위해 공개-키 방법이 사용될 수 있다. 이 경우, 서버 및 클라이언트에는 각각 고유 개인 키 및 공개 키 인증서가 부여될 수 있다. 그러나, 그러한 시스템에서는 배치하는데 매우 고가인 새로운 공개 키 인프라스트럭쳐, 또는 기존의 공개 키 인프라스트럭쳐의 재사용을 필요로 한다. 기존 인프라스트럭쳐의 재사용은 새로운 라이센싱 및 준수 요구(compliance requirements) 와 같은 기술적 및 사업적 문제를 극복하는 것이 요구된다.

본 발명에 따른 구체적인 실시예를 설명하기에 앞서, 본 실시예는 주로 클라이언트 장치로의 패스워드 분배와 관련된 방법 단계 및 장치 컴포넌트의 조합에 있다는 것이 이해될 것이다. 따라서, 본 명세서의 이점을 갖는 당업자에게 명백할 세부를 갖는 개시를 불명료하게 하지 않도록, 본 발명의 실시예를 이해하는데 적절한 특정 세부만을 나타내는 장치 컴포넌트 및 방법 단계가 도면의 통상의 심볼을 사용하여 제공될 것이다.

본 명세서에서, 제1 및 제2, 상부 및 하부 등의 관련 용어는 단지 하나의 엔티티 및 동작을 다른 엔티티 및 동작과 구별하기 위해 사용될 수 있으며, 그러한 엔티티 및 동작 사이에 소정의 실질적 관계 또는 순서를 반드시 요구하거나 암시하는 것은 아니다. "포함한다", "포함하는" 또는 그 변형된 용어는 비배타적 포함을 커버하기 위한 것이며, 엘리먼트들의 리스트를 포함하는 프로세스, 방법, 아티클 또는 장치는, 그 엘리먼트만을 포함할 수도 있지만, 그러한 프로세스, 방법, 아티클 또는 장치에 명백히 리스트되거나 갖추어져 있지 않은 다른 엘리먼트들도 포함할 수도 있다. "포함한다"에 선행되는 엘리먼트는, 그 엘리먼트를 포함하는 프로세스, 방법, 아티클 또는 장치 내에 추가적인 동일 엘리먼트가 존재하는 것을 배제하지 않는다.

본 명세서에 기술되어 있는 본 발명의 실시예는 하나 이상의 프로세서가 어떤 비프로세서 회로와 함께, 본 명세서에서 기술된 패스워드 분배 기능의 일부, 대부분 또는 전부를 실행하도록 제어하는 하나 이상의 통상적 프로세서와 고유 저장 프로그램 인스트럭션으로 이루어질 수 있다. 비프로세서 회로는 라디오 수신기, 라디오 송신기, 신호 드라이버, 클럭 회로, 전원 회로 및 사용자 입력 장치를 포함할 수 있으며, 이에 한정되는 것은 아니다. 이처럼, 이 기능들은 패스워드 분배를 클라이언트 장치에 대해 수행하는 방법으로서 해석될 수 있다. 대안적으로, 일부 또는 모든 기능은 저장 프로그램 인스트럭션을 갖지 않은 상태 머신에 의해, 또는 각 기능 또는 그 기능의 임의의 조합 일부가 맞춤형 로직으로서 실행되는 하나 이상의 ASIC(application specific integrated circuit)에서 실행될 수 있다. 물론, 2개의 방법의 조합이 사용될 수도 있다. 따라서, 이 기능들에 대한 방법 및 수단이 여기서 기술된다. 또한, 당업자는, 가령 이용가능한 시간, 현재 기술 및 경제적 고려에 의해 영향을 받는 가능성 있는 상당한 노력 및 많은 디자인 선택에도 불구하고, 본 명세서에 개시되어 있는 개념 및 원리에 의해 안내될 경우, 그러한 소프트웨어 인스트럭션 및 프로그램과 IC를 최소한의 비용으로 쉽게 생성할 수 있을 것이다.

때로는, 클라이언트 장치(예를 들어, 셀룰러 핸드셋, 개인용 컴퓨터, PDA 또는 랩톱 등)로부터 계좌와 연관된 온라인 개인 정보를 액세스하는 것이 바람직하다. 일례로는 개인 정보가 사용자의 잔고, 현재 특판, 미지불 주문 등을 포함할 수 있는, 상가에서의 고객의 계좌가 있다. 이 정보에 대한 액세스를 관리하는 통상의 방법은, 클라이언트 장치가 등록 단계 동안에 몇몇 형식의 사용자명 및 패스워드(즉, 자격증명)를 서빙 엔티티(가령, 상가의 웹 서버)와 공유하도록 하는 것이다. 후속하여, 사용자명 및 패스워드는, 전형적으로 HTTPS 또는 다이제스트 액세스 인증과 같은 보안 채널을 통한 기본 인증을 갖는 HTTP를 이용하여, 사용자의 온라인 정보에 액세스하는 것을 가능하게 한다.

따라서, 자격증명이, 추후에 서버로부터 콘텐츠를 액세스하는데 사용될 수 있도록, 핸드셋과 서버간에 자격증명(가령, 사용자명/패스워드 쌍), 예컨대 HTTP 기본 인증에 사용될 자격증명을 안전하게 생성하고 공유하는 몇몇 방법이 필요하다.

본 발명은, 자격증명이 나중에 서버로부터 콘텐츠(가령, 개인 정보)를 액세스하는데 사용될 수 있도록, 클라이언트 장치와 서버 사이에의, 사용자명/패스워드 쌍과 같은 자격증명의 생성 및 공유에 관한 것이다. 예컨대, 자격증명은 HTTP 기본 인증에 사용될 수 있다. 일반적으로, 클라이언트 장치 자체는 사용자명 및 패스워드를 사업자(the business)에게 송신할 안전한 방법을 필요로 하기 때문에, 사용자명 및 패스워드를 생성할 수 없다. 즉, 사업자는 이 자격증명의 신빙성을 판정할 필요가 있을 것이다. 이것은, 엔드투엔드 통신 보안(end-to-end communication security)(가령, SMS는 위조될 수 있는 송신자 어드레스임)이 결핍되어 있는 경우, 고가의 공개 키 인프라스트럭쳐의 사용 없이는 해결하기 어려운 작업이다. 또한, 사업자 자신은, 사용자명 및 패스워드를 핸드셋에 송신할 안전한 방법을 필요로 하기 때문에, 사용자명 및 패스워드를 생성할 수 없다. 즉, 핸드셋은 이 자격증명의 신빙성을 판정할 필요가 있는데, 이 역시 상기와 같은 이유로 곤란하다(가령, 안전치 못한 SMS 또는 고가의 인프라스트럭쳐). 따라서, 클라이언트 장치에서 사용하기 위해 사용자명 및 패스워드 쌍을 안전하게 생성할 몇몇 방법이 필요하다. 본 발명의 일 실시예에서, 클라이언트 장치는 사용자명을 생성하지만, 사업자는 패스워드를 생성한다. 이 방법에서, 패스워드는 클라이언트 장치에 안전하게 통신된다. 안전한 패스워드 분배를 제공하기 위해, 캐리어는 신뢰된 엔티티인것으로 한다.

핸드셋의 인증에 있어서의 한가지 문제는, 호출자 식별(호출자 ID) 정보가 안전하지 않다는 것이다. 예를 들어, 누군가가 가짜 호출자 ID를 전달하는 호출을 하는 것은 비교적 쉽다. 또한, SMS 메시지의 콘텐츠가 통상적으로 (암호화를 통해) 네트워크 액세스 포인트(가령, 셀룰러 베이스 사이트)와 핸드셋간의 무선 송신 동안 도청으로부터 보호된다 하더라도, SMS 메시지의 송신자 어드레스는 위조될 수 있다.

사용자명/패스워드 쌍을 안전하게 생성하기 위해, 상호 인증을 수행하는 것이 필요한데, 즉, 클라이언트 장치 사용자는 사업자가 그의 신원을 입증할 수 있다는 것을 보증할 필요가 있으며, 사업자는 요청한 핸드셋 신원을 확인할 필요가 있다.

본 발명은 사용자명/패스워드 쌍이 사용자 개입 없이 자동으로 생성될 수 있게 한다.

보안 방법을 설계할 때, 보호되는 자산(즉, 자산의 가치)과, 이 자산의 약점과, 잠재적 위험 및 이 약점에 대한 공격과, 이 위협 및 공격과 연관된 위험(공격 가능성)에 대한 고려가 있어야 한다. 예를 들어, 액세스되고 있는 콘텐츠는 재정 정보라기 보다는 개인 정보일 수 있다. 계좌 정보, 고객 할인 정보, 다른 상태 등과 같은 개인 정보는 은행 계좌 번호 또는 은행 패스워드 및 사용자명 등과 같은 재정 어플리케이션에 대한 정보보다는 보호하기에 덜 중요할 수 있다.

본 발명은, 캐리어가 신뢰된 엔티티이고 보안이 회피하는 것을 허용하지 않는 것으로 가정된다. 가령 재정 어플리케이션과 같이 더 큰 위험 및 고가의 자산을 갖는 상황에서, 캐리어는 재정 기관에 의해 신뢰되지 않을 수 있다는 점이 유의되어야 한다. 본 발명에서 전달되는 패스워드 및 사용자명은 악의적 또는 부주의한 캐리어에 취약할 수 있다. 그러므로, 본 발명에서는, 그러한 취약성이 발생하지 않도록 캐리어가 서버 엔티티에 의해 신뢰되는 것으로 가정된다.

프로토콜은 2개의 기본 동작을 포함한다. 제1 동작은 클라이언트 장치가 그 네트워크 어드레스와 사용자명을 패스워드와 연관시키는 "등록" 동작이다. 네트워크 어드레스는 예를 들어 셀룰러 전화기의 전화 번호일 수 있다. 제2 동작은 사용자명 및 패스워드를 사용한 콘텐츠의 요청이다.

도 1은 본 발명의 일부 실시예에 따른, 상호 인증으로 패스워드 분배를 위한 예시적 메시지 시퀀스 다이아그램이다.

도 2는 본 발명이 일부 실시예에 따른, 안전한 패스워드 분배를 위한 예시적 시스템이다.

도 3은 본 발명의 일 실시예에 따른, 안전한 패스워드 분배를 위한 방법의 플로우 차트이다.

당업자는 도면의 엘리먼트가 단순성 및 명료성을 위해 반드시 본래의 크기로 도시되지 않있음을 이해할 것이다. 예를 들어, 도면에서 일부 엘리먼트의 크기는 본 발명의 실시예들의 이해를 돕기 위해 다른 엘리먼트에 비해 과장되어 있을 수도 있다.

전체적으로 동일 참조 번호가 동일 또는 기능적으로 유사한 엘리먼트를 나타내는 첨부 도면은 이하 설명되는 상세한 설명과 함께 본 명세서에 통합되며, 본 발명에 따른 다양한 원리 및 이점 모두를 설명하기 위한 것이다.

도 1은 상호 인증을 이용한 패스워드 분배에 대한 예시적인 메시지 시퀀스 다이아그램으로서, 클라이언트 장치(이하, '클라이언트')를 위한 시간선(102)과 사업자(이하, '서버')를 위한 시간선(104)을 나타낸다. 도 1을 참조하면, 106에서 클라이언트는 논스(랜덤 또는 예측불가능한 심볼)을 생성하며, 108에서 이 논스를 전화 번호(또는 다른 네트워크 어드레스) 및 사용자명과 함께 HTTPS와 같은 보안 송신 프로세스를 이용하여 사업자 서버에 송신한다. 데이터는 암호화되므로 송신은 안전하며, 이 정보는 사업자 서버에 의해 암호해독될 수 있지만, 어떤 '맨인더미들(man-in-the-middle)' 도청으로부터는 비밀을 유지한다. 110에서, 사업자는 108에서 수신된 메시지를 처리할 것이다. 예를 들어, 사업자는 수신된 등록 정보(가령, 전화번호 또는 다른 네트워크 어드레스)가 데이터베이스 내에 존재하고 등록이 아직 완료되지 않은 적법한 사용자에 해당한다는 것을 보증하기 위해 데이터베이스에 쿼링(querying)함으로써, 이 메시지에 대해 몇몇 검사를 수행할 것이다. 또한, 110에서, 사업자는 패스워드를 생성하고, 112에서 제1 메시지에서 특정된 전화 번호(또는 다른 네트워크 어드레스)를 이용하여, 패스워드 및 논스를 클라이언트 장치에 다시 송신한다. 논스 및 패스워드는 SMS를 이용하여 송신될 수 있다. 핸드셋이 패스워드 및 논스를 수신하는 경우에는, 114에서 논스가 106에서 생성된 논스인지를 검증한다. 만약 제1 논스(클라이언트에 의해 송신된)가 제2 논스(서버로부터 수신된)와 일치하는 경우, 패스워드는 이 특정 사업자에 대한 "액세스" 사용자명과 함께 핸드셋에 저장된다. 따라서, 클라이언트는, 제1 논스가 제2 논스와 동일한 경우, 패스워드를 액세스 사용자명과 연관시킨다.

"액세스 사용자명"은, 클라이언트 엔티티를 고유하게 식별하기 위해 서버 엔티티에 의해 사용될 수 있는 사용자명이다. 예를 들어, 액세스 사용자명은 108에서 송신된 초기 사용자명과 클라이언트 전화 번호(또는 다른 네트워크 어드레스)로부터 유도될 수 있다. 이와 달리, 액세스 사용자명은, 이 사용자명이 서버 엔티티에 대한 클라이언트를 고유하게 식별하는데 사용될 수 있다는 것을 보장하는 방식으로 선택되는 한, 108 동안에 송신된 사용자명과 동일할 수 있다. 예를 들어, 108에서의 사용자명은, 다른 클라이언트가 그것을 앞서 사용하기를 꺼렸을 만큼 충분한 길이의 랜덤 값일 수 있다. 몇몇 실시예에서, 사용자는 사용자명을 선택할 수 있으며, 클라이언트로 작업하는 사용자는 적절하게 고유한 사용자명에 이루기 위해 서버 엔티티와 협상할 수 있다. 예를 들어, 108에서 송신된 사용자명이 다른 클라이언트에 의해 이미 사용된 경우, 서버는 클라이언트에게 다른 사용자명을 선택할 것을 통지할 필요가 있을 것이다.

일단 클라이언트가 액세스 사용자명과 패스워드를 저장하면, "등록" 프로세스가 완료된다. 하나의 SMS 메시지만이 필요하다. 이 SMS의 일 목적은, 제1 HTTPS메시지에서 식별된 클라이언트가 108에서 송신된 메시지로 표시되는 전화 번호를 통해 서비스를 갖는 것을 보장하는 것이다. SMS의 다른 목적은, 108에서 송신된 메시지에 표시되는 전화 번호로 식별되는 장치에게만 패스워드가 송신되는 것을 보장하는 것이다. 예를 들어, HTTPS 응답(원 HTTPS 요구에 대한)이 SMS가 아니라 리턴 패스워드(return password) 및 논스를 송신하는데 사용된 경우, 공격자는 위조 전화 번호로 등록할 수 있다.

이 핸드셋의 전화 번호와 연관된 콘텐츠에 액세스 하기 위해서, 클라이언트 장치는 116에서 등록 프로세스에서 취득되는 액세스 사용자명 및 패스워드를 이용하여, 사업자에 대한 HTTPS 접속을 셋업한다. 118에서, 핸드셋은, 다시 HTTPS를 이용하여, 이 전화 번호와 연관된 개인 콘텐츠를 수신한다. 보안 강도의 감소가 수용될 수 있는 경우에는, HTTPS 대신에 HTTP가 사용될 수 있음이 유의되어야 한다.

추가 액세스는, 다시 등록할 필요없이, 나중에 취득될 수 있다. 예를 들어, 클라이언트 장치는 120에서 등록 프로세스에서 취득된 사용자명 및 패스워드를 사용하여, 사업자에 대한 제2 HTTPS 접속을 셋업할 수 있다. 120에서, 핸드셋은 HTPS를 다시 사용하여, 이 전화 번호와 연관된 개인 컨텐츠를 수신한다.

메시지 시퀀스를 구현하는 예시적 시스템이 도 2에 도시되어 있다. 이 시스템은, 셀룰러 전화기, 핸드셋, PDA, 휴대형 컴퓨터, 개인용 컴퓨터 등의 클라이언 트 장치(202), 사업자 엔티티 또는 다른 정보 제공자에 의해 동작되는 서버(204)를 포함한다. 클라이언트 장치 전화 번호(PDTN)(206) 또는 다른 네트워크 어드레스는, 논스 생성 모듈(210)에 의해 생성된 논스(208) 및 모듈(214)에 의해 생성된 사용자명(212)과 함께, HTTPS 송신 모듈(216)에 전달되고, 또한 메모리 또는 데이터베이스(218)에 저장된다. 모듈(214)은 그 자체에서 사용자명, 가령, 랜덤 사용자명을 생성할하거나, 또는 가령 그래픽 사용자 인터페이스를 통해 사용자와 함께 적절한 사용자명을 선택하는 작업을 할 수 있다. 클라이언트 장치(202)의 HTTPS 모듈(216)은 PDTN, 논스 및 사용자명을 서버(204)의 HTTPS 모듈(220)에 송신한다. 초기 사용자명(252) 및 클라이언트 장치 전화 번호(250)가 처리되고(가령, 서버는, 이 데이터가 데이터베이스 내에 존재하고 이미 등록을 완료하지 않은 적법한 사용자에 대응한다는 것을 보증하기 위해 데이터베이스(222 또는 238)에 쿼링(querying)함으로써, 이 데이터에 대한 몇몇 검사를 수행할 수 있다.), 그런 다음 모듈(254)에서 액세스 사용자명(256)을 생성하기 위해 사용된다. 액세스 사용자명(256) 및 클라이언트 장치 전화 번호(PDTN)(250)는 데이터베이스 또는 메모리(222)에 저장된다. 패스워드 모듈(224)은 액세스 사용자명과 연관되는 패스워드를 생성하고, 이 패스워드를 데이터베이스(222)에 저장한다(또는 당업자에게는 명백한 바와 같이, 패스워드 및 솔트 데이터(salt data)의 해시(hash)를 저장한다). 패스워드 및 논스는 메시지 모듈(226)에 의해 클라이언트 장치(202)에 송신되는 메시지를 구성하는데 사용된다. 메시지는 SMS 메시지 또는 다른 메시지일 수 있다. 메시지는 HTTPS를 통해 수신된 전화 번호를 갖는 클라이언트 장치(202)에 송신된 다. 핸드셋은 모듈(118) 내에서 메시지를 수신하고, 모듈(230)에서 논스가 송신된 논스와 동일한 논스임을 검증한다. 만약 논스가 일치하면, 고유 액세스 사용자명이 액세스 사용자명 생성 모듈(219)에 의해 결정적으로 생성된다. 예를 들어, 액세스 사용자명은 클라이언트 장치 전화 번호(206)와 초기 사용자명(212)으로부터 생성되어, 데이터베이스(218)에 저장될 수 있다. 대안적으로, 액세스 사용자명은, 이 사용자명이 서버 엔티티에 대한 클라이언트를 고유하게 식별시키는데 사용될 수 있다는 것을 보증하는 방식으로 선택된 한, 모듈(214)에 의해 생성된 것과 동일한 사용자명일 수 있다.

클라이언트 장치(202)가 전화 번호와 연관된 개인 콘텐츠를 검색하기를 원하는 경우, 클라이언트 장치(202)는 저장된 액세스 사용자명 및 패스워드를 이용한 기본 인증을 사용하여, HPPTS 모듈(234)로부터의 HTTPS 접속을 형성할 수 있다. HTTPS 모듈(216, 234)은 동일한 모듈일 수 있다. 또한, 기본 인증 이외의 다이제스트 액세스 인증이 사용될 수 있다. 서버(204)는 HTTPS 모듈(236)을 통해 인증 정보를 수신하고, 데이터베이스(222) 내의 액세스 사용자명 및 패스워드(또는 패스워드 해시)를 조사(look up)할 수 있다. HTTPS 모듈(220, 236)은 동일한 모듈일 수 있다. 또한, 일치하는 사용자/패스워드 쌍은 전화 번호(PDTN)와 연관되며, PDTN은 데이터베이스(238)에서 계좌 정보를 조사하는데 사용된다. 그리고 나서, 계좌 특정 정보가 클라이언트 장치(202)로 귀환된다. 클라이언트 장치(202)는 HTTPS 모듈(234)을 통해 계좌 특정 정보(240)를 수신한다.

도 1 및 2를 참조하여 상술한 방법에서는 캐리어가 신뢰되는 것으로 가정되 어 있다. 이는, 가령, 캐리어가 SMS 메시지를 상기 언급된 수신자에게 전달할 것임을 의미한다. 비록 캐리어가 SMS를 다른 누군가에게 전달하거나, 또는 자신이 유지하고 있다할지라도(즉, 캐리어가 손상되어 있음), 사용자명이 안전한 이상, 보안 문제는 존재하지 않을 것이다(사용자명이 클라이언트와 서버 사이에서 안전한 엔드투엔드인 개별 송신(a trnasfer in a separate)(108)을 통해 송신됨). 만약 사용자명이 안전한 경우(즉, 비밀 유지되고 충분한 엔트로피를 보유함), SMS 메시지의 수신자는 계좌용 패스워드만을 가지며, 액세스는 할 수 없을 것이다. 또한, 캐리어는 충분히 신뢰할 가치가 있고, "활성" 맨인더미들 공격을 취하지 않을 것으로 가정된다. 즉, 적대적 캐리어는 자신이 선택한 사용자명을 갖는 원래 HTTPS를 생성했을 것이다. 캐리어로부터 이 HTTPS의 수신시, 사업자는 이 캐리어 선택 사용자명(carrier-chosen username)으로 계좌를 활성화시키고, 논스 및 패스워드를 갖는 SMS 메시지를 환송했을 것이다. 캐리어는 이 환송 SMS 메시지를 인터셉트(intercept)하여, 피해자 계좌용 패스워드 및 사용자명을 가질 것이다.

이 방법은 인증된 호출자 ID 또는 SMS 소스 전화 번호에만 의존하지는 않는다.

이 방법은 특히 전화 핸드셋의 전화 번호와 연관된 계좌 기반 정보에 유용하다. 이 정보는 계좌 잔액, 선호 고객 정보(preferred customer), 미지불 주문 등과 같은 아이템을 포함할 수 있다.

강력한 보안 패스워드(가령, 비사전적 표현)가 사업자 서버에 의해 자동적으로 생성되기 때문에, 보안이 강화된다. 패스워드는 사용자가 개입할 필요 없이 생 성되고, 이에 의해, 사용자가 부적절하게 패스워드를 누설하는 것을 막으며, 사용자가 패스워드를 생성 또는 유지할 필요성을 제거함으로써, 사용자의 경험을 단순화한다.

SMS 메시지는 위조될 수 있지만(즉, 수신자는 메시지의 기원을 확인 할 수 없음), 위조 메시지 공격은 상술한 방법으로 방지될 수 있는 것으로 알려져 있다. 예를 들어, 적수(adversary)가 잠재적 희생자의 전화 번호로부터 유래하는 것으로 보이는 그 전화 번호를 사업자에게 송신할 수 있다. 그러나, 이는 사업자가 패스워드를 포함하는 SMS 메시지로 적수의 전화보다는 희생자의 전화에 응답하게 한다. 적수가 이 응답 SMS 메시지를 인터셉트 및 암호해독하는 것은 어렵기 때문에, 그는 희생자의 패스워드를 알 수 없다. 또한, 희생자의 전화는, 요청도 없고 연관된 논스도 없었기 때문에, 수신된 메시지를 폐기할 수 있다.

SMS 메시지는 캐리어에 의해 암호화되고, 반환된 패스워드와 논스는 도청으로부터 보호된다.

요청되지 않은 수신 패스워드는, 수신된 논스가 핸드셋 생성 논스와 일치하지 않은 경우에 자동적으로 폐기되기 때문에, 논스로부터 생성된 핸드셋은 "피싱" 공격에 대해 자동 보호된다.

패스워드는 사용자보다는 클라이언트 장치와 연관되며, 따라서 일부 어플리케이션에 대해 부가적 사용자 인증이 필요할 수 있다. 개인 식별 번호 또는 생물통계학의 사용과 같은 사용자 인증 기술은 당업자에게 잘 알려져 있고, 민감한 문서, 사진, 어드레스 등과 같은 다른 정보를 보호하는데 적용되고 있다.

다른 실시예에서, 사업자로부터 핸드셋으로서 여분 패스워드의 대역외 전달(out-of-band delivery)은, 엔드투엔드 보안을 필요로 할 수 있는 어플리케이션을 안전하게 하기 위해 사용된다. 이는 캐리어를 신뢰해야만 하는 것을 회피한다. 이 방법은 더 고가이지만, 더 향상된 보안을 제공한다.

몇몇 실시예에서, 패스워드는 HTTP REST(resource state transfer) 프로토콜을 이용하여 관리된다. 예를 들어, 등록 URL 상의 HTTP POST 버브(verb)는 초기 패스워드를 생성하기 위해 사용될 수 있다. 바디(또는 URL 쿼리 스트링)는 핸드셋 전화 번호, 논스 및 사용자명을 포함할 수 있다. 등록 URL에 대한 기본 인증에 사용자명/패스워드 자격증명을 갖는 HTTP DELETE 버브는 현재 패스워드를 요구하는데 사용될 수 있을 것이다. 등록 URL에 대한 기본 인증에서 사용자명/패스워드 자격증명을 갖는 HTTP UPDATE 버브는 새로운 패스워드를 요청하는데 사용될 수 있다. 등록 URL에 대한 기본 인증에서 사용자명/패스워드 자격증명을 갖는 HTTP GET 버브는 현재 패스워드를 요청하는데 사용될 수 있다.

클라이언트 장치가 분실 또는 도난된 경우, 본 발명은 장치에 대한 임의의 다른 어플리케이션과 동일한 레벨의 보안을 가진다는 점에 유의해야 한다. 이 문제에 대한 하나의 단순한 해결책은, 개인 식별 번호(PIN) 또는 다른 보안 입력(지문 등)이 먼저 입력되어 클라이언트 장치를 잠금해제(unlock)하지 않는다면, 클라이언트 장치에 대한 잠금(lock)을 사용하여 클라이언트 장치가 사용될 수 없도록 하는 것이다.

HTTP 인증에 사용된 사용자명(이하, "액세스 사용자명")은 모든 핸드셋들간 에 고유해야 한다. 핸드셋 전화 번호는 고유하지만 공개적으로 볼 수 있고, 초기 사용자명은 볼 수는 없지만, 고유하지 않을 수 있기 때문에, 초기 사용자명(도 2의 212)과 핸드셋 전화 번호(206)의 함수로서 액세스 사용자명을 생성하는 것은 고유할 뿐만 아니라 볼 수 없는 액세스 사용자명을 제공한다. 액세스 사용자명을 생성하는 단순한 방법은 사용자명의 끝에 전화 번호를 연결시키는(concatenate) 것이다. 본 발명의 일 실시예에서, 서버는 전화 번호(240)를 등록 요구에서 제출된 초기 사용자명(242)에 첨부하여 액세스 사용자명(226)을 생성한다. 이 동작은 핸드셋이 패스워드를 수신할 때, 핸드셋이 그 자신의 전화 번호(206)를 초기 사용자명(212)에 연결시켜 액세스 사용자명/패스워드 쌍(219)을 생성하도록 하는 핸드셋에 의해 공지되어 있다. 예를 들어, 핸드셋은 전화 번호 15558881212를 갖는 사용자명 "Tom"을 생성하고, 이를 사업자에 송신하여 패스워드를 요청한다. 사업자는 패스워드를 생성하고, 이를 핸드셋에 환송한다. 사업자는 생성된 패스워드를 사용자명 TOM15558881212와 연관시킨다. 핸드셋이 패스워드를 수신할 때, 핸드셋은 사용자명 Tom15558881212를 생성하고, 이를 패스워드와 함께 저장한다. 그런 다음, Tom15558881212라는 표현은 HTTP 기본 인증을 위한 사용자명으로서 사용된다. 사용자명 및 전화 번호는, 고유 액세스 사용자명을 생성하기 위해 다른 방법으로 조합될 수도 있다. 당업자는, 핸드셋(219)과 서버(254) 모두가 초기 사용자명과 핸드셋 전화 번호로부터 액세스 사용자명을 생성하는 방법에 동의하고 있는 한, 더 복잡한 액세스 사용자명을 생성하기 위해 해싱 함수 등을 사용할 수 있다. 다른 요건은, 액새스 사용자명이 서버 엔티티에 대해 클라이언트를 고유하게 식별하는데 사용될 수 있는 방식으로 선택되는 것이다. 다른 사용자명이 각 서버 엔티티에 사용될 수 있으며, 또는 동일 사용자명이 모든 서버 엔티티에 대해 사용될 수도 있다.

초기 사용자명이 핸드셋(214)상에서 생성된다. 이 사용자명은 자동적으로 생성될 수 있고, 사용자에게 노출될 필요가 없다. 어떤 임의의 심볼 집합이 사용될 수 있다.

도 3은 상호 인증을 이용한 예시적인 패스워드 분배 방법의 플로우 차트이다. 도 3을 참조하면, 개시 블럭(302)에 후속하여, 블럭 304에서, 클라이언트가 논스(랜덤 심볼)와 초기 사용자명을 생성한다(또는 이미 생성된 초기 사용자명을 액세스한다). 블럭 306에서, 클라이언트는 HTTPS와 같은 보안 송신 프로세스를 이용하여, 논스를 클라이언트의 전화 번호(또는 다른 네트워크 어드레스) 및 초기 사용자명과 함께 사업자 서버에 송신한다. 만약, 시스템이 보안 강도의 감소(즉, 정보가 인터셉트 및 판독되고, 클라이언트가 서버를 인증하지 않을 수 있음)를 감내할 수 있다면, 비보안 송신 프로세스(가령, HTTP)가 사용될 수도 있다. 블럭 308에서, 사업자 서버는 등록 패스워드를 생성한다. 블럭 310에서, 서버는, 제1 메시지 내에 특정된 전화 번호를 이용하여, 패스워드 및 논스를 클라이언트에 환송한다. 논스 및 패스워드는, 가령, SMS를 이용하여 송신될 수도 있다. 클라이언트가 패스워드 및 논스를 수신한 경우, 판정 블럭(312)에서는, 논스가 304에서 생성된 논스와 동일한 논스인지가 판정된다. 만약 판정 블럭(312)으로부터의 긍정 브랜치에 의해 도시된 바와 같이, 논스가 일치하는 경우에는, 블럭 314에서 패스워드가 이 특정 사업자에 대한 액세스 사용자명과 함께 핸드셋에 저장된다. 액세스 사용자명이 304에서 생성된 초기 사용자명과 전화 번호의 함수로서 생성된다. 이는 "등록" 프로세스를 완료시킨다. 만약, 논스가 일치하지 않는다면, 또는 패스워드 요청이 이루어지지 않았다면, 패스워드는 폐기되고 프로세스는, 판정 블럭(312)으로부터의 부정 브랜치에 의해 도시된 바와 같이, 블럭 322에서 종료된다. 등록 프로세스를 위해서는 하나의 SMS 메시지만이 필요하다. 이 핸드셋의 전화 번호와 연관된 액세스 콘텐츠에 액세스하기 위해, 클라이언트는 블럭(316)에서 등록 처리에서 취득된 액세스 사용자명 및 패스워드를 이용하여 사업자에 대한 HTTPS 접속을 셋업한다. 블럭(318)에서, 클라이언트는 HTTPS를 이용하여 서버로부터 콘텐츠를 요청하고, 클라이언트는 HTTPS를 다시 이용하여, 그 전화 번호와 연관된 콘텐츠를 수신한다. 만약, 보안 강도의 감소가 수용될 수 있다면, HTTP를 이용한 비보안 접속이 사용될 수 있다. 정규 콘텐츠 액세스(318, 320)에는 SMS가 필요치 않을 것이다. 이 프로세스는 블럭(322)에서 종료한다.

상술한 명세서에서, 본 발명의 특정 실시예가 기술되었다. 그러나, 당업자는 이하 청구범위에 기재되는 본 발명의 범주를 벗어남이 없이 다양한 변경 및 변형이 이루어질 수 있음을 이해할 것이다. 따라서, 본 명세서 및 도면은 제한보다는 해석을 위한 것으로 이해되어야 할 것이며, 그러한 모든 변경은 본 발명의 범주에 포함되는 것으로 이해되어야 할 것이다. 이점, 이익, 문제에 대한 해결책 및 임의의 이점, 이익 또는 문제에 대한 해결책이 더 알려지도록 할 수 있는 임의의 엘리먼트는 청구항 중 어느 하나 또는 전부의 중요한, 필요한 또는 필수적인 요소 또는 엘리먼트로서 해석되지 않는다. 본 발명은 본 출원의 계류 중에 이루어지는 임의의 보정을 포함하는, 첨부된 청구항 또는 발행된 이 청구항의 모든 균등물에 의해서만 정의된다.

Claims (10)

1. 클라이언트와 서버를 포함하는 네트워크에서의 패스워드 분배 방법으로서,

   상기 클라이언트가 제1 논스(nonce)를 생성하는 단계와,

   상기 클라이언트가 상기 클라이언트의 제1 논스와, 초기 사용자명(initial username) 및 네트워크 어드레스를 상기 서버에 송신하는 단계와,

   상기 클라이언트가 상기 서버로부터 제2 논스 및 패스워드를 수신하는 단계와,

   상기 제1 논스가 상기 제2 논스와 동일할 경우, 상기 클라이언트가 상기 패스워드를 액세스 사용자명과 연관시키는 단계

   를 포함하는 패스워드 분배 방법.
2. 제1항에 있어서,

   상기 액세스 사용자명은 상기 초기 사용자명에 의존하는 패스워드 분배 방법.
3. 제1항에 있어서,

   상기 클라이언트가 상기 초기 사용자명을 생성하는 단계와,

   상기 클라이언트가 상기 액세스 사용자명을 생성하는 단계

   를 더 포함하는 패스워드 분배 방법.
4. 제1항에 있어서,

   상기 클라이언트는 보안 송신(secure transfer)을 이용하여 상기 제1 논스, 상기 초기 사용자명 및 상기 네트워크 어드레스를 상기 서버에 송신하는 패스워드 분배 방법.
5. 제1항에 있어서,

   상기 서버가 상기 제1 논스, 상기 초기 사용자명 및 상기 네트워크 어드레스를 수신하는 단계와,

   상기 서버가 상기 패스워드를 생성하는 단계와,

   상기 서버가 상기 제2 논스 및 상기 패스워드를 상기 특정 네트워크 어드레스에서 상기 클라이언트에 송신하는 단계

   를 더 포함하며,

   상기 제2 논스는 상기 수신된 제1 논스와 동일한 패스워드 분배 방법.
6. 휴대형 장치로서,

   제1 논스를 생성하도록 동작가능한 논스 생성 모듈과,

   상기 휴대형 장치의 제1 논스, 초기 사용자명 및 네트워크 어드레스를 네트워크 서버에 송신하도록 동작가능한 송신 모듈과,

   제2 논스 및 패스워드를 상기 네트워크 서버로부터 수신하도록 동작가능한 메시지 모듈과,

   상기 제1 논스와 상기 제2 논스를 비교하도록 동작가능한 논스 검증 모듈과,

   상기 네트워크 어드레스 및 상기 초기 사용자명에 따라, 액세스 사용자명을 생성하도록 동작가능한 액세스 사용자명 생성 모듈과,

   상기 제1 논스가 상기 제2 논스와 동일한 경우, 상기 액세스 사용자명 및 상기 패스워드를 저장하도록 동작가능한 메모리

   를 포함하는 휴대형 장치.
7. 제6항에 있어서,

   상기 초기 사용자명을 생성하도록 동작가능한 초기 사용자명 생성 모듈을 더 포함하는 휴대형 장치.
8. 제6항에 있어서,

   상기 휴대형 장치는 전화 핸드셋을 포함하고, 상기 네트워크 어드레스는 상기 전화 핸드셋의 전화 번호를 포함하는 휴대형 장치.
9. 제6항에 있어서,

   상기 메시지 모듈은 SMS(Small Message Service) 모듈을 포함하는 휴대형 장치.
10. 제6항에 있어서,

    상기 송신 모듈은 HTTP(Hyper Text Transfer Protocol) 모듈을 포함하는 휴대형 장치.

Images