Phân tích các giao thức con của Kerberos-role

Một phần của tài liệu Nghiên cứu phát triển các giải pháp kiểm soát truy nhập đảm bảo an toàn an ninh cho mạng máy tính191 (Trang 67 - 71)

♦ Giao thức lấy vé dịch vụ:

(1 ) A → P : (A, B, n) (thực hiện trên SSL )

(2 ) P → S : ({TP , P}KPS , {P, S, role(P), TPS , KPS }KS , {A, B, role(A), n}KPS ) (3 ) S → P : {{KAB , {A, B, role(A), TAB , KAB}KB , n}KA}KP

(4 ) P → A : {KAB , {A, B, role(A), TAB , KAB}KB , n}KA

Dạng hình thức của các thông báo trong giao thức nh sau, trong đó thông báo (1 không thuộc vào đặc tính logic của giao thức: )

(1 ) A → P : (A, B, n)

(2 ) P → S : ({TP , P KPSS}KPS ,{TPS , PKPSS, role(P)}KS , {A, B, role(A),n}KPS) (3 ) S → P : {{A KABB, {TAB , AKABB, role(A)}KB , n}KA}KP

(4 ) P → A : {AKABB, {TAB , AKABB, role(A)}KB , n}KA

Hệ quả 2.1: Với giả thiết ( ) thì giao thức lấy vé dịch vụ hợp logic và đạt đ ợc các * mục tiêu xác nhận :

A |≡≡≡≡≡ AKABB, A {TAB , AKABB, role(A)}KB và A . n

Chứng minh: Đây chính là các bớc giao thức từ (1 đến (4 của giao thức ) ) Kerberos-role trờng hợp tổng quát. Theo chứng minh ở Định lý 2.1 thì giao thức lấy vé dịch vụ hợp logic và đạt đợc các mục tiêu xác nhận nêu trên.

Hệ quả 2.1 cho thấy A nhận đợc khoá phiên KAB và vé mã hoá {ticket(A, }KB) B để giao tiếp với B. Vé này chứa role(A) là vai của A để B thực hiện kiểm soát truy nhập dựa trên vai đối với A.

♦ Giao thức yêu cầu dịch vụ:

(1 A B : ({T) → A , A}KAB , {A, B, role(A), TAB , KAB}KB , { M1, n}KAB ) (2) B → A : ({n}KAB , M2)

M1 là một yêu cầu dịch vụ do A gửi cho B. Dạng hình thức của các thông báo là: (1 A B : ({T) → A , AKABB}KAB , {TAB , AKABB, role(A)}KB ,{M1, n}KAB)

Hệ quả 2.2: Với giả thiết ( ) thì giao thức yêu cầu dịch vụ hợp logic và đạt đ ợc * các mục tiêu xác nhận :

B |≡≡≡≡≡ AKABB, B |≡≡≡≡≡ A|≡≡≡≡≡ AKABB, B |≡≡≡≡≡ role(A), B |≡≡≡≡≡ A |∼. M1.

Chứng minh: Giao thức yêu cầu dịch vụ chính là các bớc giao thức (5), (6) của giao thức Kerberos-role trờng hợp tổng quát. Theo chứng minh ở Định lý 2.1 thì giao thức yêu cầu dịch vụlà hợp logic và đạt đợc các mục tiêu xác nhận nêu trên.

Hệ quả 2.2 cho thấy B nhận đợc khoá phiên KAB và yêu cầu M1 từ A; B tin rằng A có vai role(A) nên thực hiện kiểm soát truy nhập căn cứ vào vai role(A) của A. Nếu A đợc phép truy nhập B thì B sẽ đáp ứng yêu cầu M1 của A. Còn nếu A không đợc phép truy nhập B thì A nhận đợc thông báo từ chối dịch vụ.

♦ Giao thức đăng ký định danh:

(1 ) A → P : (A, p, n) (thực hiện trên SSL )

(2 ) P → S : ({TP , P}KPS ,{P, S, role(P), TPS , KPS}KS , {A, p, role(A), n}KPS) (3 ) S → :P {{ }Kn A}KP

(4 ) P → : {A n}KA

n là mã hiệu do A tạo ra ban đầu, p là mật khẩu của thành phần máy khách A. Dạng hình thức của các thông báo trong giao thức nh sau, trong đó thông báo (1 không thuộc vào đặc tính logic của giao thức: )

