IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ヒタチ・エナジー・リミテッドの特許一覧

特許7499775資源が限られているシステムにおいてメッセージを認証するための方法
<>
  • 特許-資源が限られているシステムにおいてメッセージを認証するための方法 図1
  • 特許-資源が限られているシステムにおいてメッセージを認証するための方法 図2
  • 特許-資源が限られているシステムにおいてメッセージを認証するための方法 図3
  • 特許-資源が限られているシステムにおいてメッセージを認証するための方法 図4
  • 特許-資源が限られているシステムにおいてメッセージを認証するための方法 図5
  • 特許-資源が限られているシステムにおいてメッセージを認証するための方法 図6
  • 特許-資源が限られているシステムにおいてメッセージを認証するための方法 図7
  • 特許-資源が限られているシステムにおいてメッセージを認証するための方法 図8
  • 特許-資源が限られているシステムにおいてメッセージを認証するための方法 図9
  • 特許-資源が限られているシステムにおいてメッセージを認証するための方法 図10
  • 特許-資源が限られているシステムにおいてメッセージを認証するための方法 図11
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-06-06
(45)【発行日】2024-06-14
(54)【発明の名称】資源が限られているシステムにおいてメッセージを認証するための方法
(51)【国際特許分類】
   H04L 9/32 20060101AFI20240607BHJP
