JP2023523883A - 自動車の通信システムのためのデータリンク層の真正性およびセキュリティ - Google Patents

自動車の通信システムのためのデータリンク層の真正性およびセキュリティ Download PDF

Info

Publication number
JP2023523883A
JP2023523883A JP2022556148A JP2022556148A JP2023523883A JP 2023523883 A JP2023523883 A JP 2023523883A JP 2022556148 A JP2022556148 A JP 2022556148A JP 2022556148 A JP2022556148 A JP 2022556148A JP 2023523883 A JP2023523883 A JP 2023523883A
Authority
JP
Japan
Prior art keywords
protocol frame
transmitter
security
protocol
data
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
JP2022556148A
Other languages
English (en)
Inventor
ツェー アレクサンダー
ツヴェック ハラルト
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.)
Infineon Technologies AG
Original Assignee
Infineon Technologies AG
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 Infineon Technologies AG filed Critical Infineon Technologies AG
Publication of JP2023523883A publication Critical patent/JP2023523883A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/162—Implementing security features at a particular protocol layer at the data link layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215—Controller Area Network CAN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40267—Bus for use in transportation systems
    • H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Medical Informatics (AREA)
  • Small-Scale Networks (AREA)

Abstract

本開示は、車両内のバスベースの通信ネットワークのための真正性およびデータセキュリティに関する。本開示は、このような真正性およびデータセキュリティを提供するプロトコルフレーム、データリンク層上の送信機およびデータリンク層上の受信機と、本開示によるプロトコルフレーム、送信機および受信機を使用する車両内の通信ネットワークと、を教示する。

Description

