One of the kind of attacks that we are trying to prevent here with such mechanisms is called "Key Compromise Impersonation", where a party obtained your private key (not the other party's) and is trying to impersonate other parties to you.
Now, I'll try to tackle your different questions in a different order as it makes more sense to me and should help with the global understanding of the underlying conditions:
Q.3
- It seems to me C(0e, 2s) schemes with bilateral key confirmation should also prove the possession of the static private key, why is the ephemeral key required?
No, when using 2 static keys and 0 ephemeral key, an attacker knowing only your private key, but not the other's party private key is able to compute the same shared secret as you.
The problem is somewhat hidden in the text, e.g. in 6.3.3.3 it says:
The successful completion of the key-confirmation process provides each party with assurance that the other party has derived the same secret Z value
So, what you're getting confirmation about is really just that the derived secret is the same as yours, but not that the other party actually used their knowledge of the secret static key they claim to hold.
So here you're able to ensure there's no Person in the Middle tampering with your key agreement: you've both derived the same agreed upon key.
why is the ephemeral key required?
Because it's an ephemeral key that we just created, the other party won't know its corresponding ephemeral secret key (assuming an adversary with only knowledge of your static secret key).
So during key agreement, since you are combining your secret ephemeral key with their (claimed) public static key, if they don't know their (claimed) secret static key they won't be able to perform the same derivation as you did using the ephemeral public key you sent them.
With an ephemeral key here is what's happening usually on your side:
- you combine your ephemeral secret key with their (claimed) static public key, you get a secret $Z_e$
- you combine your static secret key with their (claimed) static public key, you get a secret $Z_s$
- you use both $Z_e$ and $Z_s$ in your derivation process to get the final shared secret $Z$
- you use a key confirmation process to ensure you both derived the same shared secret $Z$
And the other party is doing more or less the same, but they are using your public ephemeral key instead along
(This is a summarised classical C(1e,2s) key agreement.)
Now, an adversary knowing your secret key is able to mimic step 2, but cannot mimic step 1, thus cannot perform step 3 correctly and will get caught in step 4, if you use an ephemeral key.
But if you don't have an ephemeral key then you are only relying only on step 2 in step 3, and thus impersonation isn't detected in step 4.
This is really the gist of what's being said in 5.6.2.2.3.2 first condition (emphasis mine):
- The recipient of the static public key contributes an ephemeral public key to the key-agreement process, one that is intended to be arithmetically combined with the claimed owner’s (i.e., the other party’s) static private key in computations performed by the claimed owner. (If an appropriate key-agreement scheme is employed, the claimed owner will be challenged to demonstrate current knowledge of his static private key by successfully performing those computations during the transaction.)
This means that step 1 and 3 needs to occur.
And then we have the second condition:
- The recipient of the static public key is also a key-confirmation recipient, with the claimed owner (i.e., other party) serving as the key-confirmation provider. (By successfully providing key confirmation, the claimed owner can demonstrate ownership of the received static public key and current knowledge of the corresponding static private key.)
This basically means that step 4 must occur, hence providing the assurance that the key derivation process was carried as expected and thus providing assurance that the step 1 couldn't be "faked" by someone not knowing the secret static key of the received static public key, but instead your own secret static key.
Q.2
- C(2e, 2s) schemes with bilateral key confirmation should also satisfy the given conditions, right?
Yes, they usually do. They can actually satisfy to a much stronger version, where you also obtain assurance of the possession of the (claimed) secret ephemeral key. If you look at section 5.6.2.2.4, the C(2e, 2s) schemes that are satisfying the conditions 2 and 3 naturally satisfy the conditions 1 and 2 of 5.6.2.2.3.2.
Notice that only the DH and One Pass Unified model are quoted there, that's because as it is said in 7.1 (emphasis mine):
If an MQV scheme (MQV2 or Full MQV) will be employed during a transaction with an adversary who is in possession of a compromised static private key (or a compromised implicit signature corresponding to that static private key), the adversary is limited to masquerading as the owner of the compromised key pair (or as the owner of the static key pair corresponding to the compromised implicit signature). The use of the Full Unified model or dhHybrid1 scheme, however, offers the adversary additional opportunities for masquerading: If an adversary compromises an entity’s static private key, then the adversary may be able to impersonate any other entity during a Full Unified model- or dhHybrid1-based key-agreement transaction with that entity.
The MQV schemes in their "two passes" forms are already resistant to these Key Compromise Impersonation attacks and do not require the extra step that the DH-based or Full Unified model-based schemes do, which are detailed in 5.6.2.2.3.2 and 5.6.2.2.4. This is presumably why they are not explicitly quoted in 5.6.2.2.4.
Q.1
And eventually I think the answer to your first question naturally follows from the details above:
- The key agreement calculations with key confirmation also proves the possession of the static private key, so there is no need to ask other questions to the other party, is this correct?
No it does not, it could also prove possession of your static private key instead. This is why we need the ephemeral key steps.
