JP5778066B2 - ファイアウォールを利用した認証方法 - Google Patents

Description

この発明は、中継装置がポートを開ける際の認証方法に関する。

従来のネットの利用は、ユーザ端末側からサーバへリクエストを送り、そのレスポンスを受け取るものであった。しかし、スマートフォンの普及に伴って、外出先から自宅のネットワークにリモートアクセスして自宅のホームネットワークファイルサーバを利用したり、ＩＰ電話ソフトを使って通話させるために外部から通話を呼び出したりといった形で、外部からの要求に応じてソフトウェアを起動させる利用方法が拡大している。

しかし、そのような外部ネットワークからのアクセスを受けるためにポートを開け放っておくと、そこがセキュリティホールとなってしまう。これに対して、そのポートで待ち受けているアプリケーションの中でユーザＩＤ／パスワードなどを用いて認証することによりセキュリティを確保する手法が知られている。しかしこの手法が安全であるには、そのアプリケーションがパケットを受信してから認証を行うまでのシーケンスの中にセキュリティホールが存在しないことが前提となる。実際にはそのようなネットワークソフトウェアにセキュリティホールが無いことは担保できない。

従って、通信アプリケーションで発生するセキュリティリスクを最大限に回避するには、不正パケットを当該アプリケーションに一切読み込ませないことが望ましい。そのためには、平常時はアプリケーションを停止させておき、必要に応じて立ち上げることができれば理想的である。

これに類する方法として、特許文献１にポート開放要求の取り扱い手法が提示されている。この技術は、外部からポート開放要求を受ければ、その開放要求を認証し、認証に成功すれば配下端末リストを応答し、端末名を相手に指定させて、該当ポートを開くものである。

また他の方法として、特許文献２にはＩＰ電話に関する技術として、なりすましによる不正アクセスパケットを排除するため、相手端末と音声通信を開始するＩＰ電話端末において、音声パケットに適用すべき宛先ポート番号を互いに指定し合って、受信パケットの送信元ＩＰアドレスと宛先ポート番号をチェックして、受信パケットが不正パケットと判断された場合は、受信パケットを廃棄するという手法が提案されている。

特開２００８−７８８２３号公報 特開２００８−２１７６６８号公報

しかしながら、特許文献１に記載の手法では、「必要である」という事を外部から通知するために別のアプリケーションを使用する以上、そのアプリケーションにはポート開放要求を待ち受ける機能を持たせることになる。この機能そのものがセキュリティホールを有していた場合、ネットワークからのアタックを防ぎきれなくなるおそれが高くなる。

また、特許文献２に記載の手法では、認証行為をアクセス対象機能（ＳＩＰ機能）自身が実施している。該当パケットを対象機能自身が受け取って処理してしまっているため、パケットの受信から認証完了までのフローにセキュリティホールが内在していた場合に対応できなかった。

そこでこの発明は、セキュリティリスクがより低い手法で、外部からのリクエストにより通信を開始できるようにすることを目的とする。

この発明は、外部ネットワークからアクセスしようとする外部リクエスト端末と、ファイアウォールを有しそのアクセスを受け付ける中継装置やユーザ端末などの通信機能付き機器とに、予め定めた認証の書式を記録しておき、
上記外部リクエスト端末は、その認証の書式に沿った認証用データを、ＴＣＰやＵＤＰなどのパケットのポート番号として埋め込み可能なサイズに分割し、一連のパケットのポート番号部分に埋め込み順番に連続して上記機器へ送出し、
上記通信機能付き機器は、ファイアウォールで受信したパケットのポート番号の連続するパタンを監視して、記録しておいた上記の認証の書式を参照し、そのパタンが上記の認証の書式に沿ったものであることを検出したら、アクセスを受け入れるために上記ファイアウォールにアクセスのためのポートを開放したり、アクセスを受け入れる所定のソフトを立ち上げたりするようにすることで、上記の課題を解決したのである。

すなわち、ファイアウォール機能におけるパケット情報の取得処理は必ず実施しなければならない処理であるが、上記機器で実施される実施される処理の中でも、最も早い段階で処理されるものである。そこに認証機能を持たせることによって、セキュリティホールに繋がるような新たな受け付け用ポートの常時開放を行わなくても、リクエストの受付が可能となる。ファイアウォール機能が触れる情報は、ＩＰヘッダやＴＣＰ／ＵＤＰヘッダに」設定されている、ＩＰアドレスやポート番号といったごく単純な情報であるため、悪意あるユーザがパケットを工夫してバッファオーバーフローなどの不具合を誘発させることが難しい。もしＩＰヘッダやＴＣＰ／ＵＤＰヘッダなどの基本的な情報を改変すると、途中のルータなどで正しくルーティングされなかったりしてそもそも上記機器まで到達させることが難しくなるので、外部からアクセスする際にこれらの部分に異常値を紛れ込ませられる可能性は低い。このためファイアウォール自体の高い安全性も保持できる。また、一つのパケットのポート番号ではなく、連続するパケットのポート番号を一揃えで認証することで、認証に必要なｂｉｔ数を確保することができ、総当たりで突破することも難しいものとすることができる。

