JP2020501420A - 通信ネットワーク用の方法及び電子監視ユニット - Google Patents

Abstract

【課題】外部からのアクセスに対して車載ネットワークをより安全に構成され得る方法及び装置を提供する。【解決手段】本発明は、車載ネットワークにおける通信のため、データが少なくとも１つの通信経路（６０）で転送される車載ネットワーク用の方法に関する。本発明は、電子監視ユニットにも関する。

Description

本発明は、請求項１の前文に記載の通信ネットワーク用の方法及び電子監視ユニットに関する。

イーサネット（登録商標）物理層及びその上のインターネットプロトコル（ＩＰ）に基づいて、情報技術システムの範囲内ですでに広く普及している技術は、自動車の通信ネットワークへの道を見出している。特にイーサネット及びインターネットプロトコルの使用の増加を考慮して、外部アクセスを防止可能とするためにさらなるセキュリティ機構が求められている。無線技術及び関連するオープンで標準化されたプロトコルの使用が増加したために、自動車分野では、したがって実質的に初めて遠隔アクセスによって自動車の通信ネットワークにアクセス可能となっている。攻撃者が無線を介して車両にアクセスする間、重要な車両機能にそれゆえ影響可能になる車両へのアクセスが、例えば知られている。他の産業分野では、例えばワークステーションコンピュータの場合、ファイアウォールが、システムに既に存在し、車両に要求されるようにオンザフライ方式ではないデータで既に動作しているので、自動車に適用できない問題及び解決策を有する。さらに、ワークステーションコンピュータのセキュリティソフトウェアは、自動車のソフトウェアよりもかなり簡単な方法で更新可能である。

従来技術による通信パケットは、通常、送信装置のプロトコルスタックの上位層のヘッダを含む。受信装置のプロトコルスタックは、この通信パケットを受信するときに徐々に進み、例えば送信されたデータを対応するソフトウェアアプリケーションに転送するために所定のフィルタによってそれを検査する。 イーサネットメッセージなどの通信パケットは、例えば制御装置内のＴＣＰ／ＩＰスタックを通過し、内容の分析に基づいて、対応するアプリケーションに転送される。

プロトコルスタックの複雑さは使用されるプロトコルの数と共にかなり増加する。例えば、オーディオ及びビデオデータを送信及び再生するためのオーディオ／ビデオブリッジング（ＡＶＢ）は４つのサブプロトコルを含み、時間依存ネットワーク（ＴＳＮ）はさらに１１のサブプロトコル及び包括的な仕様を含む。この不利な点は、使用される多数のプロトコルのために、容易に表すことができない非常に多数の分岐の可能性があって、決定論的プロトコルスタックに対する単純なトレーサビリティがないことである。したがって、プロトコルスタック内の既存のセキュリティギャップを決定することにはかなりの問題がある。問題は、例えば、イーサネットの新しいタイプが故意に又は意図せずに使用されているのか否かの判定をどう進めるか処理するかである。これは疑わしい場合に中央計算ユニットに転送され、重大なシステム状態を引き起こし、基盤システムの機能を大幅に制限するおそれがあり、道路利用者の安全を危険にするおそれがある。プロトコルスタック内のセキュリティギャップを意図的に検索するサービス拒否攻撃（ＤｏＳ）によって、これまでに発見されていなかったセキュリティギャップに関する意図的な不正アクセスが発生するおそれがあるのである。

本発明の課題は、外部からのアクセスに対して車載ネットワークがより安全に構成され得る方法及び装置を提供することである。

上記課題は、請求項１に記載の方法と、従属請求項の記載事項とによって、達成される。

本発明は、通信ネットワークにおける通信のためにデータが少なくとも１つの通信経路で送信される、自動車内の通信ネットワークのための方法を提案する。本発明による方法は、少なくとも１つのステップ、好ましくは複数のステップを含む。これらのステップは、少なくとも、攻撃リスクに関してデータを送信する考慮の対象となる通信経路の評価に関する。

攻撃リスクは、セキュリティギャップを利用する目的で通信経路が攻撃されるリスクである。換言すると、これは通信経路が、第三者による、情報へのアクセス又は制御機構／規制機構の制御をすることにつながる攻撃（サイバー攻撃／ハッカー攻撃）の犠牲になるリスクである。自動車では、第三者によるそのような支配権の譲渡は、特に車両乗員の安全性に影響を与える可能性があるため、避けるべきである。これは本発明によって達成可能である。

本発明の文脈において、通信経路は、経路が複数の通信参加者（通信参加体）と参加者間でデータを送信するための接続とを備えると理解されるべきである。自動車内には、特定の通信、データ転送、又は異なるデータ転送に適した複数の通信経路が存在し得る。

利用可能な通信経路の攻撃リスクを確認することによって、自動車の配達の前又は試運転の前でも、おそらく攻撃のために第三者によって悪用される可能性があるギャップを検出可能である。ギャップは、したがって、なくすこと及び／又は減らすようにするか、あるいは通信参加者間の接続は、攻撃に対するセキュリティリスクを低くなるように設計され得る。

本発明の一発展態様によれば、好ましくは、通信経路におけるデータ転送のために少なくとも１つのデータ転送プロトコルが設けられる。この発展態様によると、データ転送のために問題になるデータ転送プロトコルは、攻撃リスクについて同様に評価される。