本開示は、車両ネットワークにおけるネットワークのためのデータリンク層上での認証およびセキュリティに関する。
今日の車両では、データの完全性およびセキュリティが必須となっている。過去のいくつかの機能、例えば操舵では、ステアリングホイールから車両の車輪への物理的な接続が設けられていた。同じことが、制動機能および変速機能についても当てはまる。しかしながら、今日の車両では、このような物理的な接続はもはや存在せず、ステアリング命令を電動パワーステアリングに通信する電気的なワイヤまたはバスが存在する。バスを介した操舵命令に応答して、電動パワーステアリングは、ステアリングホイールの旋回に対応する車輪の旋回を作動させる。
バスにアクセスすることにより、車両の機能を引き受けることを試みて悪意のあるバス通信または命令を挿入することが可能となり得る。挿入された悪意のあるバス命令の危険性は、今日の車両に提供されるエンターテイメント機能または接続性の向上に伴ってさらに増加している。
自動運転車両または自動運転自動車の場合には、車両の周囲を分析するためのセンサデータと、車両を制御するアクチュエータへの命令とをバス通信として実現することができるので、この危険性が一層高くなる。
この危険性を軽減するための１つの手法は、このようなバス通信のための真正性およびセキュリティをデータリンク層レベルで提供して、これらの真正性および／またはセキュリティの問題によって上位のプロトコル層に負荷をかけないようにすることである。
いくつかの可能な実装形態によれば、プロトコルに従って車両内のバスベースの通信システムの参加者間で通信するためのプロトコルフレームは、ヘッダを含むことができ、ヘッダは、送信機と受信機との間で通信されるべきプロトコルフレームの開始を示し、送信機および受信機の両方は、バスベースの通信システムの参加者であり、プロトコルフレームは、指示を含むことができ、指示は、データリンク層上でのプロトコルフレームの真正性のレベルおよび／またはデータセキュリティのレベルを示すように構成されている。第１の実装形態では、指示は、プロトコルフレームに対するデータリンク層レベルでの認証を示すように構成された第１の指示を含む。
第２の実装形態では、単独でまたは第１の実装形態と組み合わせて、指示は、プロトコルフレームに対するデータリンク層レベルでの認証およびデータセキュリティの両方を示すように構成された第２の指示を含む。
第３の実装形態では、単独でまたは第１の実装形態および第２の実装形態のうちの１つまたは複数と組み合わせて、指示、第１の指示、または第２の指示のうちの少なくとも１つは、プロトコルフレームのヘッダの一部である。
第４の実装形態では、単独でまたは第１の実装形態から第３の実装形態までの１つまたは複数と組み合わせて、指示、第１の指示、または第２の指示のうちの少なくとも１つは、プロトコルフレームのペイロードタイプとして表される。
第５の実装形態では、単独でまたは第１の実装形態から第４の実装形態までの１つまたは複数と組み合わせて、指示、第１の指示、または第２の指示のうちの少なくとも１つは、ヘッダの内部のセキュリティ指示フラグまたはビットフィールドとして表される。
第６の実装形態では、単独でまたは第１の実装形態から第５の実装形態までの１つまたは複数と組み合わせて、プロトコルフレームは、ヘッダの下流のセキュリティ情報と、ヘッダの下流の保護されたペイロード部分と、を含むことができ、セキュリティ情報は、保護されたペイロード部分に対する保護レベルを示す。
第７の実装形態では、単独でまたは第１の実装形態から第６の実装形態までの１つまたは複数と組み合わせて、セキュリティ情報は、送信機と受信機との間の仮想チャネル、または１つもしくは複数のキーのうちの少なくとも１つを示すようにさらに構成されている。
第８の実装形態では、単独でまたは第１の実装形態から第７の実装形態までの１つまたは複数と組み合わせて、セキュリティ情報と組み合わせられた指示は、プロトコルフレームに対して認証のみが適用されるか、または認証およびデータ保護が適用されるかを示す。
第９の実装形態では、単独でまたは第１の実装形態から第８の実装形態までの１つまたは複数と組み合わせて、セキュリティ情報は、プロトコルフレームに対するデータリンク層レベルでの認証のため、または認証およびデータセキュリティのために選択されるべきキーを示すセキュリティアソシエーションを示すようにさらに構成されている。
第１０の実装形態では、単独でまたは第１の実装形態から第９の実装形態までの１つまたは複数と組み合わせて、プロトコルフレームは、セキュリティタグをさらに含み、セキュリティタグは、送信機から受信機に伝送されることが意図されたオリジナルのプロトコルフレームとしてのプロトコルフレームの真正性を、データリンク層レベルで検証するように構成されており、セキュリティタグは、プロトコルフレームの真正性を、データリンク層上の送信機で、またはデータリンク層上の受信機で検証するように構成されている。
第１１の実装形態では、単独でまたは第１の実装形態から第１０の実装形態までの１つまたは複数と組み合わせて、フレームは、コントローラエリアネットワーク（ＣＡＮ）標準、ＣＡＮフレキシブルデータレート標準、またはＣＡＮエクストララージ標準と共に使用される長さＮを有する。
第１２の実装形態では、単独でまたは第１の実装形態から第１１の実装形態までの１つまたは複数と組み合わせて、フレームは、８バイト、８～６４バイト、または６４～２０４８バイトの長さＮを選択的に有する。
いくつかの可能な実装形態によれば、車両内のバスベースの通信システムに参加するように構成されている、データリンク層上の送信機であって、送信機は、上位のプロトコル層からの要求に応じてヘッダを生成し、ｋバイト長のキーＫにアクセスし、上位のプロトコル層から保護されたペイロード部分を受信し、付加認証データを集約し、送信機から受信機に送信されるオリジナルフレームとしてのフレームの真正性を、データリンク層レベルで検証するためのセキュリティタグを、キーＫおよび付加認証データを使用して生成し、ヘッダと、保護されたペイロード部分と、付加認証データと、を含むプロトコルフレームを生成するように構成されており、送信機は、プロトコルフレームを、送信機からバスベースの通信システムの１つまたは複数の参加者にデータリンク層レベルで通信するように構成されている。
第１の実装形態では、バスベースの通信システムは、ブロードキャストベースのバスシステムであり、したがって、バスベースの通信システムの内部の全てのノードが、送信機によって通信されたプロトコルフレームを受信するように構成されている。
第２の実装形態では、単独でまたは第１の実装形態と組み合わせて、プロトコルフレームは、データリンク層上でのプロトコルフレームの真正性のレベルまたはデータセキュリティのレベルを示すように構成された指示をさらに含む。
第３の実装形態では、単独でまたは第１の実装形態および第２の実装形態のうちの１つまたは複数と組み合わせて、指示は、プロトコルフレームに対するデータリンク層レベルでの認証を示すように構成された第１の指示を含む。
第４の実装形態では、単独でまたは第１の実装形態から第３の実装形態までの１つまたは複数と組み合わせて、指示は、プロトコルフレームに対するデータリンク層レベルでの認証およびデータセキュリティの両方を示すように構成された第２の指示を含む。
第５の実装形態では、単独でまたは第１の実装形態から第４の実装形態までの１つまたは複数と組み合わせて、指示、第１の指示、または第２の指示のうちの少なくとも１つは、プロトコルフレームのヘッダの一部である。
第６の実装形態では、単独でまたは第１の実装形態から第５の実装形態までの１つまたは複数と組み合わせて、指示、第１の指示、または第２の指示のうちの少なくとも１つは、ヘッダの内部のセキュリティ指示フラグまたはビットフィールドとして表される。
第７の実装形態では、単独でまたは第１の実装形態から第６の実装形態までの１つまたは複数と組み合わせて、送信機の認証のみのモードにおいて、付加認証データは、ヘッダと、保護されたペイロード部分とである。
第８の実装形態では、単独でまたは第１の実装形態から第７の実装形態までの１つまたは複数と組み合わせて、認証された暗号化モードにおける送信機は、キーと、平文での保護されたペイロード部分と、付加認証データとしてのヘッダと、を使用して、保護されたペイロード部分のための暗号文を生成するようにさらに構成されている。
第９の実装形態では、単独でまたは第１の実装形態から第８の実装形態までの１つまたは複数と組み合わせて、送信機は、ヘッダの下流にｓｎバイトのシーケンス番号を生成するようにさらに構成されており、送信機は、保護されたペイロードの短縮を犠牲にしてシーケンス番号をプロトコルフレームに組み込むように構成されており、短縮された保護されたペイロードは、保護されたペイロード部分に比べてｓｎバイトだけ短縮されている。
第１０の実装形態では、単独でまたは第１の実装形態から第９の実装形態までの１つまたは複数と組み合わせて、送信機の認証のみのモードにおいて、付加認証データは、ヘッダと、シーケンス番号と、保護されたペイロードと、を含む。
第１１の実装形態では、単独でまたは第１の実装形態から第１０の実装形態までの１つまたは複数と組み合わせて、送信機は、キーＫを使用して長さｓｉのセキュリティ情報を生成するように構成されており、送信機は、ペイロードの短縮を犠牲にしてセキュリティ情報をヘッダの下流でプロトコルフレームに組み込むようにさらに構成されており、短縮されたペイロードは、保護されたペイロードに比べてｓｉバイトだけ短縮されており、セキュリティ情報は、保護されたペイロード部分に対する保護レベルを示す。
第１２の実装形態では、単独でまたは第１の実装形態から第１１の実装形態までの１つまたは複数と組み合わせて、認証された暗号化モードにおける送信機は、ｓｉバイト長のセキュリティ情報を生成するようにさらに構成されており、送信機は、保護されたペイロードの短縮を犠牲にしてセキュリティ情報をヘッダの下流でプロトコルフレームに組み込むようにさらに構成されており、短縮された保護されたペイロードは、保護されたペイロードに比べてｓｉ＋ｓｎバイトだけ短縮されており、セキュリティ情報は、短縮された保護されたペイロードに対する保護レベルを示す。
第１３の実装形態では、単独でまたは第１の実装形態から第１２の実装形態までの１つまたは複数と組み合わせて、付加認証データは、ヘッダと、ノンスとしてのシーケンス番号と、セキュリティ情報と、短縮された保護されたペイロードと、を含む。
第１４の実装形態では、単独でまたは第１の実装形態から第１３の実装形態までの１つまたは複数と組み合わせて、認証された暗号化モードにおける送信機は、キーと、ノンスとしてのシーケンス番号と、平文での保護されたペイロードと、ヘッダと、シリアル番号と、付加認証データとしてのセキュリティ情報と、を使用して、暗号文を生成するようにさらに構成されている。
第１５の実装形態では、単独でまたは第１の実装形態から第１４の実装形態までの１つまたは複数と組み合わせて、送信機は、セキュリティアソシエーションに従って複数のキーからキーＫを選択するように構成されており、セキュリティアソシエーションは、プロトコルフレームのセキュリティ情報の内部に表されている。
いくつかの可能な実装形態によれば、車両内のバスベースの通信システムに参加するための、データリンク層上の受信機であって、受信機は、データリンク層上で、かつ送信機から、プロトコルに従ってプロトコルフレームを受信し、データリンク層上でのプロトコルフレームの真正性のレベルまたはデータセキュリティのレベルを示すように構成された指示を、プロトコルフレームから抽出するように構成されている。
第１の実装形態では、受信機は、プロトコルフレームからヘッダを抽出し、プロトコルフレームから保護されたペイロード部分を抽出し、ｋバイト長のキーにアクセスし、ヘッダの下流でプロトコルフレームからセキュリティタグを抽出し、キーと、ヘッダを含む付加真正性データと、セキュリティタグと、保護されたペイロードと、に基づいて、真正性指示を計算するようにさらに構成されており、真正性指示は、送信機から受信機に送信されるプロトコルフレームの真正性を、データリンク層上で検証するように構成されている。
第２の実装形態では、単独でまたは第１の実装形態と組み合わせて、受信機は、真正性指示が、送信機から受信機に送信されたプロトコルフレームの真正性を検証しなかった場合に、当該プロトコルフレームをドロップするようにさらに構成されており、オプションとして、このような真正性の欠如を上位のプロトコル層に示すように構成されている。
第３の実装形態では、単独でまたは第１の実装形態および第２の実装形態のうちの１つまたは複数と組み合わせて、バスベースの通信システムは、ブロードキャストベースのバスシステムであり、したがって、バスベースの通信システムの内部の全てのノードが、送信機によって通信されたプロトコルフレームを受信するように構成されている。
第４の実装形態では、単独でまたは第１の実装形態から第３の実装形態までの１つまたは複数と組み合わせて、指示は、プロトコルフレームに対するデータリンク層レベルでの認証を示すように構成された第１の指示を含む。
第５の実装形態では、単独でまたは第１の実装形態から第４の実装形態までの１つまたは複数と組み合わせて、指示は、プロトコルフレームに対するデータリンク層レベルでの認証およびデータセキュリティの両方を示すように構成された第２の指示を含む。
第６の実装形態では、単独でまたは第１の実装形態から第５の実装形態までの１つまたは複数と組み合わせて、指示、第１の指示、または第２の指示のうちの少なくとも１つは、プロトコルフレームのヘッダの一部である。
第７の実装形態では、単独でまたは第１の実装形態から第６の実装形態までの１つまたは複数と組み合わせて、指示、第１の指示、または第２の指示のうちの少なくとも１つは、ヘッダの内部のセキュリティ指示フラグまたはビットフィールドとして表される。
第８の実装形態では、単独でまたは第１の実装形態から第７の実装形態までの１つまたは複数と組み合わせて、受信機の認証された解読モードにおいて、受信機は、真正性指示が、送信機から受信機に送信されたプロトコルフレームの真正性を示す場合には、キーと、暗号文としての保護されたペイロード部分と、付加認証データと、を使用して、解読されたペイロードを上位のプロトコル層への出力ストリームとして生成するように構成されている。
第９の実装形態では、単独でまたは第１の実装形態から第８の実装形態までの１つまたは複数と組み合わせて、付加認証データは、ヘッダを含む。
第１０の実装形態では、単独でまたは第１の実装形態から第９の実装形態までの１つまたは複数と組み合わせて、受信機は、プロトコルフレームからｓｎバイトのシーケンス番号を抽出するようにさらに構成されている。
第１１の実装形態では、単独でまたは第１の実装形態から第１０の実装形態までの１つまたは複数と組み合わせて、付加認証データは、ヘッダと、シーケンス番号と、を含む。
第１２の実装形態では、単独でまたは第１の実装形態から第１１の実装形態までの１つまたは複数と組み合わせて、受信機の認証された解読モードにおいて、受信機は、真正性指示が、送信機から受信機に送信されたプロトコルフレームの真正性を示す場合であって、かつ受信機が、真正性指示を上位のプロトコル層に通知するように構成されている場合には、シーケンス番号と、キーと、暗号文としての保護されたペイロード部分と、付加認証データと、を使用して、解読されたペイロードを上位のプロトコル層への出力ストリームとして生成するように構成されている。
第１３の実装形態では、単独でまたは第１の実装形態から第１２の実装形態までの１つまたは複数と組み合わせて、付加認証データは、ヘッダと、シーケンス番号と、セキュリティ情報と、を含む。
第１４の実装形態では、単独でまたは第１の実装形態から第１３の実装形態までの１つまたは複数と組み合わせて、受信機は、ヘッダの下流でプロトコルフレームからセキュリティ情報を抽出するようにさらに構成されており、セキュリティ情報は、送信機と受信機との間の仮想チャネル、および、保護されたペイロード部分を保護するためにセキュリティアソシエーションに従って選択されるべきキーのうちの少なくとも１つを示す。
第１５の実装形態では、単独でまたは第１の実装形態から第１４の実装形態までの１つまたは複数と組み合わせて、受信機の認証および解読モードにおいて、受信機は、真正性指示が、送信機から受信機に送信されたプロトコルフレームの真正性を示す場合であって、かつ受信機が、真正性指示を上位のプロトコル層に通知するように構成されている場合には、キーと、シーケンス番号と、暗号文としての保護されたペイロード部分と、付加認証データと、を使用して、解読されたペイロードを上位のプロトコル層への出力ストリームとして生成するように構成されている。
いくつかの可能な実装形態によれば、車両内の通信ネットワークは、本明細書に記載のプロトコルフレームを使用して、本明細書に記載の送信機と本明細書に記載の受信機との間におけるトランスポートレベル層上での通信を提供するように構成されている。
本明細書において、添付の図面を参照しながら実装形態について説明する。
車両内のバスベースの通信システムを示すブロック図である。 本開示による、通信スタックと、データリンク層上の送信機と受信機と、の間の仮想チャネルとを示す図である。 セキュアゾーンの内部のノードと、セキュアゾーンの内部のセキュリティ層エンティティと、のグループ化を示す図である。さらに、セキュリティ層エンティティ間のセキュアチャネルが示されている。 車両において使用されている公知のプロトコルによるプロトコルフレームの一例を示す図である。 このようなプロトコルフレームの認証をデータリンク層レベルで提供する、プロトコルフレームの一例を示す図である。 このようなプロトコルの認証された暗号化をデータリンク層レベルで提供する、プロトコルフレームの一例を示す図である。 データリンク層レベルでのプロトコルフレームに対する総称的な認証および／またはデータセキュリティエンジンＳＡＤＳＥを示す図である。 データリンク層レベルでの送信機における認証のみのためのＳＡＤＳＥの入力変数および出力変数を示す図である。 データリンク層レベルでの受信機における認証のみのためのＳＡＤＳＥの入力変数および出力変数を示す図である。 データリンク層レベルでの送信機における認証された暗号化のためのＳＡＤＳＥの入力変数および出力変数を示す図である。 データリンク層レベルでの受信機における解読および認証のためのＳＡＤＳＥの入力変数および出力変数を示す図である。 ＣＡＮ標準によるプロトコルフレームを示す図である。
図１Ａは、複数のノードＮｏｄｅ１，Ｎｏｄｅ２，・・・，Ｎｏｄｅ ｎを接続している例示的なバスを示す。図１Ａの例によれば、バスは、２線式のバスシステムとして示されており、この２線式のバスシステムは、好適には２本の差動線路として実装可能である。当然、他のセットアップも考えられる。バスシステムは、オプションの終端抵抗Ｔ１，Ｔ２によって終端可能であり、このオプションの終端抵抗Ｔ１，Ｔ２は、典型的にはバスに沿った信号品質に作用するバスでの反射を軽減することを対象としたものであってよい。車両内のバスシステムの著名な例は、ＣＡＮ、ＣＡＮ－ＦＤ、ＣＡＮＸＬ、またはＬＩＮネットワークである。本開示は、ＣＡＮのバリエーションに焦点を当てているが、本開示の教示が他のバスシステムにも同様に適用可能であることは、当業者には明らかであろう。
図１Ａに示されているバスは、リング型のトポロジでも配置可能であることが理解されるであろう。リング型のトポロジでは、バスの両方の端部が１つのマスタユニット（図示せず）に供給され、それによってバスループを形成している。個々のノードＮｏｄｅ１，２，・・・，ｎは、前述のようにバスに結合される。
車内ネットワークまたは（図１Ａに示されているような）バスベースの通信システムは、車内ネットワークに対する要求を反映する特定の属性を有することが理解されるべきである。車内ネットワークは、センサまたはセンサの制御ユニットから上位レベルの制御ユニットに伝送されるデータフレームによって、制御ユニットへのセンサデータの通信を支援する。バスベースの通信ネットワークの個々のノード間または参加者間で通信されるデータフレームまたはプロトコルフレームのために、有用なプロトコルを使用することができる。
センサデータの受信に対する応答として、またはセンサデータの受信に応答して、センサの制御ユニットまたは上位レベルの制御ユニットは、バスに結合されたアクチュエータに所定のアクションを通信することができ、例えば、ブレーキアクチュエータに制動アクションを通信することができる。例えば、図１Ａの例では、Ｎｏｄｅ１は、ブレーキパドルがどのくらい押し付けられているかの角度を測定する角度センサ（図示せず）を表すことができる。この角度を、プロトコルフレームとして上位レベルのＥＣＵに、例えばＮｏｄｅ２に伝送することができる。角度値の受信に応答して、ＥＣＵは、ブレーキアクチュエータであるＮｏｄｅ ｎに１つまたは複数のバスフレームを送信することができる。ＥＣＵからブレーキアクチュエータに送信されるこれらのバスフレームは、制動アクションを引き起こすことができる。
制動アクションに関連するバス通信は、時間的にクリティカルであり、高速に伝送される必要があることは明らかであろう。このようなリアルタイムの要求は、標準通信ネットワークでは一般的ではない。
車内通信ネットワークは、典型的に、明確に定義された数のバス参加者を有し、これらのバス参加者は、デフォルトでは車両の寿命にわたって一定のままであり、しばらくの間、車両のアップグレードを無視する。同様に、個々のノード間の既存のリンク、ひいてはバスベースの通信システムのトポロジも、車両の寿命にわたって変更されない。標準コンピュータネットワークでは、そのような状況は非常に起こりそうにない。実際には、標準コンピュータネットワークでは、コンピュータネットワークの動作中にノードの追加または削除を可能にすることが要求されている。さらに、標準コンピュータネットワークにおける動作中に新しいリンクを提供すること、またはリンクを削除することができる。
車両機能を制御するバスベースの通信システムでは、バスを介して伝送されるプロトコルフレームの真正性を保証することが重要である。制動アクションを考慮すると、制御下で車両を駐車させる際には、緊急制動を引き起こす命令を、緩制動と取り間違えるべきではない。この目的のために、バスベースの通信システムの参加者間で通信されるプロトコルフレームの真正性を示すことが重要である。
バスベースの通信システムの参加者間で通信される時間的にクリティカルな命令の認証における上位のプロトコル層の関与を減らすために、データリンク層上でのプロトコルフレームの真正性を示すことが重要であることが理解されるであろう。
エンタテインメントシステムの増加に伴って、かつ今日利用可能となっている車車間通信の増加に伴って、悪意のある命令またはプロトコルフレームが通信システムに挿入される脆弱性が増加している。
したがって、悪意のあるプロトコルフレームの挿入を阻止するために、プロトコルフレームに対するデータセキュリティを提供することが重要である。プロトコルフレームの真正性を示すことに関して、データリンク層レベルでのデータセキュリティを提供することも魅力的である。このようにして、セキュリティ情報および／または真正性情報を提供する上位のプロトコル層または上位のプロトコル層のソフトウェアスタックの関与が不要となる。データセキュリティおよび真正性の機能を、プロトコル層上の送信機または受信機のようなハードウェア要素によって好適に支援することができることは、当業者には明らかであろう。換言すれば、データセキュリティおよび真正性の機能を、これらの機能がデータリンク層レベルで実装される場合に、データリンク層レベルの専用ハードウェアへとオフロードすることができる。
図１Ｂは、図１Ａに示されているようなバスベースの通信システムの参加者としてのＮｏｄｅ１およびＮｏｄｅ２を示す。Ｎｏｄｅ１とＮｏｄｅ２との間の通信は、十分に確立されたＯＳＩ－ＩＳＯ層モデルに従って分類することができる複数の異なる層を流れる。最下位レベルの層は、いわゆる物理層であり、Ｎｏｄｅ１およびＮｏｄｅ２に関してＰＨＹＳで示されている。ＯＳＩモデルにおけるそれぞれの層は、上位レベルから指令を受信し、各自のレベルにおいて何らかのアクションを実行し、下位レベルに要求を転送することによって下位レベルにおけるタスクをトリガすることができる。
物理層への命令は、ＰＨＹＳ層とデータリンク層との間の下向きの矢印によって示されているように、データリンク層から受信可能である。層の機能として、Ｎｏｄｅ１の物理層は、データを物理層上でＮｏｄｅ２に通信するためにＮｏｄｅ２へのコネクションまたはリンクを使用することができる。同様に、Ｎｏｄｅ１は、Ｎｏｄｅ１とＮｏｄｅ２との間の物理的なリンクを介してＮｏｄｅ２からデータを受信することができ、さらに、受信したデータを物理層の上にあるデータリンク層に転送することができる。この転送は、図１ＢのＮｏｄｅ１の物理層とデータリンク層との間の上向きの矢印によって示されている。Ｎｏｄｅ２におけるプロトコルフローは、Ｎｏｄｅ１に関して説明したものと同様である。
車両内の既存のバスベースの通信ネットワークの中には、ＯＳＩ－ＩＳＯモデルにおいて提案されているような物理層とデータリンク層との分離に従っていないものもある。この特殊な例を反映するために、図１Ｂには、物理層ＰＨＹＳおよびデータリンク層にわたって延在する送信機Ｓおよび受信機Ｒが示されている。
車両内のデータ通信の真正性に関する公知のコンセプトは、ＯＳＩ－ＩＳＯ層モデルの第７層のアプリケーション層において、図１ＢではそれぞれＮｏｄｅ１およびＮｏｄｅ２に関してＡｐｐ１，Ａｐｐ２として示されているソフトウェアスタックを使用して実装されている。ソフトウェアスタックＡｐｐ＠Ｎｏｄｅ１およびＡｐｐ＠Ｎｏｄｅ２を使用して２つ以上の参加者間で認証かつ／または保護された通信を示すために、Ｎｏｄｅ１とＮｏｄｅ２との間に仮想チャネルのコンセプトを導入することが好適であり得る。
ソフトウェアスタックを使用して車両内の車載ネットワークにセキュリティを提供するための一例は、ＡＵＴＯＳＡＲ標準に準拠したＳＥＣ ＯＣ（Secure OnBoard Communication）である。ＯＥＭがＮｏｄｅ１およびＮｏｄｅ２のソフトウェアスタックＡｐｐを指定して、Ｎｏｄｅ１およびＮｏｄｅ２のハードウェア実装に自由度を与えることが好適であり得る。トレードオフとして、ソフトウェアスタックを使用して真正性および／またはデータセキュリティを実装することにより、電子制御ユニット（ＥＣＵ）からアクチュエータへの命令に対するアクチュエータ応答についてのリアルタイムの要求が、もはや満たされなくなる可能性がある。なお、このアクチュエータは、図１Ａでは、バスベースの通信システムに参加しているＮｏｄｅ ｎとして示されている。例えば、－図１ＡではＮｏｄｅ２として示されている－制御ユニットＥＣＵから制動アクチュエータに、例えば図１ＡのＮｏｄｅ ｎに、プロトコルフレーム１００（図２Ａ～図２Ｃまたは図４において最良に見て取れる）として送信される制動命令について検討する。このような通信が、ソフトウェアスタックを使用して認証および安全化されるべきであった場合には、個々のノードに関する全ての層がこの安全化に関与することとなり、このことは、信頼できる制動動作のためには時間がかかりすぎる可能性がある。
ソフトウェアスタックによる真正性および／またはデータセキュリティのソリューションのさらなる欠点は、ソフトウェアスタックが適切に設計されていない可能性があるので、真正性および／またはセキュリティの機能が低下するか、またはそれどころか損なわれることさえあるという事実であり得る。
したがって、状況に応じて、真正性および／またはデータセキュリティに関する機能を、例えば図１ＢのＮｏｄｅ１またはＮｏｄｅ２のような通信システムへの個々の参加者の単一の層に限定することは魅力的である。真正性および／またはデータセキュリティの機能をデータリンク層に限定することにより、その他のプロトコル層がデータ完全性および／またはデータセキュリティ動作の一部によって占有されることが阻止される。
さらなる利益として、真正性が確立されていない可能性のあるプロトコルフレーム１００を、すでにデータリンク層上でドロップすることができる。つまり、プロトコルフレーム１００が送信機から受信機に送信されることが意図されていなかったことおよび／またはそのオリジナルの形式で受信機に到達しなかったことを、真正性テストが示した場合には、さらなる処理なしにそのプロトコルフレーム１００をドロップすることができる。したがって、バスベースの通信システムの１つの参加者を、データリンク層上の無効なまたは認証されていないフレーム１００によってフラッディングするという試みは、データリンク層上の当該１つのノードにしか影響を与えず、その一方で、上位のプロトコル層は、影響を受けないままでいることができる。真正性および／またはデータセキュリティに対するソフトウェアスタックベースのアプローチの場合であれば、真正性および／またはデータセキュリティの労力のそのような封じ込めは不可能であろう。
さらに、専用のハードウェア要素、すなわち、専用のハードウェアの一部として真正性および／またはデータセキュリティを実現するデータリンク層上の送信機および／またはデータリンク層上の受信機を使用することが好適である。このことは、バスの参加者、または参加者におけるソフトウェアアプリケーションＡｐｐが時間の経過に伴って変化する場合に必要とされるさらなる調査または適合を行うことなく、そのような構成ブロック－ＣＡＮバスのトランシーバを想定－を標準回路として使用することができるというさらなる利点を有するであろう。
プロトコルフレーム１００の以下の例では、データリンク層上で種々異なるレベルの認証および／またはデータセキュリティを実装することについて、図２Ａ～図２Ｃに関して説明する。
図１Ｃの左側は、バスベースの通信ネットワークを形成するためにバスに接続されているいくつかの例示的なノードＮｏｄｅ１，Ｎｏｄｅ２，Ｎｏｄｅ３，Ｎｏｄｅ４を示す。これらのノードのうちのいくつかは、セキュアゾーンＳＺの一部である。図１Ｃの例では、Ｎｏｄｅ２，Ｎｏｄｅ３，およびＮｏｄｅ４は、同一のセキュアゾーンＳＺにグループ化されているが、その一方で、Ｎｏｄｅ１は、セキュアゾーンＳＺの一部ではない。同一のセキュアゾーンＳＺにグループ化されているノード同士は、図３Ａ～図３Ｅに関してより詳細に説明されるように、認証されたモードで、またはそれどころか認証および暗号化されたモードで通信することができる。セキュアゾーンＳＺの一部を形成していないノードは、セキュアゾーンＳＺのノード間の通信をリスニングすることが可能であってよい。図１Ｃの例では、ＳＺの一部ではないＮｏｄｅ１は、Ｎｏｄｅ２と、Ｎｏｄｅ３と、Ｎｏｄｅ４と、の間の通信をリスニングすることができるが、セキュアゾーンＳＺのメンバーとしてこれらのノードに認証されたメッセージを送信することはできない。ＳＺの内部のノード間の通信が暗号化されている場合には、セキュアゾーンＳＺに属していないノードは、セキュアゾーンＳＺの内部で通信されるメッセージを解読することはできない。
図１Ｃの右側は、セキュアゾーンＳＺのコンセプトをさらに説明している。セキュアゾーンＳＺは、物理的なノードＮｏｄｅ２，Ｎｏｄｅ３およびＮｏｄｅ４にわたる論理的なオーバレイ－例えば、セキュリティ層－であると見なすことができる。セキュリティ層におけるセキュリティ層エンティティＳＬＥ１は、物理層上のＮｏｄｅ２に接続されており、セキュリティ層エンティティＳＬＥ２は、物理層上のＮｏｄｅ３に接続されており、セキュリティ層エンティティＳＬＥ３は、物理層上のＮｏｄｅ４に接続されている。図１Ｃに示されているバスの物理的なＮｏｄｅ１は、セキュアゾーンＳＺの一部ではない（図１Ｃの左側の図式において最良に見て取れる）が、この物理的なＮｏｄｅ１を、セキュリティ層の内部のセキュリティ層エンティティＳＬＥ ｎとして表すことができ、図１Ｃで選択された例では、このセキュリティ層エンティティＳＬＥ ｎは、物理層のＮｏｄｅ１に接続されている。
セキュリティ層エンティティＳＬＥ１，ＳＬＥ２およびＳＬＥ３のうちの個々のセキュリティ層エンティティ間の通信を、セキュアチャネルＳＣとして配置することは好適であり得る。セキュアチャネルＳＣは、ポイントツーポイントまたはポイントツーマルチポイントの単方向通信を提供する。セキュアチャネルＳＣを、図１Ｂに示されているようなユーザレベルでの仮想チャネルのデータリンク層表現として見なすことができることが理解されるであろう。
図１Ｃの右側は、セキュアゾーンＳＺの内部のセキュアチャネルＳＣのセットアップを示す。セキュアチャネルＳＣＡは、セキュリティ層エンティティＳＬＥ１からセキュリティ層エンティティＳＬＥ２，ＳＬＥ３への単方向通信を提供し、その一方で、セキュアチャネルＳＣＢは、セキュリティ層エンティティＳＬＥ２からセキュリティ層エンティティＳＬＥ１，ＳＬＥ３への単方向通信を提供し、その一方で、セキュアチャネルＳＣＣは、セキュリティ層エンティティＳＬＥ３からセキュリティ層エンティティＳＬＥ１，ＳＬＥ２への単方向通信を提供する。個々のセキュリティ層エンティティＳＬＥ間での双方向通信が必要とされるケースでは、少なくとも２つのセキュアチャネルＳＣが必要とされることとなる。図１Ａおよび図１Ｃに示されているバスベースの通信ネットワークは、ネットワークの内部のノードのうちの個々のノード間の通信に関して言えば、この通信ネットワークの認証という点と、この通信ネットワークのデータセキュリティ（すなわち、暗号化）プロパティという点と、の両方において静的であり得る。このような静的な認証の挙動または認証および暗号化の挙動の場合には、プロトコルフレームの複雑さを軽減することができ、使用されているセキュアチャネルに関する情報を使用して、このセキュアチャネルＳＣに対する認証のレベルまたは認証および暗号化のレベルを識別することを選択することができる。しかしながら、静的な認証および暗号化の挙動を伴うバスベースの通信ネットワークの個々のノード間の通信については、認証に関する、または認証および暗号化に関するフレキシビリティにおいてトレードオフが存在する。
図２Ａは、Ｎバイト（ただし、Ｎは整数）の全長を有するオリジナルのプロトコルフレーム１００を示す。プロトコルフレーム１００は、ヘッダＨと、ペイロードＰと、フレーム終了指示ＥＯＦと、を含むことができる。ヘッダＨは、ｈバイト（ただし、ｈはＮよりも小さい整数）の長さを有することができる。ペイロードＰは、ｐバイトの長さを有することができる。フレーム終了指示ＥＯＦは、ｅｏｆバイトの長さを有することができる。
図２Ａでは、ペイロードＰは、ヘッダＨの下流に示されており、フレーム終了部分ＥＯＦは、ヘッダＨの下流に、かつペイロードＰの下流に示されている。ヘッダＨの長さと、ペイロードＰの長さと、フレーム終了指示の長さと、の合計が、プロトコルフレーム１００のＮバイトの全長になることが理解されるであろう。さらに、個々の要素であるヘッダＨ、ペイロードＰ、またはＥＯＦのそれぞれの長さは、フルバイト長の公約数ではないビット長であってよいことが理解されるであろう。そのような場合、プロトコルフレームの全長は、Ｎバイトのままであってよいが、プロトコルフレーム１００の個々のセグメントは、サブバイトレベルの長さを有することができる。プロトコルによれば、プロトコルフレーム１００の全長が、バイト長の公約数ではないビット数であってもよいということをさらに明記しておくことができる。
ヘッダＨは、プロトコルフレーム１００の開始と、フレームの長さＮと、準拠しているプロトコルまたはプロトコルバリエーションと、を示すために使用可能である。
ヘッダＨ内では、プロトコルフレーム１００に関連する権利または優先度を示すことが可能である。そのようなオプションは、典型的にはプロトコル仕様に示されている。
プロトコル仕様は、所定のプロトコルフレームに対してデータリンク層レベルでの認証が提供されることを示す第１の指示を、フレームの内部でさらに提供することができる。代替的に、プロトコル仕様は、所定のプロトコルフレームに対してデータリンク層レベルでの認証およびデータセキュリティの両方が提供されることを示す第２の指示を、フレームの内部で提供することができる。状況に応じて、所与のフレームに対してデータリンク層レベルでの認証、またはデータリンク層レベルでの認証およびデータセキュリティの両方が提供されることを示すための総称的な指示を、プロトコルヘッダＨの内部で提供することが好適であり得る。両方のバリエーションのための総称的な指示は、ヘッダＨの内部で必要とされる指示がより少なくなるので、ヘッダＨの処理を容易にするために好適であり得る。ヘッダＨの内部で総称的な指示を使用した結果、ヘッダＨの処理が単純化されるトレードオフとして、フレーム１００に対してデータリンク層上のフルレベルでの認証およびデータ保護を示すためにフレーム１００の内部でさらなるスペースが必要とされる場合がある。
ヘッダＨの内部のペイロードタイプｐｔ指示は、車内ネットワークにおいて公知である。ペイロードタイプ指示は、フレームの内部でどのようなタイプのペイロードが伝送されているかを示すために好適であり得る。車内ネットワークでは、ブレーキアクチュエータに対する種々異なるペイロードタイプｐｔ、例えば、イーサネットフレーム、オリジナルＣＡＮフレーム、または制動命令を支援するフレームを、ヘッダＨのペイロードタイプ部分ｐｔを使用して示すことができる。当然、このような構造は、種々異なるタイプのフレームの処理を容易にするであろう。なぜなら、フレームをデータリンク層レベルで処理する際に、このフレームにおいてどのようなタイプのペイロードが伝送されているかが早期に明らかになるからである。
データリンクレベル層上での認証および暗号化に関する第１の指示、第２の指示、または総称的な指示を、専用のペイロードタイプｐｔとして実装することは好適であり得る。このようにすると、ペイロードタイプの公知のコンセプトは、所与のフレームに対して提供される認証および／またはデータセキュリティのレベルをさらに示すために拡張されることとなる。総称的な指示を、前述のように専用のペイロードタイプｐｔを使用して実装することを決定した場合には、フレーム１００に対してデータリンク層上のフルレベルでの認証およびデータ保護を示すためにフレームの内部でさらなるスペースが必要とされることのトレードオフとして、ヘッダＨの処理が単純化される。
真正性または真正性およびデータセキュリティのこのような指示は、所与のフレームに対する真正性または真正性およびデータセキュリティをソフトウェアスタックが提供する場合のように上位のプロトコル層が関与することなく実装可能であることが理解されるであろう。
さらなる代替策として、プロトコル仕様は、プロトコルフレーム１００の内部に、最適にはヘッダＨの内部に、新しいデータフィールドとして追加されるセキュリティ指示を導入することができる。前述のように、セキュリティ指示をヘッダＨに含めることにより、所与のフレーム１００に対してどのようなレベルの真正性および／またはセキュリティが適用されたかが明らかになる前に、必要とされるフレーム処理の労力が軽減される。状況に応じて、プロトコルは、総称的な指示の意味を伝達するセキュリティ指示を提供することができ、これにより、セキュリティ指示のために必要とされるスペースが低減されることとなる。このシナリオの場合、データフィールドとしてヘッダＨに追加される専用のセキュリティ指示における総称的な指示の情報を伝達するために、フレーム１００の内部の、最適にはヘッダＨの内部の、単一のビットフィールドで十分であろう。トレードオフとして、総称的な指示に関してすでに説明したように、所与のフレームに対してどのようなレベルの真正性およびデータセキュリティが適用されるかに関する完全な指示を得るために、さらなる情報が必要となる。
図２Ａでは、ペイロードＰは、ヘッダＨの下流に示されており、フレーム終了部分ＥＯＦは、ヘッダＨの下流に、かつペイロードＰの下流に示されている。上流・下流の関係性に関するこの取り決めは、本開示全体を通して使用される。
さらに、プロトコルにより、プロトコルフレーム１００のフレーム長Ｎを可変にすることが可能となることが考えられる。例えば、プロトコルフレーム１００の個々のインスタンスによって伝達される情報の量に応じて、全フレーム長Ｎを変化させることができる。
車両環境では、それぞれ異なるバリエーションのプロトコルに従っている旧型の装置と、最新の装置と、が同時に動作する可能性が高い。一例として、かなり旧型の装置、例えばＡＢＳセンサは、初期のバリエーションのプロトコル、例えばＣＡＮプロトコル（ＣＡＮは、Controller Area Networkの略称である）に従って通信している可能性があるが、その一方で、比較的最新の装置、例えばＬＩＤＡＲシステムは、ＣＡＮ－ＦＤ（ＣＡＮ－ＦＤは、Controller Area Network flexible-data rateである）標準を使用して、またはそれどころかＣＡＮＸＬ標準を使用して、電子制御ユニットと通信することができる。したがって、ヘッダＨ内で、種々異なるプロトコルタイプを示すことは有用であり得る。なぜなら、これは、個々のプロトコルフレーム１００に対して適用される真正性および／またはデータ保護のレベルにも影響を及ぼし得るからである。同様に、所与のフレームに対するデータリンク層レベルでの真正性および／またはデータセキュリティのレベルの両方を、ペイロードタイプ指示を使用して指示することが好適であり得る。この目的のために、第１の指示、第２の指示、総称的な指示およびセキュリティ指示を使用することができる。
このような環境の下では、ＮバイトまたはＮビットの合計フレーム長を、プロトコルフレーム１００のどこかに格納または符号化することが重要であり得る。フレーム長フラグをセットすることは、フレーム長をどのようにして符号化することができるかの１つのオプションであろう。このような情報をどのようにしてプロトコルフレーム１００に格納することができるかは、プロトコル仕様から取得可能である。
当技術分野で公知のように、したがって現時点ではこれ以上説明しないが、フレーム終了指示ｅｏｆは、エラーチェック情報をさらに含むことができる。
図２Ｂは、本開示によるプロトコルフレームの一例を示す。プロトコルフレーム１００は、図２Ａのオリジナルのプロトコルフレームと同様のヘッダＨを含むことができる。データリンク層レベルでの真正性および／またはデータセキュリティに関する第１の指示、第２の指示、総称的な指示、またはセキュリティ指示を含んでいるヘッダＨを有することが好適である。代替的に、ヘッダＨは、上述のように真正性および／またはデータセキュリティの側面を同様にカバーしているペイロードタイプｐｔを含むことができる。
図２Ｂのプロトコルフレーム１００は、上述のようにＮバイトまたはＮビットの長さを有する。標準のプロトコルフレームとは異なり、図２Ｂのフレームは、保護されたペイロード部分ＰＰを含む。保護されたペイロード部分ＰＰは、ｓｔバイトの長さを有することができるセキュリティタグＳｅｃＴａｇのための場所を空けるために短縮されている。本開示によるプロトコルフレーム１００は、オプションとして、ｓｉバイトのセキュリティ情報ＳｅｃＩｎｆ（ｓｉは、整数である）を含むことができる。限定するわけではないが、セキュリティ情報ＳｅｃＩｎｆをヘッダＨの一部として実装することができる。図２Ｂによるプロトコルフレームは、オプションとして、長さｓｎのシーケンス番号ＳＮをさらに含むことができる。状況に応じて、シーケンス番号ＳＮをヘッダＨ内に配置することが好適であり得る。このような配置では、誤ったシーケンス番号ＳＮを含んでいるフレームを、ヘッダＨの下流に配置されているシーケンス番号ＳＮを用いた場合よりも早期にドロップすることができる。限定するわけではないが、長さｓｔ、ｓｉ、ｓｎ、またはｐｐは、図２Ａに関して前述したようにフルバイト長の公約数であってもなくてもよい。
代替策として、短縮されたバージョンのシーケンス番号ＳＮを伝送することが重要であり得る。
当業者は、フレーム１００において如何なるシーケンス番号も送信しないというオプションも理解するであろう。このルートを選択した場合には、送信機および受信機の両方がシーケンス番号に関する共通の開始値を認識し、次いで、事前に定義されたカウントスキームに従って個々にカウントを行うことが必要である。このシーケンス番号は、秘密キーＫに関してさらに後述するように、典型的にはセキュリティアソシエーションに関連することができる。
セキュリティ情報ＳｅｃＩｎｆは、所与のフレームに対するデータリンク層レベルでの認証のレベルを示すことができる。代替的に、セキュリティ情報ＳｅｃＩｎｆは、所与のフレームに対するデータリンク層レベルでの認証およびデータセキュリティのレベルを示すことができる。
さらに、単純化されたセキュリティ情報ＳｅｃＩｎｆと組み合わせて、ヘッダＨの内部の、データリンク層レベルでの認証または暗号化の総称的な指示を使用することが可能である。同じことが、セキュリティ指示についても当てはまる。このような単純化されたセキュリティ情報ＳｅｃＩｎｆは、所与のフレームが認証されているのみであるか、または認証および暗号化されているかを示すためのものであり、その一方で、ヘッダの内部の総称的な指示は、上述のように、所与のフレームに対してある程度のレベルの認証またはデータセキュリティ、したがって暗号化が存在することを示すであろう。
認証もデータセキュリティも提供されていないフレーム１００の場合には、セキュリティ情報ＳｅｃＩｎｆまたは単純化されたセキュリティ情報を、所与のフレームに対して認証もデータセキュリティも提供されていないことを示す選択された値にセットすることができることが理解されるであろう。代替的に、ヘッダ内の総称的な指示またはセキュリティ指示が、所与のフレームに対する認証またはデータセキュリティが存在しないことをすでに示している場合には、プロトコル仕様により、セキュリティ情報ＳｅｃＩｎｆまたは単純化されたセキュリティ情報を省略することが可能となり得る。
セキュリティ情報ＳｅｃＩｎｆが、特定のフレーム１００に対して使用されるべきＳＡＤＳＥユニットの構成についての何らかの情報を含むことが好適であり得る。さらに、セキュリティ情報ＳｅｃＩｎｆが、図１Ｃの例示的なセキュアゾーンＳＺの内部のセキュリティ層エンティティＳＬＥ１，ＳＬＥ２およびＳＬＥ３の間のセキュアチャネルＳＣＡ，ＳＣＢ，ＳＣＣのようなセキュアチャネルについての何らかの情報を含むことが好適であり得る。静的な認証または静的な認証および暗号化のセットアップの場合には、セキュアチャネル情報を使用して、セキュリティ層エンティティＳＬＥ間で通信される所与のプロトコルフレーム１００の認証および暗号化のために使用されるキーＫを検索することができる。このような静的なセットアップにおける認証および暗号化のために必要とされるキーＫを検索するために、静的な認証挙動および暗号化挙動に関する総称的な指示、第１の指示および／または第２の指示を省略して、セキュアチャネル情報に依拠することを考慮することができる。実際には、認証のみが行われる状況、またはそこどころか暗号化も認証も行われない状況では、本明細書で概説したような静的な認証、または静的な認証および暗号化の場合には、いくつかのフレーム要素を省略することをさらに検討することができる。
セキュリティタグＳｅｃＴａｇは、プロトコルフレーム１００がデータリンク層レベルで送信機Ｓから受信機Ｒに伝送されることが意図されているという認証指示を表すことができる。セキュリティタグＳｅｃＴａｇにより、プロトコルフレーム１００が受信機Ｒに向かう途中で変更されたかどうかをさらにチェックすることが可能となる。
セキュリティタグＳｅｃＴａｇは、保護されたペイロード部分ＰＰの下流に示されているが、このセキュリティタグＳｅｃＴａｇは、限定するわけではないが、保護されたペイロード部分ＰＰの上流に配置されてもよいし、またはそれどころか標準ヘッダＨに組み込まれてもよい。
認証、暗号化および解読のためには秘密キーＫが必要であることが理解されるであろう。キーのデプロイは、以下のいくつかの理由から本開示の中心にはない。
第１に、自動車環境では、バスベースの通信システムの参加者の数が限られており、車両の寿命にわたってあまり変化しない。バス通信システムの全参加者に対して、長さｋの１つのキーＫを使用することが好適であり得る。
バス通信システムを介して通信可能に結合されている個々のノードがそれぞれ個々のキーＫを使用することが求められている場合には、この個々のキーを、車両の生産中にバスベースの通信システムのそれぞれのノードに格納することができる。したがって、それぞれ、Ｎｏｄｅ１とＮｏｄｅ２との間の通信のための第１のキーＫ１をＮｏｄｅ１およびＮｏｄｅ２に格納することができ、Ｎｏｄｅ１とＮｏｄｅ３との間の通信のための第２のキーＫ２をＮｏｄｅ１およびＮｏｄｅ３に格納することができ、以降も同様である。送信機Ｓおよび受信機Ｒが同じキーＫを使用すること、したがって、解読、暗号化、認証および検証が対称であることが仮定される。
システムの内部で２つ以上のキーＫが使用される場合には、認証に関与しているキーＫに関する情報を格納することが重要となり得、かつ／またはデータセキュリティを、オプションのセキュリティ情報フィールドＳｅｃＩｎｆにおいて格納または指示することができる。現在のプロトコルフレーム１００が、認証のみがなされたプロトコルフレームであるか、または認証および暗号化されたプロトコルフレーム１００であるかを、セキュリティ情報フィールドを使用して示すことはさらなるオプションである。当然、どのキーを使用すべきかに関する情報を、フレームの内部の他のデータフィールド、例えば仮想ＣＡＮ ＩＤ、ペイロードタイプｐｔ、または受信フィールドを使用して表すこともできる。
車両の寿命がかなり長いことを考慮すると、ネットワークの内部の選択されたノード間の通信を保護するか、または認証および保護する２つ以上のキーＫを有することが望ましい場合がある。より正確には、車両の寿命中にキーを変更することが望まれる。通信するノードにおいて２つ以上のキーを導入し、これらのノードが認証およびデータセキュリティのために使用されるキーを変更することができるようにすることが好適であり得る。認証および／または暗号化のためのキーをこのように変更するためには、現在使用されているキーに関する何らかの情報が必要である。現在使用されているキーに関するこのような情報を、セキュリティアソシエーションと称することとする。セキュリティアソシエーションは、好適には、ヘッダＨ、セキュリティ情報ＳｅｃＩｎｆ、または単純化されたセキュリティ情報の内部に格納可能である。プロトコル仕様により、データリンク層レベルでの認証またはデータ保護が行われないフレームに対して、セキュリティアソシエーションを特別な値にセットすることが可能となり得る。代替的に、プロトコル仕様により、そのような環境の下ではセキュリティアソシエーションを省略することが可能となり得る。
フィールドシーケンス番号ＳＮは、プロトコルフレーム１００におけるさらなるオプションの要素である。シーケンス番号ＳＮは、一度だけ使用される整数であり、ノンスとも称される。シーケンス番号ＳＮがリスニングパーティに知られないように変化する場合には、リプレイ攻撃の成功を阻止するために役立つ。ＡＵＴＯＳＡＲ標準は、リプレイ攻撃を阻止するためにそのフレッシュネス値を用いる同様のコンセプトを提案している。
後述するＳＡＤＳＥアルゴリズムのいくつかは、特定の長さのノンスを要求する場合があることが理解されるであろう。したがって、状況に応じて、シーケンス番号ＳＮからノンスＮを導出することが重要であり得る。
データリンク層上での認証および／またはデータセキュリティの最も簡単な実装形態として、リプレイ保護が必要とされる場合に、シーケンス番号ＳＮを含むフレームを用いて、認証のみを行うスキームを実施することができる。このような保護が必要とされない場合には、シーケンス番号ＳＮを省略することができ、これにより、プロトコルフレーム１００の内部の比較的大きい保護されたペイロード部分ＰＰを可能にすることができる。
状況に応じて、システムの内部において認証のために１つのキーＫだけを使用すると決定することができ、その場合には、使用されるべき複数の異なるキーＫ１，Ｋ２，Ｋ３，・・・，ＫＮに関するこのような情報を含んでいるフィールドセキュリティ情報を省略することができ、これにより、比較的大きい保護されたペイロード部分ＰＰを可能にすることができる。
複数の異なるキーＫ１，Ｋ２，Ｋ３，・・・，ＫＮも、リプレイ保護もどちらも必要とされない場合には、フィールドシーケンス番号ＳＮおよびセキュリティ情報ＳｅｃＩｎｆを省略することができ、これにより、図２Ａに示されているプロトコルフレームに比べてさらに拡大された保護されたペイロード部分ＰＰを可能にすることができ、この際、セキュリティタグＳｅｃＴａｇだけが、保護されたペイロードフィールドＰＰを標準のプロトコルフレームに比べて縮小させている。
図２Ｃは、本開示による認証および暗号化されたプロトコルフレーム１００を示す。図２Ｃのプロトコルフレーム１００は、ヘッダＨと、フレーム終了指示ＥＯＦと、セキュリティタグＳｅｃＴａｇと、オプションのフィールドシーケンス番号ＳＮと、図２Ｂに関して説明したオプションのセキュリティ情報ＳｅｃＩｎｆと、を含む。図２Ｃのプロトコルフレームは、図２Ａおよび図２Ｂのプロトコルフレームと同じ長さである。前述のように、個々のフレーム要素であるヘッダＨと、オプションのシーケンス番号ＳＮと、合計フレーム長Ｎと、は、任意の整数のバイトであってもよいし、またはフルバイト長の公約数ではない任意の他の長さであってもよい。
図２Ｃのプロトコルフレーム１００は、保護されたペイロードＰＰの代わりに、保護されたペイロードＰＰの暗号文ｃｉｐｈｅｒ｛ＰＰ｝を含む。図２Ｃのプロトコルフレームは、図２Ａおよび図２Ｂのプロトコルフレームと同じ長さである。前述のように、個々のフレーム要素であるヘッダＨと、オプションのシーケンス番号ＳＮと、合計フレーム長Ｎと、は、任意の整数のバイトであってもよいし、またはフルバイト長の公約数ではない任意の他の長さであってもよい。プロトコルフレーム１００に対する真正性および／またはデータセキュリティ保護をデータリンク層レベルで実施する１つの好適な手法は、今から図３Ａ～図３Ｅを参照してより詳細に説明するように、ＳＡＤＳＥとも称され、かつハードウェアブロックとして実施される、いわゆる対称的な認証および／またはデータセキュリティエンジン（Symmetric authentication and/or data security engines）を使用することである。
図３Ａは、ＳＡＤＳＥのための入力値および出力値を示す。ＳＡＤＳＥの入力変数および出力変数の名称は、暗号に関する文献におけるブロック暗号モードに対して確立された命名規則に従っている。ＳＡＤＳＥは、真正性のみのＡＯモードで動作してもよいし、または認証された暗号化（Authenticated Encryption）モードＡＥで動作してもよいことが理解されるであろう。ＳＡＤＳＥは、秘密キーＫと、オプションのノンスＮと、ｌｅ文字長の入力ストリームＰと、付加認証データＡＡＤと、を入力として受信する。キーＫは、好適には、所定の長さの、例えば１２８、１９２、または２５６ビットの対称キーである。前述のように、キーの配布は、本開示の焦点にはない。実際には、ＩＥＥＥ８０２．１Ｘ－２０１０において定義されたＭＡＣｓｅｃキー共有のような、対応するスキームが公知である。オプションのノンスＮは、典型的には、１回だけ使用される整数値である。状況に応じて、２つ以上のプロトコルフレーム１００に対して同一のＮの値を有することを決定してもよい。
入力ストリームＰは、ＳＡＤＳＥの動作モードに応じて異なる用途を有する。さらに後述するように、付加認証データＡＡＤは、認証において使用されるさらなるデータのうちのいくつかのビットを含む。
ＳＡＤＳＥは、ｌｅ文字長の出力ストリームを提供し、さらにタグＴを出力することができるか、または代替的に、認証指示ＡＩを直接的に出力することができる。長さｌｅの出力ストリームは、ＳＡＤＳＥの動作モードに応じて異なる用途および意味を有する。
タグＴは、ＳＡＤＳＥの使用されている入力変数に基づいて計算され、上で定義したセキュリティタグＳｅｃＴａｇの再計算であると考えることができる。状況に応じて、ＳＡＤＳＥが、プロトコルフレーム１００の内部のセキュリティタグＳｅｃＴａｇと、新たに再計算されたタグＴと、の比較結果を直接的に出力することが好適であり得る。この比較結果を、真正性指示ＡＩによって表すことができる。すなわち、真正性情報ＡＩは、プロトコルフレーム１００が、指定された送信機Ｓから所与の受信機Ｒ（両方とも典型的にはヘッダＨ内に記載されている）に送信されることが意図されていたかどうかを示す。真正性指示ＡＩは、プロトコルフレーム１００がそのオリジナルの形式にあるかどうかをさらに示す。
図３Ａから見て取れるように、ＳＡＤＳＥへのノンスＮの入力として、オプションのシーケンス番号ＳＮを使用することを選択することができる。このことは、前述のように、シーケンス番号ＳＮからノンスＮを導出することを含むことができる。当然、ノンスＮを導出するためにシーケンス番号ＳＮを使用することにより、ＳＡＤＳＥを動作させるために必要とされる労力が単純化されるであろう。なぜなら、乱数発生器は、ＳＡＤＳＥを実装する回路の複雑さを増大させるからである。シーケンス番号ＳＮを、ノンスＮとして有用なものにするために、シーケンス番号ＳＮのために必要とされるサイズを推定することが重要である。このことは、シーケンス番号ＳＮを実装するカウンタが、カウンタの最大値に到達した後に再びその開始値からカウントを開始したときに、所与のＳＮの値が再利用されるまでにどのくらいの時間がかかるかという質問に答えることである。
－これを推定する目的で－２０４８バイトの最大可能ペイロードと、２０バイトの最小ペイロードと、からなる車内ネットワークにおけるＣＡＮ ＸＬフレーム（図４において最良に見て取れる）について検討する。ノンスＮとしてさらに機能するシリアル番号ＳＮを実装する３２ビット、３７ビット、４４ビットおよび６４ビットのカウンタ長について検討する。
そのような最大ペイロードフレームは、ヘッダ情報の１９ビットと、ペイロードおよびＣＲＣ情報の１６４３５ビットと、肯定応答情報およびＥＯＦ情報の２６ビットと、からなるであろう。ネットワークの内部の典型的なボーレートでは、フルフレームが通信されるには１．７ｍｓかかるであろう。その代わりに、２０バイトのペイロードを有する短いフレームは、より高速に通信されるであろう。
以下の推定では、３つのシナリオについて、すなわち、Ａ）単一のチャネルに対して、このチャネル上の最大可能トラフィックにおいて、ノンスＮを導出するためにカウンタＳＮを使用するというシナリオ、Ｂ）ラウンドロビンアプローチにおいて５１２チャネルを介して通信が分配されることを考慮して、それぞれのチャネルが個々のシーケンス番号ＳＮを有し、これらの個々のシーケンス番号ＳＮからノンスＮが導出されるというシナリオ、およびＣ）最大可能トラフィックのわずか３０％を有する１つのチャネルに対して、ノンスＮとしてカウンタＳＮを使用するというシナリオについて検討する。この推定結果は、以下に掲載されるテーブルから見て取ることができる。
シリアル番号ＳＮをカウンタとして実装する場合には、３２ビットの長さは、いくつかのシナリオでは短すぎることが理解されるであろう。当然、シナリオＡおよびＣは、自動車の寿命を考慮すると十分ではないであろう。
同様に、シーケンス番号をノンスＮとして実装するカウンタの場合の３７ビットのビット長は、シナリオＡおよびＣにとっては十分ではない。なぜなら、シナリオＡにおける短いフレームの場合の０．５年は、自動車の寿命を考慮すると短すぎるからである。同じことが、シナリオＣによる短いフレームの場合の１．５年にも当てはまる。
これに対して、４４ビットまたは６４ビットのカウンタビット長は、３つのシナリオ全てに関する短いフレームおよび長いフレームにとって十分であると思われる。実際には、時間スパンの一部は、非常に長くなっているので、実際の値が表されておらず、ダッシュのみによって示されている。
Figure 2023523883000002
図３Ｂを次に参照して、送信機Ｓでの認証のみのモードＡＯにおけるＳＡＤＳＥについて、すなわち、図２Ａによるプロトコルフレーム１００を認証する場合について検討する。このモードでは、長さｌｅの入力ストリームは使用されない。キーＫの使用は、前述と同様である。ＳＡＤＳＥは、シーケンス番号ＳＮと、付加認証データＡＡＤと、を入力としてさらに受信する。
付加認証データＡＡＤは、簡単に言えば、ヘッダＨから始まって保護されたペイロード部分ＰＰに至るまでの、かつ保護されたペイロード部分ＰＰを含む、プロトコルフレーム１００の全ての情報を含む。リプレイ保護が必要とされない場合には、プロトコルフレーム１００は、図２Ｂと組み合わせて上述したようにシーケンス番号ＳＮを含まなくてもよい。ＳＮがセットされていない結果として、ノンスＮを、以前に使用された値のままにしておくことができるか、またはゼロもしくは任意の他の好適な値にセットすることができる。当然、ノンスＮをセットするためのルールは、送信機Ｓと受信機Ｒとで同一でなければならない。
送信機Ｓによってコンパイルされたフレームは、送信機Ｓによってコンパイルされたフレーム１００のための認証のレベルを示すために、前述のような総称的な指示、第１の指示および／またはセキュリティ指示を含むことができることが理解されるであろう。
バスベースの通信システムの内部において秘密キーとして１つの総称キーＫだけが使用される場合には、プロトコルフレーム１００は、図２Ｂに関して説明したようにセキュリティ情報ＳｅｃＩｎｆフィールドを含まなくてもよい。
図２Ｂに関してすでに説明したように、リプレイ保護が必要とされず、バスベースの通信システムにおいて総称キーＫが使用される状況では、シーケンス番号ＳＮおよびセキュリティ情報ＳｅｃＩｎｆフィールドを省略することができる。上述のように、ノンスＮを、以前に使用された値のままにしておくことができるか、またはゼロもしくは任意の他の好適な値にセットすることができる。この場合も、ノンスＮをセットするためのルールは、所与のプロトコルフレーム１００を認証および／または安全化するために送信機Ｓと受信機Ｒとで同一でなければならない。
送信機Ｓでの認証のみのモードＡＯにおいて、ＳＡＤＳＥは、キーＫと、ノンスＮと、付加認証データＡＡＤと、を使用して計算されたタグＴを出力する。タグＴは、セキュリティタグＳｅｃＴａｇとしてプロトコルフレーム１００に組み込まれ、それによって認証されたプロトコルフレーム１００を生成することができる。
図３Ｃを次に参照して、データリンク層レベルでの受信機Ｒでの認証のみのモードにおけるＳＡＤＳＥについて検討する。受信機Ｒでの認証のみのモードは、受信機Ｒにおいて受信したプロトコルフレーム１００を、送信機Ｓから受信機に送信されることが意図されたオリジナルのプロトコルフレームとして認証する。換言すれば、受信機Ｒは、図２Ａによるプロトコルフレーム１００を認証する。このモードでは、セキュリティタグが、図３Ａの入力ストリームＰの代わりとなるタグＴとして使用される。キーＫおよびシーケンス番号ＳＮの使用は、前述と同様である。
受信機での認証のみのモードＡＯにおいて、付加認証データＡＡＤは、ヘッダＨから始まって保護されたペイロード部分ＰＰに至るまでの、かつ保護されたペイロード部分ＰＰを含む、プロトコルフレーム１００の全ての情報を含む。リプレイ保護が必要とされない場合には、プロトコルフレーム１００は、図２Ｂと組み合わせて上述したようにシーケンス番号ＳＮを含まなくてもよい。ＳＮがセットされていない結果として、ノンスＮを、以前に使用された値のままにしておくことができるか、またはゼロもしくは任意の他の好適な値にセットすることができる。当然、ノンスＮをセットするためのルールは、送信機Ｓと受信機Ｒとで同一でなければならない。
受信機Ｒは、プロトコルフレームから指示を抽出するように構成されている。この指示は、受信機Ｒにおいて受信されるフレーム１００のための認証のレベルを示すために、前述のような総称的な指示、第１の指示および／またはセキュリティ指示として実装可能である。
バスベースの通信システムの内部において秘密キーとして１つの総称キーＫだけが使用される場合には、プロトコルフレーム１００は、図２Ｂに関して説明したようにセキュリティ情報ＳｅｃＩｎｆフィールドを含まなくてもよい。
図２Ｂに関してすでに説明したように、リプレイ保護が必要とされず、バスベースの通信システムにおいて総称キーＫが使用される状況では、シーケンス番号ＳＮおよびセキュリティ情報ＳｅｃＩｎｆフィールドを省略することができる。上述のように、ノンスＮを、以前に使用された値のままにしておくことができるか、またはゼロもしくは任意の他の好適な値にセットすることができる。この場合も、ノンスＮをセットするためのルールは、所与のプロトコルフレーム１００を認証および／または安全化するために送信機Ｓと受信機Ｒとで同一でなければならない。
受信機Ｒでの認証のみのモードＡＯにおいて、ＳＡＤＳＥは、キーＫと、ノンスＮと、付加認証データＡＡＤと、を使用して計算されたタグＴ’を出力する。タグＴ’は、送信機Ｓにおいて生成されたセキュリティタグＳｅｃＴａｇの再計算である。
送信機Ｓにおいて計算されたプロトコルフレーム１００の内部のセキュリティタグＳｅｃＴａｇと、受信機Ｒにおいて新たに計算されたタグＴ’と、を比較することにより、受信機Ｒにおいて受信されたプロトコルフレーム１００が、送信機Ｓから受信機Ｒに送信されることを意図したものであるかどうかを認証することが可能となり、さらに、プロトコルフレーム１００がそのオリジナルの形式にあるかどうかを認証することが可能となる。
ＳＡＤＳＥが、新たに計算されたタグＴ’とプロトコルフレーム１００の内部のセキュリティタグＳｅｃＴａｇとを比較した結果に相当する真正性指示ＡＩを、直接的に出力することは好適であり得る。セキュリティタグＳｅｃＴａｇがＳＡＤＳＥに入力されている場合には、この比較に関する全ての情報を、ＳＡＤＳＥが利用することが可能である。
ＡＥモードとも称されるＳＡＤＳＥの認証された暗号化モードについて検討する。
図３Ｄを次に参照すると、送信機ＳにおけるＳＡＤＳＥのためのＡＥモードが説明されている。前述のように、ＳＡＤＳＥは、キーＫと、シーケンス番号ＳＮと、を入力として受信する。保護されたペイロード部分ＰＰが、長さｌｅの入力ストリームの代わりとなる。保護されたペイロード部分ＰＰが、平文として入力されていることに留意されたい。
送信機ＳでのＡＥモードにおいて、付加認証データＡＡＤは、ヘッダＨと、オプションのセキュリティ情報ＳｅｃＩｎｆと、を含む。
送信機Ｓによってコンパイルされたフレームは、送信機Ｓによってコンパイルされたフレーム１００のための認証およびデータ保護のレベルを示すために、前述のような総称的な指示、第１の指示、第２の指示および／またはセキュリティ指示を含むことができることが理解されるであろう。
リプレイ保護が必要とされない場合には、プロトコルフレーム１００は、図２Ｂと組み合わせて上述したようにシーケンス番号ＳＮを含まなくてもよい。ＳＮがセットされていない結果として、ノンスＮを、以前に使用された値のままにしておくことができるか、またはゼロもしくは任意の他の好適な値にセットすることができる。当然、ノンスＮをセットするためのルールは、送信機Ｓと受信機Ｒとで同一でなければならない。
バスベースの通信システムの内部において秘密キーとして１つの総称キーＫだけが使用される場合には、プロトコルフレーム１００は、図２Ｂに関して説明したようにセキュリティ情報ＳｅｃＩｎｆフィールドを含まなくてもよい。
この場合も、リプレイ保護が必要とされず、バスベースの通信システムにおいて総称キーＫが使用される状況では、シーケンス番号ＳＮおよびセキュリティ情報ＳｅｃＩｎｆフィールドを省略することができる。上述のように、ノンスＮを、以前に使用された値のままにしておくことができるか、またはゼロもしくは任意の他の好適な値にセットすることができる。ノンスＮをセットするためのルールが、所与のプロトコルフレーム１００を認証および／または安全化するために送信機Ｓと受信機Ｒとで同一でなければならないことを思い出されたい。
送信機ＳでのＡＥモードにおいて、ＳＡＤＳＥは、保護されたペイロードＰＰの暗号化されたバージョンである暗号文ｃｉｐｈｅｒ｛保護されたペイロードＰＰ｝を、長さｌｅの出力ストリームＣとして出力する。ＳＡＤＳＥは、ノンスＮと、保護されたペイロードＰＰと、付加認証データＡＡＤと、に基づいて暗号文ｃｉｐｈｅｒ｛保護されたペイロードＰＰ｝を生成する。
送信機ＳでのＡＥモードにおいて、ＳＡＤＳＥは、キーＫと、ノンスＮと、付加認証データＡＡＤと、を使用して計算されたセキュリティタグＳｅｃＴａｇをさらに出力する。セキュリティタグＳｅｃＴａｇは、プロトコルフレーム１００に組み込まれ、それによって図２Ｂに関して説明したようなプロトコルフレームをもたらすことができる。図３Ｂおよび図３Ｃに関して上述したように、プロトコルフレーム１００が、送信機Ｓから受信機に送信されることを意図したものであることを認証するために、さらに、プロトコルフレーム１００がそのオリジナルの形式にあるかどうかを認証するために、セキュリティタグＳｅｃＴａｇを使用することができる。
送信機Ｓにおいて、保護されたペイロードＰＰを出力暗号文ｃｉｐｈｅｒ｛ＰＰ｝によって置き換えて、プロトコルフレーム１００にセキュリティタグＳｅｃＴａｇを追加することにより、図２Ｃに関して説明したような認証および暗号化されたプロトコルフレームがもたらされる。
図３Ｅを次に参照すると、受信機ＲにおけるＳＡＤＳＥのためのＡＥモードが説明されている。前述のように、ＳＡＤＳＥは、キーＫと、ノンスＮと、を入力として受信する。受信機ＲのＡＥモードにおいて、保護されたペイロード部分の暗号文ｃｉｐｈｅｒ｛ＰＰ｝が、長さｌｅの入力ストリームの代わりとなる。保護されたペイロードの暗号文ｃｉｐｈｅｒ｛ＰＰ｝が、同一の長さの保護されたペイロード部分ＰＰの暗号化されたバージョンであることに留意されたい。
受信機ＲでのＡＥモードにおいて、付加認証データＡＡＤは、ヘッダＨから始まって保護されたペイロード部分ＰＰに至るまでの、ただし保護されたペイロード部分ＰＰを含まない、プロトコルフレーム１００の全ての情報を含む。したがって、図２Ｂで説明されるプロトコルフレーム１００によれば、付加認証データＡＡＤは、ヘッダＨと、オプションのセキュリティ情報ＳｅｃＩｎｆと、を含むことができる。
リプレイ保護が必要とされない場合には、プロトコルフレーム１００は、図２Ｂと組み合わせて上述したようにシーケンス番号ＳＮを含まなくてもよい。ＳＮがセットされていない結果として、ノンスＮを、以前に使用された値のままにしておくことができるか、またはゼロもしくは任意の他の好適な値にセットすることができる。当然、ノンスＮをセットするためのルールは、送信機Ｓと受信機Ｒとで同一でなければならない。
受信機Ｒは、プロトコルフレームから指示を抽出するように構成されている。この指示は、送信機Ｓにおいて受信されるフレーム１００のための認証およびデータ保護のレベルを示すために、前述のような総称的な指示、第１の指示、ペイロードタイプおよび／またはセキュリティ指示として実装可能である。
バスベースの通信システムの内部において秘密キーとして１つの総称キーＫだけが使用される場合には、プロトコルフレーム１００は、図２Ｂに関して説明したようにセキュリティ情報ＳｅｃＩｎｆフィールドを含まなくてもよい。
この場合も、リプレイ保護が必要とされず、バスベースの通信システムにおいて総称キーＫが使用される状況では、シーケンス番号ＳＮおよびセキュリティ情報ＳｅｃＩｎｆフィールドを省略することができる。上述のように、ノンスＮを、以前に使用された値のままにしておくことができるか、またはゼロもしくは任意の他の好適な値にセットすることができる。ノンスＮをセットするためのルールが、所与のプロトコルフレーム１００を認証および／または安全化するために送信機Ｓと受信機Ｒとで同一でなければならないことを思い出されたい。
受信機ＲでのＡＥモードにおいて、ＳＡＤＳＥは、保護されたペイロード部分ＰＰを、長さｌｅの出力ストリームＣとして出力する。ＳＡＤＳＥは、ノンスＮとしてのオプションのシーケンス番号ＳＮと、暗号文ｃｉｐｈｅｒ｛ＰＰ｝と、付加認証データＡＡＤと、に基づいて、暗号文ｃｉｐｈｅｒ｛ＰＰ｝の解読されたバージョンを生成する。
受信機ＲでのＡＥモードにおいて、ＳＡＤＳＥは、キーＫと、ノンスＮとしてのオプションのシーケンス番号と、付加認証データＡＡＤと、を使用して計算されたタグＴ’を出力する。タグＴ’は、送信機Ｓにおいて生成されたセキュリティタグＳｅｃＴａｇの再計算である。
送信機Ｓにおいて計算されたプロトコルフレーム１００の内部のセキュリティタグＳｅｃＴａｇと、受信機Ｒにおいて新たに計算されたタグＴ’と、を比較することにより、受信機Ｒにおいて受信されたプロトコルフレーム１００が、送信機Ｓから受信機Ｒに送信されることを意図したものであるかどうかを認証することが可能となり、さらに、プロトコルフレーム１００がそのオリジナルの形式にあるかどうかを認証することが可能となる。
ＳＡＤＳＥが、新たに計算されたタグＴ’とプロトコルフレーム１００の内部のセキュリティタグＳｅｃＴａｇとを比較した結果に相当する真正性指示ＡＩを、直接的に出力することは好適であり得る。しかしながら、このために、セキュリティタグＳｅｃＴａｇがＳＡＤＳＥにアクセス可能であることが必要とされるであろう（図３Ｅには図示せず）。
本開示によるＳＡＤＳＥを実装するための１つの可能な手法は、ブロック暗号モードであろう。このようなブロック暗号モードの著名な一例は、ＡＥＳガロアカウンタモードである。
ＡＥＳ－ＧＣＭの場合、ＡＥＳ－ＧＣＭの入力値および出力値のためのそれぞれのビット長に関して、米国の国立標準技術研究所であるＮＩＳＴによる推奨が存在する。テーブル１には、これらのパラメータが、認証のみのモードＡＯに関してまとめられている。
Figure 2023523883000003
認証のみのモードＡＯの場合には、ｌｅ文字の平文ストリームは使用されず、平文ストリームとしての保護されたペイロードＰＰにわたる対応する暗号文も同様であり、このことは、図３Ｂおよび図３Ｃに関するＳＡＤＳＥのＡＯモードについての説明に対応している。
付加認証データＡＡＤに関して、１２８＊ａビットの長さは、本開示のＳＡＤＳＥを実装するＡＥＳ－ＧＣＭモードの性能を最適化するために１２８ビットの整数倍を選択すべきであることを示す。１２８ビットの倍数の到達は、好適にはゼロパディングを用いることによって達成可能である。カウンタＣＴＲは、ＡＥＳ－ＧＣＭの内部変数であり、ＡＯモードでは使用されないので完全性を期すために掲載されている。
テーブル２は、ＳＡＤＳＥを実装するＡＥＳ－ＧＣＭの入力パラメータおよび出力パラメータについてのそれぞれのビット長をまとめたものである。
Figure 2023523883000004
テーブル１の認証のみのＡＯモードのパラメータとは異なり、認証された暗号化モードＡＥは、３２ビット値として実装されたカウンタを使用する。
暗号文ｃｉｐｈｅｒ｛ＰＰ｝および付加認証データＡＡＤは、ＳＡＤＳＥを実装するＡＥＳ－ＧＣＭの性能を最適化するために１２８ビット長の倍数であるべきである。そのようなビット長のゼロパディングを達成することは、好適なオプションである。
図４は、ＣＡＮ標準によるプロトコルフレームを示す。ＣＡＮフレームは、１１ビットの調停フィールドと、その後に続く７ビットのコントロールフィールドと、によって形成されるヘッダＨから始まる。調停フィールドおよびコントロールフィールドの両方は、図２Ａ～図２Ｃによる本開示のプロトコルフレーム１００に関するオプションとしてすでに説明したように、フルバイト長との公約数を有さないビット長のＣＡＮフレームの一部である。調停フィールドは、前述のＣＡＮ標準のバリエーションであるＣＡＮ標準およびＣＡＮ－ＦＤ標準によれば、２９ビットからなることができることに留意されたい。
８バイトのデータフィールドは、図２Ａによるオリジナルのプロトコルフレーム１００のペイロードＰに相当する。１５ビットのＣＲＣフィールドは、確認応答（Ａｃｋ）スロットビットおよび確認応答（Ａｃｋ）デリミタビットと７ビットのフレーム終了と一緒に、図２Ａ～図２Ｃに関して説明したプロトコルフレームのフレーム終了部分ＥＯＦに相当する。
ＡＥモードにおいて、ＣＡＮネットワークを介して１つの対称キーＫを使用して、ＡＥＳ－ＧＣＭ暗号モードとして実装されたＳＡＤＳＥコンセプトを適合させることが望まれる場合には、オリジナルのペイロードＰのうちの２バイトをシーケンス番号ＳＮとして使用することができ、さらなる２バイトをセキュリティタグＳｅｃＴａｇとして使用することができ、これにより、保護されるペイロード部分ＰＰのために合計４バイトが残される。
シーケンス番号ＳＮを、オリジナルのペイロードＰの最初の２バイトとしてセットすることが好適であり得る。なぜなら、２つのシーケンス番号バイトがオリジナルのペイロード部分Ｐのさらに下流にシフトされているケースよりも早期に、シーケンス番号の誤りが検出されることとなるからである。
同様に、セキュリティタグＳｅｃＴａｇを、保護されたペイロードＰＰの終了に向かって移動させることにより、保護されたペイロード部分がセキュリティタグＳｅｃＴａｇによってセグメント化されることを阻止するであろう。セグメント化されれば、ＣＡＮフレームの構文解析がより複雑になることであろう。代替策として、ＳｅｃＴａｇおよびシーケンス番号ＳＮの両方を、保護されたペイロード部分ＰＰの開始にシフトさせることができる。
このようなアプローチによって、オリジナルのペイロード容量Ｐの５０％を維持しながら、リプレイ攻撃に対する保護が達成される。
テーブル３は、ＣＡＮシステムの内部において１つの総称キーＫを用いるＡＥＳ－ＧＣＭモードに関して、キーサイズが１２８ビットであって、かつシーケンス番号ＳＮが２バイトである場合について、ＣＡＮフレームにセキュリティタグＳｅｃＴａｇおよびシーケンス番号ＳＮを含めたときの、認証のみのモードＡＯについての入力パラメータ長および出力パラメータ長をまとめたものである。
Figure 2023523883000005
図４の例では、シーケンス番号は、１６ビットに相当する２バイトのサイズを有する。キーＫのキー長は、１２８ビットである。付加認証データは、１８ビットの全長を有するヘッダと、３２ビットに相当する４バイトの保護されたペイロードＰＰと、からなり、これにより、テーブル３に示されているように合計で５０ビットになる。ＡＥＳ－ＧＣＭの効率的な計算を達成するために、ＡＡＤのための１２８ビットの全長に到達するために必要とされる残りの７８ビットのためのゼロパディングについて検討する。
保護されたペイロードＰＰのための利用可能なバイトを６バイトに増加させるためにシーケンス番号ＳＮを省略しようとした場合には、テーブル３に記載されている長さの値がさらに変化するであろうことが理解されるであろう。この追加的な保護されたペイロードのビットは、当然、リプレイ攻撃に対する保護がないという犠牲を払うこととなる。当然、それと引き換えにして、保護されたペイロード部分ＰＰのための利用可能なバイトを増加させるために、セキュリティ要件に応じて、２バイト未満のサイズまでセキュリティタグＳｅｃＴａｇを短縮することを決定してもよい。
テーブル４は、シーケンス番号ＳＮを使用してＣＡＮシステムの内部において１つの総称キーＫを用いるＡＥＳ－ＧＣＭモードに関して、キーサイズが１２８ビットである場合について、ＡＥモードについての入力パラメータ長および出力パラメータ長をまとめたものである。
Figure 2023523883000006
ＡＥモードにおける付加認証データＡＡＤは、１８ビットの全長を有するヘッダからなる。ＡＥＳ－ＧＣＭの効率的な計算を達成するために、ＡＡＤのための６４ビットの全ブロックサイズに到達するために必要とされる残りのビットのためのゼロパディングについて検討する。
保護されたペイロードＰＰのための利用可能なバイトを６バイトに増加させるためにシーケンス番号ＳＮを省略しようとした場合には、テーブル４に記載されている長さの値がさらに変化するであろうことが理解されるであろう。この追加的な保護されたペイロードのビットは、当然、リプレイ攻撃に対する保護がないという犠牲を払うこととなる。当然、それと引き換えにして、保護されたペイロード部分ＰＰのための利用可能なバイトを増加させるために、セキュリティ要件に応じて、２バイト未満のサイズまでセキュリティタグＳｅｃＴａｇを短縮することを決定してもよい。
ＣＡＮバス通信システムのためにＳＡＤＳＥ機能を実装する場合の１つのバリエーションは、ＡＥＳ－ＧＣＭよりも短いブロックサイズのブロック暗号について検討することである。Simon and Speckは、米国の国家安全保障局によって定義されるこのような軽量暗号の一例である。テーブル５は、Simon and Speckブロック暗号ファミリーについて、種々異なるブロックサイズおよびキーサイズをまとめたものである。
Figure 2023523883000007
１８ビットのヘッダサイズと、シーケンス番号ＳＮと、２バイトのセキュリティタグＳｅｃＴａｇと、をそれぞれ有するＣＡＮシステムの内部において１つの総称キーＫを使用するSimon and Speckブロック暗号のための６４ビットのキーサイズについて検討する。
テーブル６は、ＣＡＮフレームにセキュリティタグＳｅｃＴａｇおよびシーケンス番号ＳＮを含めたときの、認証のみのＡＯモードについての入力パラメータ長および出力パラメータ長をまとめたものである。
テーブル６から見て取れるように、平文ストリームおよび暗号文は、正確に１ブロックサイズに相当する３２ビット長である。したがって、ＡＥＳ－ＧＣＭの場合のようにこれらのフィールドに対してゼロパディングは必要とされず、Simon and Speckの動作は、ＣＡＮフレームに対してＡＥＳ－ＧＣＭよりもより効率的である。
Figure 2023523883000008
シーケンス番号ＳＮおよび／またはセキュリティタグＳｅｃＴａｇを短縮または省略することによって、保護されるペイロード部分ＰＰを増加させることができるが、これにより、トレードオフとしてＣＡＮフレームのための保護のレベルが低減することは、当業者には明らかであろう。
付加認証データは、上述したＡＥＳ－ＧＣＭの場合に当てはまるように５０バイト長であり、この長さは、３２ビットのSimon and Speckブロックサイズの１ブロックサイズと２ブロックサイズとの間にあるので、ゼロパディングを必要とする。
テーブル７は、ＣＡＮフレームにセキュリティタグＳｅｃＴａｇおよびシーケンス番号ＳＮを含めたときの、認証された暗号化モードのための入力パラメータ長および出力パラメータ長をまとめたものである。
Figure 2023523883000009
テーブル７から見て取れるように、平文ストリームおよび暗号文は、正確に１ブロックサイズに相当する３２ビット長である。したがって、ＡＥＳ－ＧＣＭの場合のようにこれらのフィールドに対してゼロパディングは必要とされず、Simon and Speckの動作は、この点において、ＣＡＮフレームに対してＡＥＳ－ＧＣＭよりもより効率的である。しかしながら、付加認証データＡＡＤは、上記の例で説明したＡＥＳ－ＧＣＭの場合に当てはまるようにフルブロックサイズよりも短く、したがって、ゼロパディングを必要とする。
上述した例示的な実装形態は、単なる例示に過ぎない。本明細書に記載された構成および詳細の修正および変更は、当業者には明らかであることが理解されるであろう。したがって、出願中の特許請求の範囲によってのみ限定され、本明細書における実装形態の記載および説明によって提示される特定の詳細によって限定されるわけではないということが意図されている。

