WO2008013161A1

WO2008013161A1 - Système de communication

Info

Publication number: WO2008013161A1
Application number: PCT/JP2007/064484
Authority: WO
Inventors: Kyosuke Kanno; Isao Abe
Original assignee: Aquacast Corporation; Ntt Docomo, Inc.
Priority date: 2006-07-28
Filing date: 2007-07-24
Publication date: 2008-01-31
Also published as: JP2008035136A; JP5060746B2

Description

明細書

通方式

技術分野

[0001] 本発明は、 HTTP (Hyper Text Transfer Protocol)に則ったデータを暗号化して伝送する通信方式において、暗号化強度を高める方法に関するものである。

背景技術

[0002] インターネット網で広く使用されている通信プロトコルに、 HTTP (Hyper Text Transf er Protocol)がある。このプロトコノレは、 HTML(Hyper Text Markup Language)で記述されたホームページデータや、電子メールのデータを伝送することが出来る。このプロトコルについては、 IETF RFC2616, "Hypertext Transfer Protocol -- HTTP/1.1", The Internet Society, 1999， ρ·8に記載されている。

[0003] HTTPでの通信には、通信内容の本文に加えて、ヘッダ（Header)やタグ（Tag)などの記述情報が付帯される。 HTTPや HTMLには多数の固定メッセージが存在する。図 1は HTTP通信における固定メッセージの例を示し、図 2は HTTP通信による HTML伝送における固定メッセージの例を示し、図 3は HTTP通信による電子メーノレ伝送における固定メッセージの例を示す。具体的には、これらの図で下線を引いた部分が固定メッセージである。固定メッセージは、公開された公知のメッセージである。

[0004] これらの通信は、公衆インターネット網を介して行われるため、情報漏洩を回避するために、通信内容の暗号化技術を用いることが多い。

[0005] 伝送したい情報を暗号化する従来手法の 1つとして、排他的論理和（XOR)を用いた方法がある。例えば、ブルース'シュナイァー著、山形浩生監訳、「暗号技術大全」、ソフトバンクパブリツシング、 2003年、 ρ· 15— 16には、この方法が開示されている。図 4にその XOR演算方式暗号化を示す。この手法では、何らかの方法で生成したキ

XOR演算を行うことにより、暗号化データストリーム 2を生成する。図において、丸で囲んだ十字は XOR演算がされることを示す。

[0006] 図 4においては、スクランブルパタンは秘密鍵から喑号器による演算によって生成されている。また、上記の「暗号技術大全」によれば、平文データストリーム 1の長さより

、スクランブルパタンの長さが短い場合は、スクランブルパタンは繰り返し適用される

〇

発明の開示

発明が解決しょうとする課題

[0007] 図 4の XOR演算方式暗号化では、一定の長さのスクランブルパタンが繰り返し使用されるため、次のような脆弱性を不可避的に内包する。いま、何らかの理由でスクランブルパタンの一部のビットが解読されたとすると、スクランブルパタンが繰り返し使用される部分の対応する平文ストリーム 1のビットが解読されてしまうことになる。このように暗号の一部が破られると、破られた部分のデータが他の部分の暗号の解読に繰り返し使用されるので、 XOR演算方式暗号化の強度は、一定長さのスクランブルパタンが繰り返し使用されるならば、高いとはいえない。

[0008] また、従来技術である XOR演算方式暗号化を用いて、 HTTPプロトコルによる、ホームページ閲覧や、電子メール伝送を行うと、ヘッダやタグと呼ばれる固定メッセージが通信内容の本文と一緒に暗号化される。

[0009] 図 2は、 HTTPに則りホームページアクセスをする際に送受信されるメッセージソースの例を示す図である。メッセージソースは、 HTTPヘッダと HTML文書でなるデータであり、送信側と受信側の間で送受信される。 HTTPに則る通信では、 HTTPヘッダは記述情報として必須であり、 HTTPヘッダは" Content-Length: "等のデータが固定された固定メッセージを含む。図 2〜図 4において下線を付したデータが固定メッセ一ジの例である。