特に、データ転送プロトコルは、例えば、イーサネット、ＦｌｅｘＲａｙ（登録商標）、ＶＬＡＮ（仮想ローカルエリアネットワーク）、ＩＰ（インターネットプロトコル）、ＡＶＢ（オーディオ／ビデオブリッジング）、ＴＳＮ（タイムセンシティブネットワーキング）又はＳＯＭＥ／ＩＰ（インターネットプロトコルにわたる、スケーラブルなサービス指向ミドルウェア）として形成されている。データ転送プロトコルの追加の評価の結果、より幅広いデータベースが利用可能となり、ギャップの発見がより向上し、したがって攻撃に対するより高い安全性を達成できる。

好ましい一発展態様において、同様な方法のステップは、通信経路及びデータ転送プロトコルに関連する攻撃リスクの決定された評価に基づいて通信経路及びデータ転送プロトコルを選択することと、選択された通信経路及びデータ転送プロトコルを用いてデータを転送することとに関係する。この際に攻撃リスクの評価によって、ネットワークへの攻撃用の安全リスクが低いように、データ転送が構成されてもよい。

好ましい形式で本発明は、特に、追加の費用なしに、車両ネットワークの安全性を有利に向上可能である。自動車におけるイーサネット又は他のデータ転送システム（例えばＦｌｅｘＲａｙ）の使用では、とりわけ、高価な実装及び追加のハードウェアを省略可能にするために簡単な技術及び所与の技術の特性を使用する機構が必要とされている。通信経路の早期分析による攻撃及び異常行動の早期検出の結果として、車両が配達される前にギャップ及び障害を検出可能である。本発明によるネットワークシステムは、費用及び信頼性に関して改善されている。システムを試験する能力は本発明によってより明確に定義され、試験費用は結果として節約可能である。本発明はまた、透明なセキュリティ機能を提供する。

本発明の好ましい一発展形態では、各通信経路は複数の通信参加者を含む。この場合、通信参加者は、特に好ましくは、少なくとも送信機と受信機とを含み、それらの間でデータ転送の形態で通信が実行される。この開発によれば、通信参加者のうちの少なくとも１者（１体）、すなわち送信機又は受信機は、車載通信ネットワークの一部である。この場合、この参加者は自動車内に配置されるのが好ましい。それぞれの他の通信参加者は、同様に通信ネットワークの一部であってもよく、次に同様に自動車内に配置されてもよく、又は外部に位置する外部参加者であってもよい。外部参加者は、例えば、外部に配置された制御装置又はクラウドであり得る。開発によれば、ネットワークの一部である参加者は、好ましくは、自動車の制御ユニット（例えば、ＥＣＵ−電子制御ユニット）の形態である。

特に好ましくは、車外への接続は特に重要な方法で分析され、評価される可能性がある。それは、より大きなアクセス性のため、車両ネットワークへの攻撃が容易になる結果、第三者によって外部通信参加者がより簡単に操作されるおそれがあるからである。

本発明の別の好ましい発展形態では、方法が、好ましくは、さらなるステップとして、少なくとも１者の通信参加者のインタフェースパラメータ及び／又は少なくとも１者の通信参加者の接続パラメータを決定することを含む。特に好ましくは、決定されたパラメータはそれぞれ任意のデータベース又は共通のデータベースに格納される。少なくとも１つのデータベースは、特に好ましくは、中央制御装置、中央メモリ、又は通信参加者の制御装置に格納されてもよい。別の好ましい発展形態によれば、インタフェースパラメータ及び／又は接続性パラメータは、通信経路の攻撃リスクに関して通信経路を評価するためにさらなるステップで使用される。

各通信参加者は、データを送信するための１つ又は複数のインタフェースを有することが好ましい。本発明の好ましい一発展形態では、インタフェースパラメータは、少なくともインタフェースによってサポート及び／又は転送されるデータ転送プロトコルに関する情報を含む。さらに又は代わりに、インタフェースが診断機能又は充電機能（ＯＢＤ、電力線など）のために提供されるかどうかを決定するための提供が好ましくは行われてもよい。充電機能の場合には、車両（特に電気自動車）にインタフェースを介して電力を供給することができる。データは、特にインタフェースを介して又は電力線を介して結合することもできる。さらに好ましくは、代替的に又は追加的に、データを転送するためのそれらの速度に関してインタフェースが検査されるようになっている。

各通信参加者はまた、他の通信参加者に接続される複数の方法を有することが好ましい。 本発明の好ましい一発展形態では、接続性パラメータは、少なくとも接続技術及び／又は配信機能のサポートに関する情報を含む。制御ユニットは、例えば、様々な無線技術、例えばＷＬＡＮ又はブルートゥース（登録商標）をサポートすることができる。制御ユニットが複数のバスにアクセスできるかどうかは、分配機能パラメータの一部である。スイッチ、ブリッジ、ルータ及び／又はゲートウェイへのアクセスが可能であるかどうかも同様に確認される。

パラメータは、好ましくは、データベースに格納され、特に好ましくは、制御装置及び制御装置に直接接続されている他の装置のＭＡＣアドレス及び／又はＩＰアドレスに関する情報も格納される。