具体的には、上記機器のファイアウォール機能部に、受信したパケットのポート番号を取得するパケット情報取得部を持たせ、
また、ファイアウォール機能部によってソフトウェアとして外部から守られた部分に、認証のための数列を記録する鍵テーブルと、前記の取得されたパケットのポート番号の連続を、その鍵テーブルと比較参照するパタン解析部とを有する認証機能部を持たせ、認証に成功したらファイアウォールのポートを開けたり、ＩＰ電話用ソフトなどのアクセスを受け入れるソフトウェアを起動させたりするアクセス対象機能部を実行させる。対する、外部からアクセスしようとする端末には、予め定めた認証の書式に従い上記の数列に適合したデータを連続するパケットのポート番号に埋め込んで、連続送出する認証情報埋込パケット連続送出機能を持たせる。

ここで、認証のための数列とは、例えば１６ビットで表せる範囲の数値の連続からなる数列を受信パタンとして予め取り決めておいてもよいし、認証用の共通鍵と上記機器が認識する外部リクエスト端末の送信元ＩＰアドレスとからハッシュ値を生成させて１６ｂｉｔごとに分けた数列を認証のたびに自動的に生成するものでもよい。外部リクエスト端末がそれに適合するデータを送出する際には、その数列を個々の数値ごとに分けて連続するパケットの送信元ポート番号や宛先ポート番号の項目にそのまま埋め込むという方式や、所定の暗号化を施した上で埋め込んでも良い。例えば１２８ｂｉｔのＭＤ５であれば、８箇所のポート番号に埋め込むことで送出できる。上記鍵テーブルにはこの数列や変換された数字列が比較可能な形式で常時保存又は一時保存される。１６ｂｉｔごとに分けられた形で格納されていると比較しやすい。なお、共通鍵を用いる場合には、上記機器は鍵テーブルとは別にそれを記憶部に保存しておき、上記外部リクエスト端末も共通鍵を保持しておく必要がある。

上記の数列は長い方がセキュリティ強度は高くなるが、その分必要とするパケット数が増えるため、パケットロスによりパケットが届かずに認証に失敗する可能性も高くなる。このため、外部リクエスト端末は、認証用に用いる一連のパケットを、一定間隔を置きながら何度か送信するとよい。

この認証の書式に従ったデータの送出に用いるポート番号部分は、パケットの送信元ポート番号と宛先ポート番号との二箇所があってそれぞれ１６ｂｉｔの長さを持っており、いずれかを単独で認証に用いたり、両方を認証に用いてもよい。両方を用いる方が少ないパケット数でデータを送信できる。ただし、宛先ポートによってはすでに特定の番号にファイアウォールに許可ルールが設定されていたり、何らかのアプリケーションが待ち受けている可能性があるため、比較的自由に設定できる送信元ポート番号のみを認証に使うとエラーが比較的起こりにくくなる。

この発明により、外部のネットワークから通信を行う場合、平常時は当該通信を行うアプリケーションを停止させておいたり、ポートを閉じておいたりすることができ、セキュリティリスクを低減させることができる。そして、必要時には安全な方法でアプリケーションを外部から起動させたり、ポートを開かせたりすることができる。

この発明にかかる中継装置の機能ブロック図 この発明の実施形態を進める際のシーケンス図 送信元ポート番号のみを用いる場合の鍵テーブルの例 ファイアウォール機能部におけるフロー例図 鍵テーブルが固定である場合の認証フロー例図 鍵テーブルを動的生成させる場合の認証フロー例図 鍵テーブルの動的生成フロー例図

以下、この発明について具体的な実施形態を挙げて説明する。
外部ネットワーク３に接続された外部リクエスト端末２から、ファイアウォールに保護された機器にアクセスする実施形態として、ここでは中継装置１へのアクセスを行う場合を例に説明する。図１はこの実施形態でアクセスする機器である中継装置１の機能ブロック図であり、図２はこの実施形態を進める際のシーケンス図である。

中継装置１は、内部ネットワーク４と、外部ネットワーク３との間にある中継装置であり、例えば家庭用ルータなどのホームゲートウェイのようなゲートウェイとして機能する装置である。外部ネットワーク３からのアクセスに対しては、一部のパケットのみ通過させるファイアウォール機能を発揮させる。