[0010] 図 3は、 HTTPに則り電子メールを送受信する際の例を示す図である。通信内容は HTTPヘッダとメール本文からなるデータであり、これらは HTTPに則り通信されるので、 HTTPヘッダは必須であり、 HTTPヘッダは" Content-Length: "等のデータが固定された固定メッセージを含む。

[0011] ホームページソースでは、 HTML文書にも、多数のタグ（Tag)と呼ばれる固定メッセージを含む。タグは、 HTTP文書内で、ホームページの動きをあらわす命令やコメントを書き込むための書式であり、図 2におけるく HTML〉， (/HTML) , (HEAD) ,〈/HEA D)， (TITLE)， (/TITLE)， (BODY)， (/BODY)，く A HREF二〉，〈/A〉などはタグであり、それぞれ一定のデータである。タグの間に挟まれたデータをタグ内容と称することとする。図 2の例では、く TITLE〉と〈/TITLE〉との間に挟まれたデーダ 'Home Page" 、く A HREF=http： //www. sample .jp/link 1 /" )と〈/A〉との間のデータ"リンク 1 "などがタグ内容である。また、図 2における" http：〃 www. sample.jp/linkl/"及び" http：〃 www. s ample. jp/link2/"は属性パラメータと称される。

[0012] HTMLに関しては、 W3C (The World Wide Web Consortium)で勧告されて!/、る。タグとタグ内容で表される HTML文書の基本構成は、〈要素属性 = "パラメータ"〉タグ内容〈/要素〉である。上記 HTML, HEAD, TITLE, BODY, Aは、要素の例であり、上記 HREFは属性の例である。要素としては、その他に IMG, FONT, SCRIPT, FRAME, LINK等の多数が規定されている。属性としては、その HREFの他に、 SRC, WIDTH, HEIGHT, COLOR等の多数が規定されている。属性 HREFに付帯されるパラメータがリンク先と称され、属性 SRCに付帯されるパラメータが参照先などと称されることもある、本出願書類では、属性に付帯されるパラメータは、リンク先及び参照先も含め、属性パラメータと総称することにする。

[0013] 図 5は、従来の HTTPプロトコルに則った通信をする際に送信側および受信側で行われる処理の流れを示す図である。送信側 100では、 HTTPヘッダ [図では"ヘッダ（H eader) "と略記されている] 11a及び本文 12aでなるメッセージソース laの全体が暗号化され、暗号文 13だけでなるメッセージソース leとなり、送信される。受信側 200に受信されたメッセージソース Ifは暗号文 14だけでなり、暗号文 14は復号化処理により、平文の HTTPヘッダ l id及び本文 12dが再生される。図 5の暗号文 13には HTTPヘッダ 11 aにあった固定メッセージ（例えば、 "Content-Length: ")の暗号文を含む。固定メッセージの暗号文は、データ内容が固定であり、またメッセージソース leにおける出現位置もほぼ固定であるので、解読者に暗号解読のヒントを与える。

[0014] 図 6は、ホームページにアクセスする際に、送信側および受信側において行われる従来の HTML文書の処理の流れを示す図である。ホームページソースにおける HTM L文書は HTTPヘッダに付帯して送受信される。 HTML文書は、 HTTPヘッダともに喑号化され送受信される。ホームページソースにおける HTML文書には、タグ、属性パラメータ及びタグ内容が含まれる。送信側における平文の HTML文書 2aは暗号化処理を受け、暗号文 2eに変換され、送信される。送信側から受信側に伝送され、受信側で受信されたデータは暗号文 2ί^'けであり、暗号文 2fは復号化処理を受け、平文の HTML文書 2dが再生される。図 5の暗号文 2fには固定メッセージ（例えば、 " (HTM L〉"）の暗号文を含む。固定メッセージの暗号文は、データ内容が固定であり、また暗号文 2fにおける出現位置もほぼ固定であるので、解読者に暗号解読のヒントを与 X·る。