したがって、前述の方法によれば、状態分析は、まず始めに、どの通信参加者が存在するのかと、参加者がどのような性質を持ってきたのかとを、判断することが有利に実行される。この状態分析は、想定する攻撃の対象となるギャップを発見するべく、リスク評価の対象となる。通信経路のリスクポテンシャルは、ネットワークで与えられたパラメータを収集又は決定することで有利に正確に分析されよう。

本発明の好ましい一発展形態では、データ転送プロトコルの攻撃リスクを評価するために、当該プロトコルのパラメータも同様に算出され、データベースに格納される。この場合、好ましくは、特にプロトコルスタックが分析される。

本発明の好ましい一発展形態では、データ転送プロトコルの決定されるパラメータは、少なくとも、データプロトコルに使用される周波数、特定の数の受信機と通信するための適合性、及び／又は転送のタイプに関係する。

この場合、転送のタイプは、例えば、転送方向、同期又は非同期、通信参加者の位置及び／又は接続方向に関連する。接続方向の場合、接続の開始と終了が特別なパケットシーケンスによって定義される。データ転送プロトコルのパラメータはまた、パケット交換通信又はストリーミングが関係しているかどうかを含んでもよい。

本発明の好ましい一発展形態では、通信経路及びデータ転送プロトコルは、それぞれ関連する評価を使用してリスククラスに割り当てられる。通信経路及びデータ転送プロトコルを使用してデータの転送を決定するか否かを決定するプロセスが、したがってより簡単になる。換言すると、どの通信経路とどのデータ転送プロトコルを通信に使用することが意図されているのかに関する判断を、より簡単な方法でなし得る。

本発明の好ましい一発展形態では、異なる攻撃シナリオに関する情報を使用して通信経路の攻撃リスクを評価する。この情報は、好ましくは、特にメモリに格納されて継続的に更新されないデータベースに同様に格納される。しかしながら、攻撃シナリオに関する情報は、代替的に、より新しい攻撃シナリオも考慮可能に定期的に更新してもよい。更新は、例えば、情報が比較される外部データ接続からの更新を使用して実行してもよい。この情報は、特に好ましくは、様々な可能性のある攻撃の種類と、自動車又は乗員に対するセキュリティリスクの評価とに関する。考えられる攻撃の１つのタイプは、例えば、過負荷が第三者によって引き起こされ、機能又はサービスの障害をもたらすＤｏＳ（サービス拒否）である。したがって、通信経路の評価は、たとえば統計的に最も頻繁に発生する１つ又は複数の攻撃シナリオに合わせて有利に調整してもよい。代替的に又は付加的に、異なる攻撃シナリオに関する情報もまたデータ送信プロトコルを評価するために使用してもよい。

上述の手順の結果として、ネットワークの攻撃リスクのできるだけ正確な評価を可能とするため、詳細な分析が有利に実行されるか、又は詳細な情報が記憶される。

本発明の別の好ましい発展形態では、適切な通信経路及び適切なデータ転送プロトコルを選択する前に、通信が実際に行われ得るかどうか、又は過度に高いセキュリティリスクの結果として通信が防止されるべきかどうかを決定するようにしてもよい。さらに、他の対策、すなわち例えばファイアウォールの特別な構成も、１つ又は複数の評価に応答して採用してもよい。

本発明による方法は、好ましくは、ベルトエンドに（自動車の製造が完了した後に）、ソフトウェア更新の後に、セキュリティギャップの通信後に、又は通信の参加者の交換又は更新時に、実行される。したがって、セキュリティギャップは、例えば制御装置が交換された場合、又はソフトウェアの更新が提供された場合など、エンドカスタマーへの配達後にも有利に検出可能である。それ故、エンドカスタマーはまた、車両の運転中の攻撃に対して、より高い安全性を提供する。

好ましい一発展形態では、通信経路が攻撃されるリスクはアルゴリズムによって評価される。アルゴリズムは、好ましくは、攻撃のリスクに基づいてリスククラスを作成してもよく、通信経路をリスククラスに割り当てるようにしてもよい。この目的のために、アルゴリズムは、特に、評価における通信経路のパラメータ、データ転送プロトコル及び／又は異なる攻撃シナリオに関する情報に関する１つ又は複数のデータベースを、同時に含む。

データを転送する特定の通信経路が選択、提供、又は指定されている場合、例えば攻撃リスクを評価することによって、攻撃に関して高度なセキュリティを提供するデータ送信プロトコルを選択するようにしてもよい。この選択は、逆の方法でも可能である。データ転送プロトコルが選択され、特定され、又は提供されている場合、攻撃に関して高度なセキュリティを提供する経路は、通信経路の評価に基づいて選択するようにしてもよい。さらに、通信経路とデータ転送プロトコルとの間の相互作用における最低のセキュリティリスクを伴う組み合わせを、複数の可能な通信経路及びデータ転送プロトコルから選択してもよい。

本発明の好ましい一発展形態では、少なくとも１つのデータベース、特に好ましくは評価に使用される全てのデータベース又はデータは、セキュアメモリ領域に格納される。特に、このセキュアメモリ領域は暗号化されているため、攻撃から保護されている。この場合、セキュアメモリ領域は、例えば中央制御装置に配置してもよい。

本発明はまた、この方法を実行するように設計された自動車制御装置用の電子監視ユニット又は制御ユニットに関する。

さらなる好ましい実施形態は、図面に基づく例示的な実施態様の以下の説明から明らかになる。
図面は以下の、概略的な内容を示す。