内部ネットワーク４とは、家庭用ルータなどである中継装置１で外部ネットワーク３と区切られた、ホームネットワークなどのネットワークである。一般家庭のＬＡＮや、特定の法人内ＬＡＮでもこの発明は実施可能である。

外部ネットワーク３とは、内部ネットワーク４とは中継装置１で区切られた、特定個人又は一般の法人が管理するものではなくセキュリティリスクを有するネットワークであり、一般的にはインターネットである。ただし、特定の通信事業者によって管理される広域ネットワークでも本発明は利用可能である。

外部リクエスト端末２は、外部ネットワーク３に直接又は間接に接続され、内部ネットワーク４の中継装置１又は内部端末５に対してアクセスを求めるものである。例えば、ファイルサーバ機能を起動させてファイルを読み出そうとするノートパソコンや、ＩＰ電話による発呼を行おうとするフィーチャーフォン、スマートフォンなどが挙げられるが、ＵＤＰ／ＴＣＰパケットを送出するネットワーク機能を有する端末であれば特に限定されるものではない。携帯端末である必要もなく、デスクトップパソコンやブレードサーバなどであってもよい。

中継装置１は、外部ネットワーク３からの通信に対して防護を行うファイアウォール機能部１０と、ファイアウォール機能部１０で受けた情報を元に認証を行う認証機能部２０と、アプリケーションの起動やポートの開放などを行わせるアクセス対象機能部３０とを有するほか、図示しないが、通信を中継するゲートウェイ機能、ルーティング機能など、中継装置として一般的な機能を有する。また、必要に応じて記憶部に後述する共通鍵を保持する。

ファイアウォール機能部１０は、特定の宛先ポート番号以外のパケットを破棄する等といった所定の条件に従い不要或いは危険なパケットを破棄するパケット破棄機能を実行し、中継装置１自身及び内部ネットワーク４内に、不正なパケットが侵入することを防止するソフトウェア又はその機能を有するチップなどのハードウェアである。ただし、パケットの破棄の有無に関わらず、受信したパケットのヘッダ部分の情報を取得するパケット情報取得部１１を有し、その情報を次の認証機能部２０へ渡すパケット情報受渡機能も実行する。

認証機能部２０は、予め定めた認証の書式に従った数列を記録する鍵テーブル２２と、
前記の取得されたパケットのうち同一の送信元アドレスから送信されたものに含まれるポート番号の連続を、前記の鍵テーブルと比較参照して認証するか否かを判断するパタン解析部２１とを有する。鍵テーブル２２は、最初から定めた数列であったり、予め外部リクエスト端末２と共有した共通鍵を用いてハッシュ値を算出する数列生成機能を実行することで生成させて一時的に記録するものであったりする。パタン解析部２１は、その鍵テーブル２２とパケット情報取得部１１の前記パケット情報受渡機能から送られてきたパケットの情報とを比較、或いは計算処理して、送られてきたパケットのポート番号の連続によるパタンが認証の条件を満たしているか否かを判断する認証解析機能を実行し、認証されたら後述のアクセス対象機能部３０へ実行指示を出す実行指示機能を実行する。また、処理に時間制限を設けるためのタイマ２４を有する。

上記の鍵テーブル２２の例を図３に示す。この例では、受信すべきパケットのプロトコルがＵＤＰで、宛先ポート番号は特に限定されないが、同一の送信元ＩＰアドレスから発せられた連続して受信した８つのパケットの送信元ポート番号が順番に「１０００１，１０００２，１０００１，１００１０，２００００，１２３４５，２００００，１０００１」であった場合にのみ認証を通過させるものである。順序を考慮しなくても実施可能であるが、パタン解析部２１の負担が上がることと、セキュリティは低下するため、順番も鍵テーブル２２の通りとなっていることが好ましい。

なお、このような鍵テーブル２２又はその元となる共通鍵は、複数個あってもよい。鍵テーブル２２ごとに認証通過後に起動させるアプリケーションを変えたり、開放させるポートを変えたりすることができる。

また、上記の鍵テーブル２２の例としては、このような固定的なテーブルではなく、共通鍵のみ保持しておき、パケットを受信しはじめたら、そのパケットのＩＰヘッダに含まれる送信元ＩＰアドレスなどの変動要素と共通鍵とから動的に鍵テーブル２２を生成してもよい。この場合、認証を行う外部リクエスト端末２も、共通鍵と自身のＩＰアドレスから同じ文字列を生成して、順にパケットに載せて送出することで認証が可能となる。

