đồ án: Bảo mật nhóm trong IP Multicast

đồ án:Bảo mật nhóm trong IP MulticastĐồ án tốt nghiệp với đề tài “Bảo mật nhóm trong IP Multicast” cung cấp những kiến thức cơ bản và sau đó đi sâu vào một số khía cạnh quan trọng liên quan đến vấn đề bảo mật nhóm trong Multicast. Đồ án được thực hiện với mong muốn tìm hiểu quá trình bảo mật nhóm trong Multicast.Đồ án được chia làm bốn chương như sau:Chương 1: Multicast và những thách thức về bảo mật nhómChương 2: Nhận thực dữ liệu MulticastChương 3: Quản lý khóa nhóm trong bảo mật nhómChương 4: Chính sách bảo mật nhómDo tính chất dàn trải và luôn thay đổi của vấn đề bảo mật cùng những hạn chế về hiểu biết của bản thân nên đồ án không tránh khỏi những thiếu sót. Vì vậy, em rất mong nhận được sự góp ý của các thầy cô để hoàn thiện hơn đồ án của mình trong tương lai

Đồ án tốt nghiệp đại học Mục lục

MỤC LỤC

MỤC LỤC i

DANH SÁCH HÌNH VẼ iv

THUẬT NGỮ VIẾT TẮT v

LỜI NÓI ĐẦU viii

CHƯƠNG 1 MULTICAST VÀ NHỮNG THÁCH THỨC VỀ BẢO MẬT NHÓM 1 1.2 Các phương pháp chuyển tiếp Multicast 2

1.2.1 Các cây nguồn 3

1.2.2 Các cây dùng chung .4

1.3 Định tuyến trong IP Multicast 5

1.3.1 IGMP 5

1.3.2 IGMPv1 .6

1.3.3 IGMPv2 6

1.3.4 IGMPv3 7

1.3.5 Định tuyến Multicast 7

1.4 Multicast và những thách thức trong vấn đề bảo mật nhóm 9

1.5 Bảo vệ nội dung Multicast 12

1.5.1 Vấn đề điều khiển dữ liệu Multicast bảo mật 12

1.5.2 Vấn đề quản lý nguyên liệu tạo khóa 14

1.5.3 Vấn đề chính sách bảo mật Multicast 18

1.6 Bảo vệ kiến trúc hạ tầng 19

1.7 Kết luận chương 1 19

CHƯƠNG 2 NHẬN THỰC DỮ LIỆU MULTICAST 21

2.1 Các vấn đề trong nhận thực dữ liệu Multicast 21

2.1.1 Cung cấp nhận thực nhóm 23

2.1.2 Cung cấp nhận thực nguồn 23

2.2 Chữ ký số cho nhận thực nguồn 24

2.3 Chuỗi hàm băm cho nhận thực dữ liệu kiểu luồng 28

2.4 Nhận thực nguồn dựa trên MAC của các luồng không tin cậy 30

Đồ án tốt nghiệp đại học Mục lục

2.4.1 Quá trình khởi tạo TESLA 32

2.4.2 Nhận thực các gói ở bên gửi dựa trên MAC 33

2.4.3 Xử lý gói tại các bên nhận trong TESLA 33

2.4.4 TESLA mở rộng 35

2.5 Kết luận chương 2 35

CHƯƠNG 3: QUẢN LÝ KHÓA NHÓM TRONG BẢO MẬT NHÓM 37

3.1 Mô hình quản lý khóa nhóm 38

3.2 Các yêu cầu trong quản lý khóa nhóm 39

3.2.1 Các yêu cầu bảo mật cho quản lý khóa Unicast 40

3.2.2 Các yêu cầu bảo mật cho quản lý khóa nhóm 41

3.3 Quản lý GSA 43

3.3.1 Mô hình GSA 44

3.3.2 Định nghĩa GSA 45

3.4 Phân loại các vấn đề quản lý khóa nhóm 47

3.5 Kiến trúc và giao thức quản lý khóa nhóm 47

3.5.1 Vấn đề kiến trúc 49

3.5.1.1 IKAM 50

3.5.1.2 IOLUS 58

3.5.2 Các giao thức phân phối khóa 63

3.5.2.1 GKMP 63

3.5.2.2 GSAKMP 66

3.5.2.3 GDOI 70

3.6 Các thuật toán quản lý khóa nhóm 78

3.6.1 Chuyển khóa theo chu kỳ và theo đợt 80

3.6.2 Cân bằng trong chuyển khóa theo đợt 81

3.6.3 MARKS 82

3.6.4 LKH 84

3.7 Kết luận chương 3 89

CHƯƠNG 4 CHÍNH SÁCH BẢO MẬT NHÓM 90

4.1 Khung chính sách bảo mật nhóm 91

4.2 Phân loại chính sách bảo mật nhóm 94

Đồ án tốt nghiệp đại học Mục lục

4.2.1 Chính sách thông báo 94

4.2.2 Chính sách thành viên 95

4.2.3 Chính sách ủy quyền hay điều khiển truy nhập 95

4.2.4 Chính sách bảo vệ dữ liệu 96

4.2.5 Chính sách ủy quyền quản lý nhóm 96

4.2.6 Chính sách phân phối khóa 97

4.2.7 Chính sách khôi phục tổn hại 98

4.3 Thực thi chính sách bảo mật nhóm 98

4.4 Kết luận chương 4 99

KẾT LUẬN 100

TÀI LIỆU THAM KHẢO 102

Đồ án tốt nghiệp đại học Thuật ngữ viết tắt

DANH SÁCH HÌNH VẼ

Hình 1.1 Truyền dẫn Multicast 2

Hình 1.2 Cây nguồn 3

Hình 1.3 Cây phân phối dùng chung 4

Hình 2.1 hàm băm kiểu sao 26

Hình 2.2 Hàm băm kiểu cây 27

Hình 2.3 Chuỗi hàm băm 28

Hình 2.4 Giản đồ chuỗi hàm băm 29

Hình 2.5 Chuỗi khóa và dẫn xuất khóa MAC 31

Hình 2.6 Thông tin nhận thực cùng gói dữ liệu trong TESLA 33

Hình 2.7 Các khoảng thời gian trong TESLA 34

Hình 3.1 Các đối tượng trong quản lý khóa nhóm 38

Hình 3.2 Định nghĩa GSA 45

Hình 3.3 Phân chia vùng miền 51

Hình 3.4 Ví dụ về kiến trúc IKAM 52

Hình 3.5 bố trí IKAM các khóa cho các nhóm dữ liệu và điều khiển 54

Hình 3.6 Các nhóm con trong kiến trúc Iolus 60

Hình 3.7 Chuyển tiếp khóa / dữ liệu trong Iolus 62

Hình 3.8 Tiến trình GSAKMP 68

Hình 3.9 Trao đổi bước 2 GDOI 76

Hình 3.10 Bản tin ấn định GDOI 77

Hình 3 11 Sơ đồ khối chức năng của GDOI 78

Hình 3.12 Các loại hình chuyển khóa 81

Hình 3.13 Chuyển khóa theo đợt và điều khiển truy nhập chuyển tiếp 82

Hình 3.14 Phân phối khóa trong MARKS 83

Hình 3.15 Ví dụ về phân cấp khóa trong LKH 85

Hình 3.16 Minh họa khởi tạo cây khóa LKH 86

Hình 3.17 Chuyển khóa gia nhập trong LKH 87

Hình 3.18 Chuyển khóa rời nhóm trong LKH 89

Hình 4.1 Khung phân phối chính sách bảo mật nhóm 93

Đồ án tốt nghiệp đại học Thuật ngữ viết tắt

THUẬT NGỮ VIẾT TẮT

ACL Access Control List Danh sách điều khiển truy nhập

AKD Area Key Distributor Bộ phân phối khóa vùng

AMAAE Area Multicast address allocation

entity

Đối tượng cấp phát địa chỉ Mutlicast vùng

AMESP Application Mutlicast

Encapsulating Security Payload

Ứng dụng Multicast đóng gói bảo mật tải tin

CRL Compromise Recovery List Danh sách khôi phục tổn hại

DKD Domain Key Distributor Bộ phân phối khóa miền

DMAAE Domain Multicasst address

ESP Encapsulating Security Payload Đóng gói bảo mật tải tin

FEC Forward error correction Sửa lỗi trước

GCKS Group Controller/ Key Server Bộ điều khiển nhóm/ Server khóaGDOI Group Domain Of Interpretation Miền biên dịch nhóm

GKD Group Key Distributor Bộ phân phối khóa nhóm

GKMP Group Key Management

Protocol

Giao thức quản lý khóa nhóm

Đồ án tốt nghiệp đại học Thuật ngữ viết tắt

GOC Group Owner/ Creator Chủ/ Bộ tạo nhóm

GSA Group Security Association Liên kết bảo mật nhóm

GSAKMP Group Security Association Key

Management Protocol

Giao thức quản lý khóa liên kết bảo mật nhóm

GSC Group Key Controller Bộ điều khiển khóa nhóm

GSI Group Security Intermediarie Trung gian bảo mật nhóm

GSPT Group Security Policy Token Thẻ bài chính sách bảo mật nhóm

IGMP Internet Group Management

Protocol

Giao thức quản lý khóa Internet

IKAM Internet Key Architecture for

Mutlicast

Kiến trúc khóa Internet cho Multicast

IKE Internet Key Exchange Trao đổi khóa Internet

ISA Internet Security Association Liên kết bảo mật Internet

ISAKMP Internet Security Association

Key Management Protocol

Giao thức quản lý khóa liên kết bảo mật Internet

LKH Logical Key Hierarchical Phân cấp khóa logic

MAAS Multicast Address Allocation

Server

Server cấp phát địa chỉ Multicast

MAC Message Authentication Code Mã hóa nhận thực bản tin

MOSPF Multicast Open Shortest Path

Đồ án tốt nghiệp đại học Thuật ngữ viết tắt

PIM-SM Protocol Independent Multicast-

Spare Mode

Giao thức multicast độc lập -Chế độ phân tán

PKI Public Key Infrastructure Cấu trúc hạ tầng khóa công khai

SPI Security Parameter Index Chỉ số tham số bảo mật

TEK Traffic Encryption Key Khóa mã hóa lưu lượng

TESLA The Timed Efficien Stream Loss

Tolerant Authentication

Giao thức nhận thực cho phép- tổn thất luồng hiệu quả về mặt thời gian

Đồ án tốt nghiệp đại học Lời nói đầu

LỜI NÓI ĐẦU

Sự phát triển không ngừng của Internet đã thúc đẩy các ứng dụng mạng và các dịch vụ mới Do đó số lượng khách hàng muốn đồng thời truy cập tăng lên rất lớn trong mạng Internet Nó đặt ra yêu cầu cung cấp truy nhập dữ liệu trong khi tối ưu hóa băng thông Multicast được phát triển như một phương pháp phân phối dữ liệu từ một máy phát tới nhiều máy thu một cách hiệu quả, đảm bảo tối ưu hóa băng thông, giảm tải mạng Mặc dù với những ưu thế vượt trội về băng thông như thế nhưng khi nhìn vào thực tế chúng ta thấy rằng sau rất nhiều các công trình nghiên cứu và phát triển các giao thức Multicast trong thập kỷ trước, việc triển khai các ứng dụng của Multicast vẫn rất chậm chạp Nguyên nhân chính là do các dịch vụ Multicast thiếu hỗ trợ về quản lý lưu lượng, độ tin cậy và bảo mật

Bảo mật nhóm trong Multicast là một trong những vấn đề quan trọng nhất để giải quyết việc triển khai các ứng dụng thông tin nhóm Ví dụ, nhà đầu tư muốn một sự đảm bảo rằng các báo giá chứng khoán phân phát qua Multicast được nhận thực Tương tự như vậy, các nhà cung cấp dịch vụ muốn giới hạn nội dung phân phối tới các thuê bao

đã trả tiền cho dịch vụ Ở một khía cạnh khác, bảo mật là một yêu cầu của các ứng dụng hội thảo quan trọng Tóm lại là các ứng dụng phổ biến của Multicast rất có nhu cầu về tính toàn vẹn dữ liệu, điều khiển truy nhập và tính riêng tư

Đồ án tốt nghiệp với đề tài “Bảo mật nhóm trong IP Multicast” cung cấp những kiến thức cơ bản và sau đó đi sâu vào một số khía cạnh quan trọng liên quan đến vấn

đề bảo mật nhóm trong Multicast Đồ án được thực hiện với mong muốn tìm hiểu quá trình bảo mật nhóm trong Multicast

Đồ án được chia làm bốn chương như sau:

Chương 1: Multicast và những thách thức về bảo mật nhóm

Chương 2: Nhận thực dữ liệu Multicast

Chương 3: Quản lý khóa nhóm trong bảo mật nhóm

Chương 4: Chính sách bảo mật nhóm

Do tính chất dàn trải và luôn thay đổi của vấn đề bảo mật cùng những hạn chế về hiểu biết của bản thân nên đồ án không tránh khỏi những thiếu sót Vì vậy, em rất mong nhận được sự góp ý của các thầy cô để hoàn thiện hơn đồ án của mình trong tương lai Sinh viên

Vũ Bá Dũng

Đồ án tốt nghiệp đại học Chương1 Multicast và những thách thức

CHƯƠNG 1 MULTICAST VÀ NHỮNG THÁCH THỨC VỀ BẢO

