專利名稱：至網(wǎng)絡(luò)中的客戶端設(shè)備的安全口令分發(fā)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明一般涉及網(wǎng)絡(luò)中的客戶端設(shè)備與服務(wù)器之間的通信。
背景技術(shù)：
有時(shí)期望從客戶端設(shè)備(例如，諸如蜂窩手機(jī)、個(gè)人計(jì)算 機(jī)、PDA或膝上型電腦)訪問(wèn)與賬戶相關(guān)聯(lián)的在線個(gè)人信息。 一個(gè)示 例是在商品超市處的消費(fèi)者賬戶，其中個(gè)人信息可以包括用戶的結(jié)余、 當(dāng)前特有的消費(fèi)、未結(jié)算訂購(gòu)等。用于管理對(duì)這些信息的訪問(wèn)的常見(jiàn) 方法是，客戶端設(shè)備(例如，用戶的便攜式設(shè)備)在注冊(cè)階段與服務(wù) 實(shí)體(例如，商品超市的web服務(wù)器)共享某些形式的用戶名和口令 (即，證書(shū))。接下來(lái)，所述用戶名和口令可以實(shí)現(xiàn)對(duì)用戶的在線個(gè)人 信息的訪問(wèn)，典型地使用安全信道上的具有基本認(rèn)證的超文本傳輸協(xié) 議(HTTP)，諸如安全套接層上的HTTP (HTTPS)或分類訪問(wèn)認(rèn)證。管理對(duì)來(lái)自客戶端設(shè)備(諸如移動(dòng)電話、PDA等)的個(gè)人 信息(通常被稱為"內(nèi)容")的訪問(wèn)是非常困難的。通常需要包括創(chuàng)建用 于賬戶的用戶名和口令的注冊(cè)階段，以及然后在客戶端和服務(wù)實(shí)體之 間對(duì)該信息的安全共享。出于安全的目的，服務(wù)實(shí)體必須將正在注冊(cè) 的客戶端認(rèn)證為被授權(quán)訪問(wèn)所述內(nèi)容的實(shí)體。同樣地，客戶端必須確 定其正在注冊(cè)到可信服務(wù)器實(shí)體。也就是說(shuō)，需要具有相互認(rèn)證的特 性的解決方案。其中欺詐客戶端偽裝成另一客戶端以便獲得對(duì)該客戶 端內(nèi)容的訪問(wèn)的攻擊，以及其中欺詐服務(wù)器偽裝成真正服務(wù)器以便獲 得對(duì)可信客戶端的證書(shū)的訪問(wèn)的攻擊應(yīng)當(dāng)是不可行的。因此，需要用 于在客戶端設(shè)備和服務(wù)器之間安全地創(chuàng)建和共享證書(shū)(例如，用戶名/ 口令對(duì))的某些方法以使得這些證書(shū)可以在后來(lái)被用于訪問(wèn)來(lái)自服務(wù)
4器的內(nèi)容，例如，被用在HTTP基本認(rèn)證中的證書(shū)。 —種方法用于服務(wù)器實(shí)體使用短消息服務(wù)(SMS)來(lái)向特 定的蜂窩手機(jī)發(fā)送口令和用戶名。包含口令的SMS消息將從網(wǎng)絡(luò)的網(wǎng) 絡(luò)服務(wù)管理接入點(diǎn)傳播至手機(jī)。在該方法中，運(yùn)營(yíng)商向服務(wù)器實(shí)體提 供保證即只有具有特定移動(dòng)站綜合業(yè)務(wù)數(shù)字網(wǎng)絡(luò)編號(hào)(MSISDN)的 手機(jī)接收到該口令。該方法的一個(gè)缺點(diǎn)是可以容易地欺騙SMS消息中 的發(fā)送者地址信息(即，某人發(fā)送傳輸錯(cuò)誤發(fā)送者地址的SMS消息是 相對(duì)容易的)。在網(wǎng)絡(luò)接入點(diǎn)(諸如蜂窩基站)和手機(jī)之間的空中傳 輸過(guò)程中，SMS消息的內(nèi)容通常被保護(hù)(經(jīng)由加密)以防止竊聽(tīng);然而 客戶端不能魯棒地將所接收到的SMS消息認(rèn)證為源自該消息中所指示 的服務(wù)器實(shí)體。因此，不能實(shí)現(xiàn)相互認(rèn)證并且所述客戶端不能確信所 接收到的口令和用戶名是可信的。另一個(gè)方法是用于客戶端實(shí)體經(jīng)由短消息服務(wù)(SMS)數(shù) 字地、或經(jīng)由電話呼叫口頭地向特定服務(wù)器實(shí)體發(fā)送口令和用戶名。 因?yàn)樵谶@樣的SMS消息中易于欺騙發(fā)送者地址信息，或者在電話呼叫 的情況中，呼叫者ID缺少安全性(即，呼叫者ID也能夠被欺騙)， 因此問(wèn)題再次出現(xiàn)。所述服務(wù)器不能確信所接收到的口令和用戶名是 可信的。對(duì)于諸如賬戶激活的行為，電子郵件和SMS也正變得受 歡迎。通常賬戶激活僅被執(zhí)行一次，并且不被用于參考信息。因此，在所有這些方法中，沒(méi)有達(dá)到相互認(rèn)證和安全共享 口令和用戶名的目標(biāo)。并且，需要客戶端處的用戶的相互干預(yù)以確認(rèn) 口令和用戶名被接收并被接受。仍然需要一種方法，在該方法中在不 依靠易被偽造的信息的真實(shí)性的情況下與服務(wù)器共享客戶端的證書(shū)并 且獲得相互認(rèn)證，所述易被偽造的信息諸如呼叫者ID或SMS消息中 的發(fā)送者地址。
另一個(gè)相關(guān)技術(shù)被用在管理電子郵件分發(fā)列表的應(yīng)用中， 其中某人可以不對(duì)一些服務(wù)預(yù)訂。在這種情況下，服務(wù)器創(chuàng)建隨機(jī)數(shù) (隨機(jī)符號(hào))并且將其編碼到經(jīng)由電子郵件遞送的URL中。這種類型 的系統(tǒng)僅提供單方向認(rèn)證(服務(wù)能夠?qū)蛻舳苏J(rèn)證)，但在另一個(gè)方 向上不提供認(rèn)證(客戶端無(wú)法對(duì)發(fā)送者的電子郵件地址進(jìn)行認(rèn)證)。 因此，即使服務(wù)器能夠驗(yàn)證該非預(yù)訂請(qǐng)求是有效的，該客戶端也不能 證明所接收到的請(qǐng)求確實(shí)是來(lái)自所期望的服務(wù)器。這使單方向認(rèn)證易 受"網(wǎng)絡(luò)釣魚(yú)(phishing)"的攻擊，其中"看起來(lái)相似"的消息被發(fā) 送到不同的客戶端，希望某個(gè)來(lái)觸發(fā)URL。最后， 一種公密鑰方法可以被用于獲得相互認(rèn)證并且建立 安全信道用于傳遞用戶名和口令信息。在這種情況下，服務(wù)器和客戶 端每一個(gè)將被指配唯一私密鑰和公密鑰憑證。然而這樣的系統(tǒng)將需要
部署非常昂貴的新的公密鑰基礎(chǔ)設(shè)施，或重新使用現(xiàn)有的公密鑰基礎(chǔ) 設(shè)施。重新使用現(xiàn)有的基礎(chǔ)設(shè)施將需要克服技術(shù)和商業(yè)上的問(wèn)題，諸 如新的許可和依從要求。