(1 ) A → P : (A, p, n)

(2 ) P → : ({TS P, PKPS S}KPS,{TPS, PKPS S, role(P)}KS, {A,p, role(A), n}KPS) (3 ) S → P : {{AKAS, n}KA}KP

(4 ) P → A : { A KA S, n}KA

Bổ đề 2.2: Với giả thiết ( ), khi A nhận đ ợc thông báo* : {AKAS, n}KA (2.2 )

thì A|≡≡≡≡≡ S|≡≡≡≡≡A KA S và A n (n là mã hiệu A đã gửi đi tr ớc khi nhận đ ợc (2.2)).

Chứng minh: Theo giả thiết (*), ta thấy: Khi A nhận đợc thông báo (2.2), vì A|≡≡≡≡≡A KAS nên: A |≡≡≡≡≡ S |∼.(A KA S, n) và A (A KAS, n), do đó A n. A nhận lại đợc

mã hiệu nên An |≡≡≡≡≡ #(n) và A |≡≡≡≡≡ #(A KA S, n). Do đó A |≡≡≡≡≡ S |≡≡≡≡≡ (A KA S, n). Thế thì A |≡≡≡≡≡ S |≡≡≡≡≡ A KAS và A n. Về ý nghĩa, việc A giải mã thành công thông báo (2.2 để ) có đợc mã hiệu nchứng tỏ việc A có khoá riêng KA là đúng.