[0015] 図 7は、平文データとスクランブルパタンとの XOR演算方式暗号化（図 4)により暗号データを生成したときに、生成された暗号文データを解読する原理を説明する図である。図 7における平文データは、図 4の平文データストリームにおける一定長のビット毎に区切られた各平文データに相当する。また、図 7における暗号文データは、図 4の暗号化データストリームにおける一定長ビットの暗号化データに相当する。図 7の式（1)は、図 4の XOR演算方式暗号化力（平文データ） XOR (スクランブルパタン） = (暗号文データ）なる演算式により行われることを示している。図 4の例では、スクランブルパタンのビット長は、平文データ及び暗号文データのビット長と同じ長さである。 XOR演算においては、 2回の同じ演算により元のデータに戻るという性質がある。この性質により、データ A及び Bに関し、 A XOR B XOR B = A及び A XOR A XOR B = B (したがって、 A XOR B XOR A = B)なる式が成立する。図 7の式（2)及び式（3) は、 XOR演算のこの性質を利用し、暗号文データから平文データを得る演算を示す式である。

[0016] 図 8は、図 5及び図 6に示した暗号文における固定メッセージの始点が断定できるときに、暗号文の解読法を示す図である。いま、暗号文の暗号化データストリーム 3は、各 64ビットでなる区分暗号化データストリーム 30〜30を n個連接して構成されているものとする。そして、暗号化データストリーム 3は、 HTTPに則ったメッセージソース（図 1)又はホームページソース（図 2)の暗号文であり、 "Content-Length: "なる 16バイトの固定メッセージを含み、 "Content-，，は 8バイト（64ビット）、 "Length:，，も 8バイト（64 ビット）のデータであり、 "Content-，，と" Length:，，とは連続しており、 "Content-，，は喑号化データストリームの先頭から i番目の区分暗号化データストリーム 30に位置することが予め知られて!/、るとする。

[0017] このような条件の暗号化データストリームは、次の処理により容易に解読される。いま" Content-"を Aとし、 64ビットのスクランブルパタンを Bとすると、 i番目の区分暗号化データストリーム 30は A XOR Bなる処理により生成されている。（図 4参照）ので、 i番目の区分暗号化データストリーム 30つまり A XOR Bに Aの排他的論理和演算（XOR )を施すと、演算式は A XOR B XOR Aとなり、 A XOR B XOR Aなる演算の結果は前述のとおり Bとなる（A XOR B XOR A = B)。力、くして、スクランブルパタン Bが解読され

[0018] スクランブルパタン Bは、図 4に示されるように、全ての平文データの暗号化に共通に使用されて、暗号化データストリームが生成されているので、このスクランブルパタン Bと残りの区分暗号化データストリーム（1番目から i一 1番目の区分暗号化データストリーム 30〜30 及び i+ 1番目から n番目の区分暗号化データストリーム 30 〜30

)との排他的論理和演算を行えば、図 7の式（3)により、残りの全ての区分暗号化デ一タストリームは解読される。解読が正しく行われた否かは、 i+ 1番目の区分暗号化データストリーム 30 を解読して得た平文が "Length: "であるか否かで分かる。 "Leng th: "であれば、解読は正しく行われており、そうでなければ解読は誤っている。もし、固定メッセージ" Content-"の始点が i番目の区分暗号化データストリーム 30の開始点でな力、つたが故に、暗号化データストリームを解読できな力たときは、図 9を参照して説明する下記の方法で解読することができる。