アクセス対象機能部３０は、外部リクエスト端末２が起動を求めるアプリケーションを起動させたり、所定のポートを開放したりといった、外部リクエスト端末２が必要とする通信確立のための処理を実行する。アプリケーションを起動させる場合、中継装置１が内部端末５に起動させる場合と、中継装置１自体がサーバとしてサービスを起動させる場合と、内部端末５自体が自らアプリケーションを起動する場合とがある。また、このアクセス対象機能部３０が実際に実行する形態は一つである必要はなく、認証されたパタン（すなわち鍵テーブル２２の中身や共通鍵の種類など）の違いによって、異なるアプリケーションを起動させたり、異なるポートを開放させたりしてもよい。アクセスを求める外部リクエスト端末２の求める機能は特に制限なく、ファイルサーバ機能やＩＰ電話機能や、ネットワークに繋がったＨＤＤレコーダの予約など、内部ネットワーク４のどの内部端末５次第でもあり、必要な機能は様々だからである。

このような中継装置１に対して、外部リクエスト端末２は、そのままでは必要とする機能を起動させられず、アクセスできないので、中継装置１は一定のセキュリティを保持している。例えば、ＩＰ電話用アプリケーションが内部端末５で立ち上がっていなければ、パケットを送っても意味がない。そこで、連続するパケットに、上記の鍵テーブル２２に対応した認証情報を載せて送出する。ここで、受信パタンが固定されている場合はそのパタン通りに送出し、共通鍵と送信元ＩＰアドレスから動的にテーブルを生成する場合は、中継装置１にパケットが到着する際の送信元ＩＰアドレスを取得して、算出し、動的な数字列であるテーブルを生成させる。

このパケットを受信するファイアウォール機能部１０の動作フローについて、図４を用いて説明する。まず（Ｓ１０１）、外部ネットワーク３から送信されてきたパケットをファイアウォール機能部１０にて受信する（Ｓ１０２）。なお、実際には中継装置１の中ではネットワークインターフェース部分が最初に受信することになるが、ここでは信号をパケットの形に復元した以降の扱いについて述べる。ファイアウォール機能部１０のパケット情報取得部１１は、パケットのヘッダ情報を取得する（Ｓ１０３）。ここでパケットのペイロードまでチェックしないことによりファイアウォール機能部１０のセキュリティを維持することが望ましい。このヘッダ情報を得た後、次の二つの処理（Ｓ１０４及びＳ１１１）を並列に、又は遅延しすぎない程度に前後して進行させる。すなわち、Ｓ１０４及びＳ１１１はどちらが先でも構わない。

このＳ１０４で実行するファイアウォール処理機能は、一般的なファイアウォールと同様に、所定のファイアウォールのルールに従ったパケットの中継又は破棄である。パケット情報取得部１１で得たパケットのヘッダ情報から、中継を認めていない宛先ポート番号のパケットや、アクセスを許否する送信元ＩＰアドレスのパケットなどを破棄することで、中継装置１より中の内部ネットワーク４のセキュリティを維持する。一方で、中継が認められているポート番号及びアドレスを有するパケットは中継する。ファイアウォールの基本的機能としてはそれで完了となる（Ｓ１０５）。

ファイアウォール機能部１０は、上記のパケットの中継又は破棄と、並列又は前後して、パケット情報取得部１１で得られたパケットのヘッダ情報（基本的には「ＩＰヘッダ」「ＵＤＰヘッダ」「ＴＣＰヘッダ」であり、以下、まとめて「パケット情報」と略記することがある。）を認証機能部２０のパタン解析部２１へ通知するパケット情報通知機能を実行する（Ｓ１１１）。ここで通すのはパケットそのものではなく、抽出したヘッダの情報のみであり、バッファオーバーフローによって突破される可能性を低く抑えている。なお、通知は１つのパケットを受信するごとに行い、ファイアウォール機能部１０自身でバッファに一時保持して複数のパケット分の情報をまとめて送ることもできる。

この通知を受けて次の認証処理へ移る（Ｓ１１２→Ｓ１５４）。認証機能部２０における実施形態は、鍵テーブル２２の中身が予め固定されている場合と、動的に生成する場合との二通りが挙げられる。先に、図５を用いて鍵テーブル２２の数列が予め設定されている場合のフローについて説明し、次に図６及び７を用いて鍵テーブル２２を動的生成する場合のフローについて説明する。

図５は、鍵テーブル２２の数列が予め設定されている場合の、認証機能部２０における処理フロー図である。フローにおける変数ｉの初期値は１（Ｓ１５２）、送信元アドレスを格納する変数ａの初期値はｎｕｌｌである（Ｓ１５３）。この状態で、パケット情報取得部１１から得たパケットのヘッダ情報を取得して処理を開始する（Ｓ１１２＝Ｓ１５４）。