通信パケット又はスタックの構造を示す図である。 ソフトウェアスタックの例を示す図である。 複雑なイーサネット／ＩＰ通信スタックとその分岐の例を示す図である。 本発明の例示的実施態様を示す図である。 制御装置の接続性パラメータ及びインタフェースパラメータの決定が描画された、本発明による方法の構成の一例を示す図である。 データ転送プロトコルのパラメータの決定が描画された、本発明による方法の構成の一例を示す図である。 プロトコルのリスク評価の一例を示す図である。 クラウド又は他の外部ユニットに接続する車両におけるクリティカルパスの一例を示す図である。 通信経路を守る本発明の例示的実施態様を示す図である。

例示的な実施形態の簡潔で簡単な説明を可能にするために、同一の要素には同一の参照符号が付されている。

図１は、通信パケット又はスタック１の一般に公知の構造を示す。イーサネット及びＩＰ（インターネットプロトコル）の出現に伴う課題は、とりわけ、新しい通信スタックの複雑さである。インターネットの世界とＡＵＴＯＳＡＲの最初の融合では、両方の世界がまったく異なる方法で機能するため（静的対動的）、多くの初期費用が必要になる。

図１は、典型的な通信パケットを示す。通信のパイル（通信スタック）は、パケットの受信の度に漸次進み、正しい受信機（例えばアプリケーション）に転送するために特定のフィルタに従ってパケットを検査する。

通信パケットは、実際のデータコンテンツ３と、例として、ソフトウェアスタックの異なる層に割り当てられた複数のヘッダ２ａから２ｄとを含む（図２参照）。ソフトウェアスタックの各層にヘッダが提供され、ヘッダは、通信パケットを処理するのに必要な情報をソフトウェアスタックの層に提供する。

図２は、制御装置内のソフトウェアスタック４の例示的表現を示す。ＴＣＰ／ＩＰスタック６が例として示されている。（例えば図１に示される）通信パケットはこのスタックを通過し、そこでパケットが分析される。コンテンツの分析に基づいて、通信パケットがどのアプリケーションに転送されるかが決定される。

図示のＴＣＰ／ＩＰスタック６は、ここでは参照符号８、１０及び１２として表される複数の層を含み、層８はＭＡＣ（メディアアクセス制御）として形成されていて、層１０はＩＰ（インターネットプロトコル）の形式であり、層１２はＴＣＰ／ＵＤＰ（転送制御プロトコル／ユーザデータグラムプロトコル）として形成されている。通信パケットのヘッダ（図１参照）はそれぞれこれらの層の一つに割り当てられる。

ＭＡＣ層８は、一般に知られているＯＳＩモデルによれば、階層１（物理層）（例えば図１のヘッダ２ａを有する層）及び階層２（データリンク層）（例えば図１のヘッダ２ｂを有する層）を表す。ＩＰは、ＯＳＩモデルの（例えば図１のヘッダ２ｃを有する層）第３層を表し、ＴＣＰ／ＵＤＰは、ＯＳＩモデルの（例えば図１のヘッダ２ｄを有する）第４層を表す。「ミドルウェア」層は層１４に表され、これはＯＳＩモデルの（セッション及びプレゼンテーション）階層５及び階層６（セッション層及びプレゼンテーション層）に対応する。アプリケーション（「アプリケーション」層）は、第７層１６としてこれより上位にある。

イーサネットフレーム、すなわちデータパケット１は、ＴＣＰ／ＩＰスタック６に送信される。任意の層（ＰＤＵ ＝ペイロードデータユニット）のデータ及び管理情報１８は、例えばＴＣＰ／ＩＰスタック６から「ミドルウェア層」１４に送信してもよい。

図３は、複雑なイーサネット／ＩＰ通信スタック及びその分岐の例示的な例を示す。そのようなソフトウェアスタックで処理されなければならないイーサネットパケットの内容には、様々な可能性があることが明らかになっている。ソフトウェアスタックの複雑さは、イーサネットとＩＰの出現により、自動車では非常に大きくなっている。決定論的ソフトウェアスタックのトレーサビリティは、特にさまざまな分岐の可能性の結果として、もはやそれほど単純ではない。

図４は、データベース２０が中央ゲートウェイ２２に格納されるか、あるいは中央ゲートウェイ２２がこのデータベース２０にアクセスする、本発明の例示的な実施形態を示す。データベース２０は、本発明による方法によって決定される情報を含む。中央ゲートウェイ２２から分岐しているのは、さらなるゲートウェイ（ＧＷ）と、制御装置又は想定される通信相手（小さなボックスとして図示）である。ゲートウェイと、制御装置又は想定される通信相手とは、ＣＡＮ（制御エリアネットワーク）、ＬＩＮ（ローカル相互接続ネットワーク）、ＦｌｅｘＲａｙ、ＭＯＳＴ（メディア指向システムトランスポート）、ＷＬＡＮ（無線ローカルエリアネットワーク）、ＬＶＤＳ（低電圧差動信号）、ブルートゥース又はイーサネットを経由して、互いに接続される。

