專利名稱：正規(guī)內(nèi)容確認系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及在經(jīng)由網(wǎng)絡(luò)傳送內(nèi)容時與信源(發(fā)送機)和信宿(接收機)之間收發(fā)正當內(nèi)容用的數(shù)據(jù)傳送安全技術(shù)有關(guān)的正規(guī)內(nèi)容確認方法、內(nèi)容收發(fā)系統(tǒng)、發(fā)送機及接收機等。
背景技術(shù)：
近年來，與因特網(wǎng)的連接環(huán)境完善起來，另外家電產(chǎn)品也同樣，容易開展與網(wǎng)絡(luò)相對應(yīng)的環(huán)境(進行網(wǎng)絡(luò)化用的器件的低成本化及高性能化等)完善起來。另外同時，保護傳送的內(nèi)容使之不被非法復制、非法旁聽或非法竄改用的著作權(quán)保護技術(shù)受到重視起來。作為經(jīng)IEEE1394串行總線傳送的AV內(nèi)容的著作權(quán)保護技術(shù)，開發(fā)了Digital Transmission Content Protection(DTCP數(shù)字傳輸內(nèi)容保護)，作為擴展，在因特網(wǎng)協(xié)議(IP)上也進行了技術(shù)展開(參照DTCP Volume 1 Supplement E Mapping DTCP to IP(InformationalVersion)Revision 1.0 November 24，2003)。
圖8及圖9是根據(jù)使用HTTP協(xié)議(在服務(wù)器與客戶機之間確定了連接之后，對于來自客戶機的請求，以服務(wù)器返回響應(yīng)的形式，來進行數(shù)據(jù)交換)的DTCP-IP的、以往的傳送系統(tǒng)中的發(fā)送機及接收機的功能方框圖的一個例子。
圖8的發(fā)送機800具有證明書及密鑰保持部801、交換密鑰生成部802、認證及密鑰交換部803、更新信息生成及更新部804、復制控制信息管理部805、內(nèi)容密鑰計算部806、內(nèi)容存儲部807、內(nèi)容加密部808、內(nèi)容包生成部809，內(nèi)容包發(fā)送部810、以及HTTP協(xié)議部811。
證明書及密鑰保持部801保持著公開密鑰密碼的密鑰對(公開密鑰、秘密密鑰)及證明書。
交換密鑰生成部802生成為了計算將內(nèi)容加密用的內(nèi)容密鑰(Kc)而使用的交換密鑰(Kx)。
認證及密鑰交換部803接受來自接收機的認證請求，通過認證，確認該接收機是否是正當?shù)脑O(shè)備。這里，作為認證采用的方法是，使用發(fā)送機及接收機分別保持的公開密鑰密碼的密鑰對(公開密鑰、秘密密鑰)及證明書，進行詢問響應(yīng)型的認證。在認證期間，在發(fā)送機與接收機之間公有認證密鑰(Kauth)，認證后，使用公有的認證密鑰(Kauth)，將交換密鑰生成部802中生成的交換密鑰(Kx)傳給接收機。用認證及密鑰交換部803進行這一連串的、從認證到密鑰取得的過程。
更新信息生成及更新部804新生成更新信息(Nc)或?qū)⒏滦畔?Nc)進行更新。這里，例如所謂生成，是利用隨機數(shù)產(chǎn)生等，進行新的更新信息(Nc)的生成，所謂更新，是對現(xiàn)在的值加1。通過確立TCP連接，生成更新信息(Nc)。根據(jù)規(guī)定的規(guī)則，來進行更新。作為規(guī)定的規(guī)則，可以舉出有在同一TCP連接上的每次HTTP請求和響應(yīng)進行更新等。由于不是本發(fā)明的著重點，因此這里省略說明。這里，生成及更新的更新信息(Nc)是為了維持內(nèi)容保護而以規(guī)定的規(guī)則計算內(nèi)容密鑰(Kc)使用的。再有，更新信息(Nc)附加在用內(nèi)容密鑰(Kc)加密的內(nèi)容中傳給接收機。
復制控制信息管理部805將各內(nèi)容的管理內(nèi)容(例如，禁止復制、可復制一代等)的、與內(nèi)容相適應(yīng)的加密方式作為復制控制信息(E_EMI)進行管理。復制控制信息(E_EMI)用以計算內(nèi)容密鑰(Kc)，附加在用計算出的內(nèi)容密鑰(Kc)加密的內(nèi)容中傳給接收機。
內(nèi)容密鑰計算部806根據(jù)用交換密鑰生成部802生成的交換密鑰(Kx)、用更新信息生成及更新部804生成及更新的更新信息(Nc)、以及用復制控制信息管理部805管理的復制控制信息(E_EMI)等，使用單向性函數(shù)，計算內(nèi)容密鑰(Kc)。
內(nèi)容存儲部807存儲成為傳送對象的各種內(nèi)容。
內(nèi)容加密部808將傳送的內(nèi)容使用在內(nèi)容密鑰計算部806中計算的內(nèi)容密鑰(Kc)進行加密。
內(nèi)容包生成部809對用內(nèi)容加密部808進行加密的內(nèi)容附加用更新信息生成及更新部804生成及更新的更新信息(Nc)、以及用復制控制信息管理部805管理的復制控制信息(E_EMI)，從而生成內(nèi)容包。
內(nèi)容包發(fā)送部810發(fā)送用內(nèi)容包生成部809生成的內(nèi)容包。
HTTP協(xié)議部811進行HTTP服務(wù)器處理。接收并分析HTTP請求，生成HTTP響應(yīng)，進行應(yīng)答。這里，用內(nèi)容包生成部809生成的內(nèi)容包作為來自發(fā)送機的對于HTTP GET請求的HTTP響應(yīng)的主體進行發(fā)送。
圖9的接收機900具有證明書及密鑰保持部901、認證及密鑰交換部902、更新信息存儲部903、復制控制信息存儲部904、內(nèi)容密鑰計算部905、內(nèi)容利用部906、內(nèi)容解密部907、內(nèi)容包分析部908，內(nèi)容包接收部909、以及HTTP協(xié)議部910。
證明書及密鑰保持部901保持著公開密鑰密碼的密鑰對(公開密鑰、秘密密鑰)及證明書。
認證及密鑰交換部902在規(guī)定的時刻進行認證請求，在認證期間，在發(fā)送機與接收機之間公有認證密鑰(Kauth)，認證后，從發(fā)送機接受用公有的認證密鑰(Kauth)加密的交換密鑰(Kx)，進行解密。
更新信息存儲部903存儲從發(fā)送機接收的被加密的內(nèi)容中附加的更新信息(Nc)。
復制控制信息存儲部904存儲被加密的內(nèi)容中附加的復制控制信息(E_EMI)。
內(nèi)容密鑰計算部905根據(jù)用認證及密鑰交換部902從發(fā)送機傳來的交換密鑰(Kx)、用更新信息存儲部903存儲的更新信息(Nc)、以及用復制控制信息存儲部904存儲的復制控制信息(E_EMI)等，使用單向性函數(shù)，計算內(nèi)容密鑰(Kc)。
內(nèi)容利用部906根據(jù)用復制控制信息存儲部904存儲的復制控制信息(E_EMI)，將解密的內(nèi)容進行重放及記錄等，進行利用。
內(nèi)容解密部907使用由內(nèi)容密鑰計算部905計算出的內(nèi)容密鑰(Kc)，將被加密的內(nèi)容進行解密。
內(nèi)容包分析部908將被加密的內(nèi)容中附加的更新信息(Nc)與復制控制信息(E_EMI)分離，分別傳給更新信息存儲部903及復制控制信息存儲部904。
內(nèi)容包接收部909接收內(nèi)容包。
HTTP協(xié)議部910進行HTTP客戶機處理。生成及發(fā)送HTTP請求，接收及分析HTTP響應(yīng)。
圖10所示為具有圖8所示的發(fā)送機800及圖9所示的接收機900的、以往的傳送系統(tǒng)中的密碼通信協(xié)議順序。
以下，用圖10說明以往的密碼通信協(xié)議順序。
(1001)通過發(fā)送機800與接收機900之間的認證過程，公有認證密鑰(Kauth)。該認證密鑰(Kauth)每一次認證使用過后就扔掉。
(1002)發(fā)送機800生成交換密鑰(Kx)。
(1003)發(fā)送機800用認證密鑰(Kauth)將交換密鑰(Kx)進行加密(Ksx)，送往接收機900。
(1004)接收機900用認證密鑰(Kauth)將接受的Ksx進行解密，得到交換密鑰(Kx)。
(1005)從接收機900向發(fā)送機800發(fā)送根據(jù)HTTP GET請求的內(nèi)容請求。
(1006)發(fā)送機800生成更新信息(Nc)。
(1007)發(fā)送機800識別從接收機900請求的內(nèi)容的復制控制信息(E_EMI)。
(1008)發(fā)送機800將交換密鑰(Kx)、更新信息(Nc)及復制控制信息(E_EMI)作為輸入?yún)?shù)，使用單向性函數(shù)，計算內(nèi)容密鑰(Kc)。
(1009)發(fā)送機800利用內(nèi)容密鑰(Kc)將接收機900請求的內(nèi)容進行加密。
(1010)發(fā)送機800對于作為HTTP GET響應(yīng)的主體、加密的內(nèi)容附加更新信息(Nc)及復制控制信息(E_EMI)，向接收機發(fā)送。
(1011)接收機900從接收的響應(yīng)獲得更新信息(Nc)。
(1012)接收機900同樣從接收的響應(yīng)獲得復制控制信息(E_EMI)。
(1013)接收機900將交換密鑰(Kx)、更新信息(Nc)及復制控制信息(E_EMI)作為輸入?yún)?shù)，使用單向性函數(shù)，計算內(nèi)容密鑰(Kc)。
(1014)接收機900使用內(nèi)容密鑰(Kc)，將被加密的內(nèi)容進行解密。
根據(jù)上述一連串的協(xié)議順序，在發(fā)送機800與接收機900之間，公有公共的交換密鑰(Kx)(1080、1090)、以及內(nèi)容中附加的更新信息(Nc)(1081、1091)和復制控制信息(E_EMI)(1082、1092)，僅僅在正當?shù)慕邮諜C中使用這些參數(shù)，能夠正確地將被加密的內(nèi)容進行解密。
但是，在以往的系統(tǒng)中，雖確立了在公有交換密鑰的當事者之間利用密碼通信進行的內(nèi)容保護的結(jié)構(gòu)，但是在連接不確定多個設(shè)備的IP網(wǎng)絡(luò)特性上，有可能發(fā)生「是誰送來的」這樣的認證問題。
即，即使在接收機請求并接收了內(nèi)容，但由于沒有確認是來自正確的請求對象的正當發(fā)送機的正當內(nèi)容的方法，因此例如攻擊者監(jiān)視IP網(wǎng)絡(luò)，記錄(高速緩沖存儲器保存)傳送的加密內(nèi)容，然后對接收機的請求，冒充正當?shù)陌l(fā)送機，用該記錄的內(nèi)容進行應(yīng)答，也不能判別。
圖11所示為說明以往的傳送系統(tǒng)的網(wǎng)絡(luò)結(jié)構(gòu)中的問題的說明圖。以下，用圖11說明成為問題的一個事例。
發(fā)送機800及接收機900分別是公有交換密鑰的正當?shù)拿艽a通信對象設(shè)備。在發(fā)送機800與接收機900之間，根據(jù)接收機900的內(nèi)容請求(1111)，傳送帶有附加信息的加密內(nèi)容(1112)。
這里，連接在網(wǎng)絡(luò)上的非法設(shè)備1100監(jiān)視在總線上傳送的HTTP請求及響應(yīng)，能夠?qū)⑺鼈冞M行記錄(1113)。非法設(shè)備1100本身雖不能將內(nèi)容解密、用于視聽等，但例如在此之后，能夠鉤取從接收機900對發(fā)送機800的HTTP請求(1114)，冒充正當?shù)陌l(fā)送機800，將以前記錄的內(nèi)容頂替本來接收機900應(yīng)該接受的內(nèi)容，進行發(fā)送(1115)。這時，接收機900由于不能判別該頂替發(fā)送來的內(nèi)容是從正當?shù)陌l(fā)送機800發(fā)送來的正規(guī)內(nèi)容，還是從非法設(shè)備1100發(fā)送來的內(nèi)容，因此使用戶會利用該頂替發(fā)送來的內(nèi)容。
本發(fā)明是為了解決上述以往的問題，其目的在于提供能夠判別接收的內(nèi)容是否是正規(guī)內(nèi)容的正規(guī)內(nèi)容確認方法、內(nèi)容收發(fā)系統(tǒng)，發(fā)送機及接收機等。

