• 検索結果がありません。

21 VoIP An encrypted VoIP communication system for mobile telephones

N/A
N/A
Protected

Academic year: 2021

シェア "21 VoIP An encrypted VoIP communication system for mobile telephones"

Copied!
37
0
0

読み込み中.... (全文を見る)

全文

(1)

平成

21

年度

フロンティアプロジェクト

修士学位論文

携帯端末に適した

VoIP

暗号化通信システムの構築

An encrypted VoIP communication system

for mobile telephones

1095702

石井

勇太

指導教員

清 水

明 宏

2010

3

4

高知工科大学大学院 工学研究科 基盤工学専攻

フロンティア工学コース

(2)

要 旨

携帯端末に適した

VoIP

暗号化通信システムの構築

石井

勇太

近年, 公衆電話網とIPネットワーク網を統合する動きが進んでいる. その中で, IPネット ワークを用いた音声通信の仕組みとして, VoIP(Voice over Internet Protocol) 通信が利用 されている. しかし, 公衆網を利用したVoIP通信は, 悪意ある第三者に通話内容を盗聴され る可能性がある. この問題を解決するために, VoIP over SSL(VoIPs)を利用する方法があ るが, VoIPsは通話中に同一の暗号鍵を利用する. そのため, 通話中に暗号鍵を盗まれると, 通話内容の秘匿性を保てない. この問題を解決するために, 先行研究では一定時間ごとに暗 号鍵を変更する, 秘匿性の高いVoIP通信を提案している. 先行研究では, 携帯端末を用いた 同一LAN内のVoIP通信を実現している.

本研究では異なるLAN間のVoIP通信を実現するために, VoIP通信を中継するロビー サーバを設置し, サーバを経由して通信する.

キーワード VoIP, 暗号化, ワンタイムパスワード, SAS-2, ロビーサーバ, IPネットワー ク, 携帯電話

(3)

Abstract

An encrypted VoIP communication system

for mobile telephones

Yuta, Ishii

In recent years, movement to integrate the public telephone net and the IP network is advanced. In the movement, VoIP(Voice over Internet Protocol) to communicate the voice-data by the IP network is used. However, VoIP using the public network has danger. In order to solve this problem, there is a method of using VoIPs(VoIP over SSL). However, VoIPs keeps using the same encryption key while talking over the mobile phone. Therefore, when he/she had the encryption key stolen, hiding the content of the telephone call secretly can not be kept. As the earlier study, the VoIP communication that improve degree of hiding the content of the telephone call have been As the earlier study, the VoIP communication in same LAN with a portable terminal has been achieved.

In this study, we have achieved the VoIP communication with different LAN, and exchanged address information of the lobby server with other party beforehand.

key words VoIP, Encryption, One-time password, SAS-2, lobby server, IP network, mobile phone

(4)

目次

1章 緒論 1 1.1 研究背景 . . . 1 1.2 本論文の構成 . . . 2 第2VoIP 3 2.1 VoIP . . . 3 2.1.1 VoIP/H.323 . . . 3 2.1.2 VoIP/SIP . . . 5 2.2 VoIP over SSL . . . 8 第3章 暗号鍵交換方式 9 3.1 SAS-2鍵交換方式 . . . 9 3.1.1 定義と記法. . . 9 3.1.2 SAS-2プロトコル . . . 10 3.1.3 共通鍵/更新 . . . 13 第4SAS-Phone 14 4.1 システム構成 . . . 15 4.2 プロトコル . . . 16 4.2.1 SET UP PHASE . . . 16

4.2.2 AUDIO TRANSEFER PHASE . . . 17

5章 携帯端末に適したVoIP暗号化通信の提案 19 5.1 提案手法 . . . 20

(5)

目次 5.2.1 登録フェーズ . . . 21 5.2.2 認証フェーズ . . . 22 5.2.3 接続フェーズ . . . 23 5.2.4 通話フェーズ . . . 23 第6章 評価と考察 26 6.1 検証環境 . . . 26 6.2 検証結果 . . . 26 6.3 考察. . . 27 第7章 結論 28 謝辞 29 参考文献 30

(6)

図目次

2.1 H.323の構成図 . . . 4 2.2 H.323のコールフロー . . . 6 2.3 VoIP/SIPのコールフロー . . . 7 3.1 H.323の構成図 . . . 11 3.2 H.323の構成図 . . . 12 4.1 SAS-Phoneの概要図 . . . 15 4.2 SAS-Phoneのコールフロー . . . 16 4.3 SET UP PHASE . . . 17

4.4 AUDIO TRANSEFER PHASE . . . 18

5.1 提案システムの概要 . . . 21 5.2 提案システムのコールフロー . . . 21 5.3 VoIP端末と認証サーバの鍵交換 . . . 22 5.4 VoIP端末の認証手順 . . . 23 5.5 提案システムの接続フェーズ . . . 24 5.6 提案システムの通話フェーズ . . . 25