在附圖的各個(gè)獨(dú)立的視圖中，相同的附圖標(biāo)記表示相同的 或功能相似的元件，附圖連同下面的詳細(xì)描述一起被并入說(shuō)明書(shū)并且 形成說(shuō)明書(shū)的一部分，用于進(jìn)一步說(shuō)明各個(gè)實(shí)施例并且用于解釋所有 根據(jù)本發(fā)明的各種原理及優(yōu)點(diǎn)。圖l是根據(jù)本發(fā)明一些實(shí)施例的具有相互認(rèn)證的口令分發(fā) 的示例性消息序列圖。圖2是根據(jù)本發(fā)明一些實(shí)施例的安全口令分發(fā)的示例性系統(tǒng)。圖3是根據(jù)本發(fā)明一些實(shí)施例的安全口令分發(fā)方法的流程圖。
6
技術(shù)人員將了解出于簡(jiǎn)單和清楚的目的示出了附圖中的 元件并且沒(méi)有必要按照比例繪制這些元件。例如，附圖中一些元件的 尺寸可能相對(duì)于其他元件被放大，以幫助提高對(duì)本發(fā)明實(shí)施例的理解。
具體實(shí)施例方式在詳細(xì)描述根據(jù)本發(fā)明的實(shí)施例之前，應(yīng)當(dāng)了解到這些實(shí) 施例主要存在于與至客戶端設(shè)備的口令分發(fā)相關(guān)的方法步驟和裝置組 件的組合中。因此，在附圖中，在適當(dāng)?shù)牡胤揭延贸Ｒ?guī)的符號(hào)表示了 裝置組件和方法步驟，僅示出了與理解本發(fā)明的實(shí)施例有關(guān)的那些具 體細(xì)節(jié)，以避免對(duì)于具有此處描述的益處的本領(lǐng)域普通技術(shù)人員來(lái)說(shuō) 顯而易見(jiàn)的細(xì)節(jié)使本公開(kāi)模糊難懂。在本文檔中，關(guān)系術(shù)語(yǔ)，諸如第一和第二、頂部和底部等 等可以僅用來(lái)將一個(gè)實(shí)體或者動(dòng)作與另一個(gè)實(shí)體或者動(dòng)作區(qū)分開(kāi)，而 不必要求或暗示在該實(shí)體或動(dòng)作之間的任何實(shí)際的這種關(guān)系或者順 序。術(shù)語(yǔ)"包括"或其任何其他變型，旨在涵蓋非排他性內(nèi)含物，使得包 括一系列元件的過(guò)程、方法、物件、或裝置不僅包括該元件，還可以 包括未明確列出的或者所述過(guò)程、方法、物件、或裝置所固有的其他 元件。以"包括…一"開(kāi)始的元件，在沒(méi)有更多限制的情況下，不排除在 包括所述元件的過(guò)程、方法、物件或裝置中其他同樣元件的存在。將理解，在此描述的本發(fā)明實(shí)施例可以由一個(gè)或多個(gè)常規(guī) 處理器和唯一存儲(chǔ)的程序指令組成，該程序指令控制一個(gè)或多個(gè)處理 器協(xié)同特定的非處理器電路實(shí)現(xiàn)在此描述的口令分發(fā)的一些、多數(shù)或 所有功能。所述非處理器電路可以包括但不限于無(wú)線電接收機(jī)、無(wú)線 電發(fā)射機(jī)、信號(hào)驅(qū)動(dòng)器、時(shí)鐘電路、電源電路和用戶輸入設(shè)備。同樣 地，這些功能可以被解釋為用于執(zhí)行至客戶端設(shè)備的口令分發(fā)的方法。 可替代地，可由不具有存儲(chǔ)的程序的狀態(tài)機(jī)實(shí)現(xiàn)某些或所有功能，或 者在一個(gè)或多個(gè)專用集成電路(ASIC)中實(shí)現(xiàn)某些或所有功能，其中每一個(gè)功能或特定功能的某些組合被實(shí)現(xiàn)為定制邏輯。當(dāng)然，可以使 用兩個(gè)方法的組合。因此，在此已描述了用于這些功能的方法和裝置。 而且，將預(yù)期到本領(lǐng)域的一個(gè)普通技術(shù)人員盡管可能被例如可用時(shí)間、 現(xiàn)有技術(shù)和經(jīng)濟(jì)方面的考慮所激勵(lì)而付出巨大的努力并且具有很多設(shè) 計(jì)選擇，但當(dāng)被此處所公開(kāi)的概念和原理指導(dǎo)時(shí)，能夠通過(guò)最少的實(shí)
驗(yàn)生成這樣的軟件指令和程序以及ic。有時(shí)期望從客戶端設(shè)備(例如，諸如蜂窩手機(jī)、個(gè)人計(jì)算 機(jī)、PDA或膝上型電腦)訪問(wèn)與賬戶相關(guān)聯(lián)的在線個(gè)人信息。 一個(gè)示 例是在商品超市處的消費(fèi)者賬戶，其中個(gè)人信息可以包括用戶的結(jié)余、 當(dāng)前特有的消費(fèi)、未結(jié)算訂購(gòu)等。用于管理對(duì)該信息的訪問(wèn)的常見(jiàn)方 法是，客戶端設(shè)備(例如，用戶的便攜式設(shè)備)在注冊(cè)階段與服務(wù)實(shí) 體(例如，商品超市的web服務(wù)器)共享某些形式的用戶名和口令(即， 證書(shū))。接下來(lái)，所述用戶名和口令可以實(shí)現(xiàn)對(duì)用戶的在線個(gè)人信息 的訪問(wèn)，典型地使用安全信道上的具有基本認(rèn)證的超文本傳輸協(xié)議 (HTTP)，諸如安全套接層上的HTTP (HTTPS)或分類訪問(wèn)認(rèn)證。因此，需要用于在手機(jī)和服務(wù)器之間安全地創(chuàng)建和共享證 書(shū)(例如，用戶名/口令對(duì))的一些方法以使得這些證書(shū)可以在后來(lái)被 用于從所述服務(wù)器訪問(wèn)內(nèi)容，例如，被用在HTTP基本認(rèn)證中的證書(shū)。本發(fā)明涉及在客戶端設(shè)備和服務(wù)器之間創(chuàng)建和共享證書(shū)， 諸如用戶名/口令對(duì)，以使得這些證書(shū)可以在后來(lái)被用于訪問(wèn)來(lái)自服務(wù) 器的內(nèi)容(例如，個(gè)人信息)。例如，這些證書(shū)可以被用在HTTP基 本認(rèn)證中。 一般地，客戶端設(shè)備本身不能創(chuàng)建用戶名和口令，因?yàn)檫@ 需要一種安全方法來(lái)向商家傳輸它們。也就是說(shuō)，商家將需要確定這 些證書(shū)的真實(shí)性。在沒(méi)有使用昂貴的公密鑰基礎(chǔ)設(shè)施的情況下，倘若 缺少端到端的通信安全性(例如，SMS是可被偽造的發(fā)送者地址)， 那么這將是個(gè)難于解決的問(wèn)題。另外，商家自身不能創(chuàng)建用戶名和口 令，因?yàn)檫@需要一種安全方法來(lái)向手機(jī)傳輸它們。也就是說(shuō)，手機(jī)將需要確定這些證書(shū)的真實(shí)性，由于同樣的原因(例如，不安全的SMS 或昂貴的基礎(chǔ)設(shè)施)，這也是困難的。因此，需要用于在客戶端設(shè)備 上使用的安全地創(chuàng)建用戶名和口令對(duì)的一些方法。在本發(fā)明的一個(gè)實(shí) 施例中，客戶端設(shè)備創(chuàng)建用戶名，而商家創(chuàng)建口令。在這個(gè)方法中， 口令被安全地傳遞到客戶端設(shè)備。為了提供安全的口令分發(fā)，假設(shè)運(yùn) 營(yíng)商是可信任的實(shí)體。認(rèn)證手機(jī)的一個(gè)挑戰(zhàn)是呼叫者標(biāo)識(shí)(呼叫者ID)信息是不 安全的。例如，某人進(jìn)行傳輸錯(cuò)誤呼叫者ID的呼叫是相對(duì)容易的。而 且，即使在網(wǎng)絡(luò)接入點(diǎn)(例如，蜂窩基站)和手機(jī)之間的空中傳輸過(guò) 程中，SMS消息的內(nèi)容通常被保護(hù)(經(jīng)由加密)以防止竊聽(tīng)，SMS消 息的發(fā)送者地址也能夠被偽造。為了安全地創(chuàng)建用戶名/口令對(duì)，必須執(zhí)行相互認(rèn)證，也就 是說(shuō)，客戶端設(shè)備用戶需要確保商家能夠證明其身份，以及商家需要 確認(rèn)進(jìn)行請(qǐng)求的手機(jī)的身份。本發(fā)明允許用戶名/口令對(duì)在沒(méi)有用戶干預(yù)的情況下自動(dòng) 地被創(chuàng)建。在設(shè)計(jì)安全方法中，必須針對(duì)被保護(hù)的資產(chǎn)(即，資產(chǎn)的 價(jià)值)、該資產(chǎn)的弱點(diǎn)、對(duì)這些弱點(diǎn)潛在的威脅和攻擊以及與這些威 脅和攻擊(例如，攻擊的可能性)相關(guān)聯(lián)的風(fēng)險(xiǎn)來(lái)進(jìn)行考慮。例如， 被訪問(wèn)的內(nèi)容可能是個(gè)人信息而不是財(cái)務(wù)信息。對(duì)個(gè)人信息，諸如賬 戶信息、消費(fèi)者折扣信息、定購(gòu)狀態(tài)等的保護(hù)可能不如對(duì)財(cái)務(wù)應(yīng)用信 息的保護(hù)重要，財(cái)務(wù)應(yīng)用信息諸如銀行賬號(hào)或銀行口令和用戶名等。本發(fā)明假設(shè)運(yùn)營(yíng)商是可信任的實(shí)體并且將不允許安全性 被歸避。應(yīng)當(dāng)注意的是對(duì)于具有較大風(fēng)險(xiǎn)和較高價(jià)值的資產(chǎn)的情況， 諸如具有財(cái)務(wù)應(yīng)用的情況，運(yùn)營(yíng)商可能不被財(cái)政機(jī)構(gòu)信任。在本發(fā)明
9中所傳輸?shù)目诹詈陀脩裘赡芤资軔阂獾幕蚴韬龅倪\(yùn)營(yíng)商的攻擊；因 此，在本發(fā)明中，假設(shè)運(yùn)營(yíng)商被服務(wù)器實(shí)體信任從而不允許這樣的攻 擊發(fā)生。該協(xié)議包括兩個(gè)基本的操作。第一個(gè)操作是"注冊(cè)"操作， 在該操作中，客戶端設(shè)備將其網(wǎng)絡(luò)地址以及用戶名與口令相關(guān)聯(lián)。例 如，網(wǎng)絡(luò)地址可以是蜂窩電話的電話號(hào)碼。第二個(gè)操作是使用用戶名 和口令對(duì)內(nèi)容的請(qǐng)求。圖1是具有相互認(rèn)證的口令分發(fā)的示例性消息序列圖，并 且示出了用于客戶端設(shè)備("客戶端")的時(shí)線102和用于商家("服 務(wù)器")的時(shí)線104。參考圖1，在106，客戶端創(chuàng)建隨機(jī)數(shù)(隨機(jī)或 不可預(yù)測(cè)的符號(hào))并且在108，使用安全傳輸過(guò)程，例如HTTPS，將 隨機(jī)數(shù)連同其電話號(hào)碼(或其他網(wǎng)絡(luò)地址)和用戶名一起發(fā)送到商家 服務(wù)器。由于數(shù)據(jù)是被加密的，因此所述傳輸是安全的，所以該信息 能夠被商家服務(wù)器解密，但對(duì)任何"中間人(man-in-the middle)"的 竊聽(tīng)者保持私密。在IIO，商家將處理在108中接收到的消息。例如， 商家可以通過(guò)査詢數(shù)據(jù)庫(kù)來(lái)執(zhí)行對(duì)該消息的一些檢査，以確保所接收 到的注冊(cè)信息(例如，電話號(hào)碼或其他網(wǎng)絡(luò)地址)與存在于數(shù)據(jù)庫(kù)中 的并且還沒(méi)有完成注冊(cè)的合法用戶相對(duì)應(yīng)。而且，在110，商家創(chuàng)建口 令并且在112，使用第一消息中所指定的電話號(hào)碼(或其他網(wǎng)絡(luò)地址)， 將該口令和隨機(jī)數(shù)發(fā)送回到客戶端設(shè)備。可以使用短消息服務(wù)(SMS) 來(lái)發(fā)送隨機(jī)數(shù)和口令。當(dāng)手機(jī)接收到該口令和隨機(jī)數(shù)時(shí)，它在114驗(yàn) 證該隨機(jī)數(shù)就是在106中創(chuàng)建的隨機(jī)數(shù)。如果第一隨機(jī)數(shù)(被客戶端 發(fā)送的)與第二隨機(jī)數(shù)(從服務(wù)器接收到的)相匹配，則將該口令與 用于該特定商家的"訪問(wèn)"用戶名一起保存在手機(jī)上。這樣，如果第一隨 機(jī)數(shù)與第二隨機(jī)數(shù)相同，則所述客戶端將該口令與訪問(wèn)用戶名相關(guān)聯(lián)。"訪問(wèn)用戶名"是可由服務(wù)器實(shí)體使用以唯一地標(biāo)識(shí)客戶 端實(shí)體的用戶名。例如，能夠從108中所發(fā)送的初始用戶名和客戶端電話號(hào)碼(或其他網(wǎng)絡(luò)地址)推導(dǎo)出訪問(wèn)用戶名?？商娲兀L問(wèn)用
戶名可以與108中發(fā)送的用戶名相同，只要以下述方式來(lái)選擇該用戶 名即確保對(duì)于服務(wù)器實(shí)體該用戶名能夠被用來(lái)唯一地標(biāo)識(shí)該客戶端。 例如，108中的用戶名可以是具有足夠的長(zhǎng)度的隨機(jī)值，其不可能已經(jīng)
被另一客戶端使用過(guò)。在一些實(shí)施例中，用戶可以選擇用戶名并且通 過(guò)客戶端進(jìn)行工作的用戶可以與服務(wù)器實(shí)體協(xié)商以獲得合適的唯一的
用戶名。例如，如果在108中發(fā)送的用戶名已經(jīng)被另一客戶端所使用， 那么服務(wù)器將需要通知客戶端來(lái)選擇不同的用戶名。 —旦客戶端保存了訪問(wèn)用戶名和口令，即完成了所述"注 冊(cè)"過(guò)程。僅需要一個(gè)SMS消息。該SMS消息的一個(gè)目的是確保在 第一 HTTPS消息中標(biāo)識(shí)的客戶端具有經(jīng)由在108中發(fā)送的消息中所指 示的電話號(hào)碼的服務(wù)。該SMS消息的另一個(gè)目的是確保該口令僅被遞 送到在108處發(fā)送的消息中所指示的電話號(hào)碼所標(biāo)識(shí)的設(shè)備。例如， 如果使用了 HTTPS響應(yīng)(針對(duì)原始的HTTPS請(qǐng)求)來(lái)發(fā)送返回口令 和隨機(jī)數(shù)，而不是SMS，那么攻擊者可能利用偽電話號(hào)碼注冊(cè)。在116，為了訪問(wèn)與該手機(jī)的電話號(hào)碼相關(guān)聯(lián)的內(nèi)容，客 戶端設(shè)備使用在注冊(cè)過(guò)程中獲得的訪問(wèn)用戶名和口令來(lái)建立到商家的 HTTPS連接。在118，該手機(jī)然后再次使用HTTPS，接收與該電話號(hào) 碼相關(guān)聯(lián)的個(gè)人內(nèi)容。應(yīng)當(dāng)注意，如果安全強(qiáng)度的降低是可接受的， 則可以使用HTTP而不是HTTPS。其后，在不需要再次注冊(cè)的情況下，可以獲得另外的訪問(wèn)。 例如，在120,客戶端設(shè)備使用在注冊(cè)過(guò)程中獲得的用戶名和口令來(lái)建 立到商家的第二 HTTPS連接。在120,該手機(jī)再次使用HTTPS來(lái)接收 與該電話號(hào)碼相關(guān)聯(lián)的個(gè)人內(nèi)容。圖2中示出用于實(shí)現(xiàn)消息序列的示例性系統(tǒng)。所述系統(tǒng)包 括客戶端設(shè)備202，諸如蜂窩電話、手機(jī)、PDA、便攜式計(jì)算機(jī)、個(gè)人計(jì)算機(jī)等，以及被商家實(shí)體或其他信息提供商操作的服務(wù)器204?？蛻?端設(shè)備電話號(hào)碼(PDTN) 206或其他網(wǎng)絡(luò)地址，與由隨機(jī)數(shù)創(chuàng)建模塊 210所創(chuàng)建的隨機(jī)數(shù)208以及由模塊214所創(chuàng)建的用戶名212 —起被傳 遞到HTTPS傳輸模塊216并且還被存儲(chǔ)在存儲(chǔ)器或數(shù)據(jù)庫(kù)218中。模 塊214可以獨(dú)立地創(chuàng)建用戶名，例如，隨機(jī)用戶名，或可以和用戶一 起工作，例如經(jīng)由圖形用戶界面來(lái)選擇適當(dāng)?shù)挠脩裘??？蛻舳嗽O(shè)備202 的HTTPS模塊216發(fā)送PDTN、隨機(jī)數(shù)和用戶名到服務(wù)器204的HTTPS 模塊220。初始用戶名252和客戶端設(shè)備電話號(hào)碼250被處理(例如， 服務(wù)器可以通過(guò)查詢數(shù)據(jù)庫(kù)222或238對(duì)該數(shù)據(jù)執(zhí)行一些檢查以確保 該數(shù)據(jù)與存在于數(shù)據(jù)庫(kù)中的并且還沒(méi)有完成注冊(cè)的合法用戶相對(duì)應(yīng))， 并且然后被用于模塊254中以創(chuàng)建訪問(wèn)用戶名256。訪問(wèn)用戶名256和 客戶端設(shè)備電話號(hào)碼(PDTN) 250被存儲(chǔ)在數(shù)據(jù)庫(kù)或存儲(chǔ)器222中。 口令模塊224創(chuàng)建關(guān)聯(lián)于訪問(wèn)用戶名的口令并且將該口令(或者，如 對(duì)于本領(lǐng)域技術(shù)人員顯而易見(jiàn)的，將口令的哈希值(hash)和鹽數(shù)據(jù)(salt data))存儲(chǔ)到數(shù)據(jù)庫(kù)222中?？诹詈碗S機(jī)數(shù)被用于組成由消息模塊226 發(fā)送到客戶端設(shè)備202的消息。該消息可以是SMS消息或其他消息。 該消息被發(fā)送到具有經(jīng)由HTTPS接收到的電話號(hào)碼的客戶端設(shè)備202。 手機(jī)在模塊228中接收到該消息并且在模塊230中驗(yàn)證該隨機(jī)數(shù)與所 發(fā)送的隨機(jī)數(shù)相同。如果隨機(jī)數(shù)匹配，那么訪問(wèn)用戶名創(chuàng)建模塊219 確定地創(chuàng)建唯一的訪問(wèn)用戶名。例如，可以通過(guò)客戶端設(shè)備電話號(hào)碼 206和初始用戶名212來(lái)創(chuàng)建訪問(wèn)用戶名并且將其存儲(chǔ)于數(shù)據(jù)庫(kù)218 中。可替代地，訪問(wèn)用戶名可以與模塊214所創(chuàng)建的用戶名相同，只 要以下述方式來(lái)選擇該用戶名即確保對(duì)于服務(wù)器實(shí)體該用戶名可被 用于唯一地標(biāo)識(shí)客戶端。當(dāng)客戶端設(shè)備202希望檢索關(guān)聯(lián)于電話號(hào)碼的個(gè)人內(nèi)容 時(shí)，客戶端設(shè)備202使用具有所存儲(chǔ)的訪問(wèn)用戶名和口令的基本認(rèn)證 從HTTPS模塊234進(jìn)行HTTPS連接。HTTPS模塊216和234可以是 相同的模塊。而且，可以使用分類訪問(wèn)認(rèn)證，而不是基本認(rèn)證。服務(wù) 器204通過(guò)HTTPS模塊236接收認(rèn)證信息并在數(shù)據(jù)庫(kù)222中査詢?cè)L問(wèn)用戶名和口令(或口令的哈希值)。HTTPS模塊220和236可以是相 同的模塊。匹配的用戶名/口令對(duì)也與電話號(hào)碼(PDTN)相關(guān)聯(lián)并且該 PDTN被用來(lái)在數(shù)據(jù)庫(kù)238中査尋賬戶信息。然后賬戶特定的信息被返 回到客戶端設(shè)備202?？蛻舳嗽O(shè)備202經(jīng)由HTTPS模塊234接收該賬 戶特定的信息240。上述參照?qǐng)Dl和2描述的方法假設(shè)運(yùn)營(yíng)商是可信任的。這 意味著，例如，運(yùn)營(yíng)商將遞送SMS消息到規(guī)定的接收者。即使該運(yùn)營(yíng) 商向其他人遞送SMS或?qū)⑵浔Ａ艚o自身(即，該運(yùn)營(yíng)商已經(jīng)不安全)， 只要用戶名是安全的(該用戶名經(jīng)由客戶端和服務(wù)器之間確保的端到 端的分離傳輸108被發(fā)送)就沒(méi)有安全性問(wèn)題。如果用戶名是安全的 (即，保持私密并且包含足夠的平均信息量)，那么SMS消息的接收 者將僅具有該賬戶的口令并且不能獲得訪問(wèn)。另外，假設(shè)運(yùn)營(yíng)商是足 夠值得信任的并且將不設(shè)置"活動(dòng)的"中間人攻擊。也就是說(shuō)，敵對(duì)的運(yùn) 營(yíng)商可以生成具有其所選擇的用戶名的原始HTTPS。當(dāng)從運(yùn)營(yíng)商接收 到該HTTPS時(shí)，商家將利用該運(yùn)營(yíng)商選擇的用戶名來(lái)激活賬戶并且發(fā) 送回具有隨機(jī)數(shù)和口令的SMS消息。運(yùn)營(yíng)商將截取該返回SMS消息， 并且然后獲得用于受害者賬戶的口令和用戶名。該方法不僅僅依賴于呼叫者ID或SMS資源電話號(hào)碼是可 信的。該方法對(duì)依靠電話手機(jī)的電話號(hào)碼的基于賬戶的信息特 別有用。該信息可以包括諸如賬戶結(jié)余、優(yōu)選的消費(fèi)者信息、未結(jié)算 訂購(gòu)等的項(xiàng)。由于由商家服務(wù)器自動(dòng)創(chuàng)建的強(qiáng)大的安全口令(例如，非 字典表述)，因此安全性被加強(qiáng)。該口令在不需要用戶的干預(yù)的情況 下被創(chuàng)建，由此阻止了用戶不注意地泄漏口令并且不需要用戶去創(chuàng)建 或保持口令，從而簡(jiǎn)化了用戶的經(jīng)歷。
眾所周知，SMS消息可能被欺騙(即，接收者不能確定消 息起源)，但是在上面的方法中阻止了欺騙的消息攻擊。例如，敵手 可以發(fā)送其電話號(hào)碼到商家，其看起來(lái)好像源自潛在的受害者的電話。 然而，這導(dǎo)致商家以包含口令的SMS消息來(lái)響應(yīng)該受害者的電話而不 是敵手的電話。因?yàn)閿呈蛛y于截取和解密該響應(yīng)SMS消息，因此他不 能了解受害者的口令。另外，因?yàn)闆](méi)有請(qǐng)求并且沒(méi)有相關(guān)聯(lián)的隨機(jī)數(shù)， 因此敵手的電話將丟棄所接收到的消息。運(yùn)營(yíng)商對(duì)SMS消息進(jìn)行加密，因此能夠確保返回的口令 和隨機(jī)數(shù)的安全防止竊聽(tīng)。手機(jī)生成的隨機(jī)數(shù)允許自動(dòng)保護(hù)以防止"網(wǎng)絡(luò)釣魚(yú)"攻擊， 因?yàn)槿绻邮盏降碾S機(jī)數(shù)與手機(jī)生成的隨機(jī)數(shù)不匹配，則可以自動(dòng) 丟棄所接收到的未請(qǐng)求的口令。 口令與客戶端設(shè)備相關(guān)聯(lián)而不是與用戶相關(guān)聯(lián)，因此可能 需要附加的用戶認(rèn)證用于某些應(yīng)用。用于用戶認(rèn)證的技術(shù)，諸如個(gè)人 標(biāo)識(shí)號(hào)碼或生物測(cè)定技術(shù)，是本領(lǐng)域技術(shù)人員所熟知的并被應(yīng)用于保 護(hù)其他信息，諸如敏感文檔、圖片和地址等。在另一實(shí)施例中，從商家到手機(jī)的額外口令的帶外遞送用 于滿足可能需要端到端的安全性的應(yīng)用。這避免必須信任運(yùn)營(yíng)商。雖 然該方法可能較昂貴，但其提供了提高的安全性。在一些實(shí)施例中，使用HTTP REST(資源狀態(tài)傳輸)協(xié)議來(lái) 管理口令。例如，注冊(cè)URL上的HTTP POST動(dòng)詞(verb)可被用于創(chuàng) 建初始口令。主體(或URL査詢串)包含手機(jī)電話號(hào)碼、隨機(jī)數(shù)和用 戶名?？梢允褂米?cè)URL上的具有基本認(rèn)證中的用戶名/口令證書(shū)的 HTTP DELETE動(dòng)詞來(lái)刪除口令。可以使用注冊(cè)URL上的具有基本認(rèn)證中的用戶名/口令證書(shū)的HTTP UPDATE動(dòng)詞來(lái)請(qǐng)求新的口令?？梢?使用注冊(cè)URL上的具有基本認(rèn)證中的用戶名/口令證書(shū)的HTTP GET 動(dòng)詞來(lái)請(qǐng)求當(dāng)前的口令。注意到在客戶端設(shè)備丟失或者被盜的事件中，本發(fā)明具有 與該設(shè)備上的任何其他應(yīng)用相同的安全性級(jí)別。該問(wèn)題的一個(gè)簡(jiǎn)單的 解決方案是在客戶端設(shè)備上使用鎖，使得除非首先輸入個(gè)人標(biāo)識(shí)號(hào)碼 (PIN)或者其他安全輸入(指紋等)來(lái)對(duì)其進(jìn)行解鎖，否則客戶端設(shè) 備將不能被使用。在HTTP認(rèn)證中使用的用戶名(被稱為"訪問(wèn)用戶名")應(yīng) 當(dāng)在所有手機(jī)之中是唯一的。因?yàn)槭謾C(jī)電話號(hào)碼是唯一的，但對(duì)公眾 可見(jiàn)，并且初始用戶名是不可見(jiàn)的但可能不唯一，因此創(chuàng)建作為初始 用戶名(圖2中的212)以及手機(jī)電話號(hào)碼(206)的函數(shù)的訪問(wèn)用戶 名提供了即唯一又不可見(jiàn)的訪問(wèn)用戶名。用于創(chuàng)建訪問(wèn)用戶名的簡(jiǎn)單 方法是將所述電話號(hào)碼連結(jié)到用戶名的末端。在本發(fā)明的一個(gè)實(shí)施例 中，服務(wù)器將電話號(hào)碼(240)附加到在注冊(cè)請(qǐng)求中提交的初始用戶名 (242)上以創(chuàng)建訪問(wèn)用戶名(226)。該操作被手機(jī)所熟知，使得當(dāng)手 機(jī)接收到口令時(shí)，該手機(jī)將其自身的電話號(hào)碼(206)連結(jié)到初始用戶 名(212)以創(chuàng)建訪問(wèn)用戶名/口令對(duì)(219)。例如，手機(jī)可以創(chuàng)建具 有電話號(hào)碼15558881212的用戶名"Tom"并將其發(fā)送到商家以請(qǐng)求口 令。商家創(chuàng)建口令并且將其發(fā)送回手機(jī)。商家將所生成的口令與用戶 名Tom 15558881212相關(guān)聯(lián)。當(dāng)手機(jī)接收到口令時(shí)，該手機(jī)創(chuàng)建用戶 名Tom 15558881212并且將其與口令一起保存。然后將表述Tom 15558881212用作為用于HTTP基本認(rèn)證的用戶名。可以用其他方式將 用戶名和電話號(hào)碼相結(jié)合以創(chuàng)建唯一的訪問(wèn)用戶名。本領(lǐng)域技術(shù)人員 可以使用哈希(hashing)功能等來(lái)創(chuàng)建更復(fù)雜的訪問(wèn)用戶名，只要手 機(jī)219和服務(wù)器254就該方法達(dá)成一致以通過(guò)初始用戶名和手機(jī)號(hào)碼 來(lái)創(chuàng)建訪問(wèn)用戶名即可。另一個(gè)要求是以下述方式來(lái)選擇訪問(wèn)用戶名 即它可以被用來(lái)相對(duì)于服務(wù)器實(shí)體唯一地標(biāo)識(shí)客戶端。對(duì)于每一個(gè)服務(wù)器實(shí)體可以使用不同的用戶名，或者跨所有服務(wù)器實(shí)體可以使用相 同的用戶名。在手機(jī)(214)上創(chuàng)建初始用戶名。可以自動(dòng)生成該用戶 名并且不需要暴露給用戶。可以使用符號(hào)的任何隨意集合。圖3示出了用于使用相互認(rèn)證的口令分發(fā)的示例性方法的 流程圖。參考圖3，在開(kāi)始?jí)K302之后，在塊304客戶端創(chuàng)建隨機(jī)數(shù)(隨 機(jī)符號(hào))和初始用戶名(或訪問(wèn)已經(jīng)被創(chuàng)建的初始用戶名)。在塊306， 客戶端使用安全傳輸過(guò)程，諸如HTTPS，將隨機(jī)數(shù)連同客戶端的電話 號(hào)碼(或其他網(wǎng)絡(luò)地址)和初始用戶名一起發(fā)送到商家服務(wù)器。如果 系統(tǒng)愿意容忍安全強(qiáng)度的降低(即，信息可以被截取和讀取以及客戶 端不對(duì)服務(wù)器進(jìn)行認(rèn)證)，則可以使用非安全傳輸過(guò)程(例如，HTTP)。 在塊308中，商家服務(wù)器創(chuàng)建注冊(cè)口令。在塊310,服務(wù)器使用第一消 息中所指定的電話號(hào)碼將口令和隨機(jī)數(shù)發(fā)送回客戶端。例如，可以使 用短消息服務(wù)(SMS)來(lái)發(fā)送隨機(jī)數(shù)和口令。當(dāng)客戶端接收到口令和 隨機(jī)數(shù)時(shí)，其在決策塊312中確定該隨機(jī)數(shù)是否是在304中創(chuàng)建的相 同隨機(jī)數(shù)。如果隨機(jī)數(shù)匹配，那么如在決策塊312的肯定分支所描述 的，在塊314中將口令與用于該特定商家的訪問(wèn)用戶名一起保存在手 機(jī)上。該訪問(wèn)用戶名被創(chuàng)建為塊304中所創(chuàng)建的初始用戶名和電話號(hào) 碼的函數(shù)。這就完成了"注冊(cè)"過(guò)程。如果隨機(jī)數(shù)不匹配，或者如果沒(méi)有 進(jìn)行口令請(qǐng)求，那么如決策塊312的否定分支所描述的，在塊322中 丟棄該口令并且終止該過(guò)程。在注冊(cè)過(guò)程中僅需要一個(gè)SMS消息。為 了訪問(wèn)與該手機(jī)的電話號(hào)碼相關(guān)聯(lián)的內(nèi)容，在塊316中客戶端使用在 注冊(cè)過(guò)程中所獲得的訪問(wèn)用戶名和口令來(lái)建立到商家的HTTPS連接。 在塊318，客戶端使用HTTPS從服務(wù)器請(qǐng)求內(nèi)容，并且在塊320，客 戶端再次使用HTTPS接收與其電話號(hào)碼相關(guān)聯(lián)的內(nèi)容。如果安全強(qiáng)度 的降低是可接受的，則可以使用利用HTTP的非安全連接。對(duì)于規(guī)則 的內(nèi)容訪問(wèn)不需要SMS (318， 320)。該過(guò)程在塊322終止。
16
本發(fā)明的具體實(shí)施例已經(jīng)在前述的說(shuō)明書(shū)中被描述。然 而，本領(lǐng)域技術(shù)人員將認(rèn)識(shí)到在不脫離所附權(quán)利要求所闡述的本發(fā)明 的范圍的前提下，可以作出各種修改和改變。因此，說(shuō)明書(shū)和附圖只 被認(rèn)為是說(shuō)明性的而不是限定性的，并且所有這樣的修改都將被包括 在本發(fā)明的范圍之內(nèi)。益處、優(yōu)點(diǎn)、問(wèn)題的解決方案以及可以引起任 何益處、優(yōu)點(diǎn)或解決方案發(fā)生或變得更明顯的任何元素(多個(gè))都不 被解釋為任何或全部權(quán)利要求的關(guān)鍵的、要求的或本質(zhì)的特征或元素。 本發(fā)明僅被所附權(quán)利要求限定，包括在本申請(qǐng)未決期間所作出的任何 修改和所公布的權(quán)利要求的所有等效內(nèi)容。
權(quán)利要求
1.一種用于網(wǎng)絡(luò)中的口令分發(fā)的方法，所述網(wǎng)絡(luò)包括客戶端和服務(wù)器，所述方法包括所述客戶端創(chuàng)建第一隨機(jī)數(shù)；所述客戶端向所述服務(wù)器發(fā)送所述第一隨機(jī)數(shù)、初始用戶名和所述客戶端的網(wǎng)絡(luò)地址；所述客戶端從所述服務(wù)器接收第二隨機(jī)數(shù)和口令；以及如果所述第一隨機(jī)數(shù)與所述第二隨機(jī)數(shù)相同，則所述客戶端將所述口令與訪問(wèn)用戶名相關(guān)聯(lián)。
2. 根據(jù)權(quán)利要求1所述的方法，其中所述訪問(wèn)用戶名依賴于所述 初始用戶名。
3. 根據(jù)權(quán)利要求l所述的方法，進(jìn)一步包括 所述客戶端創(chuàng)建所述初始用戶名；以及 所述客戶端創(chuàng)建所述訪問(wèn)用戶名。
4. 根據(jù)權(quán)利要求1所述的方法，其中所述客戶端使用安全傳輸向 所述服務(wù)器發(fā)送所述第一隨機(jī)數(shù)、所述初始用戶名和所述網(wǎng)絡(luò)地址。
5. 根據(jù)權(quán)利要求1所述的方法，進(jìn)一步包括 所述服務(wù)器接收所述第一隨機(jī)數(shù)、所述初始用戶名和所述網(wǎng)絡(luò)地址；所述服務(wù)器創(chuàng)建所述口令；以及所述服務(wù)器向處于指定網(wǎng)絡(luò)地址的客戶端發(fā)送所述第二隨機(jī)數(shù)和 所述口令，其中所述第二隨機(jī)數(shù)等于所接收到的第一隨機(jī)數(shù)。
6. —種便攜式設(shè)備，包括隨機(jī)數(shù)創(chuàng)建模塊，在操作中用于創(chuàng)建第一隨機(jī)數(shù)； 傳輸模塊，在操作中用于向網(wǎng)絡(luò)服務(wù)器發(fā)送發(fā)送所述第一隨機(jī)數(shù)、 初始用戶名和所述便攜式設(shè)備的網(wǎng)絡(luò)地址；消息模塊，在操作中用于從所述網(wǎng)絡(luò)服務(wù)器接收第二隨機(jī)數(shù)和口令；隨機(jī)數(shù)驗(yàn)證模塊，在操作中用于比較所述第一隨機(jī)數(shù)和所述第二 隨機(jī)數(shù)；訪問(wèn)用戶名創(chuàng)建模塊，在操作中用于依賴于所述網(wǎng)絡(luò)地址和所述 初始用戶名創(chuàng)建訪問(wèn)用戶名；存儲(chǔ)器，在操作中用于，如果所述第一隨機(jī)數(shù)和所述第二隨機(jī)數(shù) 相同，則存儲(chǔ)所述訪問(wèn)用戶名和所述口令。
7. 根據(jù)權(quán)利要求6所述的便攜式設(shè)備，進(jìn)一步包括初始用戶名創(chuàng) 建模塊，所述初始用戶名創(chuàng)建模塊在操作中用于創(chuàng)建所述初始用戶名。
8. 根據(jù)權(quán)利要求6所述的便攜式設(shè)備，其中所述便攜式設(shè)備包括 電話手機(jī)，以及所述網(wǎng)絡(luò)地址包括所述電話手機(jī)的電話號(hào)碼。
9. 根據(jù)權(quán)利要求6所述的便攜式設(shè)備，其中所述消息模塊包括短 消息服務(wù)(SMS)模塊。
10. 根據(jù)權(quán)利要求6所述的便攜式設(shè)備，其中所述傳輸模塊包括 超文本傳輸協(xié)議(HTTP)模塊。
全文摘要
客戶端在(106)創(chuàng)建隨機(jī)數(shù)，并且在(108)使用諸如HTTPS的安全傳輸過(guò)程將隨機(jī)數(shù)連同其電話號(hào)碼和用戶名一起發(fā)送到商家服務(wù)器。在(110)，商家將處理在(108)接收到的消息。而且，在(110)，商家創(chuàng)建口令，并且在(112)使用第一消息中所指定的電話號(hào)碼將口令和隨機(jī)數(shù)發(fā)送回客戶端設(shè)備?？梢允褂枚滔⒎?wù)(SMS)來(lái)發(fā)送隨機(jī)數(shù)和口令。當(dāng)手機(jī)接收到口令和隨機(jī)數(shù)時(shí)，其在(114)驗(yàn)證該隨機(jī)數(shù)是在(106)創(chuàng)建的隨機(jī)數(shù)。如果第一隨機(jī)數(shù)與第二隨機(jī)數(shù)匹配，則將口令與用于該特定商家的“訪問(wèn)”用戶名一起保存在手機(jī)上。
文檔編號(hào)H04L9/32GK101589569SQ200780045705
公開(kāi)日2009年11月25日 申請(qǐng)日期2007年9月27日 優(yōu)先權(quán)日2006年12月11日
發(fā)明者布雷特·L·林斯利, 托馬斯·S·梅瑟吉斯 申請(qǐng)人:摩托羅拉公司