JP3819729B2 - データ安全化通信装置及びその方法 - Google Patents
データ安全化通信装置及びその方法 Download PDFInfo
- Publication number
- JP3819729B2 JP3819729B2 JP2001122610A JP2001122610A JP3819729B2 JP 3819729 B2 JP3819729 B2 JP 3819729B2 JP 2001122610 A JP2001122610 A JP 2001122610A JP 2001122610 A JP2001122610 A JP 2001122610A JP 3819729 B2 JP3819729 B2 JP 3819729B2
- Authority
- JP
- Japan
- Prior art keywords
- parameter
- data
- encryption
- input data
- range
- Prior art date
- Legal status (The legal status 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 status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/22—Arrangements for preventing the taking of data from a data transmission channel without authorisation
-
- 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
-
- 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/12—Applying verification of the received information
- H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
-
- 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/16—Implementing security features at a particular protocol layer
- H04L63/166—Implementing security features at a particular protocol layer at the transport layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
- Communication Control (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
この発明は、伝送データの傍受、改変などに対するデータの安全化、つまり暗号化、データ認証を行う通信装置及びその方法に関する。
【０００２】
【従来の技術】
インターネットに代表されるＩＰ（インターネットプロトコル）ネットワークには本来セキュリティ機能が備わっていない。何ら対策を施さない場合、途中経路におけるＩＰパケットの取得や改変などにより、通信の当事者に知られずに通信内容の傍受、改変が可能である。このため、ＩＰネットワーク上で商取引などの重要情報を送受信する場合には、いかにセキュリティ（安全性）を保つかが重要な課題となる。
【０００３】
例えば、音楽や映像をインターネット経由で配信するコンテンツ配信サービスでは、配信される音楽・映像データが価値をもった重要情報となり、途中経路における傍受、改変を防ぐ必要がある。また、ＩＰネットワークを介して電話サービスを提供するＶｏＩＰシステムにおいては、通話内容の不法な傍受を防ぐ必要がある。
ＶｏＩＰシステムやストリーム型コンテンツ配信システムにおいては、リアルタイム性（実時間性）が要求されるデータを伝送するために、ＲＴＰ／ＵＤＰが一般的に利用されている。ＲＴＰ（Realtime Transport Protocol）はアプリケーション層で用いられるプロトコルであり、実時間処理に適する。ＵＤＰ（User Datagram Protocol）はアプリケーション層とネットワーク層とのインターフェースであるトランスポート層に用いられるコネクションレスプロトコルである。ＲＴＰ／ＵＤＰでは、ＴＣＰ（Transmission Control Protocol、トランスポート層で用いられるコネクション型プロトコル）のようにパケットの確実な送達よりも、即時性のあるパケットの送達を目的としているため、途中経路でパケットロス（紛失）が生じる可能性がある。このため、ＲＴＰ／ＵＤＰに適用するセキュリティ技術を検討する際には、パケットロスに対する対策が必要となる。
【０００４】
また、現在急速に普及している移動通信への適用も重要である。移動通信網でＲＴＰ／ＵＤＰパケット伝送を行う際には、無線伝送帯域の利用効率改善のために、無線リンクにおいてＲＴＰパケット及びＵＤＰパケットの両ヘッダは対ヘッド圧縮が適用される。従って、セキュリティ技術、特に暗号化方式を検討する際には途中のリンクにおけるＲＴＰ／ＵＤＰパケットのヘッダ圧縮が可能である方式が望まれる。
移動通信網への適用を前提としたＲＴＰパケットのセキュア（安全）な伝送方式として、ＩＥＴＦ（インターネット標準化推進団体）においてＳｅｃｕｒｅ ＲＴＰ（ＳＲＴＰ、参照：draft-ictf-avt-srtp-00.txt）が提案されている。ＳＲＴＰでは、ヘッダ圧縮を適用可能とするための選択的暗号化やパケットロスやビット誤りの影響が少ない暗号化方式などが導入されている。つまりＲＴＰパケットに対し、図１１に示すように、ＲＴＰヘッダを除き、ＲＴＰペイロードの部分だけを暗号化し、この暗号化されたＲＴＰペイロードとＲＴＰヘッダに対して、データ認証コード（認証子）を生成し、これを付加して、ＲＴＰヘッダと暗号化ＲＴＰペイロードのデータの正当性を検証可能にしている。このため、効率的な保護が可能であるが、その一方ＲＴＰに特化した技術となっている。つまりＳｅｃｕｒｅ ＲＴＰを使用する場合は図１２Ｂに示すように、ＲＴＰに特化した暗号化アルゴリズム暗号化パラメータが用いられるため、他のＵＤＰ上のアプリケーション、トランスポートプロトコルにそのＳｅｃｕｒｅ ＲＴＰを用いることはできない。選択的暗号化パラメータ、暗号化アルゴリズムが固定であり、新規プロトコルに対応できない他の技術進歩の早いコンテンツ配信には適さない。このようにあるアプリケーションに特化したセキュリティ技術は、新規アプリケーションが開発される度に個別のセキュリティ技術を検討する必要があり、好ましくない。また、安全性技術は永久的ではないためＳｅｃｕｒｅ ＲＴＰは暗号化アルゴリズムなども固定であり、セキュリティ上問題がある。
【０００５】
一方、インターネットで広く利用されているセキュリティ技術としてＳＳＬ（Secure Socket Layer）（ＴＳＬ）がある。つまりＳＳＬ（ＴＳＬ）を使用しない状態では図１３Ａに示すようにアプリケーション層におけるＨＴＴＰ（Hypertext transfer Protocol）、ＦＴＰ（File Transfer Protocol）、Telnet（遠隔ログイン）などのアプリケーション層とＴＣＰ又はＵＤＰのトランスポート層とが直接接続される。図１３Ｂに示すようにＳＳＬは、ＴＣＰやＵＤＰなどのトランスポート層とアプリケーション層との間に位置するセキュリティプロトコルである。ＳＳＬは、ＴＣＰやＵＤＰが提供するデータ伝送機能を利用して送受信されるデータに何らかのセキュリティ処理を施すことで、アプリケーション層に対してセキュアなデータ伝送サービスを提供する。このため、利用できるアプリケーション、暗号化アルゴリズムが限定されないという特徴を備える。ＳＳＬは、特にＷｅｂアクセスで使用されるＨＴＴＰセッションを保護するために広く用いられているが、ＦＴＰやＴｅｌｎｅｔなど他のアプリケーションにも汎用的に利用できる。また、ＳＳＬを移動通信用に修正したものとして、ＷＡＰ Ｆｏｒｕｍで規格化されたＷＴＳＬがある。
【０００６】
ＳＳＬやＷＴＳＬは、図１４に示すように大きく分けて２層構造になっている。この２層中の下位層で使用されるプロトコルはレコードプロトコル（Record Protocol）と呼ばれており、上位層のプロトコルのデータを暗号化する機能およびデータ認証コード（ＭＡＣ）を付加する機能を提供する。ＳＳＬの２層構造中の上位層にはハンドシェークプロトコル（Handshake Protocol）、アラートプロトコル（Alert Protocol）、チェンジサイファプロトコル（Change Cipher Protocol）、アプリケーションデータプロトコル（Application Data Protocol）の４種類が含まれる。ハンドシェークプロトコルは暗号化・データ認証方式のネゴシエーション機能および端末・サーバの認証機能を有し、アラートプロトコルはイベントやエラーの通知機能を有し、チェンジサイファプロトコルはネゴシエーションした暗号化・認証方式を有効にする機能を有する、つまり暗号通信の開始を相手に通知する。アプリケーションデータプロトコルは、上位のアプリケーションデータを透過的に送受信するものであり、ＨＴＴＰやＦＴＰなどのデータはこのプロトコルを介してレコードプロトコル（Record Protocol）に受け渡される。
【０００７】
図１５に送信側と受信側のレコードプロトコル（Record Protocol）間で送受信されるデータ構造の例を示す。ヘッダ１０には上位プロトコル種別（ハンドシェーク、アラート、アプリケーションデータなど）を示す識別子（Protocol type）１１、ＳＳＬのバージョン（Major Version、Minor Version）１２、データ長（Length(high)、Length(low)）１３が、ペイロードには暗号化された上位プロトコルのデータ１４が含まれている。暗号化データ１４中はデータ本体（Content）とこのデータ本体及びヘッダの正当性検証用認証子ＭＡＣが含まれている。この構造はレコードプロトコルを利用するプロトコル全てに適用されるものであり、アプリケーションプロトコルも例外ではない。従って、ＳＳＬを利用してＲＴＰパケットを伝送する場合には、ＲＴＰパケットのヘッダ及びペイロードの全体が暗号化されて、レコードプロトコルデータのペイロード１４にマッピングされる事となる。
【０００８】
このように、ＲＴＰパケット全体を暗号化したものに、もしくはＲＴＰパケットにレコードプロトコルのヘッダを付加した場合、途中経路におけるＲＴＰヘッダ圧縮の適用が不可能になる。つまりヘッダ圧縮は、連続して設けられているＲＴＰヘッダとＵＤＰヘッダとＩＰヘッダとを一括して行うため、ＲＴＰヘッダとＵＤＰヘッダとの間にレコードプロトコルヘッダ１０が挿入されていると、これらを一括してデータ圧縮することができなくなる。このため、ＳＳＬ／ＷＴＳＬをＲＴＰパケットの保護に適用することは、移動通信においては望ましくない。
【０００９】
【発明が解決しようとする課題】
また一般のデータの通信においても、特に安全にしたい部分に対してのみ、暗号化や正当性を検証できる認証を付けるなどの安全性を施して通信することができれば、便利であるが、その安全性を適応的に付けることは困難であった。
この発明の目的は入力データの一部にのみ選択的に安全性を施して通信することを可能にするデータ安全化通信装置及びその方法を提供することにある。
【００１０】
【課題を解決するための手段】
この発明によれば、入力データの安全化対象を示すパラメータを相手のデータ安全化通信装置と通信路を介して共有し、この共有されたパラメータに従って入力データの一部を選択的に安全化して出力する。
【００１１】
【発明の実施の形態】
第１実施形態
図１にこの発明の第１実施形態を示すと共にその実施形態を用いたデータ伝送システムの概観を示す。
例えばサーバやデータ端末などのこの発明による送信側のデータ安全化通信装置２１と、同様にサーバやデータ端末などのこの発明による受信側のデータ安全化通信装置２２とが通信網２３を通じて接続することができる。通信網２３は１つの網として示しているが、公衆通信網とインターネット網とが組合された網など、複数網から構成されていてもよい。
【００１２】
データ安全化通信装置２１はアプリケーション部３１とトランスポート部３２との間にこの実施形態では安全化手段として暗号化・認証子付加部３３が設けられる。またトランスポート部３２の上位層としてパラメータ共有部３４が設けられる。トランスポート部３２はＴＣＰやＵＤＰ機能を有し、例えばＩＰ機能を有するネットワーク部３５と接続され、ネットワーク部３５は物理層である送受信部３６に接続され、送受信部３６は通信網２３と接続される。
データ安全化通信装置２２もデータ安全化通信装置２１とほぼ同様に構成され、つまりアプリケーション部４１、トランスポート部４２、ネットワーク部４５及び送受信部４６を備え、この実施形態では安全化手段として復号化・検証部４３が設けられまたトランスポート部４２の上位層としてパラメータ共有部４４が設けられる。
【００１３】
通信装置２１はアプリケーション部３１からのアプリケーションデータの送信に先立ち、データ安全化に必要なパラメータ、つまり暗号化処理・データ認証子（コード）生成処理に必要なパラメータを通信相手の装置２２と交渉して、これらのパラメータを相手通信装置２２と共有する。このパラメータは、例えば図２に示すように、暗号化アルゴリズムをＮｕｌｌ、ＤＥＳ、３ＤＥＳ、ＲＣ４などの何れにするか、データ認証子生成アルゴリズムをＭＤ５、ＳＨＡなどの何れにするか、鍵を生成するために用いる秘密情報、通信装置２１（例えばサーバ側装置）及び通信装置２２（例えばクライアント側装置）における暗号化・復号化あるいは認証・検証に用いるランダム値、送信データ中の暗号化する範囲、データ認証する範囲などである。この実施形態では特にこの共有するパラメータとして暗号化範囲及びデータ認証範囲を新たに設けた点が重要であり、他のパラメータを共有することは、従来のＳＳＬ（ＴＳＬ）による安全化プロトコルで用いられる共有パラメータと同様のものであり、またこれらパラメータの共有は、従来のＳＳＬと同様に通信路を介して、通信装置２１と２２が相互に通信して行う。
【００１４】
ここで新たに用いる共有パラメータである、伝送すべきデータの安全化対象を示すパラメータ、この例では暗号化範囲及びデータ認証範囲は、入力データパケット（この例ではアプリケーション部３１よりのデータパケット）のどの範囲を暗号化、認証するかを決定するための情報であり、様々な指定方法が考えられるが、例えば「パケット先頭の何バイト目から暗号化を開始する」などにより指定する。
更にこの暗号化範囲、データ認証範囲の決定は入力データの種別、つまりこの例ではアプリケーションに応じて、あるいは通信装置２１が接続された通信網２３の伝送特性（伝送速度、遅延特性、伝送誤り特性、減衰特性、周波数特性、歪特性など）に応じて決定される。
【００１５】
通信装置２１のパラメータ共有部３４では、例えば図３に示す手順により安全化対象を示すパラメータを共有決定する。暗号化通信要求を受信すると（Ｓ１）、入力データアプリケーションパケットがＲＴＰパケットであるかを調べ（Ｓ２）、ＲＴＰパケットであれば、装置２１が接続されている通信網２３が伝送速度が低い網、例えば移動通信網であるかを調べ（Ｓ３）、移動通信網であれば、ＲＴＰパケットを選択的に暗号化すること、例えば入力データ先頭のＲＴＰヘッダを暗号化対象外とすることを示す暗号化・認証パラメータを相手通信装置２２へ送信する（Ｓ４）。なおこの際に暗号化アルゴリズム、データ認証子生成アルゴリズムなど他のパラメータも送信する。
【００１６】
一方相手通信装置２２のパラメータ共有部４４では例えば図４に示すように通信装置２１から暗号化・認証パラメータを受信すると（Ｓ１）、受信した通信相手の暗号化・認証パラメータがＲＴＰパケット選択的暗号化であるかを調べ（Ｓ２）、そうであれば、パラメータ共有部４４における暗号化・認証パラメータをＲＴＰパケット選択的暗号化に決定し（Ｓ３）、その決定した暗号化・認証パラメータを通信装置２１へ送信する（Ｓ４）。
通信装置２１のパラメータ共有部３４では、図３に示すように通信装置２２からＲＴＰパケット選択的暗号化を示す暗号化・認証パラメータを受信すると（Ｓ５）、暗号化・認証パラメータをＲＴＰパケット選択的暗号化に決定する（Ｓ６）。このようにして両パラメータ共有部３４，４４において暗号化・認証パラメータとしてＲＴＰパケット選択的暗号化が通信路を介して共有される。なお暗号化アルゴリズムなど他のパラメータも同様にして同時に決定される。この場合、例えば従来のＳＳＬなどと同様に、各パラメータについていくつかの候補を送って、相手装置２２により決定してもらう。
【００１７】
図３において、ステップＳ２で入力データがＲＴＰパケットでないと判定され、あるいはステップＳ３で通信装置２１が接続されている通信網２３の伝送速度が高いと判定された場合は、この例では入力データ（パケット）全体を暗号化する、つまり非選択的暗号化を示す暗号化・認証パラメータを相手通信装置２２へ送信する（Ｓ７）。
通信装置２２のパラメータ共有部４４では図４に示すように、ステップＳ２で受信した通信相手の暗号化・認証パラメータがＲＴＰパケット選択的暗号化でないと判定されると、通信装置２２のアプリケーション部４１からの入力データ（アプリケーション）がＲＴＰパケットであるかを判断し（Ｓ５）、ＲＴＰパケットであれば、通信装置２２が接続された通信網２３が伝送速度の低い、例えば移動通信網であるかを調べ（Ｓ６）、そうであれば、ステップＳ３に移り、ＲＴＰパケット選択的暗号化を表わす暗号化・認証パラメータを決定して、これを通信装置２１へ送信する（Ｓ４）。ステップＳ５で入力データがＲＴＰパケットではないと判定され、あるいはステップＳ６で接続されている通信網２３の伝送速度が低くない移動通信網ではないと判定されると（Ｓ６）、非選択的暗号化を表わす暗号化・認証パラメータを決定して（Ｓ７）、相手通信装置２１へ送信する（Ｓ４）。
【００１８】
通信装置２１のパラメータ共有部３４では図３に示すように、ステップＳ７の送信後、相手通信装置２２から暗号化・認証パラメータを受信すると（Ｓ８）、その受信暗号化・認証パラメータがＲＴＰパケット選択的暗号化であるかを調べ（Ｓ９）、そうであればステップＳ６に移り、暗号化・認証パラメータを、ＲＴＰパケット選択的暗号化に決定し、ＲＴＰパケット選択的暗号化でなければ暗号化・認証パラメータを非選択的暗号化に決定する（Ｓ１０）。
このようにしてパラメータ共有部３４と４４は通信路を介して暗号化範囲を共有することができる。認証範囲は入力データ（アプリケーション）にかかわらず、また通信装置２１，２２がそれぞれ接続されている通信網２３の伝送特性に係わらず、入力データの全体とする。暗号化範囲としてはヘッダを除くか否かのみならず、暗号化範囲、認証範囲としては入力データが画像や音声である場合に、その重要部のみとすることもできる。この場合、例えばこれらデータの符号化の際に欠落すると復号が不可能となる重要なコードのみを自動的に暗号化するように指示することもできる。何れの場合も、暗号化アルゴリズムなど他のパラメータも、前記暗号化範囲の共有と同時に共有する処理を行う。
【００１９】
以上のようにしてパラメータが共有されると、共有された各種パラメータはパラメータ共有部３４，４４からそれぞれ暗号化・認証子付加部３３、復号化・検証部４３へ供給される。
暗号化・認証子付加部３３において暗号化・認証子付加の処理が行われる。その手順の例を図５に示す。上位アプリケーション部３１からデータパケットが入力されると（Ｓ１）、アプリケーションデータプロトコルにより、透過的に暗号化・認証子付加部３３に入力され（Ｓ２）、このデータパケットのうち認証範囲パラメータに従って選択された部分を用いて共有した認証子生成アルゴリズム・認証子生成用鍵により認証子を生成する（Ｓ３）。認証子生成方法は、例えば、今井秀樹著「暗号のおはなし」４．７節に詳しい。例えばハッシュ関数により認証範囲データを圧縮し、圧縮データを共通鍵で暗号化することにより生成する。その後、入力されたデータパケットに認証子を付加し（Ｓ４）、この認証子付データパケットに対し、暗号範囲パラメータに基づいて選択部分の暗号化を共有した暗号アルゴリズム、暗号鍵を用いて施す（Ｓ５）。なおブロック暗号化を行う場合は、その固定ブロック長にデータが不足した場合に埋め合せるパディングを暗号化の前に行う（Ｓ６）。
【００２０】
このようにして暗号化されたデータ構造の例を図６に示す。この例では入力されたアプリケーションデータに対し、認証子ＭＡＣが付加され、アプリケーションデータ中のヘッダを除いた部分（ペイロード）と認証子とが暗号化されている。この選択的暗号化を含むデータは下位のトランスポート部３２に受け渡され相手通信装置２２へ伝送される。
受信側通信装置２２では、上記の逆の手順を用いて暗号化されたデータを復号し、データ認証子（コード）を利用して受信データの正当性を検証する。つまり図１中の通信装置２２において、通信装置２１から受信したパケットはトランスポート部４２より復号化・検証部４３に入力され、復号化・検証部４３で共有した暗号化アルゴリズム、暗号化鍵、暗号化範囲に従って、この暗号化された部分が選択的に復号化され、この復号されたデータ中のデータ認証子（コード）ＭＡＣを用いて、ヘッダ及び復号化されたペイロード、つまり図６中のアプリケーションデータの正当性の検証を行う。正当であれば、このアプリケーションデータをアプリケーション部４１へ供給する。
【００２１】
このように暗号化範囲を共有することにより、入力データ中の一部を選択的に暗号化することができ、例えば安全性が問題になる部分のみを暗号化することにより、全体を暗号化する場合よりも処理量が少なくて済み、しかも、安全性が問題になるおそれがない。暗号化範囲は、暗号化のための他のパラメータを共有する処理と同時に行うことができ、このための処理の増加はわずかである。
特に前記例のように入力データ（アプリケーション）がＲＴＰパケットの場合で、そのＲＴＰパケットのヘッダ部分を暗号化しない領域とする場合は、このヘッダにＵＤＰパケットヘッダ、ＩＰパケットヘッダが付加されることになり、Ｓｅｃｕｒｅ ＲＴＰ同様に、途中経路における、ＲＴＰパケットヘッダを含めたヘッダ圧縮に対応可能である。また、Ｓｅｃｕｒｅ ＲＴＰとは異なり、暗号化領域は通信相手との交渉によりセッション開始時に設定可能であるため、ＲＴＰパケット以外のアプリケーションにも汎用的に対応可能である。
【００２２】
図５では、認証子付加後に暗号化を行ったが、図７に示すように暗号化後に認証子を生成し、暗号化されたパケットに認証子を付加しても良い。この場合、受信側では、受信データの正当性を検証した後、暗号の復号化を行うことになる。
以上の選択的安全化処理の流れは図８に示すようにデータが入力されると（Ｓ１）、入力データの安全化対象を示すパラメータを相手通信装置と通信路を介して共有し（Ｓ２）、その共有した安全化対象パラメータに従って入力データの一部に対して安全化処理を行って（Ｓ３）、相手装置へ送信する（Ｓ４）。
第２実施形態
図９にこの発明の第２実施形態を示す。これは図１４に示したＳＳＬを拡張して選択的暗号化をサポート可能としたものである。第１実施形態におけるパラメータ共有部３４はさらに相手通信装置２２と認証処理や暗号化・データ認証パラメータを交渉するハンドシェーク（Handshake）部３４ａ、暗号化・データ認証パラメータを有効化するチェンジサイファ（Change Cipher）部３４ｂ、イベント・エラーを通知するアラート（Alert）部３４ｃ、そして、トランスポート部３２を介して上記３つの各部３４ａ，３４ｂ，３４ｃのプロトコルデータを送受信するための第１レコード（Record）部３４ｄからなる。第１レコード部３４ｄのプロトコルデータフォーマットにはＳＳＬのＮレコード部と同じフォーマットを利用する。ハンドシェーク部３４ａでは、第１レコード部３４ｄおよび第２レコード部、つまり暗号化・認証子付加部３３で利用する暗号化・データ認証パラメータを相手通信装置２２と交渉して共有する。またチェンジサイファ（Change Cipher）部３４ｂは第１レコード部３４ｄおよび第２レコード部３３の暗号化・データ認証パラメータを有効化する。つまりその暗号化を開始させて相手に通知する。第１レコード部３４ｄには、ハンドシェーク部３４ａのプロトコルメッセージや選択的暗号化が不要なアプリケーションのデータが入力される。
【００２３】
選択的暗号化が必要なアプリケーションデータの送受信は、上記のプロトコルデータとは別に第２レコード部、つまり暗号化・認証子付加部３３で送受信される。第２アプリケーションデータ部３８は上位の第２アプリケーション部３１ｂのデータパケットを透過的に第２レコード部３３に受け渡すためのものである。また、第１レコード部３４ｄと異なり、第２レコード部、つまり暗号化・認証子付加部３３では入力データに対して新たなヘッダは追加せず、暗号化・認証子生成処理のみを施す。第１レコード部３４ｄで共有されたパラメータは第２レコード部３３の暗号化・データ認証処理に利用される。暗号化・データ認証処理は第１実施形態と同様である。
【００２４】
パラメータ共有部３４のハンドシェーク部３４ａによる相手通信装置とのパラメータ共有処理は最初は平文で通信を行うが、途中からは図１５に示したデータ構造により、暗号化・認証子付加を行って、これらパラメータの共有に対しても安全化してもよい。またアプリケーションでもＲＴＰパケットのように実時間性が要求されない、頻繁に送られない、ＨＴＴＰ，ＦＴＰ，Ｔｅｌｎｅｔ，ＲＴＳＰ（ＲＴＰのセッションを開くためのプロトコル）などのアプリケーションデータパケットは第１アプリケーション部３１ａより第１アプリケーションデータ部３７へ通じて第１レコード部３４ｄに入力して、これらに対しては、共有したパラメータにより暗号化をそのパケット全体に対して行い、図１５に示したようにレコード部のヘッダ１０を付けてレコードプロトコルパケットとしてトランスポート部３２へ供給する。なお相手側装置２２においては図９中の第２レコード部である暗号化・認証子付加部３３が、復号化・検証部になり、他は同様の構成である。
第３実施形態
図１０は、この発明の第３実施形態を示す。この実施形態では、ＲＴＳＰやＨＴＴＰなどの第１アプリケーション部３１ａを介してＲＴＰなど第２アプリケーション部３１ｂのアプリケーションデータに対して適用される暗号化・認証子付加パラメータを共有するための通信相手との交渉をする。例えば、図２の暗号化パラメータを相手通信装置２２の公開鍵で暗号化して、プロトコルメッセージボディに埋め込むことで相手通信装置２２に伝送することができる。
【００２５】
１つの通信装置に暗号化・認証子付加部と復号化・検証部を合せもたせてもよい。 上述においてはデータに対する安全化として暗号化と、データ認証子付加との両者を用いたが、その一方のみを用いてもよい。通信装置２１，２２の各部をコンピュータにプログラムを実行させて機能させてもよい。
【００２６】
【発明の効果】
以上説明したように、この発明によればデータの一部を選択的に安全化を施すことができ、かつ特定のアプリケーションに依存しない汎用的な伝送データ保護が可能であり、しかも特に移動通信に適用すればヘッダ圧縮も可能である。
【図面の簡単な説明】
【図１】この発明装置の実施形態の機能構成及びこの発明装置が用いられるシステム構成例を示す図。
【図２】暗号化パラメータの例を示す図。
【図３】送信側における暗号範囲共有処理手順の例を示す流れ図。
【図４】受信側における暗号範囲共有処理手順の例を示す流れ図。
【図５】図１中の暗号化・認証子付加部３３の処理手順の例を示す流れ図。
【図６】図１中の暗号化・認証子付加部３３の出力パケットのデータ構造の例を示す図。
【図７】暗号化・認証子付加部３３の処理手順の他の例を示す流れ図。
【図８】この発明の方法の処理手順の例を示す流れ図。
【図９】この発明装置の第２実施形態の機能構成を示す図。
【図１０】この発明装置の第３実施形態の機能構成を示す図。
【図１１】選択的暗号化されたパケットのデータ構造を示す図。
【図１２】ＡはＳｅｃｕｒｅ ＲＴＰを使用しない処理を示す図、ＢはＳｅｃｕｒｅ ＲＴＰを使用する時の処理を示す図である。
【図１３】ＡはＳＳＬ／ＷＴＬＳを使用しないアプリケーションデータの処理を示す図、ＢはＳＳＬ／ＷＴＬＳを使用する場合の処理を示す図である。
【図１４】ＳＳＬ／ＷＴＬＳレイヤの詳細を示す図。
【図１５】ＳＳＬ／ＷＴＬＳにより処理されたレコードプロトコルデータの構造を示す図。
【発明の属する技術分野】
この発明は、伝送データの傍受、改変などに対するデータの安全化、つまり暗号化、データ認証を行う通信装置及びその方法に関する。
【０００２】
【従来の技術】
インターネットに代表されるＩＰ（インターネットプロトコル）ネットワークには本来セキュリティ機能が備わっていない。何ら対策を施さない場合、途中経路におけるＩＰパケットの取得や改変などにより、通信の当事者に知られずに通信内容の傍受、改変が可能である。このため、ＩＰネットワーク上で商取引などの重要情報を送受信する場合には、いかにセキュリティ（安全性）を保つかが重要な課題となる。
【０００３】
例えば、音楽や映像をインターネット経由で配信するコンテンツ配信サービスでは、配信される音楽・映像データが価値をもった重要情報となり、途中経路における傍受、改変を防ぐ必要がある。また、ＩＰネットワークを介して電話サービスを提供するＶｏＩＰシステムにおいては、通話内容の不法な傍受を防ぐ必要がある。
ＶｏＩＰシステムやストリーム型コンテンツ配信システムにおいては、リアルタイム性（実時間性）が要求されるデータを伝送するために、ＲＴＰ／ＵＤＰが一般的に利用されている。ＲＴＰ（Realtime Transport Protocol）はアプリケーション層で用いられるプロトコルであり、実時間処理に適する。ＵＤＰ（User Datagram Protocol）はアプリケーション層とネットワーク層とのインターフェースであるトランスポート層に用いられるコネクションレスプロトコルである。ＲＴＰ／ＵＤＰでは、ＴＣＰ（Transmission Control Protocol、トランスポート層で用いられるコネクション型プロトコル）のようにパケットの確実な送達よりも、即時性のあるパケットの送達を目的としているため、途中経路でパケットロス（紛失）が生じる可能性がある。このため、ＲＴＰ／ＵＤＰに適用するセキュリティ技術を検討する際には、パケットロスに対する対策が必要となる。
【０００４】
また、現在急速に普及している移動通信への適用も重要である。移動通信網でＲＴＰ／ＵＤＰパケット伝送を行う際には、無線伝送帯域の利用効率改善のために、無線リンクにおいてＲＴＰパケット及びＵＤＰパケットの両ヘッダは対ヘッド圧縮が適用される。従って、セキュリティ技術、特に暗号化方式を検討する際には途中のリンクにおけるＲＴＰ／ＵＤＰパケットのヘッダ圧縮が可能である方式が望まれる。
移動通信網への適用を前提としたＲＴＰパケットのセキュア（安全）な伝送方式として、ＩＥＴＦ（インターネット標準化推進団体）においてＳｅｃｕｒｅ ＲＴＰ（ＳＲＴＰ、参照：draft-ictf-avt-srtp-00.txt）が提案されている。ＳＲＴＰでは、ヘッダ圧縮を適用可能とするための選択的暗号化やパケットロスやビット誤りの影響が少ない暗号化方式などが導入されている。つまりＲＴＰパケットに対し、図１１に示すように、ＲＴＰヘッダを除き、ＲＴＰペイロードの部分だけを暗号化し、この暗号化されたＲＴＰペイロードとＲＴＰヘッダに対して、データ認証コード（認証子）を生成し、これを付加して、ＲＴＰヘッダと暗号化ＲＴＰペイロードのデータの正当性を検証可能にしている。このため、効率的な保護が可能であるが、その一方ＲＴＰに特化した技術となっている。つまりＳｅｃｕｒｅ ＲＴＰを使用する場合は図１２Ｂに示すように、ＲＴＰに特化した暗号化アルゴリズム暗号化パラメータが用いられるため、他のＵＤＰ上のアプリケーション、トランスポートプロトコルにそのＳｅｃｕｒｅ ＲＴＰを用いることはできない。選択的暗号化パラメータ、暗号化アルゴリズムが固定であり、新規プロトコルに対応できない他の技術進歩の早いコンテンツ配信には適さない。このようにあるアプリケーションに特化したセキュリティ技術は、新規アプリケーションが開発される度に個別のセキュリティ技術を検討する必要があり、好ましくない。また、安全性技術は永久的ではないためＳｅｃｕｒｅ ＲＴＰは暗号化アルゴリズムなども固定であり、セキュリティ上問題がある。
【０００５】
一方、インターネットで広く利用されているセキュリティ技術としてＳＳＬ（Secure Socket Layer）（ＴＳＬ）がある。つまりＳＳＬ（ＴＳＬ）を使用しない状態では図１３Ａに示すようにアプリケーション層におけるＨＴＴＰ（Hypertext transfer Protocol）、ＦＴＰ（File Transfer Protocol）、Telnet（遠隔ログイン）などのアプリケーション層とＴＣＰ又はＵＤＰのトランスポート層とが直接接続される。図１３Ｂに示すようにＳＳＬは、ＴＣＰやＵＤＰなどのトランスポート層とアプリケーション層との間に位置するセキュリティプロトコルである。ＳＳＬは、ＴＣＰやＵＤＰが提供するデータ伝送機能を利用して送受信されるデータに何らかのセキュリティ処理を施すことで、アプリケーション層に対してセキュアなデータ伝送サービスを提供する。このため、利用できるアプリケーション、暗号化アルゴリズムが限定されないという特徴を備える。ＳＳＬは、特にＷｅｂアクセスで使用されるＨＴＴＰセッションを保護するために広く用いられているが、ＦＴＰやＴｅｌｎｅｔなど他のアプリケーションにも汎用的に利用できる。また、ＳＳＬを移動通信用に修正したものとして、ＷＡＰ Ｆｏｒｕｍで規格化されたＷＴＳＬがある。
【０００６】
ＳＳＬやＷＴＳＬは、図１４に示すように大きく分けて２層構造になっている。この２層中の下位層で使用されるプロトコルはレコードプロトコル（Record Protocol）と呼ばれており、上位層のプロトコルのデータを暗号化する機能およびデータ認証コード（ＭＡＣ）を付加する機能を提供する。ＳＳＬの２層構造中の上位層にはハンドシェークプロトコル（Handshake Protocol）、アラートプロトコル（Alert Protocol）、チェンジサイファプロトコル（Change Cipher Protocol）、アプリケーションデータプロトコル（Application Data Protocol）の４種類が含まれる。ハンドシェークプロトコルは暗号化・データ認証方式のネゴシエーション機能および端末・サーバの認証機能を有し、アラートプロトコルはイベントやエラーの通知機能を有し、チェンジサイファプロトコルはネゴシエーションした暗号化・認証方式を有効にする機能を有する、つまり暗号通信の開始を相手に通知する。アプリケーションデータプロトコルは、上位のアプリケーションデータを透過的に送受信するものであり、ＨＴＴＰやＦＴＰなどのデータはこのプロトコルを介してレコードプロトコル（Record Protocol）に受け渡される。
【０００７】
図１５に送信側と受信側のレコードプロトコル（Record Protocol）間で送受信されるデータ構造の例を示す。ヘッダ１０には上位プロトコル種別（ハンドシェーク、アラート、アプリケーションデータなど）を示す識別子（Protocol type）１１、ＳＳＬのバージョン（Major Version、Minor Version）１２、データ長（Length(high)、Length(low)）１３が、ペイロードには暗号化された上位プロトコルのデータ１４が含まれている。暗号化データ１４中はデータ本体（Content）とこのデータ本体及びヘッダの正当性検証用認証子ＭＡＣが含まれている。この構造はレコードプロトコルを利用するプロトコル全てに適用されるものであり、アプリケーションプロトコルも例外ではない。従って、ＳＳＬを利用してＲＴＰパケットを伝送する場合には、ＲＴＰパケットのヘッダ及びペイロードの全体が暗号化されて、レコードプロトコルデータのペイロード１４にマッピングされる事となる。
【０００８】
このように、ＲＴＰパケット全体を暗号化したものに、もしくはＲＴＰパケットにレコードプロトコルのヘッダを付加した場合、途中経路におけるＲＴＰヘッダ圧縮の適用が不可能になる。つまりヘッダ圧縮は、連続して設けられているＲＴＰヘッダとＵＤＰヘッダとＩＰヘッダとを一括して行うため、ＲＴＰヘッダとＵＤＰヘッダとの間にレコードプロトコルヘッダ１０が挿入されていると、これらを一括してデータ圧縮することができなくなる。このため、ＳＳＬ／ＷＴＳＬをＲＴＰパケットの保護に適用することは、移動通信においては望ましくない。
【０００９】
【発明が解決しようとする課題】
また一般のデータの通信においても、特に安全にしたい部分に対してのみ、暗号化や正当性を検証できる認証を付けるなどの安全性を施して通信することができれば、便利であるが、その安全性を適応的に付けることは困難であった。
この発明の目的は入力データの一部にのみ選択的に安全性を施して通信することを可能にするデータ安全化通信装置及びその方法を提供することにある。
【００１０】
【課題を解決するための手段】
この発明によれば、入力データの安全化対象を示すパラメータを相手のデータ安全化通信装置と通信路を介して共有し、この共有されたパラメータに従って入力データの一部を選択的に安全化して出力する。
【００１１】
【発明の実施の形態】
第１実施形態
図１にこの発明の第１実施形態を示すと共にその実施形態を用いたデータ伝送システムの概観を示す。
例えばサーバやデータ端末などのこの発明による送信側のデータ安全化通信装置２１と、同様にサーバやデータ端末などのこの発明による受信側のデータ安全化通信装置２２とが通信網２３を通じて接続することができる。通信網２３は１つの網として示しているが、公衆通信網とインターネット網とが組合された網など、複数網から構成されていてもよい。
【００１２】
データ安全化通信装置２１はアプリケーション部３１とトランスポート部３２との間にこの実施形態では安全化手段として暗号化・認証子付加部３３が設けられる。またトランスポート部３２の上位層としてパラメータ共有部３４が設けられる。トランスポート部３２はＴＣＰやＵＤＰ機能を有し、例えばＩＰ機能を有するネットワーク部３５と接続され、ネットワーク部３５は物理層である送受信部３６に接続され、送受信部３６は通信網２３と接続される。
データ安全化通信装置２２もデータ安全化通信装置２１とほぼ同様に構成され、つまりアプリケーション部４１、トランスポート部４２、ネットワーク部４５及び送受信部４６を備え、この実施形態では安全化手段として復号化・検証部４３が設けられまたトランスポート部４２の上位層としてパラメータ共有部４４が設けられる。
【００１３】
通信装置２１はアプリケーション部３１からのアプリケーションデータの送信に先立ち、データ安全化に必要なパラメータ、つまり暗号化処理・データ認証子（コード）生成処理に必要なパラメータを通信相手の装置２２と交渉して、これらのパラメータを相手通信装置２２と共有する。このパラメータは、例えば図２に示すように、暗号化アルゴリズムをＮｕｌｌ、ＤＥＳ、３ＤＥＳ、ＲＣ４などの何れにするか、データ認証子生成アルゴリズムをＭＤ５、ＳＨＡなどの何れにするか、鍵を生成するために用いる秘密情報、通信装置２１（例えばサーバ側装置）及び通信装置２２（例えばクライアント側装置）における暗号化・復号化あるいは認証・検証に用いるランダム値、送信データ中の暗号化する範囲、データ認証する範囲などである。この実施形態では特にこの共有するパラメータとして暗号化範囲及びデータ認証範囲を新たに設けた点が重要であり、他のパラメータを共有することは、従来のＳＳＬ（ＴＳＬ）による安全化プロトコルで用いられる共有パラメータと同様のものであり、またこれらパラメータの共有は、従来のＳＳＬと同様に通信路を介して、通信装置２１と２２が相互に通信して行う。
【００１４】
ここで新たに用いる共有パラメータである、伝送すべきデータの安全化対象を示すパラメータ、この例では暗号化範囲及びデータ認証範囲は、入力データパケット（この例ではアプリケーション部３１よりのデータパケット）のどの範囲を暗号化、認証するかを決定するための情報であり、様々な指定方法が考えられるが、例えば「パケット先頭の何バイト目から暗号化を開始する」などにより指定する。
更にこの暗号化範囲、データ認証範囲の決定は入力データの種別、つまりこの例ではアプリケーションに応じて、あるいは通信装置２１が接続された通信網２３の伝送特性（伝送速度、遅延特性、伝送誤り特性、減衰特性、周波数特性、歪特性など）に応じて決定される。
【００１５】
通信装置２１のパラメータ共有部３４では、例えば図３に示す手順により安全化対象を示すパラメータを共有決定する。暗号化通信要求を受信すると（Ｓ１）、入力データアプリケーションパケットがＲＴＰパケットであるかを調べ（Ｓ２）、ＲＴＰパケットであれば、装置２１が接続されている通信網２３が伝送速度が低い網、例えば移動通信網であるかを調べ（Ｓ３）、移動通信網であれば、ＲＴＰパケットを選択的に暗号化すること、例えば入力データ先頭のＲＴＰヘッダを暗号化対象外とすることを示す暗号化・認証パラメータを相手通信装置２２へ送信する（Ｓ４）。なおこの際に暗号化アルゴリズム、データ認証子生成アルゴリズムなど他のパラメータも送信する。
【００１６】
一方相手通信装置２２のパラメータ共有部４４では例えば図４に示すように通信装置２１から暗号化・認証パラメータを受信すると（Ｓ１）、受信した通信相手の暗号化・認証パラメータがＲＴＰパケット選択的暗号化であるかを調べ（Ｓ２）、そうであれば、パラメータ共有部４４における暗号化・認証パラメータをＲＴＰパケット選択的暗号化に決定し（Ｓ３）、その決定した暗号化・認証パラメータを通信装置２１へ送信する（Ｓ４）。
通信装置２１のパラメータ共有部３４では、図３に示すように通信装置２２からＲＴＰパケット選択的暗号化を示す暗号化・認証パラメータを受信すると（Ｓ５）、暗号化・認証パラメータをＲＴＰパケット選択的暗号化に決定する（Ｓ６）。このようにして両パラメータ共有部３４，４４において暗号化・認証パラメータとしてＲＴＰパケット選択的暗号化が通信路を介して共有される。なお暗号化アルゴリズムなど他のパラメータも同様にして同時に決定される。この場合、例えば従来のＳＳＬなどと同様に、各パラメータについていくつかの候補を送って、相手装置２２により決定してもらう。
【００１７】
図３において、ステップＳ２で入力データがＲＴＰパケットでないと判定され、あるいはステップＳ３で通信装置２１が接続されている通信網２３の伝送速度が高いと判定された場合は、この例では入力データ（パケット）全体を暗号化する、つまり非選択的暗号化を示す暗号化・認証パラメータを相手通信装置２２へ送信する（Ｓ７）。
通信装置２２のパラメータ共有部４４では図４に示すように、ステップＳ２で受信した通信相手の暗号化・認証パラメータがＲＴＰパケット選択的暗号化でないと判定されると、通信装置２２のアプリケーション部４１からの入力データ（アプリケーション）がＲＴＰパケットであるかを判断し（Ｓ５）、ＲＴＰパケットであれば、通信装置２２が接続された通信網２３が伝送速度の低い、例えば移動通信網であるかを調べ（Ｓ６）、そうであれば、ステップＳ３に移り、ＲＴＰパケット選択的暗号化を表わす暗号化・認証パラメータを決定して、これを通信装置２１へ送信する（Ｓ４）。ステップＳ５で入力データがＲＴＰパケットではないと判定され、あるいはステップＳ６で接続されている通信網２３の伝送速度が低くない移動通信網ではないと判定されると（Ｓ６）、非選択的暗号化を表わす暗号化・認証パラメータを決定して（Ｓ７）、相手通信装置２１へ送信する（Ｓ４）。
【００１８】
通信装置２１のパラメータ共有部３４では図３に示すように、ステップＳ７の送信後、相手通信装置２２から暗号化・認証パラメータを受信すると（Ｓ８）、その受信暗号化・認証パラメータがＲＴＰパケット選択的暗号化であるかを調べ（Ｓ９）、そうであればステップＳ６に移り、暗号化・認証パラメータを、ＲＴＰパケット選択的暗号化に決定し、ＲＴＰパケット選択的暗号化でなければ暗号化・認証パラメータを非選択的暗号化に決定する（Ｓ１０）。
このようにしてパラメータ共有部３４と４４は通信路を介して暗号化範囲を共有することができる。認証範囲は入力データ（アプリケーション）にかかわらず、また通信装置２１，２２がそれぞれ接続されている通信網２３の伝送特性に係わらず、入力データの全体とする。暗号化範囲としてはヘッダを除くか否かのみならず、暗号化範囲、認証範囲としては入力データが画像や音声である場合に、その重要部のみとすることもできる。この場合、例えばこれらデータの符号化の際に欠落すると復号が不可能となる重要なコードのみを自動的に暗号化するように指示することもできる。何れの場合も、暗号化アルゴリズムなど他のパラメータも、前記暗号化範囲の共有と同時に共有する処理を行う。
【００１９】
以上のようにしてパラメータが共有されると、共有された各種パラメータはパラメータ共有部３４，４４からそれぞれ暗号化・認証子付加部３３、復号化・検証部４３へ供給される。
暗号化・認証子付加部３３において暗号化・認証子付加の処理が行われる。その手順の例を図５に示す。上位アプリケーション部３１からデータパケットが入力されると（Ｓ１）、アプリケーションデータプロトコルにより、透過的に暗号化・認証子付加部３３に入力され（Ｓ２）、このデータパケットのうち認証範囲パラメータに従って選択された部分を用いて共有した認証子生成アルゴリズム・認証子生成用鍵により認証子を生成する（Ｓ３）。認証子生成方法は、例えば、今井秀樹著「暗号のおはなし」４．７節に詳しい。例えばハッシュ関数により認証範囲データを圧縮し、圧縮データを共通鍵で暗号化することにより生成する。その後、入力されたデータパケットに認証子を付加し（Ｓ４）、この認証子付データパケットに対し、暗号範囲パラメータに基づいて選択部分の暗号化を共有した暗号アルゴリズム、暗号鍵を用いて施す（Ｓ５）。なおブロック暗号化を行う場合は、その固定ブロック長にデータが不足した場合に埋め合せるパディングを暗号化の前に行う（Ｓ６）。
【００２０】
このようにして暗号化されたデータ構造の例を図６に示す。この例では入力されたアプリケーションデータに対し、認証子ＭＡＣが付加され、アプリケーションデータ中のヘッダを除いた部分（ペイロード）と認証子とが暗号化されている。この選択的暗号化を含むデータは下位のトランスポート部３２に受け渡され相手通信装置２２へ伝送される。
受信側通信装置２２では、上記の逆の手順を用いて暗号化されたデータを復号し、データ認証子（コード）を利用して受信データの正当性を検証する。つまり図１中の通信装置２２において、通信装置２１から受信したパケットはトランスポート部４２より復号化・検証部４３に入力され、復号化・検証部４３で共有した暗号化アルゴリズム、暗号化鍵、暗号化範囲に従って、この暗号化された部分が選択的に復号化され、この復号されたデータ中のデータ認証子（コード）ＭＡＣを用いて、ヘッダ及び復号化されたペイロード、つまり図６中のアプリケーションデータの正当性の検証を行う。正当であれば、このアプリケーションデータをアプリケーション部４１へ供給する。
【００２１】
このように暗号化範囲を共有することにより、入力データ中の一部を選択的に暗号化することができ、例えば安全性が問題になる部分のみを暗号化することにより、全体を暗号化する場合よりも処理量が少なくて済み、しかも、安全性が問題になるおそれがない。暗号化範囲は、暗号化のための他のパラメータを共有する処理と同時に行うことができ、このための処理の増加はわずかである。
特に前記例のように入力データ（アプリケーション）がＲＴＰパケットの場合で、そのＲＴＰパケットのヘッダ部分を暗号化しない領域とする場合は、このヘッダにＵＤＰパケットヘッダ、ＩＰパケットヘッダが付加されることになり、Ｓｅｃｕｒｅ ＲＴＰ同様に、途中経路における、ＲＴＰパケットヘッダを含めたヘッダ圧縮に対応可能である。また、Ｓｅｃｕｒｅ ＲＴＰとは異なり、暗号化領域は通信相手との交渉によりセッション開始時に設定可能であるため、ＲＴＰパケット以外のアプリケーションにも汎用的に対応可能である。
【００２２】
図５では、認証子付加後に暗号化を行ったが、図７に示すように暗号化後に認証子を生成し、暗号化されたパケットに認証子を付加しても良い。この場合、受信側では、受信データの正当性を検証した後、暗号の復号化を行うことになる。
以上の選択的安全化処理の流れは図８に示すようにデータが入力されると（Ｓ１）、入力データの安全化対象を示すパラメータを相手通信装置と通信路を介して共有し（Ｓ２）、その共有した安全化対象パラメータに従って入力データの一部に対して安全化処理を行って（Ｓ３）、相手装置へ送信する（Ｓ４）。
第２実施形態
図９にこの発明の第２実施形態を示す。これは図１４に示したＳＳＬを拡張して選択的暗号化をサポート可能としたものである。第１実施形態におけるパラメータ共有部３４はさらに相手通信装置２２と認証処理や暗号化・データ認証パラメータを交渉するハンドシェーク（Handshake）部３４ａ、暗号化・データ認証パラメータを有効化するチェンジサイファ（Change Cipher）部３４ｂ、イベント・エラーを通知するアラート（Alert）部３４ｃ、そして、トランスポート部３２を介して上記３つの各部３４ａ，３４ｂ，３４ｃのプロトコルデータを送受信するための第１レコード（Record）部３４ｄからなる。第１レコード部３４ｄのプロトコルデータフォーマットにはＳＳＬのＮレコード部と同じフォーマットを利用する。ハンドシェーク部３４ａでは、第１レコード部３４ｄおよび第２レコード部、つまり暗号化・認証子付加部３３で利用する暗号化・データ認証パラメータを相手通信装置２２と交渉して共有する。またチェンジサイファ（Change Cipher）部３４ｂは第１レコード部３４ｄおよび第２レコード部３３の暗号化・データ認証パラメータを有効化する。つまりその暗号化を開始させて相手に通知する。第１レコード部３４ｄには、ハンドシェーク部３４ａのプロトコルメッセージや選択的暗号化が不要なアプリケーションのデータが入力される。
【００２３】
選択的暗号化が必要なアプリケーションデータの送受信は、上記のプロトコルデータとは別に第２レコード部、つまり暗号化・認証子付加部３３で送受信される。第２アプリケーションデータ部３８は上位の第２アプリケーション部３１ｂのデータパケットを透過的に第２レコード部３３に受け渡すためのものである。また、第１レコード部３４ｄと異なり、第２レコード部、つまり暗号化・認証子付加部３３では入力データに対して新たなヘッダは追加せず、暗号化・認証子生成処理のみを施す。第１レコード部３４ｄで共有されたパラメータは第２レコード部３３の暗号化・データ認証処理に利用される。暗号化・データ認証処理は第１実施形態と同様である。
【００２４】
パラメータ共有部３４のハンドシェーク部３４ａによる相手通信装置とのパラメータ共有処理は最初は平文で通信を行うが、途中からは図１５に示したデータ構造により、暗号化・認証子付加を行って、これらパラメータの共有に対しても安全化してもよい。またアプリケーションでもＲＴＰパケットのように実時間性が要求されない、頻繁に送られない、ＨＴＴＰ，ＦＴＰ，Ｔｅｌｎｅｔ，ＲＴＳＰ（ＲＴＰのセッションを開くためのプロトコル）などのアプリケーションデータパケットは第１アプリケーション部３１ａより第１アプリケーションデータ部３７へ通じて第１レコード部３４ｄに入力して、これらに対しては、共有したパラメータにより暗号化をそのパケット全体に対して行い、図１５に示したようにレコード部のヘッダ１０を付けてレコードプロトコルパケットとしてトランスポート部３２へ供給する。なお相手側装置２２においては図９中の第２レコード部である暗号化・認証子付加部３３が、復号化・検証部になり、他は同様の構成である。
第３実施形態
図１０は、この発明の第３実施形態を示す。この実施形態では、ＲＴＳＰやＨＴＴＰなどの第１アプリケーション部３１ａを介してＲＴＰなど第２アプリケーション部３１ｂのアプリケーションデータに対して適用される暗号化・認証子付加パラメータを共有するための通信相手との交渉をする。例えば、図２の暗号化パラメータを相手通信装置２２の公開鍵で暗号化して、プロトコルメッセージボディに埋め込むことで相手通信装置２２に伝送することができる。
【００２５】
１つの通信装置に暗号化・認証子付加部と復号化・検証部を合せもたせてもよい。 上述においてはデータに対する安全化として暗号化と、データ認証子付加との両者を用いたが、その一方のみを用いてもよい。通信装置２１，２２の各部をコンピュータにプログラムを実行させて機能させてもよい。
【００２６】
【発明の効果】
以上説明したように、この発明によればデータの一部を選択的に安全化を施すことができ、かつ特定のアプリケーションに依存しない汎用的な伝送データ保護が可能であり、しかも特に移動通信に適用すればヘッダ圧縮も可能である。
【図面の簡単な説明】
【図１】この発明装置の実施形態の機能構成及びこの発明装置が用いられるシステム構成例を示す図。
【図２】暗号化パラメータの例を示す図。
【図３】送信側における暗号範囲共有処理手順の例を示す流れ図。
【図４】受信側における暗号範囲共有処理手順の例を示す流れ図。
【図５】図１中の暗号化・認証子付加部３３の処理手順の例を示す流れ図。
【図６】図１中の暗号化・認証子付加部３３の出力パケットのデータ構造の例を示す図。
【図７】暗号化・認証子付加部３３の処理手順の他の例を示す流れ図。
【図８】この発明の方法の処理手順の例を示す流れ図。
【図９】この発明装置の第２実施形態の機能構成を示す図。
【図１０】この発明装置の第３実施形態の機能構成を示す図。
【図１１】選択的暗号化されたパケットのデータ構造を示す図。
【図１２】ＡはＳｅｃｕｒｅ ＲＴＰを使用しない処理を示す図、ＢはＳｅｃｕｒｅ ＲＴＰを使用する時の処理を示す図である。
【図１３】ＡはＳＳＬ／ＷＴＬＳを使用しないアプリケーションデータの処理を示す図、ＢはＳＳＬ／ＷＴＬＳを使用する場合の処理を示す図である。
【図１４】ＳＳＬ／ＷＴＬＳレイヤの詳細を示す図。
【図１５】ＳＳＬ／ＷＴＬＳにより処理されたレコードプロトコルデータの構造を示す図。
Claims (15)
- 通信路を介して、入力データに対する安全化処理を特定する第１パラメータを相手のデータ安全通信装置（以下、「受信先装置」という。）に送信し、この受信先装置から送信された第２パラメータを受信することで、第２パラメータを受信先装置と共有するパラメータ共有手段と、
上記共有された第２パラメータに従って上記入力データの一部または全部を選択的に安全化して出力する安全化手段とを備え、
上記第１パラメータは、データ安全化通信装置の通信環境によって決定され、
上記第２パラメータは、上記第１パラメータまたは受信先装置の通信環境によって決定され、
上記第１パラメータおよび上記第２パラメータには、入力データを安全化する一部または全部の範囲を示す安全化範囲が含まれる
ことを特徴とするデータ安全化通信装置。 - 請求項１に記載の装置であって、
上記パラメータ共有手段は、上記入力データの種別に応じて上記安全化範囲を決定する
ことを特徴とするデータ安全化通信装置。 - 請求項１または２に記載の装置であって、
上記パラメータ共有手段は、この装置が接続された網の伝送特性に応じて上記安全化範囲を決定する
ことを特徴とするデータ安全化通信装置。 - 請求項１乃至３の何れかに記載の装置であって、
上記安全化範囲は暗号化範囲であり、
上記安全化手段は、上記共有されたパラメータに従って上記入力データの一部または全部を選択的に暗号化して出力する暗号化手段であり、
上記相手のデータ安全化通信装置は、暗号化された上記入力データを復号化可能なデータ安全化通信装置である
ことを特徴とするデータ安全化通信装置。 - 請求項４に記載の装置であって、
上記入力データはＲＴＰパケットであり、
上記暗号化範囲は、ＲＴＰパケットのうちＲＴＰヘッダを除いた部分である
ことを特徴とするデータ安全化通信装置。 - 請求項４に記載の装置であって、
パラメータ共有手段は、この装置が接続された網の通信路の伝送速度に応じて暗号化範囲を決定する
ことを特徴とするデータ安全化通信装置。 - 請求項１乃至３の何れかに記載の装置であって、
上記安全化範囲はデータ認証範囲であり、
上記安全化手段は、共有されたパラメータに従って入力データのデータ認証範囲から認証子を算出し、当該入力データに当該認証子を付加して出力する手段であり、
上記相手のデータ安全化通信装置は、認証子が付加された上記入力データを検証可能なデータ安全化通信装置である
ことを特徴とするデータ安全化通信装置。 - 請求項４から請求項６の何れかに記載のデータ安全化通信装置（以下、「送信元装置」という。）から受信する受信データに対する復号化処理に必要な第１パラメータを送信元装置から受信し、この第１パラメータまたはデータ安全化通信装置の通信環境によって第２パラメータを決定し、この第２パラメータを通信路を介して送信元装置に送信することで、上記第２パラメータを送信元装置と共有するパラメータ共有手段と、
上記共有された第２パラメータに従って上記受信データの一部または全部を選択的に復号化して出力する復号化手段とを備え、
上記第１パラメータおよび上記第２パラメータには、入力データを暗号化する一部または全部の範囲を示す暗号化範囲が含まれる
ことを特徴とするデータ安全化通信装置。 - 請求項７に記載のデータ安全化通信装置（以下、「送信元装置」という。）から受信する受信データに対する正当性の検証処理に必要な第１パラメータを送信元装置から受信し、この第１パラメータまたはデータ安全化通信装置の通信環境によって第２パラメータを決定し、この第２パラメータを通信路を介して送信元装置に送信することで、上記第２パラメータを送信元装置と共有するパラメータ共有手段と、
上記共有された第２パラメータに従って上記受信データの正当性を検証する検証手段とを備え、
上記第１パラメータおよび上記第２パラメータには、入力データに対するデータ認証範囲が含まれる
ことを特徴とするデータ安全化通信装置。 - 通信路を介して、入力データに対する暗号化処理を特定する第１パラメータを相手のデータ安全通信装置（以下、「受信先装置」という。）に送信し、この受信先装置から送信された第２パラメータを受信することで、第２パラメータを受信先装置と共有するパラメータ共有過程と、
上記共有された第２パラメータに従って上記入力データの一部または全部を選択的に暗号化して出力する暗号化過程とを有し、
上記第１パラメータは、データ安全化通信装置の通信環境によって決定され、
上記第２パラメータは、上記第１パラメータまたは受信先装置の通信環境によって決定され、
上記第１パラメータおよび上記第２パラメータには、入力データを暗号化する一部または全部の範囲を示す暗号化範囲が含まれる
ことを特徴とするデータ安全化通信方法。 - 請求項１０に記載の方法であって、
上記入力データはＲＴＰパケットであり、
上記暗号化範囲は、ＲＴＰパケットのうちＲＴＰヘッダを除く部分である
ことを特徴とするデータ安全化通信方法。 - 通信路を介して、入力データに対するデータ認証子生成処理を特定する第１パラメータを相手のデータ安全通信装置（以下、「受信先装置」という。）に送信し、この受信先装置から送信された第２パラメータを受信することで、第２パラメータを受信先装置と共有するパラメータ共有過程と、
上記共有された第２パラメータに従って上記入力データのデータ認証範囲から認証子を算出し、当該入力データに当該認証子を付加して出力する過程とを有し、
上記第１パラメータおよび上記第２パラメータには、入力データに対するデータ認証範囲が含まれる
ことを特徴とするデータ安全化通信方法。 - 請求項４から請求項６の何れかに記載のデータ安全化通信装置（以下、「送信元装置」という。）から受信する受信データに対する復号化処理に必要な第１パラメータを送信元装置から受信し、この第１パラメータまたはデータ安全化通信装置の通信環境によって第２パラメータを決定し、この第２パラメータを通信路を介して送信元装置に送信することで、上記第２パラメータを送信元装置と共有するパラメータ共有過程と、
上記共有されたパラメータに従って上記受信データの一部または全部を選択的に復号化して出力する復号化過程とを有し、
上記第１パラメータおよび上記第２パラメータには、入力データを暗号化する一部または全部の範囲を示す暗号化範囲が含まれる
ことを特徴とするデータ安全化通信方法。 - 請求項１３に記載の方法であって、
上記受信データはＲＴＰパケットであり、
上記復号化過程は、当該ＲＴＰパケットからＲＴＰヘッダを除いた部分に対して上記復号化を行う
ことを特徴とするデータ安全化通信方法。 - 請求項７に記載のデータ安全化通信装置（以下、「送信元装置」という。）から受信する受信データに対する正当性の検証処理に必要な第１パラメータを送信元装置から受信し、この第１パラメータまたはデータ安全化通信装置の通信環境によって第２パラメータを決定し、この第２パラメータを通信路を介して送信元装置に送信することで、上記第２パラメータを送信元装置と共有するパラメータ共有過程と、
上記共有されたパラメータに従って上記受信データの正当性を検証する検証過程とを有し、
上記第１パラメータおよび上記第２パラメータには、入力データに対するデータ認証範囲が含まれる
ことを特徴とするデータ安全化通信方法。
Priority Applications (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001122610A JP3819729B2 (ja) | 2001-04-20 | 2001-04-20 | データ安全化通信装置及びその方法 |
| CNB02801264XA CN1224212C (zh) | 2001-04-20 | 2002-04-22 | 数据安全化通信装置及其方法 |
| PCT/JP2002/003980 WO2002086847A1 (fr) | 2001-04-20 | 2002-04-22 | Appareil et procede de communication de securisation de donnees |
| US10/333,748 US7216230B2 (en) | 2001-04-20 | 2002-04-22 | Data securing communication apparatus and method |
| EP20020720547 EP1381011B1 (en) | 2001-04-20 | 2002-04-22 | Data securing communication apparatus and method |
| DE2002609475 DE60209475T8 (de) | 2001-04-20 | 2002-04-22 | Datensicherungs-kommunikationsvorrichtung und -verfahren |
| KR10-2002-7014910A KR100480225B1 (ko) | 2001-04-20 | 2002-04-22 | 데이터 안전화 통신장치 및 그 방법 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001122610A JP3819729B2 (ja) | 2001-04-20 | 2001-04-20 | データ安全化通信装置及びその方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002319936A JP2002319936A (ja) | 2002-10-31 |
| JP3819729B2 true JP3819729B2 (ja) | 2006-09-13 |
Family
ID=18972294
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001122610A Expired - Fee Related JP3819729B2 (ja) | 2001-04-20 | 2001-04-20 | データ安全化通信装置及びその方法 |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US7216230B2 (ja) |
| EP (1) | EP1381011B1 (ja) |
| JP (1) | JP3819729B2 (ja) |
| KR (1) | KR100480225B1 (ja) |
| CN (1) | CN1224212C (ja) |
| DE (1) | DE60209475T8 (ja) |
| WO (1) | WO2002086847A1 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11677495B2 (en) | 2019-04-16 | 2023-06-13 | Mitsubishi Electric Corporation | Safety communication device, safety communication system, safety communication method, and computer readable medium |
Families Citing this family (57)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8121296B2 (en) | 2001-03-28 | 2012-02-21 | Qualcomm Incorporated | Method and apparatus for security in a data processing system |
| US9100457B2 (en) | 2001-03-28 | 2015-08-04 | Qualcomm Incorporated | Method and apparatus for transmission framing in a wireless communication system |
| US8077679B2 (en) | 2001-03-28 | 2011-12-13 | Qualcomm Incorporated | Method and apparatus for providing protocol options in a wireless communication system |
| US7983419B2 (en) * | 2001-08-09 | 2011-07-19 | Trimble Navigation Limited | Wireless device to network server encryption |
| US7352868B2 (en) | 2001-10-09 | 2008-04-01 | Philip Hawkes | Method and apparatus for security in a data processing system |
| US7649829B2 (en) | 2001-10-12 | 2010-01-19 | Qualcomm Incorporated | Method and system for reduction of decoding complexity in a communication system |
| US7590855B2 (en) * | 2002-04-30 | 2009-09-15 | Tippingpoint Technologies, Inc. | Steganographically authenticated packet traffic |
| EP1540875A4 (en) * | 2002-08-28 | 2011-01-26 | Ntt Docomo Inc | ENCRYPTION ON THE BASIS OF CERTIFICATES AND PUBLIC KEY INFRASTRUCTURE |
| US7571317B1 (en) * | 2002-09-11 | 2009-08-04 | Cisco Technology, Inc. | Providing user notification signals in phones that use encryption |
| US7599655B2 (en) | 2003-01-02 | 2009-10-06 | Qualcomm Incorporated | Method and apparatus for broadcast services in a communication system |
| US20040158704A1 (en) * | 2003-02-12 | 2004-08-12 | Avaya Technology Corp. | Providing encrypted real time data transmissions on a network |
| KR100755683B1 (ko) * | 2003-05-07 | 2007-09-05 | 삼성전자주식회사 | 컨텐츠 제공자 인증 및 컨텐츠 무결성 보장 방법 |
| KR101000655B1 (ko) * | 2003-05-28 | 2010-12-10 | 엘지전자 주식회사 | 페이로드 데이터의 암호화 전송장치 및 방법 |
| EP1494460A1 (fr) * | 2003-07-02 | 2005-01-05 | THOMSON Licensing S.A. | Procédé et dispositif d'authentification de données numériques par module d'extension d'authentification |
| US7483532B2 (en) * | 2003-07-03 | 2009-01-27 | Microsoft Corporation | RTP payload format |
| US8098818B2 (en) | 2003-07-07 | 2012-01-17 | Qualcomm Incorporated | Secure registration for a multicast-broadcast-multimedia system (MBMS) |
| US8718279B2 (en) | 2003-07-08 | 2014-05-06 | Qualcomm Incorporated | Apparatus and method for a secure broadcast system |
| US8724803B2 (en) * | 2003-09-02 | 2014-05-13 | Qualcomm Incorporated | Method and apparatus for providing authenticated challenges for broadcast-multicast communications in a communication system |
| JPWO2005041610A1 (ja) | 2003-10-29 | 2007-04-05 | 富士通株式会社 | 無線装置 |
| AU2004297923B2 (en) * | 2003-11-26 | 2008-07-10 | Cisco Technology, Inc. | Method and apparatus to inline encryption and decryption for a wireless station |
| EP1544704A1 (en) * | 2003-12-19 | 2005-06-22 | STMicroelectronics Limited | Monolithic semiconductor integrated circuit and method for selective memory encryption and decryption |
| US7372856B2 (en) * | 2004-05-27 | 2008-05-13 | Avaya Technology Corp. | Method for real-time transport protocol (RTP) packet authentication |
| US7761705B2 (en) * | 2004-09-17 | 2010-07-20 | At&T Intellectual Property I, L.P. | Detection of encrypted packet streams |
| US8332938B2 (en) | 2004-09-17 | 2012-12-11 | At&T Intellectual Property I, L.P. | Detection of encrypted packet streams using a timer |
| US7730519B2 (en) * | 2004-09-17 | 2010-06-01 | At&T Intellectual Property I, L.P. | Detection of encrypted packet streams using feedback probing |
| US7451309B2 (en) | 2004-09-17 | 2008-11-11 | At&T Intellectual Property L.P. | Signature specification for encrypted packet streams |
| US20060078790A1 (en) * | 2004-10-05 | 2006-04-13 | Polyplus Battery Company | Solid electrolytes based on lithium hafnium phosphate for active metal anode protection |
| US7406597B2 (en) | 2004-10-29 | 2008-07-29 | International Business Machines Corporation | Methods for efficiently authenticating multiple objects based on access patterns |
| KR20060054662A (ko) * | 2004-11-15 | 2006-05-23 | 삼성전자주식회사 | 광대역 무선 통신 시스템에서 헤더 압축 장치 및 방법 |
| US7743245B2 (en) * | 2005-03-10 | 2010-06-22 | Intel Corporation | Security protocols on incompatible transports |
| DE102005025328B4 (de) * | 2005-05-31 | 2007-06-28 | Siemens Ag | Verfahren zur Übertragung von Synchronisierungs-Nachrichten |
| US7532638B2 (en) * | 2005-06-01 | 2009-05-12 | Broadcom Corporation | Wireless terminal baseband processor high speed turbo decoding module supporting MAC header splitting |
| CN100525476C (zh) * | 2005-06-29 | 2009-08-05 | 华为技术有限公司 | 媒体网关控制协议呼叫中的内容传输方法 |
| US20070237144A1 (en) * | 2006-03-30 | 2007-10-11 | Avaya Technology Llc | Transporting authentication information in RTP |
| US8189586B2 (en) | 2006-04-12 | 2012-05-29 | Telefonaktiebolaget Lm Ericsson (Publ) | Plural telecommunications functions having sharing transaction(s) |
| MX2008010430A (es) * | 2006-04-12 | 2008-09-24 | Ericsson Telefon Ab L M | Metodos, nodos y aparatos para compresion y encriptacion de paquetes de datos en una red de telecomunicacion. |
| JP4802123B2 (ja) * | 2007-03-07 | 2011-10-26 | 富士通株式会社 | 情報送信装置、情報送信方法、情報送信プログラムおよび該プログラムを記録した記録媒体 |
| US7813376B1 (en) * | 2007-05-18 | 2010-10-12 | Juniper Networks, Inc. | Termination of network connections in absence of a dynamic network interface |
| EP2186285B1 (de) | 2007-09-06 | 2016-07-20 | Unify GmbH & Co. KG | Verfahren und einrichtung zur authentisierung übertragener nutzdaten |
| US20090144548A1 (en) * | 2007-11-30 | 2009-06-04 | Motorola, Inc. | Authentication while exchanging data in a communication system |
| US8838819B2 (en) * | 2009-04-17 | 2014-09-16 | Empirix Inc. | Method for embedding meta-commands in normal network packets |
| US8730871B2 (en) * | 2009-05-22 | 2014-05-20 | Raytheon Company | System and method for providing voice communications over a multi-level secure network |
| US8914631B2 (en) * | 2009-07-01 | 2014-12-16 | Oracle International Corporation | Performing secure and non-secure communication over the same socket |
| JP2012010254A (ja) * | 2010-06-28 | 2012-01-12 | Fujitsu Ltd | 通信装置、通信方法及び通信システム |
| US9330196B2 (en) | 2010-11-01 | 2016-05-03 | Seven Networks, Llc | Wireless traffic management system cache optimization using http headers |
| US9060032B2 (en) * | 2010-11-01 | 2015-06-16 | Seven Networks, Inc. | Selective data compression by a distributed traffic management system to reduce mobile data traffic and signaling traffic |
| WO2012060996A2 (en) | 2010-11-01 | 2012-05-10 | Michael Luna | Caching adapted for mobile application behavior and network conditions |
| CN103069855A (zh) * | 2010-12-28 | 2013-04-24 | 三洋电机株式会社 | 终端装置 |
| JP2016510196A (ja) * | 2013-03-13 | 2016-04-04 | ジャンプトゥー メディア インコーポレイテッド | 安全なネットワーク通信 |
| EP2981021B1 (en) * | 2013-03-29 | 2020-04-29 | Sony Corporation | Integrated circuit, communication method, computer program, and communication device |
| JP6051093B2 (ja) * | 2013-04-16 | 2016-12-27 | 株式会社日立製作所 | 暗号通信システム |
| EP2846510A1 (en) * | 2013-09-09 | 2015-03-11 | Alcatel Lucent | SRTP protocol extension |
| CN104639500A (zh) * | 2013-11-08 | 2015-05-20 | 江良洲 | 双不对称加密提高移动互联网信息传输安全性的方法 |
| US10333696B2 (en) | 2015-01-12 | 2019-06-25 | X-Prime, Inc. | Systems and methods for implementing an efficient, scalable homomorphic transformation of encrypted data with minimal data expansion and improved processing efficiency |
| KR102055698B1 (ko) * | 2016-10-05 | 2019-12-13 | 에스케이텔레콤 주식회사 | 네트워크장치 및 단말장치와, 그 장치들의 동작 방법 |
| US11876786B2 (en) * | 2016-12-08 | 2024-01-16 | Comcast Cable Communications, Llc | Protocol obfuscation in moving target defense |
| US10476851B1 (en) * | 2018-04-30 | 2019-11-12 | Centri Technology, Inc. | Unbounded sessions for secure communications |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS6212227A (ja) * | 1985-07-10 | 1987-01-21 | Hitachi Ltd | 秘匿通信方式 |
| JP3792002B2 (ja) * | 1997-04-17 | 2006-06-28 | ローム株式会社 | データ通信装置、データ通信システムおよびデータ通信方法 |
| US6070245A (en) | 1997-11-25 | 2000-05-30 | International Business Machines Corporation | Application interface method and system for encryption control |
| US6154840A (en) | 1998-05-01 | 2000-11-28 | Northern Telecom Limited | System and method for transferring encrypted sections of documents across a computer network |
| SE513356C2 (sv) * | 1998-11-20 | 2000-08-28 | Ericsson Telefon Ab L M | Förfarande och anordning för kryptering av bilder |
| JP3816689B2 (ja) * | 1999-03-31 | 2006-08-30 | 株式会社東芝 | 情報配信装置、情報受信装置及び通信方法 |
| US6918034B1 (en) * | 1999-09-29 | 2005-07-12 | Nokia, Corporation | Method and apparatus to provide encryption and authentication of a mini-packet in a multiplexed RTP payload |
| US6829254B1 (en) * | 1999-12-28 | 2004-12-07 | Nokia Internet Communications, Inc. | Method and apparatus for providing efficient application-level switching for multiplexed internet protocol media streams |
| DE10001855A1 (de) * | 2000-01-18 | 2001-07-19 | Siemens Ag | Verfahren, System zur Übermittlung von Daten von einem Sender zu einem Empfänger und Sender bzw. Empfänger hierzu |
| US20010052072A1 (en) * | 2000-01-25 | 2001-12-13 | Stefan Jung | Encryption of payload on narrow-band IP links |
| US6950445B2 (en) * | 2000-11-16 | 2005-09-27 | Telefonaktiebolaget Lm Ericsson (Publ) | Communication system and method for shared context compression |
| US7237108B2 (en) * | 2001-09-26 | 2007-06-26 | General Instrument Corporation | Encryption of streaming control protocols and their headers |
| US7356687B2 (en) * | 2002-05-21 | 2008-04-08 | General Instrument Corporation | Association of security parameters for a collection of related streaming protocols |
-
2001
- 2001-04-20 JP JP2001122610A patent/JP3819729B2/ja not_active Expired - Fee Related
-
2002
- 2002-04-22 CN CNB02801264XA patent/CN1224212C/zh not_active Expired - Fee Related
- 2002-04-22 WO PCT/JP2002/003980 patent/WO2002086847A1/ja active IP Right Grant
- 2002-04-22 DE DE2002609475 patent/DE60209475T8/de active Active
- 2002-04-22 US US10/333,748 patent/US7216230B2/en not_active Expired - Fee Related
- 2002-04-22 EP EP20020720547 patent/EP1381011B1/en not_active Expired - Lifetime
- 2002-04-22 KR KR10-2002-7014910A patent/KR100480225B1/ko not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11677495B2 (en) | 2019-04-16 | 2023-06-13 | Mitsubishi Electric Corporation | Safety communication device, safety communication system, safety communication method, and computer readable medium |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002319936A (ja) | 2002-10-31 |
| EP1381011A4 (en) | 2004-06-30 |
| KR20030011837A (ko) | 2003-02-11 |
| EP1381011A1 (en) | 2004-01-14 |
| CN1461461A (zh) | 2003-12-10 |
| WO2002086847A1 (fr) | 2002-10-31 |
| DE60209475T8 (de) | 2006-12-28 |
| CN1224212C (zh) | 2005-10-19 |
| EP1381011B1 (en) | 2006-03-01 |
| DE60209475D1 (de) | 2006-04-27 |
| US7216230B2 (en) | 2007-05-08 |
| US20030167394A1 (en) | 2003-09-04 |
| KR100480225B1 (ko) | 2005-04-07 |
| DE60209475T2 (de) | 2006-09-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3819729B2 (ja) | データ安全化通信装置及びその方法 | |
| US11522838B2 (en) | Secure end-to-end transport through in intermediary nodes | |
| US8984268B2 (en) | Encrypted record transmission | |
| CN108650227B (zh) | 基于数据报安全传输协议的握手方法及系统 | |
| Argyroudis et al. | Performance analysis of cryptographic protocols on handheld devices | |
| Ylonen et al. | The secure shell (SSH) transport layer protocol | |
| US20060005239A1 (en) | Inspected secure communication protocol | |
| US20020199098A1 (en) | Non-invasive SSL payload processing for IP packet using streaming SSL parsing | |
| CN107104977B (zh) | 一种基于sctp协议的区块链数据安全传输方法 | |
| CN111756529B (zh) | 一种量子会话密钥分发方法及系统 | |
| TW201537937A (zh) | 統一身份認證平臺及認證方法 | |
| KR20180130203A (ko) | 사물인터넷 디바이스 인증 장치 및 방법 | |
| JP2005210193A (ja) | 共通秘密鍵生成装置 | |
| CN113904809A (zh) | 一种通信方法、装置、电子设备及存储介质 | |
| WO2023036348A1 (zh) | 一种加密通信方法、装置、设备及介质 | |
| CN108040071B (zh) | 一种VoIP音视频加密密钥动态切换方法 | |
| CN113950802A (zh) | 用于执行站点到站点通信的网关设备和方法 | |
| Hohendorf et al. | Secure End-to-End Transport Over SCTP. | |
| Ylonen | RFC 4253: The secure shell (SSH) transport layer protocol | |
| CN112104635B (zh) | 通信方法、系统和网络设备 | |
| WO2009094812A1 (fr) | Procédés et appareils pour assurer la sécurité de flux multimédia point à point | |
| CN118432894A (zh) | 一种基于TCP的iOS系统远程服务受信的方法和装置 | |
| Roepke et al. | A Survey on Protocols securing the Internet of Things: DTLS, IPSec and IEEE 802.11 i | |
| Hitesh et al. | Performance Analysis of Cryptographic Protocols on Handheld Devices | |
| Edward | Performance and Power Consumption Analysis of Symmetric Encryption Algorithms in Wireless Devices |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040929 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060228 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060426 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20060426 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060530 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060615 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100623 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100623 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110623 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120623 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |