クライアントとサーバーが1つずつあるシステムを作成しています。
クライアントは定期的に(5秒または10秒ごとに)少量のデータを(UDPを使用して)サーバーに送信します。
クライアントとサーバーの両方にキー/パスフレーズを安全に配置することができます。これらのキー/パスフレーズが何であるかを他の誰かが知る必要はありません。私はいつでもサーバーにアクセスできます。クライアントにアクセスできなくなった場合でも、サーバーで簡単にキー/パスフレーズを変更できます。
私のセキュリティ上の懸念は2つあります。
クライアントで対称暗号化を使用して、サーバーが(復号化したときに)使用できるペイロードに特定の一意のトークンを埋め込んで、クライアントが本人であることを確認できるかどうかを確認できますか?または、非対称(DTLS?)の公開/秘密鍵ペアソリューションが必要ですか?それともどちらも私が望むことをしませんか?
質問であなたが「懸念」と呼んだのは、情報セキュリティの世界では通常「保護目標」と呼ばれているものです。あなたのケースでは、機密性(真ん中の人は交換されたデータを読み取ることができないはずです)と信頼性(既知の良好なエンティティのみがデータを送信できるはずです)を探しています。
真正性は通常、メッセージまたはデータの一部が実際に発信元であると主張するソースから発信されていることを意味するように定義されていることに注意してください。これはまさに質問の核心です。クライアントが1つしかないことがわかっている場合は、対称キーを配布することで、データの機密性と信頼性の両方を保証できます(キーが漏洩しない場合)。
ただし、複数のクライアント(またはサーバー)が存在する(または将来存在する可能性がある)場合は、次のいずれかを行う必要があります。
したがって、スキームの各参加者に証明書を発行するPKIで非対称暗号化を使用することは、より将来性のあるソリューションになる可能性があります。これにより、各クライアントの秘密鍵でメッセージに適切に署名して、信頼性を確保できます。
どちらの方法でも、おそらく真正性と機密性以上のものを探していることに注意してください(完全性が頭に浮かびます。おそらく、途中の潜在的な人間がクライアントとサーバーの間で交換されるデータを変更できるようにしたくないでしょう)。したがって、すべての暗号化操作に対して確立されたアルゴリズムとプロトコルを実装する、適切に検証された高レベルの暗号化APIを必ず使用してください。
(暗号には多くの落とし穴があります。たとえば、多くの場合、真ん中の男が適切に構成されたメッセージをキャプチャして後で再生することは簡単です。そのような攻撃を考えて、暗号プリミティブ自体はおそらくお勧めできません)。