(7)

表目次

2.1 H.323プロトコルスタック . . . 5

2.2 VoIP/SIPプロトコルスタック . . . 7

6.1 検証環境 . . . 27

(8)

1

緒論

本章では, 本研究における社会的, および技術的背景の概要を述べる. そして, 本研究が達 成すべき目標を示す.

1.1

研究背景

企業や一般家庭へのインターネットの普及や, LANのブロードバンド化により, 公衆電話 網とIPネットワーク網を統合する動きが進んでいる[1]. 例えば, 従来の公衆電話網を用いた音声通話は, 構内交換機であるPBX(Private Branch eXchange)と電話装置, 電話配線, 拠点間を結ぶ音声専用線が必要である. そのため, メー ルやチャットなどのデジタルデータを転送するデータ網と, 音声を転送する音声専用線の2 種類が必要である. そこで, PBXをIP-PBXに変更することにより, 通信網や交換設備が 集約できるため, 拠点間を結ぶ音声専用線は不要となる.[2]. そのため, 保守やメンテナンス に必要なランニングコストが削減できる. IP網を用いる音声通信のことを, VoIP(Voice over Internet Protocol)と呼ぶ[3]. VoIP通信を利用することにより, 無線LANを利用し たVoWLAN(Voice over Wireless LAN)が可能となった. 近年, VoWLAN対応端末が増 加しており, カフェや空港のラウンジなど, VoWLANを利用できる場所も増加している[4]. VoWLAN を利用することにより, 外出先においても内線電話を利用でき, 電話料金が削減 できる.

しかし, 公衆網を用いた通話は, 通信・通話内容が第三者に盗聴される恐れがあり, 安全 とは言えない[5]. そこで, 通話内容を暗号化し, 第三者による盗聴を防ぐ技術としてVoIPs

(9)

1.2 本論文の構成

(VoIP over SSL)がある. VoIPsとは, VoIP通信にSSL 暗号化技術を応用することによ り, 音声データを暗号化して通話する技術である. しかしVoIPsは通話中, 常に同じ暗号鍵 を利用するため, 第三者に暗号鍵および暗号化された通話内容を盗まれた場合, 通話内容の 盗聴が可能となる. この問題は先行研究により, 一定時間ごとに暗号鍵を変更することで, 秘 匿性の高いVoIP通信が提案されている. 先行研究では, 携帯端末を用いた同一LAN内の VoIP通信を実現している. そこで本研究では, VoIP通信を中継するロビーサーバを設置し, サーバを経由してVoIP通信することで, 異なるLAN間のVoIP通信を実現する.

1.2

本論文の構成

本論文では, 携帯端末を用いて異なるLAN間で通話可能な, 秘匿性の高いVoIP通信につ いて述べる. 第二章では, VoIPの技術的背景および概要, 実現手法について述べる. 第三章では, 暗号鍵交換方式の中で安全性が高く, 先行研究で使用されているSAS-2につ いて述べる. 第四章では, 先行研究であるSAS-Phoneのシステム, プロトコルについて述べる. 第五章では, 提案する手法とシステムについて述べる. さらに, 提案するシステムはフェー ズごとに分けて, 音声通話の実現手順について述べる. 第六章では, 提案する手法とシステムを実装した結果について評価し, 考察を行った結果 について述べる. 最後に, 本論文の成果をまとめ, 今後の課題について述べる.

(10)

2

VoIP

本章では VoIPの技術背景, および VoIPのプロトコルについて述べる. また, 現状の VoIP通信における暗号化の方式についても述べる.

2.1

VoIP

インターネットの普及とネットワークの広帯域化により, 公衆電話網とIPネットワーク を統合する動きが進んでいる. また, 移動端末のアクセスネットワークも, IPネットワーク へ移行する動きが出ている. このように, 音声情報をデジタル情報に変換し, LANやWAN などのIPネットワークを用いて, デジタル化した音声情報を転送する技術をVoIPという. VoIPの代表的なプロトコルとして, 国際電気通信連合(ITU-T)で勧告されたVoIP/H.323 や, 現在最も採用されているVoIP/SIP(Voice over Internet Protocol / Session Initiation Protocol)がある. 次に, VoIP/H.323とVoIP/SIPについて述べる.

2.1.1

VoIP/H.323

H.323とは, 音声や動画などをインターネット網を用いて, リアルタイムでデータ通信す るプロトコルである [6]. VoIP/H.323で通信するためには, 図2.1に示すように, 音声や動 画を転送する端末,ゲートウェイ, ゲートキーパー, MCU(Multipoint Control Unit)が必要 である.

端末とは音声の録音, 再生, 符号化などの機能を有し, リアルタイムで音声情報を伝送する 機器である. ゲートウェイとは, 既存の電話網やISDNなどのH.323以外の通信プロトコル

(11)