MẬT NHÓM

Cùng với sự phát triển của các mạng tốc độ cao và sự bùng nổ về kỹ thuật nén, các ứng dụng đa phương tiện trở thành nhu cầu tất yếu Tuy nhiên các ứng dụng này không phù hợp với kiểu truyền Unicast truyền thống Trong khi đó Multicast truyền luồng dữ liệu tới nhiều điểm đích có nhu cầu nhận Cơ chế này giúp giảm tải cho mạng đến mức nhỏ nhất do bản tin chỉ thực hiện nhân gói tại những điểm rẽ nhánh tại một bộ định tuyến

1.1 Giới thiệu chung về IP Multicast

IP Multicast là một chuẩn mở của IETF dùng để truyền dẫn các gói dữ liệu IP từ một nguồn đến nhiều đích trong một mạng LAN hay WAN Các máy thu tham gia vào một nhóm Multicast Với IP Multicast, các ứng dụng chỉ gửi một bản sao của thông tin cho một địa chỉ nhóm Thông tin này chỉ gửi đến những điểm muốn nhận được lưu lượng đó Các nút có khả năng Multicast chạy bộ giao thức TCP/IP có thể nhận được bản tin Multicast Việc gửi bản tin Unicast và Broadcast là các trường hợp đặc biệt của phương pháp Multicast Truyền Multicast cải thiện đáng kể về hiệu suất, thường sử dụng băng thông nhỏ hơn truyền điểm- điểm trên mạng, và cho phép xây dựng các ứng dụng phân tán hợp lý

Việc truyền IP Multicast sử dụng phương pháp đa hướng bao gồm ba hoạt động riêng biệt: quyết định địa chỉ nhóm cho các nhóm, đăng kí thành viên nhóm, định tuyến các bản tin

Một địa chỉ Multicast cho phép phân phát một luồng dữ liệu đơn tới một tập hợp các máy trạm đã được cấu hình như những thành viên của một nhóm Multicast trong các mạng con phân tán khác nhau Đây là phương pháp truyền dẫn đa điểm Các nút nhận ra các gói Multicast tại mức phần cứng Các nhóm Multicast linh động với các điểm thu có thể được tạo ra và loại bỏ nhanh chóng

Một khái niệm quan trọng của IP Multicast là nhóm Multicast.Việc xây dựng một nhóm Multicast bắt đầu với một server đang chạy một ứng dụng Multicast như audio, video Khi một server được xây dựng, một địa chỉ Multicast Lớp D được gán cho ứng dụng đó và tất cả các thành viên của nó Một nhóm Multicast được cấp phát cho một địa chỉ lớp D đại diện cho nhóm đó Số lượng thành viên của nhóm có thể là 0, 1 hay nhiều thành viên Các thành viên có thể nằm tại các mạng con khác nhau Một máy

Đồ án tốt nghiệp đại học Chương1 Multicast và những thách thức

trạm bất kì có thể trở thành nguồn Multicast khi nó muốn truyền lưu lượng cho các máy trạm khác trong mạng

Hình 1.1 Truyền dẫn Multicast

Khi một máy thu muốn gia nhập một nhóm, nó gửi một bản tin IGMP chứa địa chỉ lớp D của nhóm mong muốn tới Bộ định tuyến Multicast cục bộ của nó Từ điểm đó, các bản tin nhóm gửi trực tiếp tới mạng của thiết bị thu Các máy thu có thể gia nhập nhóm hoặc rời bỏ khỏi nhóm bất cứ lúc nào

Một Bộ định tuyến Multicast phải có mặt trong mỗi mạng con có chứa máy thu Multicast Một trong những chức năng của bộ định tuyến này là giúp các máy thu trên các mạng gắn liền với nó truy nhập hệ thống phân phát Multicast Sau khi bộ định tuyến nhận bản tin IGMP từ phía thu, nó chuyển tiếp tất cả lưu lượng Multicast cho nhóm - mạng của thiết bị thu

1.2 Các phương pháp chuyển tiếp Multicast

Có một vài phương pháp để chuyển tiếp lưu lượng IP Multicast từ các máy trạm nguồn đến các máy thu Đầu tiên ta sắp xếp một nhóm bao gồm các máy trạm thu với một địa chỉ lớp D chung để đạt được sự phân phối lưu lượng Multicast hiệu quả Bước

Đồ án tốt nghiệp đại học Chương1 Multicast và những thách thức

tiếp theo là tạo ra một tập hợp các đường phân phối Multicast cho các bộ định tuyến sử dụng Các giao thức được xây dựng trong các bộ định tuyến giúp xây dựng cây phân phối Multicast để chuyển tiếp các gói Giao thức chuyển tiếp Multicast chủ yếu sử dụng một trong hai kỹ thuật sau:

1.2.1 Các cây nguồn

Dạng đơn giản nhất của cây phân phối Multicast là cây nguồn có gốc là nguồn Multicast và các nhánh của nó có dạng cây mở rộng dọc theo mạng đến các điểm thu

Nó là một cây đường ngắn nhất (Shortest path tree- SPT)

Hình dưới đây là ví dụ về một SPT cho nhóm 224.1.1.1 có gốc đặt tại nguồn A và

2 máy thu được nối đến máy trạm B và máy trạm C Kí hiệu (S,G) cho một SPT ở đó S

là địa chỉ IP nguồn và G là địa chỉ nhóm Multicast Ở ví dụ dưới đây SPT có kí hiệu là (192.1.1.1, 224.1.1.1)

Đồ án tốt nghiệp đại học Chương1 Multicast và những thách thức

1.2.2 Các cây dùng chung

Phương pháp chuyển tiếp cây dùng chung có nhiều ưu thế nhất trong phân phối Multicast Tuy nhiên, phương pháp chuyển tiếp cây dùng chung là một sự lựa chọn tốt hơn so với phương pháp cây chung gốc khi môi trường Multicast bao gồm các nhóm Multicast phân bố rải rác với những kết nối bậc thấp

Hình 1.3 Cây phân phối dùng chung

Phương pháp cây - dùng chung sử dụng một bộ định tuyến Multicast trung tâm, đôi khi được coi như một bộ định tuyến lõi Các máy trạm nguồn Multicast gửi các gói Multicast của chúng tới bộ định tuyến lõi này, và lần lượt chuyển tiếp các gói này qua cây dùng chung đến các thành viên của nhóm Một cây- dùng chung sử dụng một cây đơn giữa các nguồn và các thành viên nhóm

Trên đây là một ví dụ về cây dùng chung cho nhóm 224.2.2.2 với gốc đặt tại bộ định tuyến D Khi sử dụng cây dùng chung này, các nguồn phải gửi lưu lượng của chúng đến gốc và sau đó lưu lượng được chuyển tiếp xuống cây dùng chung đến tất cả các máy thu

Trong ví dụ trên, lưu lượng Multicast từ các máy trạm nguồn A và D chuyển đến gốc (Bộ định tuyến D) và sau đó được chuyển xuống 2 điểm nhận theo cây dùng chung

là bộ định tuyến B và C Do tất cả các nguồn Multicast đều sử dụng cây dùng chung

Đồ án tốt nghiệp đại học Chương1 Multicast và những thách thức

nên kí hiệu wild-card (*,G) được sử dụng đại diện cho cây Ở đó, * là tất cả các nguồn,

G là địa chỉ nhóm Multicast, như ví dụ kí hiệu là (*, 224.2.2.2)

Cả SPT và shared-tree đều là loop-free Các bản tin chỉ được nhân lên tại các điểm

Các SPT có ưu điểm trong việc tạo ra đường dẫn tối ưu nguồn và các máy thu Điều này đảm bảo trễ chuyển tiếp lưu lượng Multicast thấp nhất cho mạng Sự tối ưu này có giá của nó đó là các bộ định tuyến phải duy trì thông tin đường dẫn từ nó đến nguồn Trong một mạng có hàng nghìn nguồn và hàng nghìn điểm nhận thì điều này nhanh chóng trở thành vấn đề về tài nguyên trên các bộ định tuyến Sự tiêu thụ bộ nhớ của bảng định tuyến Multicast là một vấn đề đáng quan tâm của người thiết kế

Các cây dùng chung có ưu điểm trong việc hạn chế số trạng thái của mỗi bộ định tuyến Do đó bộ nhớ yêu cầu cho toàn mạng khi sử dụng cây dùng chung cũng ít hơn Tuy nhiên, hạn chế của cây dùng chung là đường dẫn giữa nguồn và máy thu không phải là đường dẫn tối ưu và do đó có thể tạo ra trễ trong phân phối các gói Các nhà thiết kế mạng phải quan tâm đúng mức đến vị trí đặt các RP (rendezvous point) trong môi trường chỉ có các cây dùng chung

1.3 Định tuyến trong IP Multicast

1.3.1 IGMP

IGMP được các Bộ định tuyến Multicast sử dụng để thông báo trạng thái thành viên của các máy trạm trên các đường kết nối trực tiếp Điều này được thực hiện thông qua một loạt các truy vấn IGMP liên tục và các thông báo máy trạm thành viên

IGMP sử dụng một địa chỉ lớp D dành riêng là 224.0.0.1 Đây là một nhóm cố định cho tất cả các hệ thống IP Multicast Nó đảm bảo tính có sẵn của 1 địa chỉ Multicast thông qua subnet có thể liên kết với Bộ định tuyến Multicast của nó Một máy trạm hỗ trợ Multicast phải gia nhập tất cả các hệ thống nhóm cho mỗi giao diện mạng

mà nó

Đồ án tốt nghiệp đại học Chương1 Multicast và những thách thức

IGMP v1 được đưa ra trong RFC 1112 (tháng 8/1989) và v2 được chỉ ra trong RFC 2236 (tháng 8/1997) IGMP v3 được chỉ ra ra trong RFC 3376 (tháng 8/2002) là

sự kết hợp của v1 và v2

1.3.2 IGMPv1

Để tham gia vào một nhóm Multicast, một máy trạm sẽ gửi một thông điệp đăng

ký nhóm đến bộ định tuyến cục bộ của nó Thông điệp này có tên là Membership Report IGMP chứa địa chỉ nhóm Multicast, thông báo cho bộ định tuyến về địa chỉ Multicast mà máy trạm muốn tham gia vào Địa chỉ Multicast 224.0.0.1 all-hosts được dùng như địa chỉ đích Cứ 60 giây, một bộ định tuyến trên mỗi phân đoạn mạng sẽ gửi truy vấn đến tất cả các máy trạm để kiểm tra xem các máy trạm này có còn quan tâm nhận lưu lượng Multicast nữa không? Bộ định tuyến này gọi là IGMPv1 Querier và chức năng của nó là mời các máy trạm tham gia vào nhóm Nếu một máy trạm muốn tham gia vào một nhóm, hoặc nó muốn tiếp tục nhận từ một nhóm mà nó đã tham gia,

nó phải trả lời lại bằng thông điệp membership-report

Các máy trạm có thể tham gia vào các nhóm Multicast ở bất kỳ thời điểm nào Tuy nhiên IGMPv1 không có cơ chế để cho phép một máy trạm rời khỏi một nhóm nếu máy trạm đó không còn quan tâm đến nội dung của nhóm Multicast đó Thay vào đó,

bộ định tuyến sẽ kết luận là một cổng giao tiếp đó không còn thuộc về một nhóm Multicast nào nếu bộ định tuyến không nhận được membership-report trong ba chu kỳ truy vấn liên tiếp Điều này có nghĩa là, ở chế độ mặc định, các lưu lượng Multicast vẫn gửi vào một phân đoạn mạng trong ba chu kỳ truy vấn liên tiếp sau khi tất cả các thành viên của nhóm không còn lắng nghe lưu lượng Multicast nữa

Ngoài ra, bộ định tuyến không giữ một danh sách đầy đủ các máy trạm thành viên cho từng nhóm Multicast Thay vào đó, nó cần phải lưu những nhóm Multicast nào là đang tồn tại trên những cổng nào của nó

1.3.3 IGMPv2

Phiên bản IGMPv2 giới thiệu một vài khác biệt so với phiên bản đầu tiên Các gói tin truy vấn bây giờ được gọi là General Queries Các gói này có thể gửi tới địa chỉ all-máy trạms hoặc tới từng nhóm cụ thể Một cải tiến khác nữa là các máy trạm được phép rời khỏi nhóm Khi một máy trạm quyết định rời khỏi một nhóm nó đã tham gia, nó sẽ gửi thông điệp LeaveGroup đến địa chỉ all-router 224.0.0.2 Tất cả các bộ định tuyến trên một phân đoạn mạng nội bộ sẽ lưu ý thông điệp này và bộ định tuyến truy vấn sẽ tiếp tục quá trình Bộ định tuyến sẽ hỏi rằng có còn máy trạm nào muốn nhận lưu lượng cho nhóm đó nữa không bằng thông điệp truy cập gửi theo nhóm Bất cứ máy trạm nào

Đồ án tốt nghiệp đại học Chương1 Multicast và những thách thức

cũng phải trả lời lại bằng thông điệp membership report Nếu khác đi, bộ định tuyến sẽ kết luận một cách an toàn là không cần thiết chuyển lưu lượng cho nhóm đó trên phân đoạn mạng đó

1.3.4 IGMPv3