Định lý 2 : .2 Với giả thiết ) thì giao thức đăng ký định danh hợp (* logic và đạt đ ợc các mục tiêu xác nhận : A |≡≡≡≡≡ S |≡≡≡≡≡ A KAS và A . n

Chứng minh: Theo giả thiết (*) và Bổ đề 2.1 khi S nhận đợc thông báo )(2 thì : S |≡≡≡≡≡ PKPS S, S |≡≡≡≡≡ P |≡≡≡≡≡ PKPS S, S |≡≡≡≡≡ role(P), S |≡≡≡≡≡ P |∼. (A, p, role(A), ). Vìn role(P) cho phép P quyền truy nhập S, nên S đáp ứng yêu cầu của P bằng cách sản sinh ra khoá phiên KA ứng với (A, p), lu trữ bộ (A, KA, role(A)) trong cơ sở dữ liệu xác thực của mình, đồng thời gửi thông báo (3 cho P báo nhận đã thực hiện yêu cầu của P. Khi P ) nhận đợc thông báo )(3 , vì P |≡≡≡≡≡ P KP S nên: P {AKA S, n}KA và P có thể chuyển thông báo (4 ) cho A. Khi A nhận đợc thông báo ) heo Bổ đề (4 , t 2.2 thì: A |≡≡≡≡≡ S |≡≡≡≡≡ A KAS và A n. Việc A giải mã thành công thông báo (4 ) để có đợc n chứng tỏ việc A có khoá riêng KA là đúng và việc đăng ký định danh thành công.

♦ Giao thức cập nhật định danh:

(1 ) A → P : (A,{A, A’, p}KA , n) (thực hiện trên SSL )

(2 ) P → S : ({TP, P}KPS,{P, S, role(P), TPS, KPS}KS, {A, {A, A’, p}KA, role(A’),n}KPS ) (3 ) S → :P {{ }Kn A’}KP

(4 ) P →A’: {n}KA’

n là mã hiệu do A tạo ra ban đầu, p là mật khẩu của thành phần máy khách A’. Dạng hình thức của các thông báo trong giao thức nh sau, thông báo 1 không thuộc vào đặc tính logic của giao thức:

(1 A P : (A,{A, A’, p}K) → A, n)

(2 ) P → S : ({TP,PKPS S}KPS,{TPS,PKPS S, role(P)}KS,{A,{A,A’,p}KA, role(A’),n}KPS) (3 ) S → P : {{A’KA’S, n}KA’}KP

Định lý 2.3:

Với giả thiết ( ) thì giao thức cập nhật định danh hợp logic và đạt đ ợc các mục * tiêu xác nhận : A’ |≡≡≡≡≡ S |≡≡≡≡≡ A’ KA’ S và A’ . n

Chứng minh:

Theo giả thiết (* , ta có : )

P khi nhận đợc thông báo )(1 thì P không thể giải mã mục mã hoá của thông báo này và gửi nó cho S (thông báo (1 ) không thuộc vào đặc tính logic của giao thức). Khi S nhận đợc thông báo )(2 thì S {A,{A, A’, p}KA, role(A’ ), n}KPS .

Vì S |≡≡≡≡≡ P KPS S nên: S (A,{A, A’, p}KA , role(A’), n) và S |≡≡≡≡≡ P |∼. (A,{A, A’, p}KA , role(A’), )n . Do đó S {A, A’, p}KA mà S |≡≡≡≡≡ A KA S nên S (A, A’, p). Hơn nữa,

khi S nhận đợc thông báo ), theo Bổ đề (2 2.1 thì S |≡≡≡≡≡ PKPS S, S |≡≡≡≡≡ P |≡≡≡≡≡ P KPSS, S |≡≡≡≡≡ role(P), S |≡≡≡≡≡ P |∼. (A,{A, A’, p}KA , role(A’), ). Vì vai role(P) cho phép P quyền n

truy nhập S, nên S đáp ứng yêu cầu của P bằng cách sản sinh ra khoá phiên KA ’ứng với (A’, p), lu trữ bộ (A’, KA’, role(A’)) trong cơ sở dữ liệu của mình thay cho bộ (A, KA, role(A)), đồng thời gửi thông báo ) cho P. Khi P nhận đợc thông báo )(3 (3 , vì P|≡≡≡≡≡ PKPS S nên P {A’KA’ S, n}KA ’ và P có thể chuyển thông báo (4 ) cho A’ (định danh mới của thành phần máy khách A . ) Khi A’ nhận đợc thông báo )(4 , áp dụng Bổ đề 2.2 cho cặp (A’, S) thay thế cho cho cặp (A,S) thì: A’|≡≡≡≡≡ S |≡≡≡≡≡ A’KA’S và A’ n. Việc A’ giải mã thành công thông báo (4 ) để có đợc nchứng tỏ A’ có khoá riêng KA’ là đúng và cập nhật định danh thành công.

♦ Giao thức làm mới vé :

Theo định kỳ, S làm mới các vé đã hết hạn: làm mới thời gian phát hành vé t1 thời gian hết hiệu lực của vé t2 , thời gian sống của vé tf và gán thời điểm làm mới vé tn. Dới dạng hình thức, vé dành cho giao tiếp giữa thành phần máy khách A và dịch vụ B là:

Vé cũ A, B, role(A), T( AB , KAB); vé mới (A, B, role(A), T’AB , KAB).

Đây là chức năng của riêng trung tâm phân phối khoá S, nên không xét tính logic của giao thức.

Mục trên đã trình bày giao thức xác thực tích hợp thông tin vai của định danh ngời dùng, nhằm kết hợp xác thực với kiểm soát truy nhập dựa trên vai. Tiếp theo là những nghiên cứu, phát triển về phân cấp vai, ràng buộc số lợng và phân ly trách nhiệm trong mô hình GTRBAC, làm cơ sở đề xuất xây dựng một khung làm việc thực thi kiểm soát truy nhập dựa trên vai theo mô hình GTRBAC .

2.2. Phân cấp vai trong mô hình kiểm soát truy nhập dựa trên vai GTRBAC

Mục này trình bày các quan hệ phân cấp vai của mô hình kiểm soát truy nhập dựa trên vai ràng buộc thời gian tổng quát GTRBAC theo ngữ nghĩa kế thừa giấy phép và kế thừa kích hoạt vai. Từ đó chứng minh tính đúng đắn của một tập luật suy diễn trong các quan hệ phân cấp vai. Điều này sẽ rất hữu ích khi lựa chọn các quan hệ phân cấp vai trong việc đề xuất xây dựng một khung làm thực thi việc kiểm soát truy nhập dựa trên vai theo mô hình GTRBAC Cở hơng 3 của luận án.

Một phần của tài liệu Nghiên cứu phát triển các giải pháp kiểm soát truy nhập đảm bảo an toàn an ninh cho mạng máy tính191 (Trang 67 - 71)

Tải bản đầy đủ (PDF)

(149 trang)