2.1 VoIP 図2.1 H.323の構成図 とH.323プロトコルを接続し, 音声情報とIPパケットを相互変換する機器である. ゲート キーパーとは, 電話番号からIPアドレスへの変換や,通信帯域や接続端末などの管理機能を 有する機器である. MCUとは端末にパケットを配分し, 電話会議やテレビ会議などの多地 点間通信を行う機器である. そして, これらの機器を用いて通信するには, 次のプロトコルやコーデックを使用する必要 がある. 表2.1にプロトコルスタックを示す. H.323プロトコルには4種類のプロトコルが あり, それぞれ通信を制御するプロトコルと音声を制御するプロトコルに分類できる. 通信 を制御するプロトコルには, H.225.0 RASプロトコルとQ.931プロトコルがある. H.225.0 RASプロトコルは, ゲートキーパーとVoIP端末間の通信手順の制御を行い, Q.931プロト コルはVoIP端末同士の通信を制御する. 音声を制御するプロトコルには, H.245 制御プロ トコルとRTP(Real - time Transport Protocol), RTCP(Real - time Transport Control Protocol)プロトコルがあるH.245 制御プロトコルは, VoIP端末の通話に使用する符号化 などの制御を行い, RTP, RTCPプロトコルはVoIP端末同士の音声を制御する.

H.323 を実装するためのコールフローは, 次の 4 点から構成される. 図 2.2 に, H.323 のコールフローを示す. まず, 他端末が通話可能な状態かを確認する SET UP フェイズ があり, H.225.0 RAS制御プロトコルと Q931プロトコルを用いて通信を確立する. 次に

(12)

2.1 VoIP 表2.1 H.323プロトコルスタック アプリ RTP RTCP RAS Q.931 H.245 ケーション層 (音声・映像) (H.225.0) (H.225.0) (H.225.0) トランスポート層 UDP TCP インターネットワーク層 IP CONTROL SIGNALLING フェイズがあり, H.245制御プロトコルを用いて音声の符号化 といった制御を行う. そしてAUDIOフェイズがあり, 音声情報を転送して通話を行う. 最 後にRELEASEフェイズでは, H.245制御プロトコルを用いてVoIP通信を終了する. VoIP/H.323を用いることにより, IP網でリアルタイムの音声通話が可能となった. し かし, VoIP/H.323 は特定条件においてDoS攻撃に脆弱であること, 遠隔地から第三者が 任意のコードを実行できる問題が発見されたため, VoIP/SIP に移行しつつある. また, VoIP/SIPに移行している別の理由として, VoIP/H.323はバイナリ形式のプロトコルであ ることや, データ構造の記述にASN.1(Abstract Syntax Notation One)を利用することな ど, 処理が複雑であったことも挙げられる.

2.1.2

VoIP/SIP

SIPとは, アプリケーション層を利用してインターネット上で音声, 動画, テキストメッ セージなどで, リアルタイムに通信を行うためのプロトコルである[7][8]. SIPの特徴は, テ キストベースで表現されているプロトコルのため, バイナリ形式のH.323と比較して, 実装 や拡張が容易である. 表2.2にプロトコルスタックを示す. VoIP/SIPは, クライアントがメッセージをサーバに送信するリクエスト, サーバがクラ イアントのリクエストに応答するレスポンスを繰り返す, リクエスト/レスポンスモデルで ある. VoIP/SIPを用いるためには, VoIP/SIP対応アプリケーションを搭載した端末, SIP サーバが必要である. SIPサーバには,ステートフルプロキシ,ステートレスプロキシの2種

(13)

2.1 VoIP 図2.2 H.323のコールフロー 類がある. ステートフルプロキシは, 送信端末からのリクエストに対して暫定的なレスポン スの生成や, メッセージを再送信することが出来るプロキシサーバである. それに対してス テートレスプロキシは, 送信端末に暫定的なレスポンスを生成せず, メッセージを中継する だけのプロキシサーバである. 次に, VoIP/SIPを用いた電話発信から通話終了までのコールフロープロトコルを, 図2.3 に示す.

(14)

2.1 VoIP 表2.2 VoIP/SIPプロトコルスタック SIP RTP SDP プロトコル SIP RTPRTCP/ DNS ネットワーク層 TCP UDP データリンク層 データリンク層 物理層 物理層 図2.3 VoIP/SIPのコールフロー

ジを受け取った SIPサーバは, 次のSIPサーバにはINVITEメッセージを送り, 送信元の 発信端末には100 Tryingメッセージを送る. 同様に, 送信先へはINVITEメッセージを送 り, 送信元へは100 Tryingメッセージを返信し, INVITEメッセージが受信端末に到着する まで続ける. 受信端末BがINVITEメッセージを受け取った後は, SIPサーバを経由して送 信端末Aに向けて180 Ringingメッセージと, 200 OKメッセージを送信する. 発信端末A