IGMP v3 là một dự thảo sơ bộ Nó giới thiệu bổ sung bản tin Group- Source Report cho phép một máy trạm có thể quyết định nhận lưu lượng từ các nguồn riêng biệt của một nhóm Multicast Một bản tin Group- Source Report cho phép một máy trạm chỉ ra địa chỉ IP của các nguồn riêng biệt mà nó muốn nhận Một bản tin Exclusion Group- Source Report cho phép một máy trạm nhận dạng chính xác các nguồn mà nó không muốn nhận Cuối cùng, bản tin Leave Group đã giới thiệu trong IGMPv2 đã nâng cao thành bản tin Group-Source Leave Đặc điểm này cho phép một máy trạm dời khỏi toàn bộ nhóm hay chỉ ra các địa chỉ IP riêng biệt của cặp (nguồn, nhóm) mà nó muốn rời khỏi

1.3.5 Định tuyến Multicast

Định tuyến lưu lượng Multicast phức tạp hơn định tuyến lưu lượng Unicast Số các máy thu trong một phiên Multicast có thể khá lớn Các bộ định tuyến mạng phải có khả năng chuyển địa chỉ Multicast sang địa chỉ máy trạm Trong định tuyến Multicast, các bộ định tuyến tương tác để trao đổi thông tin về các bộ định tuyến hàng xóm Giao thức quản lý nhóm sẽ chọn một bộ định tuyến đơn như bộ định tuyến bổ nhiệm (Designated router- DR) cho mỗi mạng vật lý DR thường là bộ định tuyến gần nhất với gốc

Bằng việc sử dụng các giao thức định tuyến Muticast, các bộ định tuyến Multicast thiết lập linh hoạt các cây đường đa điểm sử dụng thông tin thành viên nhóm có được từ việc truyền thông IGMP Các cây đường đa điểm đó chỉ ra các đường từ một máy phát tới tất cả máy thu Để hỗ trợ Multicasting, một bộ định tuyến cần phải hỗ trợ ít nhất một trong các giao thức định tuyến Multicast

Các giao thức định tuyến IP Multicast thường theo một trong hai dạng sau: dạng tập trung hoặc dạng phân tán

•Định tuyến Multicast dạng tập trung

Dạng tập trung: các thành viên nhóm Multicast được phân bố tập trung trong toàn mạng với nhiều mạng con chứa ít nhất một thành viên nhóm, có đặc trưng là chiếm băng tần lớn Các giao thức định tuyến dạng tập trung gồm: DVMRP, MOSPF và PIM-

Đồ án tốt nghiệp đại học Chương1 Multicast và những thách thức

DM Các giao thức này dựa vào kỹ thuật phát tán thông tin tới tất cả các bộ định tuyến mạng

•Định tuyến Multicast dạng phân tán

Dạng phân tán: thành viên nhóm nằm phân tán tại nhiều vùng của mạng và không yêu cầu băng tần lớn Nó dựa vào kỹ thuật lựa chọn để thiết lập và duy trì cây Multicast, sử dụng một quá trình khởi tạo máy thu (receiver-initiated process) Có nghĩa

là một bộ định tuyến chỉ xây dựng cây phân phối Multicast khi một trong các máy trạm thuộc mạng con của nó là thành viên của một nhóm muticast nào đó Các giao thức định tuyến dạng sparse gồm: cây dựa vào lõi (Core based tree- CBT) và PIM-SM

PIM

Các bộ định tuyến Multicast sử dụng PIM để xác định các bộ định tuyến Multicast khác cần nhận được gói Multicast PIM có hai phương thức làm việc đồng thời thích hợp: Kiểu Dense (tập trung) và Sparse (phân tán) Hỗ trợ PIM hiện có trong một số sản phẩm bộ định tuyến Mục đích của việc nỗ lực phát triển PIM là để mở rộng định tuyến Multicast liên miền qua Internet Định tuyến dựa vào giao thức PIM độc lập với các cơ chế của các giao thức định tuyến Unicast Bất kỳ sự triển khai nào hỗ trợ PIM đều yêu cầu sự có mặt của một giao thức định tuyến Unicast để cung cấp thông tin bảng định tuyến và để làm thích nghi với những thay đổi về cấu hình

Các bộ định tuyến hỗ trợ giao thức PIM được biết đến như các bộ định tuyến PIM Các bộ định tuyến chạy giao thức PIM chọn một bộ định tuyến PIM liền kề vào một hệ thống máy trạm như một máy trạm chỉ định Thông thường là bộ định tuyến có địa chỉ

IP cao nhất Định tuyến PIM sử dụng một cây giải thuật đường ngắn nhất Một bộ định tuyến PIM tồn tại ở gốc của mỗi cây đường dẫn ngắn nhất trong khi các bộ định tuyến PIM liên kết trực tiếp hệ thống máy trạm được coi là các bộ định tuyến lá Các giao thức PIM không định nghĩa các bản tin cập nhật định tuyến, chúng cũng sử dụng giao thức định tuyến Unicast truyền thống trên mạng IP Sự hỗ trợ này giúp bảo trì thông tin trạng thái bổ sung cho bảng định tuyến Unicast không hỗ trợ Multicast

Cả PIM- DM lẫn PIM- SM sử dụng chuyển tiếp đường dẫn đảo ngược Một bộ định tuyến nhận một gói Multicast dựa vào bảng định tuyến Unicast của nó để tìm nguồn và đường dẫn tốt nhất tới nguồn Khi bộ định tuyến nhận được một gói Multicast trên giao diện, bằng đường dẫn tốt nhất trở lại nguồn, bộ định tuyến chuyển tiếp một bản sao của gói dữ liệu trên tất cả các giao diện khác Các gói dữ liệu đến tại đầu vào giao diện được xem xét như đường lên của bộ định tuyến Các gói dữ liệu được chuyển tiếp tới đầu ra của giao diện được xem như đường xuống của bộ định tuyến

Đồ án tốt nghiệp đại học Chương1 Multicast và những thách thức

DVMRP & MOSPF

DVRMP bắt nguồn từ giao thức thông tin định tuyến (RIP) và sử dụng thuật toán TRPB( Truncated Reverse Path Broadcasting) Để tìm đường tốt nhất tới đích, nó sử dụng hop back trước tới nguồn như đơn vị đo DVMRP thiết lập cây nguồn sử dụng khái niệm cây broadcast rút gọn (TBT) Đó là cây mở rộng đường đi ngắn nhất từ mạng nguồn tới tất cả các bộ định tuyến trong mạng

Khi thiết lập cây, DVMRP cho phép bộ định tuyến gửi tràn datagram tới tất cả các giao diện trừ đường dẫn ngược về nguồn datagram Các bộ định tuyến DVMRP phải chạy các quá trình định tuyến riêng cho các gói muticast và Unicast

TBT được xây dựng cho tất các mạng con nhờ việc cập nhật thông tin định tuyến DVMRP định kỳ giữa các bộ định tuyến trong mạng Giống như RIPv2, thông tin cập nhật DVMRP chứa mặt nạ/tiền tố mạng cùng độ dài đường đi (theo hop count) cho biết giá để tới một mạng con cụ thể trong mạng Tuy nhiên, khác với RIPv2 bộ định tuyến DVMRP cấp dưới sử dụng quảng bá Poison- Reverse (PR) để thông báo cho một bộ định tuyến cấp trên liên kết này thuộc TBT của mạng nguồn S1 PR này được tạo ra bằng việc thêm 32 vào metric được quảng bá và gửi lại về bộ định tuyến cấp trên

MOSPF là mở rộng của giao thức định tuyến Unicast OSPF và do vậy đòi hỏi OSPF như giao thức định tuyến cơ sở Nó sử dụng một loại LSA OSPF gọi là LSA thành viên nhóm để thông báo sự tồn tại của thành viên nhóm trong các mạng LSAs thành viên nhóm được phát flood định kỳ trong cả vùng giống như LSA OSPF Nó sử dụng thuật toán Dijkstra để tính toán cây đường đi ngắn nhất cho tất cả các cặp nhóm mạng- nguồn

1.4 Multicast và những thách thức trong vấn đề bảo mật nhóm

Với ưu điểm về tiết kiệm băng thông như Multicast, nó là nền tảng để triển khai các dịch vụ đa phương tiện như phân phối dữ liệu, các chương trình truyền hình theo yêu cầu, hội thảo đa phương tiện Tuy nhiên, khi nhìn vào thực tế chúng ta thấy rằng sau rất nhiều các công trình nghiên cứu và phát triển các giao thức Multicast trong thập

kỷ trước, việc triển khai các ứng dụng của Multicast vẫn rất chậm chạp Nguyên nhân chính là do các dịch vụ Multicast thiếu hỗ trợ về quản lý lưu lượng, độ tin cậy và bảo mật

Bảo mật trong Multicast đưa ra cho ta những thách thức kỹ thuật mang tính chất đặc thù Các nhà thiết kế Multicast đưa ra cách sử dụng của nó để phân phối nội dung

dữ liệu một cách đồng thời tới số lượng lớn các bên nhận Nếu chỉ các bên nhận đó được cho phép nhìn thấy nội dung, nội dung dữ liệu phải được mã hóa Nhưng một

Đồ án tốt nghiệp đại học Chương1 Multicast và những thách thức

khóa mã hóa có thể làm thế nào để được phân phối hiệu quả tới nhiều bên nhận? Hơn nữa, một khóa cho dữ liệu mã hóa nên được thay đổi theo chu kỳ, vì chúng ta không chấp nhận mã hóa nhiều dữ liệu với chỉ cùng một khóa Và nó có lẽ nên được thay đổi khi các thành viên của nhóm thay đổi Giả thiết rằng các thành viên nhóm trả tiền để nhận nội dung như các kênh truyền hình đặc biệt, khi một thành viên rời khỏi nhóm, nhóm không thể bắt thành viên quên khóa Thêm nữa là nó muốn thay đổi khóa khi một thành viên mới gia nhập nhóm (để chúng không thể ghi lại nội dung mã hóa mà chúng không được quyền hoặc gia nhập trong một thời gian ngắn để tìm hiểu khóa sau đó chúng sẽ giải mã nội dung mà không được cho phép)

Vấn đề khác trong bảo mật thông tin là bảo vệ tính sự toàn vẹn và nhận thực dữ liệu Với một mẫu khóa bí mật, ai đó đang kiểm tra dữ liệu phải biết cùng một bí mật đã được sử dụng để tạo trường kiểm tra tính toàn vẹn Với thông tin hai bên thì điều đó không phải là vấn đề Nếu Alice đang gửi cái gì đó cho Bob, với một trường kiểm tra tính toàn vẹn đã được tạo ra từ một khóa mà chỉ hai bên chia sẻ, nếu trường kiểm tra tính toàn vẹn hợp lệ, BoB biết được rằng chỉ có Alice hay Bob có thể đã tạo ra bản tin Nếu Bob biết nó không phải của anh ấy thì nó phải là của Alice

Tuy nhiên, nếu cùng một kiểu đó được sử dụng trong thông tin nhóm, nơi mà Alice đang gửi nội dung tới hàng nghìn bên nhận, mỗi bên trong số hàng nghìn bên nhận đó sẽ phải biết cùng một bí mật mà Alice sử dụng để tạo trường kiểm tra bí mật Điều này có nghĩa là nội dung có thể đã bắt nguồn từ bất kỳ thành viên nào của nhóm

Do vậy, Alice phải tin tưởng tất cả thành viên nhóm đọc dữ liệu

Có ba vấn đề cần lưu tâm trong việc cung cấp các dịch vụ bảo mật Multicast Đầu tiên, các bên gửi cần phải mã hóa và nhận thực dữ liệu Multicast Đối với việc mã hóa, các thành viên nhóm yêu cầu một khóa chung giữa chúng Thêm nữa, điều khiển truy nhập có thể được tiến hành bằng sự phân phối một khóa chung tới các thành viên nhóm,

mà không cần tới sự thay đổi mô hình IPMulticast Khi các thành viên nhóm thay đổi, khóa chung có thể cần thiết phải thay đổi và phân phối lại tới nhóm mới của các thành viên đã được nhận thực Do đó sự phân phối khóa nhóm khả định cỡ và các kiểu chuyển khóa là một phần quan trọng của giải pháp bảo mật Multicast Tiếp theo, các thành viên phải có khả năng kiểm tra dữ liệu được nhận đã thực sự được gửi bởi một thành viên đã được nhận thực hay không Bởi vậy nhận thực nguồn gốc dữ liệu và mã hóa dữ liệu là một trong những vấn đề cần lưu tâm

Thêm nữa, những ứng dụng Multicast khác nhau- trong phạm vi từ việc thông tin

đa người dùng tới phân phối dữ liệu từ một tới nhiều người dùng có những yêu cầu biến đổi đối với các hệ thống đầu cuối, truyền thông và bảo mật Chính sách nhóm cho phép

Đồ án tốt nghiệp đại học Chương1 Multicast và những thách thức

chủ nhóm hay nhà cung cấp nội dung chỉ rõ các yêu cầu cũng như trạng thái nhóm mong muốn được thay đổi trong môi trường hoạt động

Cùng với bảo mật nội dung dữ liệu trong Multicast, chúng ta nhận ra bảo mật cơ

sở hạ tầng Multicast là một yêu cầu quan trọng khác, bao gồm sự tác động của tấn công