[0019] 図 9は、図 5及び図 6に示した暗号文における固定メッセージの始点が断定できないときに、暗号文の解読法を示す図である。いま、暗号文の暗号化データストリーム 3 は、各 64ビットでなる区分暗号化データストリーム 30〜30を連接して構成されているものとする。そして、暗号化データストリーム 3は、 HTTPに則ったメッセージソース（図 1)又はホームページソース（図 2)の暗号文であり、 "Content-Length: "なる 16バイトの固定メッセージを含み、 "Content-，，は 8バイト（64ビット）、 "Length:，，も 8バイト（64 ビット）のデータであり、 "Content-"と" Length: "とは連続していることが予め知られているが、 "Content-"が暗号化データストリームの先頭からどの位置あるかは不明であるとする。 [0020] 固定メッセージ" Content-"の出現位置が変化するときは、 "Content-"の出現位置を次の方法により割り出せる。まず、暗号化データストリーム 3の先頭から第 1ビットが" Content-"の出現始点であると仮定し、この始点から始まる 128ビットのデータに注目する。前半の 64ビットデータど' Content-"の XOR演算で得られた 64ビットのデータストリームが、後半の 64ビットデータと" Length: "の XOR演算で得られた 64ビットのデータストリームとが同じであれば、仮定した" Content-"出現の始点が正しいと判断できる。もし、得られた 2つの 64ビットデータストリームが同じでなければ、暗号化データストリームの先頭から第 2番目のビットを" Content-"出現の始点と仮定し、同様に処理を行い、仮定した" Content-"出現の始点の当否を判断する。もし、得られた 2つの 64ビットデータストリームが同じでなければ、暗号化データストリームの先頭から第 3番目のビットを" Content-"出現の始点と仮定し、同様に処理を行い、仮定した" Content-" 出現の始点の当否を判断する。以下同様に、 2つの 64ビットデータストリームが一致するまで、処理を繰り返す。

[0021] 上記処理は、図 9に概念的に示されているように、総長 128ビットの XOR演算と比較演算だけで行われる。そして、この計算は最大 HTTPヘッダ長のビット数回の繰り返しだけで足りる。例えば、電子メールの最大 HTTPヘッダ長が 1000バイト（8000ビット）のときは、論理的最大計算量は（8000— 128)回である。このように計算量が少ないので、クロック周波数 1GHzの市販のパソコンで、メッセージソースの HTTPヘッドにおける" Content-Length: "の始点の検知を試みたところ、瞬時に検出できた。なお、メッセ一ジソースやホームページソースといった HTTPデータソースには、 "Content-Length: " の他に多数の固定メッセージがあるので、 "Content-Length: "以外の固定メッセージに注目しても、固定メッセージの出現位置が同様に検出できる。

[0022] 64ビットの固定メッセージの出現位置が検出できれば、その固定メッセージと、その位置から始まる 64ビットの暗号化データストリームとの XOR演算により、 64ビットのスクランブルパタンが判明する。スクランブルパタンが判明すれば、前後に続く 64ビットずつの暗号化データストリームとスクランブルパタンとの XOR演算により、暗号化データストリームが解読できる。 1つのスクランブルパタンは、 HTTPヘッダだけでなぐメッセージソースにおけるメール本文やホームページソースにおける HTML文書と XOR演算され、暗号化データストリームを生成しているので、そのスクランブルパタンとメール本文や HTML文書との XOR演算により、メール本文や HTML文書は解読される。

[0023] 図 8及び図 9を参照して説明したところから明らかなように、 HTTPに則ったメッセ一ジソース（図 1)又はホームページソース（図 2)の暗号文のパケット通信が傍受されたとき、図 8又は図 9の処理により暗号文は解読されてしまう。

[0024] そこで本発明の目的は、通信の秘密性を向上させる手段の提供にある。

課題を解決するための手段

[0025] 本発明は、前述の課題を解決するために、 HTTPに則るメッセージソース又はホームページソースの少なくとも一方であって、固定メッセージを含むソースデータを送受信する通信方式において、前記固定メッセージを除く部分だけを暗号化して、該ソースデータを送信することを特徴とする通信方式を提供する。

[0026] また、本発明は、前述の課題を解決するために、 HTTPに則るメッセージソース又はホームページソースの少なくとも一方を含むソースデータを送受信する通信方式において、送信側は、前記ソースデータにおける固定メッセージを除くメッセージの内の少なくとも一部分のメッセージの暗号化により暗号文を生成し、該一部分以外の該ソースデータに該暗号文を連結した部分暗号化ソースデータを生成し、該部分暗号化ソースデータを送信し、受信側は、前記部分暗号化ソースデータを受信し、該部分暗号化ソースデータにおける前記暗号文の復号により前記一部分を復元し、該一部分以外の前記部分暗号化ソースデータと該一部分とを連結し、前記ソースデータを再生することを特徴とする通信方式を提供する。