(15)

2.2 VoIP over SSL が200 OKメッセージを受け取ることで, 発信端末Aと受信端末Bは通話可能状態になる. 次に, 発信端末AがSIPサーバを経由して, 受信端末BへACKメッセージを送信すること で通話状態となる. その後, お互いの端末で音声データを録音, 送受信して再生することで, 通話を実現させている. 通話を終了させるには, 片方の端末が他方の端末へ BYEメッセー ジを送信し, BYEメッセージを受け取った端末が200 OKメッセージを返信することで完 了する. これにより, 電話発信, 通話状態, 通話終了が実現出来る.

2.2

VoIP over SSL

VoIP over SSLとは, セキュリティを確保してVoIP通信を行う技術である. H.323およ びVoIP/SIPで通信する際は, 暗号化されていないデータを送受信するため, データの通信 経路上で盗聴される危険性がある. そこで, VoIP 通信を行う前にSSLセッションを確立し, データを暗号化してVoIP通信 を行うことで, 通信の秘匿性を確保している. まず, VoIP通信を行う前にお互いに暗号鍵を 送信する. 次に,送信端末は暗号鍵を使ってデータを暗号化し, 受信端末は事前に交換してい た暗号鍵を用いてデータを複合する. これにより, 仮に公衆網上で第三者にデータを盗まれ ても, データは暗号化されているため, 第三者にデータの内容を知られることはない. しかし, VoIP over SSLでは, 同一の暗号鍵を使い続けるため, 暗号鍵を盗まれ, かつ音声 通信を盗聴された場合, 完全な音声の復元が可能である. そこで, 小野らの先行研究により, 一定時間ごとに暗号鍵を変更するプロトコルが提案されている.

(16)

3

暗号鍵交換方式

本章では, 先行研究で提案されたプロトコルで用いられている, ワンタイムパスワードを 用いたSAS-2鍵交換方式について述べる. また, SAS-2鍵交換方式の定義と記法, プロトコ ル, 共通鍵交換および更新について述べる.

3.1

SAS-2

鍵交換方式

SAS-2鍵交換方式は, ワンタイムパスワード認証方式を用いた鍵交換方式である[9]. 特徴 として, 一定時間ごとにパスワードを変更するため,反射攻撃(Replay Attack)や中間者攻 撃(Man-in-the-middle Attack)などによる成りすましの危険性に対する耐性が強いこと が挙げられる. また, 鍵交換時に必要となる通信セッション回数が二回であり, さらに一方 向性関数や排他的論理和演算の適用回数が, 他の鍵交換方式よりも少ないことも挙げられる. そのため処理負荷が小さく, 高速鍵交換が求められるサービスへの応用が可能である. 次に, SAS-2鍵交換方式で実行されるプロトコルと, これを用いた共通鍵生成について述べる.

3.1.1

定義と記法

SAS-2鍵交換方式で用いる定義と記法は次のとおりである. • Userは, 鍵を生成するユーザである. • Serverは, Userの鍵を受け取るサーバである. • IDは, ユーザの識別子を示す. • Sは, ユーザのパスワードを示す.

(17)

3.1 SAS-2鍵交換方式 • X, F, Hは, 一方向性関数を示す.例として, H(x)はxを一方向性関数に適用して得た 出力値を示す.また, この一方向性関数は出力ビット数が常に一定とする. • iは,鍵交換セッション毎に加算される数値である. • Niは, i回目の鍵交換時に生成される乱数を示す. • +は, 加算演算子を示す. ⊕は, 排他的論理和演算子を示す.

3.1.2

SAS-2

プロトコル

SAS-2プロトコルは, 登録フェーズと鍵交換フェーズで構成されている. 登録フェーズは, 鍵交換を行う前に最初の一度だけ実行され, 以降は鍵交換フェーズが実行される. まず,登録 フェーズを述べ, 鍵交換フェーズ, プロトコルの安全性を述べる. まず, 図3.1に示す, 登録フェーズを述べる. 1. ユーザは, 自身の識別子ID, パスワードSを入力する.それと同時に, 乱数 N 1を生成 し, 保存する.そして入力されたID, S, 生成されたN1 を用い, A + X(ID, S ⊕ N1)を 算出する. 2. ユーザは, ID, Aを安全なルートを用いてサーバへ送信する. 3. サーバは, 受け取ったID, Aを保存する. これらを実行することにより, 鍵交換を行うための準備が整う. 図3.2に示す, 鍵交換フェーズを, 次に述べる. 1. ユーザは, 自身の識別子ID, パスワードSを入力する. そして, 入力されたデータと保 存された乱数 Ni を用い, A = X(ID, S bigoplus Ni)を算出する.次に, ユーザは乱数 Ni+1を生成し, 保存する. さらに, ユーザはC = X(ID, S ⊕ Ni+1), F(C) = F(ID, C)をそれぞれ求め, 算出されたC, F(C)と, 先に生成した乱数Ni+1を用いα = C(F(C) + A), β = F(C) ⊕ Aをそれぞれ求める.