từ chối dịch vụ DoS trên mô hình dịch vụ phân phối số đông của Multicast Đặc biệt, các giao thức định tuyến Multicast, các giao thức Multicast tin cậy và giao thức quản lý nhóm internet IGMP cần thiết sự bảo vệ tính toàn vẹn của các bản tin điều khiển cho hoạt động hiệu chỉnh Nếu không có bảo vệ tính toàn vẹn, các thành viên không được nhận thực có thể tràn lụt cây Multicast hay lôi kéo bất hợp pháp các lưu lượng không được cho phép Do đó chúng ta cần phải thêm nhận thực bản tin điều khiển cũng như là nhận thực máy trạm hay bộ định tuyến, ta có thể coi đó là cách điều khiển truy nhập các thành viên gia nhập hoặc rời nhóm

Điều khiển truy nhập chỉ là một trong những nhân tố góp phần cho việc bảo mật truyền thông Multicast, các ứng dụng thường cần tính riêng tư, nhận thực, toàn vẹn, và không từ chối của dữ liệu Multicast Tuy nhiên, những yêu cầu này có thể khác nhau về cấp độ và tầm quan trọng cho những ứng dụng khác nhau Ví dụ có những ứng dụng chỉ cần thiết nhận thực bản tin nguồn (phân phối báo cáo chứng khoán ), trong khi những ứng dụng khác có thể cần tính riêng tư cũng như nhận thực Nói cách khác, chúng ta phải có khả năng cung cấp một cấp độ tùy chọn của bảo mật trong truyền thông Multicast

Qua những cách tiếp cận vấn đề như đã trình bày ở trên, có thể xem như bảo mật Multicast được thực hiện bằng việc kết hợp sử dụng điều khiển truy nhập nhóm, tính bảo mật và nhận thực của truyền dẫn dữ liệu, và bảo mật của cơ cở hạ tầng mạng Ngoại trừ điều khiển truy nhập nhóm, những yêu cầu này đã được đưa vào trong truyền thông Unicast Thật không may, các giải pháp thiết kế cho truyền thông điểm-điểm không thể sử dụng trực tiếp cho truyền thông nhóm Đặc biệt là các đàm phán chính sách bảo mật đa bên không thể hội tụ, và các giao thức thỏa thuận khóa nhóm được phân phối lại không phù hợp cho các nhóm lớn Thêm một điều nữa đối với khả năng định cỡ Multicast, các ứng dụng khác nhau có những yêu cầu bảo mật khác nhau, và

các giải pháp một- kích cỡ- khớp- tất cả sẽ không làm việc đối với nhiều ứng dụng

Multicast

Số lượng các bên gửi trong một nhóm là một nhân tố quan trọng trong thiết kế một giao thức truyền thông nhóm bảo mật Trong nhiều ứng dụng chỉ có một bên gửi SSM (Source- specific Multicast) là một mô hình định tuyến được thiết kế đặc biệt để hỗ trợ

Đồ án tốt nghiệp đại học Chương1 Multicast và những thách thức

Multicast một bên gửi Ví dụ cho các ứng dụng một bên gửi là phân phối báo giá chứng khoán qua Multicast

Multicast truyền thống, đôi khi được coi như là Multicast tiêu chuẩn Internet hay Multicast nhiều bên gửi, hỗ trợ truyền thông đa bên gửi Sự có mặt của đa bên gửi đưa

ra một vài vấn đề mới trong việc cung cấp bảo mật cho các dịch vụ Multicast Đầu tiên, các bên gửi khác nhau có thể có những yêu cầu chính sách khác nhau, mà có thể xung đột với nhau do đó khó mà hội tụ chính sách Thứ hai, các cơ chế bảo vệ phát lại khó thiết kế hơn trong các trường hợp đa bên gửi Do đó, đồ án chỉ giới hạn trong trường hợp Multicast một bên gửi Tuy nhiên các ứng dụng công cộng như hội thảo đa phương tiện bao gồm nhiều bên gửi có thể cũng cần tính riêng tư hay toàn vẹn bản tin Do các ứng dụng này thường chỉ có một vài bên gửi, một cách khả thi nhất là sử dụng nhiều phiên bảo mật Multicast một bên gửi- nhiều bên nhận

1.5 Bảo vệ nội dung Multicast

Nhóm nghiên cứu SMuG IRTF và nhóm làm việc MSec IETF đã nêu rõ ba vấn đề trong việc cung cấp bảo mật truyền thông nhóm: điều khiển dữ liệu Multicast bảo mật, quản lý nguyên liệu tạo khóa, và các chính sách bảo mật Multicast

1.5.1 Vấn đề điều khiển dữ liệu Multicast bảo mật

Phần này trình bày vấn đề bảo mật truyền dẫn dữ liệu Multicast Chính xác hơn là

sự biến đổi dữ liệu cho bảo mật dữ liệu Multicast và bảo vệ tính toàn vẹn Đối với bảo mật dữ liệu, bên gửi cần thiết phải mã hóa dữ liệu với một khóa bí mật mà các thành viên nhóm đều biết: nghĩa là các thành viên được nhận thực để nhận dữ liệu Multicast Trong đó phân phối khả định cỡ và chuyển khóa của khóa nhóm là một vấn đề phức tạp

Ta đã biết được rằng tính bảo mật của IPsec ESP thích hợp cho truyền thông Unicast ESP cũng hỗ trợ bảo vệ tính toàn vẹn được dựa trên mã hóa nhận thực bản tin MAC-cho truyền thông Unicast Trong truyền thông hai bên, nhận thực dựa trên MAC

đủ cho một bên nhận xác định một gói được bắt nguồn tại bên gửi hay không Thật không may là trường hợp nhận thực này lại không thích hợp trong truyền thông đa bên.Chú ý rằng trong truyền thông ngang hàng hai bên, Alice và Bob, mỗi người giữ một khóa bí mật cho nhận thực bản tin Alice sử dụng khóa để tính một mã nhận thực bản tin (chuỗi khối cipher hay hàm băm) của bản tin, và gửi bản tin cùng với MAC tới bên nhận Bob lặp lại thủ tục đó để tính MAC, và so sánh nó với MAC đã nhận Nếu các MAC đồng nhất, Bob biết được rằng bản tin không bị biến đổi trên đường đến đích

Đồ án tốt nghiệp đại học Chương1 Multicast và những thách thức

Anh ta cũng biết được rằng nếu anh ta không gửi bản tin, Alice phải gửi nó, giả thiết rằng khóa nhận thực không bị xâm phạm

Chúng ta có thể sử dụng MAC cho các phiên truyền thông nhóm nhận thực theo cách tương tự như trên, nhưng với một cấp độ giảm hơn về bảo vệ tính toàn vẹn Chú ý rằng một nhóm, bao gồm Alice, Bob và Cindy, đang giữ một khóa nhận thực Alice có thể sử dụng một MAC để nhận thực bản tin giử tới Bob và Cindy, tuy nhiên, Bob (hay Cindy) không biết có hay không bản tin đã gửi hay chỉnh sửa lần cuối bởi Alice hay Cindy (hay Bob) Thông thường, các thành viên của một nhóm chỉ có thể kiểm tra các bất thành viên, điều này có nghĩa là một người nào đó không giữ khóa nhận thực nhóm

đã không thay đổi dữ liệu trong quá trình chuyển tiếp

Nhận thực nhóm là tính chất quan trọng đảm bảo chỉ một bản tin được gửi (sửa đổi lần cuối) bởi một thành viên của nhóm Đối với nhận thực nhóm, bên gửi cần thiết lập một khóa chung với các thành viên nhóm Vấn đề phân phối khóa được bàn tới ở phần sau, IPsec ESP có thể được sử dụng để mang dữ liệu Multicast được nhận thực nhóm

Trong đa số các ứng dụng, các bên nhận phải có khả năng thiết lập nguồn dữ liệu,

ít nhất là cho chính chúng Nói cách khác, chúng ta cần thiết nhận thực nguồn dữ liệu Một phiên bản mạnh hơn các tính chất trên, được gọi là không- từ chối, cho phép bên

nhận xác nhận nguồn gốc dữ liệu tới bất kỳ bên thứ ba nào

Tuy nhiên, nhận thực nguồn của dữ liệu Multicast lại là một vấn đề khó Giải pháp đơn giản nhất là đánh dấu số mỗi gói tin Nhưng vấn đề đánh dấu mỗi gói tin lại dẫn đến sự tính toán tốn kém và làm tăng tiêu đề mỗi gói tin Một vài giải pháp đã đưa ra làm giảm giá của các chữ ký số đối với nhiều gói Chương 2 sẽ cung cấp mô tả chi tiết các kỹ thuật nhận thực nguồn

Thật không may là ESP không thể sử dụng được để mang dữ liệu Multicast đã được nhận thực nguồn Một cặp biến thể của ESP được gọi là MESP và MESP lớp ứng dụng (Application MESP- AMESP) đã được đề xuất tại IETF để thích nghi với các thiết

kế nhận thực nguồn cho Multicast MESP, tương tự IPsec ESP, hoạt động tại lớp mạng, trong khi AMESP làm việc tại lớp ứng dụng Việc thực hiện IPsec ESP hay MESP yêu cầu sự thay đổi tại cấp độ- lõi mạng Điều đó là không thể trong một số trường hợp và

có thể dẫn đến bị trễ việc triển khai AMESP là sự biến đổi để sử dụng trong những trường hợp như vậy

Các yêu cầu ứng dụng ảnh hưởng lớn tới các giải pháp cho nhận thực nguồn gốc

dữ liệu Đầu tiên, một ứng dụng có thể yêu cầu không- từ chối hay nhận thực nguồn hay

Đồ án tốt nghiệp đại học Chương1 Multicast và những thách thức

chỉ nhận thực nhóm Tiếp theo, truyền dẫn dữ liệu có thể là tin cậy hay tổn thất Thêm nữa, bên gửi hay các bên nhận có thể có không gian bộ đệm bị giới hạn hay phải tính toán công suất (các thiết bị di động) hoặc là có dung lượng không đồng nhất Các bên nhận cũng có thể ở khoảng cách rộng lớn khác nhau so với bên gửi Cuối cùng, ứng dụng có thể bao gồm truyền dẫn dữ liệu lớn hay theo kiểu luồng

1.5.2 Vấn đề quản lý nguyên liệu tạo khóa

Thuật ngữ “nguyên liệu tạo khóa” (keying material) ám chỉ khóa dùng để mã hóa đang thuộc về một nhóm, trạng thái liên kết với các khóa và các tham số bảo mật khác liên quan tới khóa Do đó, quản lý các khóa mã hóa thuộc về một nhóm cần các yêu cầu quản lý trạng thái liên kết và các tham số của nhóm đó

Điều khiển truy nhập nhóm, tính riêng tư, và nhận thực nhóm của dữ liệu Multicast yêu cầu một khóa chung được phân phối tới các thành viên hiện tại của nhóm bảo mật Chúng ta sử dụng một đối tượng logic được gọi là bộ điều khiển nhóm và server khóa ( Group controller and key server- GCKS) để cung cấp điều khiển truy nhập và các dịch vụ phân phối khóa Một GCKS đại diện cho cả đối tượng và các chức năng liên quan tới sự phát hành và quản lý của các khóa mã hóa được sử dụng bởi một nhóm Multicast, quản lý nhận thực người sử dụng và các trường kiểm tra nhận thực trên mỗi ứng viên của nhóm Multicast

Các giao thức đàm phán bảo mật Unicast như là IKE dẫn đến kết quả là mỗi khóa riêng biệt cho mỗi phiên, và không thể trực tiếp được sử dụng cho truyền thông nhóm Thay vào đó, một đối tượng trung tâm như là GCKS cần thiết để tải các khóa nhóm riêng biệt tới mỗi thành viên thông qua một kênh bảo mật

Đăng ký thành viên

Mỗi thành viên liên lạc với GCKS để đăng ký và gia nhập nhóm Sau khi nhận thực lẫn nhau, GCKS kiểm tra tư cách thành viên của máy trạm, thiết lập một kênh bảo mật, và tải các khóa nhóm và chính sách tới thành viên Quá trình đăng ký là trao đổi một-một giữa GCKS (hay một trong những đại diện đã nhận thực của nó) với mỗi thành viên Trao đổi bảo mật một- một yêu cầu các biện pháp bảo mật tương tự như trong IKE hay SSL, như là bảo vệ phát lại và tấn công từ chối dịch vụ…

Đăng ký khả định cỡ/ khởi tạo của các nhóm lớn Do đăng ký là một trao đổi một-

một, việc triển khai từng phiên liên lạc đơn lẻ cho tất cả các thành viên là không hiệu quả May mắn là có một vài cách để xúc tiến quá trình xử lý này Đầu tiên, chức năng của đăng ký GCKS có thể được thực hiện qua nhiều đối tượng Thứ hai, các thành viên

Đồ án tốt nghiệp đại học Chương1 Multicast và những thách thức

có thể đăng ký tại thời điểm thích hợp với chúng, bằng cách ấy có thể tránh được một

số lượng lớn các yêu cầu đăng ký tại cùng một thời điểm

Điều khiển truy nhập chuyển tiếp và chuyển ngược Lưu ý tới việc phân phối khóa