[0027] 好ましくは、前記ソースデータは、 HTTPヘッダ及びメール本文でなるメッセージソースであり、前記暗号文は前記メール本文を暗号化したものである。

[0028] 好ましくは、前記ソースデータは、 HTTPヘッダと HTML文書とを含むホームページソースであり、前記送信側は、前記 HTML文書に含まれるタグ及び属性パラメータを抽出し、該 HTML文書における該タグ内容の暗号化により暗号化タグ内容を生成するとともに、前記属性パラメータの暗号化により暗号化属性パラメータを生成し、該喑号化タグ内容および該暗号化属性パラメータを、 MME64その他のタグを含まな!/、符号に変換することにより、符号変換暗号化タグ内容および符号変換暗号化属性パラメータを生成し、前記タグ内容及び前記属性パラメータ以外の前記 HTML文書に該符号変換暗号化タグ内容および符号変換暗号化属性パラメータを連結することにより、部分暗号化 HTML文書を生成し、前記 HTTPヘッダに該部分暗号化 HTML文書を連結し、該 HTTPヘッダ及び該部分暗号化 HTML文書を送信し、受信側は、前記 H TTPヘッダ及び前記部分暗号化 HTML文書を受信し、該部分暗号化 HTML文書における前記符号変換暗号化タグ内容および前記符号変換暗号化属性パラメータを抽出し、抽出された該符号変換暗号化タグ内容および該符号変換暗号化属性パラメ一タに逆符号変換を施すことにより前記暗号化タグ内容及び前記暗号化属性パラメータを復元し、該暗号化タグ内容及び該暗号化属性パラメータの復号化により前記タグ内容及び前記属性パラメータを復元し、該部分暗号化 HTML文書における該符号変換暗号化タグ内容および該符号変換暗号化属性パラメータ以外の部分に該タグ内容及び該属性パラメータを連結し、前記 HTML文書を再生する。

発明の効果

[0029] 本発明によれば、上述の構成により、通信の秘密性が向上した通信方式を提供できる。

図面の簡単な説明

[0030] [図 1]HTTP通信における固定メッセージの例を示す図である。

[図 2]HTTP通信による HTML伝送における固定メッセージの例を示す図である。

[図 3]HTTP通信による電子メール伝送における固定メッセージの例を示す図である

〇

[図 4]XOR演算方式暗号化の方法を示す図である。

[図 5]従来の HTTP通信における処理の流れを示す図である。

[図 6]従来の HTML文書通信における処理の流れを示す図である。

[図 7]XOR演算方式の解読原理を示す図である。

[図 8]暗号文における固定メッセージの始点が特定できる場合の解読方法を示す図である。

[図 9]暗号文における固定メッセージの始点が特定できない場合の解読方法を示す図である。 [図 10]本発明による HTTP通信の処理の流れを示す図である。

[図 11]本発明によるメール暗号化処理の例を示す図である。

[図 12]本発明による HTML文書伝送処理の流れを示す図である。

[図 13]本発明による HTML文書暗号化処理の例を示す図である。

発明を実施するための最良の形態

[0031] 次に図面を参照し、本発明の実施の形態を発明する。図 10は、本発明の第 1の実施の形態における処理の流れを示す図である。本実施の形態は、 HTTP通信におけるメッセージソースに本発明を適用した例である。メッセージソース laは、 HTTPヘッダ [図では、 "ヘッダ（Header) "と略記してある] 11aとメッセージ本文 12aとでなる（メッセ一ジソースの構成については図 2及び図 3参照）。メッセージ本文 12aは、図 4の XOR演算方式暗号化により暗号文 12bに変換する。暗号文 12bは、 HTTPヘッダ l lb(HTTPへッダ 11aと同じもの)と連結される。互いに連結された HTTPヘッダ l ib及び暗号文 12b はメッセージソース lbを構成し、メッセージソース lbは送信側 100から受信側 200へ伝送される。

