JP2015142213A - 端末装置 - Google Patents

端末装置 Download PDF

Info

Publication number
JP2015142213A
JP2015142213A JP2014013451A JP2014013451A JP2015142213A JP 2015142213 A JP2015142213 A JP 2015142213A JP 2014013451 A JP2014013451 A JP 2014013451A JP 2014013451 A JP2014013451 A JP 2014013451A JP 2015142213 A JP2015142213 A JP 2015142213A
Authority
JP
Japan
Prior art keywords
processing unit
security
message
vehicle
communication
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.)
Pending
Application number
JP2014013451A
Other languages
English (en)
Inventor
金井 雄一
Yuichi Kanai
雄一 金井
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Management Co Ltd
Original Assignee
Panasonic Intellectual Property Management Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Panasonic Intellectual Property Management Co Ltd filed Critical Panasonic Intellectual Property Management Co Ltd
Priority to JP2014013451A priority Critical patent/JP2015142213A/ja
Publication of JP2015142213A publication Critical patent/JP2015142213A/ja
Pending legal-status Critical Current

Links

Images

Abstract

【課題】共通鍵暗号方式を採用したブロードキャスト通信において、第三者によるなりすましの脅威を低減する。【解決手段】受信部は、通信鍵を共有する他の端末装置からブロードキャスト送信されたパケット信号を受信する。フレーム処理部14は、パケット信号に含まれるメッセージに、通信鍵を用いた共通鍵暗号方式によるセキュリティ処理が施されていない場合、当該メッセージを破棄する。セキュリティ処理が施されていないメッセージを破棄するか否かを処理部に設定する設定部を備えてもよい。【選択図】図4

Description