nhóm tới một nhóm linh động và rộng lớn Trong phần lớn các ứng dụng, trong khi nhiều thành viên gia nhập tại thời điểm bắt đầu của phiên và rời bỏ nhóm tại thời điểm kết thúc, các thành viên khác có thể gia nhập và rời bỏ tại bất kỳ thời điểm nào trong phiên Nói cách khác, nhiều thành viên có thể được chấp nhận tham gia một nhóm bảo mật chỉ trong một thời gian giới hạn Cũng hãy chú ý rằng một máy trạm có thể được ghi lại dữ liệu Multicast đã gửi trước khi nó được ủy quyền gia nhập nhóm Bởi vậy, GCKS cần thiết phải thay đổi khóa nhóm và phân phối khóa mới tới tất cả các thành viên Nói cách khác, các máy trạm đang gia nhập có thể giải mã dữ liệu đã gửi trước khi

nó trở thành một thành viên của nhóm Chúng ta coi tính chất này như là điều khiển truy nhập chuyển ngược Tương tự, GCKS cần thay đổi khóa nhóm khi một thành viên rời bỏ để không cho phép các thành viên đang rời bỏ giải mã các truyền thông nhóm trong tương lai Tính chất này được biết đến như là điều khiển truy nhập chuyển tiếp Tóm lại, để chắc chắn rằng chỉ các thành viên được ủy quyền hiện thời mới có thể giải

mã dữ liệu nhóm, điều khiển truy nhập chuyển ngược và chuyển tiếp phải là bắt buộc.Các bản tin chuyển khóa có thể được gửi qua Unicast hay Multicast để phân phối hiệu quả Tương tự như các bản tin đăng ký, các bản tin chuyển khóa cũng phải được bảo vệ khỏi tấn công phát lại, và phải được đánh dấu bởi GCKS cho việc nhận thực

Sự tác động của tính linh động các thành viên nhóm Kích thước và tính linh động

của nhóm có một ý nghĩa quan trọng tác động tới việc thực thi điều khiển truy nhập chuyển tiếp và chuyển ngược Lưu ý tới một phương pháp tiếp cận đơn giản quản lý khóa nhóm Bên gửi hay GCKS chia sẻ một khóa bí mật riêng biệt với mỗi thành viên Khi một thành viên rời nhóm, người quản lý phải gửi khóa nhóm mới đã mã hóa riêng biệt với mỗi khóa bí mật của các thành viên còn lại Do việc tính toán tiêu đề tại bên

Đồ án tốt nghiệp đại học Chương1 Multicast và những thách thức

gửi và truyền tải tiêu đề của kiểu này tăng lên cùng với kích thước nhóm, nên nó không hiệu quả cho các nhóm lớn và tính linh động cao

Liên kết bảo mật nhóm

Đối với bảo mật Unicast, hai bên truyền thông ngang hàng đàm phán các tham số bảo mật để thiết lập một liên kết bảo mật Internet (Internet security association- ISA) và giao thức quản lý khóa bảo mật Internet (Internet security association key management protocol- ISAKMP), là giao thức bảo vệ đàm phán của một IPsec SA cho bảo mật truyền dẫn dữ liệu Một mô hình tương tự là liên kết bảo mật nhóm (Group security association- GSA) đã được tiêu chuẩn hóa tại IETF, và có ba phần Phần đầu là việc đăng ký SA bảo vệ quá trình tải khóa trong giao thức đăng ký Quá trình tải khóa bao gồm một SA chuyển khóa và một SA bảo mật dữ liệu SA chuyển khóa bảo vệ các cập nhật SA chuyển khóa hiện thời hay SA bảo mật dữ liệu SA bảo mật dữ liệu chính nó bảo vệ quá trình truyền dẫn Multicast Ví dụ về một SA bảo mật dữ liệu bao gồm IPsec ESP, MESP và AMESP

Các giao thức, kiến trúc và thuật toán phân phối khóa nhóm

Ta phân loại việc phân phối khóa nhóm thành các kiến trúc, các giao thức và các thuật toán cho quản lý khóa nhóm Các kiến trúc phân phối khóa nhóm như Iolus và kiến trúc tạo khóa Internet cho Multicast (Internet keying architecture for Multicast-IKAM) sử dụng nhóm con phân cấp để quản lý nhóm một cách hiệu quả Chúng chia các thành viên vào trong các nhóm con, chỉ định các thành viên hay đại lý bên thứ ba như những người quản lý nhóm con (Subgroup manager- SGM) và ủy quyền tác vụ quản lý khóa nhóm cho các SGM

Thuật ngữ giao thức được sử dụng để mô tả một tập hợp các thủ tục, các trao đổi bản tin, và bản tin điều khiển trạng thái của các đối tượng trong việc hỗ trợ một nhóm bảo mật và sự tham gia đó trong một nhóm Miền biên dịch nhóm (Group domain of interpretation- GDOI) và giao thức quản lý khóa liên kết bảo mật nhóm (Group security association key management protocol- GSAKMP) là các giải pháp trong loại này

Các giao thức và các kiến trúc đều có những lợi ích riêng của nó Ví dụ, Iolus hay IKAM có thể sử dụng GDOI cho việc đăng ký và chuyển khóa trong một nhóm con Tương tự, GSAKMP cho phép nhiều thành viên được chỉ định như các quản lý nhóm con khả định cỡ Cả các giao thức và kiến trúc đều có thể lợi dụng các thuật toán quản

lý khóa nhóm, được mô tả dưới đây, hiệu quả cho việc chuyển khóa nhóm

Thuật toán quản lý khóa nhóm thường sử dụng nhóm con logic để chuyển khóa và phân phối khóa một cách hiệu quả Mỗi nhóm con logic có một khóa mã hóa khóa (Key

Đồ án tốt nghiệp đại học Chương1 Multicast và những thách thức

encryption key- KEK) đã liên kết được sử dụng để mã hóa các KEK khác hay khóa nhóm Hai lớp của thuật toán quản lý khóa nhóm dựa trên sự phụ thuộc lẫn nhau của các bản tin chuyển khóa Đầu tiên, dựa trên các phân cấp khóa logic (Logical key hierarchies- LKH) hay các cây khóa, mỗi thành viên giữ một tập con các KEK, GCKS trao đổi các KEK đó và khóa nhóm khi thành viên gia nhập hay rời đi Hầu hết các KEK phải được mã hóa với số khóa bằng với cấp độ của cây khóa Do vậy các phân cấp khóa logic sử dụng chuyển khóa yêu cầu ít hơn các bản tin, và ít hơn việc tính khóa tại GCKS Tại lớp thứ hai của thuật toán, GCKS chia các thành viên đã được ủy quyền thành các nhóm con logic được xác định trước, và gửi khóa nhóm được mã hóa với tập con các khóa như đã nêu trên Điều này sẽ tăng hiệu quả quản lý khóa nhóm và được trình bày rõ ở chương sau

Truyền tải tin cậy các bản tin chuyển khóa Các bản tin chuyển khóa thường được

gửi thông qua Multicast để tăng hiệu quả Trách nhiệm của GCKS là đảm bảo cho tất cả các thành viên đều có bảo mật dữ liệu hiện thời và các SA chuyển khóa Nói cách khác, các thành viên đã được ủy quyền có thể tình cờ bị mất khả năng giải mã các truyền thông nhóm Do vậy, GCKS phải sử dụng một cơ chế truyền tải tin cậy để gửi các bản tin chuyển khóa

Các bản tin chuyển khóa thường ngắn (thông thường là cho trao đổi thành viên đơn lẻ trong các nhóm lớn và các nhóm con), đó là cách dễ dàng để thiết kế một giao thức phân phối tin cậy Cũng có một vài trường hợp đặc biệt mà các trao đổi thành viên được xử lý trong một đợt, làm tăng kích cỡ của chúng Cuối cùng trong tất cả các KEK

đã gửi trong một bản tin chuyển khóa, tầm một nửa các thành viên chỉ cần một KEK đơn lẻ Chúng ta cần phải tận dụng ưu điểm của các tính chất này vào thiết kế bản tin chuyển khóa và giao thức cho phân phối tin cậy Ba loại giải pháp được đưa ra là:

1 Bởi vì trong nhiều trường hợp các bản tin chuyển khóa thường nhỏ (cố định trong một hay hai gói IP), GCKS có thể truyền lặp lại các bản tin chuyển khóa

2 GCKS có thể sử dụng một giao thức Multicast tin cậy hiện hành hay hạ tầng cơ

sở mạng

3 Chúng ta có thể sử dụng sửa lỗi trước FEC để mã hóa các gói chuyển khóa, sử dụng các bản tin ACK đàm phán phản hồi từ các thành viên để xây dựng các lượt tiếp theo của bản tin chuyển khóa Tuy nhiên chú ý rằng phân phối tin cậy dựa trên các phản hồi có thể dẫn đến sự bùng nổ của các bản tin phản hồi tại GCKS

Yêu cầu ứng dụng

Đồ án tốt nghiệp đại học Chương1 Multicast và những thách thức

Các yêu cầu ứng dụng ảnh hưởng lớn tới sự lựa chọn thiết kế của giải pháp cho phân phối khóa nhóm Trong nhiều trường hợp, như trong ứng dụng PPV (pure pay- per- view), tất cả thông tin SA cần cho phiên có thể được phân phối tại thời điểm đăng

ký hay khởi tạo một phiên Do đó không có chuyển khóa do các thành viên thay đổi, như vậy không cần thiết một thuật toán quản lý khóa nhóm hiệu quả SA chuyển khóa

có thể không cần thiết cho kiểu quản lý khóa nhóm mà chỉ dựa vào truyền thông điểm- điểm Sự thi hành nghiêm ngặt của điều khiển truy nhập có thể không cần thiết trong một số ứng dụng Chính xác hơn, các thay đổi thành viên có thể được xử lý theo chu kỳ hay trong một đợt, cho dù các trao đổi thành viên xảy ra tại các thời điểm khác nhau

Do đó giải pháp quản lý khóa nhóm phải đưa ra các cấp độ bảo mật có thể lựa chọn/ cấu hình được

1.5.3 Vấn đề chính sách bảo mật Multicast

Các chính sách bảo mật Multicast cung cấp các quy tắc hoạt động đối với hai vấn

đề đã nêu trên: quản lý nguyên liệu tạo khóa và điều khiển dữ liệu Multicast Ta hãy chú ý tới hai loại khác nhau của nhóm, cụ thể là các nhóm tương tác nhỏ và các nhóm lớn với một hay một số bên gửi Trong các nhóm đơn bên gửi, bên gửi hoặc là chủ nội dung hoặc là đại diện của nó Chủ nội dung thường chỉ định ai có thể nhận dữ liệu và số lượng bảo mật cần thiết, và chỉ định một GCKS và một bên gửi GCKS chịu trách nhiệm cho cả việc phân phối và thực thi các chính sách Bên gửi cũng chịu một phần trách nhiệm cho việc thực thi chính sách Các nhóm tương tác đôi khi cũng có người điều hành có thể được xem như là chủ nhóm Chính sách trong các nhóm con có thể được đàm phán, nhưng việc đàm phán không hội tụ trong các nhóm lớn

Các chủ nội dung chỉ định chỉ chính sách cấp độ cao mà sau đó phải được biên dịch vào trong các quy tắc chính xác hơn nữa để các chính sách có thể được thực thi với các cơ chế bảo mật khả dụng Các ngôn ngữ chính sách như Ismene, thẻ chính sách bảo mật nhóm (Group security policy token- GSPT) đã được đề xuất cho các đặc tả rõ ràng của các chính sách nhóm

Các nhóm đưa ra một vài vấn đề chính sách mới được so sánh với truyền thông ngang hàng Trong các nhóm, các đối tượng khác nhau có khả năng và vai trò khác nhau, và chính sách ủy quyền định nghĩa các thành viên, các bên gửi, và GCKS và các đại diện được ủy quyền của nó (ví dụ GCKS phụ và server chuyển khóa) Danh sách điều khiển truy nhập (Access control lists- ACL) là ví dụ về các cơ chế cho việc thực thi điều khiển truy nhập Chính sách cũng ra lệnh các thuật toán nhận thực hay mã hóa

sử dụng cho việc chuyển khóa cũng như bảo mật truyền thông dữ liệu Hơn nữa, chủ nội dung chỉ định GCKS được hay không được chuyển khóa sau khi mỗi thành viên

Đồ án tốt nghiệp đại học Chương1 Multicast và những thách thức

thay đổi, hay xử lý các thao đổi theo chu kỳ Chính sách nhóm cũng nên bao gồm trạng thái thành viên dự kiến khi một thành viên không có GSA mới nhất Các yêu cầu ứng dụng, giá trị của nội dung và đôi khi các cơ chế được hỗ trợ bởi bên gửi và GCKS, tất

cả đều ảnh hưởng đến chính sách nhóm

1.6 Bảo vệ kiến trúc hạ tầng

Ngoại trừ việc bảo vệ nội dung, chúng ta cần quan tâm tới những sự đe dọa tới kiến trúc hạ tầng Multicast Có ba phần trong vấn đề này, tương ứng với điều khiển truy nhập bên gửi, bảo vệ hạ tầng định tuyến Multicast, và điều khiển truy nhập bên nhận.Nhắc lại rằng trong mô hình Multicast cổ điển, một bên gửi có thể truyền dẫn dữ liệu tới bất kỳ nhóm Multicast nào Nó thậm chí không cần phải trở thành một thành viên của nhóm Bởi vậy, kẻ địch có thể đưa dữ liệu vào trong cây Multicast và phá hoại tài nguyên mạng, như là không gian bộ đệm trên các bộ định tuyến và băng thông trên các liên kết Vấn đề này đã được đưa vào trong việc phát triển và triển khai của mô hình SSM và một vài giao thức truyền thống đã được chỉnh sửa để thích ứng với mô hình SSM (ví dụ PIM-SSM)