Claims (20)

  1. プロトコルに従って車両内のバスベースの通信システムの参加者間で通信するためのプロトコルフレーム（１００）であって、
    前記プロトコルフレームは、ヘッダ（Ｈ）を含み、前記ヘッダ（Ｈ）は、送信機（Ｓ）と受信機（Ｒ）との間で通信されるべき前記プロトコルフレームの開始を示し、前記送信機（Ｓ）および前記受信機（Ｒ）の両方は、前記バスベースの通信システムの参加者であり、
    前記プロトコルフレームは、指示を含み、前記指示は、データリンク層上での前記プロトコルフレーム（１００）の真正性のレベルまたはデータセキュリティのレベルを示すように構成されている、
    プロトコルフレーム（１００）。
  2. 前記指示は、前記プロトコルフレーム（１００）に対するデータリンク層レベルでの認証を示すように構成された第１の指示を含む、
    請求項１記載のプロトコルフレーム（１００）。
  3. 前記指示は、前記プロトコルフレーム（１００）に対するデータリンク層レベルでの認証およびデータセキュリティの両方を示すように構成された第２の指示を含む、
    請求項１または２記載のプロトコルフレーム（１００）。
  4. 前記指示、前記第１の指示または前記第２の指示のうちの少なくとも１つは、
    前記プロトコルフレーム（１００）の前記ヘッダ（Ｈ）の一部であるか、
    前記プロトコルフレーム（１００）のペイロードタイプ（ｐｔ）として表されるか、または
    前記ヘッダの内部のセキュリティ指示フラグまたはビットフィールドとして表される、
    うちの少なくとも１つである、
    請求項３記載のプロトコルフレーム（１００）。
  5. 前記プロトコルフレーム（１００）は、
    前記ヘッダ（Ｈ）の下流のセキュリティ情報（ＳＩ）と、
    前記ヘッダ（Ｈ）の下流の保護されたペイロード部分（ＰＰ）と、
    をさらに含み、
    前記セキュリティ情報（ｓｉ）は、前記保護されたペイロード部分（ＰＰ）に対する保護レベルを示す、
    請求項１から４までのいずれか１項記載のプロトコルフレーム（１００）。
  6. 前記セキュリティ情報は、
    前記送信機と前記受信機との間の仮想チャネル、または
    １つまたは複数のキー
    のうちの少なくとも１つを示すようにさらに構成されている、
    請求項５記載のプロトコルフレーム（１００）。
  7. 前記セキュリティ情報（ｓｉ）と組み合わせられた前記指示は、前記プロトコルフレーム（１００）に対して認証のみが適用されるか、または、認証およびデータ保護が適用されるかを示す、
    請求項５記載のプロトコルフレーム（１００）。
  8. 前記セキュリティ情報（ｓｉ）は、前記プロトコルフレーム（１００）に対するデータリンク層レベルでの認証のため、または、認証およびデータセキュリティのために選択されるべきキー（Ｋ）を示すセキュリティアソシエーションを示すようにさらに構成されている、
    請求項５または６記載のプロトコルフレーム（１００）。
  9. 前記プロトコルフレーム（１００）は、セキュリティタグ（ＳｅｃＴａｇ）をさらに含み、
    前記セキュリティタグ（ＳｅｃＴａｇ）は、送信機から受信機に伝送されることが意図されたオリジナルのプロトコルフレームとしての前記プロトコルフレーム（１００）の真正性を、データリンク層レベルで検証するように構成されており、
    前記セキュリティタグ（ＳｅｃＴａｇ）は、前記プロトコルフレームの真正性を、前記データリンク層上の前記送信機で、または、前記データリンク層上の前記受信機で検証するように構成されている、
    請求項１から８記載のプロトコルフレーム（１００）。
  10. 前記プロトコルフレーム（１００）は、コントローラエリアネットワーク（ＣＡＮ）標準、ＣＡＮフレキシブルデータレート標準またはＣＡＮエクストララージ標準と共に使用される長さＮを有する、
    請求項１から９記載のプロトコルフレーム（１００）。
  11. 前記プロトコルフレームは、８バイト、８～６４バイトまたは６４～２０４８バイトの長さＮを選択的に有する、
    請求項１から９記載のプロトコルフレーム。
  12. 車両内のバスベースの通信システムに参加するように構成されている、データリンク層上の送信機（Ｓ）であって、
    前記送信機（Ｓ）は、
    上位のプロトコル層からの要求に応じてヘッダ（Ｈ）を生成し、
    ｋバイト長のキー（Ｋ）にアクセスし、
    前記上位のプロトコル層から保護されたペイロード部分（ＰＰ）を受信し、
    付加認証データ（ＡＡＤ）を集約し、
    前記送信機（Ｓ）から受信機（Ｒ）に送信されるオリジナルフレームとしてのフレームの真正性をデータリンク層レベルで検証するためのセキュリティタグ（ＳｅｃＴａｇ）を、前記キー（Ｋ）および前記付加認証データ（ＡＡＤ）を使用して生成し、
    前記ヘッダ（Ｈ）と、前記保護されたペイロード部分（ＰＰ）と、前記付加認証データ（ＡＡＤ）と、を含むプロトコルフレーム（１００）を生成する
    ように構成されており、
    前記送信機（Ｓ）は、前記プロトコルフレームを、前記送信機（Ｓ）から前記バスベースの通信システムの１つまたは複数の参加者に前記データリンク層レベルで通信するように構成されている、
    送信機（Ｓ）。
  13. 前記バスベースの通信システムは、ブロードキャストベースのバスシステムであり、したがって、前記バスベースの通信システムの内部の全てのノードは、前記送信機（Ｓ）によって通信された前記プロトコルフレーム（１００）を受信するように構成されている、
    請求項１２記載の送信機（Ｓ）。
  14. 前記プロトコルフレーム（１００）は、前記データリンク層上での前記プロトコルフレーム（１００）の真正性のレベルまたはデータセキュリティのレベルを示すように構成された指示をさらに含む、
    請求項１２または１３記載の送信機。
  15. 前記指示は、
    前記プロトコルフレームに対する前記データリンク層レベルでの認証を示すように構成された第１の指示、または
    前記プロトコルフレームに対する前記データリンク層レベルでの認証およびデータセキュリティの両方を示すように構成された第２の指示
    を含む、
    請求項１４記載の送信機（Ｓ）。
  16. 前記送信機の認証のみのモードにおいて、前記付加認証データは、
    前記ヘッダ（Ｈ）と、
    前記保護されたペイロード部分（ＰＰ）と、
    である、
    請求項１２から１５までのいずれか１項記載の送信機（Ｓ）。
  17. 認証された暗号化モードにおける前記送信機（Ｓ）は、
    キー（Ｋ）と、
    平文での保護されたペイロード部分（ＰＰ）と、
    付加認証データ（ＡＡＤ）としてのヘッダ（Ｈ）と、
    を使用して、前記保護されたペイロード部分のための暗号文を生成するようにさらに構成されている、
    請求項１２から１４記載の送信機（Ｓ）。
  18. 前記送信機（Ｓ）は、前記ヘッダ（Ｈ）の下流にｓｎバイトのシーケンス番号（ＳＮ）を生成するようにさらに構成されており、
    前記送信機（Ｓ）は、前記保護されたペイロードの短縮を犠牲にして前記シーケンス番号（ＳＮ）を前記プロトコルフレーム（１００）に組み込むように構成されており、短縮された保護されたペイロードは、前記保護されたペイロード部分（ＰＰ）に比べてｓｎバイトだけ短縮されている、
    請求項１２から１５までのいずれか１項記載の送信機（Ｓ）。
  19. 前記送信機（Ｓ）は、前記キーＫを使用して長さｓｉのセキュリティ情報（ＳｅｃＩｎｆ）を生成するように構成されており、
    前記送信機（Ｓ）は、ペイロードの短縮を犠牲にして前記セキュリティ情報を前記ヘッダ（Ｈ）の下流で前記プロトコルフレームに組み込むようにさらに構成されており、短縮された前記ペイロードは、前記保護されたペイロード（ＰＰ）に比べてｓｉバイトだけ短縮されており、
    前記セキュリティ情報（ＳｅｃＩｎｆ）は、前記保護されたペイロード部分に対する保護レベルを示す、
    請求項１２から１８までのいずれか１項記載の送信機（Ｓ）。
  20. 認証された暗号化モードにおける前記送信機は、ｓｉバイト長のセキュリティ情報を生成するようにさらに構成されており、
    前記送信機は、保護されたペイロードの短縮を犠牲にして前記セキュリティ情報を前記ヘッダの下流で前記プロトコルフレームに組み込むようにさらに構成されており、短縮された保護されたペイロードは、前記保護されたペイロードに比べてｓｉ＋ｓｎバイトだけ短縮されており、
    前記セキュリティ情報は、前記短縮された保護されたペイロードに対する保護レベルを示す、
    請求項１２から１４までのいずれか１項または請求項１７記載の送信機。
