SSL / TLSなしで安全なチャネルを構築する
暗号化機能が制限された複数の組み込みデバイスとHTTPサーバー（ある種のWebサービスの可能性があります）の間に安全なチャネルを構築するための可能なオプションを探しています。
1.コンテキスト
デバイスは、デバイスの開発フレームワークを介して、HTTP、一部の対称鍵アルゴリズム、および一部のハッシュ関数のみをサポートします。 残念ながらSSL/TLSはサポートされていないため、ここではオプションではありません。
起動時に、デバイスは特定の構成を取得するためにHTTPサーバーに接続します。デバイスが実際に送信される前に、デバイスを完全に制御できます。
識別された脅威のいくつかは次のとおりです。
- 悪意のある設定ファイルのダウンロード。
- （別のデバイスからの）間違った構成ファイルのダウンロード。
- 同じ構成ファイルの複数のダウンロード。
- 無許可の第三者による構成ファイルの盗聴。
- HTTPサーバーへの不正アクセス（ここでは必ずしも関係ありません）。
構成ファイルを取得するプロセスは、理想的には1回だけ行う必要があります。設定ファイルがダウンロードされると、その特定のデバイスのHTTPサーバーへのアクセスは破棄されます。
2.提案
デバイスを実際に落とす前にデバイスに一時的な共有シークレットをロードできるため、秘密キーを送信せずにデバイスを認証するためにkeyed-HMAC（ハッシュメッセージ認証コード）を使用することを考えていましたワイヤー上。 AWS API認証 に似たものを設計し、デバイスの一意のシリアル番号をキーIDとして使用します。
認証されると、デバイスはリソース（この場合は構成ファイル）へのアクセスを許可されます。特定された脅威の一部を軽減するために、構成ファイルは転送中に暗号化および署名（？）する必要があります。
この目的のために、認証された暗号化モードを使用することを考えていました。
CBCのAES256モードとHMAC-SHA256しか使用できません。他の「適切な」認証済み暗号化アルゴリズムは、フレームワーク内では使用できません。
3.質問
それは意味がありますか？
十分に複雑なものに複雑さを追加することを避けるために、プリロードされた共有シークレットをHMAC関数のキーとして使用し、共有シークレットハッシュをAES暗号化の暗号化キーとして使用するオプションはありますか？
特定のシナリオで特定された脅威を軽減することはできますか？
プロセスを簡略化して、そのセキュリティプロパティを維持できますか？
3.リソース
サーバーとクライアントはどちらも秘密を知っているので、通信がルートで変更されていないことを信頼できます。事実上、両者間の共有キーを介した接続の使用は、ハンドシェイクなしでSSLを使用するようなものです。通常、SSLは非対称暗号化を使用して、a）通信の1つ以上の関係者を検証し、b）通信の共有鍵を確立します。
ただし、両方を所有しているため、デバイスを解放する前に、部分的に信頼を確立できます。デバイスのキーが危険にさらされていない場合（これは、使用方法に応じた主な弱点です）、デバイスが、デバイスから発信されたメッセージを正しく復号化する方法で通信できる場合。したがって、リプレイ攻撃のみを心配する必要がありますが、単純なメカニズムであればそれを阻止できます（たとえば、現在のメッセージよりも古いメッセージの再利用や使用を回避するためのカウンターまたはタイムスタンプ）。