5. SIP UA nhận lấy bản tin và cố gắng tìm chứng nhận khóa cơng khai ở bên trong hợp khóa (keyring) của nó. Nếu như chứng nhận khóa cơng khai trong hợp khóa có một đối tượng mà khớp với trong header From trong bản tin SIP (vì đây là bản tin yêu cầu, cịn với trường hợp là đáp ứng SIP thì sẽ so sánh trường header To với đối tượng chứng nhận khóa cơng khai), thì SIP UA phía nhận sẽ so sánh nó với chứng nhận mà nó nhận được. Nếu chúng khác nhau, thì SIP UA có thể cảnh báo người dùng và yêu cầu sự xác nhận của người dùng trước khi tiếp tục phiên. Nếu người dùng chấp nhận chứng nhận khóa công khai mà nhận được, thì phải thêm khóa đó vào trong hộp khóa cùng với các chứng nhận khóa công khai khác được lưu trữ trong danh mục lúc trước. Sau đó các bước 6 và 7 có thể bỏ qua.
6. Nếu như chứng nhận khóa cơng khai nhận được khơng được tìm thấy trong hợp khóa, thì khi đó SIP UA phía nhận sẽ kiểm tra kí hiệu đó của nó với bất kỳ CA
khai, thì SIP UA phía nhận sẽ so sánh đối tượng trong chứng nhận khóa công khai (với header From). Nếu như SIP UA phía nhận khơng thể kiểm tra chứng nhận khóa cơng khai (do nó tự kí hiệu, hoặc là kí hiệu bởi CA mà nó khơng biết), thì người dùng phải được cảnh báo với trạng thái của chứng nhận khóa cơng khai. Và SIP UA phía nhận phải được sự cho phép từ người dùng để chấp nhận nó.
7. Nếu chứng nhận khóa công khai được sự đồng ý của người dùng hoặc là trực tiếp từ SIP UA phía nhận, thì chứng nhận khóa cơng khai sẽ được thêm vào trong ổ khóa, nó được đánh chỉ số với SIP URI trong header From.
8. Khi kí hiệu của khóa xác nhận dùng chung là hợp lệ và đã lưu trong keyring, SIP UA phía nhận xác nhận kí hiệu của thân MIME hợp lệ.
9. SIP UA phía nhận khởi tạo và gửi một đáp ứng tới SIP UA khác. Nếu đáp ứng chứa thân bản tin và SIP UA phía nhận hỗ trợ S/MIME, thì thân bản tin có thể bao gồm thực thể S/MIME.
10. Nếu SIP UA nhận đáp ứng SIP với thân bản tin mà bao gồm có một thực thể MIME, thì nó có thể cảnh báo người là phiên có thể khơng được bảo đảm.
Cách thức mã hóa bản tin cũng tương tự như trên, tuy nhiên có một số nét khác:
• Phần đầu tiên của thực thể S/MIME multipart/signed không chứa thân MIME ở dạng hiển thị text. Thay vào đó là thực thể MIME đã mã hóa được thay thế, có nghĩa lúc này thực thể S/MIME kiểu application/pkcs7-mime với giá trị smime- type là “enveloped-data”.
• SIP UA có thể truy nhập vào danh mục chung để lấy chứng nhận khóa công khai cho SIP UA phía nhận. Sau đó khóa chung được dùng để mã hóa (tn theo ḷt mã hóa).
• Nếu như SIP UA phía nhận khơng thể giải mã hóa thân MIME, thì SIP UA phía nhận sẽ từ chối yêu cầu và gửi một đáp ứng 493 (Undecipherable: khơng thể giải mã được). Đáp ứng 493 có thể chứa một chứng nhận khóa công khai trong một thực thể S/MIME application/pkcs7-mime với thông số smime-type để là “certs- only”. Khóa xác nhận chung được chọn có thể phù hợp với header To trong yêu cầu.
Trong S/MIME, mã hóa thực thể MIME được giải quyết bằng cách tạo một thực thể application/pkcs7-mime với thông số “smime-type” là ”enveloped-data” và sau đó gắn cho một đối tượng mà nằm giữa các thành phần khác chứa chứa mã hóa thực thể MIME.
Hình 3.14 Ngun lý mã hóa S/MIME.
Hình 3.15 Nguyên lý giải mã thực hiện trong S/MIME.
S/MIME trong SIP được IETF khún nghị với mợt sớ đặc điểm như sau:
• “multipart/signed” phải được gắn vào trong cú pháp bản tin mã hóa (CMS).
• Thân bản tin S/MIME có header Content-Dispostion và giá trị thơng sớ handling (điều khiển) sẽ là “required”.
• UAC khơng có ở khóa của nó kết hợp với bản ghi địa chỉ để gửi một yêu cầu, thì nó không thể gửi bản tin MIME được mã hóa kiểu “application/pkcs-7mime”. UAC có thể gửi yêu cầu ban đầu chẳng hạn như bản OPTIONS, với cú pháp bản tin CMS tách ra để lấy chứng nhận của phía từ xa (kí hiệu sẽ được đặt là message/sip).
• Thực hiện S/MIME tới thiểu phải có hỗ trợ thuật toán kí hiệu số SHA-1 và thuật toán mã hóa 3DES.
• Mỡi thân S/MIME trong bản tin SIP sẽ được kí hiệu với một chứng nhận. Nếu như UA nhận bản tin với nhiều kí hiệu, thì kí hiệu bên ngoài cùng sẽ được đối xử như là một chứng nhận đơn cho phần thân bản tin. Khơng có kí hiệu song
Sau đây là thí dụ bản tin SIP được mã hóa
Một số thông số viết tắt được mô tả trong SDP (RFC 2327) là:
• v: phiên bản giao thức.
• s: tên phiên.
• t: thời gian phiên được kích hoạt.
• c: thơng tin kết nối
• m: tên phương tiện và địa chỉ truyền tải.
• o: gồm có: chủ sở hữu phiên, số nhận dạng phiên, phiên bản phiên, kiểu mạng, kiểu địa chỉ, địa chỉ mạng của người dùng.
Nếu như client được đặt sau NAT thì có thể hiện thị dạng tên miền (như trong thí dụ).
• a: chỉ thuộc tính, khơng có hoặc có những mơ tả phiên.
• RTP/AVP (Real Time Protocol/Audio Video Profile) dùng giao thức RTP (giao thức truyền tải thời gian thực).
3.5.3 TLS (Transport Layer Security)
a. Ngăn xếp TLS
TLS là giao thức được thực hiện trên TCP và được thiết kế để cung cấp bảo mật tin cậy “tồn trình” (end-to-end). Để đảm bảo về vấn đề bảo mật cho nên TLS được dùng dựa trên truyền tải TCP chứ không phải là UDP. TLS dựa trên SSL (Secure Socket Layer), SSL được Netscape giới thiệu, đưa ra và phát triển. TLS được IETF phát triển và đưa ra trong chuẩn RFC 2246 (phiên bản 1.0) và được cập nhật trong RFC 4346 (phiên bản 1.2). SIP sử dụng giao thức TLS nhằm sử dụng các hàm băm và các thuật tốn mã hóa sẵn có trong TLS.
Hình 3.16 Ngăn xếp giao thức TLS.
Chức năng của thành phần trong ngăn xếp giao thức TLS
TLS record protocol (giao thức bản ghi TLS): cấp tính tin cậy và tính ngun vẹn. Nó điều khiển phân mảnh và nén dữ liệu ứng dụng.
TLS Handshake Protocol (Bắt tay giao thức TLS): Định nghĩa các thỏa thuận mã hóa và hàm băm an tồn và các khóa mã hóa được sử dụng để bảo vệ dữ liệu.
Change Cipher Spec Protocol (giao thức thay đổi đặc tính khóa): Bao gồm các bản tin chứa các byte. Các bản tin luôn được gửi giữa hai thực thể, trong quá trình hình thành kết TLS nó thơng báo các thực thể khác về bộ khóa thỏa thuận sẽ được dùng sau khi nhận bản tin này.
Alert Protocol (giao thức cảnh báo): Dùng để gửi TLS liên quan tới việc cảnh báo các thực thể khác. Mỗi cảnh báo có các mức độ khác nhau, có thể là cực kỳ nguy hiểm. Nếu là cảnh báo cực kỳ nguy hiểm thì kết nối TLS sẽ bị kết thúc ngay lập tức.
b. TLS Handshake (thủ tục bắt tay TLS)
TLS Handshake định nghĩa bản tin được client và server dùng để nhận thực, thỏa thuận hàm băm an toàn và thuật tốn mã hóa và cung cấp cho nhau dữ liệu bí mật để tạo các khóa mã hóa. Khóa mã hóa được sử dụng với các thuật toán đã thỏa thuận bởi
Hình 3.17 Các bản tin trong handshake
Luồng bản tin gửi trong quá trình bắt tay được chỉ ra trong hình trên và các luồng bản tin có thể chia thành 4 pha như sau: pha 1: thiết lập quan hệ bảo mật. Pha 2: nhận thực Server và trao đổi khóa. Pha 3: nhận thực client và trao đổi khóa. Pha 4: kết thúc.
i. Pha 1: thiết lập bảo mật
Handshake được khởi tạo bởi client, nó gửi bản tin ClientHello. Bản tin này có 5 thơng số, được miêu tả như trong bảng sau.
Tên thông số Mô tả
ProtocolVersion Phiên bản giao thức TLS mà client dùng trong phiên TLS
Random Số ngẫu nhiên có thể được tạo bởi bộ khởi tạo số bảo mật ngẫu nhiên.
SessionID Bộ nhận dạng phiên có chiều dài thay đổi, nó có giá trị bằng 0 nếu như client muốn tạo một kết nối mới trên một phiên mới. Nếu một client muốn tham gia lại một phiên, nó có bộ nhận dạng phiên khác 0.
CipherSuit Nó là danh sách những phần tùy chọn hỗ trợ bởi client. Client ghi ra các phần tử được ưu tiên nhất. Mỗi phần tử lại ghi ra một thuật tốn trao đổi khóa và mơ tả thuật tốn dùng cho việc mã
thod
Bảng 3.7 Các thông số bản tin ClientHello
Khi server nhận bản tin ClientHello, nó chọn một bộ mã hóa được đưa ra bởi client, và chỉ thị nén và chèn chúng vào trong bản tin ServerHello. Bản tin ServerHello có phần tên các thơng số giống như trong bản tin ClientHello. Ngồi bộ mã hóa và chỉ thị nén, server cịn tạo một bộ nhận dạng phiên, nếu như thông số SessionID trong bản tin ClientHello được đặt bằng 0, và duy nhất một giá trị Random. Sau đó Server gửi bản tin ServerHello tới client. Và bây giờ, cả hai phía đã thỏa thuận dùng thuật tốn trao đổi khóa, thuật tốn mã hóa đối xứng và hàm băm an tồn.
Cả giao thức TLS Handshake và TLS Record đều dùng hàm băm đảm bảo, nó có thể là MD5 hoặc là SHA-1 cùng với thuật tốn HMAC cung cấp việc bảo vệ tính nguyên vẹn bản tin.
ii. Pha 2: Nhận thực Server và trao đổi khóa
Nếu như server lựa chọn nhận thực chính nó với client, nó gửi một khóa xác nhận chung trong bản tin Certificate. Trước khi client và server có thể dùng thuật tốn mã hóa được thỏa thuận, chúng phải thay đổi khóa bí mật bằng cách dùng một trong những những thuật tốn được mơ tả trong hình dưới đây.
Thuật tốn thay đổi khóa
Mơ tả Thay đổi khóa
RSA
Server gửi chứng nhận khóa cơng khai của nó tới client trong một bản tin Certificate. Chứng nhận khóa cơng khai chứa khóa cơng khai RSA của server và được kí hiệu bởi CA
Client kiểm tra chứng nhận khóa cơng khai và dùng khóa cơng khai RSA để mã hóa bảo mật trước tiên. Bảo mật trước tiên đã mã hóa được gửi tới server trong bản tin ClientKeyExchang. Diffie-Hellman
nhanh
• Server gửi chứng nhận khóa cơng khai của nó tới client trong một bản tin Certificate. Chứng nhận khóa cơng khai chứa khóa cơng khai RSA của server và được kí hiệu bởi CA.
• Server khởi tạo khóa cơng khai Diffie-Hellman bằng cách dùng các thơng số Diffie-Hellman hợp lệ. Khóa cơng khai và các thơng số được kí hiệu với khóa riêng của server và gửi tới client trong bản tin ServerKeyExchange.
Diffie-Hellman của nó, bằng cách dùng các thơng số trong bản tin.
• Client gửi khóa cơng khai Diffie-Hellman của nó tới server trong bản tin ClientKeyExchange.
• Cả hai thực thể này thu được bảo mật trước tiên bằng cách dùng thuật toán Diffie-Hellman.
Diffie-Hellman • Server gửi chứng nhận khóa cơng khai của nó tới client trong một bản tin Certificate. Chứng nhận khóa cơng khai chứa khóa cơng khai RSA của server và được kí hiệu bởi CA.
• Client kiểm tra kí hiệu số của chứng nhận khóa cơng khai nhận được.
• Client gửi khóa cơng khai Diffie-Hellman của nó trong bản tin Certificate hoặc là trong bản tin ClientKeyExchange.
• Cả hai thực thể thu được bảo mật đầu tiên bằng cách dùng thuật tốn Diffie-Hellman
Diffie-Hellman ẩn
• Chứng nhận khóa cơng khai khơng được sử dụng.
• Server gửi khóa cơng khai Diffie-Hellman của nó tới client trong bản tin ServerKeyExchange.
• Client gửi khóa cơng khai Diffie-Hellman tới server trong bản tin ClientKeyExchange.
• Cả hai thực thể thu được khóa bảo mật đầu tiên bằng cách dùng thuật tốn Diffie-Hellman.
Bảng 3.8 Mơ tả thuật một số thuật tốn trao đổi khóa dùng trong TLS.
Bản tin CertificateRequest là tùy chọn, được gửi bởi server để yêu cầu khóa xác nhận chung từ client. Bản tin chứa hai danh sách. Danh sách đầu tiên ghi rõ các kiểu khóa xác nhận chung mà server sẽ chấp nhận. Danh sách thứ hai ghi các CA mà server nhận.
Bản tin tiếp theo gửi bởi server đó là bản tin ServerHelloDone. Chức năng của nó chỉ là báo cho client biết rằng server đã gửi tất cả bản tin liên kết với bản tin ServerHello. Sau đó server sẽ đợi client đáp ứng.
iii. Pha 3 Nhận thực client và trao đổi khóa
Nếu như server đã u cầu client nhận thực chính nó với server, client được yêu cầu gửi chứng nhận khóa cơng khai có hiệu lực trong bản tin Certificate. Nếu client
tin Certificate, thì nó gửi một bản tin cảnh báo tới server. Sau đó server có thể quyết định là thủ tục bắt tay có nên tiếp tục hay khơng.
Bản tin ClientKeyExchange luôn được gửi bởi client và mục đích của nó là để thực hiện thay đổi bí mật trước tiên. So với bản tin ServerKeyExchange thì nó khơng được kí hiệu.
Và cuối cùng đó là bản tin CertificateVerify, nó được gửi tùy chọn từ client tới server để cấp quyền sở hữu của nó về khóa cơng khai mà đã gửi trong bản tin Certificate trước. Bản tin này có chứa hàm băm MD5 hoặc là SHA-1của tồn bộ bản tin được gửi hoặc là nhận trong quá trình thực hiện thủ tục bắt tay.
iv. Pha 4 Finish
Cả client và server đều biết bảo mật đầu tiên và có thể có thể tính bảo mật chủ. Khi cả hai thực thể đã tính mã bí mật chủ (được tính theo hàm giả ngẫu nhiên), chúng dùng nó để tính khóa mã hóa đối xứng, khóa HMAC và giá trị khởi tạo cho thuật tốn mã hóa.
Khi client đã tính tất cả các khóa, nó gửi bản tin ChangeCipherSpec tới server. Cũng giống như tất cả các bản tin khác được gửi bởi client, lúc này nó sẽ được mã hóa và tính nguyên vẹn được bảo vệ bởi giao thức bản ghi TLS. Sau đó client sẽ gửi bản tin Finish, đây là bản tin cuối cùng được client gửi đi trong quá trình thực hiện thủ tục bắt tay. Bản tin Finish kiểm tra việc trao đổi khóa và nhận thực xử lý đã thành công, bản tin này chứa giá trị hàm băm của tất cả các bản tin đã gửi trong quá trình bắt tay (trừ bản tin Finish).
Khi server nhận bản tin ChangeCipherSpec từ client, nó gửi bản tin này tới client. Về phần client, bây giờ server mã hóa và bảo vệ tồn bộ tất cả các bản tin. Sau đó server kết thúc bắt tay bằng cách gửi bản tin Finish tới client.
d. hoạt động của giao thức bản ghi TLS
Hình sau chỉ ra hoạt động của giao thức bản ghi TLS:
Giao thức này cho phép bản tin được truyền, nó phân mảnh dữ liệu thành các khối được quản lý, nén dữ liệu theo tùy chọn, áp dụng HMAC, thêm header (tiêu đề), và truyền tải các khối TCP (đơn vị truyền của TCP là mảnh).
Hình 3.18 Quá trình chia mảnh
Trong hình 3.18, dữ liệu ứng dụng được chia nhỏ thành các mảnh khác nhau (data fragment) rồi thực hiện đệm nếu cần thiết. Với mỗi mảnh, tính HMAC, sau đó thực hiện mã hóa (trở thành tải trọng mã hóa). Sau đó gắn header với tải trọng mã hóa, và khối này được gọi là bản ghi. Phần header này nhận dạng loại nội dung (cụ thể là dữ liệu ứng dụng). Các bản ghi cũng có thể được dùng để gửi các bản tin điều khiển, do vậy đối với các bản tin loại này kiểu nội dung sẽ có kiểu mã thích hợp (báo hiệu, handshake, hoặc thay đổi đặc tính khóa).
c. Một số thí dụ về an ninh SIP kết hợp với TLS
IETF đề xuất TLS có thể sử dụng trong SIP để cung cấp tính bảo mật, các kết nối TLS được thiết lập qua đường báo hiệu. Hình dưới đây minh họa đường báo hiệu giữa hai SIP UA và có những phần được bảo vệ bằng TLS.
IETF đã đưa ra các yêu cầu sau khi mà TLS có thể dùng trong SIP:
• Tất cả các SIP server phải thực hiện TLS và được yêu cầu hỗ trợ cả nhận thực đơn hướng và song hướng.
• SIP UA được khuyến nghị có khả năng khởi tạo kết nối TLS và nó có thể