Type (1 byte): cho biết dữ liệu của trường Data Payload là thuộc định dạng
gói tin nào của giao thức Lw-TLS. Có 4 loại gói tin được sử dụng:
Gói tin của giao thức Handshake: Type có giá trị là 0x01.
Gói tin Alert: Type có giá trị là 0x02.
Gói tin Change Cipher: Type có giá trị là 0x03.
Gói tin Data, chứa dữ liệu đã mã hóa của các ứng dụng: Type có giá trị là 0x07.
Sequence Number (2 byte): chứa thứ tự của các gói tin gửi và nhận.
Sequence Number sẽ được đếm tăng dần khi mỗi gói tin được gửi đi. Bên nhận sẽ dựa vào thứ tự đó có thể sắp xếp lại các gói tin đến bị sai thứ tự trong quá trình
Trang 46
truyền. Việc kiểm tra thứ tự sẽ giúp ngăn chặn Replay Attack, khi kẻ tấn cơng gửi lại các gói tin, đã được gửi từ Client node hợp lệ trước đó, tới Server node.
Length (1 byte): Chứa độ dài của cả gói Lightweight TLS Record. Việc
thêm trường độ dài, giúp hỗ trợ việc xử lý gói tin tại node nhận được chính xác hơn.
Payload: chứa dữ liệu của 1 trong 4 loại gói tin gồm gói tin của giao thức
Handshake, gói tin Alert, gói tin Change Cipher, gói Data.
4.7.3.2 Giao thức Change Cipher:
Type Length Data
Hình 4. 21 - Lw-TLS Record Payload của giao thức Change Cipher và Alert
Khi Client Node có yêu cầu đổi bộ Key dùng để giao tiếp của giao thức Lw- TLS, Client Node sẽ gửi 1 gói Change Cipher có trường Type là Change Cipher Request giá trị là 0x01, Length là tổng độ dài của gói Change Cipher theo byte. Data sẽ gồm số ngẫu nhiên Client-Nonce mới được mã hóa bằng AES với key là Session Key và một đoạn mã xác thực MAC được tính bằng hàm HMAC cho cả Lw-TLS Record.
Server Node sẽ kiểm tra gói Change Cipher, nếu hợp lệ Server Node sẽ gửi cho Client Node gói Change Cipher có trường Type là Change Cipher Response giá trị 0x02 có chứa số ngẫu nhiên Server-Nonce mới và Session ID mới, và đoạn mã MAC nhằm xác thực cho cả gói Lw-TLS Record. Server-Nonce và Session ID được mã hóa bằng AES với key là Session Key hiện tại. Nếu gói Change Cipher nhận được không hợp lệ, Server Node sẽ không gửi phản hồi.
Client Node khi nhận được Session ID và Server-Nonce mới sẽ thực hiện tính tốn lại Master Key, Session Key, HMAC Key và lưu trong một bộ nhớ tạm thời. Tiếp đó, Client Node sẽ tính tốn Finish Data bằng hàm Pseudorandom
Trang 47
Function dùng thuật toán HMAC MD5 (PRF-MD5) như bên dưới với các thông số mới, rồi gửi tới Server Node gói Change Cipher Finish với Type có giá trị 0x04 và Data là Finish Data.
PRF-MD5(New-Master-Key, Finish Label, New-Master-Key|| New-Session-Key||
New-HMAC-Key|| New-SessionID|| New-Nonce) (4. 15)
Trường Data của gói Change Cipher này là là Finish Data đã được tính phía trên. Lúc này Client Node sẽ bật một Sended Packet Timer có thời gian 60s, ở mode gửi lại gói tin vừa gửi. Nếu khơng thấy Server Node phản hồi gói tin Lw- TLS Record vừa gửi sẽ được gửi lại. Mục đích của Timer này là gửi lại gói tin trong trường hợp gói tin đó bị mất.
Server Node sau khi nhận được gói Change Cipher Finish sẽ thực hiện kiểm tra Finish Data. Nếu hợp lệ, Server Node sẽ tính tốn lại Pre-Master Key, Session Key, HMAC Key. Tính HMAC Data, gửi gói Change Cipher Finish. Sau đó Server Node sẽ áp dụng bộ Key mã hóa mới.
Client Node sau khi nhận được gói Finish từ Server Node sẽ thực hiện việc xác thực Finish Data. Nếu hợp lệ Client Node sẽ áp dụng bộ Key mã hóa mới. Nếu khơng hợp Client Node sẽ khơng làm gì cả và chờ cho Sended Packet Timer timeout.
Sended Packet Timer được Set để gửi lại gói tin trong trường hợp không nhận được gói tin phản hồi mong muốn. Nếu Sended Packet Timer timeout 5 lần liên tục thì nó sẽ gửi một cảnh báo lỗi tới người vận hành hệ thống.
4.7.3.2 Giao thức Alert:
Cấu trúc gói tin của giao thức Alert giống như của giao thức Change Cipher được mơ tả trong hình Hình 4.19. Khi có lỗi hay vấn đề xảy ra trong quá trình sử dụng giao thức Lw-TLS, gói Alert cảnh bảo sẽ được gửi đi. Khi thực hiện giao thức Handshake nếu có lỗi xảy ra, gói Handshake Alert được gửi đi có trường Type giá trị là 0x01, Length là tổng độ dài của gói Alert đó theo byte. Trường Data khơng dùng.
Trang 48
Gói Alert được thiết kế như trên cho phép giao thức Lw-TLS có thể được bổ xung thêm nhiều loại cảnh báo khi tiếp tục nghiên cứu thêm.
4.7.4 Giao thức Lw-TLS Handshake
4.7.4.1 Các gói tin của giao thức Lw-TLS Handshake
Type
(0x01) Length Session ID Nonce
Hình 4. 22 - Lw-TLS Payload của gói tin Handshake Hello
Type
(0x02) Length PAN ID Public Key Signature Hình 4. 23 - Lw-TLS Payload của gói tin Handshake Certificate
Type
(0x04) Length Finish Data
Hình 4. 24 - Lw-TLS Payload của gói tin Handshake Finish
Trường Type (1 byte): cho biết gói tin thuộc định dạng nào trong các gói tin
của giao thức Lightweight TLS Handshake. Giao thức Handshake có 3 định dạng gói tin là Hello có Type là 0x01, Certificate có Type là 0x02 và Finish có Type là 0x04.
Trường Length (1 byte): Là tổng độ dài của gói tin Handshake.
Session ID (1 byte): cho biết thông tin ID của kết nối. ID này được tạo ra
random bởi Server node và sẽ được kiểm tra khi Client node cần khởi tạo lại. Trong trường hợp Server node nhận được yêu cầu khởi tạo kết nối đầu tiên, trường ID trong gói hello của Client node sẽ khơng được xét đến, và Server node sẽ tạo Session ID ngẫu nhiên và gửi lại Client Node. Nếu quá trình thực hiện giao thức Lightweight TLS Handshake diễn ra thành công, giá trị Session ID này sẽ được thống nhất là Session ID của kết nối và được lưu lại tại Server Node và Client Node. Mỗi Server node chỉ cho phép tối đa một kết nối tại một thời điểm.
Trang 49
Khi Client Node muốn thực hiện lại giao thức Handshake, nó phải gửi đúng Session ID đã được Server Node ghi lại trước đó, nếu khơng việc thiết lập kết nối sẽ bị hủy bỏ và Server node sẽ không gửi bất cứ phản hồi nào. Việc kiểm tra Session ID trước, rồi mới thực hiện các bước tiếp theo của giao thức Lightweight TLS Handshake nhằm mục đích hạn chế các tấn cơng DoS, vì kẻ tấn cơng cần phải biết chính xác Server Node đang giữ Session ID có giá trị bao nhiêu.
Nonce (1 byte): có 2 số Nonce được tạo ngẫu nhiên và sử dụng trong giao
thức Handshake, một được tạo bởi Server Node và một được tạo bởi Client node. Số Nonce sẽ đóng vai trị trong việc tạo ra các Session Key, HMAC Key từ Pre- Master Key. Số Nonce cũng được sử dụng để tạo ra gói Finish nhằm kiểm tra kết nối có thực hiện thành cơng hay chưa. Số Nonce cũng có vai trị chống lại các kiểu tấn công của bên thứ 3 (man-in-middle) trong quá trình thực hiện giao thức Handshake.
Certificate (81 Byte): Gồm các thông tin là PAN ID, Public Key và
Signature. PAN ID (1 byte) là ID của mạng. Public Key có độ dài 40 byte chứa Public key của mã hóa ECC-160 của một Node. Signature là chữ ký điện tử được ký bởi Private Key của một Certificate Authority (CA) bằng thuật toán ECDSA cho nội dung gồm PAN ID và Public Key đính kèm.
Finish Data (16 Byte): được tính bằng hàm Pseudorandom Function (PRF)
dùng thuật toán HMAC-MD5 như sau.
PRF-MD5 (Master-Key, Finish_Label, Master-Key||Session-Key||HMAC-Key||Session_ID||Nonce)
4.7.4.2 Mô tả hoạt động của giao thức Lw-TLS Handshake
Giao thức Lightweight TLS Handshake có 3 phase.
Phase 1: Khởi tạo kết nối, tạo Session ID, trao đổi số ngẫu nhiên Nonce,
kiểm tra khởi tạo kết nối có hợp lệ.
Client node muốn khởi tạo kết nối cần gửi cho Server gói Hello, Server sau khi nhận gói Hello, kiểm tra tính hợp lệ và gửi lại gói Hello có cấu trúc như Hình 4.22. Trong đó Type củ a gói Hello có giá trị 0x01, Length là độ dài của gói Hello
Trang 50
có giá trị 0x04, Session ID là 0x00 nếu đây là kết nối đầu tiên hoặc là Session ID được lưu la ̣i nếu đã có kết nối tới Server node từ trước.
Server Client Client_He llo (Sesion ID, Nonce Client) Server_H
ello (Session ID, N
once Server) Client_Cer tificate Handshake Protocol Server_C ertificate Finish Finish Check Certificate OK->Calculate Pre-master Key
->Master Key -> Session Key,
HMAC Key Check Certificate
OK->Calculate Pre-master Key ->Master Key -> Session Key,
HMAC Key
Calculate Finish Message PRF(Master Key,Finish_label,Master- Key||Session-Key, HMAC- Key||SessionID||Nonce-Server) Check Finish Message
OK -> Calculate Finish Mesage Calculate Finish Message
PRF(master Key,Finish_label,Master-Key|| Session-Key|| HMAC-Key|| SessionID||Nonce-Client) Check Finish OK-> Success Phase 1 Phase 2 Phase 3
Hình 4. 25 - Hoạt động của giao thức Lightweight TLS Handshake
Trong giao thức Handshake, mỗi khi gửi 1 gói tin Client node sẽ bật Sended Packet timer, nếu trong 60s khơng thấy Server node phản hồi thì Client Node sẽ hiểu là gói tin gửi đi bị lỗi mất gói và thực hiện lại giao thức Handshake từ đầu. Nếu Sended Packet Timer timeout 5 lần liên tục thì nó sẽ gửi một cảnh báo lỗi tới người vận hành hệ thống.
Server node sẽ kiểm tra Session ID và lưu lại Client-Nonce nhận được. Nếu Session ID không hợp lệ, Server node sẽ không phản hồi. Nếu Session ID hợp lệ, Server node sẽ phản hồi gói Hello, có Session ID và số Server-Nonce được tạo
Trang 51
ngẫu nhiên. Session ID mới được tạo này sẽ là Session ID của kết nối khi giao thức Handshake thực hiện thành công.
Phase 2: Client và Server node trao đổi Certificate, thực hiện quá trình xác
thực, tạo một bộ Key dùng cho việc mã hóa và xác thực dữ liệu trao đổi.
Sau khi nhận gói Hello phản hồi từ Server Node, Client sẽ gửi Certificate của mình cho Server node bằng gói tin như Hình 4.23. Type có giá trị 0x02. Length có giá trị 83.
Server Node sau khi nhận được gói Certificate, sẽ tiến hành xác thực thơng số ID và Public Key, chữ ký điện tử Signature bằng thuật toán ECDSA. Nếu kết quả hợp lệ, Server node sẽ thực hiện tính tốn Pre-Master Key bằng giải thuật ECDH. Sau đó sẽ tính tiếp Master Key bằng hàm Pseudorandom Function (PRF) dùng thuật toán HMAC MD5 như sau:
PRF(Pre-Master-Key, MasterKey_label, Nonce-Server, Nonce-Client) (4. 16)
Rồi từ Master Key sẽ tính tiếp Session Key và HMAC Key như sau:
PRF(Master-Key, SessionKey_label, Nonce-Server, Nonce-Client) (4. 17)
PRF(Master-Key, HMACKey_label, Nonce-Server, Nonce-Client) (4. 18)
Sau đó Server sẽ gửi gói Certificate chứa thơng tin của mình tới Client Node. Nếu quá trình xác thực bị lỗi, Server sẽ gửi gói Alert trở lại Client Node. Client nhận được gói Alert sẽ thực hiện lại giao thức Handshake từ đầu.
Client Node sau khi nhận được gói Certificate, sẽ tiến hành xác thực thơng số ID và Public Key. Nếu kết quả hợp lệ, Server node sẽ thực hiện tính tốn Pre-Master Key bằng giải thuật ECDH. Sau đó sẽ tính tiếp Master Key bằng hàm Pseudorandom Function (PRF) như Server. Rồi từ Master Key sẽ tính tiếp Session Key và HMAC Key bằng hàm PRF. Nếu kết quả xác thực Certificate của Server Node là không hợp lệ, Client sẽ thực hiện lại giao thức Handshake từ đầu.
Trang 52
Phase 3: Kiểm tra giao thức Handshake đã thực hiện thành công hay chưa.
Thông báo kết quả.
Sau khi đã tính xong các Key sẽ dùng cho việc mã hóa và xác thực, Client sẽ tính Finish-Data bằng hàm PRF bên dưới và chèn vào Gói Finish như Hình 4.24.
PRF(Master-Key, Finish_label, Master-Key|| Session-Key|| HMAC-Key||
SessionID||Nonce-Server) (4. 19)
Gói Finish sẽ được gửi tới Server Node, Server Node sẽ thực hiện kiểm tra bằng cách tính lại hàm PRF như trên và so sánh với giá trị nhận được. Nếu giá trị tính ra bằng với Finish-Data nhận được thì kết quả hợp lệ và Server Node sẽ tính lại Finish-Data bằng hàm PRF như sau:
PRF(Master-Key, Finish_label, Master-Key||Session-Key||HMAC-
Key||SessionID||Nonce-Client) (4. 20)
Sau đó Server Node gửi gói Finish cho Client Node. Nếu kết quả kiểm tra khơng hợp lệ, Server Node sẽ gửi gói Alert về Client Node.
Client Node khi nhận được gói Finish từ Server Node sẽ thực hiện việc kiểm tra tương tự. Nếu giá trị tính ra bằng với Finish-Data nhận được thì sẽ thơng báo giao thức Handshake thực hiện thành công kèm theo bộ Key Mã hóa Master Key, Session Key, HMAC Key và Session ID của kết nối.
Trang 53 Begin Import in Lw-TLS Packet Buffer Receive Packet TLS Record Type = Handshake TLS Record Type = Alert TLS Record Type = Change Cipher TLS Record Type = Data Handshake Type = Hello Handshake Type = Certificate Handshake Type = Finish Check MAC
code MAC is valid?
Decrypt Data
Payload
Session ID is
valid?
Send Hello Packet, Wait Certificate Packet
Certificate is
valid?
Calculate Pre-
Master Key, Master Key, Session Key,
HMAC Key
Send Server
Certificate Packet,
Wait Finish Packet
Finish Data is valid? Calculate Finish-Data Send Alert Packet Change Cipher Type = Server Response
Create new Server Nonce, new
Session ID. Calculate MAC Code. Calculate new temp Master Key,
Session Key, HMAC Key
Send Change Cipher
Packet has new Server Nonce, new Session ID,
MAC Code
Change Cipher
Type = Finish
Calculate Finish Data Apply New Keys, Session ID.
Encrypted Data Handshake Change Cipher Alert Y Y Y Y Response Data is valid? Change Cipher Finish Data is valid? Y Y Y Y Y Y Y Y Y N N N N Y N N Y N N
Send Finish Packet,
Lw-TLS is Success Y N N N N N Send Data N Encrypt Data, Calculate MAC, Create Lw-TLS Data Packet
N
Send Change
Cipher Finish Data
Y
Trang 54 Begin Import in Lw-TLS Packet Buffer Receive Packet Sended Packet Timer Is Timeout? TLS Record Type = Handshake TLS Record Type = Handshake Alert TLS Record Type = Change Cipher TLS Record Type = Data Handshake Type = Hello Handshake Type = Certificate Handshake Type = Finish Check sequence,
MAC code MAC is valid?
Decrypt Data Payload
Send Certificate Packet. Set Sended Packet Timer
Certificate is
valid?
Calculate Pre-Master
Key, Master Key, Session Key, HMAC
Key.
Calculate Finish-Data
Send Finish Packet Set Sended Packet
Timer Finish Data is valid? Notiffy Lw-TLS Handshake Protocol is Success Send Hello Packet Change Cipher Type = Client Request
Get new Server Nonce, new
Session ID. Calculate new temp Master Key, Session Key, HMAC Key. Calculate Finish Data.
Send Change Cipher Finish
Packet. Set Sended Packet Timer with Mode Resend Lw-
TLS Packet if Timeout.
Change Cipher
Type = Finish Apply new Keys
Send Hello Packet
Or Previous Packet.
Set Sended Packet Timer
Encrypted Data Handshake Change Cipher Alert Y Y Y Request Data is valid? Change Cipher Finish Data is valid? Y Y Y Y Y Y Y Y N N N N N Y N N Y N N Y N Get Session ID Y N N N N Send Data Encrypt Data, Calculate MAC, Create Lw-TLS Data Packet Y N N Y N N Timeout Times = 5 Notify Problem Y N Send Hello Packet Y
Trang 55
Server Client
Client_He
llo (Session ID,
Nonce Clie nt)
Server_H
ello (Session ID, N
once Server) Client_Cer
tificate
Handshake Protocol Data Payload
Server_Certificate Finish
Finish
Check Finish Data
Type Length Session ID Nonce
Type: 0x01 Length: 0x04
Session ID: Old Session ID Nonce: Client Nonce Type: 0x01
Length: 4
Session ID: New Session
ID, random number
Nonce: Server Nonce
Type Length ID Public Key
Type: 0x02 Length: 83 ID: 1 byte PAN ID
Public Key: 40 byte ECC-160 Public
Key của Client
Signature: 40 byte ECC-160
Signature được tạo bởi Self-CA
Signature
Type: 0x02 Length: 83 ID: 1 byte PAN ID
Public Key: 40 byte ECC-160
Public Key của Server
Signature: 40 byte ECC-160
Signature được tạo bởi Self-CA
Type Length Finish Data
Type Length Finish Data
Type: 0x04 Length: 18
Finish Data: PRF(master Key,
Finish_label, Master-Key|| Session- Key|| HMAC-Key||
SessionID||Nonce-Server)
Type: 0x04 Length: 18
Finish Data: PRF(master Key,
Finish_label, Master-Key|| Session- Key|| HMAC-Key||
SessionID||Nonce-Client)
Type Length Session ID Nonce
Type Length ID Public Key Signature
Hình 4. 28 - Lw-TLS Record Payload của giao thức Handshake
4.7.5 Mã hóa và giải mã dữ liệu
Kênh liên lạc của các thiết bị trong mạng cảm biến không dây được đảm bảo các yếu tố bảo mật gờm tính riêng tư (confidentiality), tính khơng thể chối từ (integrity), tính xác thực (authentication), tính sẵn sàng (availability). Trong q trình thực hiện câu truy vấn của cơ sở dữ liệu TinySQL, việc đảm bảo tính bảo mật được thực hiện bằng cách thực hiện mã hóa câu truy vấn và nội dụng phản hồi bằng thuật toán AES 128 dùng Session Key đã được trao đổi một cách an