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.
2.4.2 Định nghĩa GSA
Một GSA bao gồm sự tích hợp của ba loại SA. Ba loại SA tương ứng với ba kiểu truyền thông. Hình trên cho ta cái nhìn trực quan về dạng kiến trúc này.
Loại SA1: nhằm đáp ứng cho yêu cầu truyền thông unicast giữa KD và một thành viên của nhóm (có thể là một người gửi hoặc nhận). Khi tham chiếu chuẩn (IETF Reference Framework), thực thể KD phải trả lại điều khiển truy nhập tới các khóa nhóm, kèm theo sự phân phối các chính sách tới các thành viên (hoặc các thành viên trong tương lai), với khóa nhóm được phổ biến tới các thành viên gửi và nhận. Sử dụng điều này cho cho một unicast SA như là một điểm bắt đầu cho việc quản lý khóa chung của một thành viên trong môi trường quản lý khóa nhóm.
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