Iot sdk thesis

2.5.3
 
Epoch 
Given the unreliable nature of UDP, the datagrams might get lost. If the datagram 
carrying ChangeCipherSpec message, after session renegotiation, is lost, the receiving end-
point might try to use the old cipher, to decrypt the message encrypted by new cipher suite. 
Epochs are used by the endpoints to resolve this ambiguity. 
For example, consider a client transmitting data records 3, 4, 5 and 6. Record number 4 
is lost. Epoch number is incremented by 1 when ChangeCipherSpec happens. So, if record 
number 3 and record number 5 have the same epoch value, it means that record number 4 WAS 
not ChangeCipherSpec record. Hence, 5 and 6 can be decrypted as per previous cipher 
specification. 
2.5.4
 
Sequence Number 
Sequence numbers are for replay detection. Sequence numbers are incremented by 1 for 
every record and reset to 0 whenever ChangeCipherSpec happens. A bitmap is implemented 
and the bit corresponding to most-recently received packet is set. If a packet with same sequence 

---

28 
number is received again, it might have been sent by a fraudulent entity to appear trustworthy. 
It can be inferred for the bitmap that the record has been re-received and it is discarded. In case 
of TLS, since records always arrive in order, keeping track of most recent record is enough to 
detect replays.
2.5.5
 
DTLS Handshake [24] 
DTLS handshake is different to TLS handshake in two ways:
Stateless cookie exchange for DoS attack prevention
DTLS handshake has to take place over unreliable UDP datagrams. It makes the DTLS 
handshake vulnerable to two kinds of Denial-of-Service (DoS) attacks: Standard resource 
consumption attack and amplification attack. Resources consumption attack is when an attacker 
floods a legitimate resource (e.g. a server in this case) or entity to make them unavailable for 
the legitimate entity (e.g. a client) [26]. Amplification attack is when the attacker sends a 
ClientHello message to server that appears to have come from the client. Server then sends a 
ServerHello message to client which is too large for the client, making it temporarily defunct. 
With, “stateless cookie exchange” technique of DTLS, the server sends “cookies” in 
HelloVerifyRequest message, which the client must replay to demonstrate that it can receive 
the packets at its claimed IP address. Only after the successful cookie replay does the server 
allocate the resources for new connection to the entity trying to connect as a client [27]. Servers 
with very low latency expectations can, however, skip the cookie replay steps and the 
handshake in that case is identical to TLS handshake. DTLS handshake has been shown in 
Figure 2.5.5.1.