Diskussion:Lösungsvorschlag Information Security 2005

Aus VISki
Wechseln zu: Navigation, Suche

Security Bootstrapping

b) wouldn't it be possible to realise A.<->.B with only one modification, namely G_A => G_{A,B}? The paths would then look als follows:




which would yield both A.->B and B.->A. Since the exam states that two modifications are necessary, I seem to miss something here. Any ideas? Also, with the solution proposed I can't seem to find a path B.->A anymore...

--Shial 16:31, 1. Jul. 2009 (CEST)

I think your solution's correct (I don't think the proposed solution works either). As far as I understand it, the exam does not ask for a solution which includes two modifications, but for two different solutions. How many modifications they need is left to you (but they should be "minimal").

Other possibilities would be:

  • B.->A: A.->F changes to A.->.F
  • A.->B: A trusts D and J
  • A.->B: F=.H changes to F.=.H AND (H=.E changes to H.=.E OR A trusts J)

(But I'm not sure wheter the two latter motifications still count as minimal)

--Daniela (24. Jul. 09)

Security Transformations

b) I think it should read "confidental" channel, not secure channel here, if we assume that Bob has no other means than public display to deliver the message (since anyone can mess with the ciphertext in this case). If Bob has access to the trusted messenger though, which is suggested by this solution, I don't see why the subsequent communication is just secret. It would even be secure if there wasn't any box at all, since the messenger can deliver messages securely and authentically anway.

Another interpretation I see is that the delivery of the box can be seen as sharing a secret key ("A.=.B" in the dot calculus) at time t1, if the limited computing power of Bob suffices to generate a MAC, the subsequent communication is secure aswell. This interpretation would also fit the comment from question c), that a security property from b), namely authenticity, is missing now.

--Shial 13:06, 2. Jul. 2009 (CEST)

b) I would suggest using the box to do cipher block chaining at Bobs side (e.g. using cipher feedback mode). Bob can then encrypt the plaintext using CBC, then continue the encryption process using the cipher text as input. This last part (double encryption of the cipher text) acts as a MAC to actually achieve authenticity from Bob to Alice. Rvjr 11:01, 26. Jul. 2009 (CEST)

If we agree on the solution to a) being correct, then authenticity from B to A in b) follows already from the solution to a), since putting the box into a mailbox only Bob can open is no different from bringing the box to bob by a trusted messenger that can't tell from whom the box was being sent. And in this case, the messenger is even able to confirm that it was indeed Alice that sent the box. So the question should be whether more than authenticity can be achieved. If Alice kept the secret key to herself, the box acts as a shared key after being securely delivered to Bob as long as further communication only goes from B to A (recall that the Box can only encrypt, not decrypt). This implies that the channel from B to A at t2 is both authenticated and secret/confidential. Another interesting question now would be what security properties could be achieved for the channel from A to B at t2, assuming that A no longer has access to the trusted messenger and considering B's limited computing power. But the exercise clearly speaks of communication from B to A, so I don't think this was asked for. --Smf68 17:17, 4. Aug. 2010 (CEST)

I would suggest the following:

a) (A -->o B) & (A o<-- B) => (A o<-- B)

(A -->o B): A brings the box to B's mailbox and knows, that only B can open it's mailbox. One could also interpret this as a one-sided key, since A knows that only be can encrypt.

(A o<-- B): The box can encrypt and the key is hidden. The only one who has a copy of the key is A (even though that B doesn't know that). So if someone different than A has the box, there exists a confidential channel to A.

(A o<-- B): Since A knows, that B has the box, A can conclude that all messages encrypted by the box (I assume a unique encryption key) originate from B. However, an attacker could always corrupt or immitate messages, such that authenticity is lost (without MAC or PKC). But confidentiality is still there, since A is the only one with a decryption key.

b) (A o-->o B) & (A o<-- B) => (A o<-- B)