フローとしては、ここで後述するタイマ２４による制限時間が満了したか否かを判断し、満了していれば別フローへ移る（Ｓ１５５→Ｙｅｓ，Ｓ１５６）。初期時点ではタイマ２４による制限時間が設定されていないのでここは次へ移る（Ｓ１５５→Ｎｏ）。アイドル時は、パケット情報取得部１１からパケット情報が通知されるまで待機する（Ｓ１５７→Ｎｏ→Ｓ１５８→Ｓ１５４）。パケット情報が通知されたら（Ｓ１５７→Ｙｅｓ）、処理を開始する（Ｓ１６１）。

初期時点ではｉ＝１であるので（Ｓ１６１→Ｙｅｓ）、送信元アドレスのチェック（後述するがＳ１６２で行う。）を省き、パケット情報に含まれるポート番号（仮に、送信元ポート番号又は宛先ポート番号のみを使う場合を想定する。）を、鍵テーブル２２のｉ＝１番目のエントリと比較する（Ｓ１６３）。一致していなければ（Ｓ１６３→Ｎｏ）、それは本発明を利用した認証のためのパケットではないと判断して（Ｓ１６４→Ｓ１７２）、設定値は初期値のままで（Ｓ１７３，Ｓ１７４）タイマ２４も発動させていないが（Ｓ１７５）、そのまま最初に戻る（Ｓ１７６→Ｓ１５４）。鍵テーブル２２のｉ＝１番目のエントリと一致していれば（Ｓ１６３→Ｙｅｓ）、ここでは最初のエントリなので（Ｓ１６５→Ｙｅｓ）、当該パケットの送信元アドレスを変数「ａ」に代入し（Ｓ１６６）、タイマ２４による時間カウントを開始する（Ｓ１６７）。これはすなわち、所定の時間内に同一の送信元アドレスから来たパケットについてのみ、認証のために鍵テーブル２２のエントリと一致しているかを続けて確認するための条件である。基本的に鍵テーブル２２のエントリは、偶然の一致での突破を極めて起こりにくくするために複数個からなっており、エントリ数は１ではないため（Ｓ１６８→Ｎｏ）、変数ｉを＋１して（Ｓ１６９）、次のパケットを待つ（Ｓ１７０→Ｓ１５４）。

二つ目以降のパケット待ちの折に、タイマ２４によって先に定められた制限時間がすでに経過していれば（Ｓ１５５→Ｙｅｓ）、タイムアウトとみなして（Ｓ１５６→Ｓ１６４）、ｉ＝１に戻し（Ｓ１７３）、変数「ａ」から送信元アドレスをクリアし（Ｓ１７４）、タイマ２４による時間をリセットして（Ｓ１７５），再び鍵テーブル２２の一つ目のエントリに一致するパケットが来るのを待つ（Ｓ１７６→Ｓ１５４→Ｓ１５５→Ｓ１５７→Ｓ１５８→Ｓ１５４）。

タイマ２４による制限時間内で（Ｓ１５５→Ｎｏ）次のパケットを受け取ったら（Ｓ１５７→Ｙｅｓ）、今度は（Ｓ１６１→Ｎｏ）そのパケットの送信元アドレスが、変数「ａ」に格納した先のパケットの送信元アドレスと一致するか否かを判断する（Ｓ１６２）。一致しなければ（Ｓ１６２→Ｎｏ）、それは現在認証保留中の一連のパケットとは別の送信元から発せられたものであるため、認証を行わず次のパケットを待つ（Ｓ１６３→Ｓ１５４）。ここはすなわち、二つ以上の送信元アドレスからの認証を同時に受け付けて処理が錯綜することを避けるためのフローである。この場合、仮に後から認証を行おうとした送信元は最初から一連のパケットを再送信して認証を試みることになる。

送信元アドレスが変数「ａ」に格納した先の送信元アドレスと一致していれば（Ｓ１６２→Ｙｅｓ）、引き続いて、そのパケットのヘッダの送信元ポート番号が、鍵テーブル２２のｉ番眼のエントリと一致しているか否かを判断する（Ｓ１６３）。一致していなければ（Ｓ１６３→Ｎｏ）、そこまでの一致が偶然であったか、あるいは認証のミスであるか、いずれにしても認証の失敗として（Ｓ１６４→Ｓ１７２）、変数とタイマを初期値に戻して（Ｓ１７３〜Ｓ１７５）、次のパケットを待つ（Ｓ１７６→Ｓ１５４）。一致していれば（Ｓ１６３→Ｙｅｓ）、ｉ番目までは鍵テーブル２２のエントリと一致したということになる（Ｓ１６５→Ｎｏ）。そこまでが鍵テーブル２２のエントリの全てでなければ（Ｓ１６８→Ｎｏ）、変数ｉに＋１して（Ｓ１６９）認証作業を続ける。その時点のｉが鍵テーブル２２のエントリ数に到達していたら（Ｓ１６８→Ｙｅｓ）、認証成功と判断して（Ｓ１７１）、アクセス対象機能部３０を起動させ、必要なポートを開放する。その後、次の認証に備えて変数をリセットする（Ｓ１７３〜Ｓ１７５）。

