Yêu cầu đối với các thuật toán và các hàm mật mã

Một phần của tài liệu Bảo mật dữ liệu đầu vào cho mạng 3G (Trang 68)

Các hàm và các thuật toán mật mã phải đáp ứng các yêu cầu chặt chẽ và phải được thiết kế để có thể tiếp tục được sử dụng ít nhất là 20 năm. Các UE chứa các hàm này không bị giới hạn về xuất khẩu và sử dụng. Thiết bị mạng như RNC và AuC có thể phải chịu các hạn chế. Việc xuất khẩu các nút này phải tuân thủ thỏa thuận Wasenaar. Như vậy mỗi nhà khai thác có thể thiết lập thiết bị và giải thuật theo luật và giấy phép địa phương và người sử dụng có thể Roaming bằng thiết bị của mình mỗi khi chuyển đến một hãng hoặc nước mới. Khi không biết các khoá đầu vào, ta không thể phân biệt các hàm này với các hàm ngẫu nhiên độc lập của các đầu vào của chúng. Thay đổi một thông số đầu vào mỗi lần không thể phát hiện bất kỳ thông tin nào về khoá bí mật K hay trường cấu hình của nhà khai thác dịch vụ.

3.9.2. Các hàm mật mã

Các tính năng an ninh của UMTS được thực hiện bởi tập các hàm và các giải thuật mật mã. Có tất cả 10 hàm mật mã để thực hiện các tính năng: f0-f5, f1*, f5*, f8 và f9.

f0 là hàm tạo ra hô lệnh ngẫu nhiên, 7 hàm tiếp theo là các hàm tạo khoá vì thế chúng đều là đặc thù của nhà khai thác. Các khoá được sử dụng để nhận thực chỉ được tạo ra ở USIM và AuC, đây là hai miền mà một nhà khai thác đồng thời phải chịu trách nhiệm.

Các hàm để tạo ra các thông số AKA là: f1, f2, f3, f4, f5 và việc lựa chọn các hàm này về nguyên tắc là tuỳ thuộc vào nhà khai thác dịch vụ. Do việc thiết kế thuật toán mã hoá mạnh cho các hàm này rất khó nên 3GPP đã cung cấp một tập mẫu các thuật toán AKA với tên gọi là MILENAGE. Việc cấu trúc các giải thuật này dựa trên một giải thuật mật mã mạnh 128 bit được gọi là hàm lõi cùng với các trường cấu trúc bổ sung do nhà khai thác lựa chọn. AES (Advance Encrypt Standard) được khuyến nghị sử dụng cho hàm lõi của các hàm f1, f2, f3, f4 và f5. Các hàm f8 và f9 sử dụng hàm lõi là bộ mã hoá khối KASUMI.

Các hàm f8 và f9 được sử dụng trong USIM và RNC và vì hai miền này có thể thuộc các nhà khai thác khác nhau, nên chúng không thể đặc thù cho nhà khai thác. Các hàm này sử dụng khoá bí mật chung quy định trước - K. Lý do là để tránh phân phối K trên mạng và để giữ nó an toàn trong USIM và AuC.

Hàm Chức năng Đầu ra

f0 Hàm tạo số ngẫu nhiên RAND

f1 Hàm nhận thực mạng MAC-A/XMAC-A

f1* Hàm nhận thực bản tin đồng bộ lại MAC-S/XMAC-S

f2 Hàm nhận thực ngưởi sử dụng RES/XRES

f3 Hàm tạo ra khoá mật mã CK

f4 Hàm tạo ra khoá toàn vẹn IK

f5 Hàm tạo ra khoá dấu tên AK

f5* Hàm tạo ra khoá dấu tên cho bản tin

đồng bộ lại

AK

f8 Hàm mã hoá bản tin Bản tin đã được mã hoá

f9 Hàm tạo dấu ấn từ khoá toàn vẹn MAC-I/XMAC-I

