Bảo mật điện thoại trên Internet
Nguyên nhân chủ yếu của sự tăng trưởng đó là do giá thành rẻ, hoặc miễn phí. Tuy nhiên, do đặc trưng cơ bản của điện thoại IP là người gọi và người nghe không bị gắn kết với một thiết bị cố định nào cả, các thiết bị được sử dụng để kết nối mạng nhằm tiến hành các cuộc đàm thoại phần lớn có địa chỉ IP thay đổi (địa chỉ động), do đó nguy cơ nghe trộm các cuộc hội thoại trên mạng IP là rất cao, rất dễ thực hiện và khó bị phát hiện. Các hãng sản xuất điện thoại IP đều đã cố gắng đưa ra giải pháp riêng của mình nhằm bảo mật nội dung của các thuê bao trên mạng IP, nhưng cho tới thời điểm này các giải pháp đưa ra chưa thật hoàn hảo như mong đợi. Vì vậy, việc nghiên cứu bảo mật điện thoại IP là hết sức cần thiết. Bài báo này giới thiệu về SIP - một giao thức liên lạc trong VoIP va giải pháp bảo mật VoiP trong mạng SIP.
I. Sử dụng giao thức SIP trong VoIP
Hiện nay có hai giao thức chính cho liên lạc thoại là H.323 và SIP (Section Initial Protocol)[1]. H.323 là giao thức do ITU còn SIP do IETF đề xuất. Tuy ra đời sau nhưng SIP là giao thức chính được các nhà phát triển, sản xuất sử dụng đưa vào sản phẩm của mình, do vậy ở đây chúng ta chỉ đề cập đến SIP. SIP là giao thức khởi tạo phiên, chức năng chính là để khởi tạo và kết thúc phiên liên lạc hai chiều. Để hai người sử dụng có thể thiết lập liên lạc được với nhau họ cần biết được hoặc tài khoản (có thể là số điện thoại) hoặc định danh hay địa chỉ IP của nhau. Người sử dụng điện thoại IP chủ yếu có địa chỉ động do vậy vấn đề biết trước địa chỉ IP của nhau là không thực tế, hơn nữa khi muốn gọi cho một người nào đó mà lại phải nhớ địa chỉ IP của họ thì quá phức tạp nên phải có cơ chế thuận tiện hơn. Người ta đưa ra cơ chế đánh địa chỉ đặc biệt để phân biệt các tài khoản SIP, các địa chỉ đó (gọi là địa chỉ SIP) gần giống với địa chỉ e-mail và sử dụng sơ đồ phân cấp URI (Universal Resource Identifiers) để chỉ rõ miền mà tài khoản người dùng phân bố, và địa chỉ trạm (địa chỉ IP tĩnh hay động) hay số điện thoại tương ứng với tài khoản của người dùng. Ví dụ SIP: myaccount@mysip.com chỉ ra rằng tài khoản myaccount nằm trong miền mysip.com. Phương pháp này cho phép ánh xạ địa chỉ SIP tới một số điện thoại hay người dùng cụ thể. Các URI còn chứa các thông tin khác liên quan đến người dùng như địa chỉ cổng, mật khẩu …
Các thành phần chính của mạng SIP:
- Trạm đầu cuối UA (User agent ): Có thể là phần mềm cài đặt máy tính để tiến hành đàm thoại, điện thoại USB, PDA hay là Cổng kết nối (Gateway) tới mạng PSTN.
- Máy chủ SIP: Là máy tính trên mạng để phục vụ các yêu cầu của UA và gửi đáp trả lại đối với các yêu cầu đó. Tùy thuộc vào yêu cầu của UA, máy chủ SIP có thể đóng vai trò là Máy chủ đăng ký/định vị (Registrar/Location Server), Máy chủ Proxy, Máy chủ điều tiết (Redirect Server). Trong đó:
- Máy chủ đăng ký/định vị: Để ghi nhận đăng ký/định vị của UA truy cập vào mạng, nó chứa đựng địa chỉ IP của UA và tên truy cập gắn với UA.
- Máy chủ Proxy: Đứng ra thay mặt UA chuyển tiếp yêu cầu đến máy chủ SIP khác. Ngoài ra nó còn hoạt động như một Proxy thông thường.
- Máy chủ điều tiết: Cho phép UA kết nối trực tiếp với đối tượng cần gọi bằng cách cung cấp cho UA đó địa chỉ IP của đối tượng.
Gọi Bob và Alice là hai thực thể tham gia đàm thoại, sơ đồ trong hình 1 cho ta thấy mối liên kết các thành phần mạng khi Bob tiến hành gọi Alice
Thông thường máy chủ định vị nằm trong máy chủ Proxy (Proxy Server), do vậy nhiều tài liệu sẽ không nói đến máy chủ định vị.
Quá trình thiết lập cuộc gọi giữa Bob và Alice được diễn ra như sau:
- Bob gửi yêu cầu INVITE đến máy chủ Proxy (máy chủ này có địa chỉ SIP, địa chỉ IP của Bob) trong đó có chứa thông tin về giao thức trao đổi phiên SDP (Session Description Protocol - chứa các trường chỉ ra Codec được sử dụng, tên người, và các tham số khác..). Thông báo INVITE đó được chuyển tiếp đến Alice nhờ máy chủ Proxy của Bob, và các Proxy trung gian cuối cùng có thể qua máy chủ Proxy của Alice.
Hình 1: Sơ đồ gửi yêu cầu thiết lập cuộc gọi từ Bob đến Alice
- Nếu Alice đồng ý nói chuyện với Bob, cô ta sẽ gửi trả lại thông báo “OK” có chứa khuôn dạng SDP.
- Bob gửi lại thông báo “ACK”. Khi Alice nhận được thông báo “ACK” cuộc nói chuyện bắt đầu được tiến hành (Alice và Bob khi đó đã biết được địa chỉ IP của nhau). Luồng dữ liệu thoại bắt đầu được trao đổi trực tiếp giữa hai trạm đầu cuối.
- Kết thúc phiên liên lạc Bob gửi cho Alice thông báo “BYE”, Alice đáp lại bằng cách gửi cho Bob thông báo “OK” và kết thúc phiên liên lạc.
Như vậy SIP đảm bảo quá trình bắt tay trao đổi các thông tin cần thiết giữa các trạm đầu cuối để tạo phiên liên lạc. Các thông tin đó được gửi qua các nút (các Proxy Server) trung gian. Sau khi phiên liên lạc được thiết lập luồng dữ liệu thoại (media) sẽ được truyền qua /lại trực tiếp giữa hai trạm đầu/cuối.
Hình 2: Lưu đồ Bob gọi Alice trong mạng SIP
Như vậy thông tin trao đổi, vận chuyển giữa các bên tham gia đàm thoại được chia làm hai luồng: Luồng tín hiệu báo hiệu (để thiết lập cuộc gọi) và luồng dữ liệu thoại giữa các bên. Điều đó dẫn đến vấn đề bảo mật sẽ chia làm hai phần tương ứng với nó gồm:
- Bảo mật thông tin thiết lập cuộc gọi (thông tin báo hiệu)
- Bảo mật dữ liệu thoại giữa các trạm đầu cuối (xem hình 3)
Hình 3: Các luồng thông tin/ hướng đi trong giao dịch SIP
II. Giải pháp bảo mật VoIP trong mạng SIP
Bảo mật thoại trên mạng IP sử dụng giao thức SIP (gọi tắt là bảo mật VoIP, hay bảo mật điện thoại SIP) là vấn đề mới được đề cập tới. Cho đến nay chưa có một giải pháp thực tế nào được coi là thực sự hoàn chỉnh (với những tài liệu công khai) cho loại hình bảo mật này. Thoại IP có bảo mật đã có giải pháp của Google cho ứng dụng Skype, nhưng Google sử dụng giao thức bảo mật riêng của họ vì thế chúng ta không có đủ thông tin và không khẳng định được mức độ an toàn của nó.
Bảo mật VoIP phải đảm bảo được các yêu cầu sau:
- Đảm bảo người gọi chỉ kết nối với người mình cần gọi.
- Loại bỏ tối đa các cuộc gọi không mong muốn (tạm coi là các cuộc gọi rác).
- Nội dung cuộc gọi phải được bí mật và toàn vẹn.
- Thông tin về người gọi, người nghe được bảo mật.
Để đảm bảo yêu cầu 1 và 2, người gọi và người nghe phải được xác thực trước khi cuộc gọi được thiết lập. Xác thực có thể được coi như một phần của giao thức khóa được sử dụng để thiết lập bộ tham số an toàn SA (Security Association) giữa người gọi và người nghe, tức là thỏa thuận bộ tham số mật mã sẽ sử dụng (tạo khóa chủ của phiên liên lạc…). Những bộ tham số đó được sử dụng trong giao thức an toàn để mã hóa, bảo đảm tính toàn vẹn dữ liệu theo yêu cầu 3. Đối với yêu cầu 4, các thông tin báo hiệu phải được bảo mật. Giải pháp cho yêu cầu này là sử dụng TLS (Transport Level Security- An toàn tầng giao vận) để bảo mật tín hiệu báo hiệu từ nút này tới nút kia (hop-by-hop), vấn đề này không liên quan gì đến bảo mật và xác thực đầu cuối, nên chúng ta không xem xét đánh giá nó tại đây. Bạn đọc có thể tìm hiểu trong tài liệu [2].
Như đã nêu ở trên, để Alice nói chuyện được với Bob, hai người phải thỏa thuận được với nhau một số điểm cơ bản (hai bên có đồng ý nói chuyện với nhau hay không, thuật toán nén tiếng nói (codec) nào được sử dụng…). Tương tự như thế, để bảo mật luồng dữ liệu thoại giữa hai người này thì các tham số mật mã được sử dụng giữa những người tham gia liên lạc cũng cần phải thỏa thuận trước khi nói chuyện. Giao thức trao đổi khóa tùy thuộc vào phương thức bảo mật được lựa chọn. Có thể khẳng định rằng, đối với mã thoại IP phương thức bảo mật phù hợp nhất (đảm bảo chất lượng, thuận tiện, an toàn) là giao thức giao vận thời gian thực có bảo mật SRTP (Secure Real-time Transport Protocol) và giao thức trao đổi khóa đi kèm với nó được đánh giá là hợp lý, nhất là giao thức MIKEY (Multimedia Internet Keying) [3].
1. MIKEY – Giao thức trao đổi khóa trong VoIP
MIKEY là giao thức an toàn để thỏa thuận các tham số cần thiết cho các bên tham gia liên lạc với đặc tính dữ liệu thời gian thực để tạo khóa phiên đảm bảo cho mã hóa, xác thực và toàn vẹn dữ liệu thoại giữa các bên. Trong trường hợp MIKEY kết hợp với SRTP, MIKEY cung cấp khóa chủ (master key) cho SRTP. Trên cơ sở khóa chủ đó, khóa phiên (Khóa mã, khóa xác thực, và salt [3]) cho giao dịch an toàn được tạo ra
MIKEY hỗ trợ ba cơ chế xác thực khác nhau: Sử dụng khóa chia sẻ trước (shared key), Khóa công khai với vận chuyển khóa, và Khóa công khai với trao đổi khóa sử dụng lược đồ Diffie-Hellman (DH) có ký. Cơ chế thỏa thuận các tham số ở đây (kể cả cơ chế xác thực) được thực hiện theo giao thức mô tả phiên SDP (Section Description Protocol) dưới hình thức Yêu cầu/Trả lời (Request /Response) để đảm bảo tính toàn vẹn, đối với khóa chia sẻ trước là mã toàn vẹn thông báo (MIC-Message Integrity Code) và chữ ký số đối với hai trường hợp còn lại.
Trong trường hợp sử dụng khóa chia sẻ trước, khóa được sinh ra bởi người khởi tạo phiên và được truyền bằng cách bí mật nào đó tới đối tác. Tất nhiên khóa chia sẻ trước chỉ được áp dụng trong môi trường có số người sử dụng hạn chế. Đối với môi trường nhiều người sử dụng cần xây dựng cơ sở hạ tầng khóa công khai (PKI) với triển khai thực tế như sau: Người dùng lưu một tập con các CA gốc (Root CAs ), nhà cung cấp dịch vụ SIP phải có chứng chỉ ký bởi một trong các CA gốc đó, và đến lượt mình nhà cung cấp dịch vụ SIP cấp chứng chỉ sử dụng cho người dùng. Trong các cơ chế xác thực dựa trên chứng chỉ, chúng ta chỉ quan tâm đến trường hợp xác thực sử dụng DH, còn trường hợp sử dụng khóa công khai dựa trên vận chuyển khóa không được đề cập đến ở đây do độ trễ trong quá trình xác thực khá lớn (trên thực tế Alice phải bằng cách nào đó có được khóa công khai của Bob trước khi Alice gửi thông báo INVITE như trình bày trong hình 2). Mặt khác sử dụng DH có ký còn có thể đạt được an toàn phía trước hoàn thiện (perfect forward secrecy) (Với an toàn phía trước hoàn thiện, kẻ tấn công không thể giải mã được cuộc nói chuyện (bản mã) đã ghi âm giữa Alice và Bob, ngay cả khi sau đó kẻ tấn công có được khóa riêng của họ).
Khóa công khai sử dụng DH có ký được thực hiện như sau:
Thông báo m được gửi từ người khởi tạo (Init) đến người nhận (Resp) có dạng:
m : HDR,T,RAND,[IDi|CERTi],SP,DHi,SIGNi
Thông báo phản hồi từ người nhận đến người khởi tạo có dạng:
m’: HDR,T,[IDr|CERTr],IDi,DHr,DHi,SIGNr
Trong đó:
[|] Các tham số đứng trong ngoặc vuông là tùy chọn
T là tem thời gian được sử dụng để chống tấn công lặp
RAND là số ngẫu nhiên (dùng để sinh khóa mã)
IDi, IDr là định danh người khởi tạo phiên, người nhận tương ứng
CERTi, CERTr là chứng chỉ của người khởi tạo phiên và người nhận.
SP là tập những chính sách an toàn (security policies)
DHi = gxi, DHr =gxr là các giá trị DH của người gửi và người nhận, xi, xr được lựa chọn một một cách ngẫu nhiên bởi người khởi tạo và người nhận, g là phần tử sinh của nhóm nhân cyclic đủ lớn G.
SIGNi và SIGNr là chữ ký trên toàn bộ thông báo của người khởi tạo và người trả lời sử dụng khóa riêng của họ một cách tương ứng.
Đáng lưu ý ở đây là khi đưa chứng chỉ vào trong nội dung thông báo MIKEY thông báo SIP sẽ quá lớn (khi độ dài khóa lớn hơn 1024 bit), không thể sử dụng giao vận UDP để vận chuyển thông báo (thông báo SIP khi đó sẽ lớn hơn 1300 byte, vượt ngưỡng cho phép) và phải vận chuyển bằng giao vận TCP hay TLS [4].
2. SRTP – Giao thức trong bảo mật VoIP
SRTP là giải pháp tối ưu để bảo mật luồng dữ liệu VoIP, nó đảm bảo tính bí mật và toàn vẹn payload của các gói RTP, cũng như việc đảm bảo chống được tấn công lặp (replay protection) đối với các dữ liệu thoại. Vị trí của giao thức RTP, SRTP trong tương quan với các lớp của mạng được minh họa trong hình 4.
Hình 4: Phân lớp các giao thức bảo mật VoIP
Trong hình 4, dữ liệu của ứng dụng VoIP được phân làm hai loại ứng với hai cột: Cột trái là các giao thức cho luồng dữ liệu (media) thoại. Cột phải là các giao thức ứng dụng để vận chuyển các tín hiệu báo hiệu, phục vụ kết nối, trao đổi khóa.
Ce: Ký hiệu chứng chỉ số (trong trường hợp sử dụng hạ tầng cơ sở khóa công khai phân phối khóa) trong phân phối, trao đổi khóa.
Cấu trúc gói dữ liệu SRTP được mô tả như hình 5
MKI (MasterKey Identifier/Index): Định danh khóa chủ, báo hiệu khóa nào được sử dụng
MIC (Message Integrity Code): Mã toàn vẹn thông báo
Về nguyên tắc có thể sử dụng các lược đồ mã hóa an toàn khác nhau trong SRTP. Nhưng trên thực tế SRTP sử dụng mã hóa AES (được coi như cài đặt ngầm định) để mã hóa payload của gói RTP và sử dụng hàm băm an toàn HMAC-SHA1 để xác thực và đảm bảo toàn vẹn dữ liệu.
Hình 6: Lược đồ mã hóa RTP payload sử dụng AES chế độ CTR
a) Đảm bảo tính bí mật dữ liệu thoại
Tính bí mật đàm thoại được đảm bảo nhờ mã hóa các payload gói dữ liệu thoại; chỉ người gửi, người nhận có khóa hợp lệ mới có thể hiểu đúng được. Đối với tín hiệu thời gian thực, việc ứng dụng phương pháp mã khối tựa mã dòng như chế độ CTR trong AES để mã hóa được đánh giá là phù hợp nhất vì quá trình giải mã các gói dữ liệu hoàn toàn độc lập với nhau, do vậy việc mất mát (một số ít) hoặc trễ của các gói dữ liệu không ảnh hưởng lớn đến quá trình đàm thoại, mặt khác lựa chọn này cho phép chúng ta tránh được padding (làm tròn) payload gói dữ liệu, hạn chế được một số tấn công thông dụng. Hình 6 mô tả ứng dụng AES chế độ CTR để mã hóa một khối dữ liệu IP. Theo hình vẽ, một khối dòng khóa ký hiệu Bi,j là kết quả của mã hóa IV với khóa sử dụng AES-Chế độ CTR. IV được xây dựng từ 48 bit chỉ số của gói, 32 bit định danh nguồn đồng bộ SSRC (Synchronization Source identifier), và 112 bit khóa salt (mầm) [3]. Tất cả các tham số đó được dịch trái và sử dụng hoặc loại trừ (XOR)
Trong đó, AES-CM là cách viết khác của AES chế độ CTR.
Mỗi vectơ khởi tạo IV được mã hóa với khóa để tạo ra khối giả ngẫu nhiên 128 bít Bi,j . Mỗi khối 128 bít được XOR với dữ liệu payload RTP rõ để tạo ra khối mã, có thể là một phần hoặc toàn bộ payload. Quá trình mã và giải mã đều thực hiện sinh dòng khóa với chỉ số gói, SSRC, và khóa salt; mỗi quá trình đều sinh một cách đồng bộ dòng khóa Bi,j, trong đó j là chỉ số của từng khối trong dòng những khối AES nối tiếp nhau.
b) Đảm bảo xác thực và toàn vẹn dữ liệu thoại
Tính toàn vẹn dữ liệu được đảm bảo bằng cách sử dụng hàm băm một chiều đối với thông báo có sử dụng khóa mật mã nhằm đảm bảo để người nhận tin tưởng rằng người gửi có khóa bí mật và không bên nào có thể thay đổi khóa mã trên đường truyền.
Hình 7 Mô tả quá trình xác thực dữ liệu. Hàm một chiều, mã xác thực thông báo dựa trên hàm băm có khóa (HMAC – keyed-Hash Message Authentication Code ) với thuật toán băm an toàn -1 (SHA-1) được thực hiện với khóa bí mật trên cả phần đầu và phần payload của gói dữ liệu. Người gửi ghi giá trị HMAC-SHA1 vào phần thẻ xác thực (Authentication tag) và người nhận tiến hành quá trình tính toán tương tự như thế và kiểm tra kết quả với thẻ. Nếu hai giá trị không khớp nhau suy ra có sự thay đổi gói dữ liệu, gói đó bị hủy bỏ.
c) Đảm bảo chống tấn công lặp
Hình 7: Xác thực gói SRTP
Để chống tấn công lặp, con đếm vòng (Rollover Counter- ROC) và cửa sổ trượt được sử dụng. Số thứ tự độ dài 16 bit của phần đầu RTP cùng với SRTP ROC độ dài 32 bit tạo ra số thứ tự độ dài 48 bit, là chỉ số gói SRTP. Chỉ số gói được mã hóa với tham số tạo ra những đoạn dòng khóa. Hình 8 mô tả chỉ số gói nhận được cần nằm trong vùng của cửa sổ trượt, và bit “Received?” tương ứng với nó cần chưa đánh dấu để chuyển gói sang các bước xử lý tiếp theo. Nếu gói không đáp ứng yêu cầu đó, nó sẽ bị loại ngay. Nếu kẻ tấn công chọn ngẫu nhiên số trong dãy, và kích thước của số là 64 thì xác xuất gói sẽ bị loại trước khi tiến hành xác thực thông báo là rất lớn.
Hình 8 Cửa sổ trượt dùng để chống tấn công lặp gói
Lời kết
Bảo mật mã thoại trên mạng IP, đặc biệt là dòng điện thoại SIP là những vấn đề tương đối mới. Hiện nay trên thế giới đã có nhiều công trình nghiên cứu về vấn đề này nhưng dường như vẫn chưa có được một giải pháp thực sự hoàn hảo (theo nghĩa tối ưu về công nghệ và thuận tiện sử dụng). Trong nội dung bảo mật mã thoại IP thì vấn đề an toàn dữ liệu thời gian thực hết sức phức tạp. Ở đây không chỉ thuần túy giải quyết bài toán an toàn mật mã mà còn phải giải quyết vấn đề hết sức quan trọng là tính thời gian thực của luồng dữ liệu cần bảo vệ vì phần lớn các dữ liệu này mang tính tương tác cao. Có giải quyết được vấn đề này thì giải pháp bảo mật mới có thể thực sự có tính ứng dụng. Nhưng dù thế nào đi chăng, hiện nay nữa điện thoại SIP vẫn cứ phát triển với tốc độ chóng mặt trên phương diện toàn cầu. Nghiên cứu bảo mật điện thoại SIP sẽ vẫn là vấn đề “nóng” và hi vọng rằng sẽ có giải pháp hoàn thiện được cộng đồng người sử dụng đón nhận
