限られた組み込みシステム間の通信の保護
私は現在、組み込みシステム上の限られた物理通信チャネルを介した通信を強化しようとしています。
シナリオ
このシステムは、小さな組み込みアプリケーションではかなり一般的だと思います。
関連する組み込みシステムは、OSのない小さなマイクロコントローラーであり、安全な物理環境にあると見なすことができます。接続チャネルは攻撃者が物理的にアクセス可能であり、必要に応じてメッセージに干渉する可能性があります。
さまざまな通信チャネルが可能です。たとえば、RS485またはRS232。アドレス指定や大まかな整合性（ビットフリップのCRC16など）などを処理する大まかなプロトコルがあり、その上に構築できます。遅いTCPであると考えてください。
各通信パートナーは、CAとして機能できるルート証明書を知っており、署名された独自の証明書（+キー）を持っています。証明書は自己署名された楕円曲線prime256v1
mbedTLSライブラリは、これらのシステムで使用できます（DH、AES、..を使用）。
ほとんどの場合、利用可能なインターネットはありません。
システムは時間を維持でき、十分な乱数を作成できます
プライバシー、信憑性、誠実さを実現したいと考えています。
それがどのように解決されるか
暗号化プロトコルのルールは、自分で実装しないことです。残念ながら、このユースケースに一致するものは見つかりませんでした。
また、既存の質問を閲覧しましたが、探していた完全な解決策を提供するものは何もありませんでした。
最後に、この回答では、独自のプロトコルを実装することが最後のオプションとして示されています。
これが私が以下に説明する解決策を思いついた理由です-しかし私はそれについて完全には確信していません。私は上に配向のDiffie-ヘルマン鍵交換の認証方法については、この答えは、整合性をチェックする方法については、この答えと私のようにAプロトコルを実装する方法についていくつかのアイデアを与えるこのスレッドを。
通信を保護するためのプロトコル
最初に行うことは、対称鍵Kをランダムに生成することです。最初に送信されるのはハンドシェイクメッセージです。次のフィールドがあります。
| フィールド | 説明 |
|---|---|
| DH | ディフィー・ヘルマン鍵交換MSG G K |
| 証明書 | 送信デバイスの証明書（チェーン） |
| MsgIdNonce | ランダムな64ビット値 |
| 署名 | Certの秘密鍵を使用した完全なメッセージの署名 |
両方のデバイスがそのようなメッセージを送信（および受信）します。
メッセージを受信すると、次のことが行われます。
- 証明書が予想されるCAによって署名されているかどうかを確認します（チェーン内にある必要があります）
- msgがcertとそのキーで適切に署名されているかどうかを確認します
これらのチェックが送信を成功したときに受信したDH G Kのメッセージは、対称鍵を計算するために使用されます。
この時点から、アプリケーションはAES-CBCで暗号化されたメッセージを送信できます。メッセージは比較的頻繁に失われる可能性があるため、IVは常にメッセージに含まれています。
メッセージ形式は次のとおりです。
| フィールド | 説明 | 暗号化 |
|---|---|---|
| IV | AESの最初のランダムIV | 番号 |
| MsgIdNonce | ハンドシェイク/最後のMsgIdNonce + 1または+2 | はい |
| アプリケーションデータ | 保護するデータ/コマンド | はい |
| CMACが64ビットに切り捨てられました | 整合性をチェックするためのMAC | はい |
メッセージを受け入れるには、
- 予想されるMsgIdNonce（最後に受信したものより1つまたは2つ上）を持っている-リプレイ攻撃を防ぎ、1つのメッセージを失うことを可能にする
- 有効なCMACを持っている-整合性への攻撃を防ぐ
- 最大で受け取られます。最後のメッセージからT秒後-遅延攻撃の防止
期待どおりでない場合は、ハンドシェイクが再度送信され、新しく交換されたパラメータを使用してメッセージが再度送信されます。
質問
私は正しい道を進んでいますか、それともまったく別のことを試してみる必要がありますか？
これは私のセキュリティ目標を提供しますか、それともここで明らかな脆弱性を見逃しますか？
これは機能しますか？
同様の問題に直面している私や他の組み込みエンジニアを助けていただければ幸いです。
回答
暗号化プロトコルのルールは、自分で実装しないことです。残念ながら、このユースケースに一致するものは見つかりませんでした。
DTLSを検討しましたか？これは同じ問題に対処しようとし（タイムスタンプを除いて、データグラムにタイムスタンプを挿入することで追加できます）、すでに検討されています。もう1つの可能性はIPsecです。ただし、DTLSは、発生している問題への対処に近いように見えます（保護しているデータトラフィックがIPトラフィックである場合を除く）。
そうは言っても、ここにあなたが概説したプロトコルに関するいくつかの考えがあります：
2つの連続したメッセージがドロップされた場合（たとえば、誤って受信された場合）はどうなりますか？双方は何が起こったのかを理解しますか、それとも後続のすべてのメッセージをドロップしますか（「nonceは2を超えてインクリメントする必要がない」ルールのため）？
彼らがキーの再生成を試みると仮定すると、これはどのように調整されますか？一方がまだキーの再入力を行っていないと考え、もう一方の側がキーの再入力を行っていると考えた場合、古いキーで暗号化されたメッセージはどうなりますか？一般に、暗号文のタグの下に暗号化されているキーを含めると便利です（DTLSでは、これは「エポック」です）。
通信チャネルはメッセージを並べ替えることができますか？あなたの場合はできないと思いますが、可能であれば、それをどのように処理するかを考える必要があります。
誰かが以前の（有効な）ハンドシェイクメッセージを挿入するとどうなりますか？それはどのように物事を混乱させるでしょうか？
データ暗号化パスでは、CBC暗号化とCMAC整合性を使用します。これは実行可能なソリューションですが、正しく統合されていないと、さまざまなパディング攻撃が発生する可能性があります。現在の方法は、両方を行うAEADモード（GCMやChacha20 / Poly1305など）を使用することです。
暗号化されたトラフィックは単方向ですか、それとも双方向ですか？トラフィックが双方向に流れる場合、同じキーのセットを使用して両方のトラフィックのセットを保護しますか？
「何かが期待どおりでない場合は、ハンドシェイクが再度送信され、次に、新しく交換されたパラメーターを使用してメッセージが再度送信されます。」-それはどのように機能しますか？受信者がメッセージが気に入らないと判断した場合、送信者はどのようにしてメッセージを再送信することを知っていますか？