(18)

3.1 SAS-2鍵交換方式 図3.1 H.323の構成図 2. ユーザは, ID, α, β をサーバへ送信する.このとき使用するネットワークは, インター ネットのように安全でない共通ネットワークを用いてもよい. 3. サーバは, 受信した β と保存された A を用い, F(C) + β ⊕ A を算出する.さらに, サーバはC = α ⊕ (F(C) + A)を算出する.先に算出されたF(C)と, F(ID, C)を比 較し, 不一致ならば鍵交換は不成立となる.一致すれば鍵交換が成立し, 以下のしょりが 実行される. 4. サーバは, 保存されたAの代わりとしてCを保存し, 次回鍵交換に備える.さらに, γ = H(ID, F(C))を算出する. 5. サーバは, γ をインターネットなどを通してユーザへ送信する. 6. ユーザは, H(ID, F(C))を算出し, 受信したγ と比較する.もし一致すれば, 鍵交換が成 立する.不一致ならば, 鍵交換は不成立となる.

(19)

3.1 SAS-2鍵交換方式 図3.2 H.323の構成図 次に, プロトコルの安全性を述べる. ワンタイムパスワード認証方式に対する攻撃として, 反射攻撃による成りすましが考えられる. 反射攻撃では, 正当なユーザによる認証・鍵交換 が行われた際に送受信された情報を, 悪意ある第三者が経路中で盗聴し再利用する. 正当な ユーザがSAS-2による(i+1)回目の認証・鍵交換を行う際に,ユーザが送信する情報を以下 に示す. α ←− E(F (E) + C) β ←− F (E)C ID この時, 悪意ある第三者が成りすまし攻撃を実行する場合, 以下の情報を送信しなければ ならない.

(20)

3.1 SAS-2鍵交換方式 α′ ←− x(F (E) + C) β′ ←− F (x)C ID 第三者が, たとえi回目以前での情報をすべて取得できたとしても, これら情報の組み合わ せを生成することは不可能である. 以上より, SAS-2プロトコルによる認証・鍵交換は安全 であると言える.

3.1.3

共通鍵

/

更新

SAS-2を用いた相互認証が成立した場合, サーバおよびユーザはSAS-2 認証で使用した データを用いて乱数を生成し, その乱数を使用して中間鍵の生成を行う. その中間鍵を基に サーバおよびユーザは共通鍵を生成する. 相互認証および共通鍵の共有が成功すると, サー バはリクエストデータをサーバ側の共通鍵を用いて暗号化し, ユーザに送信する. 暗号化さ れたデータを受け取ったユーザは, 共通鍵を用いて受け取ったデータを複合する.

(21)

4

SAS-Phone

本章では, 先行研究である SAS-Phoneにおけるシステム構成, およびプロトコルを述べ る[10]. なお, 本章で用いる記号の定義と記法は, 次の通りである. • Xは, 音声通話を発信する発信者である. • Yは, 音声通話を受信する受信者である. • ID, Sは, 一時的なユーザ識別子である. • D, X, F, Hは, 一方向性関数を示す.例として, H(x)はxを一方向性関数に適用して得 た出力値を示す.また, この一方向性関数は出力ビット数が常に一定とする. • iは,鍵交換セッション毎に加算される数値である. • Niは, i回目の認証時に生成される乱数を示す. • Xaは, Xの処理能力情報を示す. • Yaは, Yの処理能力情報を示す. • Tは, 鍵交換を行う時間間隔を示す. • Mは,音声を一定時間録音した音声データである. • Mkは, 音声を暗号化するための共通鍵である. • Meは, 音声データMを暗号鍵Mkを用いて暗号化した暗号化データである. • +は, 加算演算子を示す. ⊕は, 排他的論理和演算子を示す.

(22)

4.1 システム構成

4.1

システム構成

実装する端末をiPod touch 2Gとしている. 選定理由としては, 音声の録音・再生機能と ネットワーク機能を有しており, いずれもデベロッパが利用可能なAPIとなっていることで ある. SAS-PhoneのVoIP通話における概要を, 図4.1に示す. また, 音声の録音・再生プ ロトコルは, 独自プロトコルとなっている[10]. 録音プロトコルは, 次の三点から構成される. まず, 鍵交換タイミングは200msとし, 決 定した鍵交換タイミングの時間の間, 音声を録音する. 次に, 録音した音声をAES暗号化方 式を用いて暗号化する. 最後に暗号化したデータをWirelessLANを用いて転送する. 次に, 再生プロトコルを述べる. 再生プロトコルは次の三点から構成される. まず, 転送さ れた音声データを受信する. 次に受信した音声データを, 交換した暗号鍵を用いて復号する. 最後に複合した音声データを再生する. そして, 鍵交換方式は, 鍵生成コストおよび鍵交換コストにおいて優位であるSAS-2とし ている. 図4.1 SAS-Phoneの概要図