Các hàm f1, f2, f3, f4, f5, f1*, f5* được thiết kế để có thể thực hiện trên IC sử dụng CPU 8 bit, hoạt động tại xung nhịp 3,25 Mhz, 8 kB ROM và 300 kB RAM. Các hàm này tạo ra AK, XMAC-A, RES và IK trong thời gian không quá 500 ms. Các hàm f1, f2, f3, f4, f5, f5* được gọi là các hàm tạo khoá, chúng được sử dụng trong các thủ tục AKA khởi đầu.

3.9.3. Sử dụng các hàm bình thƣờng để tạo ra AV trong AuC

Hình 3.7: Tạo ra AV trong AuC

Khi tạo một AV mới, AuC đọc giá trị của số trình tự được lưu, sau đó nó tạo ra một SQN mới và số ngẫu nhiên RAND mới. Cùng với AMF và khoá bí mật dùng chung quy định trước được lưu, bốn thông số đầu vào đã được chuẩn bị để sử dụng.

Các hàm sử dụng đầu vào và tạo ra các giá trị cho mã nhận thực bản tin, MAC-A kết quả kỳ vọng nhận thực người sử dụng, X-RES. Khoá mật mã CK, khoá toàn vẹn IK, khoá nặc danh AK. Sau khi SQN  AK, ta được thẻ nhận thực AUTN gồm: SQN  AK, AMF và MAC

3.9.4. Sử dụng các hàm bình thƣờng để tạo ra các thông số an ninh trong USIM

Để tạo ra các khoá đầu ra trong USIM, chỉ có một trong số bốn thông số mà AuC lấy làm đầu vào đó là khoá bí mật chia sẻ quy định trước K. Các thông số đầu vào còn lại phải được nhận từ AuC.

Khi USIM nhận được cặp RAND và AUTN nó bắt đầu tạo ra khoá dấu tên AK bằng hàm f5 dựa trên RAND nhận được. Bằng cách XOR AK với SQN nhận được từ thẻ nhận thực, ta xác định được SQNHE của AuC. Sau đó khoá bí mật chung được sử dụng cùng với AMF, SQN và RAND để tạo ra XMAC-A, mã nhận thực bản tin kỳ vọng. Sau đó XMAC-A được so sánh với MAC-A. Nếu chúng trùng nhau, USIM nhận thực rằng bản tin đúng là nhận được từ HE mong muốn và tiếp tục tiến hành các hàm tạo khoá. Sau khi nhận thực thành công mạng, USIM kiểm tra SQNHE có nằm trong dải quy định hay không (dải này được định nghĩa bởi nhà khai thác dịch vụ). Nếu số trình tự này nằm trong dải quy định, USIM tiếp tục tạo ra RES bằng hàm f2 dựa trên các thông số K và RAND.

3.9.5. Sử dụng các hàm để đồng bộ lại tại USIM

Khi sử dụng, USIM nhận thấy chuỗi trình tự nhận được nằm ngoài dải, chức năng tạo khoá bình thường bị huỷ và USIM bắt đầu tạo ra thẻ đồng bộ lại AUTS.

Hình 3.9: Thủ tục đồng bộ trong USIM

AMF được đặt bằng 0 trong bản tin đồng bộ lại. Sau đó hàm f1* tạo ra mã bản tin đồng bộ lại MAC-S với các đầu vào là: SQNMS - số trình tự lưu trong USIM, số ngẫu nhiên nhận được RAND, AMF đặt bằng 0 và khoá K. Sau đó MAC-S và SQNMS  AK được ghép vào AUTS. Cuối cùng bản tin “sự cố đồng bộ” cùng với AUTS được gửi đến VLR/SGSN. Các hàm đặc biệt f1* và f5* chỉ được sử dụng cho thủ tục đồng bộ lại. Các hàm này được xây dựng sao cho các giá trị của chúng không làm lộ các hàm khác.

3.9.6. Sử dụng các hàm đồng bộ lại tại AuC