個々の接続の可能性についてのリスク評価が少なくともデータベース（例えば２０）に格納される本発明による方法では、これらの異なる可能な接続の全てが考慮される。リスク評価は、第三者が接続を介してデータにアクセスすることと、車両内の制御／規制メカニズムを制御することとの少なくとも一方のリスクを示す。このデータベース２０内の情報は、例えばアルゴリズムによって、通信路及びデータ転送プロトコルをリスククラスに割り当てるために使用される。リスククラスは、どのデータ転送プロトコルと組み合わせてどの通信経路が複数の参加者（参加体）間の通信又はデータ転送を実行することを意図されているかを選択するための基礎として、取られる。この場合、セキュリティリスクが比較的低い、又は攻撃のリスクが比較的低いと判断された、通信経路とデータ転送プロトコルとの組み合わせが選択されることが好ましい。

図５は、制御ユニットの接続性パラメータ及びインタフェースパラメータを決定するための本発明の例示的実施形態を示す。

以下は、個々のステップの説明である。
ステップ３０：接続性及びインタフェースに関する制御装置のクエリ（質問）の開始
ステップ３２：ＥＣＵは無線技術（ＷＬＡＮ、ブルートゥースをサポートしているか？
ステップ３３：直接接続されている制御機器のアドレスを含む本機器のＭＡＣアドレスとＩＰアドレスの要求
ステップ３４：ＥＣＵには、診断や充電のために提供されているインタフェース（ＯＢＤ、電力線など）があるか？
ステップ３５：直接接続されている制御機器のアドレスと電源状態を含む本機器のＭＡＣアドレスとＩＰアドレスの要求
ステップ３６：ＥＣＵは分配機能（スイッチ、ルーター、ゲートウェイ）を持っているか？
ステップ３７：このデバイスのＩＰアドレスとポートのステータス及び速度の要求
ステップ３８：ＥＣＵには１００ＢａｓｅＴ１などの高速インタフェースがあるか、又は同等以上の高速インタフェースがあるか？
ステップ３９：ポリシング及びレート制限機能に関するクエリ
ステップ４０：終了

例えば、制御ユニット（ＥＣＵ）が無線接続、例えばＷＬＡＮ又はブルートゥース（参照符号３２）をサポートしているかどうかを問い合わせるようにしてもよい。もしそうであれば、装置のＭＡＣアドレス及び／又はＩＰアドレスが決定され（ステップ３３）、データベース２０に記憶される。制御ユニットに接続された装置のアドレス（ＭＡＣ及びＩＰ）も同様に好ましくはデータベース２０に記憶される。さらに例えば、制御ユニットが診断又は充電（ＯＢＤ−オンボード診断、ＰＬＣ−電力線通信など）に適している（ステップ３４）インタフェースを有するかどうかを問い合わせるようにしてもよい。この場合も、アドレスと電力ステータス（電力線通信用のインタフェースが存在するか否か）（ステップ３５）を再び記憶するようにしてもよい。この場合、電力ステータスは、インタフェースに、いわば、例えば外部バッテリから又は内部バッテリから電力が供給される状態についてであってもよい。

さらなる例示的なクエリは、制御ユニットの配信機能に関連してもよい（ステップ３６）。制御ユニットが分配機能を有する場合、それは異なるバスにアクセスしてもよく、したがって異なる通信参加者（例えばスイッチ、ルータ、ゲートウェイ）に到達してもよい。この制御ユニット及び接続可能な通信参加者のＩＰアドレスを記憶することに加えて、ポートのそれぞれの状態及び可能な速度もまたデータベース２０に記憶されること（ステップ３７）が好ましい。エネルギーの状態としては、「オン」、「省エネモード」、「ウェイクアップ可能」などのエネルギーの状態が、ポートの状態として提供されてもよい。

更なるクエリとして、例えば、インタフェースの速度、特に高速インタフェース、例えば１００ＢＡＳＥ−Ｔ１が存在するか否かを決定するための規定（３８）がなされてもよい。この点で、監視（ポリシング）及びレート制限機能に関する情報が、好ましくは使用される。レート制限機能の範囲内で、データレートは時間の単位に基づいて設定される。いわゆるポリシング中に、単位時間当たりの最大データレートを超えないようにするために監視が行われる。超過が発生した場合、例えば設定されたよりも多くのデータが送信された場合、例えば、前記データは拒否される。前記機能のための情報又は設定は、インタフェースのためのパラメータとして捕捉されて（ステップ３９）もよく、データベース２０に格納されてもよい。

この場合、個々のクエリステップをプログラミングループで実行してもよく、例えば中央制御装置、例えばゲートウェイ２２に、そして好ましくはセキュアメモリ領域に格納されているアルゴリズムの一部としてもよい。データベース２０もこのセキュアメモリ領域又は他のセキュアメモリ領域に格納されるのが、好ましい。

車載ネットワーク内に存在する制御装置は、重要なパラメータを記憶するために、その接続性に基づいて上述の方法によってリスククラスに分類されることが好ましく、それに基づいてセキュリティメカニズムへの割り当てが行われる。これらのＥＣＵには無線技術又はオープンネットワークインタフェースが装備されていて、これらを使用して連絡をとることが可能である。

例えば、プロトコルサポートに関するチェックがそれから行われてもよい。これは、外部への接続を保留する前、ソフトウェアの更新後、又は既存のプロトコルのセキュリティギャップの通知があったとき、１回実行される（ベルトエンド）ようにしてもよい。この方法は中央で開始されても、個々のＥＣＵから要求されるようにしてもよい。例えば、通信経路の設定が保留中であり、例えば診断データがアンテナモジュールから無線送信されることが意図されているならば、アンテナモジュールはそれぞれの近隣装置のプロトコルサポートをチェックするようにしてもよい。