なお、この図５のフローで、宛先ポート番号と送信元ポート番号との両方を用いる場合は、いずれのポート番号を先に取り扱うものかを、送信する外部リクエスト端末２と中継装置１との両方に同一の設定で保存しておき、Ｓ１６１のパケット情報との鍵テーブル２２のエントリとの対比を、ｉ番目だけでなく（ｉ＋１）番目と同時に行い、Ｓ１６９のｉの加算を＋１ではなく＋２とし、Ｓ１６８の判断を「鍵テーブル２２のエントリ数は（ｉ＋１）以下か？」と変更する。

図６は、鍵テーブル２２を生成する場合の認証機能部２０における処理フロー図である。ただしこのフローを実行する前に、認証しようとする外部リクエスト端末２のＩＰアドレスの条件値を保有しておくとよい。具体的には、特定の携帯電話キャリアのＩＰアドレス範囲や、特定のプロバイダ、特定の法人が保有するＩＰアドレス範囲を保有しておき、サービスの対象となるそれらのＩＰアドレスに対してのみ本発明を実行することができる。

まず（Ｓ２１１）、フローにおける変数ｉの初期値は１（Ｓ２１２）、生成前に鍵テーブル２２をクリアする（Ｓ２１３）。この状態で、パケット情報取得部１１から得たパケットのヘッダ情報を取得して処理を開始する（Ｓ１１２＝Ｓ２１４）。

フローとしては、ここで後述するタイマ２４による制限時間が満了したか否かを判断し、満了していれば別フローへ移る（Ｓ２１５→Ｙｅｓ，Ｓ２１６）。初期時点ではタイマ２４による制限時間が設定されていないのでここは次へ移る（Ｓ２１５→Ｎｏ）。アイドル時は、パケット情報取得部１１からパケット情報が通知されるまで待機する（Ｓ２１７→Ｎｏ→Ｓ２１８→Ｓ２１４）。パケット情報が通知されたら（Ｓ２１７→Ｙｅｓ）、送信元ＩＰアドレスが認証対象のＩＰアドレスか否かを判断する（Ｓ２１９）。例えば携帯電話キャリアが違ったり、プロバイダが違うなど、認証対象のＩＰアドレスでなければ（Ｓ２１９→Ｎｏ）、当該パケットは無視して再びパケットの通知を待つ（Ｓ２２０→Ｓ２１４）。一方、認証対象のＩＰアドレスであれば、処理を開始する（Ｓ２２１）。

初期時点ではｉ＝１であるので（Ｓ２２１→Ｙｅｓ）、鍵テーブル２２の動的な生成処理を行う（Ｓ２２２）。

この動的生成のフローについて図７を用いて説明する。まず（Ｓ２５１）、取得した送信元ＩＰアドレスと共通鍵とからハッシュ値を計算する（Ｓ２５２）。また、新たに生成することになるので鍵テーブル２２はここで初期化する（Ｓ２５３）。ここで、中継装置１と外部リクエスト端末２とが認証のために使用するポート番号がいずれかによって扱いが変わる（Ｓ２５４→Ｓ２５５〜Ｓ２５７）。送信元ポート番号のみを認証に用いる場合は、鍵テーブル２２に対して、上記の算出したハッシュ値を２バイト（１６ｂｉｔ）ずつに分割した値を、送信元ポート番号の項目に割り当て設定したエントリを追加する（Ｓ２５５）。このとき、上記の図３のように宛先ポート番号は指定しない「ａｎｙ」となり、どのような値であれ条件を満たすものとなる。エントリ数は、ハッシュ値が１２８ｂｉｔであれば、図３のように８エントリとなる。宛先ポート番号と送信元ポート番号との両方を認証に用いる場合は、鍵テーブルに対して、上記の算出したハッシュ値を２バイト（１６ｂｉｔ）ずつに分割した値を、宛先ポート番号と、送信元ポート番号の項目に割り当て設定したエントリを追加する（Ｓ２５６）。順番はどちらが先でもよいが、システム全体を通してどちらが先かを統一しておく必要がある。宛先ポート番号のみを認証に用いる場合は、鍵テーブル２２に対して、上記の算出したハッシュ値を２バイト（１６ｂｉｔ）ずつに分割した値を、宛先ポート番号の項目に割り当て設定したエントリを追加する（Ｓ２５７）。このとき、送信元ポート番号は指定しない「ａｎｙ」となり、どのような値であれ条件を満たすものとなる。これらいずれかの手法で鍵テーブル２２を生成する（Ｓ２５８）。

