Thủ tục đồng bộ lại xảy ra khi các chuỗi trình tự trong USIM (SQNMS) và trong AuC (SQNHE) không trùng nhau trong một dải quy định. Sự khác nhau này được phát hiện trong USIM khi nó tiến hành so sánh hai số trình tự này với nhau. Thủ tục được diễn ra như sau (hình 3.13):
Hình 3.13 Thủ tục đồng bộ lại của AKA.
VLR/SGSN gửi đi “yêu cầu nhận thực người sử dụng RAND(i)||AUTN(i)” đến USIM (1). Sau khi nhận được bản tin này USIM tiến hành kiểm tra tính xác thực của bản tin. Nếu đây là bản tin được tạo ra tại HE quản lý nó thì hai số trình tự SQNHE và SQNMS phải nằm trong một giải, nếu SQNHE nằm ngoài dải của SQNMS thì thủ tục đồng bộ lại được tiến hành. Khi đó USIM sẽ tạo ra một thẻ đồng bộ lại (AUTS) và gửi nó đến VLR/SGSN (2). Sau khi nhận được sự cố đồng bộ VLR/SGSN tìm một hô lệnh ngẫu nhiên thích hợp từ bộ nhớ của mình và bổ sung nó vào bản tin “yêu cầu số liệu nhận thực” và gửi bản tin này (“yêu cầu số liệu nhận thực RAND(i)||AUTS”) đến HLR/AuC đang quản lý thuê bao (3). Khi AuC nhận được AUTS từ bản tin trên, nó tiến hành so sánh hai số trình tự. Nếu thấy rằng AV tạo ra tiếp theo có thể tiếp nhận được, nó sẽ gửi AV này đến VLR/SGSN (4). Nếu không có AV nào trong số các AV được lưu nằm trong dải được USIM tiếp nhận, AuC sẽ tiến hành kiểm tra sự toàn vẹn của bản tin. Quá trình này để đảm bảo rằng chính USIM muốn thủ tục đồng bộ lại, nếu nhận thực này thành công, chuỗi SQNHE được đặt vào SQNMS. Sau đó, AuC sẽ xóa các AV cũ đồng thời tạo ra các AV mới. Vì việc tạo ra nhiều AV trong thời gian thực có thể chiếm tải lớn đối với AuC, nên có thể chỉ một AV được gửi đi trong lần trả lời đầu tiên. Khi đó, AV mới được gửi đến từ AuC sẽ được gắn thêm thông số Qi.
Khi VLR/SGSN nhận được các AV mới được gửi đến từ AuC, nó sẽ xóa tất cả các AV cũ để đảm bảo rằng các AV này không dẫn đến sự cố đồng bộ lại khác. Sau đó, VLR/SGSN lại thực hiện lại từ đầu thủ tục AKA bằng cách gửi “yêu cầu nhận thực người sử dụng RAND(i)||AUTN(i)” đến USIM (1)…..
Tiếp theo ta đi tìm hiểu về sử dụng lại các AV do USIM từ chối do kiểm tra số trình tự. Việc sử dụng lại các AV này cản trở mạng thực hiện AKA với sử dụng lặp lại một AV.
Tuy nhiên, việc sử dụng lại Av lại cần thiết, ví dụ khi VLR/SGSN gửi bản tin “yêu cầu nhận thực người sử dụng” đến USIM, nhưng lại không nhận được trả lời của USIM do mạng bị sự cố. Khi vượt quá thời gian tạm dừng để chờ trả lời, VLR/SGSN sẽ tìm cách gửi lại USIM cặp (RAND(i)||AUTN(i)) một lần nữa. Nếu thực chất USIM đã nhận được AV này lần đầu, nó coi rằng số trình tự nhận được nằm ngoài dải. Trong trường hợp này để khởi đầu thủ tục đồng bộ lại, USIM khởi đầu bằng cách so sánh hô lệnh ngẫu nhiên vừa nhận được (RAND) với RAND nhận được trước đó. Nếu chúng trùng nhau, nó chỉ cần gửi đi trả lời của người sử dụng (RES) được lưu lại lần cuối cùng. Vì thế cần lưu tất cả các thông số được đặt ra tại USIM.
Trong 3G UMTS ngay cả khi thực hiện cuộc gọi khẩn cũng cần thực hiện thủ tục nhận thực. Nhưng nếu nhận thực bị sự cố (do không có USIM hoặc do không có thỏa thuận chuyển mạng) kết nối vẫn sẽ được thiết lập. Cuộc gọi sẽ chỉ bị hủy nếu bảo mật và toàn vẹn thất bại.
3.7An ninh trong 3G UMTS R5 3.7.1 An ninh miền mạng NDS 3.7.1.1 MAPsec
Mục đích của MAPsec là bảo vệ bí mật cũng như toàn vẹn các tác nghiệp MAP. Bảo vệ MAPsec được thực hiện trong ba chế độ. Chế độ thứ nhất an ninh không được đảm bảo, chế độ thứ hai chỉ bảo vệ toàn vẹn, chế độ thứ ba cả bí mật lẫn toàn vẹn đều được đảm bảo.
Để đảm bảo bí mật, tiêu đề của các tác nghiệp MAP được mật mã hóa. Một tiêu đề an ninh được bổ sung để chỉ dẫn cách giải mật mã. Để đảm bảo toàn vẹn, một MAC nữa được tính toán dựa trên tải tin của các tác nghiệp MAC gốc và tiêu đề an ninh. Một thông số thay đổi theo thời gian cũng được sử dụng để tránh tấn công bằng cách phát lại.
3.7.1.2 IPsec
Các phần chính của IPsec là tiêu đề nhận thực (AH), tải tin an ninh đóng bao(ESP) và trao đổi khóa Internet (IKE).
IPsec được sử dụng để bảo vệ các gói IP. Quá trình này được thực hiện bởi ESP, nó đảm bảo cả bí mật lẫn toàn vẹn, còn AH chỉ đảm bảo tính toàn vẹn. Cả AH và ESP đều cần các khóa để thực hiện nhận thực và mật mã hóa các gói. Vì thế trước khi sử dụng ESP và AH cần đàm phán các khóa này. Quá trình này được thực hiện một cách an ninh thông qua IKE được xây dựng trên ý tưởng mật mã hóa khóa công cộng nhằm trao đổi thông tin an ninh trên đường truyền không an ninh.
Tồn tại hai chế độ ESP: chế độ truyền tải và chế độ truyền tunnel. Trong chế độ truyền tải toàn bộ gói IP (trừ tiêu đề) đều được mật mã hóa. Sau đó một tiêu đề ESP mới được bổ sung giữa tiêu đề IP và phần vừa được mật mã hóa. Sau cùng mã nhận thực bản tin (MAC) được tính toán cho toàn bộ, trừ tiêu đề IP và MAC được đặt vào cuối gói. Tại phía thu, tính toán toàn vẹn được đảm bảo bằng cách loại bỏ tiêu đề IP khỏi đầu gói và MAC khỏi cuối gói. Sau đó thực hiện hàm MAC và so sánh đầu ra của nó với MAC trong gói. Nếu toàn vẹn thành công, tiêu đề ESP được loại bỏ và phần còn lại được giải mã.
Trong chế độ truyền tunnel, một tiêu đề mới được bổ sung tại đầu gói. Sau đó quá trình này được tiến hành như ở chế độ truyền tải cho gói mới nhận được. Điều này có nghĩa là tiêu đề IP của gói gốc được bảo vệ.
Truyền thông ESP được thực hiện giữa hai đầu cuối sử dụng chế độ truyền tải.
Để thực hiện quá trình này hai phía truyền thông phải biết được địa chỉ IP của nhau và thực hiện chức năng IPsec.
3.7.2 An ninh IMS
3.7.2.1 Giao thức khởi tạo phiên SIP
SIP làm việc như sau: một người sử dụng hoặc một tác nhân người sử dụng (UA) gửi một bản tin lời mời “INVITE” đến một người sử dụng khác để bắt đầu phiên họp nơi mà dữ liệu đa phương tiện được trao đổi. SIP ủy thác giúp người sử dụng thực hiện nhiệm vụ này. UA này cũng gửi bản tin đăng ký “REGISTER” tới các Server SIP, cái mà được gọi là “các hộ tịch viên”. Việc đăng ký của UA này giúp cho các UA khác có thể tìm được nó. UA được mời sẽ gửi trở lại UA mời một bản tin OK nếu quyết đinh chấp nhận phiên họp. Trong tải của các bản tin SIP, các phiên truyền thông sử dụng giao thức miêu tả phiên (SDP). Các đặc tính này bao gồm tên và thời gian của phiên, kiểu và dạng của chuỗi truyền thông, các địa chỉ và cổng của nơi nhận. Người sử dụng có thể kết thúc các phiên này bằng việc gửi bản tin “BYE”.
SIP dựa trên cách thức hỏi và trả lời, tương tự như HTTP. Mỗi bản tin SIP là một yêu cầu được gửi từ một Client tới một Server hoặc một trả lời được gửi ngược trở lại. Chú ý rằng UA bao gồm cả hai Server (UAS) và Client (UAC).
Có 6 kiểu yêu cầu cơ bản, được gọi là các phương thức trong SIP: “REGISTER” sử dụng cho việc đăng ký thông tin cho một người sử dụng; “INVITE”; “ACK” và “CANCEL” để thiết lập các phiên; “BYE” để kết thúc các phiên; “OPTION” để tìm ra các khả năng của Server. Ngoài ra còn có “INFO” để truyền các thông tin báo hiệu phiên trung bình và “MESSAGE” cho các bản tin gấp.
Các trả lời bao gồm một mã tình trạng tạo thành từ ba số nguyên. Số đầu tiên cho biết kiểu của trả lời trong các dạng dưới đây:
+ 1xx là trả lời cá nhân, được thiết lập trong quá trình xử lý kết quả; + 2xx biểu thị yêu cầu được chấp nhận;
+ 3xx biểu thị gián tiếp;
+ 4xx biểu thị lỗi Client, bằng cách nào đó một yêu cầu trở nên xấu hoặc gửi nhầm Server;
+ 5xx biểu thị lỗi Server (ví dụ yêu cầu hợp lệ nhưng Server không thực hiện nó);
+ 6xx là lỗi cục bộ, yêu cầu không thể được thực hiện bởi tất cả các Server. Một giao dịch bao gồm yêu cầu được gửi đi bằng một Client và tất cả trả lời cho các yêu cầu đó được gửi lại bởi một Server. Lớp giao dịch SIP chịu trách nhiệm truyền lại các yêu cầu và trả lời, làm khớp các trả lời cho đúng với các yêu cầu và không tính thời gian.
Yêu cầu INVITE thiết lập một hộp thoại: một mối quan hệ SIP ngang hàng, tồn tại một thời gian và bao gồm vài giao dịch. Hộp thoại cũng làm cho việc sắp xếp dễ dàng hơn và việc định tuyến các bản tin SIP giữa các UA chính xác hơn.
Ngoài ra, các bản tin SIP còn bao gồm các trường tiêu đề và nội dung bản tin. Dưới đây là ví dụ về các kiểu tiều đề:
+ Via: bao gồm địa chỉ để được trả lời; (adsbygoogle = window.adsbygoogle || []).push({});
+ To: ghi rõ một cách logic theo yêu cầu của người nhận; + From: chỉ thị khởi đầu của một yêu cầu;
+ Call-ID: nhận dạng duy nhât một phiên của một người dùng cụ thể;
+ Contact: hướng tới một nhận dạng tài nguyên đồng dạng (URI) và ý nghĩa của chúng phụ thuộc vào kiểu yêu cầu;
+ Content-Type: biểu thị kiểu thông tin được truyền trong nội dung bản tin; + Authentication-Info: được sử dụng để nhận thực qua lại bởi cơ chế tóm tắt HTTP;
+ Authorization: bao gồm các giấy chứng nhận của UA cần cho việc nhận thực;
+ Priority: biểu thị sự khẩn cấp của yêu cầu;
+ Record-Router: được thêm vào bởi sự ủy thác cho các yêu cầu trong tương lai để định tuyến thông qua cùng một sự ủy thác;
+ Subject: biểu thị đặc tính/bản chất của cuộc gọi.
3.7.2.2 Kiến trúc an ninh IMS
Trong miền PS, dịch vụ chỉ được cung cấp khi đã thiết lập một liên kết an ninh giữa thiết bị di động và mạng. IMS về bản chất là một hệ thống xếp chồng liên miền. Vì thế cần có một liên kết an ninh riêng giữa Client đa phương tiện và IMS, trước khi cho phép truy nhập các dịch vụ đa phương tiện. Kiến trúc an ninh IMS
được cho ở hình 3.14.
Các khóa nhận thực IMS và các hàm tại phía người sử dụng được lưu tại UICC. Các khóa và các hàm này có thể độc lập logic với các khóa và các hàm sử dụng để nhận thực cho miền. Tuy nhiên, điều này không cản trở việc sử dụng các khóa nhận thực và các hàm chung cho việc nhận thực cả miền IMS lẫn miền PS.
Hình 3.14 Kiến trúc an ninh IMS.
Tồn tại năm liên kết an ninh và các nhu cầu khác nhau để bảo vệ an ninh cho IMS, các liên kết này được đánh số 1, 2...5 trên hình 3.14 như sau:
1. Đảm bảo nhận thực tương hỗ. HSS giao phó thực hiện nhận thực thuê bao cho IMS CSCF. Tuy nhiên nó chịu trách nhiệm tạo ra các khóa và các hô lệnh. Khóa dài hạn trong mô dun nhận dạng dịch vụ đa phương tiện Internet (ISIM) và HSS liên kết với nhận dạng riêng đa phương tiện Internet (IMPI). Thuê bao sẽ có một nhận dạng riêng người sử dụng trong mạng (IMPI) và ít nhất một dạng công cộng người sử dụng bên ngoài (IMPI: nhận dạng công cộng đa phương tiện Internet).
2. Đảm bảo đường truyền an ninh và liên kết an ninh giữa UE và P-CSCF để bảo vệ điểm giao diện Gm. Nhận thực nguồn gốc số liệu được đảm bảo (chứng thực rằng nguồn gốc số liệu nhận được là đúng như yêu cầu).
3. Đảm bảo an ninh giữa miền mạng bên ngoài cho giao diện Cx.
4. Đảm bảo an ninh giữa các mạng khác nhau đối với các nút có khả năng SIP.
5. Đảm bảo an ninh trong mạng giữa các nút có khả năng SIP.
3.7.2.3 Mô hình an ninh IMS của UMTS R5
3G UMTS R5 chỉ thay đổi mạng lõi chuyển mạch gói, còn phần chuyển mạch kênh của mạng lõi có thể là MSC/GMSC của các kiến trúc trước. R5 đưa ra hai phần tử chính và mạng lõi (mô tả cho trường hợp kết nối cuộc gọi giữa các IMS).
Hình 3.15 Kiến trúc an ninh IMS của UMTS R5.
1. Miền mạng lõi mới: được gọi là hệ thống con mạng lõi đa phương tiện IP (IMS).
2. Nâng cấp các SGSN để hỗ trợ thoại thời gian thực và các dịch vụ nhạy cảm khác hay IMS.
Vùng đa phương tiện Internet được xây dựng trên cơ sở giao thức khởi tạo phiên (SIP) dựa trên công nghệ VoIP. Trong miền PS, dịch vụ không được cung cấp chừng nào chưa được liên kết an ninh giữa các thiết bị di động và mạng. IMS chồng lấn lên miền PS và ít lệ thuộc vào miền này. Điều khiển trong R5 được thực hiện bởi mạng nhà. Sự điều khiển phức tạp này dẫn đến sự xuất hiện 3 chức năng điều khiển tình trạng cuộc gọi (CSCF): I-CSCF (CSCF hỏi); S-CSCF (CSCF phục vụ) và P-CSCF (CSCF ủy khác). Để sử dụng dịch vụ của IMS, trước hết người sử dụng phải đăng ký với mạng. Trong mọi trường hợp dù ở mạng nhà hay mạng khách thủ tục này được thực hiện qua P-CSCF. P-CSCF vừa đảm bảo hỗ trợ phiên đa phương tiện cơ sở, vừa đóng vai trò như một tường lửa cho miền IMS. Quá trình người sử dụng tìm thấy P- CSCF như sau: trước hết user tích cực một phiên PDP context để báo hiệu và đăng ký, nhận được một địa chỉ IP động hoặc tĩnh, sau đó user này sẽ gửi một tra hỏi hệ thống tên miền (DNS) về P-CSCF. Khi đó DNS tại GGSN gửi trả lời địa chỉ của P-CSCF.
Tất cả báo hiệu UE-mạng đều được gửi đến P-CSCF và đầu cuối di động không thể biết được địa chỉ của các CSCF khác. Một bản tin đăng ký được gửi đến P-CSCF, bản tin này được P-CSCF chuyển đến I-CSCF trong mạng nhà (P-CSCF nhận dạng mạng nhà theo IMSI hoặc SIP URL của người sử dụng). I-CSCF đóng vai trò như một cổng đối với mạng khác, có nhiệm vụ kiểm soát truy nhập IMS qua các mạng khác và hỏi HSS. S-CSCF có nhiều chức năng hơn P-CSCF và I-CSCF. Nó truy nhập đến các tài nguyên cần thiết để xử lý dịch vụ được yêu cầu. HSS là một HLR được bổ sung các khả năng mới phù hợp cho miền IM.
3.7.2.4 Quá trình đăng ký và nhận thực trong IMS
Trong mục này chúng ta sẽ tìm hiểu tổng quan về các thành phần của kiến trúc an ninh IMS được sử dụng trong giao thức khởi tạo phiên (SIP) (hình 3.16).
Có hai thủ tục quan trọng trong cả bản thân giao thức khởi tạo phiên (SIP) lẫn an ninh IMS, đó là: “REGISTER” để đăng ký và “INVITE” để thiết lập các phiên. Chúng ta sẽ nói đến giải pháp an ninh cho IMS xung quanh hai chức năng cơ bản này.
Sử dụng IMS dựa trên cơ sở của sự tán thành. Người sử dụng thỏa thuận với người quản lý IMS và có một nhận dạng riêng IMS (IMPI) cái này được lưu ở cả ISIM lẫn HSS. Nó cũng là một mật mã, khoá chủ (K 128bit) được lưu trong bộ nối của IMPI. IMPI không được chỉ định để đề địa chỉ người sử dụng; thay vào đó tồn tại ít nhất một nhận dạng công cộng IMS (được cài vào IMPI). Có thể có sự khác nhau về các đặc điểm dịch vụ bên trong một tiểu mục đơn giản, các IMPU khác nhau sẽ được nối tới cùng một IMPI. Về mặt kỹ thuật thì IMPI có hình thể của nhận dạng truy nhập mạng (NAI), trong khi IMPU có hình thể của một SIP URI hoặc URL(định vị tài nguyên đồng dạng). (adsbygoogle = window.adsbygoogle || []).push({});
Trước khi một thuê bao có thể bắt đầu sử dụng dịch vụ được cung cấp bởi IMS, thuê bao đó phải thực hiện đăng ký, công việc này có thể được thực hiện bằng