図６は、例として、本発明による方法の一部、及びその中に含まれるアルゴリズムの個々のステップ又は手順ステップを示す。個々のステップは次のとおりである。
ステップ５０：プロトコル実装の検討開始
各制御装置５１は、特定のプロトコルタイプ５３がサポートされているかどうか（５４）、及び／又は転送されているかどうか（５５）を判断するために、各インタフェースを調べる（５２）。
ステップ５４：インタフェースがプロトコルをサポートしているか否か判定される。
ステップ５５：インタフェースがプロトコルを転送しているか否か判定される。
ステップ５６：データベース２０に情報を記憶する。この情報は、例えば、ＥＣＵ、インタフェース、及びプロトコルタイプに関連する。
ステップ５７：プログラム実行の終了
プログラムのコメントを記載することで、プログラムの実行がより理解可能となるので、そのようなコメントが、参照符号に加えて図６に示される。

したがって、ＥＣＵごとに、またＥＣＵのインタフェースごとに、異なるプロトコルタイプがサポートされているかどうか（ステップ５１から５４）が判定される。プロトコルタイプは、好ましくは、アルゴリズムによってそれぞれ個別に照会される（ステップ５３）。結果はデータベース２０に格納される。結果は、好ましくは、ＥＣＵ及びインタフェースの指定及びそれぞれのプロトコルタイプがサポートされるかどうかを有するテーブルである。例えば、図７に示すように、このタイプの結果テーブルが、図７に示すように作成されてもよい。 図７に示すマトリックス は、仕様ではなく実際の実装を反映する。これにより、実装上の障害やギャップの識別が可能となる。起因する機構に関係なく、そして車両がエンドクライアントに納入される前でも、このマトリックスはさらに、例えばＴUＶ（技術監視協会）又はシステム製造業者にとって、セキュリティの観点から車両を検証及びテストするために役立ち得る。

図８は、例えば、外部接続（例えばクラウドへの無線接続）６２からなるクリティカルパス６０の例を示す。外部接続は、パラメータ分析の最初から、内部の接続のみよりもクリティカルであるとして分類又は評価されることが好ましい。例えば、ソフトウェアはクラウド６２からダウンロードされることが意図される、ソフトウェアダウンロード６４の形のデータ転送が開始されることを意図されている。このために、内部メモリ６６は、例えば、ヘッドユニット７０を経由してゲートウェイ６８（２２と同一でもよい）に接続され、ゲートウェイ６８はＷＬＡＮ接続モジュール７２を経由してクラウド６２に接続される。この例によると、通信パートナー６２から７２のつながりは、したがって、通信経路６０を表す。この経路６０は、経路の攻撃リスクに関して評価される。攻撃リスクとは、すなわち、車内の安全性を危険にさらす可能性がある第三者による攻撃の犠牲となるリスクがどれほど高いかということである。この目的のために、個々の通信参加者６２から７２が、それらの接続性パラメータ及びそれらのインタフェースパラメータに関して調べられる。同時に、個々の想定されるデータ転送プロトコルのリスクが、好ましくは評価に含まれる。この経路６０が通信用に選択されることが意図され、経路６０が攻撃されるリスクが考慮されるときに、意図されるプロトコルがあまりにも安全でないことが明らかになったならば、例えば、異なるプロトコルを選択してデータを送信してもよい。あるいは、他のより安全な経路が、通信用に選択されてもよい。

図８に例として示されているこの経路６０は、システム設計者又は設計者によって特定されてもよく、そのように定義されてよく、動的に決定されるようにしてもよい。

さらに、マトリックスをチェックした後（図７）、経路６０がそのギャップについて追加的にチェックされてもよい。それでもクリティカルではないパスがクリティカルになる状況は起こり得る。例えば、制御装置の異常な動作の結果として、そのデータがＣＰＵに転送されてしまうと、その結果として他の制御装置がブロックされて停止状態になることがある。

通信経路とパラメータの例を以下に示す。
関与する制御装置には、アンテナ、ゲートウェイ（スイッチを含む）、ヘッドユニットがある。
プロトコルには、イーサネット、ＶＬＡＮ、時刻同期、ＩＰ、ＴＣＰ、ＳＯＭＥ／ＩＰがある。
メッセージ頻度には、ｘ／パケット／秒イーサネット、ｘ／パケット／秒ＴＣＰなど、最大パケットサイズがある。

安全であると考えられるデータストリームが、もし毎秒１０個のデータパケットの代わりに、１０００個のデータパケットが中央演算装置によって処理されることを突然意図されたならば、リスクになり得る。したがって、入ってくるデータパケットが常に高い優先度で処理され（受け入れられ、記憶される）、ＣＰＵ（場合によっては複数）は、重要である。あまりにも多くのパケットが過度に高頻度で、そして過度のパケットサイズで到着すると、ＣＰＵはブロックされるおそれがあり、制御装置はしたがって完全に故障するかもしれない。