本発明は、通信技術に関し、特に他の端末装置からブロードキャスト送信されたパケット信号を受信する端末装置に関する。
日本では700MHz帯を使用した高度道路交通システム(Intelligent Transport System:ITS)の導入が検討されている。700MHz帯高度道路交通システムでは各路側機は固有の公開鍵証明書を保持し、自己の公開鍵証明書を付加したパケット信号をブロードキャスト送信する。当該パケット信号を受信した車載器は、付加されている公開鍵証明書を検証することによって正当なパケット信号か否かを検証できる。一方、車載器は公開鍵証明書を保持せず、通信鍵(秘密鍵、共通鍵ともいう)を保持する。当該通信鍵は車載器間で予め共有される。車載器は当該通信鍵を用いてアプリケーションデータのメッセージ認証コード(Message Authentication Code:MAC)を生成してパケットに付加する。または当該通信鍵を用いてアプリケーションデータを暗号化して秘匿する。車載器はMAC付加および暗号化の少なくとも一方をセキュリティ処理として実行することが可能であり、セキュリティ処理がなされたパケット信号をブロードキャスト送信する。当該パケット信号を受信した車載器は、共有された通信鍵を用いてMAC検証および/または復号することが可能である(例えば、特許文献1参照)。
特開2013−225875号公報
700MHz帯高度道路交通システムの路車間通信では、パケット信号に付加された公開鍵証明書を受信側で検証して送信元の真正性を確認するフェーズがあるが、車車間通信ではこのフェーズが省略される。車車間通信では、MAC検証および/または復号の成否により間接的に第三者によるなりすましを検出しているが、第三者によるなりすましの危険性は路車間通信より相対的に高くなっている。700MHz帯高度道路交通システムの車車間通信のように、公開鍵暗号方式ではなく共通鍵暗号方式を採用した通信では、第三者によるなりすましに対する十分な対策が必要となる。
本発明はこうした状況に鑑みてなされたものであり、その目的は、共通鍵暗号方式を採用したブロードキャスト通信において、第三者によるなりすましの脅威を低減する技術を提供することにある。
上記課題を解決するために、本発明のある態様の端末装置は、通信鍵を共有する他の端末装置からブロードキャスト送信されたパケット信号を受信する受信部と、前記パケット信号に含まれるメッセージに、前記通信鍵を用いた共通鍵暗号方式によるセキュリティ処理が施されていない場合、当該メッセージを破棄する処理部と、を備える。
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。
本発明によれば、共通鍵暗号方式を採用したブロードキャスト通信において、第三者によるなりすましの脅威を低減できる。
本発明の実施例に係る通信システムの構成を示す図である。 図2(a)−(d)は、通信システムにおいて規定されるスーパーフレームのフォーマットを示す図である。 基地局装置の構成を示す図である。 車両に搭載された端末装置の構成を示す図である。 車車間通信において生成されるパケット信号に含まれるセキュリティフレームのデータ構造の一例を示す図である。 セキュリティモジュールを通る場合の送信車載器と受信車載器のデータの流れを示す図である。 セキュリティモジュールを通らない場合の送信車載器と受信車載器のデータの流れを示す図である。 図8(a)−(c)は、各種ヘッダのフィールド構成の一例を示す図である。 図6に示したセキュリティモジュールを通る場合のデータ構造の一例を示す図である。 図7に示したセキュリティモジュールを通らない場合のデータ構造の一例を示す図である。 図6に示したセキュリティモジュールを通る場合のデータ構造が平文の場合の例を示す図である。 受信車載器の受理処理を示すフローチャートである。
本発明の実施例を具体的に説明する前に、基礎となった知見を説明する。本発明の実施例は、車両に搭載された端末装置間において車車間通信を実行するとともに、交差点等に設置された基地局装置から端末装置へ路車間通信も実行する通信システムに関する。以下、前述の700MHz帯高度道路交通システムを想定する。700MHz帯高度道路交通システムは、IEEE802.11等の規格に準拠した無線LAN(Local Area Network)と同様に、CSMA/CA(Carrier Sense Multiple Access with Collision Avoidance)と呼ばれるアクセス制御機能を使用する。そのため、複数の端末装置によって同一の無線チャネルが共有される。一方、700MHz帯高度道路交通システムでは不特定多数の端末装置へ情報を送信する必要がある。そのような送信を効率的に実行するために、700MHz帯高度道路交通システムではパケット信号をブロードキャスト送信する。
つまり車車間通信として端末装置は、車両の速度あるいは位置等の情報を格納したパケット信号をブロードキャスト送信する。また他の端末装置はパケット信号を受信するとともに、前述の情報をもとに車両の接近等を認識する。ここで、路車間通信と車車間通信との干渉を低減するために基地局装置は、複数のサブフレームが含まれたフレームを繰り返し規定する。基地局装置は路車間通信のために、複数のサブフレームのいずれかを選択し、選択したサブフレームの先頭部分の期間において、制御情報等が格納されたパケット信号をブロードキャスト送信する。
当該制御情報には、当該基地局装置がパケット信号をブロードキャスト送信するための期間(以下、「路車送信期間」という)に関する情報が含まれている。端末装置は当該制御情報をもとに路車送信期間を特定し、路車送信期間以外の期間(以下、「車車送信期間」という)においてCSMA方式でパケット信号をブロードキャスト送信する。その結果、路車間通信と車車間通信とが時分割多重される。なお、基地局装置からの制御情報を受信できない端末装置、つまり基地局装置によって形成されたエリアの外に存在する端末装置は、フレームの構成に関係なくCSMA方式でパケット信号を送信する。
図1は、本発明の実施例に係る通信システム500の構成を示す。これは、ひとつの交差点を上方から見た場合に相当する。通信システム500は、基地局装置20、第1車両100aに搭載された端末装置10a、第2車両100bに搭載された端末装置10bを含む。なお、第1車両100aおよび第2車両100bは車両100と総称し、端末装置10aおよび端末装置10bは端末装置10と総称する。エリア202は基地局装置20の電波圏内を示し、エリア外204は基地局装置20の電波圏外を示す。図面の上側が「北」に対応し、第1車両100aは「南」から「北」に進んでおり、第2車両100bは「東」から「西」に進んでいる。基地局装置20は外部ネットワーク200を介して外部の装置と通信が可能である。
図2(a)−(d)は、通信システム500において規定されるスーパーフレームのフォーマットを示す。図2(a)は、スーパーフレームの構成を示す。スーパーフレームは、第1サブフレームから第Nサブフレームと示されるN個のサブフレームによって形成されている。例えば、スーパーフレームの長さが100msecであり、Nが8である場合、12.5msecの長さのサブフレームが規定される。Nは、8以外であってもよい。
図2(b)は、図示しない第1基地局装置20aによって生成されるスーパーフレームの構成を示す。第1基地局装置20aは、基地局装置20のうちの任意のひとつに相当する。第1基地局装置20aは第1サブフレームの先頭部分に路車送信期間を設定する。また、第1基地局装置20aは第1サブフレームにおいて、路車送信期間に続いて車車送信期間を設定する。車車送信期間とは、端末装置10がパケット信号をブロードキャスト送信する期間である。つまり第1サブフレームの先頭期間である路車送信期間において、第1基地局装置20aは必ずこの期間にパケット信号をブロードキャスト送信する。逆に、第1基地局装置20aの電波到達距離内に配置される他の基地局装置20、及びこの電波到達距離内に存在する端末装置10は、この期間にパケット信号をブロードキャスト送信することはない。第1サブフレームの路車送信期間に後続する車車送信期間において、端末装置10がパケット信号をブロードキャスト送信可能であるように規定される。さらに、第1基地局装置20aは第2サブフレームから第Nサブフレームに車車送信期間のみを設定する。
図2(c)は、図示しない第2基地局装置20bによって生成されるスーパーフレームの構成を示す。第2基地局装置20bは、第1基地局装置20aとは異なった基地局装置20に相当する。第2基地局装置20bは、第2サブフレームの先頭部分に路車送信期間を設定する。また第2基地局装置20bは、第2サブフレームにおける路車送信期間の後段、第1サブフレーム、第3サブフレームから第Nサブフレームに車車送信期間を設定する。
図2(d)は、図示しない第3基地局装置20cによって生成されるスーパーフレームの構成を示す。第3基地局装置20cは、第1基地局装置20aや第2基地局装置20bとは異なった基地局装置20に相当する。第3基地局装置20cは、第3サブフレームの先頭部分に路車送信期間を設定する。また第3基地局装置20cは、第3サブフレームにおける路車送信期間の後段、第1サブフレーム、第2サブフレーム、第4サブフレームから第Nサブフレームに車車送信期間を設定する。このように複数の基地局装置20は、互いに異なったサブフレームを選択し、選択したサブフレームの先頭部分に路車送信期間を設定する。このように基地局装置20は、自身のパケット信号(情報)をブロードキャスト送信するために一つのサブフレームの路車送信期間を独占する。これにより基地局装置20は、固有のブロードキャスト送信期間をスーパーフレーム内に確保している。
図3は、基地局装置20の構成を示す。基地局装置20はアンテナ21、RF部22、変復調部23、フレーム処理部24、セキュリティ処理部25、アプリケーション処理部26、ネットワーク通信部27、制御部28、設定部29及びスイッチ29aを備える。セキュリティ処理部25は暗号処理部251、秘密鍵・公開鍵証明書252及び共通鍵テーブル253を含む。
フレーム処理部24、セキュリティ処理部25、アプリケーション処理部26、ネットワーク通信部27、制御部28及び設定部29の構成は、ハードウエア的には、任意のプロセッサ、メモリ、その他のLSIで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。以下、本実施例ではセキュリティ処理部25が、耐タンパ性が確保されたハードウェアモジュールであるSAM(Secure Application Module)で構成される例を想定する。
RF部22は受信処理として、端末装置10および他の基地局装置20からのパケット信号をアンテナ21で受信する。RF部22は、受信した無線周波数のパケット信号を周波数変換し、ベースバンドのパケット信号を生成する。RF部22は、ベースバンドのパケット信号を変復調部23に出力する。一般的に、ベースバンドのパケット信号は同相成分と直交成分によって形成されるため、2つの信号線が示されるべきであるが図を簡略化するため、図3ではひとつの信号線だけを示している。RF部22は受信系の構成要素として、図示しないLNA(Low Noise Amplifier)、ミキサ、AGC、A/D変換部などを含む。
RF部22は送信処理として、生成したパケット信号を基地局装置20から送信する。RF部22は、変復調部23から入力されるベースバンドのパケット信号を周波数変換し、無線周波数のパケット信号を生成する。RF部22は路車送信期間において、無線周波数のパケット信号をアンテナ21から送信する。RF部22は送信系の構成要素として、図示しないPA(Power Amplifier)、ミキサ、D/A変換部などを含む。
変復調部23は受信処理として、RF部22からのベースバンドのパケット信号を復調する。変復調部23は復調した結果から、MACフレームをフレーム処理部24に出力する。また変復調部23は送信処理として、フレーム処理部24からのMACフレームを変調する。変復調部23は変調した結果をベースバンドのパケット信号としてRF部22に出力する。
本実施例に係る通信システム500では、OFDM(Orthogonal Frequency Division Multiplexing)変調方式を採用する。この場合、変復調部23は受信処理としてFFT(Fast Fourier Transform)を実行し、送信処理としてIFFT(Inverse Fast Fourier Transform)を実行する。
フレーム処理部24は、700MHz帯高度道路交通システムの標準規格及び拡張機能ガイドライン(本実施例ではARIB STD−T109、ITS FORUM RC−010を想定)に規定されたプロトコルスタックに従いMACフレームを生成または解釈する。本実施例では拡張機能ガイドラインのMAC層から拡張層までの通信制御を実行する。この通信制御の詳細は後述する。
ネットワーク通信部27は外部ネットワーク200に接続される。外部ネットワーク200には、運転支援システムサービス提供者の図示しない路側機管理装置などが接続されている。ネットワーク通信部27は、外部ネットワーク200から工事や渋滞などに関する道路情報を受信し、アプリケーション処理部26に出力する。またネットワーク通信部27は、アプリケーション処理部26から出力された所定の情報を外部ネットワーク200に送信する。
アプリケーション処理部26は、図示しないセンサやカメラで検知した又は外部ネットワーク200から取得した、交通状況や信号情報などのインフラ情報を含むアプリケーションデータを生成して、セキュリティ処理部25またはフレーム処理部24に出力する。またアプリケーション処理部26は、セキュリティ処理部25またはフレーム処理部24から出力されたアプリケーションデータを解釈して、所定の処理を実行する。
セキュリティ処理部25は所定のセキュリティ処理を実行して、セキュリティフレームを生成または解釈する。本通信システム500では路車間通信に公開鍵暗号方式を使用し、車車間通信に共通鍵暗号方式を使用する。本実施例では路車間通信に、IEEE1609.02で定義されている公開鍵アルゴリズムによる電子署名方式を使用する。また車車間通信に、共通鍵アルゴリズムによるメッセージ認証コード(MAC)方式を使用する。
セキュリティ処理部25は秘密鍵・公開鍵証明書252を保持する。秘密鍵・公開鍵証明書252は、公開鍵アルゴリズムによる電子署名に必要なセキュリティ情報である。なお図示しないが当該セキュリティ情報として、セキュリティ処理部25は認証局(Certification Authority:CA)の証明書も保持する。
公開鍵アルゴリズムによる電子署名方式では、送信側と受信側で異なる鍵を使用する。送信側で秘密鍵を使用して暗号化し、受信側で当該秘密鍵と対をなす公開鍵を使用して復号する。秘密鍵は各装置に固有の鍵である。公開鍵証明書は、当該秘密鍵と対をなす公開鍵と、認証局の署名を含む。この認証局の署名により当該公開鍵の所有者が証明される。
まず基地局装置20が路車間通信における送信側になる場合を説明する。暗号処理部251は、アプリケーション処理部26により生成されたアプリケーションデータを含む署名対象に、自己の秘密鍵を用いた所定のアルゴリズムを適用して署名を生成する。当該アルゴリズムとして例えば、ECDSA(Elliptic Curve−DSA)を使用できる。前述の署名対象には、アプリケーションデータの他にアプリケーションデータのデータ長などを含めることができる。
セキュリティ処理部25は、ヘッダに公開鍵証明書を少なくとも含み、ペイロードにアプリケーションデータを少なくとも含み、フッタに署名を少なくとも含むセキュリティフレームを生成する。セキュリティ処理部25は、セキュリティフレームをフレーム処理部24に出力する。フレーム処理部24は、当該セキュリティフレームに対して拡張層からMAC層までの通信制御を実行する。アンテナ21、RF部22及び変復調部23で構成される送信部は、前述のようにセキュリティ処理が施されたメッセージを含むパケット信号をブロードキャスト送信する。当該ブロードキャスト送信されたパケット信号は、本通信システム500内の他の基地局装置20及び端末装置10により受信される。
次に基地局装置20が他の基地局装置20からブロードキャスト送信されたパケット信号を受信する場合を説明する。アンテナ21、RF部22及び変復調部23で構成される受信部は、他の基地局装置20からブロードキャスト送信されたパケット信号を受信する。フレーム処理部24は、当該パケット信号に対してMAC層から拡張層までの通信制御を実行してセキュリティフレームを取り出す。取り出したセキュリティフレームをセキュリティ処理部25に出力する。
暗号処理部251は、セキュリティフレーム内の公開鍵証明書に含まれる認証局の署名を、保持する認証局の証明書内の認証局公開鍵を用いて検証する。この検証が成功した場合、送信元が正当な公開鍵証明書を保持していることを確認できる。公開鍵証明書の検証が成功すると、暗号処理部251は、セキュリティフレームのフッタに含まれる署名を、公開鍵証明書に含まれる公開鍵を用いて検証する。この検証が成功した場合、アプリケーションデータが改ざんされていないこと、及びそのアプリケーションデータの送信元が公開鍵証明書の保有者であることを確認できる。これらの署名検証が成功すると、セキュリティ処理部25はアプリケーションデータをアプリケーション処理部26に出力する。
セキュリティ処理部25は共通鍵テーブル253を保持する。共通鍵テーブル253は複数の通信鍵を含む。各通信鍵には固有の鍵IDが付加される。前述のように本通信システム500では車車間通信に、共通鍵アルゴリズムによるMAC方式が使用される。共通鍵アルゴリズムは、送信側と受信側で同じ鍵を使用する必要がある。通信システム500で一つの通信鍵を使用すると、その鍵が漏洩した場合のリスクが大きくなる。そこで通信システム500内の各装置で複数の通信鍵を共有して、ランダムに通信鍵を選択して使用する。
共通鍵アルゴリズムによるMAC方式は車車間通信で使用されるが、端末装置10からブロードキャスト送信されたパケット信号は、他の端末装置10だけでなく基地局装置20でも受信される。端末装置10からブロードキャスト送信されたパケット信号の基地局装置20による受信処理は、端末装置10による受信処理と同様である。この端末装置10による受信処理の詳細は後述する。
制御部28は基地局装置20全体の処理を制御する。設定部29及びスイッチ29aは、端末装置10の設定部及びスイッチと同様の機能を有し、その詳細な機能は後述する。
図4は、車両100に搭載された端末装置10の構成を示す。端末装置10はアンテナ11、RF部12、変復調部13、フレーム処理部14、セキュリティ処理部15、アプリケーション処理部16、ユーザインタフェース17、制御部18、設定部19及びスイッチ19aを備える。セキュリティ処理部15は暗号処理部151、共通鍵テーブル153を含む。
フレーム処理部14、セキュリティ処理部15、アプリケーション処理部16、制御部18及び設定部19の構成は、ハードウエア的には、任意のプロセッサ、メモリ、その他のLSIで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。以下、本実施例ではセキュリティ処理部15が、耐タンパ性が確保されたハードウェアモジュールであるSAMで構成される例を想定する。
アンテナ11、RF部12、変復調部13及びフレーム処理部14の構成および動作は、図3の基地局装置20のアンテナ21、RF部22、変復調部23及びフレーム処理部24の構成および動作と共通する。
アプリケーション処理部16は、図示しないGPS受信機、ジャイロスコープ、車速センサなどから供給される情報にもとづき、端末装置10が搭載された車両100の現在位置、進行方向、移動速度などを特定する。なお現在位置は緯度・経度によって示される。これらの情報の特定方法は一般的な公知の技術により実現可能であるため、ここでは説明を省略する。アプリケーション処理部16は、特定した情報をもとにアプリケーションデータを生成して、セキュリティ処理部15またはフレーム処理部14に出力する。
またアプリケーション処理部16は、セキュリティ処理部15またはフレーム処理部14から出力されたアプリケーションデータ及び/又は自車の車両情報にもとづき、衝突の危険性、救急車や消防車といった緊急車両の接近、進行方向の道路および交差点の混雑状況などを推定する。また、データが画像情報であればユーザインタフェース17に表示させる。
ユーザインタフェース17は、図示しないモニタ、ランプ、スピーカなどのユーザへの通知手段を含む。アプリケーション処理部16からの指示にしたがって、図示しない他の車両の接近などを運転者に通知する。また渋滞情報、交差点などの画像情報などをモニタに表示する。
セキュリティ処理部15は所定のセキュリティ処理を実行して、セキュリティフレームを生成または解釈する。まず端末装置10が車車間通信における送信側になる場合を説明する。セキュリティ処理部15は共通鍵テーブル153から、送信に使用する通信鍵を選択する。暗号処理部151は、アプリケーション処理部16により生成されたアプリケーションデータを含むMAC対象に対して、選択された通信鍵を用いた所定のアルゴリズムを適用してMACを生成する。当該アルゴリズムとして例えば、AES(Advanced Encryption Standard)を使用できる。前述のMAC対象には、アプリケーションデータの他に、アプリケーションデータのデータ長、NONCEなどを含めることができる。
セキュリティ処理部15は、ヘッダに鍵IDを少なくとも含み、ペイロードにアプリケーションデータを少なくとも含み、フッタにMACを少なくとも含むセキュリティフレームを生成する。暗号処理部151は、当該セキュリティフレームのペイロードとフッタを含む暗号化対象を、選択された通信鍵を用いて暗号化する。この暗号化のアルゴリズムとして例えば、AES_CTR(CounTeR)を使用できる。セキュリティ処理部15は、暗号化されたセキュリティフレームをフレーム処理部14に出力する。
MAC生成および暗号化はいずれか一方だけを実行してもよい。即ちセキュリティ処理部15は、MACが付加され暗号化もされたメッセージ(認証付き暗号化メッセージ)、MACが付加され暗号化されていないメッセージ(認証付きメッセージ)、MACが付加されず暗号化されているメッセージ(暗号化メッセージ)のいずれのメッセージも生成できる。なおセキュリティ処理部15は、MACが付加されず暗号化もされていないメッセージ(平文メッセージ)も生成できる。
図5は、車車間通信において生成されるパケット信号に含まれるセキュリティフレームのデータ構造の一例を示す。当該セキュリティフレームのデータ構造では、セキュリティヘッダとして「バージョン(VER)」、「メッセージタイプ(MT)」、「鍵ID」、「NONCE」及び「データ長」が配置され、その後にペイロードとして「サービスアプリ(アプリケーションデータ)」が配置され、最後にセキュリティフッタとして「MAC」が配置される。この例では「NONCE」、「データ長」及び「サービスアプリ」がMAC対象である。「鍵ID」により特定される共通鍵テーブル153内の通信鍵により「MAC」が生成され、当該通信鍵により「サービスアプリ」及び「MAC」が暗号化されて秘匿される。この例では鍵共有形式として鍵テーブル方式を採用し、データ認証形式としてMAC方式を採用しているため、セキュリティヘッダには「通信鍵」が配置されず、セキュリティフッタに「MAC」が配置される。
「バージョン(VER)」にはプロトコルバージョンが規定される。「メッセージタイプ(MT)」には平文メッセージ、認証付きメッセージ、暗号化メッセージ、認証付き暗号化メッセージのいずれかが指定される。「NONCE」は送信毎にユニークな値を持つ。例えば、機器ID及び乱数を含んで構成される。「NONCE」を使用することにより、ペイロードに同じアプリケーションデータがセットされたときでもMACや暗号化データを、送信毎に異なった値にできる。
図4に戻る。フレーム処理部14は、当該セキュリティフレームに拡張層からMAC層までの通信制御を実行する。アンテナ11、RF部12及び変復調部13で構成される送信部は、前述のようにセキュリティ処理が施されたメッセージを含むパケット信号をブロードキャスト送信する。当該ブロードキャスト送信されたパケット信号は、本通信システム500内の他の端末装置10及び基地局装置20により受信される。
次に端末装置10が車車間通信における受信側になる場合を説明する。アンテナ11、RF部12及び変復調部13で構成される受信部は、他の端末装置10からブロードキャスト送信されたパケット信号を受信する。フレーム処理部14は、当該パケット信号に対してMAC層から拡張層までの通信制御を実行してセキュリティフレームを取り出し、セキュリティ処理部15に出力する。
暗号処理部151は、セキュリティフレーム内の鍵IDを取得して、共通鍵テーブル153内から当該鍵IDに対応する通信鍵を取得する。暗号処理部151は当該通信鍵を用いて暗号化メッセージを復号する。暗号処理部151は、復号されたメッセージに含まれるMACを検証する。具体的には暗号処理部151は、復号されたアプリケーションデータを含むMAC対象に対して、取得した通信鍵を用いた所定のアルゴリズムを適用してMACを生成する。暗号処理部151は生成したMACと、復号されたメッセージに含まれるMACとを比較し、一致したとき検証成功と判定する。この検証が成功した場合、受信したアプリケーションデータの送信元が正当な通信鍵を保持すること、及びアプリケーションデータが改ざんされていないことを確認できる。復号およびMAC検証が成功すると、セキュリティ処理部15はアプリケーションデータをアプリケーション処理部16に出力する。
端末装置10が路車間通信における受信側になる場合の処理は、前述の基地局装置20が他の基地局装置20からパケット信号を受信する場合の処理と同様である。
制御部18は端末装置10全体の処理を制御する。設定部19は、セキュリティ処理が施されていないメッセージを破棄するか否かをフレーム処理部14に設定する。フレーム処理部14は、設定部19により設定された設定情報に応じて、セキュリティ処理が施されていないメッセージを破棄するか否か決定する。
スイッチ19aは、ユーザにより切り替え操作が可能な物理的なスイッチである。設定部19は、当該スイッチの状態に応じて、セキュリティ処理が施されていないメッセージを破棄するか否かをフレーム処理部14に設定する。例えばスイッチオンの状態で、セキュリティ処理が施されていないメッセージを破棄するに設定し、スイッチオフの状態で、セキュリティ処理が施されていないメッセージを破棄しないに設定する。
なおスイッチ19aの代わりに、USB端子などの外部端子が設けられてもよい。当該外部端子にPC、タブレット等のコンピュータを接続して、当該コンピュータからコマンドを入力して、セキュリティ処理が施されていないメッセージを破棄するか否かをフレーム処理部14に設定してもよい。
設定部19はユーザ操作に従い、端末装置10が出荷前の状態で、セキュリティ処理が施されていないメッセージを破棄しないに設定し、端末装置10が出荷後の状態で、セキュリティ処理が施されていないメッセージを破棄するに設定してもよい。
前述の700MHz帯高度道路交通システムでは、765MHzを中心周波数とした10MHzの1チャンネルの中で車車間通信と路車間通信を時分割処理で対応している。1台の端末装置10(以下、車載器と表記する)の送信時間は、隣接周波数への干渉を回避するため1台あたり300μsec程度しか許容されていない。300μsecの送信時間をデータ量に換算すると、変調方式など信号処理に依存するが100バイト程度となる。即ち車載器から送信されるパケット信号は、データ長による大きな制限を受ける。車車間通信では、車載器は100msecに1回、自己の位置や速度などの車両情報を含むパケット信号をブロードキャスト送信する。
正規の車載器以外の無線機による「なりすまし」などを防ぐためにセキュリティ対策が必要である。国際規格であるIEEE1609.2では各車載器は公開鍵証明書を保持し、その公開鍵証明書を含むパケット信号を送信する。そのパケット信号を受信した車載器は、その公開鍵証明書が正当なものであるか否か認証処理する。これにより正当な車載器から送信されたパケット信号であることを確認できる。
しかしながら、この公開鍵証明書のデータ長を100バイト以下に抑えることは難しく150バイト程度のデータ量が必要になる。従って700MHz帯高度道路交通システムにおいて車載器が送信するパケット信号に、公開鍵証明書が必要なセキュリティ対策を使用することは難しい。
次に考えられるセキュリティ対策として、通信鍵を車載器間で共有する方法がある。この方法では、送信元の特定はできないが正当な送信元であることは認識できる。前述のようにメッセージにMACを付加することで、データが改ざんされていないことを確認できる。またデータを暗号化することで秘匿性も確保できる。従って700MHz帯高度道路交通システムのようなパケットのデータ長が短いシステムでは、このような通信鍵を共有してMAC生成および/または暗号化するセキュリティ対策が有効である。通信鍵の共有による正当性の保証は、鍵を使用する処理を実行することが前提である。
700MHz帯高度道路交通システムにおいては、セキュリティ対策されているサービスも、セキュリティ対策されていないサービスも許容している。従ってセキュリティ処理が施されていないパケット信号を受理してしまうリスクを伴う。
また相互接続性の確認という観点からは、セキュリティ対策が必須のサービスにおいても、接続テストの段階では、セキュリティ対策なしでの接続性を先に確認し、後にセキュリティ対策ありでの接続性を確認する。従って車載器としては、セキュリティ対策ありとなしの両方をサポートすることが望ましい。セキュリティ対策なしの状態は、セキュリティモジュール(図4のセキュリティ処理部15)を経由しない場合と、セキュリティモジュールは経由するが平文の状態であると認識される場合の2通りがある。両者に共通していえるのは受信処理の中で、車載器間で共有された通信鍵を使用しないことである。
700MHz帯高度道路交通システムの標準規格(ARIB STD−T109)のプロトコルスタックでは、レイヤ1(物理層:Physical Layer)、レイヤ2(データリンク層:Data Link Layer)、車車間・路車間共用通信制御情報層(IVC−RVC層:Inter−Vehcle Communication−Road to Vehcle Communication Layer)、レイヤ7(アプリケーション層:Application Layer)の4層構造を規定している。
レイヤ1(物理層)は、物理媒体依存副層と物理層コンバージェンス手順副層を備える。物理媒体依存副層は、OFDMシステムを用いる端末の間でデータの送受信を行う特性と方法を規定する。物理層コンバージェンス手順副層は、物理媒体依存副層の機能を物理層サービスに適合させる機能を規定する。レイヤ2(データリンク層)は、MAC副層とLLC副層を備える。MAC副層方式としてCSMA/CA方式を適用する。LLC副層は、上位層のエンティティ間でパケット伝送を行うために、確認なしコネクションレス型サービスを提供するための方法を規定する。
車車間・路車間共用通信制御情報層(IVC−RVC)層は、車車間・路車間共用通信制御に必要な情報の生成・管理を行い、送信制御に必要なパラメータをMAC副層に受け渡す方法を規定する。レイヤ7(アプリケーション層)は、アプリケーションに対して通信制御手段及びサービスを提供するとともに、IVC−RVC層を介してデータの送受信を行う方法を規定する。
700MHz帯高度道路交通システムの拡張機能ガイドライン(ITS FORUM RC−010)では、標準規格の4層とアプリケーションの間に拡張プロトコルとして拡張層(EL層:Extened Layer)を規定している。拡張層(EL層)は、アプリケーションデータの分割・統合、セキュリティモジュールへのアクセスを規定している。
図6は、セキュリティモジュール15aを通る場合の送信車載器10sと受信車載器10rのデータの流れを示す図である。物理層13aに規定されるプロトコルは、図4のアンテナ11、RF部12及び変復調部13で実現される。データリンク層14a、IVC−RVC層14b、アプリケーション層14c及びEL層14dに規定されるプロトコルは、図4のフレーム処理部14で実現される。セキュリティモジュール15aは図4のセキュリティ処理部15に相当する。アプリケーション16aは、図4のアプリケーション処理部16に相当する。
送信車載器10sでは、アプリケーション16a、EL層14d、セキュリティモジュール15a、EL層14d、アプリケーション層14c、IVC−RVC層14b、データリンク層14a、物理層13aの順にデータが流れる(R1〜R7)。送信車載器10sから受信車載器10rにデータが送信される(R8)。受信車載器10rでは送信車載器10sと逆に、物理層13a、データリンク層14a、IVC−RVC層14b、アプリケーション層14c、EL層14d、セキュリティモジュール15a、EL層14d、アプリケーション16aの順にデータが流れる(R9〜R16)。
図7は、セキュリティモジュール15bを通らない場合の送信車載器10sと受信車載器10rのデータの流れを示す図である。送信車載器10sでは、アプリケーション16a、EL層14d、アプリケーション層14c、IVC−RVC層14b、データリンク層14a、物理層13aの順にデータが流れる(R21〜R25)。送信車載器10sから受信車載器10rにデータが送信される(R26)。受信車載器10rでは送信車載器10sと逆に、物理層13a、データリンク層14a、IVC−RVC層14b、アプリケーション層14c、EL層14d、アプリケーション16aの順にデータが流れる(R27〜R31)。
図8(a)−(c)は、各種ヘッダのフィールド構成の一例を示す図である。図8(a)は、アプリケーションデータのヘッダ部の中の、サービスID(以下、SIDという)のフィールド構成の一例を示す図である。「b000」がサービスA、「b001」がサービスB、「b010」がサービスCをそれぞれ示し、「b011」−「b111」はリザーブである。IDの最初の「b」は、後の続きの数字が2進数の0又は1であることを示している。図8(a)ではSIDが3ビット構成の例を示しているが、ビット数は許容するサービス数に依存しており3ビット構成に限るものではない。700MHz帯高度道路交通システムでは、将来的にいくつかのサービスが行われることが想定されている。以下の説明では、車車間通信の安全安心サービスをサービスAとする。
図8(b)は、ELヘッダ内のセキュリティ種別情報(以下、SCという) のフィールド構成の一例を示す図である。「b00」がセキュリティモジュールのアクセスを行わない、「b01」がセキュリティモジュールのアクセスをレイヤ7で行う、「b10」がセキュリティモジュールのアクセスをEL層で行う、をそれぞれ示し、「b11」はリザーブである。IDの最初の「b」は、後の続きの数字が2進数の0又は1であることを示している。図8(b)では2ビットで、セキュリティモジュールのアクセスに関する情報を指定する例を示している。なお、「b10」のセキュリティモジュールのアクセスをレイヤ7で行うは、本実施例では使用しない。
図8(c)は、セキュリティヘッダ内のセキュリティ情報(以下、SIという) のフィールド構成の一例を示す図である。「b00」が平文、「b01」が非暗号・MAC付き、「b10」が暗号化、「b11」が暗号化・MAC付きをそれぞれ示している。IDの最初の「b」は、後の続きの数字が2進数の0又は1であることを示している。SIは、上記図5の「メッセージタイプ(MT)」に対応する。
図9は、図6に示したセキュリティモジュール15aを通る場合のデータ構造の一例を示す図である。図10は、図7に示したセキュリティモジュール15aを通らない場合のデータ構造の一例を示す図である。図9、10のアプリケーションデータは、SID=「b000」のサービスAのアプリケーションデータである。なお図9の符号R1〜R16は図6の符号R1〜R16に対応しており、図10の符号R21〜R31は図7の符号R21〜R31に対応している。
まず図10のセキュリティモジュール15aを通らない場合のデータ構造を先に説明する。送信車載器10sのアプリケーション処理部16は、アプリケーション16aの処理として、アプリケーションデータを生成する際にSIDを「b000」に設定し、当該SIDを含むアプリケーションデータをフレーム処理部14に渡す(R21)。フレーム処理部14は、EL層14dの処理として、アプリケーション処理部16から渡されたアプリケーションデータに、SCを「b00」に設定したELヘッダを付加する。なお、送信車載器10sのアプリケーション層14cから物理層13cまでの処理、及び受信車載器10rの物理層13cからアプリケーション層14cまでの処理の説明は省略する(R22〜R30)。
受信車載器10rのフレーム処理部14は、EL層14dにおいて、SCが「b00」であるため、セキュリティモジュール15aのアクセスを行わないと判断する。フレーム処理部14は、EL層14dの処理として、ELヘッダを除去したアプリケーションデータをアプリケーション処理部16に渡す(R31)。アプリケーション処理部16は、アプリケーション16aにおいて、SIDが「b000」であることを確認し、サービスAのアプリケーションデータであることを認識する。
次に図9のセキュリティモジュール15aを通る場合のデータ構造を説明する。送信車載器10sのアプリケーション処理部16は、アプリケーション16aの処理として、アプリケーションデータを生成する際にSIDを「b000」に設定し、当該SIDを含むアプリケーションデータをフレーム処理部14に渡す(R1)。フレーム処理部14は、アプリケーション処理部16から渡されたアプリケーションデータをセキュリティモジュール15aに渡す(R2)。セキュリティモジュール15aは、アプリケーションデータの前後にセキュリティヘッダ及びセキュリティフッタを付加する。セキュリティモジュール15aは、それらが付加されたアプリケーションデータをフレーム処理部14に渡す(R3)。フレーム処理部14は、EL層14dの処理として、セキュリティモジュール15aから渡されたセキュリティ付きアプリケーションデータに、SCを「b10」に設定したELヘッダを付加する。送信車載器10sのアプリケーション層14cから物理層13cまでの処理、及び受信車載器10rの物理層13cからアプリケーション層14cまでの処理の説明は省略する(R4〜R13)。
受信車載器10rのフレーム処理部14は、EL層14dにおいて、SCが「b10」であるため、セキュリティモジュール15aのアクセスを行うと判断する。フレーム処理部14は、EL層14dの処理として、ELヘッダを除去したセキュリティ付きアプリケーションデータをセキュリティモジュール15aに渡す(R14)。セキュリティモジュール15aは、フレーム処理部14から渡されたセキュリティ付きアプリケーションデータにセキュリティ処理を施し、セキュリティヘッダ及びセキュリティフッタを除去する。セキュリティモジュール15aは、それらが除去されたアプリケーションデータをフレーム処理部14に渡す(R15)。フレーム処理部14は、セキュリティモジュール15aから渡されたアプリケーションデータをアプリケーション処理部16に渡す(R16)。アプリケーション処理部16は、アプリケーション16aにおいて、SIDが「b000」であることを確認し、サービスAのアプリケーションデータであることを認識する。
図11は、図6に示したセキュリティモジュール15aを通る場合のデータ構造が平文の場合の例を示す図である。図8(c)に示したようにセキュリティタイプには平文(平文メッセージ)、MACによる署名(認証付きメッセージ)、データ暗号化(暗号化メッセージ)、データ暗号化とMACによる署名の両方(認証付き暗号化メッセージ)の、4種類が規定されている。平文の場合、アプリケーションデータ自体にセキュリティ処理が施されないが、セキュリティモジュール15aを経由するため、アプリケーションデータにセキュリティヘッダ及びセキュリティフッタが付加される。
送信車載器10sのアプリケーション処理部16は、アプリケーション16aの処理として、アプリケーションデータを生成する際にSIDを「b000」に設定し、当該SIDを含むアプリケーションデータをフレーム処理部14に渡す(R1)。フレーム処理部14は、アプリケーション処理部16から渡されたアプリケーションデータをセキュリティモジュール15aに渡す(R2)。セキュリティモジュール15aは、アプリケーションデータの前後にセキュリティヘッダ及びセキュリティフッタを付加する。この例では平文処理のため、セキュリティヘッダ内のSIを「b00」に設定する。セキュリティモジュール15aは、セキュリティヘッダ及びセキュリティフッタが付加されたアプリケーションデータをフレーム処理部14に渡す(R3)。フレーム処理部14は、EL層14dの処理として、セキュリティモジュール15aから渡されたデータに、SCを「b10」に設定したELヘッダを付加する。送信車載器10sのアプリケーション層14cから物理層13cまでの処理、及び受信車載器10rの物理層13cからアプリケーション層14cまでの処理の説明は省略する(R4〜R13)。
受信車載器10rのフレーム処理部14は、EL層14dにおいて、SCが「b10」であるため、セキュリティモジュール15aのアクセスを行うと判断する。フレーム処理部14は、EL層14dの処理として、ELヘッダを除去したデータをセキュリティモジュール15aに渡す(R14)。セキュリティモジュール15aは、フレーム処理部14から渡されたデータのセキュリティヘッダ内のSIが「b00」であることを確認し、平文と認識する。セキュリティモジュール15aは、フレーム処理部14から渡されたデータからセキュリティヘッダ及びセキュリティフッタを除去して、フレーム処理部14に渡す(R15)。フレーム処理部14は、セキュリティモジュール15aから渡されたアプリケーションデータをアプリケーション処理部16に渡す(R16)。アプリケーション処理部16は、アプリケーション16aにおいて、SIDが「b000」であることを確認し、サービスAのアプリケーションデータであることを認識する。
以下、図4のフレーム処理部14の機能および設定部19の機能を、より詳細に説明する。フレーム処理部14は、受信データセキュリティ情報識別機能および受信データ判定機能を有する。設定部19はデータ選別条件通知機能を有する。データ選別条件通知機能は、セキュリティモジュール15aでセキュリティ処理が施されない平文のデータ、及びセキュリティモジュール15aを経由しないデータを受理対象とするか否かを示す選別条件を受信データ判定機能に通知する。この選別条件は例えば、物理的なスイッチやソフトウエアのコマンドなどで指定される。
受信データセキュリティ情報識別機能は、ELヘッダ、セキュリティヘッダを確認し、受信データのセキュリティ処理の内容を識別する。受信データ判定機能は、アプリケーションのサービス種別、及び選別条件にもとづき、受信データを破棄するか受理するかを判定する。
図12は、受信車載器10rの受理処理を示すフローチャートである。アンテナ11でパケット信号を受信し(S10)、RF部12及び変復調部13は、受信されたパケット信号に含まれるデータに復調処理などを施し、フレーム処理部14に渡す。フレーム処理部14は、変復調部13から渡されたデータに対して、データリンク層14a、IVC−RVC層14b、アプリケーション層14c、EL層14dに規定された処理を順番に実行する。
フレーム処理部14は、ELヘッダに含まれるSCを確認する(S11)。SCが「b00」でなく(S11のN)、「b10」である場合(S12のY)、フレーム処理部14は、データをセキュリティモジュール15aに渡す。セキュリティモジュール15aは、セキュリティヘッダに含まれるSIを確認する(S13)。SIが「b00」でない場合(S13のN)、セキュリティモジュール15aは、送信車載器10sと共有されている通信鍵を使用して復号および/またはMAC検証を実行する(S14)。復号および/またはMAC検証が成功した場合(S14のY)、セキュリティモジュール15aは、アプリケーションデータをフレーム処理部14に返し、フレーム処理部14は、返されたアプリケーションデータをアプリケーション処理部16に渡す。アプリケーション処理部16は、アプリケーションデータのヘッダに含まれるSIDを確認する(S15)。SIDが「b000」である場合(S15のY)、アプリケーションデータを正式に受理する(S16)。
ELヘッダに含まれるSCが「b00」でなく(S11のN)、「b10」でもない場合(S12のN)、フレーム処理部14は受信されたデータを破棄する(S18)。ELヘッダに含まれるSCが「b00」であり(S11のY)、データ選別スイッチがオンの場合(S17のY)、フレーム処理部14は受信されたデータを破棄する(S18)。ELヘッダに含まれるSCが「b00」であり(S11のY)、データ選別スイッチがオフの場合(S17のN)、ステップS15に移行する。
ELヘッダに含まれるSCが「b10」であり(S11のN、S12のY)、セキュリティヘッダに含まれるSIが「b00」であり(S13のY)、データ選別スイッチがオンの場合(S17のY)、フレーム処理部14は受信されたデータを破棄する(S18)。ELヘッダに含まれるSCが「b10」であり(S11のN、S12のY)、セキュリティヘッダに含まれるSIが「b00」であり(S13のY)、データ選別スイッチがオフの場合(S17のN)、ステップS15に移行する。
ステップS14にて、通信鍵を使用した復号および/またはMAC検証が失敗した場合(S14のN)、セキュリティモジュール15aは受信されたデータを破棄する(S18)。ステップS15にて、SIDが「b000」でない場合(S15のN)、アプリケーション処理部16は、受信されたデータを破棄する(S18)。
以上説明したように本実施例によれば、通信鍵を共有しない無線機からの、平文メッセージを含む平文パケットを受理しない機能を搭載することにより、第三者によるなりすましの脅威を低減できる。即ち、通信鍵を共有する通信システム内の無線機で生成されるパケットと同じデータ構造を持つ平文パケットを、当該通信システム外の無線機が送信した場合、その平文パケットを当該通信システム内の無線機が受理してしまうことを防止して、安全性を向上させることができる。
以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
本発明は、共通鍵暗号方式を採用したブロードキャスト通信全般に適用可能であり、700MHz帯高度道路交通システムに限定されない。また本発明は、共通鍵暗号方式を採用したブロードキャスト通信システムにおいて、共有された通信鍵を用いたセキュリティ処理が施されていないメッセージを常に破棄する端末装置にも適用可能である。
10 端末装置、 11 アンテナ、 12 RF部、 13 変復調部、 13a 物理層、 14 フレーム処理部、 14a データリンク層、 14b IVC−RVC層、 14c アプリケーション層、 14d EL層、 15 セキュリティ処理部、 15a セキュリティモジュール、 151 暗号処理部、 153 共通鍵テーブル、 16 アプリケーション処理部、 17 ユーザインタフェース、 18 制御部、 19 設定部、 19a スイッチ、 20 基地局装置、 21 アンテナ、 22 RF部、 23 変復調部、 24 フレーム処理部、 25 セキュリティ処理部、 251 暗号処理部、 252 秘密鍵・公開鍵証明書、 253 共通鍵テーブル、 26 アプリケーション処理部、 27 ネットワーク通信部、 28 制御部、 29 設定部、 29a スイッチ、 200 外部ネットワーク、 202 エリア、 204 エリア外、 500 通信システム。