AuC nhận được RAND, AUTS từ VLR/SGSN và thực hiện thủ tục đồng bộ lại. Hàm f1* sử dụng các thông số đầu vào RAND, AMF và K để tạo ra mã nhận thực đồng bộ lại kỳ vọng XMAC-S. XMAC-S được so sánh với MAC-S, nếu trùng nhau thì thủ tục sẽ được tiến hành tiếp.

Hình 3.10: Thủ tục đồng bộ lại trong AuC

Hàm f5* sử dụng các thông số đầu vào là RAND và K để tạo ra khoá dấu tên AK, sau đó XOR với SQNMS, tìm được SQNMS của USIM.

AuC so sánh hai số trình tự SQNMS và SQNHE. Nếu nó nhận thấy AV được tạo ra tiếp theo sẽ được tiếp nhận, nó sẽ gửi AV này trở lại VLR/SGSN. Nếu không AV nằm trong dải tiếp nhận bởi USIM, AuC đặt SQNHE=SQNMS. VLR/SGSN sẽ tạo ra XMAC-S và so sánh nó với MAC-S nhận được từ AUTS. Quá trình này được thực hiện để nhận thực thuê bao và nếu thành công, số trình tự của AuC SQNHE được đặt lại bằng SQNMS. Sau khi đặt lại SQNHE của AuC, AuC phải tạo lại một tập các AV mới.

3.9.7. Thứ tự tạo khoá

Thứ tự tạo khoá có thể không được thực hiện như đã mô tả. Thứ tự được mô tả ở trên là logic, nhưng thực hiện có thể khác, nếu việc thực hiện này hiệu quả hơn, nhưng vẫn phải đảm bảo rằng các khoá phải sẵn sàng theo thứ tự trình bày ở trên.

3.9.8. Kích cỡ của các thông số nhận thực

Thông số Định nghĩa Số bit

K Khoá bí mật chung quy định trước 128

RAND Số ngẫu nhiên 128

SQN Số trình tự 48

AK Khoá nặc danh 48

AMF Trường quản lý nhận thực 16

MAC Mã nhận thực bản tin 64 CK Khoá mã hoá 128 IK Khoá toàn vẹn 128 RES Trả lời 32-128 X-RES Trả lời kỳ vọng 32-128 AUTN Thẻ nhận thực 128(16+64+48) AUTS Thẻ nhận thực đồng bộ lại 96-128

MAC-I Mã nhận thực cho bản tin toàn vẹn số liệu 32

3.9.9. Sử dụng hàm f9 để tính toán mã toàn vẹn

Hầu hết các phần tử thông tin báo hiệu điều khiển được gửi giữa UE và mạng đều được coi là nhạy cảm và cần được bảo vệ. Hàm toàn vẹn f9 được sử dụng cho các thông tin báo hiệu được phát đi giữa UE và RNC. Trái lại số liệu của người sử dụng không được bảo vệ toàn vẹn mà nó chỉ được bổ sung ở các giao thức bậc cao hơn nếu cần thiết. Bảo vệ toàn vẹn là bắt buộc ở UMTS cho các bản tin báo hiệu. Hàm f9 được sử dụng giống như AUTN và AUTS. Nó bổ sung các con dấu vào các bản tin để đảm bảo rằng các bản tin này được tạo ra tại nhận dạng hợp lệ. Nó cũng đảm bảo rằng bản tin không phải là giả mạo.

Bộ đếm COUNT-I tăng mỗi khi có bản tin được bảo vệ toàn vẹn. Tồn tại hai bộ đếm cho đường lên và đường xuống. COUNT-I cùng với số nhận dạng hướng đảm bảo rằng các thông số đầu vào luôn thay đổi trong một kết nối để tránh tấn công phát lại. Khoá toàn vẹn được tạo ra ở cả AuC lẫn USIM. VLR/SGSN nhận IK trong AV đến từ AuC và gửi nó đến RNC sau khi nhận thực tương hỗ hoàn tất. Khi xảy ra chuyển giao, khoá toàn vẹn được chuyển từ RNC hiện thời đến RNC mới. IK không thay đổi khi chuyển giao.