JP2022556148A 2020-03-20 2021-03-19 自動車の通信システムのためのデータリンク層の真正性およびセキュリティ Pending JP2023523883A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/825,896 2020-03-20
US16/825,896 US11321442B2 (en) 2020-03-20 2020-03-20 Data link layer authenticity and security for automotive communication system
PCT/EP2021/057087 WO2021186030A1 (en) 2020-03-20 2021-03-19 Data link layer authenticity and security for automotive communication system

Publications (1)

Publication Number Publication Date
JP2023523883A true JP2023523883A (ja) 2023-06-08

Family

ID=75267477

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2022556148A Pending JP2023523883A (ja) 2020-03-20 2021-03-19 自動車の通信システムのためのデータリンク層の真正性およびセキュリティ

Country Status (6)

Country Link
US (3) US11321442B2 (ja)
EP (2) EP4122177B1 (ja)
JP (1) JP2023523883A (ja)
KR (1) KR20220157388A (ja)
CN (1) CN115336225A (ja)
WO (1) WO2021186030A1 (ja)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11321442B2 (en) 2020-03-20 2022-05-03 Infineon Technologies Ag Data link layer authenticity and security for automotive communication system
US11539621B2 (en) * 2021-02-03 2022-12-27 Motional Ad Llc Controller area network messages in an autonomous vehicle
US11522678B2 (en) * 2021-06-08 2022-12-06 Intel Corporation Block cipher encryption for processor-accelerator memory mapped input/output communication
US20210297243A1 (en) 2021-06-08 2021-09-23 Intel Corporation Permutation cipher encryption for processor-accelerator memory mapped input/output communication
CN113676900A (zh) * 2021-10-25 2021-11-19 奥特酷智能科技(南京)有限公司 基于canxl总线的车载传感器数据安全传输方法及系统
CN114827968B (zh) * 2022-03-31 2022-11-08 远峰科技股份有限公司 一种ble智能钥匙canfd的大数据传输方法
EP4270869A1 (en) * 2022-04-27 2023-11-01 Schneider Electric Industries SAS Secure communication protocol for communication devices
CN115766915A (zh) * 2022-11-01 2023-03-07 长城汽车股份有限公司 汽车开放系统架构、数据处理方法、介质及车载设备
CN117424947B (zh) * 2023-12-19 2024-03-12 无锡梵克罗电气设计有限公司 骑行设备系统

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8379638B2 (en) * 2006-09-25 2013-02-19 Certes Networks, Inc. Security encapsulation of ethernet frames
US8973125B2 (en) * 2010-05-28 2015-03-03 Alcatel Lucent Application layer authentication in packet networks
US9980082B2 (en) 2014-08-26 2018-05-22 Kooltechs Inc. System and method for tracking locations and activities
CN107819736B (zh) * 2016-09-13 2021-12-31 现代自动车株式会社 基于车辆网络中的汽车安全完整性等级的通信方法及设备
CN106899404B (zh) 2017-02-15 2020-06-02 同济大学 基于预共享密钥的车载can fd总线通信系统及方法
US11321442B2 (en) 2020-03-20 2022-05-03 Infineon Technologies Ag Data link layer authenticity and security for automotive communication system