Claims (5)

  1. 通信鍵を共有する他の端末装置からブロードキャスト送信されたパケット信号を受信する受信部と、
    前記パケット信号に含まれるメッセージに、前記通信鍵を用いた共通鍵暗号方式によるセキュリティ処理が施されていない場合、当該メッセージを破棄する処理部と、
    を備えることを特徴とする端末装置。
  2. 他の端末装置からブロードキャスト送信されるメッセージのタイプとして、
    平文タイプ、
    前記メッセージに前記通信鍵をもとに生成されるMAC(Message Authentication Code)が付加されるタイプ、
    前記メッセージが前記通信鍵を用いて暗号化されるタイプ、及び
    前記メッセージに前記MACが付加され、かつ前記通信鍵を用いて暗号化されるタイプが選択可能であり、
    前記処理部は、受信されたパケット信号に含まれるメッセージが平文タイプである場合、当該メッセージを破棄することを特徴とする請求項1に記載の端末装置。
  3. 前記セキュリティ処理が施されていないメッセージを破棄するか否かを前記処理部に設定する設定部を、さらに備え、
    前記処理部は、前記設定部により設定された設定情報に応じて、前記セキュリティ処理が施されていないメッセージを破棄するか否か決定することを特徴とする請求項1または2に記載の端末装置。
  4. ユーザにより切り替え操作が可能な物理的なスイッチを、さらに備え、
    前記設定部は、前記スイッチの状態に応じて、前記セキュリティ処理が施されていないメッセージを破棄するか否かを前記処理部に設定することを特徴とする請求項3に記載の端末装置。
  5. 前記受信部は、基地局装置がパケット信号をブロードキャスト送信可能な第1期間と、端末装置間のCSMA/CA通信に使用可能な第2期間とが時分割多重されたフレームのうち、第1期間において、基地局装置から公開鍵証明書が付与されたパケット信号を受信するとともに、第2期間において、通信鍵を共有する他の端末装置からブロードキャスト送信されたパケット信号を受信することを特徴とする請求項1から4のいずれかに記載の端末装置。
