0
$\begingroup$

I'm a bit confused in the way nonces are used in these processes to prevent replay attacks. Heres How I think it works during SSL:

Nonces are exchanged during stage one of the handshake protocol. Nonces of the other party will be different so the keys will be different. The random numbers are used to create symmetric keys using the master_secret. Even if Eve could use the same random numbers as in the previous connection, the server will most likely not, therefore the keys will be different in the attempted replay connection.

Is that correct? I'm a bit confused how they work in MAC.

Improve this question
$\endgroup$
2
  • $\begingroup$ What do you mean by MAC? Is that a Message Authentication Code (which is used in SSL)? $\endgroup$
    – poncho
    Commented Jan 15, 2015 at 15:23
  • $\begingroup$ Message Authentication Code. I was reading that the nonces are sent with the MACs which prevent replay of legitimate messages. I want to know how it works. $\endgroup$
    – cryptoconfused
    Commented Jan 15, 2015 at 15:25

1 Answer 1

Reset to default
1
$\begingroup$

Well, you have it right in how nonces are used to make sure that the keys in different SSL sessions; this effectively prevents someone from taking an SSL record from one session, and injecting it into another -- because the keys aren't the same, it won't pass the integrity tests.

However, that's not the only place we care about replay attacks; we can also be concerned about someone taking an SSL record from one session, and replaying it latter in that same session. Because the keys are the same, we can't use the above logic.

So, what SSL transmitter does when it computes the MAC for a record is logically prepend the current byte count; that is, the number of bytes that have passed through this SSL connection so far. This byte count is not sent over the wire, but it is implied. When the receiver gets the record, it also logically prepends its current byte count (which should match the transmitter's); and so it should compute the same MAC. After processing the record, both the transmitter and the receiver updates its current byte count (based on how long the record was).

Now, if someone should replay that record, the receiver would then logically prepend its current byte count (which would not match what the transmitter prepended when it originally generated the record); because that count is different, the receiver would generate a different MAC, and so the record would be rejected.

That gives you the answer, I want to close with one clarification; you mentioned SSL; well, the current version of the protocol is known as TLS. There are several versions (TLS 1.0, 1.1 and 1.2); TLS 1.2 handles the byte count slightly differently; however it does the same job. There's also something known as DTLS; for that protocol, the count (which is a count of records, and not bytes) is explicitly sent within the record.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Nitpicks: the count is records for (stream)TLS including SSL also. Since only a whole record is MACed (or AEADed) the security result is the same. And I see no difference in 1.2. DTLS makes the record count explicit and also the renegotiation count because UDP packets can arrive out of order. (But this matters only if you use renego in DTLS, and I see less possible benefit than in TLS which is already not very much.) $\endgroup$
    – dave_thompson_085
    Commented Jan 16, 2015 at 23:37
  • $\begingroup$ @dave_thompson_085: you're right; SSL prepends a record count. My bad; my memory assured me that it was a byte count. As for 1.2, my difference I was alluding to was in inserting it into the MAC vs. putting it as a part of the AAD. $\endgroup$
    – poncho
    Commented Jan 16, 2015 at 23:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.