通信経路が固定されている場合は、例えば図８に示すように、関与する制御装置６２から７２は、それらのリスククラス及びそれらのプロトコルサポートに関してクエリが実行されるようにしてもよい。通信に必要なプロトコルを使用して、ギャップやリスクをしたがって即座に検出可能である。例えば、ＴＣＰデータトラフィックは、これに関連してヘッドユニット７０内のＣＰＵに贈られる。この情報はリスク評価に含まれる。実際の接続が確立される前であっても、ＴＣＰトラフィックはヘッドユニット７０内又はそれ以前（ゲートウェイ６８内）で制限可能であり、すなわち、１秒当たりの最大パケットデータレートを設定可能である。

さらに、ヘッドユニット７０内のファイアウォールは、通信パラメータ及び（既に）検出されたギャップに基づいて構成してもよい。これは、ファイアウォールのフィルタがこの通信に合わせて調整され、より高い優先度が置かれることを意味する。

図９は、本発明による方法の可能な全体図を示す。本方法の開始時に、好ましくは、個々の通信参加者は、通信参加者のインタフェース及び通信参加者の接続性パラメータに関して、まず始めにクエリ８０を受ける。結果はデータベース２０に格納される。さらに、例えば次のステップとして、サポートされているデータ転送プロトコルがクエリされ（８２）、同様にデータベースに格納される。この場合、各データ転送プロトコルが攻撃されるリスクも格納される。様々な種類のデータ転送プロトコルが一般に既知なので、それぞれ存在する攻撃リスクもデータベース内の情報として既に格納されている可能性があり、その情報はサポートされるプロトコルの決定時に使用される。データ転送プロトコルが攻撃されるリスクが、次に、格納された情報に基づいて評価される。

全体として、リスクマトリックス８４（図７に示すように）を作成してもよい。経路は、次に、その攻撃リスクに関して評価される（ステップ８６）。これはアルゴリズムによって実行してもよい。比較的低いセキュリティリスク（ネットワークに対する攻撃のリスク）を有するそのプロトコルは、通信のためにサポートされているデータ転送プロトコルから選択（ステップ８８）可能である。

分類に基づいて、可能なセキュリティリソースのレベルも決定され割り当てられ（ステップ９０）、そこでネットワーク内の情報セキュリティを、設計段階の間、ベルトエンドプログラミングの間、又は動的かつディスラプティブアーキテクチャの場合のいずれかに計画及び実装されるようにしてもよい。

ステップの概要を以下に示す。
ステップ８０：通信参加者の接続性パラメータ及びインタフェースパラメータの決定
ステップ８２：どのプロトコルがサポートされているかの判断
ステップ８４：リスクマトリックスの作成
ステップ８６：クリティカルパスの計算／クエリ
ステップ８８：必要なプロトコルの分析／適切なデータ転送プロトコルの選択
ステップ９０：セキュリティ方式の定義

データベース２０及び／又は評価アルゴリズムは、特に好ましくは、集中的に及び個々の制御装置のそれぞれに格納される。いわゆるリスク評価は、サポートされているプロトコルとサポートされていないプロトコル、及びプロトコルの処理に基づいて作成される。このリスク評価は、次に、通信経路を分析し保護するために使用可能である。このマトリックスは、通信経路の作成中にクエリを受け、必要に応じてアクションが定義される。その際に生じるマトリックスは、仕様ではなく実際の実装を反映する。これにより、実装上の欠陥やセキュリティギャップを特定できるようになる。結果生じる機構とは無関係に、追加的に、マトリックスを、情報セキュリティに関して車両の検証及びチェックに役立ち得る。

プロトコルサポートの知識を得た後、ＥＣＵは、例えば、経路上に問題があると、プロトコルの選択を変更してもよい。例えば、より安全なプロトコルが選択されてもよい。

本願の図面では、データベースに参照符号２０が付されている。しかしながら、個々に決定されたパラメータ及び攻撃リスクは、別々のデータベースに同様に格納されてもよい。この場合、データベースは、インタフェースパラメータ、接続パラメータ、通信経路又は通信参加者が攻撃されるリスク、データ転送プロトコルが攻撃されるリスク、及びリスククラスについてそれぞれ利用可能である。

本発明は、潜在的な攻撃機能に対して正しいソフトウェアブランチを選択するためのメカニズムを定義する。本発明は、どのパケットがどのタイプのアプリケーションに使用でき、どれが使用できないかを述べる。

本発明は、ベルトエンドプログラミング及びシステム試験に使用してもよい。さらに、将来、自動車用のソフトウェア更新がますます提供され、その結果、新しい機能が有効になる。多種多様な結果として、本発明は、更新後の車両内のソフトウェアスタックの全体及び部分について、チェック及び新たな評価に適する。本発明は、ネットワーク内でこれらの規制機構及び可能性を構成し、それらをインタフェース経由で使用可能にする方法を提案する。どの潜在的なギャップが存在するか、そしてソフトウェアが事前定義された要件を満たしているかどうかを、したがって、識別可能となる。この方法はまた、透明性を提供することを可能にし、したがって、一層簡単な方法で、セキュリティについてネットワーク全体のチェック及びテストを可能にする。