Các thông số đầu vào cho hàm toàn vẹn được cho trong bảng:

Thông số Mô tả Số bit

COUNT-I Số trình tự toàn vẹn 32

IK Khóa toàn vẹn 128

FRESH Từ đặc biệt phía mạng 32

DIRECTION Hoặc 0 ( UE  RNC) hoặc 1 ( RNC  UE) 1

MESSAGE Bản tin báo hiệu cùng với nhận dạng kênh mang vô

tuyến

Từ đặc biệt phía mạng FRESH được sử dụng để chống các tấn công phát lại. Một giá trị FRESH được ấn định cho từng người sử dụng và RNC tạo ra từ này khi thiết lập kết nối. Sau đó nó gửi từ này đến ngưởi dụng bằng “Lệnh chế độ an ninh”. Trong thời gian hiệu lực của giá trị FRESH là một kết nối và FRESH mới sẽ được tạo ra tại kết nối sau. Ngoài ra khi chuyển giao, FRESH sẽ được đặt lại bằng giá trị mới. Số nhận dạng hướng là 1 bit, với “0” cho bản tin từ USIM đến RNC (đường lên) và “1” cho bản tin từ RNC đến USIM (đường xuống).

Số nhận dạng hướng (DIRECTION) được sử dụng để phân biệt bản tin phát và bản tin thu. Điều này cần thiết để tránh việc hàm sử dụng cùng một tham số cho các bản tin phát đi và phát về.

Bản tin đầu vào quan trọng cho hàm. Nhờ hàm này bản tin được bảo vệ toàn vẹn. Nếu ai đó thay đổi bản tin giữa nơi gửi và nơi nhận, nới nhận sẽ không có XMAC-I trùng với MAC-I thu được, vì thế nơi nhận sẽ từ chối bản tin này.

Hình 3.11: Nhận thực toàn vẹn bản tin sử dụng hàm toàn vẹn f9

MAC-I và XMAC-I

Mã nhận thực toàn vẹn bản tin cho toàn vẹn số liệu MAC-I và XMAC-I kỳ vọng được sử dụng sau khi kết thúc các thủ tục AKA. MAC-I được tạo ra tại phía phát và được so sánh với XMAC-I tại phía thu. Phía phát tạo ra MAC-I với bản tin là một đầu vào và phía thu sử dụng bản tin đó đi kèm cho hàm của chính nó để tạo ra XMAC- I. Nếu chúng trùng nhau chứng tỏ rằng bản tin không bị thay đổi và gốc của nó được nhận thực. Nếu không trùng nhau, bản tin bị từ chối.

Nhận dạng thuật toán toàn vẹn UMTS

Vì thuật toán toàn vẹn UMTS xảy ra ở cả USIM và RNC, nên chúng có thể ở các miền của các nhà khai thác khác nhau. Vì thế các nút có thể hỗ trợ các thuật toán khác nhau. Để nhận dạng các thuật toán khác nhau đã được dùng, mỗi UIA (UMTS Integrity Algorithm) được sử dụng, mỗi UIA có một nhận dạng riêng 4 bit. USIM sẽ cung cấp cho RNC thông tin về các UIA mà nó hỗ trợ và sau đó RNC quyết định sẽ sử dụng UIA nào (theo ưu tiên của nhà khai thác dịch vụ).

Handover to UTRAN Complete (hoàn thành chuyển giao đến UTRAN).

Paging Type (kiểu tìm gọi 1)

PUSCH CAPACITY REQUEST

PHYSICAL SHARED CHANNEL ALLOCATION

RRC CONNECTION REQUEST

RRC CONNECTION SETUP

RRC CONNECTION SETUP COMPLETE

RRC CONNECTION REJECT