(23)

4.2 プロトコル

4.2

プロトコル

コールフロープロトコルの構成を, 図4.2に示す. まず, 端末情報や音声符号化形式など を転送するSET UP PHASEを実行する. 次に, 暗号鍵交換を行っていない場合, FIRST KEY EXCHANGEを実行する. そして, 音声通信が開始し, 音声情報や暗号鍵交換などを 行うAUDIO TRANSEFFR PHASEを実行する. 最後に, 通話終了のためにシグナル送受 信や, セッション切断などを行う.

図4.2 SAS-Phoneのコールフロー

4.2.1

SET UP PHASE

SET UP PHASEのフローチャートを図4.3に示し, SET UP PHASEについて述べる. SET UP PHASEでは, 音声通話を行うために必要な情報を交換するとともに, XおよびY を通話開始可能状態にする. そのために, まずXが処理能力Xa を算出する. 次に, Xが接

続要求をYに出す. そして, 接続要求を受けたYは, 能力情報Yaを算出する. 算出が終わっ

(24)

4.2 プロトコル

時間から実測ネットワーク帯域を算出する. そして, Yは実測ネットワーク帯域, Xa, Ya

り, 鍵交換タイミングTを算出する. その後, Yが算出した鍵交換タイミングをXに送信し, XはTを保存する. これらを行うことで, SET UP PHASEは終了する.

図4.3 SET UP PHASE

4.2.2

AUDIO TRANSEFER PHASE

AUDIO TRANSEFER PHASEは, 鍵交換フェーズと音声情報転送フェーズから構成さ れる. 鍵交換フェーズは, SAS-2鍵交換フェーズと同様である. 音声情報転送フェーズの構成を, 図4.4に示す. まず, XがF(C)を用いて暗号鍵Mkを算 出する. 次に, 録音した音声データ M をMk を用いて暗号化する. 暗号化された音声デー タMeは, 無線LANを用いてXからYに転送される. そして, YはF(C)をもとにMk を 算出する. さらに, Yは算出したMkを利用して, Mkを音声データMに復号する. 最後に, Yは複合した音声データMを再生する. これらを行うことにより, AUDIO TRANSEFER PHASEは終了する.

(25)

4.2 プロトコル

(26)

5

携帯端末に適した

VoIP

暗号化通信

の提案

小野らの先行研究は, 既存方式と比べてより安全にVoIP通信することができ, 携帯端末 を用いて同じネットワーク内での通信を実現している. そこで, 同じネットワーク内だけで なく, 異なるネットワーク同士で通信可能な, 携帯端末に適したVoIP暗号化通信システム を提案する. 本章では, 本研究における提案手法, および提案システムについて述べる. なお, 本章で用いる記号の定義と記法は次の通りである. • Xは, 音声通話を発信する発信者である. • Yは, 音声通話を受信する受信者である. • Zは, 発信者と受信者を認証し, 音声を中継する認証サーバである. • ID, Sは, 一時的なユーザ識別子である. • D, X, F, Hは, 一方向性関数を示す.例としてF(x)はxを一方向性関数に適用して得 た出力値を示す.またこの一方向性関数は, 出力ビット数が常に一定とする. • iは,認証セッション毎に加算される数値である. • Niは, i回目の認証時に生成される乱数を示す. • Mは, 音声を一定時間録音した音声データである. • Mkは, 音声を暗号化するための共通鍵である. • Meは, 音声データMを暗号鍵Mkを用いて暗号化した, 暗号化データである.

(27)

5.1 提案手法 • +は, 加算演算子を示す. ⊕は, 排他的論理和演算子を示す.

5.1

提案手法

提案手法は, VoIP端末が認証サーバと通信し, サーバを経由して通信先VoIP端末とIP 網を用いて通信する. VoIP端末と認証サーバの構成を図5.1に示し, IP 網を用いてVoIP 端末間で通信するまでの流れを示す. 1. 端末Aからユーザ認証情報をサーバに送信して,認証に成功するとログインする 2. VoIP通信を行う端末Bを指定する 3. サーバはVoIP通信を行うための接続ポートを生成する 4. 生成した接続ポートで通信するためのURLを, メールに記載して端末Bへ送信する 5. 端末Bは受信したメールのURLにアクセスし, ログインする 6. 端末Bはサーバとソケット接続を行い, サーバは端末Aにソケット接続要求を行う 7. 端末A がソケット接続を行うことで, サーバを経由して端末間でVoIP通話が可能に なる

5.2

提案システム