Also Published As

Publication number Publication date
EP4122177A1 (en) 2023-01-25
US11321442B2 (en) 2022-05-03
US20210294889A1 (en) 2021-09-23
EP4369660A2 (en) 2024-05-15
CN115336225A (zh) 2022-11-11
US20240126866A1 (en) 2024-04-18
WO2021186030A1 (en) 2021-09-23
US11816201B2 (en) 2023-11-14
KR20220157388A (ko) 2022-11-29
EP4369660A3 (en) 2024-05-22
US20220261471A1 (en) 2022-08-18
EP4122177B1 (en) 2024-05-01

Similar Documents

Publication Publication Date Title
JP2023523883A (ja) 自動車の通信システムのためのデータリンク層の真正性およびセキュリティ
CN110073634B (zh) 数据转换系统及方法
CN108696411B (zh) 用于在can系统中使用的装置
KR101740957B1 (ko) 차량용 데이터의 인증 및 획득 방법
US20060126847A1 (en) System and method for establishing secure communications between devices in distributed wireless networks
CN111447235A (zh) 网络装置以及网络系统
CN101542961A (zh) 在通信网络中加密数据
US20220294607A1 (en) Transport layer authenticity and security for automotive communication
US10699031B2 (en) Secure transactions in a memory fabric
Hafeez et al. Comparative study of can-bus and flexray protocols for in-vehicle communication
CN110035047A (zh) 用于检查数据包中的消息完整性的轻型机制
US10311005B2 (en) Message translator
Xiao et al. Session key distribution made practical for CAN and CAN-FD message authentication
CN113632419A (zh) 用于对要在总线系统（bu）、特别是机动车辆的总线系统中传输的至少一个数据分组进行生成和认证检查的装置和方法
Fazzat et al. A comparative performance study of cryptographic algorithms for connected vehicles
CN113810173A (zh) 一种校验应用信息的方法、报文处理方法及装置
CN114128220B (zh) 针对汽车通信系统的数据链路层真实性和安全性
CN114731292A (zh) 低延迟介质访问控制安全认证
Došek et al. Secure high level communication protocol for CAN bus
Wang et al. Unified data authenticated encryption for vehicular communication
Piao et al. A Security Framework for In-Vehicle FlexRay Bus Network
Vougioukalos An embedded platform for developing data protection protocols on smart vehicles.
Han et al. Enhancing security and robustness of Cyphal on Controller Area Network in unmanned aerial vehicle environments
Kim et al. Routing Methods Considering Security and Real-Time of Vehicle Gateway System
Janků et al. SECURE HIGH LEVEL COMMUNICATION PROTOCOL FOR CAN BUS.

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20221209

A529 Written submission of copy of amendment under article 34 pct

Free format text: JAPANESE INTERMEDIATE CODE: A529

Effective date: 20221116

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20240312