Tiếp theo, để giao thức định tuyến Unicast hay Multicast vận hành chính xác, tất

cả các gói điều khiển đã trao đổi trong hoạt động của các bộ định tuyến và trong các giao thức phải được bảo vệ một lần nữa khỏi những chỉnh sửa, cả việc xóa bỏ và việc đưa vào các gói điều khiển giả

Tương tự như các giao thức định tuyến Multicast, các giao thức Multicast tin cậy hoạt động bằng sự trao đổi các bản tin điều khiển giữa các đối tượng được bao gồm trong mỗi giao thức Đối với một giao thức Multicast tin cậy, các bản tin điều khiển của

nó phải được bảo vệ khỏi những sự chỉnh sửa trong truyền dẫn

Cuối cùng, nhắc lại rằng bất kỳ máy trạm nào cũng có thể gia nhập một nhóm Multicast và kéo cây phân phối về phía chính nó Kẻ địch có thể lợi dụng tính năng này

và kéo lưu lượng Multicast mà không được sự cho phép Bởi vậy, để bảo vệ kíến trúc

hạ tầng, các bộ định tuyến biên phải chỉ cho phép các thành viên được ủy quyền kéo dữ liệu Multicast

1.7 Kết luận chương 1

Chương 1 đã giới thiệu tổng quan về IPMulticast và những vấn đề liên quan cụ thể đến bảo mật nhóm trong Multicast Có thể tóm tắt các vấn đề đó như sau:

Đồ án tốt nghiệp đại học Chương1 Multicast và những thách thức

Vấn đề điều khiển dữ liệu Multicast Phần này bao trùm các vấn đề liên quan tới các xử lý- bảo mật của dữ liệu Multicast của bên gửi và bên nhận

Vấn đề quản lý nguyên liệu tạo khóa Phần này liên quan tới bảo mật phân phối và làm mới nguyên liệu tạo khóa Việc quản lý các khóa mã hóa thuộc về một nhóm cần các yêu cầu quản lý trạng thái liên kết và các tham số của nhóm đó Một số giải pháp cho các vấn đề đặc thù phải được thêm vào

Vấn đề các chính sách bảo mật Multicast Các chính sách bảo mật Multicast phải cung cấp các tiêu chuẩn cho hoạt động của các thành phần khác của khung tham khảo Trong chính sách bảo mật Multicast, tập trung vào bộ điều khiển chính sách Quản lý chính sách bảo mật Multicast được mở rộng nội dung phát triển theo những hướng sau đây:

Những chương tiếp theo sẽ trình bày cụ thể, đi sâu vào từng vấn đề để có cái nhìn sâu hơn về bảo mật nhóm trong Multicast

Đồ án tốt nghiệp đại học Chương2 Nhận thực dữ liệu Multicast

CHƯƠNG 2 NHẬN THỰC DỮ LIỆU MULTICAST

Chương này trình bày vấn đề bảo mật điều khiển dữ liệu Multicast, đây là một trong ba vấn đề được đưa ra bởi nhóm nghiên cứu SMuG và được thông qua bởi nhóm làm việc IETF MSec Các ứng dụng khác nhau có những yêu cầu bảo mật khác nhau cho bảo mật truyền dẫn dữ liệu Ví dụ, trong một số trường hợp, nhận thực nguồn dữ liệu và bảo vệ tính toàn vẹn có thể ở mức độ thấp trong khi các ứng dụng khác có thể cần tính bảo mật nhiều hơn

Những ứng dụng khác nhau có thể cần các cấp độ khác nhau của nhận thực cho truyền thông nhóm bảo mật Ví dụ, trong một vài ứng dụng có thể là đủ để biết được rằng gói dữ liệu được nguyên gốc trong nhóm bảo mật và không bị sửa đổi trong khi truyền dẫn bởi các đối tượng không phải thành viên Tính chất này được coi như là nhận thực nhóm Trong những ứng dụng khác, các thành viên (hay bên nhận) có thể cần kiểm tra các gói dữ liệu đã được gửi bởi một nguồn đã được ủy quyền Tính chất này được gọi là nhận thực nguồn Cuối cùng, trong một số trường hợp, một bên thứ ba trung gian cũng nên có quyền kiểm tra một cách độc lập nguồn dữ liệu Nói cách khác, một bên gửi không có quyền từ chối rằng mình đã từng gửi dữ liệu

Còn có nhiều thách thức khác trong nhận thực nguồn của dữ liệu Multicast Trong khi có một vài ứng dụng bao gồm truyền dẫn dữ liệu kiểu khối tới một nhóm bên nhận, còn lại đa phần là truyền dữ liệu kiểu luồng Ngoài ra, dữ liệu có thể cần được truyền dẫn trong thời gian thực, cùng với các yêu cầu về không gian bộ đệm tại cả bên nhận và bên gửi Cuối cùng, các gói có thể mất trong quá trình truyền dẫn hay đến không đúng kiểu Do vậy, nhận thực nguồn và không- từ chối của các phiên truyền thông nhóm là vấn đề khó khăn

2.1 Các vấn đề trong nhận thực dữ liệu Multicast

Vấn đề nhận thực dữ liệu Multicast bao gồm ba yếu tố: toàn vẹn dữ liệu (data integrity), nhận thực (authentication), và không- từ chối (non- repudiation)

Bên nhận phải có khả năng xác định dữ liệu đã không bị chỉnh sửa bởi các thành viên khác của nhóm Multicast hay của các kẻ địch bên ngoài Tính chất này được gọi là bảo vệ tính toàn vẹn

Các bên nhận cần phải có khả năng thiết lập nguồn của dữ liệu, ít nhất là cho chính chúng Nói cách khác, ta cần nhận thực gốc dữ liệu

Một phiên bản mạnh hơn của các tính chất trên, được gọi là không- từ chối, cho phép bên thứ ba kiểm tra nguồn dữ liệu

Đồ án tốt nghiệp đại học Chương2 Nhận thực dữ liệu Multicast

Toàn vẹn dữ liệu và nhận thực dữ liệu liên quan chặt chẽ với nhau Chú ý rằng nếu

dữ liệu đã bị chỉnh sửa trong khi truyền dẫn, nguồn không còn còn là điểm bắt đầu của

dữ liệu nữa Tương tự, nếu một bên nhận có thể thiết lập nguồn của dữ liệu (ít nhất là cho chính nó), dữ liệu đã không bị chỉnh sửa trên đường đi Do vậy toàn vẹn dữ liệu và nhận thực dữ liệu là phụ thuộc vào nhau Không- từ chối bản chất là một phiên bản mạnh hơn của nhận thực dữ liệu Nói cách khác, một giao thức hay cơ chế đảm bảo không từ chối thì cũng đảm bảo nhận thực

Có hai loại ứng dụng rõ ràng, với các yêu cầu đa dạng, liên quan tới nhận thực dữ liệu Multicast Đầu tiên, một bên gửi truyền dẫn khối dữ liệu tới các bên nhận Nói cách khác, các bên nhận có thể chờ cho đến khi chúng nhận được tất cả dữ liệu đã gửi, trước khi kiểm tra nhận thực và toàn vẹn của dữ liệu Kiểu thứ hai là các ứng dụng dữ liệu Multicast kiểu luồng Các bên nhận có thể muốn kiểm tra tính toàn vẹn và nhận thực mỗi gói dữ liệu mỗi khi chúng tới đích, và sử dụng nó ngay lập tức Chúng ta cũng cần điều khiển các kênh thông tin tổn thất, cũng như việc phân phối gói không đúng thứ tự Nói cách khác, thông tin nhận thực phải được liên kết với mỗi gói Video theo yêu cầu

và hội thảo đa phương tiện là ví dụ về các ứng dụng cần Multicast kiểu luồng

Hai cơ chế khác nhau thường được sử dụng cho nhận thực nguồn Đầu tiên là sử dụng chữ ký số cho không- từ chối, và thứ hai là sử dụng MAC chỉ cho việc nhận thực Phải nhắc lại rằng không- từ chối là dạng mạnh hơn của nhận thực Tuy nhiên, trong khi MAC không thể cung cấp không- từ chối thì chúng lại hiệu quả hơn khi so sánh với chữ ký số Đăng ký số mỗi gói của luồng dữ liệu đắt đỏ ghê gớm (cả việc tính toán cùng với việc đảm bảo thông tin tiêu đề cho mỗi gói)

Trong truyền thông Unicast, MAC hỗ trợ nhận thực dữ liệu như sau: Trong thông tin ngang hàng, Alice và Bob cùng giữ một khóa bí mật để nhận thực Alice sử dụng

khóa và hàm một chiều để tính hàm băm khóa của bản tin và gửi bản tin cùng với MAC

tới bên nhận Bob lặp lại thủ tục để tính MAC, và so sánh nó với MAC nhận được Nếu các MAC tương ứng, Bob biết được rằng bản tin đã không bị chỉnh sửa trên đường đi Anh ấy cũng biết được rằng anh ấy không gửi bản tin và do vậy Alice phải gửi nó, giả thiết rằng khóa nhận thực không bị tổn hại Tuy nhiên, một bên thứ ba không thể kiểm tra bản tin đã được gửi bởi Alice hay Bob Do vậy, MAC không thể cung cấp không- từ chối

Chúng ta có thể sử dụng MAC cho các phiên truyền thông nhóm nhận thực bằng những thủ tục tương tự như ở trên, nhưng với cấp độ giảm hơn về bảo mật Chú ý tới nhóm, bao gồm Alice, Bob và Cindy, giữ một khóa nhận thực Alice có thể sử dụng một MAC để nhận thực bản tin gửi tới Bob và Cindy Bob (hay Cindy) không biết bản

Đồ án tốt nghiệp đại học Chương2 Nhận thực dữ liệu Multicast

tin đã được gửi hay chỉnh sửa lần cuối bởi Alice hay Cindy (hay Bob) Thông thường, các thành viên nhóm có thể chỉ kiểm tra được các đối tượng không phải thành viên, người mà không giữ khóa nhận thực nhóm thì không thay đổi được dữ liệu trong khi truyền dẫn Tính chất này đảm bảo chỉ bản tin được gửi hay sửa đổi bởi một thành viên

của nhóm và được gọi là nhận thực nhóm.

Ngược lại, nếu một thành viên có thể xác định được bên gửi dữ liệu hợp lệ, chúng

ta gọi tính chất này là nhận thực nguồn Với nhận thực nguồn, một thành viên có thể

kiểm tra nguồn dữ liệu và biết được rằng dữ liệu không bị sửa đổi trên đường đi Các giải pháp cho nhận thực nguồn thông thường là đắt và phức tạp, và thường phụ thuộc vào ứng dụng

2.1.1 Cung cấp nhận thực nhóm

Nhận thực nhóm của một bản tin có nghĩa là bản tin còn nguyên gốc trong nhóm,

và không bị sửa đổi bởi các đối tượng bên ngoài nhóm MAC được sử dụng cho nhận thực nhóm, và do vậy nó rẻ hơn so với nhận thực luồng dữ liệu trong thời gian thực Nhận thực nhóm có một vài ứng dụng quan trọng Ví dụ, bảo mật truyền thông giữa các đối tượng tin tưởng lẫn nhau, qua Internet công cộng Nhận thực nhóm là đủ trong trường hợp này, do các thành viên giữ các khóa nhóm được giả thiết là không quan tâm đến việc chỉnh sửa dữ liệu được gửi bởi các thành viên khác Nhận thực nhóm chỉ thỏa mãn mục đích hạn chế tuy nhiên nó không đủ cho đa số các ứng dụng

Các thành viên của nhóm cần một khóa chung cho nhận thực nhóm (cho việc tính toán MAC) Do vậy, ta cần có khả năng thiết lập và cập nhật các khóa nhận thực trong phạm vi bảo mật các thành viên Các giao thức và thuật toán phân phối khóa nhóm cung cấp các cách thức thiết lập một khóa chung cho các thành viên của nhóm sẽ được nói ở các phần sau Cùng với các khóa mã hóa, một quản lý nhóm cũng có thể phân phối các khóa nhận thực Giao thức đăng ký được sử dụng để gửi các khởi tạo khóa, và giao thức chuyển khóa được sử dụng để gửi các bản tin cập nhật khóa Bên gửi có thể

sử dụng các khóa này trong giao thức bảo mật dữ liệu (ESP, MESP) cho truyền thông nhóm nhận thực

2.1.2 Cung cấp nhận thực nguồn

Các yêu cầu ứng dụng ảnh hưởng lớn tới giải pháp cho nhận thực nguồn Đầu tiên, một ứng dụng có thể yêu cầu không- từ chối hay chỉ cần nhận thực nguồn Tiếp đến, truyền dẫn dữ liệu có thể tin cậy hoặc tổn thất Bên gửi hay bên nhận có thể có giới hạn không gian bộ đệm Hơn nữa, các bên nhận có thể công suất tính toán giới hạn (các thiết bị cầm tay) và trong một vài trường hợp, khả năng tính toán của các bên nhận có

Đồ án tốt nghiệp đại học Chương2 Nhận thực dữ liệu Multicast