提案システムは, 携帯端末におけるSAS-2を適用したVoIP通話である. 提案システムで利用するプロトコルは, 登録フェーズ, 認証フェーズ, 接続フェーズ, 通話 フェーズから構成される. 提案システムの概要を,図5.2に示す. 登録フェーズは, VoIP端末 が認証サーバと初めて通信する場合のみ行う. VoIP通信するには3つのフェーズがあり, 認 証フェーズ, 通話フェーズ, 終了フェーズから構成される. 次に, 各フェーズについて述べる.

(28)

5.2 提案システム 図5.1 提案システムの概要 図5.2 提案システムのコールフロー

5.2.1

登録フェーズ

登録フェーズでは, VoIP端末と認証サーバが暗号鍵を交換していない場合のみ, SAS-2を 用いて鍵交換を行う. 図5.3に示す, 認証サーバとVoIP端末の鍵交換ついて述べる. まず, 認証サーバに登録を行うユーザXが, 無線LANセッションをSSLで確立する. 次に, ユー ザXが認証サーバに対して, SAS-2登録フェーズを実行する.

(29)

5.2 提案システム 図5.3 VoIP端末と認証サーバの鍵交換

5.2.2

認証フェーズ

認証フェーズでは, サーバは登録フェーズで登録した情報を用いてVoIP端末を認証する. VoIP端末を認証する手順を, 図5.4に示す. まず, ユーザX はサーバへSSL通信で認証を 行い, 認証に成功するとログイン出来る. ログインしたユーザXは, VoIP通信を行うユーザ Yを指定し, 接続要求を認証サーバへ行う. 接続要求を受け取った認証サーバは, VoIP通信 を行うためのポートを作成し, ユーザYへURL情報の記載されたメールを送信する. メー ルを受け取ったユーザ Y は, メールに記載されているURLにログインを行うことで認証 フェーズは完了する.

(30)

5.2 提案システム

図5.4 VoIP端末の認証手順

5.2.3

接続フェーズ

接続フェーズでは, VoIP通信する準備としてVoIP端末と認証サーバがSocket通信を行 う. 図5.5に示す, VoIP 端末と認証サーバのSocket接続について述べる. まず, ユーザY は認証フェーズでログインが完了した後, 認証サーバへ接続する. ユーザYに接続された認 証サーバは, ユーザ Xへと接続要求を送信する. そして, ユーザX は認証サーバへ接続し, 認証サーバがユーザYへOKメッセージを送信することで, ユーザXとユーザY がVoIP 通信する準備が完了する.

5.2.4

通話フェーズ

通話フェーズでは, サーバを経由してVoIP端末同士でVoIP通信を行う. 図5.6に示す, 通話フェーズについて述べる. まず, XがF(x)を用いて暗号鍵Mkを算出する. 次に, 録音 した音声データMをMk を用いて暗号化する. 暗号化された音声データMe は, 無線LAN を用いて, XからZに転送される. そしてZは, F(C)をもとに, Mk を算出する. さらにZ は, 算出したMkを利用してMk を音声データMに復号する. 同様に, ZからYへも暗号化 をして音声データを送信する. 最後にYは, 復号した音声データMを再生する.

(31)

5.2 提案システム

(32)

5.2 提案システム

(33)

6

評価と考察

本研究における提案システムをエミュレータを用いて再現し, 得られた処理速度によって 評価する. ただし, 本来の目的はネットワーク間の通信であるが, 今回の検証実験ではローカ ルネットワーク内で中継サーバを利用している. また, 送信端末と受信端末はシミュレータ を利用しており, 携帯端末との性能差はあるが, 今回は中継サーバによる遅延の計測が目的 である.

6.1

検証環境

送信クライアント端末から中継サーバ端末, 中継サーバ端末から受信クライアント端末の 順に音声ファイルを転送し, その転送時間を計測した. 転送時間の測定に使用した音声ファ イルの容量は, 1MB(1,085,597byte)である. 今回行った検証実験の環境を, 表6.1に示す. ただし, 本来の使用端末は iPhoneであり, 今回の使用端末はMacBookAir とMacProで ある.

6.2

検証結果

まず, 送信端末で音声ファイルをバイナリ化し, 中継サーバ端末にTCPプロトコルを用い て送信した. 中継サーバはバイナリデータを受信し, 受信したデータを受信端末にTCPプ ロトコルを用いて転送する. 受信端末は受信したバイナリデータを, 音声ファイルに再構築 することで, 音声通話が可能となった. 各端末での処理時間を, 表6.2に示す.

(34)

6.3 考察

表6.1 検証環境

送信クライアント端末 MacBookAir

プロセッサ 1.6GHz Intel Core 2 Duo メモリ 2GB 1067MHz DDR3 中継サーバ端末 CentOSデスクトップマシン

プロセッサ Intel(R) Pentium(R) 4 CPU 3.00GHz メモリ 1GB 受信クライアント端末 MacPro プロセッサ 2 x 2 GHz Dual-Intel Xeon メモリ 4GB 無線LAN IPN-W500AP 通信速度 54Mbps 表6.2 端末の処理時間 送信クライアント端末 5.270000ms 中継サーバ端末 0.050000ms 受信クライアント端末 1.670000ms

