Nghiên cứu vấn đề quản lý và phân phối khóa nhóm trong việc đảm bảo an toàn dữ liệu Multicast

Với dữ liệu mật người gửi cần mã hóa dữ liệu với khóa mật và khóa mật này sẽ được các thành viên của nhóm hiểu được: giả sử rằng host nào đó xác thực được và nhận dữ liệu Multicast.. Để

MỤC LỤC

MỤC LỤC ERROR! BOOKMARK NOT DEFINED.

DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ 6

DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT 7

MỞ ĐẦU 8

CHƯƠNG 1: MỞ ĐẦU 9

1.1 Về an toàn dữ liệu trong truyền Multicast 9

1.2 Sự cần thiết Multicast an toàn 10

1.3 Xử lý dữ liệu Multicast an toàn 13

1.3.1 Kết nối dữ liệu Multicast an toàn 13

1.3.2 Quản lý khóa 15

1.3.3 Các chính sách an toàn Multicast: 19

1.4 Bảo vệ hạ tầng 20

1.5 Ứng dụng của Multicast an toàn 21

CHƯƠNG 2: QUẢN LÝ KHÓA NHÓM 23

2.1 Mô hình quản lý khóa nhóm: 24

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

2.2.1 Yêu cầu an toàn cho quản lý khóa unicast .26

2.3 Các yêu cầu an toàn trong quản lý khóa nhóm 29

2.4 Quản lý kiến trúc an toàn nhóm (Group Security Architecture -GSA) 32

2.4.1 Mô hình GSA 33

2.4.2 Định nghĩa GSA 35

2.5 Phân lớp bài toán quản lý khóa nhóm 36

2.6 Tóm lại 37

CHƯƠNG 3: CÁC THUẬT TOÁN QUẢN LÝ KHÓA NHÓM 39

3.1 Đợt và chu kỳ thay khóa 41

3.1.1 Sự kết hợp hài hoà trong đợt thay khóa (Trade-offs in batch rekeying) 42

3.2 MARKS (Multicast Key Management Using Arbitrarily Revealed Key Sequences) 44

3.3 LKH (Logical Key Hierarchy) 46

3.3.1 Khởi tạo LKH: 47

3.3.2 Thêm thành viên tham gia cây khóa .48

3.3.3 Thay khóa khi có thành viên mới tham gia nhóm trong LKH 49

3.3.4 Thay khóa hiệu quả sử dụng LKH+ 50

3.3.5 Thay khóa khi có thành viên rời khỏi nhóm trong LKH 51

3.3.6 Thay khoá hiệu quả khi có thành viên rời nhóm OFCs: 52

3.4 OFT(One-way Function Tree) 54

3.4.1 Khởi tạo một OFT 55

3.4.2 Thay khoá khi có thành viên mới tham gia trong OFT 56

3.4.3 Thay khoá khi có thành viên rời nhóm trong OFT 58

3.5 Xử lý theo đợt của các hội viên thay đổi trong cây khóa 59

3.6 Truyền thông điệp thay khóa tin cậy 60

3.6.1 Lặp việc truyền lại các thông điệp thay khóa .60

3.6.2 FEC (Forward error correction) cho độ tin cậy 60

3.6.3 Tính hiệu lực của khóa trong việc truyền vận thông điệp .61

3.7 Giải thuật huỷ khóa không mang quốc tịch 62

3.7.1 Huỷ thành viên áp dụng STR 62

3.7.2 SDR(Subset Difference Revocation Algorithm) giải phóng thành viên 64

3.8 Tổng kết 67

CHƯƠNG 4: ỨNG DỤNG 70

4.1 Mục đích ứng dụng 70

4.2 Mô hình ứng dụng Multicast an toàn trong ứng dụng Chat theo nhóm 71

4.3 Sơ đồ trạng thái sử dụng giao thức GSAKMP áp dụng cho ứng dụng Chat theo nhóm: 72

4.4 Áp dụng thuật toán LKH trong ứng dụng Chat theo nhóm 73

4.5 Yêu cầu kết hợp giữa LKH và GSAKMP 75

4.6.Ví dụ định dạng thẻ bài trong giải thuật LKH 75

4.6.1 Ví dụ về download khóa LKH 76

4.6.2 Ví dụ sự kiện thay khoá LKH 77

4.7.Thiết lập các chính sách cho ứng dụng: 80

4.8 Đặc trưng ứng dụng quản lý khóa áp dụng cho ứng dụng Chating .81

4.9 Thiết lập thẻ bài cho chính sách khóa nhóm 82

4.10 Định nghĩa các thuộc tính 82

4.10.1 Định nghĩa thuộc tính ID cho thẻ bài 82

4.10.2 Định nghĩa các thuộc tính xác thực 83

4.10.3 Định nghĩa các thuộc tính điều khiển 83

4.10.4 Định nghĩa các thuộc tính tự động 84

4.10.5 Định nghĩa các trường khối chữ ký 85

4.11 Kiến trúc thiết lập nhóm và quản lý khóa nhóm 85

4.12 Thông điệp thiết lập quản lý khóa 86

4.13 Thực hiện thay khóa trong quản lý khóa nhóm 86

4.14 Yêu cầu ra nhập thành viên 86

4.15 Mời tham gia thành viên 87

4.16 Trả lời mời tham gia nhóm 87

4.17 Download khóa thông qua SA 87

4.18 Xác nhận khóa 88

4.19 Thay khóa 88

4.20 Một số màn hình chương trình Chat demo .88

4.20.1 Màn hình chung (cho hai kiểu user) 88

4.20.2 Điều tiết phiên làm việc 90

4.20.3 Phiên của người tham gia Chat 93

4.20.4 Màn hình Chat 93

KẾT LUẬN 95

TÀI LIỆU THAM KHẢO 97

DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ

Hình 2.1: Mô hình quản lý khóa nhóm 24

Hình 2.2: Unicast SA được định nghĩa trong ISAKMP 28

Hình 2.3: Định nghĩa GSA 33

Hình 3.1 Thay khóa theo đợt, theo chu kỳ, ngay tức thời 43

Hình 3.3: Phân phối khóa trong MARKS 45

Hình 3.4: Một ví dụ về cây khóa 47

Hình 3.5: Khởi tạo một cây khóa nhị phân 49

Hình 3.6: Tham gia thay khóa trong LKH 50

Hình 3.7: Giải phóng thay khóa trong LKH 52

Hình 3.8: Cải tiến giải phóng thay khóa hiệu quả sử dụng OFC 53

Hình 3.9: Phân phối khóa OFT 55

Hình 3.10: Khởi tạo OFT 56

Hình 3.11: Tham gia thay khóa trong OFT 57

Hình 3.12: Thay khóa khi rời thành viên trong OFT 59

Hình 3.13: Phân phối khóa trong STR 64

Hình 3.14: Giải phóng thành viên dựa trên STR-based 65

Hình 3.15: Minh hoạ các tập con khác nhau 67

Hình 3.16: Giải phóng thành viên trong SDR 68

Hình 4.1: Mô hình ứng dụng 71

Hình 4.2: Sơ đồ trạng thái GSAKMP 72

Hình 4.3: Cây LKH 73

Hình 4.4: Cây khoá LKH và GSAKMP 75

Hình 4.5: Thiết lập chính sách khóa 80

Hình 4.6: Mô hình thẻ bài cho các chính sách khóa 82

Hình 4.7: Kiến trúc thiết lập nhóm và quản lý khóa nhóm 85

Hình 4.8: Màn hình chọn file khóa 89

Hình 4.9: Màn hình chọn file khóa 89

Hình 4.10: Màn hình chọn user 89

Hình 4.11: Màn hình chọn phiên 90

Hình 4.12: Màn hình cập nhật thông tin máy chủ 91

Hình 4.13: Màn hình hiển thị cho phép users thuộc phiên 92

Hình 4.14: Màn hình chọn người tham gia 93

Hình 4.15: Màn hình tham gia Chat 93

Hình 4.16: Màn hình thông báo lỗi không được tham gia 94

DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT

1 ACLs Access control lists

2 ASM Any Source Multicast

3 BSRs Bootstrap routers

4 BGMP Border Gateway Multicast Protocol

5 BGP Border Gateway Protocol

6 CDN Content distribution network

7 CCNT Cryptographic context negotiation template

8 CCNP Cryptographic context negotiation protocol

9 CBT Core-Based Tree

10 GCKS Group controller and key server

11 GS Group secrecy

12 GSA Group security association

13 GSAKMP Group security association key Management protocol

14 GSC Group security controller

15 IETF Internet Engineering Task Force

16 IRTF Internet Research Task Force

17 ISAKMP Internet security association and key management protocol

18 KDs Key distributors

19 KEKs Key Encryption Keys

20 IGMP Internet group management protocol

21 MAAS Multicast address allocation server

22 MDP Multicast data protocol

