Iot sdk thesis

Message 
Description/Content 
ClientHello
Version of TLS Client would like to use + a list of ciphers it supports + random 
string that server will require later 
ServerHello
TLS version, cipher choice + random string that the client will need later 
Certificate 
Certificate issued by Certificate Authority that server as proof of identity 
ServerHelloDone
Indication that Server hello is done 
ClientKeyExchange
Pre-master secret (used by both sides to generate session keys) 
ChangeCipherSpec
Client
’
s indication to server that all messages from now on are encrypted with 
the generated session keys 
Finished
Hash of handshake components encrypted with session key (Server uses to 
verify the integrity of the handshake) 
ChangeCipherSpec
Server
’
s indication to client that all messages from now on are encrypted with 
the generated session keys 
Finished 
Hash of handshake components encrypted with session key (Client uses to 
verify the integrity of the handshake) 
Table 2.5.1.2 TLS Handshake Messages [24] 

---

27 
Just as with the records, the lost previous messages result in inability to decrypt the 
next message which eventually results in a failed handshake. Transport layer is responsible for 
the retransmission, in case of a lossy handshake [23]. 
2.5.2
 
DTLS Overview 
As mentioned before, DTLS is a minor redesign of TLS to work in absence of reliable, 
in-order packet delivery and replay detection of TCP. The modified DTLS records have been 
shown in the code snippet below: 
struct
{ 
ContentType type; 
ProtocolVersion version; 
uint16 epoch; 
//new field
uint48 sequence_number; 
//new field
uint16 length; 
opaque payload[length]; 
} DTLSRecord; 
Just like TLS, the data is carried in records in DTLS as well. The DTLS records are fit 
into a single UDP datagram, which eliminates the need to store record fragments. Two new 
fields are introduced in DTLS: 16-bit epoch and 48-bit sequence number.