6.3

考察

中継サーバの処理時間は0.05秒であり,音声通話において支障がない程度の遅延時間であ ると考えられる. 今回の実験は,携帯端末ではなくシミュレータを利用しているが,サーバを 経由してもSAS-2を用いた音声通信が実現できる可能性を確認できた.

(35)

7

結論

本論文では, 本研究における提案システムを用いることにより, 中継サーバを経由して SAS-2 を用いた音声通話を実現する可能性を示した. しかし, 今回検証した環境は, 送信端 末と受信端末にシミュレータを使用しており, 本来の使用用途である携帯端末の処理能力は 考慮していない. そのため, 携帯端末で無線LANを利用して音声通話すると, 携帯端末の処 理能力では通信速度が低下する恐れがある. この問題の解決策としては, SAS-2の鍵交換回 数を減らし, 暗号化の処理量を減らすことが考えられる. また, ローカルネットワーク内に中 継サーバを設置して通信したが, 中継サーバでの処理時間が非常に短いことから, 中継サー バを経由してもSAS-2を用いたVoIP通話が可能であると考えられる.

(36)

謝辞

本研究の遂行と論文作成にあたって, 言葉では言い表せないほどの御指導, 御助言をいた だきました高知工科大学フロンティア工学コース 清水明宏教授に心より感謝し厚く御礼申 し上げます.本研究の副査を担当していただいた高知工科大学フロンティア工学コース 渡 邊法美教授, 古沢浩准教授に深く御礼申し上げます. また, 提案システム実装にご協力いただきました清水研究室, 青木渉氏に心より感謝いた します.さらに, 本研究において適切なご助言ををいただいた高知工科大学 清水研究室 岡 村大氏, 中野友貴氏に心より感謝いたします. 最後に, 有益な議論を交わしていただいた高知 工科大学 清水研究室の関係者各位に深く感謝いたします.

(37)

参考文献

[1] 小泉 修,“図解でわかるVoIPのすべて,” 日本実業出版社,2003. [2] IP電話普及推進センタ,“実践入門ネットワーク NGN時代のIP電話標準テキスト,” リックテレコム,2009. [3] 日経NETWORK,“絶対わかる!IP電話超入門,” 日経BP社,ISBN-10:4822212785, 2005/10.

[4] Hiroyuki Koga,Shigeru Kashihara, Yutaka Fukuda, Katsuyoshi Iida, Yuji Oie“A quality-aware VoWLAN architecture and its quantitative evaluations,” Wireless Communications, IEEE, Vol.13, No. 5, pp. 52-59, 2006.

[5] Matthew Gast,渡辺 尚, 小野 良司, “ 802.11無線ネットワーク管理,” オライリー・ ジャパン,ISBN-4-87311-308-3, 2006/11.

[6] ITU-T,“Visual Telephone Systems and Equipment for Local Area Networks Which Provide a Non-Guaranteed Quality of Service,” ITU-T Recommendation H.323, 1996.

[7] IETF3261,“SIP:Session Initiation Protocol,” IETF,2002. [8] IETF4566,“SDP:Session Description Protocol,” IETF,2006.

[9] T. Tsuji,and A. Shimizu, “Simple and secure password authentication protocol, ver.2(SAS-2), ” IEICE Technical Reports, OIS2002-30, 2002.

[10] 小野 豊,“携帯電話におけるVoIP暗号化通信の提案,”平成20年度高知工科大学論集, 2009.

図 4.2 SAS-Phone のコールフロー
図 4.3 SET UP PHASE
図 4.4 AUDIO TRANSEFER PHASE
図 5.4 VoIP 端末の認証手順
+4

参照

Outline

関連したドキュメント

キュリティ強化を前提に、加盟店におけるカード番号非保持化を徹底し、特

「Remote NDIS based Internet Sharing Devise」を誤って削除してしまった。 → 資格確認端末の再起動を行っていただくことで、ネットワーク接続に「Remote NDIS

入札参加者端末でMicrosoft Edge(Chromium版)または Google

携帯端末が iPhone および iPad などの場合は App Store から、 Android 端末の場合は Google Play TM から「 GENNECT Cross 」を検索します。 GENNECT

 ESET PROTECT から iOS 端末にポリシーを配布しても Safari の Cookie の設定 を正しく変更できない現象について. 本製品で iOS

ソリューション事業は、法人向けの携帯電話の販売や端末・回線管理サービス等のソリューションサービスの提

Should Buyer purchase or use SCILLC products for any such unintended or unauthorized application, Buyer shall indemnify and hold SCILLC and its officers, employees,

AMS (代替管理システム): AMS を搭載した船舶は規則に適合しているため延長は 認められない。 AMS は船舶の適合期日から 5 年間使用することができる。