thể không đồng nhất Các bên nhận có thể ở những khoảng cách khác nhau so với bên gửi Cuối cùng, ứng dụng có thể bao gồm truyền tải dữ liệu khối hoặc luồng Trong phần dưới đây, ta trình bày về các yêu cầu nhận thực nguồn của một vài loại ứng dụng khác nhau

Truyền dẫn dữ liệu kiểu khối tin cậy Ta giả thiết rằng truyền dẫn dữ liệu tin cậy

và bên gửi đã có sẵn dữ liệu khả dụng Các bên nhận chỉ có thể sử dụng dữ liệu sau khi tất cả chúng được nhận Không gian bộ đệm không phải là mối quan tâm tại bên gửi

hay tại các bên nhận Các luồng kiểu này được coi như các luồng kiểu tất cả hay không

gì cả

Một giải pháp đơn giản có thể dùng cho bên gửi, đó là tính toán giá trị hàm băm của dữ liệu và đánh dấu nó Chú ý rằng, đối phương có thể làm gián đoạn quá trình nhận thực này bằng cách thay đổi chỉ một bit đơn trong luồng Các bên nhận không thể phát hiện kiểu tấn công này cho đến khi tất cả dữ liệu nhận được Hơn nữa, chúng không thể xác định đoạn dữ liệu đã bị thay đổi Do vậy, chúng phải yêu cầu truyền lại toàn bộ luồng

Luồng tin cậy của dữ liệu dự trữ Đối với kiểu truyền dẫn tin cậy của dữ liệu mà

bên gửi biết trước Bên gửi cần một bộ đệm lớn để lưu trữ dữ liệu do nó biết trước dữ liệu Các bên nhận được kỳ vọng sẽ nhận thực và sử dụng các gói dữ liệu đúng như là chúng nhận được Do vậy, yêu cầu bộ đệm ở bên nhận là khá khiêm tốn

Luồng tổn thất của dữ liệu lưu trữ Điều này tương tự như mục trên, ngoại trừ các

gói có thể bị mất khi truyền dẫn Đối với các gói tổn thất, các bên nhận nên có khả năng kiểm tra tính nhận thực của các phần dữ liệu đã nhận được Video theo yêu cầu là một ứng dụng kiểu này Kiểu ứng dụng này có thể cho phép một lượng trễ cố định

Luồng thời gian thực với tổn thất gói Các ứng dụng thời gian thực yêu cầu bên

gửi truyền dữ liệu càng sớm càng tốt Do vậy, bên gửi cần áp dụng biến đổi nhận thực trong thời gian thực Đối với truyền tải tổn thất, mỗi tính nhận thực của một gói phải có khả năng kiểm tra độc lập Hội thảo đa phương tiện là một ứng dụng yêu cầu luồng thời gian thực tồn tại tổn thất dữ liệu

2.2 Chữ ký số cho nhận thực nguồn

Nhận thực nguồn có thể thực hiện được bằng cách sử dụng chữ ký số Bên gửi chia nhỏ dữ liệu thành từng khối Với mỗi khối, nó tính toán một giá trị hàm băm , đánh dấu hàm băm và gửi chữ ký đi với khối dữ liệu Khi kích thước mỗi khối tăng, bên gửi

sử dụng ít chữ ký số hơn và các thành viên sử dụng kiểm tra chữ ký ít hơn Tuy nhiên, một thành viên cần nhận một khối dữ liệu đầy đủ trước khi kiểm tra tính nhận thực của

Đồ án tốt nghiệp đại học Chương2 Nhận thực dữ liệu Multicast

nó Đối với các khối kích thước nhỏ hơn, số lượng chữ ký và kiểm tra tăng lên Nhưng

ưu điểm là các thành viên không cần đợi lâu trước khi kiểm tra và sử dụng một khối dữ liệu

Chú ý rằng thủ tục này có một vài đặc điểm có lợi Mỗi khối được nhận thực riêng

rẽ và do vậy được kiểm tra độc lập Hơn nữa, kỹ thuật này cung cấp không- từ chối Đánh dấu và kiểm tra mỗi khối đòi hỏi sự tính toán đắt đỏ Hơn nữa, mỗi khối cần phải mang chữ ký của chính nó, dẫn đến kết quả dư thừa thông tin tiêu đề Nhận thực các gói độc lập làm cho đánh dấu mỗi gói trở nên hấp dẫn Tuy nhiên, trong thực tế, đánh dấu mỗi gói trong luồng thời gian thực tốc độ cao là không khả thi Sử dụng các chữ ký một lần có chút ít hiệu quả hơn so với đánh dấu mỗi gói Nhưng chữ ký một lần yêu cầu số lượng lớn tính toán hàm băm và không thể điều khiển tổn thất gói

Chữ ký khối và nhận thực gói riêng biệt

Đối với các luồng nhạy cảm trễ, đánh dấu mỗi gói quá là đắt đỏ Tuy nhiên chúng

ta vẫn cần một cơ chế nhận thực để bên nhận có thể kiểm tra các gói khi chúng đến Nói cách khác, mỗi gói phải được kiểm tra độc lập Một cặp kỹ thuật được gọi là hàm băm kiểu sao và hàm băm kiểu cây Các kỹ thuật này làm giảm giá chữ ký trong mỗi khối của các gói, chúng yêu cầu bộ đệm bên gửi giữ khối của các gói Do vậy, hàm băm kiểu sao và hàm băm kiểu cây đôi khi còn được gọi là hàm băm kiểu khối

Hàm băm kiểu sao

Bên gửi chia một khối dữ liệu thành m gói Nó đánh dấu một hàm băm của khối (block hash), và rồi làm giảm giá của chữ ký thông qua m gói Để nhận thực từng gói riêng rẽ, nó tính toán các hàm băm h 1 , h 2 ,…,h m của m gói Hàm băm khối, h, là hàm trong đó, h i = hash(P i ), P i là gói thứ i Với mỗi gói, bên gửi bao gồm hàm băm khối và

các hàm băm của tất cả các gói trong khối Nó cũng gửi vị trí tương đối của gói trong khối

Hình 2.1 minh họa kỹ thuật hàm băm kiểu sao Các nhánh là các hàm băm của các gói, và gốc là hàm băm khối Trong hình cũng mô tả mối quan hệ giữa các hàm băm của các gói và hàm băm khối; đó là: hàm băm khối phụ thuộc vào tất cả các hàm băm nhánh

h = hash(h 1 , h 2 ,…,h m )

Đồ án tốt nghiệp đại học Chương2 Nhận thực dữ liệu Multicast

Hình 2.1 hàm băm kiểu sao

Trong lúc tiếp nhận gói P i , bên nhận tính toán hàm băm của nó, gọi là h’ i Nó lặp lại thủ tục tính toán hàm băm như bên gửi Nếu hàm băm khối đã đánh dấu trùng với

hàm băm khối đã tính toán, bên nhận biết được rằng P i đã được nhận thực Hơn nữa,

nó cũng biết được rằng những hàm băm còn lại cũng được nhận thực, nếu không thì việc so sánh hàm băm khối đã thất bại Đối với các gói khác trong cùng một khối, bên nhận chỉ cần kiểm tra hàm băm của gói đã được tính xem có bằng với hàm băm nhận được hay không Nói cách khác, chỉ có một hoạt động kiểm tra chữ ký đơn lẻ cho mỗi khối tại các bên nhận

Bên nhận sử dụng một hoạt động kiểm tra chữ ký và hai lần tính toán hàm băm để kiểm tra tính nhận thực của gói đầu tiên nhận được của một khối Đối với những gói khác của block đó, một tính toán hàm băm đơn lẻ và so sánh là đủ Cũng phải nhắc lại

rằng mỗi gói cần mang các hàm băm của toàn bộ các gói (m) trong một khối, cũng như

là một chữ ký số Một hàm băm thường có độ dài 20 bytes ( sử dụng SHA-1), trong khi

đó một chữ ký số thường có kích cỡ 128 bytes

Hàm băm kiểu cây

Hàm băm kiểu cây sử dụng một cơ chế tính toán hàm băm khối khác so với hàm băm kiểu sao Trong khi cơ chế tính toán hàm băm tự nó đã phức tạp hơn và không hiệu quả, điều này làm giảm thông tin tiêu đề liên kết với hàm băm

Bên gửi chia khối dữ liệu thành m gói và tính toán các hàm băm của từng gói riêng rẽ Đối với việc tính toán hàm băm khối, nó liên kết mỗi hàm băm gói riêng rẽ với nút nhánh của cây hàm băm Mỗi hàm băm của nút nội bộ là hàm băm được ghép

từ các hàm băm con, do vậy h 12 = hash (h 1 , h 2) Bằng việc sử dụng hàm này, bên gửi tính toán đệ quy ra được hàm băm của gốc Với mỗi gói, bên gửi bao gồm hàm băm

h

Đồ án tốt nghiệp đại học Chương2 Nhận thực dữ liệu Multicast

khối đã đánh dấu, packet ID, và các hàm băm anh em của tất cả các nút trong đường dẫn của gói hiện thời đến gốc

Các bên nhận theo thủ tục tương tự hàm băm kiểu sao để kiểm tra tính nhận thực của mỗi gói Đầu tiên, bên nhận tính toán hàm băm của gói đã nhận Nó sử dụng hàm băm đã tính toán và các hàm băm đã nhận để tính hàm băm gốc Nếu hàm băm gốc

đã tính toán trùng với hàm băm khối đã đánh dấu, gói bên nhận được nhận thực

Chúng ta sử dụng hình dưới đây để mô tả quá trình tính toán tại bên nhận Giả sử

P 2 là gói đến đầu tiên Bên nhận tính toán h’2 cho gói đã nhận Với P 2, bên gửi bao gồm

các hàm băm anh em của tất cả các nút trên đường dẫn của P 2 tới gốc Trong ví dụ này,

nó bao gồm các hàm băm h1, h34 và h58 Bên nhận tính toán h’12= hash (h1, h’2), h’14= hash (h’12, h34), và h’18= hash (h’14, h58) Nếu h’18 và hàm băm khối đã đánh dấu là h18 tương đồng, P 2 đã được nhận thực Hơn nữa, các hàm băm nhận được và các hàm băm

đã tính toán là h1, h34, h58, h 2 , h12, h14 cũng được nhận thực Bên nhận nhớ đệm các nút

đã kiểm tra của cây hàm băm để kiểm tra hiệu quả hơn các gói khác trong cùng một khối

Hình 2.2 Hàm băm kiểu cây

Hình 2.2 cũng mô tả ưu điểm của việc nhớ đệm kiểm tra các nút hàm băm Ví dụ,

nếu lần tiếp theo nhận được P 4 , bên nhận chỉ cần tính h’ 34 và so sánh với h 34 đã được

kiểm tra từ trước Nếu chúng đồng nhất thì coi như P 4 đã được nhận thực

Kiểm tra nhận thực của gói nhận được đầu tiên của một khối bao gồm hoạt động kiểm tra chữ ký số và tính toán tất cả các hàm băm trong đường dẫn từ vị trí gói hiện

tại trong cây tới gốc Tổng cộng, bên nhận cần tính logm hàm băm Việc kiểm tra các

Đồ án tốt nghiệp đại học Chương2 Nhận thực dữ liệu Multicast

gói tiếp theo đó yêu cầu tính toán hàm băm ít hơn và không cần hoạt động kiểm tra chữ

ký số

Chữ ký khối được sử dụng bởihàm băm kiểu sao và hàm băm kiểu cây có một số nhược điểm Bên gửi muốn có trước một khối dữ liệu khả dụng để tính các hàm băm

và chữ ký số Do vậy, cơ chế này gây trễ trong truyền dẫn luồng Hơn nữa, bên gửi cần

có bộ đệm để lưu trữ khối dữ liệu, nếu m lớn, ta cần một bộ đệm lớn tại bên gửi, cơ chế

này còn làm gia tăng độ dài tiêu đề gói tin Cuối cùng, bên gửi có thể truyền cả một khối các gói cùng lúc sau khi nhận thực, điều này có thể dẫn đến sự bùng nổ băng thông

dễ dẫn đến mất gói

Tuy nhiên, số lượng chữ ký số trên mỗi luồng giảm khi tăng m Thêm nữa là bộ

đệm bên nhận không phải là bắt buộc Các bên nhận có thể kiểm tra mỗi gói khi mà chúng nhận được Hàm băm khối cũng hỗ trợ không- từ chối do hàm băm được đánh dấu bởi bên nhận

2.3 Chuỗi hàm băm cho nhận thực dữ liệu kiểu luồng

Chuỗi là giải pháp chung cho việc giảm giá chữ ký số đối với nhận thực dữ liệu kiểu luồng Đối với truyền dẫn tin cậy của dữ liệu kiểu luồng, ta giả thiết rằng bên gửi

đã có sẵn luồng dữ liệu khả dụng

Chuỗi hàm băm làm việc như sau: Đầu tiên, bên gửi chia dữ liệu thành n khối

Tiếp theo, nó tính hàm băm (sử dụng MD5 hoặc SHA-1) của khối đầu tiên, đánh dấu tải tin hàm băm , và gửi chữ ký tới các bên nhận Sau đó nó gửi mỗi khối đã được gắn thêm hàm băm của khối ngay sau nó trừ khối cuối cùng không có hàm băm Hình 2.3

mô tả chuỗi hàm băm Dữ liệu được chia vào n khối từ B1 tới Bn Trong hình vẽ, hàm