【FI】
H04L9/32 200A
H04L9/32 200E
【請求項の数】 11
(21)【出願番号】P 2021545920
(86)(22)【出願日】2020-02-05
(65)【公表番号】
(43)【公表日】2022-03-24
(86)【国際出願番号】 EP2020052897
(87)【国際公開番号】W WO2020161201
(87)【国際公開日】2020-08-13
【審査請求日】2021-10-04
(31)【優先権主張番号】19155836.0
(32)【優先日】2019-02-06
(33)【優先権主張国・地域又は機関】EP
【前置審査】
(73)【特許権者】
【識別番号】523380173
【氏名又は名称】ヒタチ・エナジー・リミテッド
【氏名又は名称原語表記】HITACHI ENERGY LTD
(74)【代理人】
【識別番号】110001195
【氏名又は名称】弁理士法人深見特許事務所
(72)【発明者】
【氏名】ズン,ダクフィ
(72)【発明者】
【氏名】シバンティ,ターニケサバン
【審査官】金沢 史明
(56)【参考文献】
【文献】国際公開第2015/170452(WO,A1)
【文献】特開2018-032903(JP,A)
【文献】特開2016-100632(JP,A)
【文献】特開2019-016987(JP,A)
【文献】米国特許出願公開第2018/0316504(US,A1)
【文献】米国特許出願公開第2007/0101412(US,A1)
【文献】米国特許出願公開第2002/0174332(US,A1)
【文献】特開平06-315027(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
H04L 9/00- 9/40
(57)【特許請求の範囲】
【請求項1】
ネットワークを介するメッセージ認証のための方法であって、デバイスが以下のステップを実行して認証メッセージを生成するように構成され、前記ステップは、
(a)ブロック長さ(L)を有するデータブロックを準備するステップと、
(c)少なくとも前記ブロック長さ(L)およびデータフレームの最大長さ(Lmax)から、利用可能な長さ(Lavail)を求めるステップと、
(d)少なくとも前記データブロックから、前記利用可能な長さ(Lavail)以下のメッセージ認証コード(MAC)長さ(LMAC)を有するMAC(430)を計算するステップと、
(e)前記データブロックと前記MAC(430)とを備える前記データフレーム(400)を作成するステップと、
(e2)前記データブロックと追加MAC(630)とを備える追加データフレーム(600)を作成するステップとを備え、
前記MAC(430)を計算するステップは、少なくとも前記データブロックから、前記利用可能な長さ(Lavail)以下の追加MAC長さ(LMAC2)を有する前記追加MAC(630)を計算するステップを備え
前記MAC(430)および/または前記追加MAC(630)は、少なくとも前記データブロックおよび少なくとも1つの以前に送信または格納されたデータブロックから計算される、方法。
【請求項2】
前記データブロックを、前記MAC(430)を計算するために使用されない暗号鍵を用いて暗号化するステップをさらに備える、請求項1に記載の方法。
【請求項3】
(f)前記データフレーム(400)を送信または格納するステップ、および
(f2)前記追加データフレーム(600)を送信または格納するステップとをさらに備える、請求項1または請求項2に記載の方法。
【請求項4】
(g)前記データフレーム(400)および/または前記追加データフレーム(600)を受信または検索するステップと、
(h)前記MAC(430)および/または前記追加MAC(630)を確認するステップとをさらに備える、請求項2または請求項3に記載の方法。
【請求項5】
(h2)信頼レベルを前記受信した前記データフレーム(400)、前記追加データフレーム(600)および/または前記データブロックに関連付けるステップをさらに備える、請求項4に記載の方法。
【請求項6】
(k)前記信頼レベルが許容閾値を上回っていることを確認するステップをさらに備える、請求項5に記載の方法。
【請求項7】
命令を備えるコンピュータプログラムが格納されたコンピュータ読取可能なデータキャリアであって、前記命令は、前記プログラムがコンピュータまたはコンピュータシステムによって実行されると、前記コンピュータまたは前記コンピュータシステムに請求項1~請求項6のいずれか1項に記載の方法を実行させる、コンピュータ読取可能なデータキャリア。
【請求項8】
ネットワークを介して通信される認証されたメッセージを生成するためのデバイス(100)であって、
ブロック長さ(L)を有するデータブロックを準備し、
少なくとも前記ブロック長さ(L)およびデータフレームの最大長さ(Lmax)から、利用可能な長さ(Lavail)を求め、
少なくとも前記データブロックから、前記利用可能な長さ(Lavail)以下のメッセージ認証コード(MAC)長さ(LMAC)を有するMAC(430)を計算し、
前記データブロックと前記MAC(430)とを備える前記データフレーム(400)を作成し、
前記利用可能な長さ(Lavail)以下の追加MAC長さ(LMAC2)を有する追加MAC(630)を計算し、
前記データブロックと前記追加MAC(630)とを備える追加データフレーム(600)を作成するように構成され
前記MAC(430)および/または前記追加MAC(630)は、少なくとも前記データブロックおよび少なくとも1つの以前に送信または格納されたデータブロックから計算される、デバイス。
【請求項9】
メッセージを認証するためのシステムであって、
請求項8に記載の認証されたメッセージを送信または生成するためのデバイスと、
請求項8に記載のデバイス(100)から、認証されたメッセージを受信するためのデバイス(200)であって、
データブロックとメッセージ認証コード(MAC)(430)とを備えるデータフレーム(400)を受信し、
前記MAC(430)を確認し、
前記データブロックと追加MAC(630)とを備える追加データフレームを受信し、
前記追加MACを確認するように構成される、デバイスと、
を備えるシステム。
【請求項10】
前記データブロックを圧縮するステップを含む、請求項1に記載の方法。
【請求項11】
前記データブロックを圧縮するよう構成される、請求項8に記載のデバイス。
【発明の詳細な説明】
【技術分野】
【0001】
発明の分野
本発明は、資源(リソース)が限られているシステムにおけるメッセージ認証の分野に関する。
【背景技術】
【0002】
発明の背景
産業オートメーション、特にグリッドオートメーションのためのデバイス、および、IoTゲートウェイなどのモノのインターネット(IoT)デバイスは、特にセキュリティ保護されていないシステムおよびネットワークを使用してメッセージを送信したり、受信したり、格納したりすることがある。さらに、記憶容量および送信容量は、限られている場合がある。メッセージ偽造または改ざんおよびなりすまし攻撃に対するセキュリティを提供するために、メッセージは認証される。これは、メッセージ認証コード(MAC)によって実現することができ、MACは、メッセージの暗号化されたチェックサムまたは鍵付きハッシュであり得る。たとえば、送信者は、アルゴリズムを介してメッセージからMACを計算し、暗号化鍵を使用してMACを暗号化し、メッセージおよびMACを受信者に送信することができ、暗号化鍵およびアルゴリズムを知っている受信者は、自分自身で、受信したメッセージからMACを計算することができ、それを受信したMACと比較することができる。一致している場合、メッセージは認証される。メッセージ認証は、データサイズを大幅に増加させることになり、これは、特に容量が限られている場合には問題になり得る。たとえば、ブルートフォースアタック(総当たり攻撃)を防止するために、MACは長くなければならず、たとえばセキュアハッシュアルゴリズムSHA-256では256ビットでなければならない。通信容量または記憶容量が限られているシステムでは、32バイトは、無視できないオーバーヘッドであり、たとえば、ローパワー・ロングレンジ・ワイドエリアネットワーク(LPWAN)は、一般的なパケットがほんの数バイトのペイロードを運ぶ低レートワイヤレス通信システムである。
【0003】
US 2002/174332 A1には、メッセージを送信する方法が開示されており、この方法では、メッセージの長さがブロックサイズの長さよりも短い場合に、算出されたメッセージ認証コードは、残りの空間にフィットするように切り捨てられる。
【発明の概要】
【課題を解決するための手段】
【0004】
発明の説明
本発明の目的は、特に送信容量または記憶容量が低い場合における、セキュリティを強化させたメッセージ認証のための方法を提供することである。さらなる目的は、認証されたメッセージを生成または送信するための対応するデバイスおよび認証されたメッセージを受信または検索するための対応するデバイス、ならびにこのようなデバイスを備えるシステムを提供することである。メッセージ認証コードを配置するためのメッセージまたはデータフレームにおけるさらなる空間を利用できるようにすることが、さらなる目的であると言える。
【0005】
これらの目的は、独立請求項の主題によって開示されているようにデータ圧縮および/または冗長なメッセージの生成によってメッセージ認証のためのさらなる空間を作成または使用することによって実現される。さらなる例示的な実施形態は、従属請求項および以下の説明から明らかである。
【0006】
本発明の第1の局面は、メッセージ認証のための方法、特にコンピュータによって実行される方法に関する。この方法は、メッセージソース、送信者側またはメッセージ生成側で実行され得る以下の方法要素を備えていてもよく、上記方法要素は、
特に準備モジュールが、圧縮されていない長さを有するデータブロック、特に圧縮されていないデータブロックを準備するステップと、
特に上記データブロックを準備するステップの後に、特に圧縮モジュールが、上記データブロック、特に圧縮されたデータブロックが上記圧縮されていない長さよりも小さな圧縮された長さを有するように上記データブロックを圧縮するステップと、
特に上記データブロックを圧縮するステップの後に、特に認証モジュールが、少なくとも上記圧縮された長さおよびデータフレームの最大長さから利用可能な長さを求めるステップとを備え、上記最大長さは、予め定められた長さ、予め規定された長さまたは所与の最大長さであってもよく、上記方法要素はさらに、
特に上記利用可能な長さを求めるステップの後に、特に上記認証モジュールが、少なくとも上記データブロックから、特に少なくとも上記圧縮されたデータブロックから、メッセージ認証コード(MAC)を計算するステップを備え、上記MACは、上記利用可能な長さ以下のMAC長さを有し、認証鍵が使用されてもよく、上記方法要素はさらに、
特に上記MACを計算するステップの後に、メッセージ生成モジュールが、特に上記圧縮された長さの上記データブロックまたは上記圧縮されたデータブロックと上記MACとを、特に予め規定された順序またはメッセージフォーマットで備える上記データフレームを作成するステップを備える。
【0007】
本明細書において、上記データブロックは、特に、メッセージ認証のためのさらなる容量を作成するように圧縮されてもよい。実施形態において、上記データフレームは、上記圧縮された長さおよび/または上記MAC長さを示す少なくとも1つのデータアイテムをさらに備えていてもよい。
【0008】
特に、少なくとも上記データブロックから上記MACを計算するステップは、上記利用可能な長さ以下の追加MAC長さを有する追加MACを計算するステップを備えていてもよく、上記方法はさらに、上記メッセージ生成側または上記送信者側で実行され得る以下の方法要素を備えていてもよく、上記方法要素は、
特に上記メッセージ生成モジュールが、上記データブロック、特に上記圧縮された長さの上記データブロックまたは上記圧縮されたデータブロックと上記追加MACとを、特に予め規定された順序またはメッセージフォーマットで備える追加データフレームを作成するステップを備える。上記追加MACは、上記MACとは異なっていてもよい。上記追加データフレームは、上記圧縮された長さおよび/または上記追加MAC長さを示す少なくとも1つのデータアイテムをさらに備えていてもよい。
【0009】
特に冗長なメッセージの生成または送信の場合、圧縮および復元する方法要素は省略されてもよい。この場合、上記圧縮された長さと上記圧縮されていない長さとは一致し、同義で使用されてもよく、および/または、ブロック長さと表記されてもよい。実施形態において、本発明の第1の局面の方法は、
特に準備モジュールが、ブロック長さを有するデータブロックを準備するステップと、
特に認証モジュールが、少なくとも上記ブロック長さおよびデータフレームの最大長さから利用可能な長さを求めるステップとを備え、上記最大長さは、予め定められた長さ、予め規定された長さまたは所与の最大長さであってもよく、上記方法はさらに、
特に上記利用可能な長さを求めるステップの後に、特に上記認証モジュールが、少なくとも上記データブロックから、上記利用可能な長さ以下のメッセージ認証コード(MAC)長さを有するMACと、上記利用可能な長さ以下の追加MAC長さを有する追加MACとを計算するステップを備え、認証鍵が使用されてもよく、上記方法はさらに、
特に上記MACを計算するステップの後に、特にメッセージ生成モジュールが、上記データブロックと上記MACとを、特に予め規定された順序またはメッセージフォーマットで備える上記データフレームを作成するステップと、
特に上記MACと上記追加MACとを計算するステップの後に、特に上記メッセージ生成モジュールが、上記データブロックと上記追加MACとを、特に予め規定された順序またはメッセージフォーマットで備える追加データフレームを作成するステップとを備える。本明細書において、上記MACと上記追加MACとは異なっていてもよい。上記データフレームは、上記ブロック長さおよび/または上記MAC長さを示す少なくとも1つのデータアイテムをさらに備えていてもよく、上記追加データフレームは、上記ブロック長さおよび/または上記追加MAC長さを示す少なくとも1つのデータアイテムをさらに備えていてもよい。
【0010】
本発明の第1の局面の方法は、特に上記データブロックを圧縮するステップの後および/または上記MACを計算するステップの前に、上記データブロックまたは上記圧縮されたデータブロックを暗号化するステップをさらに備えていてもよい。この方法要素は、特に暗号化モジュールによって、上記メッセージソース、上記送信者側または上記メッセージ生成側で実行されてもよい。上記認証鍵とは異なる暗号化鍵が使用されてもよい。
【0011】
上記方法は、特に上記データフレームを生成するステップの後に、特に上記メッセージソース、上記送信者側または上記メッセージ生成側で、特に送信モジュールまたは格納モジュールによって、上記データフレームを送信または格納し、および/または、上記追加データフレームを送信または格納するステップをさらに備えていてもよい。
【0012】
上記MACおよび/または上記追加MACは、少なくとも上記データブロックおよび少なくとも1つの以前に送信または格納されたデータブロックから計算されてもよく、上記少なくとも1つの以前に送信または格納されたデータブロックは、以前に送信または格納されたデータフレームおよび/または以前に送信または格納された追加データフレームの一部として圧縮および/または送信されていてもよい。
【0013】
また、上記方法はさらに、上記データフレームを送信するステップの後に、および/または、メッセージ検索側または受信者側で実行され得る以下の方法要素を備えていてもよく、上記方法要素は、
特にメッセージ受信または検索モジュールが、上記データフレームおよび/または上記追加データフレームを受信または検索するステップと、
特に確認モジュールが、上記MACおよび/または上記追加MACを確認するステップとを備え、上記MACを確認するステップは、少なくとも上記データブロックから確認MACを計算して、上記MACを上記確認MACと比較するステップを備えていてもよく、上記追加MACを確認するステップは、少なくとも上記データブロックから追加確認MACを計算して、上記追加MACを上記追加確認MACと比較するステップを備えていてもよい。
【0014】
上記方法はさらに、
特に復元モジュールが、特に上記MACの確認が肯定的である場合に、上記データブロックを復元するステップ、および/または、
上記データブロックの暗号化の場合に、特に解読モジュールが、特に上記データブロックを復元するステップの前および/または上記MACおよび/または上記追加MACを確認するステップの後に、上記データブロックを解読するステップを備えていてもよい。
【0015】
また、上記方法は、上記メッセージ検索側または上記受信者側で実行され得る以下の方法要素を備えていてもよく、上記方法要素は、
特に上記確認モジュールが、特に上記MACおよび/または上記追加MACを確認するステップの後に、信頼レベルを上記データフレーム、上記追加データフレームおよび/または上記データブロックに付与するステップを備え、上記信頼レベルは、少なくとも、上記MACおよび/または上記追加MACの確認に基づいていてもよく、少なくとも1つの以前に受信もしくは検索されたデータフレームおよび/または少なくとも1つの以前に受信もしくは検索された追加データフレームのMAC/追加MACの確認に基づいていてもよく、上記MAC長さに基づいていてもよく、上記追加MAC長さに基づいていてもよく、上記少なくとも1つの以前に受信または検索されたデータフレームの上記MAC長さに基づいていてもよく、および/または、上記少なくとも1つの以前に受信もしくは検索された追加データフレームの上記追加MAC長さに基づいていてもよく、上記信頼レベルは、上記追加MACもしくは上記MAC単独の確認が肯定的である場合、または、確認が肯定的でない場合よりも、上記追加MACおよび上記MACの確認が肯定的である場合に高くてもよく、上記方法要素はさらに、
特に出力モジュールが、特に上記データブロックを復元および/または解読するステップの後に、上記データブロック、特に上記信頼レベルを有する上記データブロックをユーザおよび/またはアプリケーションに出力するステップを備え、上記方法はさらに、特に上記データブロックを出力するステップの前に、上記データブロックを出力するための条件として、上記データブロックを出力するステップの後に、および/または、特に上記アプリケーションまたは上記ユーザによる上記データブロックのさらなる処理のための条件として、特に上記確認モジュール、上記ユーザおよび/または上記アプリケーションが、上記信頼レベルが許容閾値を上回っていることを確認するステップを備えていてもよい。
【0016】
実施形態において、本発明の第1の局面に係る方法の方法要素のうちの少なくとも一部または全ては、少なくとも1つの集積回路によって実行される。
【0017】
本発明の第2の局面は、コンピュータまたはコンピュータシステムによって実行されると、上記コンピュータまたは上記コンピュータシステムに本発明の第1の局面に係る方法を実行させる命令を備えるコンピュータプログラム、および、上記コンピュータプログラムが格納された特に非一時的なコンピュータ読取可能なデータキャリアに関する。
【0018】
本発明の第3の局面は、本発明の第1の局面の方法、特にメッセージ生成または送信者側で実行され得る方法要素を実行するように構成され得る、認証されたメッセージまたはデータフレームを送信または生成するためのデバイスに関する。実施形態において、上記デバイスは、
圧縮されていない長さまたはブロック長さを有するデータブロック、特に圧縮されていないデータブロックを準備し、
少なくとも圧縮された長さまたは上記ブロック長さおよびデータフレームの最大長さから利用可能な長さを求め、少なくとも上記データブロックから、特に少なくとも圧縮されたデータブロックから、または少なくとも上記データブロックおよび少なくとも1つの以前に送信または格納されたデータブロックから、上記利用可能な長さ以下のメッセージ認証コード(MAC)長さを有するMACを計算するように適合または構成されてもよく、上記少なくとも1つの以前に送信されたデータブロックは、以前に送信または格納されたデータフレームの一部として送信または格納されてもよく、上記デバイスはさらに、
特に上記圧縮された長さの上記データブロックまたは上記圧縮されたデータブロックおよび上記MACを、特に予め定められたまたは予め規定された順序またはメッセージフォーマットで備える上記データフレームを作成するように適合または構成されてもよく、
上記デバイスはさらに、
上記データブロック、特に上記圧縮されたデータブロックが上記圧縮されていない長さよりも小さな上記圧縮された長さを有するように上記データブロックを圧縮し、および/または、
少なくとも上記データブロックから、特に少なくとも上記データブロックおよび少なくとも1つの以前に送信または格納されたデータブロックから、上記利用可能な長さ以下の追加MAC長さを計算するように構成され、上記少なくとも1つの以前に送信または格納されたデータブロックは、以前に送信または格納されたデータフレームの一部として送信または格納されてもよく、上記デバイスはさらに、
上記データブロックと上記追加MACとを、特に予め定められたまたは予め規定された順序またはメッセージフォーマットで備える追加データフレームを作成するように構成される。
【0019】
上記データフレームは、上記ブロック/圧縮された長さおよび/または上記MAC長さを示す少なくとも1つのデータアイテムをさらに備えていてもよく、上記追加データフレームは、上記ブロック/圧縮された長さおよび/または上記追加MAC長さを示す少なくとも1つのデータアイテムをさらに備えていてもよい。
【0020】
実施形態において、上記デバイスはさらに、上記データブロックを暗号化するように構成されてもよい。
【0021】
実施形態において、上記デバイスは、少なくとも1つの集積回路を備えていてもよい。
実施形態において、上記デバイスはさらに、
上記圧縮されていない長さまたは上記ブロック長さを有する上記データブロックを準備するように構成された準備モジュールと、
少なくとも上記圧縮された長さまたは上記ブロック長さおよびデータフレームの上記最大長さから上記利用可能な長さを求め、少なくとも上記データブロックから上記MACおよび/または上記追加MACを計算するように構成された認証モジュールと、
上記データブロックと上記MACとを備える上記データフレーム、および/または、上記データブロックと上記追加MACとを備える上記追加データフレームを作成するように構成されたメッセージ生成モジュールとを備えていてもよい。
【0022】
上記デバイスは、上記データブロックが上記圧縮されていない長さよりも小さな上記圧縮された長さを有するように上記データブロックを圧縮するように構成された圧縮モジュールをさらに備えていてもよい。
【0023】
上記デバイスは、上記データブロックを暗号化するように構成された暗号化モジュールをさらに備えていてもよい。
【0024】
本発明の第4の局面は、本発明の第1の局面の方法、特にメッセージ検索または受信側で実行され得る方法要素を実行するように構成され得る、認証されたメッセージまたはデータフレームを受信または検索するためのデバイスに関する。実施形態において、上記デバイスは、
圧縮されたデータブロックまたはデータブロックとメッセージ認証コード(MAC)とを、特に予め定められたまたは予め規定された順序またはメッセージフォーマットで備えるデータフレームを受信または検索し、
特に少なくとも上記圧縮されたデータブロックまたは上記データブロックから確認MACを計算して、上記MACを上記確認MACと比較することによって、上記MACを確認するように適合または構成されてもよく、上記デバイスはさらに、
上記圧縮されたデータブロックを復元し、
上記データブロックをユーザおよび/またはアプリケーションに出力し、および/または、
上記データブロックと追加MACとを備える追加データフレームを受信または検索し、
特に少なくとも上記圧縮されたデータブロックまたは上記データブロックから追加確認MACを計算して、上記追加MACを上記追加確認MACと比較することによって、上記追加MACを確認するように構成される。本明細書において、上記MACと上記追加MACとは異なっていてもよい。
【0025】
実施形態において、上記デバイスはさらに、
信頼レベルを上記データフレーム、上記追加データフレームおよび/または上記データブロックに付与するように構成されてもよく、特に上記信頼レベルは、少なくとも、上記MACの確認が肯定的であることに基づいており、上記追加MACの確認が肯定的であることに基づいており、以前に受信されたデータフレームおよび/または追加データフレームのMAC、上記MACおよび/または上記追加MACの長さ、および/または、以前に受信もしくは検索されたデータフレームおよび/または以前に受信もしくは検索された追加データフレームのMACの長さの確認が肯定的であることに基づいており、上記デバイスはさらに、
上記信頼レベルが許容閾値を上回っていることを確認するように構成されてもよい。
【0026】
実施形態において、上記デバイスは、少なくとも1つの集積回路を備えていてもよい。
実施形態において、上記デバイスはさらに、
上記データフレームおよび/または上記追加データフレームを受信または検索するように構成されたメッセージ受信または検索モジュールと、
上記MACおよび/または上記追加MACを確認し、および/または、上記信頼レベルを上記データフレーム、上記追加データフレームおよび/または上記データブロックに付与するように構成された確認モジュールと、
上記データブロックを出力するように構成された出力モジュールとを備えていてもよい。
【0027】
上記デバイスは、上記圧縮されたデータブロックを復元するように構成された復元モジュールをさらに備えていてもよい。
【0028】
本発明の第5の局面は、メッセージを認証するためのシステムに関する。上記システムは、本発明の第3の局面に係る認証されたメッセージを送信または生成するためのデバイスと、本発明の第4の局面に係る認証されたメッセージを受信または検索するためのデバイスとを備える。
【0029】
本発明のこれらのおよび他の局面は、以下で説明する実施形態から明らかであり、以下で説明する実施形態を参照しながら説明されるであろう。
【0030】
本発明の主題は、添付の図面に示されている例示的な実施形態を参照して以下の本文でより詳細に説明されるであろう。
【図面の簡単な説明】
【0031】
図1】本発明の第1の局面の一実施形態のフロー図を概略的に示す図である。
図2】本発明の第1の局面の一実施形態のフロー図を概略的に示す図である。
図3】本発明の第1の局面の一実施形態のフロー図を概略的に示す図である。
図4】本発明の第1の局面の一実施形態のフロー図を概略的に示す図である。
図5】本発明の第3の局面の一実施形態を概略的に示す図である。
図6】本発明の第4の局面の一実施形態を概略的に示す図である。
図7】本発明の局面に係るデータブロック、データフレームヘッダ、データフレームおよびMACを一例として概略的に示す図である。
図8】本発明の第1の局面の実施形態のフロー図を概略的に示す図である。
図9】本発明の局面に係るデータブロック、データフレームヘッダ、データフレームおよびMACを一例として概略的に示す図である。
図10】本発明の第5の局面の一実施形態を概略的に示す図である。
図11】本発明の第5の局面の一実施形態を概略的に示す図である。
【発明を実施するための形態】
【0032】
図面において使用される参照符号およびそれらの意味は、参照符号の一覧に要約形式で一覧表示されている。原則として、図中、同一の部分には同一の参照符号が付けられている。
【0033】
例示的な実施形態の詳細な説明
例示的な実施形態が示されている図面を参照して、本発明をより詳細に説明する。
【0034】
言い換えれば、本発明の第1の局面は、データフレーム内のデータブロックを認証するための方法として説明することができ、上記方法は、
ブロック長さを有するようにデータブロックを準備するステップと、
上記データブロックをデータフレーム内に配置するステップと、
メッセージ認証コード(MAC)を配置するための、利用可能な長さを有する利用可能な空間を、上記データフレーム内または上記データフレームおよび少なくとも1つの追加データフレーム内に割り当てるステップとを備え、
上記データブロックを準備するステップは、上記データブロックを圧縮するステップを備え、および/または、
上記利用可能な空間は、上記データフレームおよび上記少なくとも1つの追加データフレーム内に割り当てられ、上記方法はさらに、上記追加データフレーム内の上記データブロックを複製するステップを備える。上記方法はさらに、少なくとも上記データブロックから利用可能な長さの上記MACを計算するステップ、上記MACを上記データフレーム内または上記データフレームおよび上記追加データフレーム内に配置するステップ、特に上記MACを計算するステップの前および/または上記データブロックを圧縮するステップの後に上記データブロックを暗号化するステップ、および/または、上記データフレームおよび/または上記追加データフレームを送信または格納するステップを備えていてもよい。実施形態において、上記MACは、少なくとも上記データブロックおよび少なくとも1つの以前に送信または格納されたデータブロックにわたって計算されてもよい。上記方法はさらに、上記データフレームおよび/または上記追加データフレームを受信または検索するステップと、上記MACを確認するまたは上記MACの少なくとも一部、特に上記データフレーム内に配置された上記MACの一部もしくは上記追加データフレーム内に配置された上記MACの一部を確認するステップとを備えていてもよい。上記方法はさらに、上記データブロックを復元するステップを備えていてもよい。実施形態において、上記方法はさらに、信頼レベルを上記データブロック、上記データフレームおよび/または上記追加フレームに付与するステップを備えていてもよく、上記信頼レベルは、上記確認されたMACまたは上記MACの上記確認された部分の長さに基づく。これらの代替単語において、上記MACは、追加MACを備え、すなわち、追加MACは、上記追加データフレーム内に配置されたMACの一部である。
【0035】
本発明の文脈において、メッセージは、たとえばデータブロックに含まれる1つの情報またはデータであってもよく、特にメッセージ受信または検索側などの受け取り手によるメッセージの消費を意図して、送信またはメッセージ生成側によって送信または格納されてもよい。さらに、本発明に係るデータフレームは、メッセージフレームであってもよい。本発明の文脈において、圧縮された長さは、圧縮されたデータブロック長さであってもよく、圧縮されていない長さは、圧縮されていないデータブロック長さであってもよく、ブロック長さは、特にデータブロック長さであってもよい。
【0036】
本発明は、データフレームまたは追加データフレームにおける利用可能な容量を使用または作成して、できるだけ多くの認証情報を伝えることを提案する。したがって、本発明の局面に係る方法およびデバイスは、利用可能な予備容量に対応することができ、MAC長さおよび追加MAC長さは、変化してもよい。このような予備容量は、特に情報、データまたはデータブロックのデータ圧縮によって作成されてもよく、または利用可能であってもよい。任意のデータ圧縮方法、特にハフマン符号化、ランレングス符号化、算術符号化、Lempel-Ziv符号化、Lempel-Ziv-WelchもしくはLempel-Ziv-Storer-Szymanski符号化などの可逆圧縮方法、または非可逆圧縮方法が適用可能である。データブロックのエントロピに応じて、非可逆圧縮の場合には許容可能な損失のレベルに応じて、圧縮されたデータのサイズおよび/または圧縮率は変化してもよい。予備容量を作成または使用するさらなるオプションは、パディングであってもよい。単語のバイト数の点でのメッセージフォーマットおよび/またはサイズ粒度の制約のために、データフレームは、ダミーまたはパディングビットで埋められてもよい。本発明の局面において、パディングまたはダミービットは、MACおよび/または追加MACの少なくとも一部に使用されてもよい。通信およびデータ格納では、往々にして、メッセージは冗長的に送信または格納される(たとえば、IEC61850におけるGOOSE送信の場合)。たとえば、同一のメッセージは、素な経路を介して送信されて、PRPまたはiPRPの場合のようなネットワークコンポーネントに対するシームレスなフェイルオーバーを実現してもよい。冗長なメッセージの生成および/または送信の場合、先行技術におけるメッセージ検索または受信側は、いかなる冗長的に検索または受信されたメッセージまたはデータフレームも廃棄する。本発明において、冗長なメッセージまたはデータフレーム、すなわち同一のデータブロックを備える追加メッセージまたはデータフレームは、追加MAC、たとえば認証情報の追加部分を備えていてもよい。メッセージ検索または受信側が、データブロックを備えるデータフレームを2つ以上検索または受信する場合、それは、利用可能なより多くの認証ビットを有するため、データフレームおよび/またはデータブロックの信頼レベルを向上させることができる。さらに、データブロックまたはフレームのMACの計算は、1つまたは複数の以前に送信または格納されたデータブロックへのデータブロックの連鎖方式も利用して、これらの以前に送信または格納されたデータブロックおよび当該データブロックのメッセージ認証が当該データブロックおよび以前に送信または格納されたデータブロックの信頼レベルを向上させてもよい。このような連鎖方式は、たとえば暗号ブロック連鎖方式(CBC-MAC)または暗号フィードバックMAC(CFB-MAC)に基づいていてもよい。一般に、認証されたデータフレーム、追加データフレームおよび/またはデータブロックに付与され得る信頼レベルが、本発明の局面において使用可能であり、この信頼レベルは、データフレームまたはデータブロックの認証に利用可能なビット数に対応してもよい。
【0037】
本発明の局面はさらに、データフレームおよび/または追加データフレームのエラー制御のための手段を備えていてもよい。これは、チェックサムまたは整合性チェック値を備えるデータフレームおよび/または追加データフレームによって実現可能であり、このチェックサムまたは整合性チェック値は、特にデータブロックおよび/またはMAC/追加MACなどのデータフレームまたは追加データフレームの他のまたは全ての他の要素にわたってメッセージ生成または送信者側で計算されてもよい。メッセージ検索または受信側で、このチェックサムまたは整合性チェック値がチェックされてもよく、エラーが発見された場合には、データフレームまたは追加データフレームを廃棄することができる。
【0038】
この方法の第1の局面に係る方法の例示的な実施形態は、送信者またはメッセージ生成側で実行され得る方法要素を備える図1および図2に示されている。本発明をよりよく理解するために、図7および図9は、データブロック、データフレームヘッダ、データフレームおよびMACを一例として概略的に示す図である。この方法は、本発明の第3の局面に係るデバイス100によって実行されてもよく、その例示的な実施形態は、図5に示されている。
【0039】
方法要素aにおいて、たとえば準備モジュール110が、データブロック、特に圧縮されていないデータブロック300を準備してもよい。このデータブロックは、格納または送信に関連する情報を備えていてもよく、特定のエントロピと圧縮されていない長さLまたはブロック長さLとを有し、圧縮されていない長さLまたはブロック長さLは、データフレームに含まれる情報量に対応する予め規定されたまたは固定の長さであってもよい。
【0040】
したがって、特に圧縮モジュール120がデータブロックを圧縮する方法要素bは、一般に圧縮されていない長さLよりも短い圧縮された長さLを有する圧縮されたデータブロック420をもたらす。データブロックのエントロピが高すぎる場合、圧縮率は、1または1に近い値であってもよく、この圧縮によってデータブロックの長さが減少することはない。
【0041】
冗長なメッセージのメッセージ認証の場合、データブロック300,420を圧縮する方法要素bは任意であり、本発明の目的は、図2に概略的に示されている方法の実施形態によって実現することができる。データブロックの圧縮がない場合、圧縮された長さLと圧縮されていない長さLとは明らかに一致し、同義で使用することができ、ブロック長さLと表記することができる。
【0042】
方法要素cにおいて、特に認証モジュール140が、少なくとも圧縮された長さLまたはブロック長さLおよび最大長さLmaxから利用可能な長さLavailを求める。これは、たとえば圧縮された長さLまたはブロック長さL、ならびに場合によってはデータフレームヘッダ410およびメッセージフォーマットに従った他のメッセージ部分の長さLを、データフレーム400の最大長さLmaxから減算することによって実現することができる。圧縮されていない長さLまたはブロック長さLに応じて、圧縮されていないデータブロック300のエントロピ、後に圧縮率、および/または、圧縮された長さL、利用可能な長さLavailは変化してもよい。たとえば、圧縮されていないデータブロック300のエントロピが低い場合、MAC430で利用可能なビットがより多く存在してもよく、利用可能な長さLavailは、より大きくてもよい。
【0043】
MACを計算する方法要素dにおいて、特に認証モジュール140が、少なくともデータブロック300,420からMACを計算する。この方法要素はさらに、利用可能な長さLavail以下の追加MAC長さLMAC2を有する追加MAC630を少なくともデータブロックから計算するステップを備えていてもよい。特に、認証鍵としての秘密鍵が使用されてもよく、MACおよび追加MACの計算に同一の鍵が使用されてもよく、または異なる鍵が使用されてもよい。セキュリティを強化するために、認証鍵は、定期的に変更されてもよく、すなわち鍵を変えられてもよい。これは、メッセージ生成または送信者側100が適切な鍵ロールオーバ情報をメッセージ受信または検索側200に提供することによって実現されてもよい。MACおよび/または追加MACの計算は、暗号ハッシュ関数によってなされることができる。この計算のための入力は、データブロック300,420を備えることができ、任意にデータフレームヘッダ410もしくは追加メッセージヘッダの少なくとも一部またはデータフレームもしくは追加データフレームの他の部分を備えることができる。この計算は、それがMAC長さLMACのMAC430および/または追加MAC長さLMAC2の追加MAC630を直接生じさせるような関数によってなされることができる。代替的に、MAC長さLMACよりも大きな長さを有する初期MACが計算され、次いで、このMACがそれに応じて切り捨てられてもよい。冗長なメッセージの生成または送信の場合、初期MACの切り捨てられる部分は、追加データフレームの追加MACであってもよい。より詳細には、n-1個(nは1よりも大きな整数)の追加データフレームが生成される場合、MAC長さLMACのn倍の長さを有する初期MACが計算されてもよく、その後、MACおよびn-1個の追加MACが切り捨てによって生成されてもよい。この例において、追加MAC長さLMAC2とMAC長さLMACとは一致する。他の実施形態において、たとえばMACおよび1つの追加MACが不均一な長さの初期MACから生成される場合、追加MAC長さとMAC長さとは、たとえば1または複数ビットだけ異なっていてもよい。いずれの場合でも、MACおよび/または追加MACは、データブロック300,420および任意にデータフレームヘッダ410またはデータフレーム400の他の部分のみから計算されるだけでなく、少なくとも1つの以前に送信または格納されたデータブロックにも基づいていてもよく、または少なくとも1つの以前に送信または格納されたデータブロックからも計算されてもよい。次いで、連鎖方式に関する上記の方法が利用されてもよい。本発明の第1の局面の方法の実施形態に従って、少なくとも1つの以前に送信または格納されたデータブロック自体も圧縮されてもよく、および/または、送信もしくは格納されてもよい。
【0044】
データフレーム400を作成する方法要素eにおいて、メッセージ生成モジュール150が、たとえば予め規定された順序またはメッセージフォーマットでデータフレームを作成してもよい。一例として、このようなメッセージフォーマットは、図7に概略的に示されており、図7では、一例として、データブロック420は、圧縮されたデータブロックであり、第一にデータフレームヘッダ410を備え、第二にデータブロック420を備え、第三にMAC430を備えていてもよい。MAC長さLMACは、データフレームの長さが最大長さLmaxを超えないように少なくとも圧縮された長さLまたはブロック長さおよび最大長さLmaxから求められた。ヘッダ410は、圧縮された長さLまたはブロック長さおよび/またはMAC長さLMACを示す少なくとも1つのデータアイテムを備えていてもよい。少なくとも1つのデータアイテムは、たとえばビット単位の圧縮された長さL/ブロック長さおよび/またはMAC長さLMACを備えていてもよい。このデータアイテムと、データフレームの長さと、少なくとも1つのデータアイテムにおいて規定され得るかまたは予め規定され得るメッセージ順序またはフォーマットとから、データフレームのどのビットがデータブロック420を備え、どのビットがMAC430を備えるかを導き出すことができる。特にメッセージ生成モジュールによって実行される冗長なメッセージの認証の場合、この方法はさらに、データブロック300,420と、追加MAC630と、圧縮された長さおよび/または追加MAC長さ610を示す少なくとも1つのデータアイテムとを備える追加データフレーム600を作成するステップ(e2)を備えていてもよい。この追加データフレームは、一例として図9に概略的に示されているように、データブロック300または圧縮されたデータブロックと、追加MAC630と、ヘッダ610とを備えていてもよい。たとえば、追加メッセージ610のヘッダは、圧縮された長さおよび/または追加MAC長さを示す少なくとも1つのデータアイテムを備えていてもよい。追加データフレーム600は、特にデータフレーム400と同一の予め規定された順序またはメッセージフォーマットを有していてもよい。冗長なメッセージの認証の場合、データフレームおよび追加データフレームは、初期MACのどのサブセットがそれぞれのMACまたは追加MACに使用されたかを示すさらなるデータアイテムを備えていてもよい。これは、MACおよび/または追加MACの確認を容易にする。
【0045】
この方法は、特に一例として図5に概略的に示されている本発明の第3の局面に係るデバイス100における送信者またはメッセージ生成側100で実行され得る、たとえば図4および/または図8に概略的に示されているさらなる方法要素を備えていてもよい。
【0046】
さらなる方法要素b2は、特に暗号化モジュール130がデータブロック300,420を暗号化するステップであってもよい。好ましくは、暗号化は、データブロック420の任意の圧縮bの後になされてもよい。なぜなら、暗号化は、一般に、データブロックのエントロピを増加させ、その結果、圧縮率が1または1に近い値になるからである。セキュリティの強化のために、認証鍵とは異なる暗号化鍵が使用されてもよい。認証鍵の場合のように、暗号化鍵は、定期的に鍵を変えられてもよく、メッセージ生成または送信者側100は、適切な鍵ロールオーバ情報をメッセージ受信または検索側200に提供してもよい。暗号化は、暗号化されたデータブロック420にわたってMAC430および/または追加MAC630が計算されるように、MACおよび/または追加MACを計算する前に実行されてもよく、データフレーム400および/または追加データフレームは、解読の前に認証されることができる。代替的に、データブロック420ならびにデータフレーム400および/または追加データフレーム600のさらなる部分は、MAC430および/または追加MAC630の計算の後に暗号化されることができ、このような場合、解読は、メッセージ認証の前に必要とされる。データフレーム400はさらに、送信または格納されてもよい。この方法要素fは、デバイス100における送信または格納モジュール160によって実行されてもよい。格納のために、デバイス100における内部メモリ、クラウドストレージ、外部データもしくはイベントレコーダ、またはリムーバブル記憶媒体などの任意の格納手段が使用されてもよい。送信のために、送信チャネル700(無線送信、近距離ワイヤレスネットワーク、WIFI、ブルートゥース(登録商標)、セルラー式送信、NFC、ローパワー・ロングレンジ・ワイドエリアネットワーク、有線もしくは光ファイバ通信リンク、および/または、パワーライン通信など)が利用されてもよい。格納手段または送信チャネル700は、送信または格納モジュール160に通信可能に結合されてもよい。さらなる方法要素f2は、特に送信または格納モジュール160が追加データフレーム600を送信または格納するステップであってもよい。この目的のために、データフレーム400を送信または格納するためのものと同一の送信チャネル700または同一の格納手段が使用されてもよい。代替的に、異なる送信チャネル(ワイヤレスネットワークの異なるチャネルなど)または異なる格納手段を使用して、より高い信頼性を実現してもよい。送信または格納モジュール160は、この異なる送信チャネルまたは格納手段にも通信可能に結合されてもよい。
【0047】
データフレーム400を送信または格納した後に実行される方法要素は、特に一例として図6に概略的に示されている本発明の第4の局面に係るデバイス200によって、メッセージ受信または検索側で特に実行されてもよい。これらの方法要素は、本発明の第1の局面の実施形態の一部として考えられてもよく、または、特にメッセージ生成または送信者側から独立してメッセージ受信または検索側で実行される場合には本発明のさらなる独立した局面として考えられてもよい。図3図4および図8は、これらの方法要素の実施形態を概略的に示している。データフレームおよび/または追加データフレームを受信または検索する方法要素gは、メッセージ検索モジュールまたは受信モジュール210によって実行されてもよく、メッセージ検索モジュールまたは受信モジュール210は、送信チャネル700または格納手段に通信可能に結合されてもよく、または通信可能に結合されるように適合されてもよい。その後、MACおよび/または追加MACを確認する方法要素hにおいて、特に確認モジュール220がMAC430および/または追加MACを確認する。この目的のために、MAC長さLMACおよび/または追加MAC長さは、データフレームまたは追加データフレームからそれぞれ、たとえばブロック長さ/圧縮された長さおよび/またはMAC長さ/追加MAC長さを示す少なくとも1つのデータアイテムから求められてもよい。特に、MAC長さLMAC、MAC430およびデータブロック300,420は、データフレーム400から検索されてもよい。さらに、認証鍵およびMAC430を計算するための方法と同一または同様の方法を使用して、少なくともデータブロック300,420から確認MACが計算されてもよい。その後、確認MACは、MACと比較される。たとえば、MAC長さLMACよりも大きな長さを有する確認MACが計算されると、MAC計算中の初期MACの切り捨てに従って、最初の数ビットまたは確認MACの別のサブセットのみがMAC430と比較されてもよい。MAC長さLMACを有する確認MACまたは確認MACのサブセットとMAC430とが一致する場合、データフレームは認証または確認される。追加MAC630を確認するステップは、MACを確認する方法要素と同様に、少なくともデータブロック420から追加確認MACを計算し、追加MACを追加確認MACと比較するステップを備えていてもよい。実施形態において、確認MACと追加確認MACとは一致し得る。この場合、MACと追加MACとは、初期MACの異なるサブセットであり、データフレームおよび/または追加データフレームは、これらのサブセットをより詳細に指定するためのさらなるデータアイテムまたは複数のさらなるデータアイテムを備えていてもよい。代替的に、たとえばより長い確認MACの中にMACおよび/または追加MACのビットシーケンスを見い出すことができる場合、MACおよび/または追加MACの肯定的確認が与えられてもよい。
【0048】
さらなる方法要素iは、特に復元モジュール240が、圧縮されたデータブロック420を復元するステップであってもよい。これは、MACを確認するステップの前または後になされてもよい。後者の場合、圧縮されたデータブロック420は、MAC430の確認が肯定的である場合にのみ復元されてもよく、または代替的に、圧縮されたデータブロック420は、いずれの場合にも復元されてもよい。MAC430の確認が肯定的でない場合、圧縮されたデータブロック420またはデータフレーム400は、一例として図3のフロー図に概略的に示されているように拒否されてもよい。これは、復元に必要なメッセージ検索または受信側200における計算および/またはストレージ資源を他のタスクに使用できるという技術的利点を有する。データブロック300,420および場合によってはデータフレーム400または追加データフレームの他の部分がメッセージ生成または送信者側100で暗号化された場合、この方法は、特に任意の解読モジュール230がデータブロック300,420を解読するステップをさらに備えていてもよい。さらに上記したように、圧縮されたデータブロック420は、好ましくは圧縮後に暗号化され、この場合、解読は、復元の前に実行される。メッセージ検索または受信側200での計算および/またはストレージ資源を節約するために、解読は、MAC430または追加MACの確認が肯定的である場合にのみ実行されてもよい。
【0049】
一例として、図4は、メッセージ生成または送信者側100およびメッセージ検索または受信側200でそれぞれ実行され得る、本発明に従って互いに独立して実行可能な方法要素のフロー図を示す図である。さらなる方法要素は、特に確認モジュール220が、信頼レベルをデータフレーム400、追加データフレームおよび/またはデータブロック(300,420)に付与するステップであってもよい。このような信頼レベルは、MAC長さLMACに基づいていてもよく、すなわち、MACの確認が肯定的である場合には、MAC長さが長ければ長いほど、高い信頼レベルがデータブロック420に付与されてもよい。なぜなら、MACの確認が肯定的であることにより信頼度が高くなるからである。MACの確認が肯定的でない場合、信頼レベルは、ゼロ、または、データフレーム400またはデータブロック300,420の情報が信頼できないものであるという表示に設定されてもよい。MAC430および/または追加MACがデータブロックから計算されるだけでなく、たとえば少なくとも1つの以前に送信または格納されたデータブロックからも計算される場合、信頼レベルは、MACおよび/または追加MACの確認が肯定的であること、ならびに任意にMAC長さおよび/または追加MACに基づくだけでなく、特に少なくとも1つの以前に送信または格納されたデータブロックを備える少なくとも1つの以前に受信または検索されたデータフレームおよび/または少なくとも1つの以前に受信または検索された追加データフレームの確認が肯定的であること、ならびに任意にこの少なくとも1つのデータフレームおよび/または追加データフレームのMAC長さにも基づいていてもよい。たとえば、連続して確認が肯定的であったデータフレームごとに、現在のデータブロック300,420および/または以前のデータブロックの信頼レベルを、確認に使用された追加ビット数だけ、たとえばMAC長さLMACおよび追加MAC長さだけ、向上させてもよい。信頼レベルは、連続して確認が肯定的であったMACのビット数に対応してもよく、または連続して確認が肯定的であったMACのビット数に基づいていてもよい。信頼レベルは、追加MACもしくはMAC単独の確認が肯定的である場合または確認が肯定的でない場合よりも、追加MACおよびMACの確認が肯定的である場合の方が高くてもよい。実施形態において、復元および解読する方法要素は、信頼レベルが許容閾値を上回る場合にのみ実行されてもよい。このさらなるステップも確認モジュール220によって実行されてもよい。
【0050】
この方法はさらに、特に出力モジュール250がデータブロック300,420を出力する方法要素jを備えていてもよい。データブロック420は、特にMAC430および/または追加MACの確認が肯定的である場合、または、信頼レベルが許容閾値を上回る場合にのみ、ユーザまたはアプリケーション260に出力されてもよい。信頼レベルは、データブロック300,420とともに出力されてもよく、その結果、ユーザまたはアプリケーションは、この信頼レベルに基づいて、データブロック300,420の情報をさらに処理すべきであるか否か、およびデータブロック300,420の情報をどの程度さらに処理すべきであるかを決定することができる。たとえば、特定の信頼レベルを下回る場合、アプリケーション/ユーザは、依然として情報目的でデータブロックを使用してもよいが、データブロックの情報に基づいて特定のアクションを開始することはできない。別の特定の信頼レベルを下回る場合、データブロックは完全に廃棄されてもよい。
【0051】
本発明の第3の局面は、認証されたメッセージを送信または生成するためのデバイス100に関し、このデバイス100は、一例として図5に概略的に示されている。本発明の第4の局面は、認証されたメッセージを受信または検索するためのデバイス200に関し、このデバイス200は、一例として図6に概略的に示されている。これらのデバイスは、互いに機能的に結合されて開示されているメッセージ認証方法の実施形態を実行するモジュールを備えていてもよい。冗長なメッセージの認証の場合、デバイス100は、圧縮モジュール120を必要とせず、デバイス200は、復元モジュール240を必要とせず、これらの場合、準備モジュール110は、暗号化モジュールまたは認証モジュール140に直接結合されてもよく、確認モジュール220または解読モジュール230は、出力モジュール250に直接結合されてもよい。このようなデバイスは、汎用コンピュータ、インテリジェント電子デバイス、IED(特に変電所自動化のためのIED)、および/または、IoTデバイス(特にIoTゲートウェイ)であってもよい。実施形態において、認証されたメッセージを送信または生成するためのデバイス100は、メッセージ検索または受信側で方法要素を実行するようにも適合されてもよい。図6には、ユーザ/アプリケーション260がデバイス200の外側、たとえばデバイス200に通信可能に結合されたさらなるデバイス内にあってもよいことが示されている。また、ユーザ260は、ヒューマン・マシン・インターフェイス(HMI)を介してデータブロック300の情報を受信する人間のオペレータまたはユーザであってもよい。
【0052】
図10および図11は、本発明の第5の局面に係るメッセージを認証するためのシステムの実施形態を概略的に示す図であり、このシステムは、認証されたメッセージを送信または生成するためのデバイス100と、認証されたメッセージを受信または検索するためのデバイス200とを備え、これらのデバイスは、送信チャネル700または共通の格納手段へのアクセスを介して互いに通信可能であってもよい。図11は、データフレーム400および追加データフレーム600が同一の送信チャネル700を介して送信される冗長なメッセージの送信の実施形態を示している。
【0053】
図面および上記の説明において本発明を詳細に説明してきたが、このような説明は、例証的または例示的であって、限定的ではないと考えられるべきである。開示されている実施形態に対する変更は、図面、開示内容および添付の特許請求の範囲を検討することによって、クレームされている発明を実施する当業者によって理解され、なされることができる。特許請求の範囲において、「備える(comprising)」という語は、他の要素またはステップを排除するものではなく、不定冠詞「a」または「an」は、複数を排除するものではない。特定の要素またはステップが特定の請求項に記載されているという事実だけで、これらの要素またはステップの組み合わせを有効に使用することができないというわけではなく、具体的には、実際の請求項の従属関係に加えて、さらなる意味のある請求項の組み合わせはいずれも開示されていると考えるべきである。
【0054】
参照符号の一覧
100 メッセージソース、送信者側、メッセージ生成側、認証されたメッセージを送信または生成するためのデバイス
110 準備モジュール
120 圧縮モジュール
130 暗号化モジュール
140 認証モジュール
150 メッセージ生成モジュール
160 送信または格納モジュール
200 メッセージ検索側、受信者側、認証されたメッセージを受信または検索するためのデバイス
210 メッセージ検索モジュール、受信モジュール
220 確認モジュール
230 解読モジュール
240 復元モジュール
250 出力モジュール
260 ユーザ、アプリケーション
300 データブロック、圧縮されていないデータブロック
420 データブロック、圧縮されたデータブロック
400 データフレーム
410 データフレームヘッダ;圧縮された長さ、ブロック長さおよび/またはMAC長さを示すデータアイテム
430 MAC
600 追加データフレーム
610 追加メッセージのヘッダ;ブロック長さ、圧縮された長さおよび/または追加MAC長さを示すデータアイテム
630 追加MAC
700 送信チャネル
ブロック長さ
圧縮されていない長さ
圧縮された長さ、圧縮されたデータブロックの長さ
max 最大長さ
avail 利用可能な長さ
MAC MAC長さ、MACの長さ
MAC2 追加MAC長さ、追加MACの長さ
データフレームヘッダ長さ
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11