(57)【要約】      （修正有）【課題】任意のパケット長のデータに対して復号処理を高速化する。【解決手段】復号回路１５Ａは、暗号化データに対して暗号化の単位ブロックごとに復号処理を行う復号処理部１５７と、復号処理部１５７で復号処理された暗号化データの認証処理を行う認証処理部１５８と、前記暗号化データの復号結果を先頭から第１のサイズまで認証処理部１５８に入力する入力提供部１５６と、を有する。認証処理部１５８は、第１のサイズまで復号処理と並列に認証処理を行う。【選択図】図６
2017011392.tif 000002
【特許請求の範囲】
【請求項１】
暗号化データに対して暗号化の単位ブロックごとに復号処理を行う復号処理部と、
前記復号処理部で復号処理された前記暗号化データの認証処理を行う認証処理部と、
前記暗号化データの復号結果を先頭から第１のサイズまで前記認証処理部に入力する入力提供部と、
を有し、
前記認証処理部は、前記第１のサイズまで前記復号処理と並列に前記認証処理を行うことを特徴とする復号回路。
【請求項２】
前記第１のサイズは、前記暗号化データの全サイズから、パディング長を示す第１フィールドのサイズと、認証コードを示す第２フィールドのサイズと、前記単位ブロックのサイズを引き算したサイズであることを特徴とする請求項１に記載の復号回路。
【請求項３】
前記入力提供部は、前記第１フィールドの復号の結果、前記暗号化データのパディング長が前記単位ブロックのサイズより小さい場合に、前記第１のサイズを超える部分の認証対象データを前記認証処理部に供給し、
前記認証処理部は、前記復号処理の完了後に、前記第１のサイズを超える部分の認証対象データを認証することを特徴とする請求項２に記載の復号回路。
【請求項４】
前記認証処理部は、前記入力提供部から入力される前記暗号化データの復号結果が第２のサイズ以下である場合に、認証結果を中間値として出力し、
前記復号回路は、中間値を保持する中間値記憶部、
をさらに有し、
前記第２のサイズは、前記暗号化データの全サイズから、前記第１フィールドのサイズと、前記第２フィールドのサイズと、前記パディング長がとり得る最大サイズを引き算したサイズであることを特徴とする請求項２または３に記載の復号回路。
【請求項５】
前記認証処理部は、前記第１フィールドの復号の結果、前記暗号化データのパディング長が前記単位ブロックのサイズより大きい場合に、前記中間値記憶部に保持された前記中間値を用いて、認証の再計算を行うことを特徴とする請求項４に記載の復号回路。
【請求項６】
前記認証処理部は、前記中間値記憶部が保持する中間値と、前記認証処理のための初期値のいずれかを入力として選択するセレクタと、
前記セレクタにより選択された値を用いて前記認証処理を実行する認証モジュールと、
を有することを特徴とする請求項４または５に記載の復号回路。
【請求項７】
前記入力提供部は、前記第１のサイズの復号結果の最終部分であって、前記パディング長がとり得る最大サイズに相当する分のデータをバッファリングするバッファ部を有し、
前記認証処理部は、暗号化データのパディング長が前記単位ブロックのサイズより大きい場合に、前記中間値と、前記入力提供部にバッファリングされたデータとを用いて認証の再計算を行うことを特徴とする請求項４〜６のいずれか１項に記載の復号回路。
【請求項８】
前記認証部は、前記入力提供部から入力される前記暗号化データの復号結果が前記第１のサイズより小さく、かつ前記第２のサイズより大きい場合に、認証結果を破棄することを特徴とする請求項４に記載の復号回路。
【請求項９】
前記復号処理部は、前記暗号化の単位ブロックのサイズ以下のパディング長を有する暗号化データだけを入力として受け取ることを特徴とする請求項１〜３のいずれか１項に記載の復号回路。
【請求項１０】
前記パディング長がとり得る最大サイズは２５５バイトであることを特徴とする請求項４〜８のいずれか１項に記載の復号回路。
【請求項１１】
前記暗号化の単位ブロックのサイズは１６バイトであることを特徴とする請求項１〜１０のいずれか１項に記載の復号回路。
【請求項１２】
請求項１〜１１のいずれか１項に記載の復号回路と、
通信インタフェースと、
前記通信インタフェースを介して前記暗号化データを受信したときに、前記復号回路を起動する制御部と
を有する通信装置。
【請求項１３】
請求項１２に記載の通信装置と、
前記暗号化データを送信する第２の通信装置と、
を含む通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、復号回路と、これを用いた通信装置、及び通信システムに関する。
【背景技術】
【０００２】
様々な機器がネットワークに接続される中で、より小型で省電力の機器に対しても安全性の高い通信が求められている。「ＩｏＴ（Internet of Things）」と呼ばれるモノのインターネットでは、家電や自動車など多種多様なものをインターネットやクラウドに接続し、情報交換することで相互制御を行う。たとえば、道路に設置された信号機や標識に車両を検知するセンサを搭載し、クラウド経由で単位時間当たりの交通量を車両やスマートフォン等の携帯端末に通知することで、交通渋滞を抑制する。
【０００３】
信号機からの情報が偽装可能であれば、悪意のユーザによる意図的な交通渋滞が発生し得る。これを回避するために通信内容の認証や暗号化を行うと、通信速度が低下し、リアルタイム情報に対する要望に答えられなくなる。また、通信の暗号化と復号の処理は、ＣＰＵ（Central Processing Unit：演算装置）に対して多大な処理コストを要求する。小型の機器では、通信速度の低下だけではなく、ＣＰＵの占有による他の処理の中断といった問題も生じる。
【０００４】
そこで、ＴＬＳ（Transport Layer Security）やＩＰｓｅｃなどの通信プロトコルの暗号化と復号処理をハードウェア化することで、通信速度を向上しつつ、ＣＰＵの占有を防ぐ技術が検討されている。特に、ＴＳＬの復号処理と認証処理を並列に実行することで、処理を高速化する方法が提案されている（たとえば、特許文献１参照）。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、復号と認証をハードウェア回路で並列処理する公知の手法では、パケットの終端近傍の領域において復号と認証の処理を並列化することが困難である。パディング長に関する情報はパケットの末尾に記述されているため、復号によりパディング長が確定しないと認証処理への入力が確定しないからである。パディング長として最大で２５５バイトを想定した場合、この範囲について復号処理と認証処理を並列に行うことができない。特にパケットサイズの小さいデータに関しては、復号と認証を並列処理できるデータ区間がほとんどなく、並列化のメリットが得られないという問題がある。
【０００６】
そこで、任意のパケットサイズのデータに対して復号処理を高速化する復号回路と、これを用いた通信装置、及び通信システムの提供を目的とする。
【課題を解決するための手段】
【０００７】
実施形態では、通信パケットのパディング長が暗号化の単位ブロックのサイズ以下（たとえば１６バイト以下）であると仮定し、復号によりパディング長が確定するよりも前の段階で入力データに対する認証を進める。これにより、任意の長さのパケットに対して復号と認証の並列処理が可能な区間を拡張する。
【０００８】
具体的には、本発明の一つの態様において、復号回路は、
暗号化データに対して暗号化の単位ブロックごとに復号処理を行う復号処理部と、
前記復号処理部で復号処理された前記暗号化データの認証処理を行う認証処理部と、
前記暗号化データの復号結果を先頭から第１のサイズまで前記認証処理部に入力する入力提供部と、
を有し、
前記認証処理部は、前記第１のサイズまで前記復号処理と並列に前記認証処理を行うことを特徴とする。
【発明の効果】
【０００９】
上記構成により、任意のパケット長のデータに対して復号処理を高速化することができる。
【図面の簡単な説明】
【００１０】
【図１】実施形態の通信システムの概略構成図である。
【図２】ＴＬＳのパケット構成を示す図である。
【図３】ＴＬＳの認証に用いる入力データを説明する図である。
【図４】認証処理に入力できるデータ長の説明図である。
【図５】実施形態の原理を説明する図であり、実施形態で認証処理に入力するデータ長を示す図である。
【図６】第１実施形態の復号回路の概略構成図である。
【図７】認証処理部の中のＨＡＳＨ処理部の構成例である。
【図８】認証処理部の中のＨＡＳＨ処理部の別の構成例である。
【図９Ａ】実施形態の復号回路の処理フローである。
【図９Ｂ】実施形態の復号回路の処理フローであり、図９ＡのＡ点に続くフローである。
【図１０】第２実施形態の復号回路の概略構成図である。
【図１１】実施形態の通信システムの適用例を示す図である。
【発明を実施するための形態】
【００１１】
以下、図面を参照して本発明の実施の形態を説明する。図１は、実施形態の通信システム１の概略図である。通信システム１は、伝送チャネル２を介して互いに接続される通信装置１０と通信装置２０を有する。通信装置２０は、たとえば暗号化機能を有する送信機であり、通信装置１０は、復号機能を有する受信機である。伝送チャネル２は、同軸ケーブルや光ファイバケーブル等の有線の伝送路あってもよいし、無線チャネルであってもよいし、ＵＳＢ（Universal Serial Bas）であってもよい。図示は省略するが、通信装置１０と通信装置２０はインターネット、クラウド、ＬＡＮ（Local Area Network）等の任意のネットワークを介して接続されていてもよい。
【００１２】
通信装置２０は、バス２６で相互接続されるＣＰＵ２１、ＲＯＭ（Read Only Memory）２２、ＲＡＭ（Random Access Memory）２３、外部インタフェース（Ｉ／Ｆ）２４、及び暗号化回路２５を有する。暗号化回路２５は、たとえばＴＬＳプロトコルにより送信データを暗号化する。暗号化回路２５は、共通鍵暗号アルゴリズムとして、たとえばＡＥＳ（Advanced Encryption Standard）を用い、１６バイトのブロック単位で暗号化を行う。ＣＰＵ２１は、データを送信する際に暗号化回路２５を起動し、暗号化回路２５へのデータの転送を制御する。ＲＯＭ２２は、ＣＰＵ２１を動作させるコード等を保持する。ＲＡＭ２３は、暗号化回路２５による暗号化の際に必要に応じて処理中のデータを展開する。外部インタフェース２４は、ＴＬＳで暗号化されたパケットを伝送チャネル２に送出する。
【００１３】
通信装置１０は、バス１６で相互接続されるＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、外部インタフェース（Ｉ／Ｆ）１４、及び復号回路１５を有する。パケットの受信時に、ＣＰＵ１１は、ＲＯＭ１１２に記録されたＴＬＳのパケットを受け付けるためのコードを実行する。外部インタフェース１４は、伝送チャネル２を介して送られてきたＴＬＳのパケットを通信装置１０に入力する。ＣＰＵ１１は、入力されたＴＬＳのパケットをＲＡＭ１３上に展開して、復号回路１５を起動する。復号回路１５は、ＲＡＭ１３上に展開されたＴＬＳのパケットを読み込んで、後述する手順で復号する。ＣＰＵ１１は、復号結果に応じた処理動作を行う。
【００１４】
外部インタフェース１４、２４は、Ｅｔｈｅｒｎｅｔ（登録商標）、ＷｉＦｉ（登録商標）、３Ｇなど、任意のネットワークインタフェースとの接続が可能な通信インタフェースである。また、ＵＳＢなどの外部接続用のインタフェースから、他の機器により送信されたＴＬＳデータを通信装置１０に入力してもよい。
【００１５】
図１では、便宜上、通信装置２０を暗号化機能を有する送信機、通信装置１０を復号機能を有する受信機として描いているが、通信装置１０と２０の双方が、送受信機能と暗号化／復号機能を有する送受信装置であってもよい。
【００１６】
通信システム１は、後述するように、たとえば交通監視システムに適用することができる。ＩｏＴを構築する交通監視システムで、通信装置２０は、たとえば信号機に設置された送信機である。この場合、一つのパケットで送信するデータはそれほど多くはないが、情報のリアルタイム性を考えると、送信頻度は高く、短いパケットを大量に送るケースが発生する。受信側の通信装置１０は、たとえば車載搭載端末や、ドライバーが有するスマートフォン等の携帯端末である。通信装置１０でも、リアルタイム受信が望ましい情報については、クラウドに集約されたデータを頻繁に受け取るケースが増える。
【００１７】
そこで、通信装置１０の復号回路１５は、ＴＬＳのパケットに付加されたパディングのサイズ（パディング長）を、暗号ブロックのサイズより小さいサイズと仮定して復号処理と認証を並列に行う。一例として、暗号化の標準規格としてＡＥＳを用いる場合は、ＴＬＳのパケットのパディング長を１６バイト以下と仮定して認証部への入力を制御する。
【００１８】
実施形態の復号回路と復号処理を具体的に説明する前に、図２と図３を参照して、暗号化通信で用いられるパケットの構成について説明する。
【００１９】
図２は、ＴＬＳのパケット構成を示す図である。ＴＬＳのパケットは、「Type」、「Version」、「CipherTextLength」で構成される５バイトのＴＬＳヘッダと、「Compressed Fragment」、「MAC」、「Padding」、及び「Padding Length」の各フィールドを有する。このうち、暗号化されるのは、「Compressed Fragment」、「MAC」、「Padding」、「Padding Length」の領域であり、ＴＬＳヘッダは暗号化されずに送信される。
【００２０】
ＴＬＳヘッダの「Type」は、パケットのペイロードに格納されているデータの種類を記述する。「Version」は、ＴＬＳプロトロコルのバージョンを記述する。「CipherTextLength」は暗号化されているフィールド全体のサイズを示す。
【００２１】
暗号化の対象となる「Compressed Fragment」は、メッセージまたはコンテンツを格納する。「MAC」は認証用のコード（Message Authentication Code）を格納する。「Padding」はデータを暗号処理の単位であるブロックサイズに合わせるために付加されるフィールドである。「Padding Length」はパディング長を示す情報を格納する。「Compressed Fragment」、「MAC」、「Padding」、及び「Padding Length」の各フィールドが復号されて初めてパケットの中身を知ることができる。
【００２２】
「Compressed Fragment」は１６キロバイト（ｋｂｙｔｅ）を上限として任意の長さをとり得るが、暗号化されたフィールド全体では、暗号ブロックの処理単位の倍数でなければならない。ＡＥＳのアルゴリズムの場合、暗号化されたフィールドの合計サイズは１６バイトの整数倍である。そのため、「Compressed Fragment」、「MAC」、「Padding」、「Padding Length」の各フィールドの長さの合計が１６バイトの整数倍となるように、パディング長が調整される。一般的に、復号のアルゴリズムは直前の復号結果を入力とするアルゴリズムであり、復号は先頭から順に暗号ブロックごとに行われる。
【００２３】
「MAC」のサイズは認証アルゴリズムに依存する。認証アルゴリズムがHMAC_SHA1であれば２０バイト、HMAC_SHA256であれば３２バイト、HMAC_SHA512であれば６４バイトである。認証アルゴリズムはＴＬＳの通信が始まる前の、通信相手とのコネクション確立時に定義され、ＴＬＳのパケットが受信側に届いている時点では長さの確定している既知の値である。
【００２４】
「Padding」のサイズは、暗号化フィールドを暗号化ブロックの整数倍のサイズに合わせるために０バイト〜２５５バイトまでの任意の長さを選択可能である。たとえば、「Compressed Fragment」、「MAC」、及び「Padding Length」のサイズの合計が、１６バイトの整数倍に３バイト足りないときは、パディング長として、３バイト、１９バイト、３５バイト、５１バイトといった３＋１６ｋ（ｋ＝０〜１５）の長さをとり得る。
【００２５】
「Padding Length」は１バイトの固定サイズであり、パディング長が記述される。フィールドサイズが１バイトであるため、取り得る値は０〜２５５であり、パディング長として指定可能な範囲は０〜２５５バイトとなる。ＴＬＳのパケットの復号時には、「Padding Length」に記述された情報から「Padding」の領域を特定し、既知となっている「MAC」のサイズを用いて計算することでパケット中の「Compressed Fragment」の領域を特定する。
【００２６】
図３は、ＴＬＳのパケットの復号時に認証処理に供給されるデータ部分を説明する図である。斜線で示される復号データ（すなわち「Compressed Fragment」のフィールド）が認証に用いられる。ＴＬＳの認証では、「SeqNum」と、ＴＬＳヘッダと、「Compressed Fragment」の復号結果を用いてMAC値を計算する。「SeqNum」は、暗号化データの送受信に先立って、送信側と受信側であらかじめ共有されるデータである。認証では、計算されたMAC値と、ＴＬＳのパケット内に存在するMAC値の復号結果が一致するか否かを確認し、一致する場合は認証は成功したと判断する。一致しない場合は認証に失敗したと判断する。
【００２７】
この認証アルゴリズムは、「Compressed Fragment」の復号データを入力として用いるため、作業としてはブロック単位で復号されたデータを、順次、認証アルゴリズムに入力する。ＴＬＳのパケットは、「Compressed Fragment」のデータの後に「MAC」、「Padding」、「Padding Length」のフィールドを有するが、これらのデータは認証アルゴリズムに入力してはならない。
【００２８】
認証アルゴリズムに対して「Compressed Fragment」の復号結果だけを入力するには、「Compressed Fragment」のサイズを調べる必要がある。そのためには、一般に「padding Length」の復号結果を待ち、その復号結果から「Compressed Fragment」長さを逆算する。認証と復号処理を並列で行う場合、ＴＬＳのパケットで間違いなく「Compressed Fragment」であると確定できる領域に関しては、復号処理と認証を並列に行うことができるが、「MAC」である可能性が残されている領域について並列処理は困難である。復号処理が完了して、「Compressed Fragment」の領域が確定してからでないと、認証処理を再開することが困難だからである。実施形態では、後述する手法と構成でこの問題を解決する。
【００２９】
図４は、ＴＬＳのパケットで、一般的な手法で認証処理に入力できるデータ長を説明する図である。ＴＬＳのパケットの復号と認証を並列で処理する場合、復号前のＴＬＳパケットは、「Compressed Fragment」であることが確定できる領域Ａ、「Compressed Fragment」の可能性がある領域Ｂ、「Compressed Fragment」の可能性がない領域Ｃに分けられる。
【００３０】
領域Ａは、ChiherTextLengthとＨＭＡＣサイズから計算可能である。暗号化された部分のデータ長はCompressed Fragment、HMAC、Padding、Paddingサイズから成り、PaddingとPaddingサイズの合計は最大でも２５６バイトであるため、領域Ａは（CipherTextLength）−（ＨＭＡＣサイズ）−２５６で計算が可能である。
【００３１】
ＴＬＳのパケットの暗号化されているデータのデータ長は、ＴＬＳヘッダ内の「CipherTextLength」のフィールドに記載されている。パディング長は０バイトから２５５バイトまでの範囲であり、「Padding Length」のフィールドサイズは１バイトである。したがって、「Compressed Fragment」がとり得るサイズ（長さ）は下記の式（１）の範囲であり、この範囲はＴＬＳのヘッダを見た段階で分かる。
【００３２】
CipherTextLength-(HMACサイズ+PaddingLengthフィールドサイズ+255)
≦Compressed Fragmentサイズ
≦CipherTextLength-(HMACサイズ+PaddingLengthフィールドサイズ)        （１）
ここでは、ＭＡＣコードとして、共有鍵とハッシュ関数を組み合わせたＨＭＡＣ（keyed-Hashing for Message Authentication Code）を想定している。
【００３３】
式（１）の下限は、パディング長を最大の２５５バイトとしたときの「Compressed Fragment」のサイズであり、上限は、パディング長を最小の０バイトとしたときの「Compressed Fragment」のサイズである。
【００３４】
「Compressed Fragment」と確定できる領域Ａは、式（１）の下限であり、復号結果をそのまま認証処理の入力として、復号と認証の並列動作が可能である。
【００３５】
実際のパディング長は、パケットデータの末尾の「Padding Length」の復号結果を待たないと確定しない。それよりも前の段階では、「Compressed Fragment」と確定できる領域Ａを超えた部分について、「Compressed Fragment」であるか、「MAC」のデータであるか、「padding」であるかを区別することができない。これらを区別するには、復号をパケットの終端まで行ってパディング長が確定するのを待つ必要があり、領域Ｂについて並列処理を行うのが困難となる。
【００３６】
従来の並列化方法では、「Compressed Fragment」であることが確定の領域Ａだけを並列処理している。並列化できないのは、上述のとおり領域Ｂと領域Cである。HMAC_SHA256の場合はＨＭＡＣサイズが３２バイトであり、２８８バイトのデータが復号処理できないことになる。ＴＬＳのパケットサイズが１６キロバイトのように大きい場合は、「Compressed Fragment」の大部分が並列処理可能である。しかし、ＴＬＳのパケットサイズが２５６バイト前後と小さい場合、暗号化されたデータの全てが「Compressed Fragment」でない可能性もあり、並列処理を行える部分がほとんどなくなる。
【００３７】
一方で、openSSLなどの一般的に用いられるＴＬＳのプロトコル実装では、多くの場合はパディング長を１６バイト以下に設定している。「Compressed Fragment」と断定できない領域Ｂに対してパケットの復号が完了するまで認証処理を実行できないとすると、openSSLで暗号化されたパケットの場合、最低でも２４０バイトは復号処理が完全に終了まで認証処理の入力とすることができない。逆に、パディング長が２５５バイトまたはそれに近い長さを持つときは、認証処理の入力として追加入力するデータは、ごくわずかである。
【００３８】
つまり、「Compressed Fragment」であると確定してから認証処理にデータを入力する従来のハードウェア構成は、パケットサイズが大きいときに効果を発揮するが、一般的に使われているＴＬＳプロトコルの実装に対しては、逆に処理時間のかかる構成となる。
【００３９】
図５は、実施形態の原理を説明する図であり、実施形態で認証処理に入力するデータ長を示す図である。実施形態の特徴は、一般的に多く使われるパディング長である１６バイト以下というサイズに合わせて認証処理を最適化する点にある。パディング長を１６バイト以下と想定することで、パディング長が確定する前に認証処理を進めることできる範囲が拡張される。特に、openSSLといった一般的に広く普及しているＴＬＳの実装プロトコルで処理速度が最大になるように認証処理が最適化される。
【００４０】
図５において、パディング長が不確定のため従来方法で並列処理ができない領域は、「Compressed Fragment」が含まれている可能性のある領域Ｂである。また、認証処理の必要のない箇所は領域Ｃ（１バイトの「Padding Length」とＨＭＡＣサイズを合わせた領域）である。実施形態では、ＴＬＳのパケットの復号時に、領域Ｃの開始点から１６バイト手前までは「Compressed Fragment」が存在すると仮定して、並列処理のために認証処理に入力する。認証処理に入力する領域のサイズＬ１は、「Compressed Fragment」であることが確定している領域ＡのサイズＬ２に、２４０バイトを加算したサイズである。サイズＬ１の領域を、パディング長が確定しない段階で復号処理と認証の並列処理にかける。パディング長が確定してから領域Ｂについての認証を実施する従来の手法に比べて、２４０バイト多く並列処理が可能になる。
【００４１】
ただし、ＴＬＳのプロトコルとしては、パディング長が２５５バイトまで許容されているため、１６バイト以上のパディング長のパケットが来たときに、ＴＬＳのプロトコルで認証ができなくなる。
【００４２】
そこで、「Compressed Fragment」であると確定される領域Ａと、「Compressed Fragment」の可能性がある領域Ｂの境界Ｘに最も近い認証アルゴリズムの出力結果をレジスタに格納しておく。境界Ｘに最も近い箇所での認証の中間出力値を記憶しておくことで、パディング長が１６バイト以上のときは、境界Ｘの最近傍から認証処理を再開する。この構成により、任意のパディング長のＴＬＳプロトコルに対応可能とする。認証の再開処理の詳細は後述する。
【００４３】
１６バイトという数字はＴＬＳの暗号／復号アルゴリズムとしてＡＥＳを想定しているための数字であり、別の暗号／復号アルゴリズムのときは、そのアルゴリズムの暗号ブロックサイズに従う。たとえば、２０１５年現在では使われなくなったが、ＤＥＳ（Data Encryption Standard）を想定する場合はパディング長を８バイト以下と仮定し、３２バイトごとの暗号化方式については、パディング長を３２バイト以下と仮定して並列処理を行う。
【００４４】
図５では、パディング長が１６バイトを超えるパケットに対して領域Ａと領域Ｂの境界Ｘから認証の値を再計算させる構成としているが、これは認証アルゴリズムの中間出力結果を格納する領域（レジスタ）を１つだけ用意する場合の構成である。認証アルゴリズムの中間出力を領域Ｂの複数個所で格納するために複数のレジスタを用意してもよい。その場合は、レジスタの増加分だけ回路サイズが大きくなるが、パディング長が１６バイトをわずかに超えるパケット（パディング長が１７バイト、１８バイト等）に対しても、認証処理の再計算が速くなるというメリットを持つ。
＜第１実施例＞
図６は、第１実施例の復号回路１５Ａの概略構成図である。復号回路１５Ａは、図１の通信装置１０の復号回路１５として用いられる。復号回路１５Ａは、入出力データ転送部１５１、セレクタ１５２、入力パラメータ記憶部１５３、入力データ成型部１５４、認証中間値記憶部１５５、認証用入力提供部１５６、暗号／復号処理部１５７、認証処理部１５８、及び出力データ成型部１５９を有する。実施形態では、認証にＨＭＡＣアルゴリズムを用いる。この点で、認証中間値記憶部１５５を「ＨＭＡＣ中間値記憶部１５５」と称してもよい。同様に、認証用入力提供部１５６を「ＨＭＡＣ入力提供部１５６」と称してもよい。以下では、「ＨＭＡＣ中間値記憶部１５５」及び「ＨＭＡＣ入力提供部１５６」として説明する。
【００４５】
入出力データ転送部１５１は、バス１６から入力パラメータと、入力データの２種類のデータアイテムを受け取る。入力パラメータは、ＴＬＳの暗号化通信で用いられる暗号化鍵、初期化ベクトル（ＩＶ：Initialization Vector）、シーケンスナンバー（SeqNum）、ＴＬＳヘッダ、暗号化アルゴリズム、認証アルゴリズムを含む。入力データは、ＴＬＳのパケットのうちＴＬＳヘッダを除く部分を指す。セレクタ１５２は、それぞれのデータアイテムを入力パラメータ記憶部１５３に送るか、入力データ成型部１５４に送るかを決定する。
【００４６】
入力パラメータ記憶部１５３は、入力パラメータをＴＬＳの復号処理の間保持するとともに、入力パラメータをＨＡＭＣ入力提供部１５６と認証処理部１５８に提供する。入力データ成型部１５４はＴＬＳのパケットの本体部分を受け取り、復号すべきデータを暗号／復号処理部１５７に渡す。
【００４７】
暗号／復号処理部１５７は、ＴＬＳのパケットの暗号化された領域を暗号化ブロック単位で復号する。復号結果は順次出力データ成型部１５９に送られ、入出力データ転送部１５１経由でバス１６上に出力される。復号結果はまた、ＨＭＡＣ入力提供部１５６に送られ、認証アルゴリズムにかける入力データとして扱われる。
【００４８】
ＨＭＡＣ入力提供部１５６は、前記入力パラメータ記憶部１５３から渡される入力パラメータに含まれる暗号化データ長を示す情報（CipherTextLength）と、ＨＭＡＣアルゴリズムに基づいて、認証処理部１５８に認証のためのデータを入力する。実施形態の特徴として、ＨＭＡＣ入力提供部１５６は、図４の「Compressed Fragment」と確定される領域Ａだけではなく、「Compressed Fragment」の復号結果の可能性がある領域Ｂの一部も認証処理部１５８に入力する。認証処理部１５８は、パディング長が確定する前の段階で最大限に並列処理を進める。ＨＭＡＣ入力提供部１５６は、バッファ領域１６５を有する。ＨＭＡＣ入力提供部１５６は、パディング長が１６バイト以上である場合に備えて、許容される最大パディング長である２５５バイトに相当する量のデータまでバッファリングして、認証処理の再計算を可能にする。
【００４９】
認証処理部１５８は、ＨＭＡＣ入力提供部１５６の入力データに基づいて、認証を実行する。このとき、「Compressed Fragment」であることが確定の領域Ａと、「Compressed Fragment」の可能性がある領域Ｂの境界Ｘにて、認証アルゴリズムのデータ境界に最も近く、かつ「Compressed Fragment」であることが確定の領域Ａの認証中間値を一時的に出力して、ＨＭＡＣ中間値記憶部１５５に保存させる。
【００５０】
ＨＭＡＣ中間値記憶部１５５は、領域Ａの境界Ｘの最近傍での「Compressed Fragment」の認証結果を中間値として記憶しておく。ＴＬＳのパケットの最後の復号結果としてパディング長が１６バイト以上であると判明したときに、ＨＭＡＣ中間値記憶部１５５は、ＨＭＡＣ入力提供部１５６に保持していた中間値を提供する。ＨＭＡＣ入力提供部１５６は受け取った中間値とバッファリングしておいた２５５バイト相当のデータを認証処理部１５８に渡して、ＨＭＡＣ値の再計算を可能にする。
【００５１】
出力データ成型部１５９は、暗号／復号処理部１５７からの復号結果と、認証処理部１５８からの認証結果を受けとる。復号結果に含まれるＨＭＡＣ値と、認証処理部１５８で計算されたＨＭＡＣ値が一致するときは、認証成功と判断して、暗号／復号処理部１５７から出力された復号結果を入出力データ転送部１５１に供給する。復号結果の末尾には、パディングとパディング長も付加されているが、この部分については出力してもよいし、しなくてもよい。回路サイズを小さくすることを優先する場合は、復号されたパディングとパディング長をそのまま入出力データ転送部１５１に渡し、後にソフトウェア的な処理で除去してもよい。ソフトウェアの処理を少なくすることを優先する場合、出力データ成型部１５９でハードウェア的にパディング位置を特定し、特定したパディング位置に基づいてパディングとパディング長を除去した形で入出力データ転送部１５１に復号結果を供給してもよい。
【００５２】
図７は、認証処理部１５８のＨＡＳＨ（ハッシュ）処理部１６０のひとつの構成例として、ＨＡＳＨ処理部１６０Ｉを示す。ＴＬＳの認証に用いるＨＡＳＨアルゴリズムは、入力が２つで出力が１つの演算を連続的に繰り返す処理である。入力は、入力データブロックと、事前のＨＡＳＨ計算の出力結果である。一番目のＨＡＳＨ処理については、事前のＨＡＳＨ計算の出力結果は、アルゴリズムごとに決められたＨＡＳＨ初期値を入力する。入力データブロックは、ＴＬＳの復号においては「Compressed Fragment」の復号結果であり、アルゴリズムの要求するブロック長に応じて分割されたものである。ブロック長はSHA1やSHA256では５１２ビットであり、SHA512では１０２４ビットである。図６ではSHA1を想定しており、入力ブロックサイズは５１２ビットとして記載されている。入力データブロックは、ＨＭＡＣ入力提供部１５６を介して認証処理部１５８のＨＡＳＨ処理部１６０Ｉに入力される。入力データブロックとして与える入力がなくなるまでＨＡＳＨ処理を繰り返し、その結果として得られた値がＨＡＳＨの出力となる。
【００５３】
図８は、認証処理部１５８のＨＡＳＨ処理部１６０の別の構成例として、ＨＡＳＨ処理部１６０IIを示す。図８のＨＡＳＨ処理部１６０IIは、ＨＡＳＨモジュール１６１と、ＨＡＳＨモジュール１６１への入力を選択するセレクタ１６２を有する。セレクタ１６２は、ＨＭＡＣ入力提供部１５６からの機能セレクト信号に基づいて、中間値データとＨＡＳＨ初期値を選択する。
【００５４】
図６の復号回路１５Ａでは、パディング長が１６バイト以上であるときに、領域境界ＸからＨＡＳＨの再計算を行う。この場合、ＨＡＳＨ初期値に替えて、「Compressed Fragment」であると確定される領域ＡでのＨＡＳＨ処理の中間出力値をＨＡＳＨ処理部１６０に入力して、ハッシュ化の途中から再計算する。そのため、図８では、ＨＡＳＨ処理の中間出力値（「中間値」とも称する）と、ＨＡＳＨ初期値を選択的に出力するセレクタ１６２を用いる。セレクタ１６２は、ＨＡＳＨモジュール１６１に対して事前の出力結果を次の入力とするインターフェースとして機能する。この構成により、パディング長が１６バイト以下のときは、ＨＡＳＨ初期値から順に計算し、パディング長が１６バイトを超えるときは領域Ａの終端（図５の境界Ｘ）でのＨＡＳＨモジュール１６１の出力を中間値データとして用いて再計算を行う。
【００５５】
ＨＭＡＣ入力提供部１５６は、ＨＡＳＨモジュール１６１を起動させる処理の最初に、機能セレクト信号をＨＡＳＨ処理部１６０IIに入力して、ＨＡＳＨモジュール１６１を起動する。この起動時の機能セレクト信号は、ＨＡＳＨモジュール１６１にＨＡＳＨ初期値が入力されることを指示する。中間値データの選択を指示する機能セレクト信号を供給するか否かは、ＨＭＡＣ入力提供部１５６が復号結果を受け取ってパディング長が確定した段階で決定する。パディング長が１６バイト以下ならば、再計算の必要はないので、ＨＭＡＣ入力提供部１５６は中間値データの選択を指示する機能セレクト信号を出力しない。パディング長が１６バイト以上のときは、中間値データを選択するように指示する機能セレクト信号を出力する。この中間値データの選択を指示する機能セレクト信号は、ＨＡＳＨモジュール１６１の処理を一時中断して、ＨＭＡＣ中間値記憶部１５５のデータをＨＡＳＨモジュール１６１の入力とすることを示す。
【００５６】
この構成により、パディング長を一般的に用いられる１６バイト以下と扱って認証処理を順次進め、パディング長が１６バイト以上のときに、領域の境界Ｘの最近傍から速やかに再計算を開始する。
【００５７】
図９Ａと図９Ｂは、復号回路１５Ａの処理フローである。まず、暗号／復号処理部１５７でＴＬＳの復号が開始されると（Ｓ１１）、認証処理部１５８は入力パラメータ記憶部１５３から復号パラメータを取得する（Ｓ１２）。そして、暗号／復号処理部１５７と認証処理部にて並列に各々の作業を開始する（Ｓ１３）。図の点線で囲まれた領域が並列処理される部分である。
【００５８】
暗号／復号処理部１５７は、ＴＬＳのデータが存在する限りデータを読み込み（Ｓ１４〜Ｓ１５）、ブロック単位で復号処理を実施する（Ｓ１６）。復号結果は順次出力され（Ｓ１７）、入力データの最後まで復号されたところで、パディング長が確定する（Ｓ１８）。
【００５９】
認証処理部１５８は、認証アルゴリズムの初期化を行う（Ｓ２１）。初期化の際に、入力パラメータに含まれる共有鍵（ＨＭＡＣ鍵）を用いるが、本発明の本質ではないので詳細を省略する。初期化が終わると、認証処理部１５８は、ＨＭＡＣ入力提供部１５６を介して復号結果を順次受け取って、認証への入力サイズがＬ１以上であるか否かを判断する（Ｓ２２）。認証への入力サイズがＬ１以上の場合は（Ｓ２２でＹＥＳ）、パディング長は想定どおり１６バイト以下となるので、復号結果を用いてＬ１のサイズまで（領域Ａの終端から２４０バイトまで）認証を行う（Ｓ２３）。復号処理の出力が間に合わない場合はここで待ち合わせが発生する。その後、Ｓ２６へ進んでパディング長の特定（Ｓ１８）を待つ。上記のＬ１の値は、openSSLなどの一般的な実装である１６バイト以下のパディング長を考慮した値である。この値を採用することでパディング長が特定された後の残部の認証処理（すなわち並列化できない部分の認証処理）を極力少ない入力データ量で済ませることができる。
【００６０】
認証への入力サイズがＬ１より小さい場合は（Ｓ２２でＮＯ）、パディング長が１６バイトよりも大きいことを意味する（図５参照）。この場合は、復号処理結果を用いて認証処理を行い（Ｓ２３）、認証への入力サイズが図５の領域ＡのサイズＬ２以下であるか否かを判断する（Ｓ２４）。入力サイズがＬ２以下の場合は（Ｓ２４でＹＥＳ）、「Compressed Fragment」のデータであることが確定しており、この時点での認証結果をＨＭＡＣ中間値記憶部１５５に保持させる（Ｓ２５）。入力サイズがＬ２を超える場合（Ｓ２４でＮＯ）は、「Compressed Fragment」かどうか未確定の領域であるため、認証の出力結果を破棄してＳ２２〜Ｓ２４を繰り返す。Ｓ２２〜Ｓ２４の繰り返しの終了タイミングと、復号処理の終了タイミングは同期する（Ｓ２６）。
【００６１】
図９Ｂに移って、Ｓ１８で特定されたパディング長を用いて、認証の最終処理を行う。すなわち、特定されたパディング長が１６バイト未満か否かを判断する（Ｓ２７）。パディング長が１６バイト未満であれば（Ｓ２７でＹＥＳ）、Ｌ１を超える部分の端数の復号データを認証処理に入力し、認証を行うことで処理終了となる（Ｓ２８〜Ｓ２９）。特定されたパディング長が１６バイト以上のときは、認証出力結果としてＳ２５で保持された値を用いて、認証の再計算を行う（Ｓ３１）。パディング長が１６バイトを超える場合、再計算のために入力されるデータ長は２４０バイト未満であるが、一般的に用いられるパディング長が短いことを考慮にいれると、多くの場合２４０バイトに近い入力量になると考えられる。すなわち、パディング長が１６バイトを超えるパケットについては、復号及び認証処理は公知技術と同等の処理速度となる。
【００６２】
しかし、実施形態の特徴として、openSSLの実装に合わせてパディング長が１６バイト以下のパケットのときに処理速度が最適化される構成としている。公知技術では、領域Ａを超える部分については認証処理を停止させているが、実施形態ではパディング長の仮予測にしたがって領域Ａの終端から２４０バイトのところまで復号処理と並列に認証処理を行っているので、トータルでみると処理速度は向上する。
＜第２実施例＞
図１０は、第２実施例の復号回路１５Ｂの概略構成図である。第２実施例では、通信システム１で送受信するパケットを、パディング長が暗号化の単位ブロックサイズ以下であるＴＬＳのパケットに限定する。これにより認証アルゴリズムの中間出力の保持を省略する。ＡＥＳ規格の場合は、図１の通信システム１は、パディング長が１６バイト以下のＴＬＳのパケットだけを送受信する。
【００６３】
復号回路１５Ｂは、図６の復号回路１５ＡからＨＭＡＣ中間値記憶部１５５を消去した構成を有し、その分、回路構成が簡単になる。また、ＨＭＡＣ入力提供部２５６は、再計算用の２５５バイト分のバッファ領域１６５を有する必要がない。さらに、ＨＡＳＨの再計算用の回路が不要となることから、認証処理部１５８は図７に示す単純な構成のＨＡＳＨ処理部１６０Ｉを有する。
【００６４】
この構成は、図１の通信システム１を、交通監視など、小さいパケットサイズでの送受信を行う用途に適用する場合に効果的である。
＜適用例＞
図１１は、実施形態の通信システム１の適用例を示す。第１実施例の復号回路１５Ａや第２実施例の復号回路１５Ｂは、受信側の通信装置１０の性能が限られており、送信側の送信装置２０が複数存在するときに、さらに効果を発揮する。その一例として、車両通信システムを例にとる。
【００６５】
自動運転などの新技術を視野に入れた自動車の通信は多岐に渡って行われることが想像される。通信装置１０は、例えばクラウドサーバ２０ｓから最新の交通情報を取り入れつつ、近隣の車両の通信装置２０ｃから車両情報を受信する。また、信号に設置された通信装置２０ａから、赤から青に変わるタイミングなどの信号情報を取得し、道路の脇に設置された通信装置２０ｂから最新の道路状況を仕入れる。
【００６６】
一方で、車のような高速で動く移動体では情報の遅延は許されない。通信で得た情報を用いて即座に車の動作を決定しなくては事故が発生するおそれがある。そのため、車両に搭載されたＣＰＵが通信処理に占有されるのは望ましくなく、通信処理をハードウェア化して、処理をオフロードすることが望ましい。この点、第１実施例の復号回路１５Ａや第２実施例の復号回路１５Ｂは有用である。
【００６７】
図１１の状況では、復号回路１５Ａ、１５Ｂの高速化も効果を発揮する。複数の通信装置２０が同時にデータを送信してくるため、受信したデータを即座に復号して、次の処理に供給しなければならない。高速化は極めて重要な要件である。車両の機器を制御するファームウェアのアップデートなどの要件から、通信装置１０はバッテリー駆動で動作できるほどの低消費電力であることが望ましい。この観点から、動作クロックは小さいほど良いという要件もある。
【００６８】
実施形態のように、ＨＡＳＨ計算を２４０バイト分多く並列処理する復号回路１５Ａまたは１５Ｂを導入することで、ＨＡＳＨ処理５回分の処理時間を短縮することができる。換言すると、ＨＡＳＨ計算時間を、１処理当たり６４バイト速くできる。ＨＡＳＨは、特定の処理を８０回繰り返すイテレーション処理で構築されるため（図７参照）、少なくとも一回の処理に８０クロックかかる。復号回路１５Ａまたは１５Ｂによる高速化の恩恵は４００クロック分にわたる。動作クロックを下げる要件から８ｋＨｚで動作させることを想定すると、４００クロックの差にかかる時間は０．０５秒である。通信相手となる通信装置２０が６つある場合は、０．３秒の処理の短縮化が可能である。高速道路の走行では、車両は０．３秒で１０メートル近く進むため、従来方法の０．３秒の処理の遅れが事故につながる可能性もある。
【００６９】
実施形態では、復号と認証の並列処理が可能な範囲を拡張し、任意のパケットサイズのデータに対して復号処理を高速化することで、高速処理を要する任意の通信システムへの適用が実現する。
【符号の説明】
【００７０】
１  通信システム
１０  通信装置（受信装置）
１１  ＣＰＵ（制御部）
１４  外部インタフェース（通信インタフェース）
１５、１５Ａ、１５Ｂ  復号回路
２０  通信装置（送信装置）
２１  ＣＰＵ（制御部）
２４  外部インタフェース
２５  暗号化回路
１５１  入出力データ転送部
１５２  セレクタ
１５３  入力パラメータ記憶部
１５４  入力データ成型部
１５５  ＨＭＡＣ中間値記憶部（認証中間値記憶部）
１５６、２５６  ＨＭＡＣ入力提供部（認証入力提供部）
１５７  暗号／復号処理部（復号処理部）
１５８  認証処理部
１５９  出力データ成型部
１６０、１６０Ｉ、１６０II  ＨＡＳＨ（ハッシュ）処理部
１６１  ＨＡＳＨモジュール
１６２  セレクタ
【先行技術文献】
【特許文献】
【００７１】
【特許文献１】特開２０１３−００９２７６号公報
【図１】
2017011392.tif 000003
【図２】
2017011392.tif 000004
【図３】
2017011392.tif 000005
【図４】
2017011392.tif 000006
【図５】
2017011392.tif 000007
【図６】
2017011392.tif 000008
【図７】
2017011392.tif 000009
【図８】
2017011392.tif 000010
【図９Ａ】
2017011392.tif 000011
【図９Ｂ】
2017011392.tif 000012
【図１０】
2017011392.tif 000013
【図１１】
2017011392.tif 000014