發(fā)明內(nèi)容
為了解決上述問題，本發(fā)明的第1發(fā)明的正規(guī)內(nèi)容確認方法，是內(nèi)容收發(fā)系統(tǒng)中的正規(guī)內(nèi)容確認方法，該內(nèi)容收發(fā)系統(tǒng)根據(jù)來自接收機的內(nèi)容請求，與網(wǎng)絡(luò)連接的發(fā)送機將在規(guī)定時刻更新的更新信息、即生成內(nèi)容加密及解密用的內(nèi)容密鑰所必需的前述更新信息附加在被加密的內(nèi)容中，進行發(fā)送，其中包括以下步驟用前述接收機發(fā)送至少包含從前述發(fā)送機接收的前述更新信息的正規(guī)確認請求的確認請求步驟；用前述發(fā)送機核對從前述接收機接收的前述正規(guī)確認請求中包含的前述更新信息是否是規(guī)定的更新信息的更新信息核對步驟；在用前述發(fā)送機判定為前述更新信息是前述規(guī)定的更新信息時，使用前述更新信息及所述發(fā)送機和前述接收機的雙方預先公有的交換密鑰，生成知道消息并向前述接收機發(fā)送的知道消息發(fā)送步驟；以及在用前述接收機接收了來自前述發(fā)送機的前述知道消息時，判斷為接收中的內(nèi)容是正規(guī)內(nèi)容的正規(guī)內(nèi)容判定步驟。
另外，本發(fā)明的第2發(fā)明是在本發(fā)明的第1發(fā)明的正規(guī)內(nèi)容確認方法中，前述規(guī)定的更新信息是現(xiàn)在使用中的更新信息或規(guī)定次數(shù)更新前的更新信息。
另外，本發(fā)明的第3發(fā)明是在本發(fā)明的第1發(fā)明的正規(guī)內(nèi)容確認方法中，在前述確認請求步驟中，前述接收機每發(fā)送一次前述正規(guī)確認請求，將不同的數(shù)也包含在前述正規(guī)確認請求中進行發(fā)送，在前述知道消息發(fā)送步驟中，前述發(fā)送機還使用前述正規(guī)確認請求中包含的前述數(shù)，生成前述知道消息。
另外，本發(fā)明的第4發(fā)明是在本發(fā)明的第1發(fā)明的正規(guī)內(nèi)容確認方法中，在前述確認請求步驟中，前述接收機使用前述交換密鑰及從前述發(fā)送機發(fā)送來的前述更新信息生成的識別消息也包含在前述正規(guī)確認請求中進行發(fā)送，在前述知道消息發(fā)送步驟中，前述發(fā)送機在判定為前述更新信息是前述規(guī)定的更新信息、而且確認前述正規(guī)確認請求中包含的前述識別消息與前述發(fā)送機本身使用前述交換密鑰及前述更新信息生成的識別消息一致時，將前述知道消息向前述接收機發(fā)送。
另外，本發(fā)明的第5發(fā)明是在本發(fā)明的第1發(fā)明的正規(guī)內(nèi)容確認方法中，在前述知道消息發(fā)送步驟中，前述發(fā)送機在判定為前述更新信息不是前述規(guī)定的更新信息時，將非知道消息向前述接收機發(fā)送，在前述正規(guī)內(nèi)容判定步驟中，在用前述接收機接收了來自前述發(fā)送機的前述非知道消息時，判斷為接收中的內(nèi)容不是正規(guī)內(nèi)容，不利用前述內(nèi)容。
另外，本發(fā)明的第6發(fā)明是在本發(fā)明的第1發(fā)明的正規(guī)內(nèi)容確認方法中，在前述正規(guī)內(nèi)容判定步驟中，在前述接收機不能接收前述知道消息時，還具有用前述接收機在規(guī)定期間重復發(fā)送前述正規(guī)確認請求的確認請求重新發(fā)送步驟，在前述正規(guī)內(nèi)容判定步驟中，在用前述接收機即使超過前述規(guī)定期間也不能接收前述知道消息時，就不利用接收的內(nèi)容。
另外，本發(fā)明的第7發(fā)明是在本發(fā)明的第1發(fā)明的正規(guī)內(nèi)容確認方法中，在前述正規(guī)內(nèi)容判定步驟中，在前述接收機不能接收前述知道消息時，還具有用前述接收機重復規(guī)定次數(shù)發(fā)送前述正規(guī)確認請求的確認請求重新發(fā)送步驟，在前述正規(guī)內(nèi)容判定步驟中，在用前述接收機即使發(fā)送前述規(guī)定次數(shù)的前述正規(guī)確認請求也不能接收前述知道消息時，就不利用接收的內(nèi)容。
另外，本發(fā)明的第8發(fā)明是在本發(fā)明的第5至第7發(fā)明的正規(guī)內(nèi)容確認方法中，在前述正規(guī)內(nèi)容判定步驟中，在用前述接收機不利用接收的前述內(nèi)容之后，直到規(guī)定的限制次數(shù)或規(guī)定的限制期間或規(guī)定的停止條件具備之前，還具有重復發(fā)送前述正規(guī)確認請求的確認請求再發(fā)送步驟，在前述正規(guī)內(nèi)容判定步驟中，在用前述接收機不利用接收的前述內(nèi)容之后，在接收了前述知道消息時，就利用接收的內(nèi)容。
另外，本發(fā)明的第9發(fā)明的內(nèi)容收發(fā)系統(tǒng)，具有發(fā)送內(nèi)容請求的接收機、以及發(fā)送機，前述發(fā)送機利用網(wǎng)絡(luò)與前述接收機連接，根據(jù)來自接收機的內(nèi)容請求，將在規(guī)定時刻更新的更新信息、即生成內(nèi)容加密及解密用的內(nèi)容密鑰所必需的前述更新信息附加在被加密的內(nèi)容中，進行發(fā)送，其中，前述接收機具有發(fā)送使用與前述發(fā)送機的雙方預先公有的交換密鑰、和從前述發(fā)送機接收的前述更新信息生成的正規(guī)確認請求的確認請求單元；以及在接收了來自前述發(fā)送機的知道消息時，判斷為接收中的內(nèi)容是正規(guī)內(nèi)容的確認結(jié)果核對單元，前述發(fā)送機具有接收從前述接收機發(fā)送來的前述正規(guī)確認請求的確認請求接受單元；核對接收的前述正規(guī)確認請求中包含的前述更新信息是否是規(guī)定的更新信息的更新信息確認單元；以及在判定為前述更新信息是前述規(guī)定的更新信息時，使用前述更新信息和與前述接收機的雙方公有的前述交換密鑰生成前述知道消息，并向前述接收機發(fā)送的確認應(yīng)答單元。
另外，本發(fā)明的第10發(fā)明的發(fā)送機，是內(nèi)容收發(fā)系統(tǒng)中使用的發(fā)送機，該內(nèi)容收發(fā)系統(tǒng)根據(jù)來自接收機的內(nèi)容請求，與網(wǎng)絡(luò)連接的發(fā)送機將在規(guī)定時刻更新的更新信息、即生成內(nèi)容加密及解密用的內(nèi)容密鑰所必需的前述更新信息附加在被加密的內(nèi)容中，進行發(fā)送，其中具有接收所述接收機中使用與前述接收機的雙方預先公有的交換密鑰、和從前述發(fā)送機接收的前述更新信息生成的、并從前述接收機發(fā)送來的正規(guī)確認請求的確認請求接受單元；核對從前述接收機接收的前述正規(guī)確認請求中包含的前述更新信息是否是規(guī)定的更新信息的更新信息確認單元；以及在判定為前述更新信息是前述規(guī)定的更新信息時，使用前述更新信息和前述交換密鑰，生成判斷前述接收機接收中的內(nèi)容是否是正規(guī)內(nèi)容用的知道消息，并向前述接收機發(fā)送的確認應(yīng)答單元。
另外，本發(fā)明的第11發(fā)明的接收機，是內(nèi)容收發(fā)系統(tǒng)中使用的接收機，該內(nèi)容收發(fā)系統(tǒng)根據(jù)來自接收機的內(nèi)容請求，與網(wǎng)絡(luò)連接的發(fā)送機將在規(guī)定時刻更新的更新信息、即生成內(nèi)容加密及解密用的內(nèi)容密鑰所必需的前述更新信息附加在被加密的內(nèi)容中，進行發(fā)送，其中具有發(fā)送使用與前述發(fā)送機的雙方預先公有的交換密鑰、和從前述發(fā)送機接收的前述更新信息生成的正規(guī)確認請求的確認請求單元；以及在接收了前述發(fā)送機判定為接收的前述正規(guī)確認請求中包含的前述更新信息是規(guī)定的更新信息后，使用前述更新信息及前述交換密鑰生成并發(fā)送來的知道消息時，判斷為接收中的內(nèi)容是正規(guī)內(nèi)容的確認結(jié)果核對單元。
另外，本發(fā)明的第12發(fā)明的程序，是使計算機執(zhí)行本發(fā)明的第1發(fā)明的正規(guī)內(nèi)容確認方法的步驟用的程序，所述步驟包括用前述接收機發(fā)送前述正規(guī)確認請求的前述確認請求步驟；用前述發(fā)送機核對前述更新信息是否是前述規(guī)定的更新信息的前述更新信息核對步驟；用前述發(fā)送機生成前述知道消息并向前述接收機發(fā)送的前述知道消息發(fā)送步驟；以及在用前述接收機接收了來自前述發(fā)送機的前述知道消息時，確認前述發(fā)送機是正規(guī)的發(fā)送機的前述正規(guī)內(nèi)容判定步驟。
另外，本發(fā)明的第13發(fā)明是記錄媒體，是能夠利用計算機處理的記錄媒體，是記錄了本發(fā)明的第12發(fā)明的程序的記錄媒體。
根據(jù)本發(fā)明，能夠提供能夠判別接收的內(nèi)容是否是正規(guī)內(nèi)容的正規(guī)內(nèi)容確認方法、內(nèi)容收發(fā)系統(tǒng)、發(fā)送機及接收機等。


