2.2 BẢO MẬT TRONG IMS
Bảo mật trong IMS được chia thành hai loại: bảo mật cho truy nhập và bảo mật cho mạng. Bảo mật cho truy nhập gồm nhận thực user và nhận thực mạng, và sự bảo vệ cho lưu lượng giữa đầu cuối IMS và mạng. Bảo mật mạng giải quyết cho vấn đề bảo mật lưu lượng giữa các nút mạng (có thể giống nhau đối với các mạng khác nhau).
2.2.1 Bảo mật cho sự truy nhập
Một User truy nhập mạng IMS cần phải được nhận thực và trao quyền trước khi dùng một dịch vụ IMS nào. Khi User được trao quyền, chúng bảo vệ lưu lượng SIP giữa UE và P- CSCF nhờ cơ chế kết hợp bảo mật IPsec.
Sự thiết lập kết hợp bảo mật: P-CSCF và đầu cuối thiết lập hai kết hợp bảo mật
IPsec. Thực hiện hai sự kết hợp này cho phép các đầu cuối P-CSCF dùng UDP để nhận các phản hồi cho một yêu cầu (số hiệu port nằm trong mà đầu Via của yêu cầu) trên một port khác với port được dùng cho việc gửi yêu cầu (do có hai port nên cần hai sự kết hợp bảo mật). Hoặc theo cách khác, P-CSCF dùng cùng một kết nối TCP để gửi và nhận yêu cầu và phản hồi. Trong cả hai trường hợp, sự kết hợp bảo mật được thiết lập từ port client-protected của đầu cuối đến port server-protected của P-CSCF và ngược lại, sự kết hợp bảo mật này sẽ hỗ trợ bảo mật cho lưu lượng theo cả hai hướng.
Protected Client Port Protected Server Port Protected Server Port Protected Client Port Requests Requests Responses Responses P-CSCF
Protected Client Port Protected Server Port Protected Server Port Protected Client Port Requests Requests Responses Responses P-CSCF Hình 2.9. Sự kết hợp bảo mật dùng trên TCP [3]
Sau khi yêu cầu sơ cấp lên tới S-CSCF để thực hiện việc nhận thực, S-CSCF sẽ gửi lại phản hồi 401 Unauthorized (chứa các tham số cần thiết cho sự kiểm tra nhận thực như IK, CK, AUTN và RAND) lại phía UE.
2.2.2 Bảo mật mạng
Bảo mật mạng được dùng cho việc bảo mật lưu lượng giữa các miền mạng khác nhau. Tất cả lưu lượng tới hoặc đi khỏi miền bảo mật đều phải qua cổng bảo mật SEG (Security Gateway). Lưu lượng từ một miền mạng đến một miền mạng khác phải qua hai SEG (hình 2.10). SEG SEG Interdomain traffic Sercurity Domain 1 Sercurity Domain 2
Hình 2.10. Lƣu lƣợng qua hai cổng bảo mật [3]
Lưu lượng giữa các SEG được bảo vệ bằng việc dùng IPsec ESP (Encapsulated Security Payload định nghĩa trong RFC 2406 ) hoạt động ở chế độ ngầm. Sự kết hợp bảo mật giữa các SEG được thiết lập và được duy trì nhờ dùng IKE (Internet Key Exchange định nghĩa trong RFC 2409 .
Có hai loại giao diện giữa các SEG: giao diện Za giữa các SEG thực hiện truyền lưu lượng giữa các miền mạng khác nhau, và Zb giữa các SEG nội miền (hình 2.11).
SEG SEG Za Zb Zb Zb Zb Zb Zb CSCF CSCF CSCF CSCF
2.2.3 Một số khái niệm chi tiết liên quan đến bảo mật
Khi Server nhận được một yêu cầu từ Client, nó sẽ mời Client cung cấp các khả năng của Client trong miền mạng (Client sẽ cung cấp tên và các chứng thực rằng Client cũng đã biết Share Secret - như password chẳng hạn). Chính vì thế cần mật mã các thơng tin này khi truyền giữa Client và Server. Client dùng digest có thể chứng thực các thơng tin bí mật đó mà khơng cần gửi qua mạng.
TLS - bảo mật lớp truyền tải
TLS (Transport Layer Security, định nghĩa trong RFC 2246 ) dựa trên SSL (Secure Socket Layer). SSL được thiết kế cho việc bảo vệ thông tin web và được triển khai trong hầu hết các trình duyệt Internet. TLS tổng quát hơn SSL, nó có thể được dùng để bảo vệ bất cứ loại kết nối nào. Vì thế TLS được dùng để bảo vệ lưu lượng SIP.
TLS có hai lớp: lớp bắt tay (TLS handshake) và lớp bản ghi (TLS record). TLS handshake thực hiện nhận thực các thực thể ngang hàng, nó dùng các khóa cơng cộng và các chứng chỉ (Certifỉcate - hay khoá để hiểu TLS và S/MINE), thuật toán để tạo mã bảo mật truyền dữ liệu, hay cịn gọi là khố bảo mật. TLS record thực hiện mã hóa dữ liệu. Nó dùng thuật tốn mã hóa đối xứng có khóa được tạo từ giá trị được lớp handshake cung cấp.
Hình 2.12. Thiết lập kết nối TLS [9]
S/MINE
Khi UE muốn chuyển các thông tin mà proxy khơng thể truy nhập (ví dụ như nội dung của luồng audio hay video giữa hai user), thì SIP cần dùng giải pháp bảo mật end-to-end hay dùng S/MINE (Secure/Multipurpose Internet Mail Extension). Thường thì thân của bản tin sẽ được dùng với S/MINE, đơi khi nó cũng được dùng để mật mã hoặc mã hố các mào đầu có mang thơng tin nhậy cảm.
Message
Encrypted Message
Content Encryption Key
Encryption Content Encryption Key
Recipient’s Public Key
Hình 2.13. Sơ đồ dùng S/MINE mật mã thân bản tin [6]
Message Encrypted
Message
Content Encryption Key Encryption Content
Encryption Key
Recipient’s Public Key
Hình 2.14. Sơ đồ dùng S/MINE giải mã thân bản tin [6]
Khi UE muốn bảo mật cho mào đầu (ví dụ ở đây là mào đầu From, To và Contact), nó sẽ copy và đặt các mào đầu này vào toàn bộ thân bản tin cần được dùng S/MINE để bảo mật (thực hiện điều này sẽ tránh được việc bị thay đổi thông tin của mào đầu). Mào đầu Content- Type: message/sigfrag sẽ chỉ ra bản tin có dùng S/MINE cho bảo mật mào đầu.
2.3 QUẢN LÝ PHIÊN TRUYỀN DẪN TRONG IMS
2.4.1 Quản lý phiên truyền dẫn
Một phiên truyền dẫn ở đây được hiểu theo nghĩa của một giao dịch hồn thiện tức là cả một q trình từ khi UE bắt đầu tham gia tạo một phiên dịch vụ IMS (sau khi đã được đăng ký, và trao quyền) đến khi kết thúc phiên dịch vụ đó. Vì vậy quản lý phiên truyền dẫn sẽ liên quan đến cả quá trình tạo lập, nắm giữ và giải phóng phiên, nó gồm một loạt các vấn đề từ việc nhận dạng chủ gọi – bị gọi, định tuyến, chọn lựa mã truyền thông, điều khiển phương tiện truyền thơng, tính cước, và giải phóng phiên. Để nắm được thông suốt và cũng để gắn với thực tế, chúng ta sẽ trình bầy những điều này thơng qua ví dụ về một phiên hồn thiện được tạo lập giữa Tobias và Theresa (sau khi họ đã đăng ký và được trao quyền), qua một loạt các bước:
UE của Tobias tạo yêu cầu INVITE chứa nhận dạng public user (đã đăng ký ở thủ tục đăng ký) của Theresa
Tất cả các bản tin SIP cần phải đi qua P-CSCF và S-CSCF của cả hai user
Tất cả các bản tin SIP được gửi qua IPsec ASs đã được thiết lập giữa UE và P-CSCF
Tất cả các gói SIP được nén lại khi truyền giữa UE và P-CSCF của nó
UE đồng ý dùng cùng một bộ mã hóa cho luồng truyền thơng sẽ được truyền
Các mạng sẽ trao quyền truyền thông cho phiên, vì thế các user có thể dự chữ các tài nguyên liên quan
Cả hai UE thực hiện Resource Reservation (như đã giới thiệu ở vấn đề QoS).
Các thực thể mạng sẽ gửi thơng tin tính cước đến hệ thống tính cước.
UE của Theresa sẽ nhận được tín hiệu chng, Theresa sẽ chấp nhận phiên, và phiên được thiết lập thành công.
Sau khi kết thúc cuộc gọi, UE của bên đặt máy trước (kết thúc trước) sẽ gửi yêu cầu BYE tới UE kia, và phiên sẽ kết thúc. Hình 2.15 mơ tả tồn bộ q trình quản lý một phiên truyền dẫn.
Tobias’ UE P-CSCF S-CSCF I-CSCF S-CSCF P-CSCF Theresa’s UE
Visited Finland home1.fr home2.hu
INVITE (st1 SDP oder) INVITE (st1 SDP oder) 100 Trying Australia 100 Trying INVITE (st1 SDP oder) 100 Trying INVITE (st1 SDP oder) 100 Trying INVITE (st1 SDP oder) 100 Trying INVITE (st1 SDP oder) 183 Session Progress (st1 SDP answer) 183 Session Progress (st1 SDP answer) 183 Session Progress (st1 SDP answer) 183 Session Progress (st1 SDP answer) 183 Session Progress (st1 SDP answer) 183 Session Progress (st1 SDP answer) PRACK (2nd SDP oder) PRACK (2nd SDP oder) PRACK (2nd SDP oder) PRACK (2nd SDP oder) PRACK (2nd SDP oder) PRACK (2nd SDP oder) R es ou rc e re se rv at at io n R es ou rce re se rva tati on 200 OK (2nd SDP answer) 200 OK (2nd SDP answer) 200 OK (2nd SDP answer) 200 OK (2nd SDP answer) 200 OK (2nd SDP answer) 200 OK (2nd SDP answer) UPDATE (3rd SDP oder) UPDATE (3rd SDP oder) UPDATE
(3rd SDP oder) (3rd SDP oder)UPDATE UPDATE
(3rd SDP oder) UPDATE (3rd SDP oder) 200 OK (3rd SDP answer) 200 OK (3rd SDP answer) 200 OK (3rd SDP answer) 200 OK (3rd SDP answer) 200 OK (3rd SDP answer) 200 OK (3rd SDP answer) 183 Ringing 183 Ringing 183 Ringing 183 Ringing 183 Ringing 183 Ringing PRACK PRACK PRACK PRACK PRACK PRACK 200 OK 200 OK 200 OK 200 OK 200 OK 200 OK O ffh oo k 200 OK 200 OK 200 OK 200 OK 200 OK 200 OK ACK ACK ACK ACK ACK ACK Hình 2.15. Phiên truyền dẫn [9] 2.4.2 Các nhận dạng chủ gọi và bị gọi
Sau khi đã được mạng nhận thực, đăng ký và trao quyền, UE sẽ có khả năng được tham gia dịch vụ. UE của Tobias sẽ gửi yêu cầu INVITE chứa nhận dạng public user của Tobias để đảm bảo cho mạng nhận dạng user và thực thi đúng các dịch vụ cho user. Nhận dạng này sẽ nằm ở mào đầu P-Asserted-Identity. Các nhận dạng public user của bị gọi cũng được chỉ định để mạng thực thi đúng các dịch vụ cho bị gọi, sẽ nằm ở P-Asserted-Identity của phản hồi đầu tiên (trả lời yêu cầu INVITE).
Sự nhận dạng user chủ gọi
UE chủ gọi gửi yêu cầu chứa mào đầu P-Preffered-Identity, có chứa thơng tin nhận dạng public user đã được đăng ký. Để ẩn đi nhận dạng (của Tobias) thì cần đặt Privacy có giá trị ―id‖. Thực hiện điều này sẽ làm P-CSCF của Theresa xóa bỏ P-Preffered-Identity của Tobias trước khi gửi đến UE của Theresa, vì thế Theresa chỉ nhìn thấy nhận dạng của Tobisa ở mào đầu From.
P-CSCF phía chủ gọi sẽ nhận được yêu cầu INVITE, nó kiểm tra yêu cầu nhận được có qua IPsec SA hay khơng, nếu khơng thì P-CSCF sẽ từ chối u cầu. Sau đó P-CSCF sẽ chèn P-Assered-Identity ở INVITE thay cho P-Preffered-Identity.
Nếu P-Preffered-Identity chứa URI có là nhận dạng public user đã được đăng ký (bằng cách kiểm tra thông tin trạng thái đăng ký của user) đã được dùng từ trước hay không. Nếu đúng, P-CSCF sẽ thay nội dung của P-Perffered-Identity vào làm nội dung của P- Assered-Identity.
Sự nhận dạng của user bị gọi
Để ý đến yêu cầu INVITE, thấy request URI: INVITE sip: theresa@home2.hu SIP/2 \.0. Dựa vào URI này, S-CSCF của Theresa sẽ kiểm tra sự tồn tại của nhận thực public user này có là nhận dạng hiện tại đã được đăng ký và trao quyền hay không. Nếu hiện tại Theresa không đăng ký bằng nhận dạng này, thì S-CSCF sẽ gửi lại phía chủ gọi bản tin 404 (Not Found) phản hồi cho yêu cầu INVITE và cuộc gọi sẽ bị hỏng. Lúc đó, tùy theo tiêu chuẩn lọc đối với user chưa đăng ký, bản tin INVITE sẽ được gửi forward đến hộp thư thoại của Theresa.
S-CSCF của Theresa nhận được yêu cầu INVITE, nếu thỏa mãn các điều kiện trên, nó sẽ thay nhận dạng public user ở request URI cũ bởi địa chỉ liên lạc đã được đăng ký của Theresa, và để vẫn giữa được nhận dạng cũ, S-CSCF sẽ thêm vào mào đầu P-Called-Party- ID.
Sau khi nhận được yêu cầu INVITE, UE của Theresa sẽ gửi lại mào đầu P-Preffered-Identity (chứa nhận dạng public user của Theresa) ở phản hồi đầu tiên cho u cầu INVITE.
Sau đó tiến trình thực hiện tương tụ như đã đề cập đối với hướng từ Tobias, nhưng theo chiều ngược lại.
2.4.3 Định tuyến
Phân biệt giữa phiên, dialog, các giao dịch và nhánh (branch)
Phiên, là thuật ngữ mơ tả kết nối truyền thơng giữa các user (ví dụ Tobias muốn gửi các luồng audio và video đến Theresa). Sự truyền thông này gọi là mức mang (bearer level): các gói RTP được gửi từ hai UE đến GGSN và GGSN sẽ thực hiện truyền các gói này một cách trực tiếp qua mạng. Phiên ở đây được thiết lập dựa trên SIP và báo hiệu SDP (giao thức mô tả phiên) được truyền trên mặt bằng điều khiển (control plane).
SIP dialog là báo hiệu giữa hai UE cần để thiết lập, điều chỉnh và giải phóng phiên đa phương tiện. Một dialog bắt đầu được thiết lập với yêu cầu INVITE và tồn tại đến hết kết
thúc phiên bằng phản hồi 200 (OK) cho yêu cầu BYE. Mọi dialog đều được nhận dạng bằng giá trị chứa ở mào đầu Call-ID và các nhãn (tag) ở mào đầu To và From của các yêu cầu SIP.
Một giao dịch SIP gồm một yêu cầu SIP và tất cả các phản hồi liên quan đến yêu cầu đó. Ví dụ để thiết lập phiên, UE của Tobias gửi một yêu cầu INVITE đến UE của Theresa và sẽ nhận được phản hồi 100 (Trying) từ P-CSCF, phản hồi 183 (Session in Progress) và 180 (Ringing) và 200 (OK) từ UE của Theresa. Như vậy có năm bản tin cho giao dịch đó, và cả năm bản tin đêu thuộc một dialog và có cùng số Csep.
Sau khi đã thiết lập được IPsec SAs, UE của Tobias sẽ đặt địa chỉ port đã được bảo vệ (1357) ở mào đầu Contact, đặt địa chỉ port đã được bảo vệ của nó tại mào đầu Via để có thể nhận được tất cả các phản hồi qua port được bảo vệ đó. Địa chỉ của port được bảo vệ của P- CSCF (7531) được đặt ở mào đầu Route đầu tiên để P-CSCF có thể nhận được tất cả các yêu cầu của UE qua cổng bảo vệ kết hợp bảo mật đó. Các mào đầu To và From khơng được dùng cho mục đích định tuyến mà nó chỉ có mục đích nhận dạng.
Khi nhận được yêu cầu, P-CSCF sẽ thực hiện: xóa mào đầu Route thứ nhất liên quan đến địa chỉ của P-CSCF, kiểm tra xem thông tin định tuyến chứa ở trong yêu cầu có theo đúng như thơng tin định tuyến P-CSCF đã lưu trữ trong q trình đăng ký hay khơng, đặt thêm địa chỉ của nó ở mào đầu Via trên cùng (sẽ giúp nhận được các gói phản hồi), thêm vào mào đầu Record-Route và đặt địa chỉ của nó vào đó (giúp tất cả các gói tin đều phải đi qua P- CSCF này), rồi gửi cho S-CSCF của Tobias.
S-CSCF của Tobias nhận được yêu cầu đó, nó sẽ xóa mào đầu Route liên quan đến địa chỉ của chính S-CSCF đó và thực hiện các thủ tục (*). S-CSCF tiếp tục định tuyến yêu cầu INVITE sang I-CSCF của Theresa (S-CSCF của Tobias dựa vào DNS để tìm địa chỉ của I- CSCF). Nếu S-CSCF biết được khả năng định tuyến của I-CSCF thì nó sẽ thêm địa chỉ của I- CSCF vào mào đầu Route và thực hiện gửi theo SIP, tuy nhiên vì S-CSCF của Tobias và I- CSCF của Theresa ở đây nằm ở hai mạng khác nhau nên S-CSCF sẽ khơng thực hiện được điều đó. S-CSCF của Tobias sẽ đóng gói UDP chứa yêu cầu INVITE đến I-CSCF.
I-CSCF mạng thường trú của Theresa cần tìm ra địa chỉ của S-CSCF sẽ phục vụ cho Theresa. Nếu Theresa chưa đăng ký, I-CSCF cần tìm ra địa chỉ của S-CSCF mặc định cho Theresa thuê bao dịch vụ như một user không đăng ký. Thông tin S-CSCF đã cấp cho user được lưu tại HSS, nếu có nhiều HSS thì I-CSCF cần truy vấn SLF để tìm ra HSS phù hợp chứa thông tin về S-CSCF cấp cho Theresa. Sau khi đã tìm ra địa chỉ S-CSCF, I-CSCF sẽ xóa địa chỉ của nó ở mào đầu Route và thêm vào yêu cầu INVITE địa chỉ đó ở mào đầu Route trên cùng, và thêm vào địa chỉ của I-CSCF vào mào đầu Via trên cùng. Vì nhiệm vụ của I- CSCF chủ yếu để tìm S-CSCF do vậy những gói tin sau đó khơng cần thiết phải qua I-CSCF mà sẽ tới thẳng S-CSCF, do đó I-CSCF sẽ khơng thêm địa chỉ của nó vào mào đầu Record- Route của yêu cầu INVITE này.
S-CSCF của Theresa nhận được yêu cầu INVITE, nó sẽ xóa địa chỉ của nó tại mào đâu Route, thêm vào địa chỉ của nó ở mà đầu Via, và S-CSCF sẽ thực hiện thông tin với AS của Theresa tương tự các thủ tục (**). Bằng việc này, S-CSCF sẽ thay request URI bằng địa chỉ liên lạc đã đăng ký có cổng server bảo vệ là 1006 (cũng chính là port của UE Theresa),
cùng với địa chỉ của P-CSCF (của Theresa) có được từ mào đầu Path của yêu cầu REGISTER của Theresa. S-CSCF sẽ đặt địa chỉ của P-CSCF vào mào đầu Route.
P-CSCF của Theresa nhận được yêu cầu INVITE nó sẽ xóa tất cả mào đầu Route và