23 NACKs Negativeacknowledgments`

24 OSPF Open Shortest Path First

25 OFC one-way function chains

26 OFT one-way function tree

27 PPV Pay-per-view

28 VPNs Virtual private networks

29 TEK Traffic Encryption Key

30 LKH Logical Key Hierarchy

31 OFT One-Way Function Trees

MỞ ĐẦU

Vấn đề an toàn (security) dữ liệu trong truyền dữ liệu Multicast là chủ đề Công nghệ được rất nhiều người quan tâm, khi nghiên cứu có thể làm nản chí, nhưng nó thực sự là một chủ đề rất đáng được quan tâm

Vậy thì điều gì đã lôi cuốn tôi nghiên cứu vấn đề an toàn Multicast (Multicast security)? Các nhà thiết kế đã đưa ra mô hình truyền Multicast được

sử dụng để phân phối dữ liệu cùng một thời điểm tới một số lượng người nhận Nếu chỉ những người nhận được phép xem nội dung, vậy thì cần được bảo mật thông tin, nhưng làm cách nào khóa bảo mật được phân phối tới rất nhiều người nhận? hơn thế nữa, một khóa (key) cho dữ liệu bảo mật sẽ được thay đổi một cách định kỳ, trong khi đó các nhà nghiên cứu mật mã rất lo lắng trong việc bảo mật nhiều dữ liệu với cùng một khóa Điều gì xảy ra khi các thành viên của nhóm thay đổi? Hỗ trợ như thế nào khi các thành viên của nhóm trả khoản phí khi người nhận nội dung phải thanh toán (chẳng hạn: TV channels) Khi một thành viên rời khỏi nhóm không làm ảnh hưởng tới các thành viên trong nhóm Sự cần thiết và mong muốn khi thành viên mới tham gia nhóm, nhóm đó sẽ có sự thay đổi khóa Vấn đề là trong một khoảng thời gian rất ngắn khi thành viên mới tham gia nhóm làm thế nào để khám phá ra khóa và giải mã nội dung đó?

Mặt khác, để đưa ra sự an toàn truyền thông bao gồm tính toàn vẹn và xác thực dữ liệu với lược đồ khóa bí mật, một người nào đó có khóa bí mật phải hiểu

và kiểm tra được tính đúng đắn, toàn vẹn của dữ liệu Với môi trường truyền thông có tính bắt tay 2 chiều thì không có vấn đề gì Nếu Alice gửi một thông điệp tới Bob, tính toàn vẹn là kiểm tra phần dữ liệu ngoài khóa và chỉ có 2 người cùng chia sẻ Nếu việc kiểm tra xác nhận đúng, Bob sẽ hiểu được thông điệp của Alice Tuy nhiên, nếu cùng một lược đồ khóa được sử dụng cho nhóm truyền thông Alice gửi thông điệp cho hàng nghìn người nhận, mỗi người nhận được sẽ hiểu cùng một hệ mật mà Alice sử dụng theo đúng cơ chế sinh để kiểm tra tính toàn vẹn Ý ở đây muốn nói rằng nội dung dữ liệu có thể đến với thành viên bất

kỳ trong nhóm và cho phép tất cả thành viên trong nhóm đọc dữ liệu, nhưng nếu bạn muốn bảo mật và chỉ cho một số thành viên có thể đọc được dữ liệu thì vấn

đề quản lý khóa nhóm như thế nào? Chẳng hạn thay đổi hệ mật mã khóa công khai, nhưng nó sẽ rất chậm do việc sinh và kiểm tra chữ ký số trên rất nhiều các gói tin Vì vậy, các nhà thiết kế bảo mật thông tin trong truyền Multicast đã phát minh ra lược đồ cho phép xác thực bằng hệ mật mã khóa công khai không ảnh hưởng tới tốc độ thực hiện Các vấn đề về quản lý khóa nhóm trong an toàn dữ liệu truyền Multicast sẽ được làm sáng rõ trong đề tài nghiên cứu này

Chương 1: MỞ ĐẦU

1.1 Về an toàn dữ liệu trong truyền Multicast

Ngày nay, có rất nhiều các dạng ứng dụng phân phối, các phần mềm phân phối, luồng kết xuất từ kho dữ liệu, Web Caching, các ứng dụng Multimedia là các

ví dụ điển hình yêu cầu truyền thông theo hướng one-to-many hoặc many-to-many Multicast trở nên rất có hiệu quả cho các hình thức truyền thông theo nhóm, cho phép người gửi truyền các bản dữ liệu sao chép thông qua các thành phần của mạng như routers, switches nhằm sao chép các dữ liệu cần thiết cho người nhận Multicast giảm số lần gửi dữ liệu của người gửi và tạo ra một số lượng các bản dữ liệu sao chép lan truyền trên mạng

Thật không may, khi một số lượng lớn các nghiên cứu và phát triển các giao thức Multicast trong thập kỷ qua, các nghiên cứu phát triển các ứng dụng Multicast rất chậm Trên thực tế thiếu vắng các dịch vụ Multicast hỗ trợ cho quản lý truyền thông mạng, quản lý tính cước, độ tin cậy và vấn đề an toàn dữ liệu

Chúng ta nhận thấy rằng sự an toàn Multicast là một trong những vấn đề hết sức quan trọng để giải quyết thành công cho sự phát triển các ứng dụng truyền thông theo nhóm Chẳng hạn, các nhà đầu tư muốn lấy dữ liệu từ các kho dữ liệu thông qua luồng truyền dữ liệu theo dạng Multicast đã được xác thực đúng kết quả muốn tìm kiếm Tương tự, các nhà cung cấp dữ liệu muốn giới hạn nội dung cần phân phối cho các thuê bao (người sẽ trả cho nhà cung cấp một khoản phí nào đó) Cuối cùng sự mong đợi đó là an toàn dữ liệu, độ tin cậy là một yêu cầu bức thiết của các ứng dụng truyền thông dạng conferencing, truyền thông qua internet… Nhìn chung các ứng dụng phổ biến của Multicast đòi hỏi tính toàn vẹn, điều khiển luồng truy cập và các vấn đề mang tính riêng tư IP Multicast được xem là rất tốt trong mô hình hệ thống mở Người nhận có thể kết hợp với người gửi để truyền dữ liệu tới nhóm Multicast không chịu ảnh hưởng của các thực thể trung tâm Tuy nhiên, cùng một mô hình hệ thống mở cũng có sự khác biệt hỗ trợ điều khiển truy nhập Multicast Để đảm bảo tính riêng tư, nhóm các thành phần cần có khóa chung, khóa này có thể yêu cầu sự tương tác với thực thể trung tâm Mặc dù yêu cầu khó khăn trước mắt đặt ra cho chúng ta là đảm bảo an toàn trong truyền thông Multicast không mất mát thông tin

Có ba mục đích được đưa ra xem xét trong cung cấp dịch vụ an toàn Multicast

Người gửi cần bảo mật và xác thực dữ liệu truyền Multicast Để bảo mật, nhóm thành viên yêu cầu 1 khóa chung được trao đổi giữa chúng Hơn thế nữa điều khiển truy nhập có hiệu lực bằng cách phân phối khóa chung tới các thành viên trong nhóm, không thay đổi mô hình IP Multicast Khi thành viên của nhóm thay đổi, khóa chung được tạo lại và phân phối tới tập các thành viên mới thiết lập trong nhóm Lược đồ tạo lại khóa và phân phối khóa trong nhóm là một phần quan trọng trong giải pháp an toàn truyền dữ liệu Multicast

Bước tiếp theo các thành viên phải kiểm tra các dữ liệu nhận về đúng với dữ liệu của người gửi Bởi vậy việc xác thực và bảo mật dữ liệu là một phần cấu thành nên các vấn đề cần nghiên cứu

Thêm vào đó, sự khác nhau giữa các ứng dụng Multicast many- to -many và one – to –many dạng phân phối offline dữ liệu cần phải có sự kiểm tra các yêu cầu

hệ thống cuối, các vấn đề truyền thông và bảo mật hệ thống Nhóm các chính sách cho phép quyền trong nhóm hoặc cung cấp nội dung để nêu rõ yêu cầu mong đợi các hành vi của nhóm thay đổi trong môi trường thực hiện

Thêm vào đó để bảo vệ nội dung, chúng ta phải xác định rõ việc bảo vệ hạ tầng Multicast cũng như các yêu cầu quan trong khác, xem xét thực tế việc từ chối dịch vụ (denial of service- DoS) gắn kèm với mô hình dịch vụ phân phối của Multicast Đặc biệt xem xét đến các giao thức định tuyến, các giao thức Multicast tin cậy (Reliable Multicast protocols) và giao thức quản lý nhóm Internet (Internet group management protocol-IGMP) cần thiết để bảo vệ tính toàn vẹn của các thông điệp điều khiển để đảm bảo thao tác đúng Không bảo vệ toàn vẹn, không xác thực

dữ liệu khi đến các thành viên tạo ra 1 dòng chảy dữ liệu không kiểm soát hoặc làm tắc nghẽn mạng, kết quả từ chối dịch vụ đến với các thành viên Vì vậy cần xác thực thông điệp điều khiển địa chỉ, cũng như việc xác thực của các thiết bị router hoặc các host

1.2 Sự cần thiết Multicast an toàn

Truyền Multicast là một giải pháp hiệu quả cho truyền thông theo nhóm trên Internet, thay thế việc gửi dữ liệu từng bản copy tới từng người nhận nhiều lần bằng một lần gửi Các thiết bị routers trong mạng sẽ tạo ra bản copies và chuyển tiếp các gói tin tương ứng đến người nhận Truyền Multicast mang nhiều tiện ích: tận dụng băng thông, sử dụng không gian lưu trữ hiệu quả và giảm load dữ liệu từ người gửi, như vậy sẽ rất thuận lợi cho việc chuyển các thông điệp qua các routers

IP Multicast được thiết kế mức tổng quát, người nhận không trực tiếp liên hệ với người gửi để diễn đạt các ý của họ về nội dung dữ liệu gửi đến người nhận Thay vào đó, người nhận gửi một thông điệp dạng Multicast đến router đầu tiên theo bước nhảy định tuyến trước, router này quan tâm đến các đến các dữ liệu của người nhận để chuyển đến nhóm Multicast cụ thể Đặc biệt khi người nhận sử dụng giao thức quản lý nhóm Internet (Internet Group Management Protocol) [9] để nhận

dữ liệu từ nhóm đưa tới Multicast chuyển tiếp cây bao gồm cả chính nó sử dụng giao thức định tuyến giống như giao thức không phụ thuộc vào Multicast (PIM [15]) Trong khi khía cạnh tiên tiến của truyền Multicast được làm sáng rõ, có một vài cản trở cho sự phát triển trên phạm vi rộng [17] Các ứng dụng phổ biến trên internet dựa trên kiểu truyền unicast (từ một máy chuyển dữ liệu đến 1 máy đích) và phụ thuộc vào độ tin cậy và bảo mật đường truyền Hầu hết các ứng dụng sử dụng giao thức (hypertext transfer protocol (HTTP), file transfer protocol (FTP) hoặc telnet) chạy thông qua giao thức TCP cho sự tin cậy và phần lớn các ứng dụng thương mại điện tử chạy thông qua giao thức (secure socket layer -SSL) Việc truyền theo theo phương thức unicast được đảm bảo trong suốt cuộc truyền và chúng ta thấy các thông tin được hiển thị trước khi phải nhập username, password,

số thể tín dụng và các thông tin nhạy cảm khác Người sử dụng cuối và các nhà cung cấp dịch vụ ứng dụng mong đợi độ tin cậy và bảo mật dữ liệu trong quá trình truyền Multicast Tuy nhiên, không phải tất cả các ứng dụng truyền theo dạng unicast hoặc Multicast cần độ tin cậy hoặc an toàn dữ liệu Truyền thông IP Multicast cần được bảo mật nếu có yêu cầu Các nhà cung cấp nội dung có thể nạp

dữ liệu lên đường truyền internet theo phương thức unicast để tăng tốc độ truyền Chẳng hạn, các dạng dữ liệu download, thư viện số dùng chung, các tạp chí trực tuyến…

Tuy nhiên, không thể áp dụng đồng loạt cho trường hợp truyền Multicast Lý

do chính ở đây là không thể ẩn mô hình người nhận của IP Multicast Một người nhận có thể yêu cầu dữ liệu nhận về và người gửi không thể điều khiển thông qua các thành viên quen thuộc của nhóm Một cách đơn giản hơn, một người bất kỳ có thể gửi dữ liệu tới nhóm Multicast Một người nào đó mong đợi điều khiển truy nhập có hiệu lực ở tầng cao hơn, điển hình là tầng ứng dụng Sự xem xét biến đổi điều khiển truy nhập có hiện lực nếu sử dụng IGMP (Internet Group Mamagment Protocol) Một router biên có thể kiểm tra nếu host đó là một thành viên, trước khi chuyển yêu cầu truyền dữ liệu Multicast Nhưng khi dữ liệu đi theo vào luồng chia

sẻ chung trong mạng LAN, hầu hết các host trong mạng LAN có được quyền truy

cập dữ liệu nếu chúng là thành viên, nếu tất cả các thành viên thanh toán dịch vụ hay chỉ có một thành viên thanh toán? Vì vậy việc bảo mật dữ liệu Multicast và phân phối các khóa mật tới các thành viên là chỉ ra cách để đảm bảo quyền truy cập

dữ liệu Nói cách khác an toàn Multicast cho phép cung cấp nội dung để đảm bảo điều khiển truy cập dữ liệu có hiệu lực mặc dù dữ liệu được truyền dạng Multicast Điều khiển truy cập chỉ là nhân tố thúc đẩy cho đảm bảo an toàn truyền thông Multicast Các ứng dụng nhìn chung phải được đảm bảo tính riêng tư, tính xác thực

và toàn vẹn dữ liệu, không từ chối dữ liệu truyền Multicast Hơn thế nữa, các yêu cầu có thể khác nhau về mức độ quan trọng với mỗi ứng dụng: chẳng hạn, một số ứng dụng có thể cần thông điệp xác thực nguồn (các kho dữ liệu), một số khác lại cần tính riêng tư và tính xác thực đi kèm Hay nói cách khác cần được bảo mật dữ liệu theo các cấp độ khác nhau để đảm bảo an toàn trong truyền Multicast Các khối dữ liệu phân phối theo luồng Multicast đem lại lợi ích rất to lớn cho các nhà cung cấp dịch vụ internet (ISPs) Một yêu cầu gửi bất kỳ có thể bắt đầu gửi dữ liệu tới nhóm Multicast, đơn giản host lôi cuốn dữ liệu vào luồng truyền thông Multicast kể cả các luồng không cần thiết truyền tới, cho dù lãng phí tài nguyên mạng và không gian bộ đệm lưu trữ trên routers và băng thông trên đường truyền Điều này liên quan đến địa chỉ hóa phải rất tốt Giao thức định tuyến Multicast (Multicast routing protocols) và giao thức Multicast tin cậy (Reliable Multicast protocols) rất cần thiết cho sự bảo vệ tính toàn vẹn cho các thông điệp điều khiển để chống lại kẻ tấn công có thể làm thay đổi, xóa hoặc từ chối các thông điệp điều khiển, như vậy sẽ là nguyên nhân từ chối dịch vụ

Như vậy, có thể xem an toàn Multicast là việc cải tiến hiệu quả điều khiển truy nhập theo nhóm, độ tin cậy và tính xác thực cho truyền dữ liệu và bảo vệ chống sự tấn công trên mạng Loại trừ nhóm truy nhập, các yêu cầu này phải gắn liền với việc địa chỉ hóa cho truyền thông dạng unicast Thật không may mắn các giải pháp thiết

kế cho kiểu truyền thông one – to one không thể được sử dụng trực tiếp cho truyền thông theo nhóm Cụ thể: việc đàn phán các chính sách bảo mật cho rất nhiều thành phần có thể không được thống nhất và được phân phối các khóa nhóm, các giao thức thỏa thuận không được phân chia tới các nhóm lớn Lưu ý rằng việc bảo mật không phải dịch vụ nào cũng phải sử dụng các mức bảo mật giống nhau Các mức bảo vệ khác nhau phụ thuộc vào ứng dụng và không thể có 1 giải pháp duy nhất trên mạng có thể áp dụng cho các ứng dụng Multicast

Số lượng người gửi trong nhóm thực sự rất quan trọng cho việc thiết kế chính sách bảo mật khi truyền thông theo nhóm Trong rất nhiều ứng dụng chỉ có 1 người

gửi Source-specific Multicast (SSM) là một định tuyến cụ thể được thiết kế để hỗ trợ cho one-sender Multicast Ví dụ: ứng dụng một người gửi việc thanh toán trên 1 lần view trong truyền Multicast là kho dữ liệu luu trữ được phân phối trên Internet theo luồng Multicast, đồng bộ với các cache (bộ lưu trữ tạm thời) của web

Truyền Multicast mang tính thương mại, sẽ tham chiếu đến chuẩn (Internet Standard Multicast - ISM) hoặc người gửi bất kỳ (any sender Multicast-ASM), hỗ trợ truyền thông nhiều người gửi Tiêu biểu cho việc truyền thông nhiều người gửi

có thể đưa ra một số vấn đề mới khi cung cấp dịch vụ Multicast an toàn như sau: mọi người gửi khác nhau yêu cầu các chính sách khác nhau, điều này có thể xảy ra xung đột; một vấn đề khác nữa các máy tính có thể được thiết kế bảo vệ bởi các phần cứng trong trường hợp nhiều người gửi

Tuy nhiên chúng ta giới hạn phạm vi nghiên cứu với 1 người gửi Multicast Hơn thế nữa, các ứng dụng phổ biến như: multimedia conferencing bao gồm nhiều người gửi có thể cần đến các chính sách riêng hoặc thêm các thông điệp toàn vẹn cho một số phiên làm việc Khi các ứng dụng dạng này chỉ có thể áp dụng cho một vài người gửi, một trong số họ phải sử dụng một vài phiên khởi tạo chế độ an toàn theo phương án one – to – Multicast

1.3 Xử lý dữ liệu Multicast an toàn

Nhóm nghiên cứu IRTF SMuG Research Group và IETF MSEC đã đưa ra ba vấn đề khoanh vùng trong việc cung cấp truyền thông nhóm an toàn: kết nối dữ liệu Multicast an toàn; mức độ quan trọng của quản lý khóa và các chính sách Multicast

an toàn

1.3.1 Kết nối dữ liệu Multicast an toàn

Trong phần này, chúng ta đánh địa chỉ cho việc truyền dữ liệu Multicast an toàn Để chính xác hơn, chúng ta đưa ra việc truyền dữ liệu các dữ liệu Multicast được giữ bí mật và được bảo vệ tính toàn vẹn Với dữ liệu mật người gửi cần mã hóa dữ liệu với khóa mật và khóa mật này sẽ được các thành viên của nhóm hiểu được: giả sử rằng host nào đó xác thực được và nhận dữ liệu Multicast Theo các cấp độ phân phối và việc tạo lại khóa của khóa nhóm là một vấn đề phức tạp và được thiết kế thông qua việc phân vùng cho chính nhóm đó Việc vận chuyển an toàn các dữ liệu đã đóng gói (IPsec encapsulating security payload (ESP)[31] ) trong chế độ bảo mật là các ứng dụng truyền thông Multicast riêng lẻ Trong phần này chúng ta đánh địa chỉ cho vấn đề truyền bảo mật dữ liệu Multicast an toàn Một

cách chính xác hơn, chúng ta thảo luận truyền dữ liệu sao cho bảo mật dữ liệu Multicast và bảo vệ tính toàn vẹn Để bảo mật dữ liệu, người gửi cần mã hóa dữ liệu với một khóa mật, khóa mật này chỉ có thành viên của nhóm hiểu được, điều đó chứng tỏ các hosts phải xác thực được các dữ liệu nhận được Mức độ phân phối và thay khóa của khóa nhóm là một vấn đề phức tạp và được thiết kế trong phạm vi của chính nó Tải cho việc truyền gói dữ liệu IPSec được đóng gói và truyền dữ liệu cho các ứng dụng truyền thông mạng riêng là rất tốt (IPsec encapsulating security payload (ESP)[31] ) Chỉ thông báo trước cho các máy được bảo vệ nạp lại các gói tin dạng ESP và làm việc theo kiểu một người gửi và nhiều người nhận ESP hỗ trợ

mã xác thực thông điệp dựa trên địa chỉ MAC đảm bảo cho tính toàn vẹn trong truyền thông đơn hướng

Trong hai cách truyền thông, xác thực dựa trên địa chỉ vật lý (MAC) là đầy đủ cho người nhận để xác định gói tin của người gửi, không phù hợp khi truyền thông với nhiều thành phần Xem xét trong trường hợp truyền thông 2 điểm, Alice và Bob, mỗi người lưu giữ một khóa mật cho việc xác thực thông điệp Alice sử dụng khóa để tính toán mã xác thực thông điệp (có thể định hướng dựa trên hàm MAC, chuỗi khối mật mã (cipher block chaining (CBC), các hàm MAC dựa trên cơ sở hàm băm (MAC - hash-based MAC (HMAC) [37]) ) và gửi thông điệp cùng với hàm MAC đến người nhận Bob lặp lại thủ tục tính toán hàm MAC và so sánh với hàm MAC nhận được Nếu hàm MAC được xác định, Bob hiểu các thông điệp không bị thay đổi trên đường truyền Khi Bob biết thông điệp chưa được gửi, Alice phải gửi lại nó, khóa xác thực chưa được dàn xếp ổn thỏa

Chúng ta cần sử dụng hàm MAC cho việc truyền thông nhóm có xác thực theo cách đơn giản ở trên, nhưng giảm mức độ bảo vệ tính toàn vẹn Khi xem xét trong một nhóm bao gồm Alice, Bob và Cindy lưu giữ khóa xác thực Alice sử dụng hàm MAC để xác thực thông điệp gửi tới Bob và Cindy, tuy nhiên không thể hiểu được nếu thông điệp được gửi hoặc hoặc bị thay đổi bởi Alice hoặc Cindy hoặc Bob Nhìn chung các thành viên của một nhóm chỉ có thể kiểm tra việc không phải thành viên của nhóm vì một người bất kỳ không thể có khóa xác thực và không thể thay đổi nội dung giữ liệu theo đường truyền Xác thực nhóm là thuộc tính chỉ đảm bảo rằng các thông điệp được gửi và được thay đổi cuối cùng bởi thành viên nào của nhóm Khi một hàm MAC được sử dụng cho xác thực nhóm sẽ không tốn kém cho việc xác thực luồng dữ liệu theo thời gian thực Để xác thực theo nhóm, người gửi cần thiết lập một khóa chung với các thành viên của nhóm Vấn đề phân phối khóa được đánh địa chỉ trong các phân đoạn kế tiếp và IPsec ESP có thể được sử dụng để

mang theo dữ liệu truyền Multicast được xác thực theo nhóm Trong hầu hết các ứng dụng, người nhận phải được thiết lập tới nguồn dữ liệu tại đoạn cuối cùng với người nhận Theo cách hiểu khác chúng ta cần xác thực nguồn dữ liệu Một phiên bản đúng đắn nhất bao gồm các thuộc tính theo mô tả trên và cho phép người nhận

dữ liệu thuộc thành phần thứ 3 cung cấp

Tuy nhiên, xác thực nguồn dữ liệu dữ liệu Multicast là một vấn đề khó Giải pháp đơn giản là chữ ký số cho các gói tin, nhưng nếu mỗi gói tin kèm theo chữ ký

sẽ làm cho giá cả truyền thông dữ liệu cao lên, đưa ra sự dư thừa của các gói tin truyền thông làm tràn các bộ nhớ đệm Một vài giải pháp đã được đưa ra nhằm giảm giá thành các chữ ký số trên số lượng gói tin được ký

Bảo đảm Unicast thông qua giao thức trao đổi khóa IKE [9] kết quả tạo ra khóa cụ thể mỗi khi khởi tạo và không thể sử dụng trực tiếp cho truyền thông theo nhóm Thay thế vào đó có một thực thể trung tâm như GCKS cần thiết để download các khóa nhóm cụ thể cho mỗi thành viên theo các kênh mà thành viên đăng ký Mỗi thành viên liên hệ vói GCKS để đăng ký và tham gia nhóm Sau khi xác thực GCKS kiểm tra lại các thành viên tham gia, thiết lập kênh truyền an toàn và download các khóa nhóm kèm các chính sách cho thành viên Việc đăng ký trao đổi khóa theo hướng one – to – one giữa GCKS hoặc một đại diện xác thực và mỗi thành viên Các trao đổi an toàn one – to – one được yêu cầu tương tự cách bảo vệ trong IKE or SSL, đóng vai trò bảo vệ trung gian trong việc lặp lại hoặc từ chối đính kèm dịch vụ, tạo kết nối và hướng tới phân chia đăng ký khởi tạo các nhóm rộng lớn Khi đăng ký trao đổi khóa one – to – one điểm thuê dịch vụ liên hệ với tất

cả các thành viên là không khả thi Có một vài cách giải quyết tiến trình:

Cách thứ nhất, các chức năng đăng ký GCKS có thể được phân phối thông qua một số thực thể

Cách thứ hai: các thành viên có thể đăng ký tại điểm chung của họ, tuy nhiên cần tránh nhiều thành viên đăng ký tại một thời điểm Trong tiến trình này đơn giản

là cấp thẻ cho các sự kiện thực hiện tiến trình và cho phép thực hiện với các thẻ trong trạng thái Master tại lối ra và được xác thực hành trình các agents

Thay khóa nhóm khi các khóa mật có trong thời gian sống, GCKS phải tạo lại khóa nhóm trước thời gian cho phép Nếu không phải tất cả các thành viên có thể gửi yêu cầu tới GCKS cho việc cấp khóa mới, kết quả là khóa được thay không được cập nhật cho nhóm thành viên Phần sau xem xét vấn đề hiệu lực điều khiển truy nhập trong nhóm động, tức là nhóm có sự thay đổi các thành viên một cách liên tục GCKS có thể cần được thay khóa trong nhóm và phân phối khóa mới tới tất cả các thành viên của nhóm mỗi lần thay đổi thành viên trong nhóm Chuyển tiếp và nhận lại các điều khiển truy nhập Xem xét phân phối khóa nhóm tới nhóm động và trong phạm vi rộng lớn Trong hầu hết các ứng dụng một vài thành viên tham gia vào nhóm và rời khỏi nhóm trong một thời điểm nào đó trong phân đoạn tham gia Một số thành viên được cho phép tham gia trong một công đoạn nhất định, trong tình huống như vậy một host có thể gửi bản tin dữ liệu Multicast trước khi nó tham gia nhóm GCKS cần thay đổi khóa và phân phối khóa mới tới tất cả các thành viên Khi host tham gia vào nhóm cần được giải mã dữ liệu đã được gửi trước đó trước khi trở thành thành viên chính thức Tương tự khi thành viên rời khỏi nhóm, GCKS cần thay đổi khóa, như vậy sẽ không cho phép thành viên này được phép giải mã thông tin trong tương lai khi tham gia truyền thông

Tóm lại, để đảm bảo chỉ có thể xác thực được các thành viên và cho phép các thành viên giải mã dữ liệu cần chuyển tiếp và nhận lại các thông tin điều khiển truy nhập, các thông điệp thay đổi khóa có thể được truyền đi theo luồng Unicast hoặc Multicast đảm bảo tính hiệu lực phân phối cho tất cả các thành viên Cách đơn giản

là đăng ký các thông điệp, khóa mới tạo ra phải được bảo vệ gắn kèm với với việc tham gia lại cuộc chơi và phải được đăng ký bởi GCKS cho việc xác thực

Trên thực tế các thành viên của nhóm có thể thay đổi động, kích cỡ động của các nhóm có một ý nghĩa thực tế rất quan trọng cho việc chuyển tiếp các điều khiển truy nhập Cần xem xét một cách tiếp cận để quản lý khóa nhóm Người gửi hoặc GCKS chia sẻ khóa mật với các thành viên Khi một thành viên rời khỏi nhóm, người quản lý phải gửi khóa mật mới tới các thành viên của nhóm Đồng thời phải tính đến việc gia nhập nhóm làm tăng các kích thước bộ nhớ đệm, làm cho lược đồ quản lý khóa rộng hơn, nó có thế làm cho không có hiệu lực với một nhóm rộng lớn Kết hợp bảo mật nhóm cho an toàn unicast, hai điểm truyền thông dàn xếp các

biến bảo mật để thiết lập để gắn kết bảo mật Internet và giao thức quản lý khóa ((ISAKMP) SA), điều đó bảo vệ sự dàn xếp IPsec SA cho truyền dữ liệu bảo mật [11] Theo một mô hình đơn giản, sự kết hợp an toàn nhóm (GSA) [21] được tiêu chuẩn hóa theo tổ chức IETF và có sự tham gia của thành phần thứ 3 Đầu tiên đăng

ký SA để bảo vệ download khóa trong khi đăng ký giao thức Khóa download chứa khóa đã được làm lại và một SA an toàn dữ liệu Khóa SA được thay mới tại thời điểm hiện tại hoặc một SA an toàn dữ liệu Chính SA an toàn dữ liệu bảo vệ cho việc truyền dữ liệu Multicast Ví dụ: một SA an toàn dữ bao gồm IPsec ESP, MESP và AMESP

Kiến trúc phân phối khóa nhóm, các giao thức và các giải thuật, chúng ta thấy phân lớp các phần tử phân phối khóa nhóm trong kiến trúc, giao thức, giải thuật cho quản lý khóa nhóm, kiến trúc phân phối khóa nhóm được chi tiết trong [43] và kiến trúc khóa Internet cho Multicast (IKAM) chi tiết trong [57], đã sử dụng nhóm con phân cấp tạo hiệu quả trong quản lý nhóm

Chúng chia các thành viên của nhóm thành các nhóm con, lựa chọn các thành viên hoặc phân đoạn các agents giống như quản lý các nhóm con (subgroup managers) và quản lý khóa nhóm đại diện nhận nhiệm vụ từ SGMs Trong chủ đề này sẽ làm sáng rõ hơn ở chương sau

Khái niệm các giao thức được sử dụng để miêu tả tập các thủ tục, thay đổi thông điệp và nạp lại các thông điệp thông qua hành vi của các thực thể bao gồm cả

sự hỗ trợ nhóm an toàn (các servers) và sự tham gia của chúng trong nhóm (các hosts) Vùng nhóm phiên dịch (Group domain of interpretation (GDOI) [15]) và giao thức quản lý khóa gắn kêt an toàn nhóm (group security association key management protocol (GSAKMP) [26]) là những giải pháp trải ra trong danh mục phần này

Các kiến trúc và các giao thức là hữu ích giải quyết vấn đề quản lý khóa nhóm

Ví dụ: Iolus hoặc IKAM có thể sử dụng GDOI cho việc đăng ký và thay khóa bên trong nhóm con

Tương tự GSAKMP cho phép một số thành viên tiếp nhận sự quản lý của các nhóm con theo từng mức đã phân chia Cả hai vấn đề kiến trúc và giao thức có hữu ích cho giải thuật quản lý khóa nhóm, được đưa ra trong phần sau Tạo hiệu quả cho việc thay khóa nhóm

Đặc thù của các giải thuật quản lý khóa nhóm sử dụng nhóm con cho việc thay khóa và phân phối khóa hiệu quả (trái ngược vấn đề này là dễ dàng miêu tả kiến

trúc quản lý khóa nhóm) Mỗi một nhóm con logic được gắn với một khóa mã hóa (KEK) được sử dụng để bảo mật các khóa KEKs khác nhau hoặc khóa nhóm Chúng ta định nghĩa 2 lớp giao thức quản lý khóa nhóm dựa trên sự phụ thuộc lẫn nhau của các thông điệp khóa Đầu tiên, dựa trên phân cấp khóa logic hoặc cây khóa [54], mỗi thành viên lưu tập con của KEKs và GCKS thay đổi các khóa KEKs này

và khóa nhóm khi thành viên mới tham gia hoặc rời khỏi nhóm Hầu hết KEK phải được mã hóa với rất nhiều các khóa theo các mức của cây khóa Mặc dù thay khóa

sử dụng kiến trúc phân cấp khóa logic yêu cầu độ phức tạo tính toán mức logarithmic các thông điệp trao đổi và một vài cách tính toán khóa tại GCKS Trong lớp giải thuật thứ 2, GCKS phân chia quyền xác thực các thành viên bên trong tập con logic được định nghia trước và gửi các khóa đã được mã hóa với khóa của tập con Đối tượng quan tâm này là trung tâm quản lý khóa nhóm được mô tả kỹ hơn trong phần sau

Vận chuyển tin cậy thông điệp thay khóa Thông điệp thay khóa là một đặc thù gửi theo luồng Multicast sao cho hiệu quả Đó là trách nhiệm của GCKS để đảm bảo rằng các thành viên có được sự bảo mật dữ liệu hiện thời và thay khóa SA Mặt khác các thành viên được xác thực có thể bị từ chối giải mã thông điệp truyền thông nhóm Vì vậy GCKS phải sử dụng cơ chế tự động truyền vận thông điệp tin cậy để gửi thông điệp thay khóa Multicast tin cậy là một vấn đề khó, nhưng có một vài giải pháp chứng minh bằng tài liệu lý thuyết Chúng ta sẽ thảo luận truyền vận thông điệp thay khóa tin cậy trong phần này

Thông điệp thay khóa là một đặc thù ngắn (áp dụng cho các hội viên thay đổi trong nhóm lớn hoặc trong nhóm nhỏ nói chung), tạo ra nó dễ dàng để thiết kế một giao thức phân phối tin cậy Cách kết nối khác yêu cầu thêm tính an toàn bằng cách thêm độ dài để giải quyêt bài toán Có một vài trường hợp thành viên thay đổi được

xử lý theo đợt, làm gia tăng kích thước của chúng Cuối cùng trong số tất cả các khóa được gửi đi thông điệp thay khóa, một nửa số thành viên chỉ cần một KEK đơn lẻ Chúng ta cần đưa ra khía cạnh tiên tiến của các thuộc tính trong thiết kế các thông điệp thay khóa và một giao thức đảm bảo độ tin cậy Có 3 danh mục giải pháp được đề xuất:

+ Bởi vì rất nhiều trường hợp thông điệp thay khóa là rất nhỏ (cố định trong 1 hoặc 2 gói tin IP), GCKS có thể lặp truyền lại thông điệp thay khóa + GCKS có thể sử dụng giao thức Multicast tin cậy hoặc một hạ tầng

để đảm bảo

+ Chúng ta có thể sử dụng forward việc sửa lỗi vào trong gói tin thay khóa mã hoá, sử dụng cơ chế feedback bác bỏ sự nhận acknowledgements hoặc (NACKs) từ các thành viên để xây dựng vòng tiếp theo của thông điệp thay khóa [57] Tuy nhiên lưu ý rằng vấn đề truyền tin cậy dựa trên feedback

có thể nhận được nạp 2 lần thông điệp feedback tại GCKS

Yêu cầu của các ứng dụng

Yêu cầu của các ứng dụng ảnh hưởng rất lớn đến lựa chọn thiết kế giải pháp cho phân phối khóa nhóm Trong một vài trường hợp chẳng hạn phải trả cho việc xem dữ liệu (pay-per-view (PPV)), tất cả các thông tin SA cần được nạp vào phiên được phân phối tại thời điểm đăng ký hoặc khởi tạo phiên làm việc Như vậy không được thay khóa khi hội viên thay đổi Thay khóa SA có thể không cần thiết cho lược

đồ quản lý khóa, điều này đáp ứng trong truyền thông điểm- điểm (nhóm là rất nhỏ)

Sự ràng buộc chặt chẽ của điều khiển truy nhập forward và backward có thể không cần thiết trong một số ứng dụng

Chính xác hơn, sự thay đổi hội viên có thể được xử lý theo ưu tiên hoặc theo đợt [48], xảy ra vấn đề là nếu hội viên thay đổi chuyên gì xảy ra tại các thời điểm khác nhau Vì vậy giải pháp quản lý khóa nhóm phải tham chiếu lựa chọn mức cấu hình cho an toàn bảo mật thông tin

1.3.3 Các chính sách an toàn Multicast:

Chính sách an toàn Multicast cung cấp các luật để thực hiện 2 phạm vi vấn đề: quản lý khóa và kết nối dữ liệu Multicast Chúng ta xem xét hai kiểu khác nhau của nhóm, định danh và tương tác các nhóm và các nhóm lớn hơn với một hoặc một vài người gửi Nhóm chỉ có 1 người gửi, người gửi là người sở hữu nội dung hoặc nó được đại diện để gửi Quyền sở hữu nội dung xác định ai là người có thể nhận dữ liệu và số lượng tin cần được bảo vệ và thiết kế GCKS GCKS cho phép cả 2 hình thức phân phối và các chính sách ép buộc Thỉnh thoảng các nhóm tương tác với nhau có thể điều tiết, việc điều tiết có thể được xem xét quyền của nhóm Chính sách cho nhóm nhỏ có thể xem xét sự dàn xếp trong [16], như sự dàn xếp này không thể áp dụng cho các nhóm lớn Sự thay đổi quyền nhóm có thể phân phối và các chính sách ép buộc Quyền nội dung xác định mức độ chính sách cho chúng và phải được dịch thành các luật một cách chính xác vì rằng các chính sách có thể có hiệu lực với cơ chế tự động an toàn sẵn có Ngôn ngữ đề xuất chính sách chẳng hạn theo Ismene [41], mẫu đàm phán ngữ cảnh bảo mật (cyptographic context negotiation

template (CCNT) [16]) và thẻ bài quy định chính sách an toàn nhóm (group security policy token (GSPT) [26]) được đề xuất rõ ràng chính sách nhóm

Các thành phần của chính sách nhóm an toàn

Các nhóm có một vài chính sách nhóm đối với mô hình truyền thông peer – to – peer Trong nhóm, các thực thể khác nhau về luật,,các khả năng và các chính sách xác thực định nghĩa các thành viên, người gửi và GCKS và các thành phần đại diện cho xác thực chúng (chẳng hạn đặc quyền của GCKS và các máy chủ chuyên thay khóa) Danh sách điều khiển truy nhập (Access control lists ACL) và các chứng chỉ

số là một trong các ví dụ tự động cho quyền điều khiển truy nhập Chính sách mệnh lệnh, cụ thể là các giải thuật xác thực mã hoá được sử dụng thể thay khóa là rất tốt cho truyền thông dữ liệu an toàn Hơn thế nữa, quyền sở hữu nội dung chỉ ra nếu GCKS cần phải thực hiện thay khóa khi có thành viên thay đổi, hoặc xử lý theo sự

ưu tiên Chính sách nhóm sẽ bao gồm cả hành vi của các thành viên khi một thành viên không có trong GSA tính đến thời điểm sau nhất Yêu cầu của các ứng dụng, giá trị của nội dung và một vài thời điểm tự động hỗ trợ bởi người gửi và GCKS, tất

cả nhóm trở nên có hiệu quả

Chúng ta kết thúc phần này với một lưu ý phân phối chính sách trong các nhóm Cách gọi khác đó là thương thuyết chính sách không hội tụ trong các nhóm lớn Tuy nhiên chính sách phân phối mang đến một vấn đề khá thú vị Khi không có

sự thương thuyết, các thành viên có thể hiểu nếu chúng có thể bị tham gia trước khi đăng nhập (trả tiền để lấy quyền truy nhập) để nhận được dữ liệu Cách nói khác, một số chính sách cần được phân phối trước Tuy nhiên nó không thể thực hiện mạnh trong việc quảng cáo chính sách nhóm an toàn cho tất cả thế giới biết tới Như vậy sự phụ thuộc yêu cầu của ứng dụng, một số chính sách phải được phân phối trước Trong khi phần còn lại được phân phối bởi GCKS chỉ để xác thực các thành viên

1.4 Bảo vệ hạ tầng

Việc bảo vệ nội dung, chúng ta cần xem xét sự đe dọa hạ tầng Multicast Có 3 thành phần của vấn đề này, tương ứng cho người gửi điều kiển truy nhập, bảo vệ hạ tầng định tuyến Multicast và tiếp nhận điều khiển truy nhập

Xem xét trong mô hình Multicast truyền thống, một người gửi có thể truyền

dữ liệu tới nhóm Multicast bất kỳ; nó không cần thành viên của nhóm

Như vậy, một đối thủ có thể từ chối dữ liệu trên cây Multicast và bỏ hoang tài nguyên mạng, chẳng hạn như không gian bộ đệm trên các thiết bị routers và băng thông trên đường truyền Vấn đề này đã được định nghĩa trong mô hình sự phát triển gần đây (mô hình SSM) và một số giao thức truyền thống được sửa đổi cho phù hợp với mô hình SSM (PIM-SSM [28])

Tiếp theo, theo trật tự giao thức định tuyến Multicast và unicast để có hành vi một cách đúng đắn, tất cả các gói tin điều khiển được thay đổi giữa các router thực hiện định tuyến phải được bảo vệ chống lại sự cố tình thay đổi dữ liệu hoặc xoá dữ liệu đó

Tương tự giao thức định tuyến Multicast, giao thức Multicast tin cậy thực hiện bởi sự thay đổi thông điệp điều khiển giữa các thực thể phức tạp trong giao thức Từ giao thức Multicast tin cậy đến thuộc tính của các hàm điều khiển, các thông điệp điều khiển phải được bảo vệ từ việc thay đổi trong vận chuyển

Cuối cùng, cần nhắc lại rằng host bất kỳ có thể tham gia nhóm Multicast và đẩy theo luồng phân phối của cây chuyển tiếp đến chính nó Một chính sách quảng cáo có thể được khai thác trong tương lai và đẩy theo luồng giao thông Multicast là không cần thiết, nó có thể là lý do để từ chối dịch vụ Như vậy để bảo vệ hạ tầng, các router biên phải cho phép xác thực các thành viên đẩy luồng dữ liệu

1.5 Ứng dụng của Multicast an toàn

Bảo mật dữ liệu và phân phối khóa để xác thực các thành viên hỗ trợ điều khiển truy nhập nhóm không thay đổi mô hình multicasr IP Điều khiển truy nhập cho phép các nhà cung cấp nội dung phân phối dữ liệu điều khiển và tính tiền cho nội dung Phân phối TV vệ tinh là một ứng dụng cần hỗ trợ cho điều khiển truy nhập nhóm

Các ứng dụng Multicast yêu cầu dữ liệu một cách tin cậy hoặc tính chính xác của các thông điệp Các nhà đầu tư nhận hạn mức cổ phần cần sự bảo đảm dữ liệu

đó được gửi và được người gửi xác thực được và không bị thay đổi bởi router cuối cùng

Một vài tập đoàn truyền các thông tin nhạy cảm chẳng hạn phần mềm, cơ sở

dữ liệu và kiểm tra đánh giá cập nhật sử dụng multicast ftp (MFTP) [42]) Chúng ta

sẽ thảo luận các giải pháp để bảo vệ cẩn mật và tính chính trực của dữ liệu của truyền thông MFTP

Hội nghị đa phương tiện thông qua internet cần giao thức và cơ chế tự động cho tính riêng tư và chính xác của dữ liệu Cuối cùng, xem xét đến đó là mạng riêng

ảo (VPN) là một ứng dụng cho phép thực hiện mạng riêng cho phép kết nối giữa các chi nhánh của ngân hang thông qua Internet

Chương 2: QUẢN LÝ KHÓA NHÓM

Quản lý khóa nhóm là một lính vực nghiên cứu quản lý khóa mật mã cho các nhóm Quản lý khóa nhóm, nhìn chung là việc cung cấp một khóa đối xúng chung hoặc khóa nhóm cho tất cả các thành viên của nhóm Khóa nhóm thường được gọi

là TEK(Traffic Encryption Key ), nhằm đưa ra khóa thường được sử dụng để bảo mật dữ liệu truyền và được truyền từ một nhóm đến một người nào đó, hoặc hầu hết người gửi chuyển giao khóa nhóm (TEK) tới tất cả các thành viên của nhóm, đảm bảo đúng và không bị giả mạo Mô hình này tập trung xung quanh một mô hình thực thể trung tâm, các khóa được phân phối tới người tham gia một cách tự nhiên Vấn đề này đựơc giải quyết từ năm đầu 1980 trong khuân khổ tham chiếu đến khóa phân phối [45] giống như trung tâm phân phối khóa tin cậy (key distribution center KDC) được tìm thấy trong trong giao thức xác thực kerberos [34,51], mặc dù chính kerberos không được thiết kế để thực hiện quản lý khóa nhóm Chủ đề chính đưa ra lược đồ có quan hệ tới hệ mật mã hướng nhóm và có đưa ra chủ đề chính theo hướng cách phân phối khóa nhóm và cách thỏa mãn một số lượng các điều kiện hoặc yêu cầu đặt ra

Theo cách nhìn rộng hơn, ý tưởng đưa ra xem xét lược đồ phân phối khóa không thực sự yêu cầu thực thể tin cậy đơn lẻ, nó mang tính dân chủ Các thành viên trao đổi với các thành viên khác một cách không tin cậy Theo cách tính toán chung khóa truyền đi theo hướng tích luỹ các đoạn khóa phân phối từ mỗi thành viên Mỗi thành viên sẽ kiểm tra chính nó có đúng trong tiến trình xử lý (hoặc tính toán khóa) bằng cách kiểm tra kết quả tích luỹ [45] Một vài ví dụ yêu cầu bao gồm

cả bằng chứng cụ thể bên trong việc tham gia, kết quả có thể đúng bằng hoặc chứng

tỏ sự đóng góp của các thành viên có khóa riêng tư Một ví dụ cho lược đồ mật mã hướng nhóm [45, 8, 29, 35, 50,52] Kết quả của các yêu cầu phức tạp, đưa ra lược

đồ phân phối khóa với mức tính toán cao, không phù hợp với việc áp dụng cho thực

tế Thêm vào đó lược đồ không đưa ra việc xem xét các biến đổi cần hỗ trợ cho quản lý cách tiếp cận của các khóa tham chiếu, trên thực tế sự thay đổi của các vị trí trong mỗi thành viên diễn ra thường xuyên

Cái gì để phân biệt vùng quản lý khóa nhóm từ việc phân phối khóa trao đổi, hoặc tính toán một cách chính xác việc quản lý khóa chung trong một môi trường động áp dụng cho từng thành viên cụ thể Để đạt được các yêu cầu mang tính thực tiễn cao cần đưa thêm hay còn gọi KEKs để bảo vệ việc phân phát khóa nhóm KEK sẽ thay đổi trong suốt thời gian thay đổi các thành viên hoduyặc hết thời hạn

sống của KEK Vùng quản lý khóa nhóm được sử dụng trong thực tế truyền thông muticast, được sử dụng để quản lý khóa, mỗi thực thể nhóm là tập con của nhóm Trong chương này giới thiệu và đưa ra ngữ cảnh cài đặt quàn lý khóa nhóm, các yêu cầu an toàn cho quản lý khóa nhóm Nó cũng là nền tảng cho việc quản lý khóa trong trường hợp truyền unicast Trọng tâm trong chương này đưa ra định nghĩa một cách chính xác GSA, cũng như việc tạo ra bản sao Multicast từ unicast

mà hiện nay đang áp dụng chung là IKE và IPsec

2.1 Mô hình quản lý khóa nhóm:

Trong phần trước đã tham chiếu đến nền tảng phát triển trong IETF (Internet Engineering Task Force) cũng như các phương thức để chia nhỏ vấn đề Multicast và

an toàn nhóm trong phân chia quản lý Tiếp trong phần này nghiên cứu mô hình sử dụng cho quản lý khóa nhóm dựa trên cơ sở nền tảng IETF

Hình 2.1 đưa ra các thực thể trong quản lý khóa nhóm, cả trong hình dáng trung tâm và môi trường phân phối Mô hình xác nhận one – to – many Multicast được triển khai Xác nhận chỉ có một một người gửi cho dữ liệu Multicast

Hình 2.1: Mô hình quản lý khóa nhóm Các thực thể được đưa vào trong mô hình là các KDs (Key distributor); các thành viên gửi và các thành viên nhận

Hình 2.1 đưa ra khái niệm khác biệt về trung tâm phân phối khoá KD từ việc tham chiếu đến KD; với mỗi thành viên thuộc về nhóm sẽ được tương tác ảnh hưởng thông qua KD Sự khác biệt ẩn chứa bên trong là việc đưa ra khái niệm độ

co dãn quản lý khóa, nơi có rất nhiều các KDs được triển khai và mỗi một thành viên được kết hợp với một ―local‖ hoặc được ưu tiên KD

Hình 2.1 đưa ra quản lý khóa và chức năng quản lý SA (Internet Security Architecture) được chỉ ra bởi đường nét liền 2 chiều Mỗi thành viên thưc hiện quản lý khóa và quản lý SA với một khóa KD Các thành viên gửi sẽ truyền các gói tin đã được mã hoá theo luồng truyền Multicast trong nhóm Multicast theo đường nết liền và người nhận có thể là các local và remote thông qua cây phân phối Multicast Với mô hình này không tạo ra sự khác biệt về phương thức định tuyến các gói tin tới người nhận

Bức tranh khái quát về việc bảo vệ dữ liệu, các gói tin được mã hoá để bảo mật bởi khóa nhóm, được phân phát và quản lý thông qua quản lý khóa KD và các chức năng quản lý SA (thể hiện đường nét liền 2 chiều)

Hình 2.1 đưa ra các KDs gửi gói tin điều khiển (thể hiện đường nét đứt) tới các tập thành viên thuộc quyền điều khiển của KD Một kênh điều khiển được đặt

ra cho các KD để đảm bảo các thông điệp (chẳng hạn: các câu lệnh, các cú pháp nhắc lại, các yêu cầu khẩn cấp) tới các thành viên Thêm vào đó các kênh điều khiển được sử dụng để quản lý cả 2 loại khóa (TEKs và KEKs), keying material và

SA Kênh điều khiển đảm bảo độ tin cậy Mặc dù mô hình trên không đưa ra giao thức Multicast tin cậy (Reliable Multicast-RM) được sử dụng để tạo ra các gói tin điều khiển truyền tới các thành viên, mặc dù vấn đề này gợi ý sự tồn tại một trên điều khiển (back-channel) từ các thành viên (bao gồm cả người gửi và nhận) tới trung tâm phân phối khóa KDs Khi truyền thông tin cậy không phải chức năng cốt lõi của quản lý khóa Mô hình truyền Multicast tin cậy (RM) không được mô phỏng trong mô hình trên, mặc dù được hiểu một cách rõ ràng 1

1 Cần một kênh điều khiển (định danh, giao thức bảo mật) để tăng độ tin cậy, và cần cho giao thức Multicast tin cậy (RM) để đảm bảo có thể lĩnh hội vấn đề con gà và quả trứng Tuy nhiên, nguyên nhân lòng vòng có thể được kết thúc khi đưa ra một kênh điều khiển ngay từ ban đầu Như vậy, có thể cho phép truyền các gói tin quan trọng chứa đựng các khóa keying material

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

Các thành phần chủ yếu của quản lý khóa nhóm là quản lý các SA Trong thế giới unicast, quản lý SA cho truyền thông trên diện rộng đã được địa chỉ hoá bởi nền tảng ISAKMP [40], và được thể hiện qua giao thức IKE [22] Sự thoả hiệp IKE, ISAKMP và rộng hơn là tuôn theo chuẩn IETF, khái niệm ―key management‘‘ là sự kết hợp chặt chẽ keying material, bao gồm các khóa mật mã, định danh khóa, và các tham biến, đó là mục đích hỗ trợ chung cho các khóa đối xứng tại hai điểm đầu cuối của kết nối unicast

Trong ngữ cảnh IP Multicast môi trường truyền thông nhóm rộng hơn, có hai phần trong mô hình quản lý khóa với ISAKMP/IKE là chưa đủ, trên thực tế nhóm

có nhiều thành phần (nhiều người gửi và nhiều người nhận) Trong ISAKMP/IKE các thành phần đáp ứng (responder) trong unicast thay đổi sự lựa chọn một vài biến

và trả lại giá trị khởi tạo (initiator) Trong Multicast có nhiều thành phần tương ứng,

mô hình SA unicast đơn giản và không ánh xạ đến các nhóm Hơn thế nữa một nhóm đưa ra các thủ tục gồm các biến SA đơn giản và không có giá trị thực tế khi tham chiếu các ứng dụng Multicast

2.2.1 Yêu cầu an toàn cho quản lý khóa unicast

Khi thừa nhận rằng quản lý khóa nhóm phải được thao tác thông qua nhiều loại hình mạng internet khác nhau, cụ thể các mạng Multicast, một số tối thiểu các thuộc tính của quản lý khóa internet được yêu cầu cho quản lý khóa nhóm Các đặc tính được tổng kết theo [20, 27] bao gồm:

1 Bảo vệ chống lại tấn công, đóng vai trò như các lớp trung gian, lấy mất các kết nối, lặp lại việc truyền, các kiểu tấn công (DoS) Khái niệm thay đổi khóa xác thực (The authenticated key exchange (AKE)) là cơ sở quản lý khóa Internet và các giao thức xác định khóa để chống lại sự tấn công xảy ra trên mạng Internet làm mất tính an toàn Các kiểu tấn công bao gồm: đóng vai trò trung gian, cướp kết nối, tấn công phản hồi lại các thông điệp, có thể tạo ra cuộc chiến cho các máy trực tiếp xác thực, những vấn đề này có thể được tích hợp với các khóa thay đổi, được miêu tả trong giao thức station-to-station (STS) protocol [59] Các thông điệp có thể bị thay đổi phần nào đó trong khi chạy sẽ thay đổi chuỗi mắt xích trong các thông tin xác thực, chứa đựng các dữ liệu ngẫu nhiên được phân phối với mỗi thành phần khi thay đổi khóa giữa 2 thành phần Công nghệ này trợ giúp đảm bảo các thông điệp nhận được được xem ngang hàng với bên gửi Để làm được việc này cần được chứng

thực thuộc tính AKE, trên cơ sở xem xét các thông điệp gửi và nhận trong sự thay đổi tương ứng [4] Khi các phiên khóa được sử dụng để bảo vệ sự thay đổi đó xác định được đúng các phiên khóa khác nhau, giữ bí mật chuyển tiếp đầy đủ (perfect forward secrecy (PFS)) có thể đảm bảo rằng làm sáng rõ hơn khái niệm ―secret keying material‖ không có sự thoả hiệp tính bảo mật cho khóa thay đổi từ việc thực hiện dễ dàng hơn [59], xa hơn là phải có sự gắn kết giữa xác thực và thay đổi khóa như yêu cầu theo hướng Tuy nhiên, có thể kế thừa thuật toán trao đổi khóa (Diffie-Hellman exchange), trong trường hợp này có thể không phù hợp với tất cả các ứng dụng

2 Mức lựa chọn đảm bảo an toàn khi khóa được phát hành như: thay đổi hoàn toàn, lụa chọn các tiêu chí PFS (perfect forward secrecy) và bảo vệ một cách đồng

bộ để hỗ trợ cho các ứng dụng hỗn hợp trên Internet và các máy tính Khái niệm

‗‗selectable level of security‘‘ là cơ sở để quản lý khóa trên mạng Internet, bao gồm nhiều loại hình truyền thông qua Internet và các máy tính host với nhau Trong môi trường này, một số ứng dụng có thể được cân bằng giữa các yếu tố để giảm giá cả truyền thông, giảm việc tính toán khi truyền dữ liệu Lựa chọn sự bảo đảm phụ thuộc theo các ứng dụng yêu cầu, phù hợp với khả năng của các host và các thiết bị mạng Mục đích để hỗ trợ cho các mạng hỗn hợp và với các chủng loại thiết bị mạng khác nhau Quản lý khóa Internet hỗ trợ nhiều kiểu thay đổi bao gồm nhiều phương thức truyền khác nhau Một số thay đổi có thể cung cấp khả năng bảo vệ nhất quán và cung cấp PFS, một số ví dụ [36] Để có tính đa dạng và tiếp cận linh hoạt cần cung cấp một khả năng biến đổi trong khi truyền và gắn nhóm theo giao thức trao đổi khóa Diffie-Hellman, tất cả được xem xét kỹ hơn trong [22, 46]

3 Cơ chế tự động xác thực sự thay đổi, như chia sẻ khóa, hạ tầng khóa công khai ( public key infrastructure (PKI) và các khóa công khai hỗ trợ các mô hình chứng thực khác nhau Tại một thời điểm các thủ tục cần thiết để hình thành khóa cần được thay thể trong kiến trúc bảo mật Internet [32] có một hạ tầng quản lý khóa, ISAKMP định nghĩa tập đối tượng trừu tượng của sự thay đổi, được tổ chức bởi các chế độ và các pha, cung cấp các cấp độ lựa chọn bảo vệ [40, 36] Để cung cấp các giải pháp linh hoạt cho quản lý khóa Internet, ISAKMP cho phép thay đổi xác thực

tự động trong một môi trường luôn luôn biến đổi, đồng thời tham số hoá trong một vùng rõ ràng (domain of interpretation (DOI)), trong trường hợp các máy xác định khóa riêng biệt được định nghĩa thông qua việc chỉ rõ không gian tên, chính sách,

cơ chế thanh toán và các lựa chọn cho sự thay đổi mới Trong cách này ISAKMP được thiết kế để có thể mở rộng được cho người sử dụng khác nhau và cho phép

chuyển tiếp giao thức trao đổi khóa và truyền thông bảo mật Mặc dù độ mềm dẻo của cách tiếp cận này có thể dẫn tới nhiều phức tạp hơn, đôi khi còn trở nên lỏng lẻo hơn cho công tác bảo mật, các tác giả ISAKMP khuyến cáo người sử dụng ISAKMP xây dựng hạ tầng quản lý khóa riêng cho người mới sử dụng cũng như việc quản lý khóa nhóm, đó là cách tốt nhất cho việc truyền và quản lý các khóa ứng dụng [40] Người mới sử dụng được thực hiện thông qua việc chỉ rõ trong DOI

4 Chuyển tiếp đường dẫn tới các máy bảo mật mới, cũng như cách truyền bảo mật mới cùng với sự thay đổi các sự kiện mới

Quản lý khóa Internet theo cách thức ISAKMP, hỗ trợ chuyển tiếp các đường dẫn, như vậy giải thuật mới có thể được đưa ra thay thế cho các phương thức cũ [40,

22, 36, 46]

5 Một hạ tầng quản lý khóa đơn để hỗ trợ cho việc xuất bản khóa dạng SA theo các mức độ hệ thống ISAKMP để đạt được độ linh hoạt bằng cách tổng quát hoá hơn là các giao thức xác định khóa, khi quản lý SA và các khóa không đúng với các khóa xuất bản Các khóa được đóng gói dạng tổng quát [40, 32,30,47], các thông tin về khóa cũng như chu kỳ sống của khóa, các chính sách bảo mật, như vậy

sẽ cho phép hình thái diện mạo cũng như các thay đổi cần thiết cho các ứng dụng và môi trường trong kiến trúc bảo mật Internet ngày nay, tuy nhiên, quản lý khóa SA management là dạng ngang hàng (peer to peer) cụ thể theo mô hình dưới đây

Hình 2.2: Unicast SA được định nghĩa trong ISAKMP

SA được định nghĩa phức tạp trong kiến trúc bảo mật Internet [32] và được định nghĩa bới các chỉ số biên bảo mật (security parameter index (SPI) [32, 30]) Các SA được thiết lập theo các chính sách cục bộ [32, 47], sự trao đổi được thiết kế

để bảo vệ chống lại cách tấn công chống lại các khóa cơ sở, như kiểu người canh cửa giữa là ngắt kết nối, lặp lại truyền, các dịch vụ gắn kèm (man-in-the-middle, connection hijacking, replay/reflection, and DoS [40]) Mặc dù đầu tiên có 3 kiểu tấn công là các vấn đề chính trong tự động trao đổi khóa xác thực, bảo vệ chống lại DoS sử dụng cơ chế tự động cookie [30] giữa các thực thể ngang hàng, xuất hiện trong phần header của ISAKMP header cho tất cả sự thay đổi [40, 22]

Chúng ta đảm bảo rằng các thuộc tính được đưa vào để quản lý khóa nhóm là rất tốt, vấn đề tiếp theo là quản lý khóa nhóm cần đưa thêm các điểm cần thiết để làm tốt hơn theo 5 điểm đã nêu ở đây

2.3 Các yêu cầu an toàn trong quản lý khóa nhóm

Trong các phần trước cho thấy một cách rõ ràng có rất nhiều yêu cầu và các đặc trưng thiết kế cho việc quản lý khóa Internet là quản lý khóa nhóm Trên thực tế rất nhiều các các khoản chi phí phải trả, các vấn đề trao đổi khóa và các biến đổi được tìm thấy trong ISAKMP và IKE có thể trở nên phù hợp cho quản lý khóa nhóm

Rất nhiều giao thức quản lý khóa nhóm và các giải thuật, có thể thấy nhiều trong

GKMP [24, 25], LKH [54], cây chức năng chọn đường (one-way function tree (OFT)) [1], GSAKMP [26], NARK [7] và việc quản lý khóa Multicast với các biến đổi tuần tự khóa (management with arbitrarily revealed key sequences (MARKS) [6]) đảm bảo tính duy nhất của khóa cho các thành viên, điều đó đã thiết lập các thủ tục cần thiết trong việc truyền point-to-point với một khóa server Mục đích của việc xác thực các thành viên của nhóm, khởi tạo nó với các khóa, khóa nhóm phải được kéo theo bởi một cách riêng biệt từ client tới server Các thành viên của nhóm phải tính toán off-line trong khi cập nhật các khóa kéo theo và được khởi tạo lại (hoặc yêu cầu khởi tạo lại bởi KD) trong một chế độ bảo mật, có thể là các giao thức point-to-point Việc sử dụng không thay đổi IKE (với IPsec DOI), tuy nhiên,

có thể ngoài các yêu cầu cần được hỗ trợ phân phối khóa nhóm (chẳng hạn: nới cần

mở rộng khóa đưa tới thành viên bởi KD, thêm vào đó cần phân phối các chính sách hơn là việc điều chỉnh các chính sách khóa và việc sử dụng truyền thông Multicast

để đặt việc cập nhật khóa để ban hành khóa thay đổi Rất cần thiết để refresh các khóa trong phạm vi cuối mỗi thời điểm chu kỳ sống bảo mật chúng và kết quả thay đổi các khóa khi thay đổi các thành viên của nhóm Một vài giải thuật được đưa ra

để sửa đổi hoặc thay khóa [1, 54, 26, 6]

Một khối xây dựng chức năng quản lý khóa nhóm linh hoạt sẽ hỗ trợ các giải thuật biến đổi linh hoạt, để tiếp nhận chuyển tiếp khi các giải thuật mới được phát triển, hoặc các sai lầm tồn tại trong giải thuật không được bao quát hết

Sử dụng dịch vụ Multicast để đẩy các khóa cập nhật và các thông điệp từ các

KD để các thành viên yên tâm về gánh nặng của việc các thành viên kết nối tới mỗi

thành viên riêng lẻ để thay đổi khóa hoặc cấu hình lại nhóm Trong cách này, quản

lý khóa nhóm có thể phủ số lượng lớn cho một số lượng lớn các thành viên Sự tin tưởng này để triển khai cho chính mô hình quản lý khóa nhóm trong Multicast phù hợp với các ứng dụng biến đổi Các thuộc tính này có thể trở nên thừa không ảnh hưởng đến các phiên làm việc, nơi các thành viên được khóa bởi một khóa và không bao giờ gặp lại trong cùng một phiên Ngoại trừ các phiên quyên góp hoặc trong các phiên cần được sự thay đổi khóa, căn bản thiết kế ứng dụng Multicast tốt sẽ bảo vệ

KD từ mục tiêu mang tính định kỳ và có khả năng đồng bộ hoá các yêu cầu trên một phạm vi rộng lớn các thành viên kéo theo các khóa

Không giống như các nhóm tích hợp thành các vùng rộng lớn, chu kỳ sống ngắn, các nhóm động là các đặc tính của quan hệ các thành viên trong nhóm nhỏ có thể cần quản lý khóa nhóm với thời gian rât nhỏ nó có thể tạo và thêm mới thành viên của nhóm Tuy vậy quản lý khóa nhóm có thể sửa đổi có hiệu quả cho phạm vi rộng lớn, an toàn nhóm để hỗ trợ cho phạm vi lớn các thành viên Trong khi không ngăn được các huỷ bỏ, sửa đổi, khởi tạo nhanh cho các nhóm nhỏ hơn điều đó được dàn xếp trong truyền thông theo nhóm Cần được hỗ trợ tổ chức thực hiện và móc nối cần thiết cho các ứng dụng khác nhau là nền tảng cho quản lý khóa Internet điều

đó được chia sẻ bởi quản lý khóa nhóm

Quản lý khóa nhóm, bởi vậy, sử dụng tập khác nhau các thuộc tính trừu tượng nhiều hơn trong ISAKMP và IKE Tuy nhiên việc sử dụng các thuộc tính trừu tượng có thể được xây dựng từ các đặc tính trừu tượng của ISAKMP, nơi GSA chứa đựng các thuộc tính kiến trúc bảo mật Internet (Internet Security Architecture SA), điều đó được định nghĩa ngắn gọn trong việc đóng gói các chính sách và khóa [32]

cụ thể như sau:

Một kiến trúc unicast có các lụa chọn, như nguồn và đích địa chỉ truyền

Một kiến trúc unicast có các thuộc tính như: SPI hoặc cặp cookie và các định danh

Một kiến trúc có chính sách bảo mật: các giải thuật, các chế độ, chu kỳ sống của khóa, độ rộng khóa sử dụng cho xác thực hoặc độ tin cậy

Một kiến trúc unicast có các khóa: xác thực, mã hoá và chữ ký khóa

Trong phần sau đưa ra kiến trúc tổng quan GSA bao gồm các thuộc tính mở rộng của SA như:

Một GSA có các thuộc tính chính sách nhóm chẳng hạn: kiểu ký tin tưởng cần được đưa ra cho các thành viên của nhóm, dựa trên đó nhóm sẽ đưa ra khóa mới khi có thành viên mới tham gia còn gọi là ‗‗backward rekey‘‘ hoặc nếu nhóm thành viên sẽ đưa ra khóa mới khi các thành viên rời khỏi nhóm, được gọi là ‗‗forward rekey‘‘ Một GSA có các SA cũng như các thuộc tính Điểm cuối cùng một GSA bao gồm nhiều SA, được mô tả đầy đủ hơn trong phần sau,

Tóm lại:

Để miêu tả các thuộc tính quản lý khóa nhóm Internet theo các tiêu chí sau:

1 Gồm năm thuộc tính quản lý khóa Internet được mô tả trên

2 Hỗ trợ chuẩn bảo mật IETF (Secure Multicast Reference Framework [47]),

có một KD để điều khiển truy nhập tới nhóm thành viên gửi và nhận, theo nhóm các chính sách phân phối Điều này tham chiếu nền tảng đã được công nhận bởi tổ chức MSEC đang làm việc nhóm trong IETF

3 Hỗ trợ các ứng dụng Multicast IP, nơi mà có thể một hoặc nhiều người gửi tới một nhóm, mỗi thành viên có một SA duy nhất trong nhóm hoặc chia sẻ SA trong nhóm

4 Hỗ trợ cho cả người nhận khởi tạo chính sách khóa và cả KD được khởi tạo, đẩy theo luồng, sử dụng các giải thuật thay đổi khóa

5 Khả năng lựa chọn các cấp độ thực hiện cho quản lý khóa nhóm cho phép cân bằng sự ngầm định khởi tạo, khởi tạo lại tình huống phức tạp, các thông điệp chàn bộ đệm, các kết nối ngầm, giải phóng ngầm và tốc độ thực hiện liên quan đến bảo mật cũng như quá trình truyền

Yêu cầu cao hơn là backward rekey và forward rekey Thao tác thay đổi khóa cần được đảm bảo các thông điệp được gửi tới nhóm không thể truy cập được bởi các thành viên trong nhóm đã bị KD thu hồi Một vài ứng dụng yêu cầu khi một thành viên tham gia nhóm bị từ chối quyền truy cập thông điệp sẽ được gửi cho nhóm trước khi nó trở thành thành viên của nhóm Chúng ta gọi trường hợp này là forward rekey, khi một khóa thay đổi được nhắc bởi một thành viên rời khỏi nhóm trường hợp này gọi là backward rekey, khi đổi khóa được thiết lập khi thành viên mới tham gia nhóm Thay khóa là hình thức sủa đổi hay còn gọi là ‗‗perfect forward confidentiality‘‘ và ‗‗perfect backward confidentiality,‘‘một cách rõ ràng Các thuộc tính này được tham chiếu tới ‗‗forward/backward secrecy,‘‘

‗‗forward/backward security‘‘ và ‗‗forward/backward access control‘‘ mô tả trong [1, 26, 23]

2.4 Quản lý kiến trúc an toàn nhóm (Group Security Architecture GSA)

-Thật dễ dàng nhận ra rằng việc gắn kết các yếu tố an toàn trong quản lý khóa nhóm càng trở nên phức tạp hơn so với quản lý khóa unicast, nhất là khi số lượng tham gia ngày càng nhiều hơn

Ngược lại, lần sau cùng nhất thiết lập một kiến trúc an toàn quản lý khóa để bảo vệ cho kiến trúc an toàn ứng dụng (trong trường hợp trao đổi khóa Internet –IKE là dùng chung giao thức IPSec), khi đó sẽ đủ nhỏ để 2 kiến trúc an toàn SA cần khóa để xử lý ứng dụng Internet, vậy thì số lượng nhỏ nhất khi đó là 3 thành phần

Có sự kéo theo (pull) trong mô hình SA giữa các thành viên nhóm và KD, đặt các

SA giữa KD và tất cả các thành viên của nhóm và mỗi thành phần SA bảo vệ dữ liệu ứng dụng từ các thành viên là người gửi tới các thành viên là người nhận Trên thực tế, mỗi người gửi tới nhóm có thể sử dụng một khóa duy nhất cho dữ liệu mà

nó muốn gửi tới theo phân đoạn SA Mặc dù, có thể có nhiều hơn các SA có trong nhóm người gửi 3

Trong phần tiếp theo đưa ra mô hình GSA model và đặc tả các thành phần trong SA là điều kiện cần thiết cho việc dàn xếp giữa các thành viên và KD Bước tiếp theo các thành viên bắt đầu tham gia vào một nhóm Multicast, được cấp các biến riêng từ các thực thể tin cậy bên trong nhánh hoặc bên ngoài nhánh Điểm này trong unicast là không thể thiếu được và được đóng gói trong phần định nghĩa GSA

3 Một số tác giả tham chiếu ― pull ― SA giống như ‗‗registration‘‘ SA, và ―push‖ SA giống

‗‗rekey‘‘ SA

2.4.1 Mô hình GSA

Để đi đến định nghĩa GSA được tích hợp trong 3 loại dựa vào các kiểu SA [20] Kiến trúc này được lựa chọn bởi các tác giả sáng tạo ra GSA trong môi trường Multicast bằng cách tham chiếu đến chuẩn IETF (Internet Engineering Task Force ) (Framework [19]) Cần phải có sự sửa đổi giữa một KD và một nhóm (cho người gửi, người nhận hoặc cả hai) và giữa các thành viên Trong khi tham chiếu Framework, KD được mang kèm các điều khiển truy nhập tới khóa nhóm, với chính sách phân phối tới các thành viên client hoặc cho các thành viên tương lai và với sự phổ biến khóa nhóm tới thành viên gửi và nhận Kiến trúc này áp dụng chung trong rất nhiều môi trường quản lý khóa nhóm ([1, 54, 26, 25])

Có hai SA được thiết lập giữa KD và các thành viên Thứ nhất tham chiếu đến Category 1 SA (hay còn gọi SA1), thứ hai là Category 2 SA (hay SA2) Thêm vào

đó sẽ có SA thứ 3 được thiết lập giữa các thành viên gửi và nhận còn gọi Category 3

SA (hay SA3) Ba SA được thể hiện trong hình dưới đây

Hình 2.3: Định nghĩa GSA

Các khái niệm SA1, SA2 và SA3 được sử dụng đơn giản theo phần đưa ra sau (khái niệm pull/registration SA, push/rekey SA, và data security SA đã được sử dụng)

SA1 được khởi tạo bởi một thành viên để ―pull‖ thông tin GSA từ KD Để làm được điều này thành viên gửi yêu cầu tham gia thành viên nhóm an toàn, hoặc có các khóa GSA được khởi tạo sau khi mất kết nối từ nhóm (chẳng hạn khi máy tính

bị tắt trong khi thao tac đổi khóa) Thông tin GSA sẽ được ―pulled‖ xuống từ các

KD, bao gồm: SA, Keys và các chính sách được sử dụng để đảm bảo cho việc truyền dữ liệu giữa thành viên gửi và nhận (đây chính là SA3 )

Lưu ý rằng SA3 là một danh sách các SA, có thể bao gồm nhiều SA được thiết lập giữa thành viên gửi và nhận cuối cùng Có thể tồn tại chẳng hạn một SA của Category 3 trong đó tất cả người gửi chia sẻ chung 1 khóa và kết nối với thông tin cần gửi

Lựa chọn khác, có thể một hoặc nhiều SA trong SA3 là duy nhất tới người gửi

cụ thể Một SA3 có thể được thiết lập lại hoặc nó có sự thay đổi khóa thông qua thao tác đổi khóa xảy ra thông qua SA2 (áp dụng cho một số nhóm nhỏ hơn)

Theo cách này mục đích để khởi tạo sử dụng SA1 để đảm bảo lấy các SA2 và SA3 từ KD về các thành viên SA2 được sử dụng cho các thông điệp điều khiển được gửi bởi KD, trong khi SA3 được sử dụng cho thông điệp dữ liệu (chẳng hạn lưu lượng hoặc nội dung) từ người gửi tới người nhận Đưa vào trong thông điệp điều khiển là các thông tin cập nhật hoặc thay thế trong SA3 Do đó chúng ta có thể nói rằng SA2 được sử dụng để cập nhật lại SA3, khi nó được tiên đoán trước sẽ có một vài người sử dụng SA2 so với SA3 (chẳng hạn: SA3 được sử dụng cho một khối lượng luồng dữ liệu media) Thuận theo cách tự nhiên, chính sách bảo mật của SA2 phải đủ mạnh bằng hoặc hơn so với SA3 Hai phần tùy chọn cuối cùng là khả năng sẵn sàng cho việc cập nhật SA2 khi có sự thay đổi SA2 có thể được cập nhật thông qua SA1 một lần nữa (unicast), hoặc SA2 cũ có thể được sử dụng để cập nhật cho SA2 mới Điều này trái với tùy chọn thực hiện theo [20], khi định nghĩa GSA phải đảm bảo cho các ứng dụng biến đổi trong phạm vi rộng

Lưu ý rằng các ứng dụng cập nhật khóa xảy ra bên trong luồng dữ liệu (sử dụng SA3 để bảo vệ), định nghĩa GSA yêu cầu SA2 phải được khai báo là giá trị null (điều đó khác với việc không tồn tại) Trong một vài trường hợp ứng dụng chỉ đơn giản dạng PPV(Pay-per-view), tất cả các thông tin SA cần cho các session có thể được phân phối tại thời điểm đăng ký hoặc sự lựa chọn session (chẳng hạn thông qua SA1) Thay khóa và khởi tạo lại khóa có thể không cần thiết, vì vậy SA2

là null Hầu hết các ứng dụng gắn việc thay đổi khởi tạo unicast với phân phối

Multicast để thay khóa Để góp các nhóm với các khóa được thay đổi khi các thành viên có sự thay đổi, khi đó một SA2 cần thiết để khởi tạo lại SA3

Lưu ý rằng unicast SA được sử dụng để bảo vệ các thành phần khác của GSA (chính là 2 loại SA còn lại) Như vậy, các SA này chính là sự quyết định và là một phần không thể tách rời với hai SA còn lại được định nghĩa trong GSA Từ các khối đưa ra trong KD, có rất nhiều Category1 SA duy nhất có các thành viên (các người gửi, người nhận) trong nhóm Như vậy sẽ có lợi ích cho một số ứng dụng và như vậy Category1 SA có thể được sử dụng theo yêu cầu, ngược lại Category 2 và Category 3 SA được thiết lập sau cùng của chu kỳ các session chúng hỗ trợ Lưu ý rằng một vài kiến trúc phân phối KDs có thể được phát triển theo hướng leo thang, như vậy sẽ dàn trải số lượng các SA qua KDs này

Category 2 SA (SA2): Một SA được yêu cầu cho truyền Multicast cho các thông điệp điều khiển, quản lý khóa (không trực tiếp) từ KD tới tất cả các thành viên của nhóm Như vậy, SA này được nhận biết bởi KD và tất cả các thành viên của nhóm Các SA này không được dàn xếp khi tất cả các thành viên của nhóm phải chia sẻ nó Như vậy KD phải được xác thực nguồn và hành động như một điểm nền móng để liên hệ các thành viên của nhóm để đạt được các SA này Từ việc sắp xếp mỗi thành viên cụ thể trong nhóm (bao gồm KD và tất cả các thành viên), có Category 2 SA ở cuối của nhóm Lưu ý rằng điều này cho phép khả năng các KD triển khai nhiều Category 2 SA cho các mục đích quản lý bảo mật khác Ví dụ: có thể một thông điệp điều khiển đoạn găng/tình huống khẩn cấp và thông điệp khác điều khiển các luật/ các thứ tự ưu tiên

Category 3 SA(SA3): Một hoặc nhiều các SA được yêu cầu cho truyền Multicast các thông điệp dữ liệu không trực tiếp từ người gửi tới các thành viên khác của nhóm Tương tự như Category 2 SA, bất chấp các thành viên khởi tạo category thứ 3 này của các SA, các SA này không được thương lượng Hơn thế nữa tất cả các thành viên của nhóm thu được nó từ các KD Chính các KD này không sử dụng category của SA khi nó không tồn tại, điều đó nói lên rằng KD không truyền được thông điệp dữ liệu Khối người nhận cuối mỗi Category 3 SA cho thành viên gửi (một hoặc nhiều) trong nhóm Điều đó cho phép có thể gắn kèm nhóm IDs (GID) trong truyền đóng gói dữ liệu từ người gửi trong nhóm Có một thành viên có thể có hiệu quả tới các thành viên của Category 3 SA và sử dụng chung với GIDs Mỗi người gửi trong nhóm có thể truy nhập duy nhất Category 3 SA, kết quả

là mỗi người nhận phải sửa đổi rất nhiều trong Category 3 SA khi có rất nhiều người gửi trong nhóm

Nhóm đầu vào triển khai một Category 3 SA đơn lẻ cho tất cả người gửi với cùng việc sử dụng GIDs Mọi người nhận sẽ phải lọc dựa trên GIDs, chỉnh sửa chỉ trên một Category 3 SA

Có thể kết hợp hai lựa chọn trên

2.5 Phân lớp bài toán quản lý khóa nhóm

Trước khi kết thúc chương này, chúng ta đưa ra việc phân lớp phạm vi các vấn

đề quản lý khóa Trong phần trước, quản lý khóa nhóm liên quan đến quản lý khóa nhóm hoặc gọi tắt khóa nhóm TEK trong môi trường động nhiều người tham gia, có thể trong chính dịch vụ Multicast để trợ giúp cho công việc quản lý khóa nhóm Một vài thành phần có quan hệ với nhau hoặc trong chính thành phần đó khi nhìn nhận trong các vấn đề đóng:

Kiến trúc (Architecture): khái niệm kiến trúc tham chiếu đến quan hệ, cách sắp xếp các khóa nhóm (TEK) và các khóa khác (KEKs) hỗ trợ an toàn cho việc giao nhận khóa nhóm Cách tổ chức này ảnh hưởng đến phạm vi và mật độ các thành viên tham gia, tính động của thành viên có liên quan, mô hình luồng dữ liệu và các thành phần khác

Các giao thức (Protocols): Khái niệm giao thức được sử dụng để miêu tả tập các thủ tục, sự trao đổi thông điệp và đóng vai trò trọng tài quyết định hành vi của các thực thể hỗ trợ một nhóm (servers) và các thành phần cụ thể của nhóm (hosts)

Giải thuật (Algorithm): Khái niệm giải thuật được sử dụng để miêu tả phương thức để tổ chức và cập nhật hỗ trợ khóa, được sử dụng để quản lý khóa nhóm Khái niệm chính xác hơn là xác định khóa nhóm hoặc giải thuật quản lý Các khóa hỗ trợ được tổ chức trong một LKH (hoặc cây khóa), mỗi thành viên giữ các khóa chắc chắn từ cây khóa logic Sự thay đổi trong các thành viên của nhóm thường yêu cầu khóa nhóm mới và chuyển giao cho các thành viên còn lại của nhóm Hoàn thành bằng cách sao chép mã hoá của khóa nhóm dưới một tập các khóa chứa trong cây khóa Khi một thành viên chỉ có 1 tập con của các khóa bên trong cây khóa Các thành viên sẽ giải mã các thông điệp được gửi đi bởi các dự định KD cho các thành viên (tên, được mã hoá bằng KD sử dụng khóa tương ứng bên trong cây khóa) Khi các thành viên thay đổi, cây khóa được cấu hình lại, sau đó là giải thuật sắp xếp lại cây Đối tượng quan tâm là trung tâm quản lý khóa nhóm

Các chính sách (Policies): Các luật cần được điều khiển hành vi của các thực thể trong khi khởi tạo nhóm, phân phối khóa nhóm, sự biến đổi các thành viên trong nhóm, các tình huống mới phát sinh và các vấn đề khác

2.6 Tóm lại

Trong chương này và chương tiếp theo nghiên cứu sâu hơn về quản lý khóa nhóm Cập nhật được từ tổ chức tiêu chuẩn Internet Engineering Task Force (IETF) tham chiếu cho nền tảng phát triển truyền thông internet Trong chương này đã mô

tả mô hình đặc biệt trong quản lý khóa nhóm, sự ảnh hưởng giữa các thực thể khác nhau Mô hình quản lý khóa nhóm được định nghĩa bởi GSA sẽ miêu tả kỹ hơn ở chương sau Dựa trên cơ sở miêu tả yêu cầu của quản lý khóa nhóm, xem xét lại yêu cầu quản lý khóa unicast được đưa ra Năm yêu cầu cho quản lý khóa unicast được xem xét sẽ là cơ sở cho yêu cầu quản lý khóa nhóm Bảo vệ tránh sự biến đổi có thể tấn công khi thay đổi khóa Lựa chọn mức độ bảo mật để bảo vệ, thay khóa theo cơ chế xác thực tự động, phân phối khóa theo luồng thống nhất dựa trên nền tảng quản

lý khóa

Cốt lõi của chương này là việc định nghĩa GSD cho Multicast, bao gồm sự kết hợp của 3 categories SA Định nghĩa GSA cụ thể hơn trong [20] cho phép sử dụng phức tạp hơn các thành phần AS tạo ra một GSA

Trong chương này giới thiệu mục đích bên trong của vùng quản lý khóa nhóm, định danh tên, kiến trúc, giao thức, giải thuật và các chính sách Chương sau sẽ nghiên cứu chi tiết hơn về quản lý khóa nhóm

Chương 3: CÁC THUẬT TOÁN QUẢN LÝ KHÓA

NHÓM

Tính riêng tư là một yêu cầu của một vài ứng dụng truyền thông nhóm chẳng hạn các cuộc hội thảo, tại vị trí điều khiển truy nhập yêu cầu các ứng dụng như phân phối hạn mức tài nguyền qua luồng Internet Cả hai việc đảm bảo tính riêng tư và điều khiển truy nhập có thể tạo nên có hiệu quả bằng việc mã hoá dữ liệu nhóm và phân phối khóa nhóm tới các thành viên hiện thời Các thành viên của nhóm cần lưu một khóa chung cho việc xác thực nhóm

Trong chương trước chúng ta đã thảo luận về GSA, giao thức phân phối khóa nhóm

và kiến trúc có hiệu quả cho quản lý khóa nhóm Chúng ta bàn đến chủ đề phân phối khóa nhóm và mức giải thuật thay khóa Khóa nhóm phải được thay đổi theo thời gian do các nguyên nhân yêu cầu biến đổi Mục đích đầu tiên là giữ tính bảo mật trong quá trình thay khóa, điều đó cho thấy rằng để sử dụng khóa chắc chắn theo thời gian, hoặc để bảo mật chắc chắn số lượng dữ liệu

Yêu cầu thứ hai thay khóa là làm cho rõ ràng hơn các nhóm Xem xét các nhóm, quyền của các nhóm muốn không cho phép các thành viên tham gia nhóm có thể giải mã được dữ liệu truyền qua nó và các bộ phận của nhóm có thể giải mã được dữ liệu trong tương lai Để làm được như vậy, người gửi hoặc trung tâm GCKS phải thay đổi khóa nhóm tại các thời điểm thay đổi thành viên Lược đồ thay khóa nhóm, bảo mật khóa nhóm cụ thể cho mỗi khi thay đổi thành viên của nhóm Một cách rõ ràng hơn, chẳng hạn lược đồ máy tính và các phương thức truyền thông phức tạp, điều đó tương ứng với kích thước của cỡ nhóm Trong chương trước, chúng ta đã thảo luận một vài kiến trúc quản lý nhóm bảo mật, cho ví dụ, Ilus đã đề xuất phân cấp thành các nhóm nhỏ hơn để thay khóa hiệu quả hơn Giá của việc thêm hạ tầng, lược đồ này giới hạn đối tượng thay khóa khi có thành viên thay đổi và không ảnh hưởng đến nhóm con thay vì cho cả nhóm Trừ khi các nhóm con có kích thước rất nhỏ, lược đồ thay khóa tỏ ra không hiệu quả cho nhóm con thay khóa Mức độ phân tích và thiết kế giải thuật là chủ đề chính trong chương này Chúng ta đề xuất giải thuật quản lý khóa nhóm và tính phù hợp với các kịch bản ứng dụng cụ thể

Đầu tiên chúng ta xem xét các cách áp dụng GCKS cho việc thay khóa tại thời điểm

ấn định khi khởi tạo chu kỳ sống của nhóm và sự nhận biết được thông tin thay khóa của các thành viên khi có thành viên mới tham gia trong tương lai

MARKS (Multicast Key Management Using Arbitrarily Revealed Key Sequences)

là một cơ chế tự động tỏ ra rất có hiệu quả trong việc phân phối khóa tới các nhóm Các thành viên nhận các hàm ngẫu nhiên kết hợp với chính khóa của đối tượng để có thể sinh

ra khóa bảo mật nhóm được sử dụng trong suốt thời kỳ tham gia của nhóm Ứng dụng thương mại chẳng hạn TV truyền qua vệ tinh với yêu cầu người dùng phải trả một khoản phí trước khi xem chương trình (trên giờ hoặc số lượt xem), có thể sử dụng giải thuật này

Tiếp theo chúng ta xem xét các ứng dụng mà các thành viên gia nhập nhóm hoặc rời khỏi nhóm ở thời điểm bất kỳ Để đảm bảo tính bảo mật trong quân sự thì mức độ truyền thông yêu cầu bảo mật rất cao Trung tâm GCKS thực hiện thay khóa sau khi thay đổi mỗi thành viên nhằm sửa đổi chặt chẽ, chuyển tiếp và tiếp nhận lại điều khiển truy nhập kịp thời Tuy nhiên các ứng dụng thương mại theo định kỳ hoặc xử lý theo đợt các thành viên khi thay đổi sao cho hiệu quả với sự cung cấp thay khóa ngay để từ chối một thành viên rời khỏi nhóm là một ví dụ Như vậy chúng ta cần sinh ra giải thuật quản lý khóa nhóm và sinh khóa nhóm có thể hiệu quả theo thời gian thực hoặc theo định kỳ nếu thấy cần thiết

Công nghệ chung trong một vài đề xuất lược đồ quản lý khóa nhóm là chia các nhóm thành các nhóm con, mỗi nhóm nhỏ vậy sẽ được trang bị khóa bảo mật, và phân phối khóa đã được bảo mật đó với khóa nhóm con Một vài đề xuất sinh ra cơ chế cập nhật tự động cho tập con các khóa trong quá trình thay khóa, một số quan điểm khác thì không Thay khóa là trạng thái trong lược đồ đó được cập nhật tập con các khóa Theo cách hiểu khác trạng thái đầy đủ lược đồ thay khóa sử dụng các khóa đã được gửi khi truyền thông điệp khóa để bảo vệ các thông điệp thay khóa hiện thời Thuộc tính này yêu cầu giải phóng truyền thông điệp thay khóa, nếu ứng dụng đó không cần giải phóng truyền dữ liệu

Các giải thuật quản lý khóa nhóm khá phổ biến và có từ rất sớm là LKH, chỉ định mỗi thành viên tại vị trí lá trong cây khóa logic cho phân phối khóa Mỗi nút trong của cây đại diện cho nhóm con chứa tất cả các nút lá là thanh viên Mỗi thành viên hiểu các khóa của tất cả các nhóm con thuộc nó sở hữu, hoặc tất cả các nút trong đường dẫn tới gốc trong cây khóa Khóa của nút trong được bảo vệ bởi các khóa của cây con của nó trong quá trình thay khóa Khi có thành viên tham gia hoặc rời bỏ, GCKs cần thay đổi và phân phối khóa với độ phức tạp thuật toán O(logn) cho nhóm có cỡ n Gọi lại giải thuật thay khóa yêu cầu GCKS để bảo mật và truyền khóa nhóm sẽ có độ phức tạp thời gian tính toán cỡ O(n)