MAC-次に、認証された鍵交換のためにSIGMAプロトコルで暗号化します
SIGMAプロトコル2003年に提案し、TLS 1.3およびIKEで使用されるが、「SIGN-と-MAC」の略で、暗号化を使用して、必要に応じて保護アイデンティティをすることができます。
以下に示すSIGMA-Iバリアントは、MAC-then-encryptアプローチを使用していることを示しています。
ここに $\{\dots \}_{K} $ キーを使用した対称暗号化機能の下での括弧間の情報の暗号化を示します $K$。
鍵交換プロトコルにencrypt-then-MACではなくMAC-then-encryptを使用する特別な理由はありますか？MAC-then-encryptとencrypt-then-MACの比較を見ると、恣意的と思われるよりも良い答えを見つけることができませんでした。
編集： この関連する回答にリンクされているRFC 7366は、encrypt-then-MACを優先する（D）TLS通信（ハンドシェイクについては何も言われていません）というヒントをいくつか示しています。特に、次のように述べています。
TLSとDTLSは、元のSecure Socket Layer（SSL）プロトコルが1990年代半ばに指定されたときに安全であると見なされていたMAC-then-encrypt構造を使用しますが、それはもはや安全であるとは見なされません。
興味深いことに、H Krawczyk（SIGMAの作成者）は、2001年にSIGMAの前に通信を保護するための暗号化と認証の順序（またはSSLの安全性）を書いています。
回答
Arnaudは私にこの問題を明確にするように頼んだ。
認証付き暗号化モードまたはencrypt-then-MACを使用する必要があるのは事実であり、この論文ではそれを明示的に述べています。確かに、上記の図に続く論文の説明文（のセクション5.2https://webee.technion.ac.il/~hugo/sigma-pdf.pdf）この問題に対処します。それは言う：
暗号化機能（3番目のメッセージで適用される）はアクティブな攻撃に耐性がある必要があるため、何らかの形式の整合性保護を組み合わせる必要があることを強調します。[16]のような機密性と整合性を組み合わせた変換を使用するか、暗号文の上に計算されたMAC関数を使用して従来の暗号化モード（CBCなど）を使用できます[3、26]。
つまり、 $\{...\}_{K_e}$認証付き暗号化スキームを使用する必要があります。（認証された暗号化の必要性は、SIGMA-Rの形式でより完全なプロトコルを示す付録Bでも繰り返されています）。
暗号化の下に（ID上に）MACがあるという事実は、MACがSIGMAプロトコルの（必須の）部分であり、暗号化とはまったく関係がないためです（特に、IDの保護を気にしない場合でも必要です）。 ）。したがって、「MAC-次に暗号化」のように見えますが、この暗号化モードとは関係ありません。
注：認証付き暗号化が3番目のメッセージにのみ必要であるとテキストに記載されている理由は、同じ段落の冒頭で述べたように、SIGMA-Iは、アクティブな攻撃者からイニシエーターのIDを保護し、パッシブな攻撃者からレスポンダーのIDを保護するためです。攻撃者。したがって、レスポンダーのIDを暗号化するには、認証されていない暗号化で十分な受動的攻撃に対するセキュリティのみが必要です。実際には、両方のフローに同じ暗号化スキーム、つまり両方に認証付き暗号化を使用するため、これは実際には学術的な意見です。
これは多少の推測ですが、これはシグマが設計されたモジュール方式によるものだと思います。つまり、Hugo KrawczykがSigmaを設計したとき、彼が求めていた主なセキュリティプロパティは、基本的に2つのもので構成されるAKEセキュリティでした。
セッションキーの識別不能性：攻撃者は、実際のセッションキーとランダムなセッションキーを区別できないようにする必要があります。そして
明示的エンティティ認証（EA）：プロトコル参加者がプロトコルの実行を完了すると、実際に期待されるパーティと通信しており、このパーティが実際に同じセッションキーを計算したことが保証されるプロパティ。
EAプロパティは基本的に、活性と認証を保証する重要な確認ステップです。これは、キーを使用して、プロトコルデータの一部に対してMACを計算することによって実現されます。$K_m$ セッションキーの派生に使用されたものと同じマスターシークレットから派生。
重要なのは、暗号化をまったく行わなくても、AKEセキュリティ（つまり、プロパティ1と2）を実現できるということです。実際、KrawczykがSigmaがAKEセキュリティを満たしていることを証明したとき（これがどの紙であったか思い出せません。後で見つけようとします）、彼は単に暗号化ステップがまったくないと想定します。（彼はまた、TLSv1.3の前身である彼のOPTLS論文でもこれを行っています）。
私が言ったように、ほとんどの鍵交換プロトコルの標準的なセキュリティ目標は、BellareとRogawayによる元の論文以来、基本的にすべてAKEセキュリティに関するものでした。ただし、KrawczykがSigmaを設計したとき、彼は別の非標準の機能、つまりID保護も追加したいと考えていました。しかし、暗号化なしのSigmaプロトコルがAKEセキュリティを実現することを彼がすでに示していたことを考えると、ID保護も取得するために、これに暗号化を追加するだけで済みました。したがって、MAC-then-Encrypt。
ただし、MACと暗号化のこれら2つの使用法はどちらかと言えば直交しており、目的が異なります。内部MACはEAセキュリティを提供し、外部暗号化はID保護を提供することになっています。
また、ノートシグマは通常ことない暗号化-その後、-MACを使用します。特に、IKEv2でのSigmaのインスタンス化では、外部暗号化には、標準のEtM方式での暗号化の外部に追加のMACが伴います。IKEv2のでは、内側MACキーが呼び出されSK_p*、外側の暗号化キーが呼び出されるSK_e*と、外側MACキーが呼び出されSK_a*（*いずれかであるiか、rこのメッセージは、イニシエータまたはレスポンダによって作成されているかどうかに応じて）。さらに、IKEv2の新しいインスタンス化では、外部暗号化が専用の認証済み暗号化アルゴリズムに置き換えられています。この場合、SK_a*キーは使用されません（そして、EtMの質問全体が無意味になります）。シグマのTLSv1.3インスタンス化では、認証された暗号化のみが使用されます。ただし、暗号化の内部（AEまたはEtM）には、EAセキュリティを提供することを目的とした内部MACがあることに注意してください。