JP2014013451A 2014-01-28 2014-01-28 端末装置 Pending JP2015142213A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2014013451A JP2015142213A (ja) 2014-01-28 2014-01-28 端末装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014013451A JP2015142213A (ja) 2014-01-28 2014-01-28 端末装置

Publications (1)

Publication Number Publication Date
JP2015142213A true JP2015142213A (ja) 2015-08-03

Family

ID=53772321

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014013451A Pending JP2015142213A (ja) 2014-01-28 2014-01-28 端末装置

Country Status (1)

Country Link
JP (1) JP2015142213A (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004201038A (ja) * 2002-12-18 2004-07-15 Internatl Business Mach Corp <Ibm> データ記憶装置、これを搭載した情報処理装置及びそのデータ処理方法並びにプログラム
JP2006041726A (ja) * 2004-07-23 2006-02-09 Matsushita Electric Ind Co Ltd 共有鍵交換システム、共有鍵交換方法及び方法プログラム
JP2013229886A (ja) * 2010-07-13 2013-11-07 Sanyo Electric Co Ltd 車載器

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004201038A (ja) * 2002-12-18 2004-07-15 Internatl Business Mach Corp <Ibm> データ記憶装置、これを搭載した情報処理装置及びそのデータ処理方法並びにプログラム
JP2006041726A (ja) * 2004-07-23 2006-02-09 Matsushita Electric Ind Co Ltd 共有鍵交換システム、共有鍵交換方法及び方法プログラム
JP2013229886A (ja) * 2010-07-13 2013-11-07 Sanyo Electric Co Ltd 車載器

Similar Documents

Publication Publication Date Title
JP6103274B2 (ja) 車載器
JP5362925B2 (ja) 路側機および車載器
JP5390036B2 (ja) 車載器
JP5350560B1 (ja) 路側機および車載器
JP2008228051A (ja) 暗号通信システム、暗号通信方法、暗号通信プログラム、車載端末およびサーバ
JP6112467B2 (ja) 通信装置
JP2014158105A (ja) 端末装置
JP2015142213A (ja) 端末装置
JP5991560B2 (ja) 無線装置
JP6183629B2 (ja) 処理装置
JP2015050586A (ja) 車載器
JP2014158104A (ja) 端末装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20160801

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170515

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170606

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170705

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20171128

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20180529