再び図６のフローの説明に戻る（Ｓ２２２〜）。ここで、タイマ２４による制限時間のカウントを開始する（Ｓ２２３）。動的生成させた鍵テーブル２２について、別途有効期限を設定しておき、その設定した時間を超えたら鍵テーブル２２を破棄することで、認証を不正に突破される可能性を低下させるためである。それから、パケット情報に含まれるポート番号（仮に、送信元ポート番号又は宛先ポート番号のみを使う場合を想定する。）を、鍵テーブル２２のｉ＝１番目のエントリと比較する（Ｓ２３１）。一致していなければ（Ｓ２３１→Ｎｏ）、それは本発明を利用した認証のためのパケットではないと判断して（Ｓ２３２→Ｓ２４２）、設定値は初期値のままで（Ｓ２４３），鍵テーブル２２を初期化し（Ｓ２４４）、タイマ２４を停止させて（Ｓ２４５）、そのまま最初に戻る（Ｓ２４６→Ｓ２１４）。鍵テーブル２２のｉ＝１番目のエントリと一致していれば（Ｓ２３１→Ｙｅｓ）、ここでは最初のエントリでかつ基本的に鍵テーブル２２のエントリは偶然の一致での突破を極めて起こりにくくするために複数個からなっているので、エントリ数は１ではなく（Ｓ２３３→Ｎｏ）、変数ｉを＋１して（Ｓ２３４）、次のパケットを待つ（Ｓ２３５→Ｓ２１４）。

二つ目以降のパケット待ちの折に、タイマ２４によって先に定められた制限時間がすでに経過していれば（Ｓ２１５→Ｙｅｓ）、タイムアウトとみなして（Ｓ２１６→Ｓ２４２）、ｉ＝１に戻し（Ｓ２４３）、鍵テーブル２２を初期化し（Ｓ２４４）、タイマ２４による制限時間をリセットして（Ｓ２４５），再び鍵テーブル２２の一つ目のエントリに一致するパケットが来るのを待つ（Ｓ２４６→Ｓ２１４→Ｓ２１５→Ｓ２１７→Ｓ２１８→Ｓ２１４）。

タイマ２４による制限時間内で（Ｓ２１５→Ｎｏ）次のパケットを受け取ったら（Ｓ２１７→Ｙｅｓ）、今度は（Ｓ２２１→Ｎｏ）そのパケットの送信元アドレスが、現在扱っている認証対象のＩＰアドレスと一致するか否かを判断する（Ｓ２２５）。一致しなければ（Ｓ２２５→Ｎｏ）、それは現在認証保留中の一連のパケットとは別の送信元から発せられたものであるため、認証を行わず次のパケットを待つ（Ｓ２２６→Ｓ２１４）。ここはすなわち、二つ以上の送信元アドレスからの認証を同時に受け付けて処理が錯綜することを避けるためのフローである。この場合、仮に後から認証を行おうとした送信元は最初から一連のパケットを再送信して認証を試みることになる。

送信元アドレスが現在扱っている認証対象の送信元アドレスと一致していれば（Ｓ２２５→Ｙｅｓ）、引き続いて、そのパケットのヘッダの送信元ポート番号（又は宛先ポート番号）が、鍵テーブル２２のｉ番目のエントリと一致しているか否かを判断する（Ｓ２３１）。一致していなければ（Ｓ２３１→Ｎｏ）、そこまでの一致が偶然であったか、あるいは認証のミスであるか、いずれにしても認証の失敗として（Ｓ２３２→Ｓ２４２）、変数と鍵テーブル２２とタイマを初期値に戻して（Ｓ２４３〜Ｓ２４５）、次のパケットを待つ（Ｓ２４６→Ｓ２１４）。一致していれば（Ｓ２３１→Ｙｅｓ）、ｉ番目までは鍵テーブル２２のエントリと一致したということになる。そこまでが鍵テーブル２２のエントリの全てでなければ（Ｓ２３３→Ｎｏ）、変数ｉに＋１して（Ｓ２３４）認証作業を続ける。その時点のｉが鍵テーブル２２のエントリ数に到達したら（Ｓ２３３→Ｙｅｓ）、認証成功と判断して（Ｓ２４１）、アクセス対象機能部３０を起動させ、必要なポートを開放する。その後、次の認証に備えて変数をリセットする（Ｓ２４３〜Ｓ２４５）。