RRC CONNECTION RELEASE (CCCH only)

SYSTEM INFORMATION (BROADCAST INFORMATION)

SYSTEM INFORMATION CHANGE INDICATION

TRANSPORT FORMAT COMBINATION CONTROL (TM DCCH only)

3.9.10. Sử dụng hàm mật mã f8

Số liệu ngưởi sử dụng và một số phần tử thông tin báo hiệu được coi là nhạy cảm và cần phải được mã hoá. Để bảo mật nhận dạng, P-TMSI phải được truyền trong chế độ mã hoá tại thời điểm cấp phát và tại các thời điểm khác khi các thủ tục báo hiệu cho phép nó. Hàm mật mã đảm bảo chế độ truyền dẫn có bảo vệ trên các kênh truy nhập vô tuyến giữa UE và RNC.

Hình 3.12: Quá trình mật mã hóa và giải thuật f8

Hàm mật mã f8 là bộ mật mã luồng khoá để tạo ra một khối luồng khoá. Khối luồng khoá này thực hiện XOR với khối văn bản thô rồi phát kết quả lên giao diện vô tuyến. Luồng khoá của bộ mật mã hoá là duy nhất đối với từng khối. Nó không chỉ tạo ra một khoá trên một phiên để thực hiện XOR với tất cả các khối có kích cỡ chiều dài mà còn tạo ra một khoá mới cho tất cả các khối. Vì thế cả phía phát và phía thu phải đồng bộ bằng cùng một bộ đếm tại mọi thời điểm nếu không sẽ không thể giải mã. Các thông số đầu vào giải thuật mật mã:

Thông số Mô tả Số bit

COUNT-C Số trình tự bản tin mã hoá 32

CK Khoá mật mã 128

BEARER Nhận dạng kênh mang vô tuyến 5

DIRECTION 0 cho bản tin từ UE->RNC và 1 cho bản tin từ

RNC->UE

1

LENGTH Độ dài thực tế của bản tin đã được mã hoá 16

Bộ đếm COUNT-C tăng mỗi khi gửi đi hoặc nhận được một bản tin được bảo mật. Có hai bộ đếm cho đường lên và đường xuống. Thông số này cùng với nhận dạng hướng đảm bảo rằng các thông số đầu vào thay đổi trong một kết nối. Có thể có một khoá mật mã CK cho các kết nối CS - KCS được thiết lập giữa miền dịch vụ chuyển mạch kệnh với ngưởi sử dụng và một khoá mật mã khác cho các kết nối chuyển mạch gói CKPS được thiết lập giữa miền dịch vụ chuyển mạch gói với người sử dụng.

Khoá mật mã được tạo ra ở AuC và được gửi đến VLR/SGSN trong AV. Sau khi hoàn thành nhận thực 2 chiều, khoá này được gửi từ VLR/SGSN đến RNC. USIM tự tạo ra CK trong thời gian nhận thực. Khi thực hiện chuyển giao, CK được chuyển từ RNC hiện thời đến RNC mới để đảm bảo tiếp tục truyền thông. CK không đổi khi chuyển giao.

Nhận dạng kênh mang BEARER được sử dụng để phân biệt kênh mang vô tuyển logic khác nhau liên kết với cùng một ngưởi sử dụng trên cùng một kênh vật lý. Điều này được thực hiện để tránh xảy ra cùng một thông số đầu vào dẫn đến cùng một luồng khoá cho các kênh mang vô tuyến khác nhau.

Nhận dạng hướng DIRECTION được sử dụng để phân biệt các bản tin phát với các bản tin thu nhằm tránh sử dụng cùng các thông số đầu vào cho hàm. Nhận dạng hướng có kích cỡ 1 bit với “0” cho các bản tin phát đi từ USIM (đường lên) và “1” cho các bản tin phát đi từ RNC (đường xuống).

Một phần của tài liệu Bảo mật dữ liệu đầu vào cho mạng 3G (Trang 68)