１ 通信パケット又はスタック
２ ヘッダ
３ データコンテンツ
４ ソフトウェアスタック
６ ＴＣＰ／ＩＰスタック
８ ＭＡＣの形式の層
１０ ＩＰの形式の層
１２ ＴＣＰ／ＵＤＰの形式の層
１４ ミドルウェア層
１６ 第７層
１８ データ及び管理情報
２０ データベース
２２ 中央ゲートウェイ
３０ 接続性及びインタフェースに関する制御装置のクエリの開始
３２ ＥＣＵは無線技術（ＷＬＡＮ、ブルートゥースをサポートしているか？
３３ 直接接続されている制御機器のアドレスを含む本機器のＭＡＣアドレスとＩＰアドレスの要求
３４ ＥＣＵには、診断や充電のために提供されているインタフェース（ＯＢＤ、電力線など）があるか？
３５ 直接接続されている制御機器のアドレスと電源状態を含む本機器のＭＡＣアドレスとＩＰアドレスの要求
３６ ＥＣＵは分配機能（スイッチ、ルーター、ゲートウェイ）を持っているか？
３７ このデバイスのＩＰアドレスとポートのステータス及び速度の要求
３８ ＥＣＵには１００ＢａｓｅＴ１などの高速インタフェースがあるか、又は同等以上の高速インタフェースがあるか？
３９ ポリシング及びレート制限機能に関するクエリ
４０ 終了
５０ プロトコル実装の検討開始
５１ 制御装置
５２ インタフェースを調べる
５３ プロトコルタイプについてのクエリ
５４ インタフェースがプロトコルをサポートしているか否か判定する
５５ インタフェースがプロトコルを転送しているか否か判定する
５６ データベース２０に情報を記憶する
５７ 終了
６０ 通信経路（クリティカルパス）
６２ クラウド
６４ ソフトウェアダウンロード
６６ 内部メモリ
６８ ゲートウェイ
７０ ヘッドユニット
７２ ＷＬＡＮ接続モジュール
８０ 通信参加者の接続性パラメータ及びインタフェースパラメータの決定
８２ どのプロトコルがサポートされているかの判断
８４ リスクマトリックスの作成
８６ クリティカルパスの計算／クエリ
８８ 必要なプロトコルの分析／適切なデータ伝送プロトコルの選択
９０ セキュリティ方式の定義

Claims (9)

1. 車載ネットワーク内の通信のため少なくとも１つの通信経路（６０）でデータが転送される、車載ネットワーク用の方法であって、
   当該方法は、攻撃リスクについて、データを転送する可能性のある通信経路（６０）を評価する（８６）ステップを備え、
   攻撃リスクが、通信経路（６０）がセキュリティギャップを利用するために通信経路（６０）が攻撃されるリスクである
   ことを特徴とする、車載ネットワーク用の方法。
2. 少なくとも１つのデータ転送プロトコル（４）が通信経路（６０）での通信に提供され、
   当該方法が、攻撃リスクについて、データを転送する可能性のあるデータ転送プロトコル（４）を評価する（８２）ステップをさらに備えることを特徴とする、請求項１に記載の方法。
3. 通信経路（６０）の攻撃リスクの評価（８６）と、データ転送プロトコル（４）の攻撃リスクの評価（８２）とに基づいて通信経路（６０）とデータ転送プロトコル（４）とを選択するステップと、
   選択された通信経路（６０）と選択されたデータ転送プロトコル（４）とを用いてデータを転送するステップと
   を備えることを特徴とする請求項２に記載の方法。
4. 各通信経路（６０）は複数の通信参加者（６２、６６、６８、７０、７２）を備え、通信参加者のうちの少なくとも１者は通信ネットワークの一部であるとともに車両内の制御ユニットの形態であって、
   当該方法が、
   少なくとも１つの制御ユニットのインタフェースパラメータを決定するステップと、
   インタフェースパラメータをデータベース（２０）に格納するステップと、
   インタフェースパラメータを通信経路（６０）の評価（８６）に使用するステップと、
   をさらに備えることを特徴とする、請求項１から３のいずれか一項に記載の方法。
5. 各通信経路（６０）は複数の通信参加者（６２、６６、６８、７０、７２）を備え、通信参加者のうちの少なくとも１者は通信ネットワークの一部であるとともに車両内の制御ユニットの形態であって、
   当該方法が、
   少なくとも１つの制御ユニットの接続パラメータを決定するステップと、
   接続パラメータをデータベース（２０）に格納するステップと、
   決定された接続パラメータを通信経路（６０）の評価（８６）に使用するステップと、
   をさらに備えることを特徴とする請求項１から４のいずれか一項に記載の方法。
6. 攻撃リスクの評価（８６、８２）それぞれに付随するリスククラスについて、通信経路（６０）とデータ転送プロトコル（４）とを評価するステップ
   を備えることを特徴とする請求項１から５のいずれか一項に記載の方法。
7. 異なる攻撃シナリオに関連する情報を、通信経路（６０）とデータ転送プロトコル（４）との少なくとも一方についての攻撃リスクの評価（８６、８２）に使用することを特徴とする請求項１から６のいずれか一項に記載の方法。
8. ベルトエンド時と、ソフトウェア更新後と、セキュリティギャップの公知後と、通信経路（６０）の参加者の交換又は更新と、のいずれかにおいて１回実行されることを特徴とする請求項１から７のいずれか一項に記載の方法。
9. 自動車制御装置用の電子監視ユニットにおいて、自動車制御装置が請求項１から８のいずれか一項に記載の方法を実施するように形成されたことを特徴とする、電子監視ユニット。