なお、この図５のフローで、宛先ポート番号と送信元ポート番号との両方を用いる場合は、いずれのポート番号を先に取り扱うものかを、送信する外部リクエスト端末２と中継装置１との両方に同一の設定で保存しておき、Ｓ１６１のパケット情報との鍵テーブル２２のエントリとの対比を、ｉ番目だけでなく（ｉ＋１）番目と同時に行い、Ｓ１６９のｉの加算を＋１ではなく＋２とし、Ｓ１６８の判断を「鍵テーブル２２のエントリ数は（ｉ＋１）以下か？」と変更する。

以上の中継装置１を用いた認証方法は、パーソナルファイアウォール機能を有するパソコンやサーバ、スマートフォンが、中継装置１で外部ネットワーク３と区切られた内部ネットワーク４内に存在している場合でも実行可能である。すなわち、上記の実施形態と同様に、端末自体のパーソナルファイアウォールであるファイアウォール機能部にパケット情報取得部を有するものとさせ、共通鍵又は鍵テーブルと、パタン解析部を有する認証機能部を有するものとさせ、アクセス対象機能部により、具体的に電話ソフトなどのアプリケーションを立ち上げたりするようにすればよい。

１ 中継装置
２ 外部リクエスト端末
３ 外部ネットワーク
４ 内部ネットワーク
５ 内部端末
１０ ファイアウォール機能部
１１ パケット情報取得部
２０ 認証機能部
２１ パタン解析部
２２ 鍵テーブル
２４ タイマ
３０ アクセス対象機能部

Claims (7)

1. 外部ネットワークからアクセスしようとする外部リクエスト端末と、ファイアウォールを有しそのアクセスを受け付ける通信機能付き機器とに、予め定めた認証の書式を記録しておき、
   上記外部リクエスト端末は、その認証の書式に沿った数列をパケットのポート番号として埋め込み可能なサイズに分割した情報として、一連のパケットの送信元ポート番号部分のみに埋め込み連続して上記機器へ送出し、
   上記機器は、ファイアウォールで受信したパケットの送信元ポート番号の連続するパタンを監視して、記録しておいた上記の認証の書式を参照し、そのパタンが上記の認証の書式に沿ったものであることを検出したら、アクセスを受け入れるためのアクセス対象機能部を実行させる、ファイアウォールを用いた認証方法。
2. 上記の予め定めた認証の書式が、同一送信元アドレスから送信された連続するパケットの送信元ポート番号の連続との一致を判断すべき数列であり、上記機器及び上記リクエスト端末がそれぞれその数列を保持して認証を行う請求項１に記載の認証方法。
3. 上記の予め定めた認証の書式が、上記機器と上記外部リクエスト端末とが共有する共通鍵と、上記機器が認識する上記外部リクエスト端末の送信元ＩＰアドレスとからハッシュ値を生成し、パケットの送信元ポート番号に格納可能なサイズに分割した数列を、認証のたびに生成させて認証を行う請求項１に記載の認証方法。
4. 外部ネットワークからの通信に対してファイアウォールとして機能するファイアウォール機能部を有する通信機能付き機器であって、
   上記ファイアウォール機能部は、受信したパケットの送信元ポート番号を取得するパケット情報取得部を有し、
   また、
   予め定めた認証の書式に従った数列を記録する鍵テーブルと、
   前記の取得されたパケットのうち同一の送信元アドレスから送信されたものに含まれる送信元ポート番号の連続を、前記の鍵テーブルと比較参照して認証するか否かを判断するパタン解析部と、
   を含み上記ファイアウォール機能部によって外部ネットワークから守られた認証機能部を有し、
   さらに、上記認証に成功したら、前記ファイアウォールの所定のポートを開け、アクセスを受け入れる所定のソフトウェアを起動させ、又はそれらの両方を行わせるアクセス対象機能部を有する、
   外部ネットワークに接続した外部リクエスト端末からの認証をファイアウォールにより認証可能な通信機能付き機器。
5. 上記の予め定めた認証の書式が、上記鍵テーブルに予め記録された、同一送信元アドレスから送信された連続するパケットの送信元ポート番号との一致を判断すべき数列である請求項４に記載の通信機能付き機器。
6. 上記の予め定めた認証の書式が、上記外部リクエスト端末との間で共有する共通鍵と、上記機器自身が認識する上記外部リクエスト端末の送信元ＩＰアドレスと、からハッシュ値を生成し、パケットの送信元ポート番号に格納可能なサイズに分割した数列からなる上記鍵テーブルを認証のたびに生成させて上記認証を行うものである、請求項４に記載の通信機能付き機器。
7. 外部ネットワークと内部ネットワークとの間に設ける中継装置である請求項４乃至６のいずれかに記載の通信機能付き機器と、
   上記の予め定めた認証の書式に従い上記の数列に適合したデータを連続するパケットの送信元ポート番号に埋め込んで、連続送出する認証情報埋込パケット連続送出機能を持たせた外部リクエスト端末と
   からなる認証システム。
   

Images