エンベロープ暗号化（KMSを使用）とECDH
職場で、メッセージをクライアントに送信するときに基本的なエンベロープ暗号化を実装しました。 AWS KMSを使用していて、そこにマスターキーがあります。データキーを取得し、AES-GCMでメッセージを暗号化して、暗号化されたデータキー、IV、タグなどでメッセージを送信します。次に、クライアントはAWS KMSを呼び出してデータキーを復号化し、メッセージを復号化します。 AWSのドキュメントを見てこれを実装しました。新しいキーを生成する前に、データキーをしばらくの間再利用するためにキャッシュしています。
私よりも暗号化が得意なある同僚は、メッセージと一緒にキーを送信するため、これは安全ではないと考えています。これは、マスターキーを理解することにつながるのではないでしょうか。彼は、AESキーを生成するために秘密/公開キーと共有秘密を使用して、より良いキー配布を持つECDHを推奨します。これに関する問題は、公開鍵と秘密鍵のペアをどこかに保存する必要があり、これらの両方の方法でシークレット（KMSキーまたはプライベートキー）にアクセスする必要があることです。
これらの異なる方法がどれほど安全であるかについて他の意見を探しています。本当に脆弱性の違いは何ですか？
編集：明確化：マスターキーは、特定のクライアントへのこれらのメッセージのデータキーを暗号化するためにのみ作成される特定のキーで、他にはありません。私が使用したAWSのドキュメント： https://docs.aws.Amazon.com/kms/latest/developerguide/concepts.html#enveloping
数学的には、暗号化された安全な疑似乱数ジェネレータを使用してデータキーが適切に生成された場合、マスターキーをメッセージから戻すことはできません（AESが破損していないと想定しています）。ただし、運用上、このスキームは「ベビーベッド」を提供しますマスターキーを推測しようとする攻撃者に。 「既知の平文」攻撃を可能にします。
敵対者があなたのマスターキーの一部を持っていると信じている場合を考えてみましょう。彼は、このシステムから傍受されたメッセージをテストとして使用して、推測が正しいかどうかを確認できます。または、AESに対するそのような攻撃が知られるようになった場合は、アルゴリズムを巻き戻すことができます。
このスキームは、「キーは単一の目的に使用する必要がある」という原則に従っていません。マスターキーは引き続き各メッセージに存在するため、各データキーはマスターキーを他のすべてのキーと共有しています。
とはいえ、私はシステムがどのように構成されているかを知るのにAWSのKMSに精通していませんが、私が使用するすべてのKMSシステムは、個々のユーザーにアプリケーションのキーのみにアクセスする許可を与えることによってキー管理を実行します。ユーザーは、システムの実際のマスターキーを使用してデータキーを直接暗号化するアクセス権を持ちません。そのため、説明が完全ではない可能性があり、マスターキーとして参照していたのは、単にアプリケーション固有のキーを参照しているだけかもしれません。その場合、キーの漏洩がKMS内の他のキーの漏洩につながることはありません。組織の他のキーは、たとえあなたのキーが侵害されたとしても、侵害されることはありません。
その場合でも、同僚の助言を得て、マスターキーでデータキーを直接暗号化するのではなく、キーの交換について説明したような非対称キーソリューションを使用するように変更することを検討します。秘密キーはメッセージと共に送信されることはないため、送信者と受信者にKMSを使用して秘密キーを解読させることができます。マスターキーに対する既知の平文攻撃を取り除きます。