Here, the only difference to a) is, that B knows, who he's talking to, but the resulting channel (to my mind) stays the same. Hereby i assumed that there doesn't exist a secure channel at time t' < t2 from B to A (meaning, that the trusted messenger brings something back to A). --Teeh 15:44, 18. Aug. 2010 (CEST)

a) louis, 19. Aug. 2010

I think neither solution is correct [see below]. Imho we cannot guarantee anything about the resulting channel, because:

  • the resulting channel is not confidential: Eve can insert his own encryption box into Bob's mailbox (Bob has no way of checking the authenticity of the box) and then read&decrypt the message Bob sends to Alice.
  • <wrong>the resulting channel is not authentic: Without knowing the encryption box at all Eve can still send random cipher-texts to Alice over the insecure channel. The encryption-box does not append a MAC or anything, therefore Alice cannot verify the authenticity of the message.</wrong>

Luftibus: I think that Bob can actually do a MAC... it says in the text that he can do simple operations such as concatenation and XOR, also it says the box uses a block cipher. So I would say, that the channel is authentic.

louis: Ok, I agree with what Rvjr said above. However, I think Luftibus does not realize the subtle issues of the situation. You need a key to MAC so you cannot just "do concatenation and XOR" to MAC. Hoever Bob could do the following (similar to what Rvjr proposed): Sending "M||crypt(M)" , (where M denotes the message). Note again that sending "crypt(M)" alone is not enough.

A security protocol

b) I'm pretty confused. In my opinion, the solution follows immediately from the two additional assumptions:

BS --> MT : BS,K_BS,{BS,K_BS}K_CA^-1

MT --> BS : {K,MT}K_BS,

MT --> BS : {P}K

The only 2 changes i made are: BS sends its certificate, signed by CA and MT sends its name together with the session key, such that BS is able to assign K to MT. But the second change would actually not be necessary, since the only requirement is to fix the attack described in a). In a) we were able to intersect (BS --> MT), which is not possible anymore (i guess :) ). --Teeh 17:43, 18. Aug. 2010 (CEST)

Another security protocol

I don't think that the second way in fixing the protocol leads to success: "Another solution would be to replace H_Kas in message 3 (the message that is replayed in the attack) by H_Kbs. This way, B would be able to check whether S really received (g^x,g^y,A,B) and generated H_Kbs(g^x,g^y,A,B). If an attacker replayed an earlier message 3 H_Kbs(g^x',g^y',A,B), B would realize this isn't the MAC corresponding to the new g^x, g^y and thus would reject it. This renders the attack described in b) useless."

We don't know how B chooses y and if it really remembers previous messages. In this case anyone with enough messages recorded can still use the replay attack. Another question about this is that in my opinion HM_k(M) = M, H_k(M) means that the messages are not encrypted so the only way this replay attack works is when B chooses a Y which has already been recorded before since it can always verify if the g_x, g_y in M3 matches.

I agree with you, that if the attacker records enough messages (while always using the same x, otherwise he would need even more!), it is possible to use the replay attack again. But actually this argument also holds for the case where we use nonces, you just have to record enough ;).--Teeh 19:45, 18. Aug. 2010 (CEST)
Oh I completely missed the fact that in M3 its only sending the hash H_Kas(gx, gy, A, B) instead of message and hash HM_Kas(gx, gy, A, B) .. then the fix makes sense of course. --Joker 21:45, 18. Aug. 2010 (CEST)

Formalizing the Dolev-Yao Intruder

d) I think its possible that given a private key I can generate the corresponding public key. Using ssh-keygen the manual says:

 -y          Read private key file and print public key.
In my opinion, this is not possible. The private key is the multiplicative inverse (modulo the group-order) of the public key and vice versa. In other words: when creating a key-pair, it's up to you which key you define to be the public key, and which one to be the private key. So if you're able to compute the public key from the private key efficiently, then you're also able to do the inverse.--Teeh 21:06, 18. Aug. 2010 (CEST)