[0032] メッセージソース lbは、受信側 200にメッセージソース lcとして受信される。メッセ一ジソース lcは、 HTTPヘッダ 11c (HTTPヘッダ l ibと同じ内容）及び暗号文 12c (暗号文 12bと同じ内容）でなる。暗号文 12cは、復号化の処理を受け、メッセージ本文 12dが復元される。メッセージ本文 12dは HTTPヘッダ l ld (HTTPヘッダ 11cと同じ内容）と連結され、メッセージソース Id (メッセージソース laと同じ内容）となる。ここに、送信側のメッセージソース laが再生された。

[0033] 図 11は、図 10の実施の形態において暗号化前のメッセージソース la (図の上段）と暗号化後のメッセージソース lb (図の下段）とを示す図である。本図の示すように、図 1の実施の形態では、 HTTPヘッダは暗号化されず平文のまま送信され、他方本文は暗号化して送信される。

[0034] 図 11の実施の形態では、 HTTPヘッダ 11aは喑号化されず、平文のまま送信され、暗号化されるのは本文 12aだけであり、暗号文 12bには固定メッセージは含まれないので、暗号文 12bを解読しょうとしても、固定メッセージをヒントとする暗号文 12bの解読はできない。このように、本実施の形態によれば、通信の秘密性が向上する。 [0035] 図 12は、本発明の第 2の実施の形態における処理の流れを示す図である。本実施の形態は、ホームページにアクセスした際のホームページソースの通信に本発明を適用した例である。ホームページソースは、図 2に構成の例を示すように、 HTTPへッダと HTML文書とでなり、 HTTPヘッダには" Content-Length: "等の固定メッセージを

、また HTML文書にはく TITLE〉， (/TITLE)，く A HREF= 〉，〈/A〉等のタグと呼ばれる固定メッセージを含む。く TITLE〉と〈/TITLE〉との間に挟まれたデータ" Home Pa ge"、 (A HREF=http： //www . sample .jp/link 1 /" )と〈/A〉との間のデータ"リンク 1"などカタグ内容であり、 "http://www.sample.jp/linkl/"及び" http://www.sample.jp/link2 /"は属性パラメータと称されることは前述のとおりである。

[0036] この第 2の実施の形態においても、前記第 1の実施の形態と同じぐ HTTPヘッダには固定メッセージが含まれるので、 HTTPヘッダは暗号化せず、平文のまま送信する。前述のとおり、第 1の実施の形態の送信データであるメッセージソースにおける本文には固定メッセージが含まれないので、第 1の実施の形態では本文は全体を暗号化して送信した。他方、第 2の実施の形態の送信データであるホームページソースにおける HTML文書には固定メッセージのタグが含まれるので、 HTML文書全体を暗号化すると、タグが暗号解読のヒントとなる。そこで、第 2の実施の形態では、タグは平文のまま送信し、タグ内容を XOR演算方式で暗号化し、送信する。

[0037] ただし、タグ内容を暗号化すると、タグ内容の一部がタグと同一又はタグの一部と同一のデータに化け、暗号文にタグ又はタグの一部が現れることがある。暗号文にタグの一部が現れると、どの部分が本来のタグであるかが分からなくなるので、受信側で平文のタグを抽出し、タグ内容の暗号文を復号しょうとしても、抽出するタグが誤ったものとなるので、元の HTML文書は復元されない。

[0038] そこで、本第 2の実施の形態では、送信側において暗号化タグ内容を MIME64により符号変換する。 MIME64符号では、タグの開始及び終了をそれぞれ表す記号"く" 及び"〉"は生成されないので、暗号化タグ内容を送信側で一旦 MIME64符号にし、 M IME64符号の暗号化タグ内容をタグではさんで送信することにより、受信側では、タグを抽出し、暗号化タグ内容のデータ範囲を正しく確定できる。このように、暗号化タグ内容のデータ範囲を正しく確定した後に、 MME64符号の暗号化タグ内容に MIME64 の逆符号変換 (逆 MME64)を施し、元の暗号化タグ内容を再現し、その元の暗号化タグ内容を復号し、タグ内容を再生する。このように、タグ内容の暗号文を、タグの開始-終了記号"く"，"〉"が現れない符号に変換することにより、暗号文にタグ又はタグの一部が含まれていても、受信側におけるタグの抽出は正確に行われる。

[0039] このように、第 2の実施の形態では、上述の方法で、送信側では、 HTML文書の一部分を暗号化した部分暗号化 HTML文書を生成し、受信側では、その部分暗号化 H TML文書における暗号化部分、即ちタグ内容を復号化し、元の HTML文書を再生する。以上には、ホームページソースにおける HTTPヘッダについては述べなかったが、第 2の実施の形態は HTTPに則ったホームページソースの通信方式であるから、本文に HTTPヘッダを送信側で付帯した図 10の第 1の実施の形態と同様に、第 2の実施の形態でも、送信側では、部分暗号化 HTML文書に HTTPヘッダを付帯して送信し、受信側では、 HTTPヘッダを付帯された部分暗号化 HTML文書を受信する。すなわち、第 2の実施の形態は、 HTTPヘッダの処理に関しては第 1の実施の形態と同様である。

[0040] 次に図 12を参照して、第 2の実施の形態における HTML文書の処理を一層具体的に説明する。送信側 100では、ホームページソースから取り出された HTML文書 2aについて、まずタグ抽出 S11と属性パラメータ抽出 S21とが施される。図 13の上段（暗号化前）に、 HTML文書 2aを例示した。但し、図 13で HTML文書 2aのヘッダ部分は省略する。タグ抽出 S11では、開始タグとそれに対応する終了タグを検知し、それらの間の部分をタグ内容と判定する。属性パラメータ抽出 S21では、開始タグとそれに対応する終了タグの間に = "があれば、 = "とその終了タグの間の部分を属性パラメータとして抽出する。例えば、く A HREF= FILENAME.HTML > く/ A〉という文については、そのうち FILENAME.HTMじ〉が属性パラメータであり、く A HREF二" HTTP：〃 UR じ〉……く/ A〉という文については、そのうち HTTP：〃 URじ'〉……が属性パラメータである。また、空要素タグについては、 = "を含んでいれば、 = "と〉の間の部分を属性パラメータとして抽出する。例えば、 <IMG

では、 FILENAME.gifが属性パラメータである。タグ抽出 S11によりタグに挟まれたタグ内容のデータ範囲が分かるので、そのデータ範囲をタグ内容と判定し、タグ内容の暗号化 S12を XOR演算方式で行う。このタグ内容の暗号化 S12により生成した暗号化タグ内容に MIME64符号変換 S13を施し、 MIME64符号変換暗号化タグ内容を生成す

[0041] 一方、属性パラメータ抽出 S21で抽出した属性パラメータについても、タグ内容と同様に属性パラメータの暗号化 S22および MIME64符号変換 S23を施し、符号変換暗号化属性パラメータを生成する。 MME64による符号変換がされた暗号化タグ内容はタグで挟まれ、これと MIME64による符号変換がされた暗号化属性パラメータは、 HTML 文書 4aにお!/、て暗号化されずに平文のまま残された部分 (タグ及びその他のデータ）と連結され、部分暗号化 HTML文書 2bが生成される。図 13の下段（暗号化後）に、その上段の HTML文書について部分暗号化をした部分暗号化 HTML文書 2bを例示した。但し、図 13で部分暗号化 HTML文書 2bのヘッダ部分は省略する。部分暗号化 H TML文書 2bは、伝送路で伝送される。

[0042] 受信側 200で受信された部分暗号化 HTML文書 2bは、部分暗号化 HTML文書 2cと称することとする。部分暗号化 HTML文書 2cについて、まずタグ抽出 S31及び符号変換暗号化属性パラメータ抽出 S41がなされる。部分暗号化 HTML文書 2cの暗号化部分には、 MIME64符号化されたデータであるから、タグと同一又はタグの一部と見間違うデータは含まれないので、タグ抽出 S31において、部分暗号化 HTML文書 2cにおけるタグは誤りなく抽出される。タグ抽出 S31により抽出されたタグに挟まれたタグ内容は、逆符号変換 S32において逆 MIME64符号化が施され、元の暗号化タグ内容に変換される。この暗号化タグ内容は、タグ内容の復号 S33により、復号される。

[0043] 一方符号変換暗号化属性パラメータ抽出 S41において、タグ抽出 S31と同様に、誤りなく符号変換暗号化属性パラメータが抽出される。以下、逆符号変換 S42及び属性ノラメータの復号 S43により、タグ内容と同様に、属性パラメータが復号される。タグ内容の復号 S33で復号化されたタグ内容及び属性パラメータの復号 S43で復号された属性パラメータは、部分暗号化 HTML文書 2cにおける平文部分 (タグ及びその他のデータ）と連結され、 HTML文書 2dが再生される。

[0044] 力、くして、図 12の処理により、送信側の HTML文書 4aと同じ内容の HTML文書 2dが再生されたので、第 2の実施の形態では、図 10の第 1の実施の形態における HTTP ヘッダと本文との連結と同様に、 HTTPヘッダと HTML文書 2dを連結し、元のホームべージソースを再生する。

なお、以上には実施の形態を挙げ、本発明を説明したが、本発明はこの実施の形態に限られるものではない。

Claims

請求の範囲

[1] HTTPに則るメッセージソース又はホームページソースの少なくとも一方であって、固定メッセージを含むソースデータを送受信する通信方式において、

前記固定メッセージを除く部分だけを暗号化して、該ソースデータを送信することを特徴とする通信方式。

[2] HTTPに則るメッセージソース又はホームページソースの少なくとも一方を含むソースデータを送受信する通信方式にぉレ、て、

送信側は、前記ソースデータにおける固定メッセージを除くメッセージ内の少なくとも一部分のメッセージの暗号化により暗号文を生成し、該一部分以外の該ソースデ一タに該暗号文を連結した部分暗号化ソースデータを生成し、該部分暗号化ソースァータを送 1Sし、

受信側は、前記部分暗号化ソースデータを受信し、該部分暗号化ソースデータにおける前記暗号文の復号により前記一部分を復元し、該一部分以外の前記部分喑号化ソースデータと該一部分とを連結し、前記ソースデータを再生することを特徴とする通信方式。

[3] 前記ソースデータは、 HTTPヘッダ及びメール本文でなるメッセージソースであり、前記暗号文は前記メール本文を暗号化したものである

ことを特徴とする請求項 2に記載の通信方式。

[4] 前記ソースデータは、 HTTPヘッダと HTML文書とを含むホームページソースであり前記送信側は、前記 HTML文書に含まれるタグ及び属性パラメータを抽出し、該 H TML文書における該タグ内容の暗号化により暗号化タグ内容を生成するとともに、前記属性パラメータの暗号化により暗号化属性パラメータを生成し、該暗号化タグ内容および該暗号化属性パラメータを、 MME64その他のタグを含まな!/、符号に変換することにより、符号変換暗号化タグ内容および符号変換暗号化属性パラメータを生成し、前記タグ内容及び前記属性パラメータ以外の前記 HTML文書に該符号変換暗号化内タグ内容および符号変換暗号化属性パラメータを連結することにより、部分暗号化 HTML文書を生成し、前記 HTTPヘッダに該部分暗号化 HTML文書を連結し、該 H TTPヘッダ及び該部分暗号化 HTML文書を送信し、

受信側は、前記 HTTPヘッダ及び前記部分暗号化 HTML文書を受信し、該部分喑号化 HTML文書における前記符号変換暗号化タグ内容および前記符号変換暗号化属性パラメータを抽出し、抽出された該符号変換暗号化タグ内容および該符号変換暗号化属性パラメータに逆符号変換を施すことにより前記暗号化タグ内容及び前記暗号化属性パラメータを復元し、該暗号化タグ内容及び該暗号化属性パラメータの復号化により前記タグ内容及び前記属性パラメータを復元し、該部分暗号化 HTML 文書における該符号変換暗号化タグ内容および該符号変換暗号化属性パラメータ以外の部分に該タグ内容及び該属性パラメータを連結し、前記 HTML文書を再生する

ことを特徴とする請求項 2に記載の通信方式。