băm B1 của khối đầu tiên được đánh dấu Khối đầu tiên bao gồm hàm băm của B2 cùng với dữ liệu B1 Điều này tiếp tục cho tới khối Bn-1 chứa hàm băm của Bn Khối cuối cùng không chứa hàm băm

Hình 2.3 Chuỗi hàm băm

Mỗi thành viên kiểm tra chữ ký bên gửi, tách hàm băm của khối chữ ký số, và lưu trữ hàm băm Khi khối đầu tiên tới, bên nhận tính toán hàm băm và so sánh với hàm băm đã lưu trữ Nếu các hàm băm đồng nhất, tính toàn vẹn và nhận thực của khối thứ nhất được thiết lập Tiếp tục tách hàm băm của khối thứ hai và lưu trữ chúng Nó lặp

hash B1 hash B2 Dữ liệu hash B3 Dữ liệu Dữ liệu

Đồ án tốt nghiệp đại học Chương2 Nhận thực dữ liệu Multicast

lại thủ tục kiểm tra cho đến khối cuối cùng Nếu các gói nhận được đúng thứ tự, các bên nhận chỉ cần bộ đệm để lưu trữ một khối và một hàm băm

Chú ý rằng do chuỗi nhận thực kết thúc trong một gói chữ ký, chuỗi hàm băm cung cấp không- từ chối Bất kỳ bên thứ ba nào có thể lặp lại thủ tục kiểm tra tính độc lập và xác định nguồn dữ liệu

Chuỗi hàm băm hết sức hiệu quả, chỉ có một khóa công khai duy nhất hoạt động tại bên gửi (chữ ký) và tại mỗi thành viên (kiểm tra) Thêm nữa, tính toán hàm băm thường nhanh hơn 1000 lần so với tính khóa công khai Thông tin tiêu đề cũng nhỏ

Tổng cộng, cơ chế này tăng thêm một chữ ký (128 bytes) và n hàm băm (n * 20 bytes

với SHA-1) đối với tiêu đề trong nhận thực toàn bộ luồng dữ liệu

Thật không may là chuỗi hàm băm có một vài giới hạn trong thực tế sử dụng Đầu tiên, nó chỉ làm việc khi bên gửi có trước toàn bộ luồng dữ liệu khả dụng Quan trọng hơn là nhận thực chỉ có thể hoàn thành khi gửi các khối theo thứ tự một cách chính xác Kiểu hàm băm chuỗi này không cho phép tổn thất gói Các bên nhận không thể nhận thực bất kỳ gói tiếp theo nào khi một đoạn bất kỳ của khối bị mất khi truyền dẫn.Việc nhận các khối không đúng thứ tự cũng là một rắc rối Một khối không đúng thứ tự phải được giữ lại ở bộ đệm cho đến khi tất cả các khối đứng trước nó được nhận và kiểm tra

Giản đồ biểu diễn chuỗi hàm băm

Chuỗi hàm băm sẽ được hiểu tốt hơn với một giản đồ biểu diễn nhận thực Mỗi gói chứa thông tin nhận thực biểu diễn bằng một nút trên giản đồ Như vậy một gói chứa hàm băm hay chữ ký số là một nút trên giản đồ Một cạnh gắn trực tiếp biểu diễn

mối quan hệ nhận thực giữa hai gói Nếu gói P i chứa hàm băm của gói P j, sẽ có một

cạnh nối trực tiếp từ P i tới P j Tương tự, có một cạnh trực tiếp từ gói dữ liệu P i tới gói

chữ ký nhận thực trực tiếp cho P i Cuối cùng, để nhận thực nguồn cho gói P j phải có

một đường dẫn từ P j tới gói chữ ký

Hình 2.4 Giản đồ chuỗi hàm băm

Hình 2.4 mô tả một chuỗi hàm băm được biểu diễn như một giản đồ trực tiếp Quan trọng nhất là chỉ có một đường dẫn từ bất kỳ nút nào tới gốc Cũng chú ý rằng

hash B1 hash B2 Dữ liệu hash B3 Dữ liệu Dữ liệu Gói chữ ký

Đồ án tốt nghiệp đại học Chương2 Nhận thực dữ liệu Multicast

nếu một gói bị mất khi truyền dẫn, nút tương ứng trên giản đồ sẽ bị xóa Do vậy không thể có đường dẫn nào từ bất kỳ các gói tiếp theo gói bị mất tới gói chữ ký

Chuỗi hàm băm đơn giản này có hai hạn chế cần thiết được bổ xung Đầu tiên, bên gửi cần phải biết trước toàn bộ luồng dữ liệu Thứ hai là kiểu nhận thực này không cho phép tổn thất gói Cần phải nhắc lại rằng chúng ta đều muốn hỗ trợ nhiều hơn các ứng dụng cần nhận thực trong thời gian thực và trong điều kiện có tổn thất gói

Chú ý rằng chuỗi hàm băm đã được giải thích ở trên sử dụng chuỗi chuyển ngược

Nghĩa là P i chứa thông tin nhận thực của P j, mà i<j Trong dạng đơn giản nhất của

chuỗi ta có j= i + 1 Chuỗi chuyển ngược yêu cầu tất cả luồng phải khả dụng trước khi

truyền dẫn, nhưng có ưu điểm là nhận thực ngay lập tức tại bên nhận (giả thiết rằng phân phối đúng thứ tự gói) Chuỗi chuyển tiếp là dạng đối lập với chuỗi chuyển ngược trong đó gói chữ ký theo sau các gói dữ liệu Do vậy bên gửi có thể bắt đầu gửi dữ liệu thời gian thực trong khi đó bên nhận không thể nhận thực dữ liệu cho đến khi nhận được gói chữ ký, chuỗi chuyển tiếp sẽ dẫn đến trễ nhận thực

Chìa khóa cho việc chấp nhận tổn thất gói là gửi hàm băm của gói trên nhiều gói,

và đưa nhiều hàm băm (của các gói khác nhau) vào trong các gói chữ ký Truyền dẫn tin cậy của các gói chữ ký là điều cốt yếu trong kiểu này Chú ý rằng trong việc hỗ trợ chấp nhận tổn thất, tiêu đề các gói tăng lên Ngoài ra, cùng với số lượng các gói chữ ký tăng lên, giá thành đánh dấu và kiểm tra tại bên gửi và bên nhận cũng tăng lên tương ứng

2.4 Nhận thực nguồn dựa trên MAC của các luồng không tin cậy

Chuỗi khóa một- chiều cho nhận thực dựa trên MAC được sử dụng cho việc gửi các bản tin cập nhật định tuyến trạng thái liên kết đã được nhận thực Bên gửi tạo một

chuỗi hàm băm có độ dài l, sử dụng số bí mật ngẫu nhiên r và hàm một chiều h Thành phần của chuỗi hàm băm h(r), h 2 (r)…, h l (r), trong đó h 2 (r)= h(h(r)) được sử dụng trong

đảo ngược thứ tự các khóa MAC để nhận thực các bản tin cập nhật trạng thái liên kết Các bộ định tuyến được coi như gần đồng bộ, và các khóa MAC được bên gửi để lộ sau một thời gian trễ biết trước Trong phần này sẽ mô tả giao thức sử dụng các kỹ thuật này và các kỹ thuật khác để nhận thực hiệu quả các luồng thời gian thực có tổn thất.Giao thức nhận thực cho phép- tổn thất luồng hiệu quả về mặt thời gian ( The timed efficient stream loss tolerant authentication- TESLA) cung cấp hỗ trợ đầy đủ cho nhận thực nguồn của luồng Multicast sử dụng các MAC Phải nhắc lại rằng MAC được dựa trên khóa đối xứng, và tất cả thành viên của nhóm phải biết khóa để nhận thực Tuy nhiên, như đã nói ở phần 2.1, các khóa đối xứng chỉ hỗ trợ nhận thực nhóm TESLA

Đồ án tốt nghiệp đại học Chương2 Nhận thực dữ liệu Multicast

tránh hạn chế này bằng cách xác nhận khóa MAC đầu tiên, và để lộ nó sau trễ quảng bá trước Tiếp đến, ta giới thiệu một số thuật ngữ và khái niệm giúp mô tả TESLA

Khoảng thời gian Mỗi gói P i được nhận thực riêng rẽ, với một MAC Thời gian

được chia thành t khoảng trong mỗi T int Bên gửi có thể không truyền gói hoặc truyền

nhiều gói trong mỗi khoảng I j , 1 ≤ j ≤ t Sự mềm dẻo này làm cho có thể gửi bất kỳ số

lượng gói nào trong một khoảng thời gian cho phép bên gửi tương thích với tốc độ

truyền dẫn thay đổi của các ứng dụng Tương ứng với mỗi khoảng I j, có một khóa nhận

thực k’ j Nói cách khác, tất cả các gói gửi trong khoảng thời gian I j đều được nhận thực

với khóa MAC k’ j

Khóa MAC Bên gửi tạo ra một chuỗi khóa, k 1 , k 2 ,…k t, sử dụng một hàm một chiều

f Để làm như vậy, đầu tiên nó tạo ngẫu nhiên khóa cuối cùng k t của chuỗi và sử dụng

phương trình k j-1 = f(k j ), tạo ra những khóa còn lại Chú ý rằng trong định nghĩa hàm

một chiều, từ k j-1 cho trước, không thể tính được k j Bên gửi tạo các khóa MAC k’ j =

g(k j ), 1 ≤ j ≤ t, trong đó g là hàm một chiều khác Hình 2.5 mô tả chuỗi khóa và dẫn

xuất khóa MAC trong TESLA

Hình 2.5 Chuỗi khóa và dẫn xuất khóa MAC

Với một khóa cho trước, k a trong chuỗi, bên nhận có thể tính tất cả các khóa k i , i <

a, bằng cách áp dụng lặp lại hàm một chiều f Do vậy, cho dù một số khóa bị mất trong

khi truyền dẫn, bên nhận có thể tính chúng khi nó nhận được một khóa sau đó trong chuỗi Nói cách khác, giao thức này cho phép tổn thất gói

Xác nhận chuỗi khóa Bên gửi có thể xác nhận một chuỗi khóa bằng cách đánh

dấu một gói chứa khóa từ chuỗi hoặc chứa khóa trong gói đã nhận thực Xác nhận ở đây

k’

k

Đồ án tốt nghiệp đại học Chương2 Nhận thực dữ liệu Multicast

chính là xác định chuỗi khóa với khóa chứa trong đó Ví dụ, để xác nhận chuỗi khóa k 1 ,

k 2 ,…k t , bên nhận sẽ truyền gói đã nhận thực chứa k 0 = f(k 1 ).

Đồng bộ thời gian tổn thất giữa bên gửi và các bên nhận Các bên nhận cần được

đồng bộ thời gian tổn thất với bên gửi, có nghĩa là chúng cần biết giới hạn lớn hơn của thời gian bên gửi Vì vậy nếu thời gian khác nhau giữa bên gửi và bên nhận là δt, ta giả thiết rằng bên nhận biết ∆t mà ∆t≥δt

Trễ để lộ Trễ để lộ chỉ ra khoảng thời gian mà bên nhận cần phải đợi trước khi có

khả năng nhận thực một gói trong khoảng thời gian I j Trễ để lộ kéo theo các yêu cầu

không gian bộ đệm bên nhận, như là trễ nhận thực Trễ để lộ ngắn có thể dẫn tới bên nhận không có khả năng nhận thực thành công nhiều gói Các nhà thiết kế TESLA đề

xuất trễ để lộ bằng [RTT/T int] + 1, RTT là giới hạn trên của thời gian quay vòng giữa bên gửi và bên nhận

2.4.1 Quá trình khởi tạo TESLA

Để khởi tạo bên nhận, bên gửi truyền gói được đánh dấu số bao gồm: thông tin về các khoảng thời gian, thông tin đồng bộ thời gian, xác nhận bắt đầu chuỗi khóa tại khoảng thời gian hiện tại và trễ để lộ Việc đăng ký ở bên nhận cho việc bảo mật nhóm

có thể bắt đầu tại thời điểm bắt đầu truyền dẫn hoặc giữa phiên Đối với việc các bên nhận gia nhập giữa phiên, bên nhận có thể phải gửi thông tin khởi động qua Unicast.Quản lý nhóm có thể khởi tạo TESLA trong giao thức đăng ký được định nghĩa bởi kiến trúc quản lý khóa nhóm Phải nhắc lại rằng một trong những mục đích của đăng ký là khởi tạo liên kết bảo mật dữ liệu SA, trong đó nhận thực nguồn là một thành phần Các máy trạm là thành viên của nhóm khi bắt đầu cũng có thể được khởi tạo qua Unicast Khởi tạo nhóm hiệu quả hơn, do bên gửi chỉ cần đánh dấu một gói và có thể gửi chúng qua Multicast Tuy nhiên, vấn đề ở đây lại là phân phối Multicast tin cậy.Thông thường, gói khởi tạo chữ ký từ bên gửi bao gồm:

Chỉ số khoảng cách hiện tại j;

Thời điểm bắt đầu T j của khoảng I j;

Khoảng thời gian T int;

Xác nhận bắt đầu chuỗi khóa tại k i , i<j – d (nếu j < d thì i = 0);

Trễ để lộ khóa d (trong nhiều khoảng thời gian).

Các bên nhận sử dụng thông tin trên trong việc xác định tính nhận thực của các gói

đã nhận Nhắc lại rằng TESLA tránh các giới hạn của nhận thực dựa trên MAC đối với