圖1所示為本發(fā)明實施形態(tài)1有關(guān)的內(nèi)容收發(fā)系統(tǒng)中使用的發(fā)送機的功能方框圖。
圖2所示為本發(fā)明實施形態(tài)1有關(guān)的內(nèi)容收發(fā)系統(tǒng)中使用的接收機的功能方框圖。
圖3所示為本發(fā)明實施形態(tài)1有關(guān)的內(nèi)容收發(fā)系統(tǒng)的處理順序圖。
圖4所示為本發(fā)明實施形態(tài)2有關(guān)的內(nèi)容收發(fā)系統(tǒng)中使用的接收機的功能方框圖。
圖5所示為本發(fā)明實施形態(tài)2有關(guān)的內(nèi)容收發(fā)系統(tǒng)的處理順序圖。
圖6所示為本發(fā)明實施形態(tài)3有關(guān)的內(nèi)容收發(fā)系統(tǒng)中使用的接收機的功能方框圖。
圖7所示為本發(fā)明實施形態(tài)3有關(guān)的內(nèi)容收發(fā)系統(tǒng)的處理順序圖。
圖8所示為以往的傳送系統(tǒng)中的發(fā)送機的功能方框圖。
圖9所示為以往的傳送系統(tǒng)中的接收機的功能方框圖。
圖10所示為以往的傳送系統(tǒng)中的密碼通信協(xié)議順序圖。
圖11為說明以往的傳送系統(tǒng)的網(wǎng)絡(luò)構(gòu)成中的問題的說明圖。
標號說明100發(fā)送機101確認請求接受部
102識別信息確認部103更新信息確認部104確認應(yīng)答部105更新信息生成及更新部200、400、600接收機201確認參數(shù)生成部202、601確認請求部203確認結(jié)果核對部204、402、602內(nèi)容包接收部205、403內(nèi)容利用部401重新判斷部801證明書及密鑰保持部802交換密鑰生成部803認證及密鑰交換部805復制控制信息管理部806內(nèi)容密鑰計算部807內(nèi)容存儲部808內(nèi)容加密部809內(nèi)容包生成部810內(nèi)容包發(fā)送部901證明書及密鑰保持部902認證及密鑰交換部903更新信息存儲部904復制控制信息存儲部905內(nèi)容密鑰計算部907內(nèi)容解碼部908內(nèi)容包分析部910HTTP協(xié)議部
具體實施例方式
以下，對于本發(fā)明的正規(guī)內(nèi)容確認方法，說明適應(yīng)于以往的傳送系統(tǒng)的情況。另外，在以下的各實施形態(tài)中，對于與上述的以往例同一或與之相當?shù)奶幚砑皹?gòu)成，使用同一標號，并省略其詳細說明。
(實施形態(tài)1)圖1為本發(fā)明實施形態(tài)1有關(guān)的內(nèi)容收發(fā)系統(tǒng)中使用的發(fā)送機的功能方框圖。
發(fā)送機100與圖8所示的以往的發(fā)送機800相同，具有證明書及密鑰保持部801、交換密鑰生成部802、認證及密鑰交換部803、復制控制信息管理部805、內(nèi)容密鑰計算部806、內(nèi)容存儲部807、內(nèi)容加密部808、內(nèi)容包生成部809，內(nèi)容包發(fā)送部810、以及HTTP協(xié)議部811。還具有確認請求接受部101、識別信息確認部102、更新信息確認部103、確認應(yīng)答部104、以及更新信息生成及更新部105。
另外，確認請求接受部101、更新信息確認部103、確認應(yīng)答部104分別相當于本發(fā)明的確認請求接受單元、更新信息確認單元、確認應(yīng)答單元的一個例子。
確認請求接受部101從接收機接收用更新信息(test_Nc)及任意數(shù)(N＝接收機每次確認請求指定的不同的數(shù))及識別信息構(gòu)成的確認請求。
識別信息確認部102確認接收的確認請求中包含的識別信息是否是表示是正確的接收機的信息。這里，識別信息是用同樣確認請求中包含的更新信息(Nc)及任意數(shù)(N)、以及與接收機之間公有的交換密鑰(Kx)計算出的信息，通過進行同樣的計算，能夠確認在發(fā)送機中是否是正確的識別信息。
這里，例如識別信息是將連接交換密鑰(Kx)的數(shù)輸入散列函數(shù)，將計算出的散列值與更新信息(Nc)與任意數(shù)(N)相加，再輸入散列函數(shù)，取所得到的值(160位(bit))的低80位。由于散列值取偽隨機數(shù)那樣的值，據(jù)此不能再現(xiàn)原文，因此非法設(shè)備不能根據(jù)該識別信息來解讀交換密鑰(Kx)。
另外，確認請求相當于本發(fā)明的正規(guī)確認請求的一個例子，識別信息相當于本發(fā)明的識別消息的一個例子。
更新信息生成及更新部105與以往的發(fā)送機800的更新信息生成及更新部804相同，新生成更新信息(Nc)或?qū)⒏滦畔?Nc)進行更新，同時保持更新前的更新信息(pre_Nc)。
更新信息確認部103確認接收的確認請求中包含的更新信息(test_Nc)與現(xiàn)在發(fā)送機100為了內(nèi)容發(fā)送而使用中的更新信息是否一致。這里，作為使用中的更新信息，是指用更新信息生成及更新部105管理的更新信息(Nc)或剛才之前的更新信息(pre_Nc)。另外，考慮到更新信息在短期間內(nèi)改變，也可以將這之前使用的多個更新信息作為剛才之前的更新信息保持。
這里，為了確認與更新信息(test_Nc)一致而使用的使用中的更新信息相當于本發(fā)明的規(guī)定的更新信息的一個例子。另外，在這之前使用的多個更新信息相當于本發(fā)明的規(guī)定次數(shù)更新前的更新信息的一個例子。
確認應(yīng)答部104在用識別信息確認部102及更新信息確認部103判定為是時，使用從接收機接受的更新信息(test_Nc)及任意數(shù)(N)、以及與接收機之間公有的交換密鑰(Kx)，生成知道消息，向該接收機發(fā)送。
這里，例如如下述那樣進行計算知道消息。將連接交換密鑰(Kx)的數(shù)輸入散列函數(shù)，計算散列值。將計算出的散列值與來自接收機的更新信息(test_Nc)與任意數(shù)(N)相加，再輸入散列函數(shù)，將所得到的值(160位)的高80位用作為知道消息。
另外，在用識別信息確認部102或更新信息確認部103判定為不是時，確認應(yīng)答部104生成非知道消息，向該接收機發(fā)送。
非知道消息作為其目的只要利用與知道消息不同的值即可。例如，也可以使用與知道消息同樣得到的值的低80位。另外，也可以使用改變與知道消息同樣計算散列值時所使用的任意數(shù)(N)(例如加1)而得到的值的高80位。
圖2所示為實施形態(tài)1有關(guān)的內(nèi)容收發(fā)系統(tǒng)中使用的接收機的功能方框圖。
接收機200與圖9所示的以往的接收機900相同，具有證明書及密鑰保持部901、認證及密鑰交換部902、更新信息存儲部903、復制控制信息存儲部904、內(nèi)容密鑰計算部905、內(nèi)容解密部907、內(nèi)容包分析部908，以及HTTP協(xié)議部910。還具有確認參數(shù)生成部201、確認請求部202、確認結(jié)果核對部203、內(nèi)容包接收部204、以及內(nèi)容利用部205。
另外，確認請求部202及確認結(jié)果核對部203分別相當于本發(fā)明的確認請求單元及確認結(jié)果核對單元的一個例子。
這里，確認參數(shù)生成部201每次確認請求都生成不同的數(shù)(N)。然后，使用更新信息(Nc)及生成的任意數(shù)(N)、以及與發(fā)送機之間公有的交換密鑰(Kx)，計算識別信息。由于識別信息的計算方法如前所述，因此省略。
確認請求部202將用更新信息存儲部903中存儲的更新信息(是現(xiàn)在接收的加密內(nèi)容中附加來的Nc，為Test_Nc)、和確認參數(shù)生成部201中生成的任意數(shù)(N)、和識別信息構(gòu)成的確認請求向發(fā)送機發(fā)送。
確認結(jié)果核對部203確認從發(fā)送機接收的應(yīng)答消息是否是知道消息。這里，為了確認是否是知道消息，使用發(fā)送的更新信息(test_Nc)及任意數(shù)(N)、以及與發(fā)送機之間公有的交換密鑰(Kx)，用與發(fā)送機的確認應(yīng)答部104計算知道消息相同的方法計算知道消息，與從發(fā)送機接收的應(yīng)答消息進行比較。由于知道消息的計算方法如前所述，因此省略。
內(nèi)容包接收部204接受用確認結(jié)果核對部203判定的結(jié)果，在判定為從發(fā)送機接收的應(yīng)答消息不是知道消息時，在包含該內(nèi)容的HTTP響應(yīng)結(jié)束之前，將作為該主體接收的內(nèi)容包拋棄。在判定為從發(fā)送機接收的應(yīng)答消息是知道消息、即是從正規(guī)的發(fā)送機發(fā)送時，判斷為正接收正確的內(nèi)容，繼續(xù)照原樣接收內(nèi)容。
內(nèi)容利用部205接受用確認結(jié)果核對部203判定的結(jié)果，在判定為從發(fā)送機接收的應(yīng)答消息不是知道消息時，中止利用該內(nèi)容。在判定為從發(fā)送機接收的應(yīng)答消息是知道消息、即是從正規(guī)的發(fā)送機發(fā)送時，判斷為正接收正確的內(nèi)容，繼續(xù)照原樣利用內(nèi)容。
圖3所示為具有圖1的發(fā)送機100及圖2的接收機200的實施形態(tài)1的內(nèi)容收發(fā)系統(tǒng)中的處理順序(協(xié)議)圖。認證及密鑰公有、內(nèi)容請求及接收的處理順序與前述以往例的圖10中所述的相同，故省略。
首先，用圖2及圖3，說明接收機200進行的、確認接收內(nèi)容是否是正規(guī)的協(xié)議動作。
步驟S321用內(nèi)容利用部205，開始利用解密內(nèi)容。
步驟S322用確認參數(shù)生成部201，生成任意數(shù)(N)及識別信息。這里，生成N，使得與剛才之前實施的確認請求中使用的數(shù)不相等。
步驟S323用確認請求部202，使用內(nèi)容中附加的更新信息(Nc)及任意數(shù)(N)及識別信息生成確認請求，并進行發(fā)送。
步驟S324用確認結(jié)果核對部203，從發(fā)送機100接收應(yīng)答消息。
步驟S325用確認結(jié)果核對部203，確認接收的應(yīng)答消息是否是知道消息。若是知道消息，則進入步驟S326，繼續(xù)利用內(nèi)容。若不是知道消息，則進入步驟S327，中止利用內(nèi)容。
步驟S326用內(nèi)容利用部205，繼續(xù)利用解密的內(nèi)容。
步驟S327用內(nèi)容利用部205中止利用內(nèi)容，用內(nèi)容包接收部204拋棄接收中的內(nèi)容包。
下面，用圖1及圖3，說明發(fā)送機100進行的、確認接收機是否正接收正規(guī)內(nèi)容用的協(xié)議動作。
步驟S311用確認請求接受部101，從接收機接收確認請求。
步驟S312用識別信息確認部102，判斷接收的確認請求中包含的識別信息是否正確。若正確，則進入步驟S313，進行更新信息確認。若不正確，則進入步驟S316，生成非知道消息。
步驟S313用更新信息確認部103，判斷接收的確認請求中包含的更新信息是否是可看成使用中。若是使用中，則進入步驟S314，生成知道消息。若不是使用中，則進入步驟S316，生成非知道消息。
步驟S314用確認應(yīng)答部104，使用從接收機200接受的更新信息及任意數(shù)(N)、以及與接收機之間公有的交換密鑰(Kx)，生成知道消息。
步驟S316用確認應(yīng)答部104，生成與知道消息不同的非知道消息。照原樣進入步驟S315。
步驟S315用確認應(yīng)答部104，發(fā)送應(yīng)答消息(知道消息或非知道消息)。
步驟S323相當于本發(fā)明的確認請求步驟的一個例子，步驟S325相當于本發(fā)明的正規(guī)內(nèi)容判定步驟的一個例子。另外，步驟S313相當于本發(fā)明的更新信息核對步驟的一個例子，將步驟S314及步驟S315合起來的處理相當于本發(fā)明的知道消息發(fā)送步驟的一個例子。
更新信息利用發(fā)送機按照規(guī)定的規(guī)則進行更新。因而，在非法設(shè)備進行內(nèi)容頂替時，頂替的內(nèi)容中附加的更新信息與發(fā)送機在該時刻保持的更新信息不一致。因而，發(fā)送機能夠根據(jù)從接收機發(fā)送來的確認請求中包含的更新信息，確認該接收機現(xiàn)在是否正接收正確的內(nèi)容。
另外，由于該確認結(jié)果通知即知道消息是使用正當?shù)陌l(fā)送機與該接收機之間預先公有的交換密鑰生成的，因此接收機能夠確認接收的知道消息是否是從正當?shù)陌l(fā)送機發(fā)送來的。通過這樣，能夠判別來自非法的冒充設(shè)備的頂替內(nèi)容。
另外，發(fā)送機中的更新信息的更新由于是內(nèi)部處理，可以認為是在比接收機接收附加剛才之前的更新信息的內(nèi)容更早的時刻進行的，因此通過對于剛才之前的更新信息也作為知道對象，能夠得到減輕關(guān)于正確內(nèi)容收發(fā)進行誤確認的頻次的效果。
另外，通過每次確認請求還使用不同的數(shù)，從而例如非法設(shè)備存儲發(fā)送機與接收機之間交換的更新信息及知道消息的組合，在接收機在來自冒充設(shè)備的頂替內(nèi)容接收中發(fā)送確認請求時，即使發(fā)送與非法設(shè)備存儲的該相同確認請求相對應(yīng)的知道消息，也能夠防止接收機中識別成功。
另外，由于通過確認請求中也包含使用正當?shù)陌l(fā)送機與該接收機之間預先公有的交換密鑰而生成的識別信息，從而即使非法設(shè)備將現(xiàn)在使用中的更新信息向該發(fā)送機發(fā)送，也不能獲得對應(yīng)的知道消息，因此接收機在來自冒充設(shè)備的頂替內(nèi)容接收中，能夠防止接收機中識別成功。
另外，在接收機不能接收知道消息時，即接收了非知道消息時，通過不利用接收內(nèi)容，能夠防止因非法設(shè)備干擾而使用戶有可能利用來自非法的冒充設(shè)備的頂替內(nèi)容。
另外，在實施形態(tài)1中，說明的是在發(fā)送機與接收機之間使用HTTP協(xié)議進行內(nèi)容收發(fā)的情況，但本發(fā)明不限于此，例如也可以適用于發(fā)送機實時將內(nèi)容進行流傳送的情況。
(實施形態(tài)2)圖4所示為本發(fā)明實施形態(tài)2有關(guān)的內(nèi)容收發(fā)系統(tǒng)中使用的接收機的功能方框圖。實施形態(tài)2的內(nèi)容收發(fā)系統(tǒng)中使用的發(fā)送機的構(gòu)成與實施形態(tài)1相同，如圖1所示的構(gòu)成。
在實施形態(tài)2中，說明與實施形態(tài)1不同的部分。在實施形態(tài)2中，從接收機對發(fā)送機重新進行確認請求，一直到最大規(guī)定次數(shù)。
接收機400與圖2所示的實施形態(tài)1的接收機200相同，具有證明書及密鑰保持部901、認證及密鑰交換部902、更新信息存儲部903、復制控制信息存儲部904、內(nèi)容密鑰計算部905、內(nèi)容解密部907、內(nèi)容包分析部908，HTTP協(xié)議部910、確認參數(shù)生成部201、確認請求部202、以及確認結(jié)果核對部203。還具有重新判斷部401、內(nèi)容包接收部402、以及內(nèi)容利用部403。
重新判斷部401在用確認結(jié)果核對部203判定為不是時，判斷是否重新進行。這里，例如根據(jù)進行了確認請求的次數(shù)再進一步判斷是否重新進行，在使用相同的更新信息連續(xù)已經(jīng)進行了兩次確認請求時，判斷為不重新進行更多次數(shù)的確認請求。
內(nèi)容包接收部402經(jīng)由重新判斷部401接受用確認結(jié)果核對部203判定的結(jié)果，在判定為從發(fā)送機接收的應(yīng)答消息不是知道消息時，在包含該內(nèi)容的HTTP響應(yīng)結(jié)束之前，將作為該主體接收的內(nèi)容包拋棄。在判定為從發(fā)送機接收的應(yīng)答消息是知道消息、即是從正規(guī)的發(fā)送機發(fā)送時，判斷為正接收正確的內(nèi)容，繼續(xù)照原樣接收內(nèi)容。
內(nèi)容利用部403經(jīng)由重新判斷部401接受用確認結(jié)果核對部203判定的結(jié)果，在判定為從發(fā)送機接收的應(yīng)答消息不是知道消息時，中止利用該內(nèi)容。在判定為從發(fā)送機接收的應(yīng)答消息是知道消息、即是從正規(guī)的發(fā)送機發(fā)送時，判斷為正接收正確的內(nèi)容，繼續(xù)照原樣利用內(nèi)容。
圖5所示為具有圖1的發(fā)送機100及圖4的接收機400的實施形態(tài)2的內(nèi)容收發(fā)系統(tǒng)中的處理順序(協(xié)議)圖。
下面，用圖4及圖5，說明接收機400進行的、確認接收內(nèi)容是否是正規(guī)的協(xié)議動作。步驟S321～步驟S324與前述實施形態(tài)1的圖3中所述相同，故省略。
步驟S325用確認結(jié)果核對部203，確認接收的應(yīng)答消息是否是知道消息。若是知道消息，則進入步驟S326，繼續(xù)利用內(nèi)容。若不是知道消息，則進入步驟S501，判斷是否重新進行。
步驟S326用內(nèi)容利用部403，繼續(xù)利用解密的內(nèi)容。
步驟S501用重新判斷部401，判斷是否重新進行確認請求。在重新進行時，返回步驟S322，進行確認請求發(fā)送用的準備。在不重新進行時，進入步驟S327。
這里，由于對重新判斷部401設(shè)定為「使用相同更新信息的重新進行最多兩次」，因此在第2次的確認請求重新發(fā)送后，再次進行步驟S501的判定時，不返回步驟S322，而進入S327。
另外，步驟S501相當于本發(fā)明的確認請求重新發(fā)送步驟的一個例子。而且，這里對重新判斷部401設(shè)定的所謂兩次的重新進行的最大規(guī)定次數(shù)，相當于本發(fā)明的確認請求重新步驟中重復發(fā)送正規(guī)確認請求的規(guī)定次數(shù)的一個例子。
步驟S327用內(nèi)容利用部403中止利用內(nèi)容，用內(nèi)容包接收部402拋棄接收中的內(nèi)容包。
因而，通過使用實施形態(tài)2的接收機400，能夠利用重新進行，得到減輕關(guān)于正確內(nèi)容收發(fā)進行誤確認的頻次的效果，同時通過設(shè)置最大重新次數(shù)，還能夠防止因非法設(shè)備干擾而在接收機長久重新進行之間能夠利用內(nèi)容(能夠視聽)的情況。
另外，在實施形態(tài)2中，是將重新進行的最大規(guī)定次數(shù)設(shè)為兩次進行說明的，但只要根據(jù)使用的內(nèi)容收發(fā)系統(tǒng)的使用狀況及使用環(huán)境等，設(shè)定適當?shù)拇螖?shù)即可。
另外，在實施形態(tài)2中，是將重新進行的限制設(shè)定為次數(shù)，但也可以用期間(時間)來設(shè)定，在這種情況下也能夠得到同樣的效果。
在對重新判斷部401設(shè)定期間作為重新進行的限制時，在該設(shè)定的期間中進行步驟S501的判定時，返回步驟S322，在該設(shè)定的期間經(jīng)過后進行步驟S501的判定時，不返回步驟S322，而進入步驟S327。這里，對重新判斷部401設(shè)定作為重新進行的限制的期間，相當于確認請求重新步驟中重復發(fā)送正規(guī)確認請求的規(guī)定期間的一個例子。
另外，在實施形態(tài)2中，重新進行時使用的更新信息是作為與最初的確認請求中使用的更新信息相同固定的，但也可以與和接收內(nèi)容一起變化的更新信息同步。
(實施形態(tài)3)圖6所示為本發(fā)明實施形態(tài)3有關(guān)的內(nèi)容收發(fā)系統(tǒng)中使用的接收機的功能方框圖。實施形態(tài)3的內(nèi)容收發(fā)系統(tǒng)中使用的發(fā)送機的構(gòu)成與實施形態(tài)1相同，如圖1所示的構(gòu)成。
在實施形態(tài)3中，說明與實施形態(tài)1不同的部分。在實施形態(tài)3中，在接收機中止利用接收內(nèi)容后，還進行確認請求，直到能夠接收知道消息為止。
接收機600與圖4所示的實施形態(tài)2的接收機400相同，具有證明書及密鑰保持部901、認證及密鑰交換部902、更新信息存儲部903、復制控制信息存儲部904、內(nèi)容密鑰計算部905、內(nèi)容解密部907、內(nèi)容包分析部908，HTTP協(xié)議部910、確認參數(shù)生成部201、確認結(jié)果核對部203、重新判斷部401、以及內(nèi)容利用部403。還具有確認請求部601及內(nèi)容包接收部602。
確認請求部601在一旦中止利用內(nèi)容后，也向發(fā)送機發(fā)送確認請求。這里，例如發(fā)送確認請求的時刻設(shè)為預先設(shè)定的重新再開始時間的反復時刻。
若從確認請求部601有請求，則內(nèi)容包接收部602不拋棄接收中的內(nèi)容包，向內(nèi)容包分析部908傳送。這是為了存儲生成確認請求所必需的、現(xiàn)在接收中的內(nèi)容中附加的更新信息(Nc)及復制控制信息(E_EMI)。
圖7所示為具有圖1的發(fā)送機100及圖6的接收機600的實施形態(tài)3的內(nèi)容收發(fā)系統(tǒng)中的處理順序(協(xié)議)圖。
下面，用圖6及圖7，說明接收機600進行的、確認接收內(nèi)容是否是正規(guī)的協(xié)議動作。步驟S321～步驟S327與前述實施形態(tài)2的圖5中所述相同，故省略。
步驟S701用確認請求部601，確認在發(fā)送前一次的確認請求之后是否經(jīng)過重新再開始時間，若經(jīng)過了，則中止用內(nèi)容包接收部602拋棄接收內(nèi)容包，返回步驟S322，發(fā)送確認請求。另外，步驟S701相當于本發(fā)明的確認請求再發(fā)送步驟的一個例子。
因而，若非法設(shè)備的冒充結(jié)束，則能夠立即再開始接收。
另外，也可以對確認請求部601設(shè)定使其再開始重新進行的限制次數(shù)或限制時間，使得不無限制地重新進行。通過連續(xù)的次數(shù)或從最初判定開始的經(jīng)過時間來限制步驟S701中的連續(xù)的判定。在超過該限制次數(shù)或限制時間時，中止確認請求的重新發(fā)送，一直到從接收機600發(fā)送內(nèi)容請求等為止。
這里對確認請求部601設(shè)定的限制次數(shù)或限制時間，相當于本發(fā)明的確認請求再發(fā)送步驟中重復發(fā)送正規(guī)確認請求的規(guī)定的限制次數(shù)或規(guī)定的限制期間的一個例子。
將為了再開始該重新進行而設(shè)定的限制次數(shù)或限制時間設(shè)定為足夠多的次數(shù)或足夠長的時間，通過這樣在非法設(shè)備的冒充結(jié)束后，能夠確實接收來自正規(guī)的發(fā)送機的知道消息。
另外，若用戶給出停止指示等、產(chǎn)生預先設(shè)定的停止條件，則也可以停止重新進行。
另外，在實施形態(tài)3中，是設(shè)重新再開始時間重復發(fā)出中止利用內(nèi)容后的確認請求，但也可以是用戶的輸入指定。
如上所述，若使用本發(fā)明的正規(guī)內(nèi)容確認方法，則發(fā)送機根據(jù)從接收機發(fā)送的更新信息，能夠確認該接收機現(xiàn)在是否正接收正確的內(nèi)容。另外，由于該確認結(jié)果通知即知道消息是使用正當?shù)陌l(fā)送機與該接收機之間預先公有的交換密鑰而生成的，因此接收機能夠確認接收的知道消息是否是從正當?shù)陌l(fā)送機發(fā)送的。通過這樣，能夠判別來自非法的冒充設(shè)備的頂替內(nèi)容。
另外，發(fā)送機中的更新信息的更新由于是內(nèi)部處理，可以認為是在比接收機接收附加剛才之前的更新信息的內(nèi)容更早的時刻進行的，因此通過不僅對于現(xiàn)在使用中的更新信息、對于剛才之前的更新信息也作為知道對象，能夠得到減輕關(guān)于正確內(nèi)容收發(fā)進行誤確認的頻次的效果。
另外，通過每次確認請求還使用不同的數(shù)，從而例如非法設(shè)備存儲發(fā)送機與接收機之間交換的更新信息及知道消息的組合，在接收機在來自冒充設(shè)備的頂替內(nèi)容接收中發(fā)送確認請求時，即使發(fā)送與非法設(shè)備存儲的該相同確認請求相對應(yīng)的知道消息，也能夠防止接收機中識別成功。
另外，由于通過確認請求中包含使用正當?shù)陌l(fā)送機與該接收機之間預先公有的交換密鑰而生成的消息，從而即使非法設(shè)備將現(xiàn)在使用中的更新信息向該發(fā)送機發(fā)送，也不能獲得對應(yīng)的知道消息，因此接收機在來自冒充設(shè)備的頂替內(nèi)容接收中，能夠防止使得識別成功。
另外這里，在接收機不能接收知道消息時，通過不利用接收內(nèi)容，能夠防止用戶有可能利用來自非法的冒充設(shè)備的頂替內(nèi)容。
另外，在接收機不能接收知道消息時，通過規(guī)定期間或規(guī)定次數(shù)重新進行后不利用接收內(nèi)容，從而能夠防止因非法設(shè)備干擾而在接收機長久重新進行之間能夠利用內(nèi)容(能夠視聽)的情況。
另外，接收機在中止利用接收內(nèi)容后，在能夠接收知道消息之前，還進行確認請求，通過這樣能夠得到若非法設(shè)備的冒充結(jié)束、則可立即再開始接收的效果。
這樣，通過使用本發(fā)明的正規(guī)內(nèi)容確認方法、內(nèi)容收發(fā)系統(tǒng)、發(fā)送機及接收機，能夠防止接收來自非法的冒充設(shè)備的頂替內(nèi)容。
另外，本發(fā)明的程序是使計算機執(zhí)行上述本發(fā)明的正規(guī)內(nèi)容確認方法的步驟的全部或一部分步驟的動作用的程序，是與計算機協(xié)同動作的程序，前述步驟具有用前述接收機發(fā)送前述正規(guī)確認請求的前述確認請求步驟；用前述發(fā)送機核對前述更新信息是否是前述規(guī)定的更新信息的前述更新信息核對步驟；用前述發(fā)送機生成前述知道消息并向前述接收機發(fā)送的前述知道消息發(fā)送步驟；以及在用前述接收機接收了來自前述發(fā)送機的前述知道消息時，確認前述發(fā)送機是正規(guī)的發(fā)送機的前述正規(guī)內(nèi)容判定步驟。
另外，本發(fā)明的記錄媒體是記錄了使計算機執(zhí)行上述本發(fā)明的正規(guī)內(nèi)容確認方法的步驟的全部或一部分步驟的動作用的程序的記錄媒體，是能夠用計算機讀取的、而且讀取的前述程序與前述計算機協(xié)同使用的記錄媒體，前述步驟具有以下步驟用前述接收機發(fā)送前述正規(guī)確認請求的前述確認請求步驟；用前述發(fā)送機核對前述更新信息是否是前述規(guī)定的更新信息的前述更新信息核對步驟；用前述發(fā)送機生成前述知道消息并向前述接收機發(fā)送的前述知道消息發(fā)送步驟；以及在用前述接收機接收了來自前述發(fā)送機的前述知道消息時，確認前述發(fā)送機是正規(guī)的發(fā)送機的前述正規(guī)內(nèi)容判定步驟。
另外，本發(fā)明的所謂上述「一部分步驟」，意味著是這些多個步驟內(nèi)的、一個或幾個步驟。
另外，本發(fā)明的所謂上述「步驟的動作」，意味著是前述步驟的全部或一部分的動作。
另外，本發(fā)明的程序的一個利用形態(tài)也可以是記錄在利用計算機能夠讀取的記錄媒體中、與計算機協(xié)同動作的形態(tài)。
另外，作為記錄媒體，包含ROM等。
另外，上述的本發(fā)明的計算機不限于CPU等純粹的硬件，也可以包含固件、0S、甚至外圍設(shè)備等。
另外，如上所述，本發(fā)明的構(gòu)成可以通過軟件來實現(xiàn)，也可以通過硬件來實現(xiàn)。
工業(yè)上的實用性本發(fā)明的正規(guī)內(nèi)容確認方法、內(nèi)容收發(fā)系統(tǒng)、發(fā)送機及接收機作為內(nèi)容確認技術(shù)是有用的，該內(nèi)容確認技術(shù)用于在網(wǎng)絡(luò)上逃避非法設(shè)備監(jiān)視正當?shù)陌l(fā)送機與接收機之間的通信、并對接收機發(fā)送非法內(nèi)容的這樣的攻擊。
權(quán)利要求
1.一種正規(guī)內(nèi)容確認方法，是內(nèi)容收發(fā)系統(tǒng)中的正規(guī)內(nèi)容確認方法，該內(nèi)容收發(fā)系統(tǒng)根據(jù)來自接收機的內(nèi)容請求，與網(wǎng)絡(luò)連接的發(fā)送機將在規(guī)定時刻更新的更新信息、即生成內(nèi)容加密及解密用的內(nèi)容密鑰所必需的所述更新信息附加在被加密的內(nèi)容中，進行發(fā)送，其特征在于，所述正規(guī)內(nèi)容確認方法包括以下步驟用所述接收機發(fā)送至少包含從所述發(fā)送機接收的所述更新信息的正規(guī)確認請求的確認請求步驟；用所述發(fā)送機核對從所述接收機接收的所述正規(guī)確認請求中包含的所述更新信息是否是規(guī)定的更新信息的更新信息核對步驟；在用所述發(fā)送機判定為所述更新信息是所述規(guī)定的更新信息時，使用所述更新信息及所述發(fā)送機和所述接收機的雙方預先公有的交換密鑰，生成知道消息并向所述接收機發(fā)送的知道消息發(fā)送步驟；以及在用所述接收機接收了來自所述發(fā)送機的所述知道消息時，判斷為接收中的內(nèi)容是正規(guī)內(nèi)容的正規(guī)內(nèi)容判定步驟。
2.如權(quán)利要求1所述的正規(guī)內(nèi)容確認方法，其特征在于，所述規(guī)定的更新信息是現(xiàn)在使用中的更新信息或規(guī)定次數(shù)更新前的更新信息。
3.如權(quán)利要求1所述的正規(guī)內(nèi)容確認方法，其特征在于，在所述確認請求步驟中，所述接收機每發(fā)送一次所述正規(guī)確認請求，將不同的數(shù)也包含在所述正規(guī)確認請求中進行發(fā)送，在所述知道消息發(fā)送步驟中，所述發(fā)送機還使用所述正規(guī)確認請求中包含的所述數(shù)，生成所述知道消息。
4.如權(quán)利要求1所述的正規(guī)內(nèi)容確認方法，其特征在于，在所述確認請求步驟中，所述接收機使用所述交換密鑰及從所述發(fā)送機發(fā)送來的所述更新信息生成的識別消息也包含在所述正規(guī)確認請求中進行發(fā)送，在所述知道消息發(fā)送步驟中，所述發(fā)送機在判定為所述更新信息是所述規(guī)定的更新信息、而且確認所述正規(guī)確認請求中包含的所述識別消息與所述發(fā)送機本身使用所述交換密鑰及所述更新信息生成的識別消息一致時，將所述知道消息向所述接收機發(fā)送。
5.如權(quán)利要求1所述的正規(guī)內(nèi)容確認方法，其特征在于，在所述知道消息發(fā)送步驟中，所述發(fā)送機在判定為所述更新信息不是所述規(guī)定的更新信息時，將非知道消息向所述接收機發(fā)送，在所述正規(guī)內(nèi)容判定步驟中，在用所述接收機接收了來自所述發(fā)送機的所述非知道消息時，判斷為接收中的內(nèi)容不是正規(guī)內(nèi)容，不利用所述內(nèi)容。
6.如權(quán)利要求1所述的正規(guī)內(nèi)容確認方法，其特征在于，在所述正規(guī)內(nèi)容判定步驟中，在所述接收機不能接收所述知道消息時，還具有用所述接收機在規(guī)定期間重復發(fā)送所述正規(guī)確認請求的確認請求重新發(fā)送步驟，在所述正規(guī)內(nèi)容判定步驟中，在用所述接收機即使超過所述規(guī)定期間也不能接收所述知道消息時，就不利用接收的內(nèi)容。
7.如權(quán)利要求1所述的正規(guī)內(nèi)容確認方法，其特征在于，在所述正規(guī)內(nèi)容判定步驟中，在所述接收機不能接收所述知道消息時，還具有用所述接收機重復規(guī)定次數(shù)發(fā)送所述正規(guī)確認請求的確認請求重新發(fā)送步驟，在所述正規(guī)內(nèi)容判定步驟中，在用所述接收機即使發(fā)送所述規(guī)定次數(shù)的所述正規(guī)確認請求也不能接收所述知道消息時，就不利用接收的內(nèi)容。
8.如權(quán)利要求5至7的任一項所述的正規(guī)內(nèi)容確認方法，其特征在于，在所述正規(guī)內(nèi)容判定步驟中，在用所述接收機不利用接收的所述內(nèi)容之后，直到規(guī)定的限制次數(shù)或規(guī)定的限制期間或規(guī)定的停止條件具備之前，還具有重復發(fā)送所述正規(guī)確認請求的確認請求再發(fā)送步驟，在所述正規(guī)內(nèi)容判定步驟中，在用所述接收機不利用接收的所述內(nèi)容之后，在接收了所述知道消息時，就利用接收的內(nèi)容。
9.一種內(nèi)容收發(fā)系統(tǒng)，具有發(fā)送內(nèi)容請求的接收機、以及發(fā)送機，該發(fā)送機利用網(wǎng)絡(luò)與所述接收機連接，根據(jù)來自接收機的內(nèi)容請求，將在規(guī)定時刻更新的更新信息、即生成內(nèi)容加密及解密用的內(nèi)容密鑰所必需的所述更新信息附加在被加密的內(nèi)容中，進行發(fā)送，其特征在于，所述接收機具有發(fā)送使用與所述發(fā)送機的雙方預先公有的交換密鑰、和從所述發(fā)送機接收的所述更新信息生成的正規(guī)確認請求的確認請求單元；以及在接收了來自所述發(fā)送機的知道消息時，判斷為接收中的內(nèi)容是正規(guī)內(nèi)容的確認結(jié)果核對單元，所述發(fā)送機具有接收從所述接收機發(fā)送來的所述正規(guī)確認請求的確認請求接受單元；核對接收的所述正規(guī)確認請求中包含的所述更新信息是否是規(guī)定的更新信息的更新信息確認單元；以及在判定為所述更新信息是所述規(guī)定的更新信息時，使用所述更新信息和與所述接收機的雙方公有的所述交換密鑰生成所述知道消息，并向所述接收機發(fā)送的確認應(yīng)答單元。
10.一種發(fā)送機，是內(nèi)容收發(fā)系統(tǒng)中使用的發(fā)送機，該內(nèi)容收發(fā)系統(tǒng)根據(jù)來自接收機的內(nèi)容請求，與網(wǎng)絡(luò)連接的發(fā)送機將在規(guī)定時刻更新的更新信息、即生成內(nèi)容加密及解密用的內(nèi)容密鑰所必需的所述更新信息附加在被加密的內(nèi)容中，進行發(fā)送，其特征在于，具有接收所述接收機中使用與所述接收機的雙方預先公有的交換密鑰、和從所述發(fā)送機接收的所述更新信息生成的、并從所述接收機發(fā)送來的正規(guī)確認請求的確認請求接受單元；核對從所述接收機接收的所述正規(guī)確認請求中包含的所述更新信息是否是規(guī)定的更新信息的更新信息確認單元；以及在判定為所述更新信息是所述規(guī)定的更新信息時，使用所述更新信息和所述交換密鑰，生成判斷所述接收機接收中的內(nèi)容是否是正規(guī)內(nèi)容用的知道消息，并向所述接收機發(fā)送的確認應(yīng)答單元。
11.一種接收機，是內(nèi)容收發(fā)系統(tǒng)中使用的接收機，該內(nèi)容收發(fā)系統(tǒng)根據(jù)來自接收機的內(nèi)容請求，與網(wǎng)絡(luò)連接的發(fā)送機將在規(guī)定時刻更新的更新信息、即生成內(nèi)容加密及解密用的內(nèi)容密鑰所必需的所述更新信息附加在被加密的內(nèi)容中，進行發(fā)送，其特征在于，具有發(fā)送使用與所述發(fā)送機的雙方預先公有的交換密鑰、和從所述發(fā)送機接收的所述更新信息生成的正規(guī)確認請求的確認請求單元；以及在接收了所述發(fā)送機判定為接收的所述正規(guī)確認請求中包含的所述更新信息是規(guī)定的更新信息后，使用所述更新信息及所述交換密鑰生成并發(fā)送來的知道消息時，判斷為接收中的內(nèi)容是正規(guī)內(nèi)容的確認結(jié)果核對單元。
12.一種程序，其特征在于，是使計算機執(zhí)行權(quán)利要求1所述的正規(guī)內(nèi)容確認方法的步驟用的程序，所述步驟包括用所述接收機發(fā)送所述正規(guī)確認請求的所述確認請求步驟；用所述發(fā)送機核對所述更新信息是否是所述規(guī)定的更新信息的所述更新信息核對步驟；用所述發(fā)送機生成所述知道消息并向所述接收機發(fā)送的所述知道消息發(fā)送步驟；以及在用所述接收機接收了來自所述發(fā)送機的所述知道消息時，確認所述發(fā)送機是正規(guī)的發(fā)送機的所述正規(guī)內(nèi)容判定步驟。
13.一種記錄媒體，能夠利用計算機處理，其特征在于，是記錄了權(quán)利要求12所述的程序的記錄媒體。
全文摘要
以往不能檢測出監(jiān)視正當?shù)陌l(fā)送機與接收機之間的通信的非法設(shè)備進行的冒充、以及對接收機發(fā)送非法內(nèi)容。在將生成內(nèi)容加密/解密用的內(nèi)容密鑰所必需的更新信息附加在被加密的內(nèi)容中并進行傳送的系統(tǒng)中，采用正規(guī)內(nèi)容確認方法，該正規(guī)內(nèi)容確認方法包括以下步驟接收機200發(fā)送包含從發(fā)送機100接收的更新信息的正規(guī)確認請求的確認請求步驟S323；發(fā)送機100核對接收的正規(guī)確認請求中包含的更新信息是否是規(guī)定的更新信息的更新信息核對步驟S313；在與規(guī)定的更新信息一致時，使用該更新信息和發(fā)送機100/接收機200之間公有的交換密鑰，生成知道消息并發(fā)送的知道消息發(fā)送步驟S314及S315；以及接收機200接收了知道消息后，判斷為正規(guī)內(nèi)容的正規(guī)內(nèi)容判定步驟S325。
文檔編號G11B20/10GK101036341SQ200580034388
公開日2007年9月12日 申請日期2005年10月12日 優(yōu)先權(quán)日2004年10月13日
發(fā)明者高辻綾子, 飯塚裕之, 臼木直司 申請人:松下電器產(chǎn)業(yè)株式會社