JP2013048374A - 保護通信方法 - Google Patents
保護通信方法 Download PDFInfo
- Publication number
- JP2013048374A JP2013048374A JP2011186243A JP2011186243A JP2013048374A JP 2013048374 A JP2013048374 A JP 2013048374A JP 2011186243 A JP2011186243 A JP 2011186243A JP 2011186243 A JP2011186243 A JP 2011186243A JP 2013048374 A JP2013048374 A JP 2013048374A
- Authority
- JP
- Japan
- Prior art keywords
- message
- work key
- ecu
- format
- serial number
- 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.)
- Withdrawn
Links
Images
Landscapes
- Small-Scale Networks (AREA)
Abstract
【課題】CANにおけるフォーマットの互換性確保とセキュリティ性向上を両立させた保護通信方法を提供することを課題とする。
【解決手段】CAN通信プロトコルに基づいて送受信されるデータを保護するための保護通信方法であって、MAC(メッセージ認証コード)を生成し(S46)、MACと送信データを暗号化し(S48)、その暗号化したMACと通し番号とワーク鍵IDをCAN通信プロトコルの拡張フォーマットの識別子拡張領域に格納し、標準フォーマット互換のメッセージIDを拡張フォーマットの識別子ベース領域に格納し、暗号化した送信データを拡張フォーマットのデータ領域に格納し(S49)、その拡張フォーマットでメッセージを送信する(S49)。
【選択図】図6
【解決手段】CAN通信プロトコルに基づいて送受信されるデータを保護するための保護通信方法であって、MAC(メッセージ認証コード)を生成し(S46)、MACと送信データを暗号化し(S48)、その暗号化したMACと通し番号とワーク鍵IDをCAN通信プロトコルの拡張フォーマットの識別子拡張領域に格納し、標準フォーマット互換のメッセージIDを拡張フォーマットの識別子ベース領域に格納し、暗号化した送信データを拡張フォーマットのデータ領域に格納し(S49)、その拡張フォーマットでメッセージを送信する(S49)。
【選択図】図6
Description
本発明は、CAN通信プロトコルに基づいて送受信されるデータを保護するための保護通信方法に関する。
車載のECU[Electronic Control Unit]間の基幹ネットワークとして、一般に、CAN[Controller Area Network]が用いられている。CANには、OBD[OnBoard Diagnosis]のためのインタフェースやECU追加のためのコネクタも用意されている。このような箇所からCANに接続し、外部から不正メッセージを送信することも可能である。このような不正メッセージを排除してセキュリティ性を向上させるために、一般に、メッセージにMAC[Message Authentication Code](メッセージ認証コード)を付与する手法がある。特許文献1には、ネットワークにおけるデータ通信においてMACを暗号化して送信する技術が開示されている。
セキュリティ性を向上させるためには、上記のようにMAC等のセキュリティに関するデータを追加する必要がある。しかし、CANの場合、標準フォーマットが決まっており、データ領域に格納可能なデータは最大8バイトであり、データ領域に格納するデータは決まっているので、データ領域に安全な長さのMACを格納することは困難である。また、MACを付加するために、送信データ量を大幅に増加すると、コストアップにつながる。さらに、CANは車載の標準の基幹ネットワークとして定着しているので、他の通信方式に移行することは難しい。
そこで、本発明は、CANにおけるフォーマットの互換性確保とセキュリティ性向上を両立させた保護通信方法を提供することを課題とする。
本発明に係る保護通信方法は、CAN通信プロトコルに基づいて送受信されるデータを保護するための保護通信方法であって、メッセージ認証コードを生成する生成ステップと、生成ステップで生成したメッセージ認証コードと送信データを暗号化する暗号化ステップと、暗号化ステップで暗号化したメッセージ認証コードをCAN通信プロトコルの拡張フォーマットの識別子拡張領域に格納し、暗号化ステップで暗号化した送信データを拡張フォーマットのデータ領域に格納する格納ステップと、格納ステップで格納した拡張フォーマットでメッセージを送信する送信ステップとを含むこと特徴とする。
この保護通信方法では、生成ステップでメッセージ認証コードを生成し、暗号化ステップでメッセージ認証コードと送信データをそれぞれ暗号化する。そして、保護通信方法では、格納ステップで少なくとも暗号化したメッセージ認証コードを拡張フォーマットの識別子拡張領域に格納するとともに暗号化した送信データを拡張フォーマットのデータ領域に格納し、送信ステップでその拡張フォーマットでメッセージを送信する。この際、拡張フォーマットの識別子ベース領域には、標準フォーマット互換の識別子(ID)が格納される。したがって、CANのハードウェアでは拡張フォーマットとして処理でき、CANに接続される各ノードのアプリケーションソフトウェアでは拡張フォーマットの識別子ベース領域に格納される標準フォーマット互換の識別子(ID)を用いて標準フォーマットと同等に処理できる。また、拡張フォーマットの識別子拡張領域に格納される暗号化したメッセージ認証コードを用いてメッセージを認証でき、メッセージの安全性を向上できる。さらに、メッセージ認証コードを暗号化することにより、少ないデータ量でもメッセージの安全性を向上でき、拡張フォーマットの識張子拡張領域内において暗号化メッセージ認証コードを格納する領域を確保でき、拡張フォーマットのデータ領域にメッセージ認証コードを格納しなくてよい。また、送信データを暗号化することにより、送信データの安全性を向上できる。このように、保護通信方法では、メッセージ認証コードと送信データを暗号化し、この暗号化したメッセージ認証コードと送信データを拡張フォーマットを利用して送信することにより、CANにおけるフォーマットの互換性を確保しつつセキュリティ性を向上させることができる。
本発明の上記保護通信方法では、格納ステップではワーク鍵ID、メッセージの通し番号をCAN通信プロトコルの拡張フォーマットの識別子拡張領域に格納し、送信ステップで送信された拡張フォーマットのメッセージを受信したノードにおいて、通し番号の検証又はメッセージ認証コードの検証で異常を検出した場合、防御モードに移行する。
この保護通信方法では、格納ステップで拡張フォーマットの識別子拡張領域に暗号化メッセージ認証コードの他にワーク鍵IDとメッセージの通し番号を格納し、送信ステップでその拡張フォーマットでメッセージを送信する。CANバスに接続する各ノードでは、この拡張フォーマットのメッセージを受信した場合、メッセージの通し番号で検証するとともにメッセージ認証コードを用いて検証し、少なくとも一方の検証で異常を検出した場合には防御モードに移行する。このように、保護通信方式では、通し番号とメッセージ認証コードによってメッセージを検証することにより、再送攻撃等の不正メッセージを高精度に検出でき、メッセージの安全性を向上でき、セキュリティ性がより向上する。
本発明によれば、メッセージ認証コードと送信データを暗号化し、この暗号化したメッセージ認証コードと送信データを拡張フォーマットを利用して送信することにより、CANにおけるフォーマットの互換性を確保しつつセキュリティ性を向上させることができる。
以下、図面を参照して、本発明に係る保護通信方法の実施の形態を説明する。なお、各図において同一又は相当する要素については同一の符号を付し、重複する説明を省略する。
本実施の形態では、本発明に係る保護通信方法を、車両に搭載されるCAN通信システムに適用する。本実施の形態に係るCAN通信システムは、CAN2.0の通信プロトコルに基づいてメッセージを送受信する車載LAN[Local Area Network]であり、CANバスに複数のECU(ノード)が接続されている。特に、本実施の形態では、CAN通信システムにおける保護通信処理について詳細に説明する。
なお、CAN2.0の通信プロトコルのデータフレームには、標準フォーマットと拡張フォーマットがある。標準フォーマット、拡張フォーマットは、データを格納するデータ領域とメッセージIDを格納する識別子領域(ID領域)を有している。データ領域は、0〜8バイト(0〜64ビット)のデータを格納可能である。標準フォーマットの識別子領域は、11ビット長である。拡張フォーマットの識別子領域は、29ビット長である。拡張フォーマットの識別子領域は、11ビット長の識別子ベース領域と18ビット長の識別子拡張領域で構成される。
図1〜図3を参照して、本実施の形態に係るCAN通信システム1について説明する。図1は、本実施の形態に係るCAN通信システムの構成図である。図2は、保護通信メンバECUのメモリに確保される保護通信で必要なバッファであり、(a)がワーク鍵関連のバッファであり、(b)が送信メッセージ関連のバッファであり、(c)が受信メッセージ関連のバッファである。図3は、保護メッセージの拡張フォーマットの識別子領域である。
CAN通信システム1は、保護通信のマスタとなる保護通信マスタECU2と相互に保護通信を行う複数の保護通信メンバECU3(3A,3B)とからなり、各ECU2,3がCANバス4に接続されている。また、CAN通信システム1は、保守用のOBD−IIポート5やECU追加のためのコネクタ(図示せず)なども備えており、これらもCANバス4に接続されている。例えば、OBD−IIポート5に不正送信機器WEが接続され、OBD−IIポート5からCANバス4上に不正メッセージを送信することが可能である。CAN通信システム1では、保護対象のメッセージの場合、そのような不正メッセージを検出し、不正メッセージを排除する保護通信を行う。本実施の形態では、各ECU2,3に搭載される中位層のソフトウェアによる処理で保護通信のための各処理を行う。
保護通信マスタECU2では、周期的に、ワーク鍵シードを格納してワーク鍵シードメッセージを送信する。保護通信メンバECU3では、ワーク鍵シードメッセージを受信すると、ワーク鍵シードからワーク鍵を生成する(周期的にワーク鍵を更新する)。保護メッセージを送信する場合、保護通信メンバECU3Aでは、MACを生成し、MACと送信データ本体を暗号化し、拡張フォーマットのデータ領域に暗号化した送信データ本体を格納するとともに拡張フォーマットの識別子拡張領域にワーク鍵ID、通し番号、暗号化したMACを格納してメッセージを送信する。保護メッセージを受信した場合、保護通信メンバECU3Bでは、暗号化された送信データ本体とMACを復号化し、通し番号とMACで検証し、検証で異常を検出した場合には防御モードに移行する。
なお、ワーク鍵は、CAN通信システム1において周期的に更新される鍵であり、本実施の形態ではストリーム暗号化に用いる鍵ストリームを生成するために使われる。ワーク鍵IDは、ワーク鍵の更新タイミングを送信側と受信側で同期をとるために用いられ、本実施の形態ではワーク鍵シードを更新(ひいては、ワーク鍵を更新)する際に0と1とで切り替えられる。ワーク鍵シードは、ワーク鍵を生成するためのシードであり、本実施の形態では64ビットとする。通し番号は、送信側の保護通信メンバECU3Aが送信するメッセージID毎に付与され、同じメッセージIDのメッセージを送信する毎に1ずつ増加する番号であり、ワーク鍵が更新される毎にリセットされる。システム鍵は、CAN通信システム1に接続される全てのECUが事前に持っている共有鍵である。
保護通信マスタECU2は、保護通信でマスタとなるECUであり、保護通信を行うECUの中から任意のECUが選択される。保護通信マスタECU2は、周期的に、ワーク鍵シードを生成し、ワーク鍵IDを付加したワーク鍵シードメッセージを送信する。
具体的には、保護通信マスタECU2では、一定時間毎に、ワーク鍵シードを生成し、標準フォーマットのデータ領域にワーク鍵シードを格納するとともに識別子領域(ID28〜ID18)にワーク鍵IDのメッセージIDを格納し、ワーク鍵シードメッセージをCANバス4上に送信する。ワーク鍵シードは、例えば、64ビット長乱数である。ワーク鍵ID=0の場合にはメッセージIDを0x10とし、ワーク鍵ID=1の場合にはメッセージIDを0x11とする。ワーク鍵IDはワーク鍵メッセージを送信する毎(ワーク鍵シードを更新する毎)に切り替えられ、0、1、0、1・・・が繰り返される。なお、ワーク鍵シードメッセージのCRC[Cyclic Redundancy Check]は、送信時にCANのハードウェアによって付与されるものとする。
保護通信メンバECU3は、相互に保護通信を行う複数のECUである。保護通信メンバECU3は、ワーク鍵シードメッセージを受信する毎に、ワーク鍵シードメッセージからワーク鍵IDとワーク鍵シードを取得し、ワーク鍵を生成する。また、送信側の保護通信メンバECU3Aは、保護メッセージの場合、通し番号とデータ本体のMACを計算し、データ本体と平文MAC(MACの一部)をワーク鍵を用いたストリーム暗号で暗号化し、暗号化データ本体の他にワーク鍵ID、通し番号、暗号化MACを拡張フォーマットに格納して保護メッセージを送信する。また、保護通信メンバECU3Bは、保護メッセージを受信すると、暗号化データ本体と暗号化MACを復号化し、その復号化したデータ本体と通し番号のMACを計算し、計算したMACと復号化したMACとを検証するとともに通し番号を検証し、検証で異常がある場合には防御モードに移行する。
各保護通信メンバECU3には、下記に示すように、メモリ上に保護通信に必要なバッファ領域がそれぞれ確保されている。保護通信メンバECU3は、図2(a)に示すように、最新ワーク鍵IDを管理するための最新ワーク鍵IDバッファIBを有しており、初期値は−1である。最新ワーク鍵IDバッファIBは、0,1,−1のうちのいずれかの値が格納され、値が−1の場合には「無効」を意味する。また、保護通信メンバECU3は、図2(a)に示すように、ワーク鍵ID=0の場合のワーク鍵を管理するためのワーク鍵0バッファKB0とワーク鍵ID=1の場合のワーク鍵を管理するためのワーク鍵1バッファKB1を有しており、各バッファKB0,KB1の初期値は0である。
また、保護通信メンバECU3は、図2(b)に示すように、保護メッセージ送信する場合の各メッセージIDの通し番号を管理するために受信メッセージID毎に通し番号バッファTNB1,TNB2,TNB3,・・・,TNBnを有しており、初期値は0である。ECU3毎に送信するメッセージIDは決まっており、ECU3毎に送信メッセージIDの個数nは変わる。また、保護通信メンバECU3は、図2(c)に示すように、保護メッセージを受信した場合の最新のワーク鍵IDを管理するために受信メッセージID毎に最新ワーク鍵IDバッファRIB1,RIB2,RIB3,・・・,RIBnを有しており、初期値は−1である。また、保護通信メンバECU3は、図2(c)に示すように、保護メッセージを受信した場合の最新の通し番号を管理するために受信メッセージID毎に最新通し番号バッファRNB1,RNB2,RNB3,・・・,RNBnを有しており、初期値は0である。ECU3毎に受信するメッセージIDは決まっており、ECU3毎に受信メッセージIDの個数nは変わる。
ワーク鍵シードメッセージ受信時について具体的に説明する。ワーク鍵シードメッセージを受信すると、保護通信メンバECU3では、ワーク鍵シードメッセージの標準フォーマットのデータ領域からワーク鍵シードを取り出し、そのワーク鍵シードを用いてワーク鍵を生成する。ワーク鍵の生成方法としては、例えば、ワーク鍵ID=0の場合にはワーク鍵シードSeed0を用いて式(1)によりワーク鍵KW0を計算し、ワーク鍵ID=1の場合にはワーク鍵シードSeed1を用いて式(2)によりワーク鍵KW1を計算する。式(1)、(2)のEKsはシステム鍵Ksを鍵としたDES[Data Encryption Standard]などの64ビット長ブロック暗号演算である。
KW0=EKs(Seed0)・・・(1)
KW1=EKs(Seed1)・・・(2)
KW0=EKs(Seed0)・・・(1)
KW1=EKs(Seed1)・・・(2)
そして、保護通信メンバECU3では、標準フォーマットの識別子領域(ID28〜ID18)に格納されるメッセージIDが0x10(ワーク鍵IDが0)の場合にはワーク鍵0バッファKB0にワーク鍵を保存し、メッセージIDが0x11(ワーク鍵IDが1)の場合にはワーク鍵1バッファKB1にワーク鍵を保存する。また、保護通信メンバECU3では、ワーク鍵IDが更新される毎にそのワーク鍵IDを最新ワーク鍵IDバッファIBに保存する。また、保護通信メンバECU3では、ワーク鍵が更新される毎(新しいワーク鍵シードを受信する毎)に、送信メッセージID毎の通し番号バッファTNB1,・・・,TNBnを全て0でクリアする。また、保護通信メンバECU3では、受信メッセージID毎の最新ワーク鍵IDバッファRIB1,・・・,RIBnに格納されるワーク鍵IDと標準フォーマットの識別子領域(ID28〜ID18)に格納されるメッセージIDのワーク鍵IDとが等しい場合(同じワーク鍵IDのワーク鍵が更新された場合(新しいワーク鍵シードを受信した場合))、受信メッセージID毎の最新ワーク鍵IDバッファRIB1,・・・,RIBnを全て−1でクリアするとともに受信メッセージID毎の通し番号バッファRNB1,・・・,RNBnを全て0でクリアする。なお、ワーク鍵シードメッセージのCRCは、受信時にCANのハードウェアで検証されるものとする。
メッセージ送信時について具体的に説明する。送信側の保護通信メンバECU3Aでは、標準フォーマットのメッセージIDで送信する各種送信情報を収集し、収集できた送信情報からメッセージIDを取得する。CAN通信システム1では、メッセージID毎に、データ領域に格納される送信情報が予め決められている。保護通信メンバECU3Aでは、メッセージIDに基づいて保護対象メッセージか否かを判定する。CAN通信システム1では、メッセージID毎に、保護通信の対象か否か予め決められている。
メッセージIDが保護対象メッセージの場合、保護通信メンバECU3Aでは、送信するメッセージIDに対応する通し番号バッファTNBiに保存されている通し番号(前回送信時の通し番号)に1を加算し、その加算後の通し番号(今回送信時の通し番号)を通し番号バッファTNBiに保存する。保護通信メンバECU3Aでは、送信するメッセージID、最新のワーク鍵ID(最新ワーク鍵IDバッファIBに格納されているワーク鍵ID)、今回送信時の通し番号及び収集された送信情報からなるデータ本体からMACを計算し、その計算したMACの下位13ビットを平文MACとする。MACの計算としては、例えば、システム鍵Ksを用いてOMAC[One-Key CBC MAC]方式で計算する。保護通信メンバECU3Aでは、最新のワーク鍵(最新のワーク鍵IDが0の場合にはワーク鍵0バッファKB0に保存されているワーク鍵、最新のワーク鍵IDが1の場合にはワーク鍵1バッファKB1に保存されているワーク鍵)、送信するメッセージID、最新のワーク鍵ID及び今回送信時の通し番号を用いて、ストリーム暗号の鍵ストリームを生成し、データ本体と平文MACを鍵ストリームを用いてストリーム暗号化する。ストリーム暗号としては、例えば、ブロック暗号のOFB[Output Feed Back]モードにより、メッセージIDとワーク鍵IDと通し番号を用いて初期ベクトルを生成し、初期ベクトルと鍵(ワーク鍵)を用いて鍵ストリームを生成し、鍵ストリームと平文を結合して暗号文を生成する。
保護通信メンバECU3Aでは、図3に示すように、拡張フォーマットの識別子ベース領域(ID28〜ID18)に送信するメッセージID(標準フォーマット互換の11ビットのメッセージID)を格納し、拡張フォーマットの識別子拡張領域のID17に最新のワーク鍵IDを格納し、識別子拡張領域のID16〜ID13に今回送信時の通し番号を格納し、識別子拡張領域のID12〜ID0に暗号化したMACを格納し、拡張フォーマットのデータ領域に暗号化したデータ本体を格納する。そして、保護通信メンバECU3Aでは、拡張フォーマットでメッセージ(保護メッセージ)をCANバス4上に送信する。このように、拡張フォーマットに格納することにより、保護メッセージは、CAN2.0の通常の拡張フォーマットと同等の形式をとる。したがって、CANのハードウェアでは、CAN2.0の拡張フォーマットとして処理する。なお、送信メッセージのCRCは、送信時にCANのハードウェアによって付与されるものとする。
メッセージ受信時について具体的に説明する。メッセージを受信すると、受信側の保護通信メンバECU3Bでは、識別子領域のID28〜ID18に格納されるメッセージIDに基づいて受信対象メッセージか否かを判定し、受信対象メッセージの場合には標準フォーマットか否かを判定する。
拡張フォーマットの場合、保護通信メンバECU3Bでは、受信したメッセージIDに対応する最新ワーク鍵IDバッファRIBiから最新のワーク鍵IDを取得するとともに、受信したメッセージIDに対応する最新通し番号バッファRNBiから通し番号(前回受信時の通し番号)を取得する。保護通信メンバECU3Bでは、拡張フォーマットの識別子拡張領域のID17に格納されるワーク鍵IDが最新のワーク鍵ID(同じメッセージIDのメッセージを前回受信したときのワーク鍵ID)と一致する場合、拡張フォーマットの識別子拡張領域のID16〜ID13に格納される通し番号が最新の通し番号(同じメッセージIDのメッセージを前回受信したときの通し番号)より大きい番号か否かを判定する。ワーク鍵IDが前回受信時と同じで通し番号が前回受信時の通し番号以下の場合(同じメッセージIDのメッセージを前回受信したときとワーク鍵IDが同じで通し番号が前回受信時から減っているかあるいは同じ場合)、保護通信メンバECU3Bでは、受信したメッセージを不正メッセージ(攻撃メッセージ)と判断し、そのメッセージを破棄し、防御モードに移行する。
ワーク鍵IDが前回受信時と同じで通し番号が前回受信時の通し番号より大きい場合あるいはワーク鍵IDが前回受信時と異なる場合、保護通信メンバECU3Bでは、受信したメッセージIDに対応する最新ワーク鍵IDバッファRIBiに今回のワーク鍵IDを保存するとともに、メッセージIDに対応する最新通し番号バッファRNBiに今回の通し番号を保存する。
保護通信メンバECU3Bでは、最新のワーク鍵(最新のワーク鍵IDが0の場合にはワーク鍵0バッファKB0に保存されているワーク鍵、最新のワーク鍵IDが1の場合にはワーク鍵1バッファKB1に保存されているワーク鍵)、今回受信したメッセージID、今回受信したワーク鍵ID及び今回受信した通し番号を用いて、ストリーム暗号の鍵ストリームを生成し、拡張フォーマットのデータ領域に格納される暗号化データ本体と拡張フォーマットの識別子拡張領域のID12〜ID0に格納される暗号化MACを鍵ストリームを用いて復号化する。そして、保護通信メンバECU3Bでは、今回受信したメッセージID、今回受信したワーク鍵ID、今回受信した通し番号及び復号化したデータ本体からMACを計算し、その計算したMACの下位13ビットと復号化した平文MACとを比較する。保護通信メンバECU3Bでは、比較したMACが一致しない場合、受信したメッセージを不正メッセージと判断し、そのメッセージを破棄し、防御モードに移行する。また、保護通信メンバECU3Bでは、比較したMACが一致する場合、上位層のアプリケーションソフトにおいて11ビットのメッセージID(すなわち、標準フォーマットのデータ形式)で受信処理を行う。なお、メッセージのCRCは、受信時にCANのハードウェアによって検証されているものとする。
図1〜図3を参照して、CAN通信システム1における保護通信の処理の流れを説明する。ここでは、保護通信マスタECU2におけるワーク鍵シードメッセージ送信処理について図4のフローチャートに沿って説明し、保護通信メンバECU3におけるワーク鍵シードメッセージ受信処理について図5のフローチャートに沿って説明し、送信側の保護通信メンバECU3Aにおけるメッセージ送信処理については図6のフローチャートに沿って説明し、受信側の保護通信メンバECU3Bにおけるメッセージ受信処理については図7のフローチャートに沿って説明する。
保護通信マスタECU2では、最初に、メッセージIDとして0x10(ワーク鍵ID=0)を設定する(S10)。ワーク鍵シードメッセージの送信タイミング毎に、保護通信マスタECU2では、ワーク鍵シード(64ビット長乱数)を生成する(S11)。保護通信マスタECU2では、標準フォーマットの識別子領域にメッセージIDを格納し、データ領域にワーク鍵シードを格納し、ワーク鍵シードメッセージを生成する(S12)。そして、保護通信マスタECU2では、ワーク鍵シードメッセージを送信する(S13)。
ワーク鍵シードメッセージ送信後、保護通信マスタECU2では、次の送信タイミングまで一定時間待つ(S14)。一定時間後、保護通信マスタECU2では、ワーク鍵シードメッセージの最新のメッセージIDが0x10か否かを判定する(S15)。保護通信マスタECU2では、S15にてメッセージIDが0x10と判定した場合にはメッセージIDとして0x11(ワーク鍵ID=1)を設定し(S16)、S15にてメッセージIDが0x11と判定した場合にはメッセージIDとして0x10(ワーク鍵ID=0)を設定する(S17)。そして、保護通信マスタECU2では、上記したように、ワーク鍵シードを生成し(S11)、そのワーク鍵シードにメッセージIDを付加してワーク鍵シードメッセージを生成し(S12)、ワーク鍵シードメッセージを送信する(S13)。
このように、保護通信マスタECU2では、周期的に、ワーク鍵シードを更新し、ワーク鍵シードを更新する毎にメッセージID(ワーク鍵ID)を切り替えて、ワーク鍵シードメッセージを保護通信メンバECU3に送信する。
ワーク鍵シードメッセージを受信する毎に(S20)、全ての保護通信メンバECU3では、ワーク鍵シードメッセージの標準フォーマットの識別子領域に格納されるメッセージIDが0x10か否かを判定する(S21)。保護通信メンバECU3では、S21にてメッセージIDが0x10と判定した場合にはワーク鍵IDを0とし(S22)、S21にてメッセージIDが0x11と判定した場合にはワーク鍵IDを1とする(S23)。
保護通信メンバECU3では、ワーク鍵シードメッセージの標準フォーマットのデータ領域からワーク鍵シードを取得し(S24)、そのワーク鍵シードを用いてワーク鍵を生成する(S25)。保護通信メンバECU3では、S22又はS23で取得したワーク鍵IDに対応するワーク鍵バッファKBjに生成したワーク鍵を保存する(S26)。
保護通信メンバECU3では、全ての送信メッセージIDに対応する通し番号バッファTNB1,・・・,TNBnの通し番号を0でクリアする(S27)。また、保護通信メンバECU3では、全ての受信メッセージに対応する最新ワーク鍵IDバッファRTB1,・・・,RTBnに保存されているワーク鍵IDがS22又はS23で取得したワーク鍵IDと等しい場合、全ての受信メッセージに対応する最新ワーク鍵IDバッファRTB1,・・・,RTBnのワーク鍵IDを−1でクリアし、全ての受信メッセージに対応する最新通し番号バッファRNB1,・・・,RNBnの通し番号を0でクリアする(S28)。最後に、保護通信メンバECU3では、最新ワーク鍵IDバッファIBにS22又はS23で取得したワーク鍵IDを保存する(S29)。
このように、全ての保護通信メンバECU3では、周期的に、ワーク鍵シードメッセージを受信し、ワーク鍵シードからワーク鍵を更新するとともにワーク鍵IDも切り替えられる。
送信側の保護通信メンバECU3Aでは、標準フォーマットのメッセージIDで送信する各種送信情報を収集する(S40)。そして、保護通信メンバECU3Aでは、収集できた送信情報からメッセージIDを取得する(S41)。保護通信メンバECU3Aでは、そのメッセージIDに基づいて保護対象メッセージか否かを判定する(S42)。S42にて保護対象メッセージでないと判定した場合、保護通信メンバECU3Aでは、標準フォーマットの識別子領域にメッセージIDを格納し、標準フォーマットのデータ領域に収集した送信情報のデータを格納し、標準フォーマットでメッセージを送信する(S43)。
S42にて保護対象メッセージと判定した場合、保護通信メンバECU3Aでは、最新ワーク鍵IDバッファIBから最新のワーク鍵IDを取得する(S44)。また、保護通信メンバECU3Aでは、送信するメッセージIDに対応する通し番号バッファTNBiから通し番号を取得し、その取得した通し番号に1を加算し、その加算後の通し番号を通し番号バッファTNBiに保存する(S45)。
保護通信メンバECU3Aでは、送信するメッセージIDと最新のワーク鍵IDと加算後の通し番号と収集できた送信情報によるデータ領域のデータからMACを生成し、生成したMACの下位13ビットを平文MACとする(S46)。また、保護通信メンバECU3Aでは、最新のワーク鍵IDに対応するワーク鍵バッファKBjからワーク鍵を取得し、そのワーク鍵と送信するメッセージIDと最新のワーク鍵IDと加算後の通し番号からストリーム暗号の鍵ストリームを生成する(S47)。そして、保護通信メンバECU3Aでは、収集した送信情報によるデータ領域のデータと平文MACを鍵ストリームを用いてそれぞれ暗号化する(S48)。
保護通信メンバECU3Aでは、拡張フォーマットのデータ領域に暗号化したデータを入れ、拡張フォーマットの識別子ベース領域(ID28〜ID18)にメッセージIDを入れ、拡張フォーマットの識別子拡張領域(ID17〜ID0)に最新のワーク鍵IDと加算後の通し場号と暗号化したMACを入れ、拡張フォーマットでメッセージを送信する(S49)。
このように、メッセージを送信する場合、保護通信メンバECU3Aでは、そのメッセージが保護対象の場合には、通し番号とデータ本体を含むMACを生成し、そのMACの一部とデータ本体をワーク鍵を用いたストリーム暗号で暗号化し、拡張フォーマットの識別子拡張領域を利用してワーク鍵ID、通し番号、暗号化MAC(セキュリティに関するデータ)を入れて、拡張フォーマットでメッセージを送信する。この際、保護通信メンバECU3AのCANのハードウェアでは、拡張フォーマットとして送信処理を行う。また、保護通信メンバECU3Aの上位層のアプリケーションソフトウェアからは、メッセージIDが標準フォーマットと同じく11ビットとなる。
受信側の保護通信メンバECU3Bでは、メッセージを受信する毎に(S60)、ID28〜ID18に格納されているメッセージIDに基づいて受信対象のメッセージか否かを判定する(S61)。S61にて受信対象のメッセージでないと判定した場合、保護通信メンバECU3Bでは、処理を終了する。
S61にて受信対象のメッセージと判定した場合、保護通信メンバECU3Bでは、メッセージが標準フォーマットか否かを判定する(S62)。S62にて標準フォーマットと判定した場合、保護通信メンバECU3Bでは、上位層のアプリケーションソフトウェアが標準フォーマットの通常の受信処理を行う(S63)。
S62にて拡張フォーマットと判定した場合、保護通信メンバECU3Bでは、拡張フォーマットの識別子ベース領域(ID28〜ID18)の受信メッセージIDに対応する最新ワーク鍵IDバッファRIBiと最新通し番号バッファRNBiからワーク鍵IDと通し番号の組を取得する(S64)。そして、保護通信メンバECU3Bでは、拡張フォーマットの識別子拡張領域のID17のデータと取得したワーク鍵IDとが一致するか否かを判定する(S65)。S65にて一致すると判定した場合、保護通信メンバECU3Bでは、拡張フォーマットの識別子拡張領域のID16〜ID13のデータが取得した通し番号より大きいか否かを判定する(S66)。S66にてID16〜ID13のデータが取得した通し番号以下と判定した場合、保護通信メンバECU3Bでは、受信したメッセージを廃棄し、防御モードに移行する(S73)。
S65にて一致しないと判定した場合又はS66にてID16〜ID13のデータが取得した通し番号より大きいと判定した場合、保護通信メンバECU3Bでは、受信メッセージIDに対応する最新ワーク鍵IDバッファRIBiに拡張フォーマットの識別子拡張領域のID17のデータ(今回受信したワーク鍵ID)を保存し、最新通し番号バッファRNBiに拡張フォーマットの識別子拡張領域のID16〜ID13のデータ(今回受信した通し番号)を保存する(S67)。
保護通信メンバECU3Bでは、ワーク鍵IDに対応するワーク鍵バッファKBjからワーク鍵を取得し、そのワーク鍵と受信したメッセージIDと受信したワーク鍵IDと受信した通し番号からストリーム暗号の鍵ストリームを生成する(S68)。そして、保護通信メンバECU3Bでは、受信メッセージの拡張フォーマットのデータ領域の暗号化データと拡張フォーマットの識別子拡張領域のID12〜ID0の暗号化MACを鍵ストリームを用いてそれぞれ復号化する(S69)。さらに、保護通信メンバECU3Bでは、受信したメッセージIDと受信したワーク鍵IDと受信した通し番号と復号化したデータからMACを生成し、生成したMACの下位13ビットと復号化した平文MACとを比較する(S70)。そして、保護通信メンバECU3Bでは、S70で比較した結果、MACが等しいか否かを判定する(S71)。
S71にてMACが等しいと判定した場合、保護通信メンバECU3Bでは、上位層のアプリケーションソフトウェアが11ビットのメッセージIDとして標準フォーマットのデータ形式で受信処理を行う(S72)。一方、S71にてMACが等しくないと判定した場合、保護通信メンバECU3Bでは、受信したメッセージを廃棄し、防御モードに移行する(S73)。
このように、拡張フォーマットでメッセージを受信した場合、保護通信メンバECU3Bでは、通し番号とMACによる検証で不正メッセージか否かを判定し、不正メッセージと判定した場合には防御モードに移行する。この際、保護通信メンバECU3BのCANのハードウェアでは、拡張フォーマットとして受信処理を行う。また、保護通信メンバECU3Bの上位層のアプリケーションソフトウェアでは、標準フォーマットと同等の11ビットのメッセージIDとして受信処理を行う。
このCAN通信システム1によれば、MACとデータ本体を暗号化し、この暗号化したMACとデータ本体を拡張フォーマットを利用して送信することにより、CANにおけるフォーマットの互換性を確保しつつセキュリティ性を向上させることができる。また、CAN通信システム1によれば、メッセージID毎の通し番号とMACによってメッセージを検証することにより、再送攻撃等の不正メッセージを高精度に検出でき、メッセージの安全性を向上でき、セキュリティ性がより向上する。また、CAN通信システム1によれば、各ECU2,3におけるソフトウェアによる処理だけで簡易に保護通信を行うことができる。
特に、CAN通信システム1によれば、CANのハードウェアが拡張フォーマットとして処理できるとともに、各保護通信メンバECU3の上位層のアプリケーションソフトウェアが拡張フォーマットの識別子ベース領域に格納される標準フォーマット互換のメッセージID(11ビット)を用いて標準フォーマットと同等に受信処理できる。さらに、CAN通信システム1によれば、MACを暗号化しているので、少ないデータ量でもメッセージの安全性を確保できる。したがって、拡張フォーマットの識張子拡張領域内に暗号化MACや通し番号を格納する領域を確保でき、拡張フォーマットのデータ領域にMAC等を格納しなくてよいので、拡張フォーマットのデータ領域には通常と同様にデータを格納でき、データ領域の互換性も確保できる。また、CAN通信システム1によれば、データ本体を暗号化しているので、データ本体の安全性も向上できる。
さらに、CAN通信システム1によれば、保護通信マスタECU2から周期的に更新したワーク鍵シードを送信することにより、保護通信メンバECU3で周期的にワーク鍵を更新でき、ワーク鍵の安全性を確保できる。また、CAN通信システム1によれば、ワーク鍵シードを更新する毎にワーク鍵IDを0と1で切り替えることにより、メッセージの送信側と受信側とでワーク鍵の更新の同期をとることができる。
以上、本発明に係る実施の形態について説明したが、本発明は上記実施の形態に限定されることなく様々な形態で実施される。
例えば、本実施の形態では車両に搭載されるCAN通信システムに適用したが、車両以外のCANにも適用可能である。また、本実施の形態ではソフトウェアで保護通信のための各処理を行う構成としたが、処理の一部(例えば、暗号化処理)をCANのハードウェアで行ってもよい。
また、本実施の形態ではワーク鍵を更新する際に送信側と受信側で同期をとるために、ワーク鍵IDを導入し、ワーク鍵IDを0と1で切り替える手法を適用したが、他の手法を用いてもよい。また、本実施の形態ではMACと通し番号を用いてメッセージを検証したが、MACによる検証だけでもよい。この場合、拡張フォーマットの識別子拡張領域には少なくとも暗号化MACを格納すればよい。
また、本実施の形態ではメッセージID、ワーク鍵ID、通し番号、データ本体からMACを生成したが、この組み合わせ以外でMACを生成してもよい。また、本実施の形態ではワーク鍵、メッセージID、ワーク鍵ID、通し番号から鍵ストリームを生成したが、この組み合わせ以外で鍵ストリームを生成してもよい。また、本実施の形態ではストリーム暗号を適用したが、他の暗号方法を適用してもよい。
また、本実施の形態では保護通信マスタECUでワーク鍵シードを更新する毎にワーク鍵シードメッセージを一度だけ保護通信メンバECUに送信する構成としたが、保護通信メンバECUでワーク鍵シードメッセージを確実に受信するために、保護通信マスタECUから同じワーク鍵シードメッセージを複数回送信するようにしてもよい。
1…CAN通信システム、2…保護通信マスタECU、3,3A,3B…保護通信メンバECU、4…CANバス、5…OBD−IIポート。
Claims (2)
- CAN通信プロトコルに基づいて送受信されるデータを保護するための保護通信方法であって、
メッセージ認証コードを生成する生成ステップと、
前記生成ステップで生成したメッセージ認証コードと送信データを暗号化する暗号化ステップと、
前記暗号化ステップで暗号化したメッセージ認証コードをCAN通信プロトコルの拡張フォーマットの識別子拡張領域に格納し、前記暗号化ステップで暗号化した送信データを拡張フォーマットのデータ領域に格納する格納ステップと、
前記格納ステップで格納した拡張フォーマットでメッセージを送信する送信ステップと、
を含むこと特徴とする保護通信方法。 - 前記格納ステップでは、ワーク鍵ID、メッセージの通し番号をCAN通信プロトコルの拡張フォーマットの識別子拡張領域に格納し、
前記送信ステップで送信された拡張フォーマットのメッセージを受信したノードにおいて、前記通し番号の検証又は前記メッセージ認証コードの検証で異常を検出した場合、防御モードに移行することを特徴とする請求項1に記載の保護通信方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2011186243A JP2013048374A (ja) | 2011-08-29 | 2011-08-29 | 保護通信方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2011186243A JP2013048374A (ja) | 2011-08-29 | 2011-08-29 | 保護通信方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2013048374A true JP2013048374A (ja) | 2013-03-07 |
Family
ID=48011129
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2011186243A Withdrawn JP2013048374A (ja) | 2011-08-29 | 2011-08-29 | 保護通信方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2013048374A (ja) |
Cited By (34)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2015095841A (ja) * | 2013-11-13 | 2015-05-18 | 株式会社メガチップス | 情報処理システム |
JP5802892B1 (ja) * | 2014-11-12 | 2015-11-04 | オプテックス株式会社 | 通信パケットのメッセージ認証コードの生成方法および認証方法 |
WO2015170457A1 (ja) * | 2014-05-08 | 2015-11-12 | パナソニックIpマネジメント株式会社 | 送信装置、受信装置、送信方法、及び受信方法 |
JP2015233343A (ja) * | 2015-09-17 | 2015-12-24 | パナソニックIpマネジメント株式会社 | 送信装置、受信装置、送信方法、及び受信方法 |
WO2016076358A1 (ja) * | 2014-11-13 | 2016-05-19 | 日立オートモティブシステムズ株式会社 | 情報処理装置、メッセージ認証方法 |
JP2016100632A (ja) * | 2014-11-18 | 2016-05-30 | 株式会社東芝 | 通信システム及び通信装置 |
JP2016129339A (ja) * | 2016-01-19 | 2016-07-14 | パナソニックIpマネジメント株式会社 | 受信装置、及び受信方法 |
JP2016134834A (ja) * | 2015-01-21 | 2016-07-25 | トヨタ自動車株式会社 | 車載ゲートウェイ装置及び車載ネットワークシステム |
JP2016139883A (ja) * | 2015-01-27 | 2016-08-04 | ルネサスエレクトロニクス株式会社 | 中継装置、端末装置および通信方法 |
WO2017010172A1 (ja) * | 2015-07-15 | 2017-01-19 | 日立オートモティブシステムズ株式会社 | ゲートウェイ装置およびその制御方法 |
JP2017038365A (ja) * | 2015-08-07 | 2017-02-16 | 株式会社デンソー | 通信システム、管理ノード、通常ノード、カウンタ同期方法、プログラム、記録媒体 |
WO2017026361A1 (ja) * | 2015-08-07 | 2017-02-16 | 株式会社デンソー | 通信システム、管理ノード、通常ノード、カウンタ同期方法、プログラム、記録媒体 |
CN106458112A (zh) * | 2014-11-12 | 2017-02-22 | 松下电器(美国)知识产权公司 | 更新管理方法、更新管理装置以及控制程序 |
JP2017060031A (ja) * | 2015-09-17 | 2017-03-23 | Kddi株式会社 | 車載制御システム、車両、管理装置、車載コンピュータ、データ共有方法、及びコンピュータプログラム |
JP2017092634A (ja) * | 2015-11-06 | 2017-05-25 | 日立オートモティブシステムズ株式会社 | 情報処理装置および不正メッセージ検知方法 |
JP2017091280A (ja) * | 2015-11-12 | 2017-05-25 | 富士通株式会社 | 監視方法および監視システム |
WO2017109584A3 (en) * | 2015-09-18 | 2017-09-28 | Trillium Incorporated | Computer-implemented cryptographic method for improving a computer network, and terminal, system and computer-readable medium for the same |
CN107395339A (zh) * | 2016-05-17 | 2017-11-24 | 罗伯特·博世有限公司 | 用于在网络中生成秘密或密钥的方法 |
JP2017225186A (ja) * | 2017-08-30 | 2017-12-21 | Kddi株式会社 | 車載制御システム、車両、管理装置、車載コンピュータ、データ共有方法、及びコンピュータプログラム |
US9866570B2 (en) | 2014-12-15 | 2018-01-09 | Toyota Jidosha Kabushiki Kaisha | On-vehicle communication system |
WO2018070601A1 (ko) * | 2016-10-10 | 2018-04-19 | 주식회사 페스카로 | Can 통신 기반 해킹공격에 안전한 can 컨트롤러 |
JP2018074435A (ja) * | 2016-10-31 | 2018-05-10 | トヨタ自動車株式会社 | 通信システム及び通信方法 |
JP2018078474A (ja) * | 2016-11-10 | 2018-05-17 | トヨタ自動車株式会社 | 通信システム |
JP2018078473A (ja) * | 2016-11-10 | 2018-05-17 | トヨタ自動車株式会社 | 通信システム |
US10050983B2 (en) | 2015-11-13 | 2018-08-14 | Kabushiki Kaisha Toshiba | Communication system, receiving apparatus, receiving method, and computer program product |
JP2020123960A (ja) * | 2020-03-26 | 2020-08-13 | トヨタ自動車株式会社 | 通信システム |
JP2020123961A (ja) * | 2016-11-10 | 2020-08-13 | トヨタ自動車株式会社 | 通信システム |
WO2020209201A1 (ja) * | 2019-04-12 | 2020-10-15 | 株式会社東海理化電機製作所 | 通信システム及び制御装置 |
JP2020174347A (ja) * | 2019-04-12 | 2020-10-22 | 株式会社東海理化電機製作所 | 通信システム及び制御装置 |
JP2021106401A (ja) * | 2016-09-23 | 2021-07-26 | アップル インコーポレイテッドApple Inc. | ネットワークトラフィックのセキュア通信 |
US20210306177A1 (en) * | 2018-08-07 | 2021-09-30 | Kvaser Ab | Adaptable and Secure Can Bus |
KR20220065680A (ko) * | 2020-11-13 | 2022-05-20 | 도요타지도샤가부시키가이샤 | 차량 통신 시스템, 통신 방법 및 통신 프로그램을 기록한 기록 매체 |
US11814069B2 (en) | 2020-03-25 | 2023-11-14 | Toyota Jidosha Kabushiki Kaisha | Vehicle control system, data transmitting method, and recording medium on which program is recorded |
US12143489B2 (en) | 2019-04-12 | 2024-11-12 | Kabushiki Kaisha Tokai Rika Denki Seisakusho | Communication system and control device |
-
2011
- 2011-08-29 JP JP2011186243A patent/JP2013048374A/ja not_active Withdrawn
Cited By (62)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2015095841A (ja) * | 2013-11-13 | 2015-05-18 | 株式会社メガチップス | 情報処理システム |
WO2015170457A1 (ja) * | 2014-05-08 | 2015-11-12 | パナソニックIpマネジメント株式会社 | 送信装置、受信装置、送信方法、及び受信方法 |
JP2015216469A (ja) * | 2014-05-08 | 2015-12-03 | パナソニックIpマネジメント株式会社 | 送信装置 |
EP3142290A4 (en) * | 2014-05-08 | 2017-08-23 | Panasonic Intellectual Property Management Co., Ltd. | Transmission device, reception device, transmission method, and reception method |
JP5802892B1 (ja) * | 2014-11-12 | 2015-11-04 | オプテックス株式会社 | 通信パケットのメッセージ認証コードの生成方法および認証方法 |
US10637657B2 (en) * | 2014-11-12 | 2020-04-28 | Panasonic Intellectual Property Corporation Of America | Update management method, update management system, and non-transitory recording medium |
US20170134164A1 (en) * | 2014-11-12 | 2017-05-11 | Panasonic Intellectual Property Corporation Of America | Update management method, update management system, and non-transitory recording medium |
JP2016096375A (ja) * | 2014-11-12 | 2016-05-26 | オプテックス株式会社 | 通信パケットのメッセージ認証コードの生成方法および認証方法 |
CN106458112A (zh) * | 2014-11-12 | 2017-02-22 | 松下电器(美国)知识产权公司 | 更新管理方法、更新管理装置以及控制程序 |
US11283601B2 (en) | 2014-11-12 | 2022-03-22 | Panasonic Intellectual Property Corporation Of America | Update management method, update management system, and non-transitory recording medium |
WO2016076358A1 (ja) * | 2014-11-13 | 2016-05-19 | 日立オートモティブシステムズ株式会社 | 情報処理装置、メッセージ認証方法 |
US10425231B2 (en) | 2014-11-13 | 2019-09-24 | Hitachi Automotive Systems, Ltd. | Information processing apparatus and method for authenticating message |
JP2016096419A (ja) * | 2014-11-13 | 2016-05-26 | 日立オートモティブシステムズ株式会社 | 情報処理装置、メッセージ認証方法 |
JP2016100632A (ja) * | 2014-11-18 | 2016-05-30 | 株式会社東芝 | 通信システム及び通信装置 |
US9866570B2 (en) | 2014-12-15 | 2018-01-09 | Toyota Jidosha Kabushiki Kaisha | On-vehicle communication system |
US10104094B2 (en) | 2014-12-15 | 2018-10-16 | Toyota Jidosha Kabushiki Kaisha | On-vehicle communication system |
JP2016134834A (ja) * | 2015-01-21 | 2016-07-25 | トヨタ自動車株式会社 | 車載ゲートウェイ装置及び車載ネットワークシステム |
JP2016139883A (ja) * | 2015-01-27 | 2016-08-04 | ルネサスエレクトロニクス株式会社 | 中継装置、端末装置および通信方法 |
WO2017010172A1 (ja) * | 2015-07-15 | 2017-01-19 | 日立オートモティブシステムズ株式会社 | ゲートウェイ装置およびその制御方法 |
US10560286B2 (en) | 2015-07-15 | 2020-02-11 | Hitachi Automotive Systems, Ltd. | Gateway device and control method for the same |
WO2017026361A1 (ja) * | 2015-08-07 | 2017-02-16 | 株式会社デンソー | 通信システム、管理ノード、通常ノード、カウンタ同期方法、プログラム、記録媒体 |
US10735435B2 (en) | 2015-08-07 | 2020-08-04 | Denso Corporation | Communication system, management node, normal node, counter synchronization method, and storage medium |
JP2019165473A (ja) * | 2015-08-07 | 2019-09-26 | 株式会社デンソー | 通信システム、管理ノード、通常ノード、カウンタ同期方法、カウント値配信方法、カウント値初期化方法、プログラム、記録媒体 |
JP2017038365A (ja) * | 2015-08-07 | 2017-02-16 | 株式会社デンソー | 通信システム、管理ノード、通常ノード、カウンタ同期方法、プログラム、記録媒体 |
JP2017060031A (ja) * | 2015-09-17 | 2017-03-23 | Kddi株式会社 | 車載制御システム、車両、管理装置、車載コンピュータ、データ共有方法、及びコンピュータプログラム |
JP2015233343A (ja) * | 2015-09-17 | 2015-12-24 | パナソニックIpマネジメント株式会社 | 送信装置、受信装置、送信方法、及び受信方法 |
WO2017109584A3 (en) * | 2015-09-18 | 2017-09-28 | Trillium Incorporated | Computer-implemented cryptographic method for improving a computer network, and terminal, system and computer-readable medium for the same |
KR101972724B1 (ko) | 2015-09-18 | 2019-04-25 | 트릴리움 인코퍼레이티드 | 컴퓨터 네트워크를 개선하기 위한 컴퓨터로-구현되는 암호화 방법, 및 단말, 시스템 및 이를 위한 컴퓨터-판독 가능한 매체 |
JP2018527856A (ja) * | 2015-09-18 | 2018-09-20 | Trillium株式会社 | コンピュータネットワークを改善するためのコンピュータで実現される暗号化方法、及び端末、システム及びそれらのためのコンピュータ可読媒体 |
KR20180066048A (ko) * | 2015-09-18 | 2018-06-18 | 트릴리움 인코퍼레이티드 | 컴퓨터 네트워크를 개선하기 위한 컴퓨터로-구현되는 암호화 방법, 및 단말, 시스템 및 이를 위한 컴퓨터-판독 가능한 매체 |
CN108352991A (zh) * | 2015-11-06 | 2018-07-31 | 日立汽车系统株式会社 | 信息处理装置以及不正当消息检测方法 |
JP2017092634A (ja) * | 2015-11-06 | 2017-05-25 | 日立オートモティブシステムズ株式会社 | 情報処理装置および不正メッセージ検知方法 |
US10726161B2 (en) | 2015-11-06 | 2020-07-28 | Hitachi Automotive Systems, Ltd. | Information processing device and malicious message detection method |
JP2017091280A (ja) * | 2015-11-12 | 2017-05-25 | 富士通株式会社 | 監視方法および監視システム |
US10050983B2 (en) | 2015-11-13 | 2018-08-14 | Kabushiki Kaisha Toshiba | Communication system, receiving apparatus, receiving method, and computer program product |
JP2016129339A (ja) * | 2016-01-19 | 2016-07-14 | パナソニックIpマネジメント株式会社 | 受信装置、及び受信方法 |
CN107395339A (zh) * | 2016-05-17 | 2017-11-24 | 罗伯特·博世有限公司 | 用于在网络中生成秘密或密钥的方法 |
JP2021106401A (ja) * | 2016-09-23 | 2021-07-26 | アップル インコーポレイテッドApple Inc. | ネットワークトラフィックのセキュア通信 |
US11595366B2 (en) | 2016-09-23 | 2023-02-28 | Apple Inc. | Secure communication of network traffic |
JP7274518B2 (ja) | 2016-09-23 | 2023-05-16 | アップル インコーポレイテッド | ネットワークトラフィックのセキュア通信 |
WO2018070601A1 (ko) * | 2016-10-10 | 2018-04-19 | 주식회사 페스카로 | Can 통신 기반 해킹공격에 안전한 can 컨트롤러 |
US10764326B2 (en) | 2016-10-10 | 2020-09-01 | Fescaro Co., Ltd. | Can controller safe against can-communication-based hacking attack |
JP2018074435A (ja) * | 2016-10-31 | 2018-05-10 | トヨタ自動車株式会社 | 通信システム及び通信方法 |
JP2020123961A (ja) * | 2016-11-10 | 2020-08-13 | トヨタ自動車株式会社 | 通信システム |
JP2018078474A (ja) * | 2016-11-10 | 2018-05-17 | トヨタ自動車株式会社 | 通信システム |
JP2018078473A (ja) * | 2016-11-10 | 2018-05-17 | トヨタ自動車株式会社 | 通信システム |
JP2017225186A (ja) * | 2017-08-30 | 2017-12-21 | Kddi株式会社 | 車載制御システム、車両、管理装置、車載コンピュータ、データ共有方法、及びコンピュータプログラム |
US20210306177A1 (en) * | 2018-08-07 | 2021-09-30 | Kvaser Ab | Adaptable and Secure Can Bus |
EP3834377A4 (en) * | 2018-08-07 | 2022-04-06 | Kvaser AB | CUSTOMIZABLE AND SECURE CAN-BUS |
JP2020174347A (ja) * | 2019-04-12 | 2020-10-22 | 株式会社東海理化電機製作所 | 通信システム及び制御装置 |
CN113545005A (zh) * | 2019-04-12 | 2021-10-22 | 株式会社东海理化电机制作所 | 通信系统以及控制装置 |
WO2020209201A1 (ja) * | 2019-04-12 | 2020-10-15 | 株式会社東海理化電機製作所 | 通信システム及び制御装置 |
JP7366819B2 (ja) | 2019-04-12 | 2023-10-23 | 株式会社東海理化電機製作所 | 通信システム及び制御装置 |
US11838416B2 (en) | 2019-04-12 | 2023-12-05 | Kabushiki Kaisha Tokai Rika Denki Seisakusho | Communication system and control device |
CN113545005B (zh) * | 2019-04-12 | 2024-04-05 | 株式会社东海理化电机制作所 | 通信系统以及控制装置 |
US12143489B2 (en) | 2019-04-12 | 2024-11-12 | Kabushiki Kaisha Tokai Rika Denki Seisakusho | Communication system and control device |
US11814069B2 (en) | 2020-03-25 | 2023-11-14 | Toyota Jidosha Kabushiki Kaisha | Vehicle control system, data transmitting method, and recording medium on which program is recorded |
JP2020123960A (ja) * | 2020-03-26 | 2020-08-13 | トヨタ自動車株式会社 | 通信システム |
KR20220065680A (ko) * | 2020-11-13 | 2022-05-20 | 도요타지도샤가부시키가이샤 | 차량 통신 시스템, 통신 방법 및 통신 프로그램을 기록한 기록 매체 |
JP2022078868A (ja) * | 2020-11-13 | 2022-05-25 | トヨタ自動車株式会社 | 車両通信システム、通信方法及び通信プログラム |
JP7380530B2 (ja) | 2020-11-13 | 2023-11-15 | トヨタ自動車株式会社 | 車両通信システム、通信方法及び通信プログラム |
KR102649908B1 (ko) | 2020-11-13 | 2024-03-22 | 도요타지도샤가부시키가이샤 | 차량 통신 시스템, 통신 방법 및 통신 프로그램을 기록한 기록 매체 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2013048374A (ja) | 保護通信方法 | |
EP3386163B1 (en) | Apparatuses and methods for use in a can system | |
EP3038318B1 (en) | Communication control apparatus, communication control method and communication control program | |
JP6569087B2 (ja) | 受信装置および受信方法 | |
CN110505193B (zh) | 车辆抗随机数滥用认证加密 | |
CN108023730B (zh) | 通信系统及通信方法 | |
EP3324574B1 (en) | Gateway device and control method therefor | |
CN110896387B (zh) | 数据传输方法、电池管理系统和存储介质 | |
CN111865922B (zh) | 一种通信方法、装置、设备及存储介质 | |
WO2018017566A1 (en) | Hash-chain based sender identification scheme | |
EP2938015B1 (en) | Communication system, communication unit, and communication method | |
CN105897748B (zh) | 一种对称密钥的传输方法及设备 | |
CN106941404A (zh) | 密钥保护方法及装置 | |
JP5016394B2 (ja) | 無線制御セキュリティシステム | |
US12021999B2 (en) | Devices and methods for the generating and authentication of at least one data packet to be transmitted in a bus system (BU), in particular of a motor vehicle | |
JP5503692B2 (ja) | 無線制御セキュリティシステム | |
Bittl | Attack potential and efficient security enhancement of automotive bus networks using short MACs with rapid key change | |
Shannon et al. | Blockchain based distributed key provisioning and secure communication over CAN FD | |
JP6454614B2 (ja) | 車載システム、その制御装置および制御方法 | |
CN113872969B (zh) | 基于代理重加密机制的自动驾驶车车内消息重加密方法 | |
CN111460477B (zh) | Ecu安全认证方法及装置 | |
CN107104868B (zh) | 一种车载网络加密通信方法及装置 | |
JP6615721B2 (ja) | 通信システム、受信装置、受信方法およびプログラム | |
CN117595988A (zh) | 一种车载can网络安全通信方法、装置、设备及介质 | |
CN114690744A (zh) | 一种车辆内部can总线轻量化消息验证方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A300 | Application deemed to be withdrawn because no request for examination was validly filed |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20141104 |