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

Đây là chức năng của riêng trung tâm phân phối khoá KDC. Nólàm mới các vé hết hạn và các vé cũ không hợp lệ trong cơ sở dữ liệu vé. Theo định kỳ, thành

phần KDC kiểm tra các vé ticket(C, S) trong cơ sở dữ liệu vé của mình để hiệu chỉnh 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 , thời điểm làm mới vé tnnếu nh các vé này hết hạn.

Nếu xảy ra sự thay đổi vai role(C) của một định danh thành phần máy khách C nào đó, thành phần AdminRole sẽ cập nhật sự thay đổi này rồi truyền vai mới role’(C) của thành phần máy khách cho PKDC.

Đến lợt mình, PKDC gửi cho KDC một bộ xác thực, một vé giao tiếp giữa PKDC và KDC cùng với một thông báo chứa định danh, địa chỉ IP, vai mới role’(C) của thành phần máy khách định danh của dịch cụ S và một mã hiệu , n. Thông báo này đợc mã hoá bằng khoá phiên KPKDC,KDC . KDC giải mã bộ xác thực và vé giao tiếp để xác thực PKDC. Nếu hợp lệ, KDC giải mã thông báo cuối cùng {C, addr, S,

n, role’(C)}KPKDC,KDC . Bộ dữ liệu (C, addr, S, role’(C)) đợc KDC dùng để làm mới vé ticket(C, S) của thành phần máy khách C.

+ Vé cũ của thành phần máy khách C giao tiếp với dịch vụ S: ticket(C, S) (= C, addr, S, t1 , t2 , tf , tn, KC,S , role(C)) + Vé mới của thành phần máy khách C giao tiếp với dịch vụ S:

(*)

2.1.3. áp dụng logic BAN phân tích giao thức Kerberos-role 2.1.3.1. Phân tích giao thức Kerberos-role tr ờng hợp tổng quát

Để đơn giản, từ mục này ký hiệu: KDC là S, PKDC là P, auth(A)= (TA , A) và ticket(A, B) = (A, B, role(A), TAB , KAB). Trong đó TA là thời gian hiện tại khi phát hành bộ xác thực auth(A), TAB là tem thời gian bao gồm 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 , thời gian làm mới vé tn trong vé ticket(A, B), KAB là khoá phiên giao tiếp giữa A và B. Địa chỉ addr của thành phần máy khách đợc hiểu là gộp vào định danh của thành phần máy khách .

♦ Giao thức Kerberos-role tr ờng hợp tổng quát:

(1 ) A → P : (A, B, n) (thực hiện trên tầng socket an toà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 → : {KA AB , {A, B, role(A), TAB , KAB}KB , n}KA

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

M1là một thông báo hoặc yêu cầu của A gửi cho B. M2là đáp ứng của B khi nhận đợc thông báo (5) từ 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, B, n)

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

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

(5 A : ({T) → B A , AKABB}KAB , {TAB , AKABB, role(A)}KB , {M1 , n}KAB ) (6 ) B → : (A {AKABB, # (AKABB), n}KAB , M2)

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

({TA , AKABB}KAB , {TAB , AKABB, role(A)}KB , {M, n}KAB ) (2.1 )

thì : B|≡≡≡≡≡AKABB, B|≡≡≡≡≡ A|≡≡≡≡≡ AKABB, B|≡≡≡≡≡ role(A), B|≡≡≡≡≡ A|∼.M .

Chứng minh: Khi B nhận đợc thông báo (2.1) thì B {TAB , AKABB, role(A)}KB. Theo giả thiết (*) ta có:

Vì B |≡≡≡≡≡ BKB S nên theo luật ý nghĩa thông báo ta có B |≡≡≡≡≡ S |∼. (TAB , AKABB, role(A))

Vì B |≡≡≡≡≡ #(TAB) nên B |≡≡≡≡≡ # (TAB , AKABB, role(A)). Theo luật kiểm tra mã hiệu ta có B |≡≡≡≡≡ S |≡≡≡≡≡ (TAB , AKABB, role(A)). Suy ra: B |≡≡≡≡≡ S |≡≡≡≡≡ AKABB và B |≡≡≡≡≡ S |≡≡≡≡≡ role(A)

Vì B |≡≡≡≡≡ K.(S ∀ |⇒ A K B) nên B |≡≡≡≡≡ S ⇒| AKABB. Mà B |≡≡≡≡≡ S |⇒ role(A), nên áp dụng luật quyền hạn, ta đợc: B |≡≡≡≡≡ A KABB và B |≡≡≡≡≡ role(A).

Khi nhận đợc thông báo (2.1) thì B {TA , AKABB}KAB . Vì B |≡≡≡≡≡ AKABB nên theo luật ý nghĩa thông báo: B |≡≡≡≡≡ A|∼.(TA, AKABB ). Vì B |≡≡≡≡≡ (T# A) nên B |≡≡≡≡≡ #(TA , AKABB . ) áp dụng luật kiểm tra mã hiệu ta đợc B|≡≡≡≡≡A|≡≡≡≡≡ (TA, A KABB . Suy ra: ) B |≡≡≡≡≡ A|≡≡≡≡≡ AKABB. Khi nhận đợc thông báo (2 ) thì B.1 {M, n}KAB . Vì B |≡≡≡≡≡ A KABB nên theo luật ý nghĩa thông báo ta có B |≡≡≡≡≡ A |∼. M.

Vậy: B |≡≡≡≡≡ A KABB, B |≡≡≡≡≡ A|≡≡≡≡≡ AKABB, B |≡≡≡≡≡ role(A), B|≡≡≡≡≡ A|∼. M.

Ta có B |≡≡≡≡≡ role(A), tức B tin rằng A có vai là role(A), nên B thực hiện kiểm soát truy nhập căn cứ vàovai của A. Nếu A đợc phép truy nhập B thì B đáp ứng yêu cầu M.

Định lý 2.1:Với giả thiết ( ) thì giao thức Kerberos role tr ờng hợp tổng quát hợp * - logic và đạt đ ợc các mục tiêu xác nhận :

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

Nghĩa là S tin rằng mình đang giao tiếp với P và P có vai role(P). Vì S |≡≡≡≡≡ role(P) và role(P) cho phép P truy nhập S nên S đáp ứng yêu cầu của P, cụ thể S đáp ứng yêu cầu của P bằng một thông báo mã hoá chứa khoá phiên và vé giao tiếp giữa A và B

trong thông báo (3 . ) Khi P nhận đợc thông báo (3), vì P |≡≡≡≡≡ P KP S nên ta có P {AKABB, {TAB , A KABB, role(A)}KB , n}KA. Do đó P có thể gửi cho A thông báo (4). Khi A nhận đợc thông báo )(4 , vì A |≡≡≡≡≡ A KAS nên theo luật ý nghĩa thông báo ta đợc A |≡≡≡≡≡ S |∼. (AKABB,{TAB , AKABB, role(A)}KB , n). A gửi đi mã hiệu n và nhận lại đợc thông báo chứa n, nên A|≡≡≡≡≡#n Avà |≡≡≡≡≡#(AKABB,{TAB, AKABB,role(A)}KB, n). áp dụng luật kiểm tra mã hiệu, ta có A|≡≡≡≡≡S|≡≡≡≡≡(AKABB,{TAB,AKABB,role(A)}KB, n). Suy ra: A |≡≡≡≡≡ S |≡≡≡≡≡ A KABB. Vì A |≡≡≡≡≡ K.(S ∀ ⇒| A K B) nên A |≡≡≡≡≡ S |⇒ AKABB. áp dụng luật quyền hạn, ta đợc A |≡≡≡≡≡ A KABB. Hơn nữa khi A nhận đợc thông báo )(4 thì vì A |≡≡≡≡≡ A KAS nên: A (AKABB, {TAB , AKABB, role(A)}KB , . n)

Suy ra: A {TAB , AKABB, role(A)}KB và A n

Vậy A có thể xây dựng thông báo (5 ) và chuyển cho B. Khi B nhận đợc thông báo (5 , ) theo Bổ đề 2.1 thì: B |≡≡≡≡≡ AKABB, B |≡≡≡≡≡ A|≡≡≡≡≡ AKABB, B|≡≡≡≡≡ role(A), B|≡≡≡≡≡ A|∼. M1.

Vì B |≡≡≡≡≡role(A), tức B tin rằng A có vai là role(A), nên B sẽ thực hiện kiểm soát truy nhập căn cứ vào vai của A. Nếu A đợc phép truy nhập B thì B đáp ứng yêu cầu M1 và gửi thông báo (6 ) cho A. Nếu A không đợc phép truy nhập B thì B gửi thông báo từ chối truy nhập (ở đây không xét chi tiết kiểm soát truy nhập dựa trên vai . )

đó theo luật kiểm tra mã hiệu ta đợc A|≡≡≡≡≡ B |≡≡≡≡≡ (AKABB, # (AKABB), n). Suy ra: A |≡≡≡≡≡ B |≡≡≡≡≡ AKABB. Tóm lại: A |≡≡≡≡≡ AKABB, A |≡≡≡≡≡ B |≡≡≡≡≡ A KABB, B |≡≡≡≡≡ A |∼. M1,

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

♦ 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

Đị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.

2.2.1. Các vị từ trạng thái

Trong mô hình GTRBAC Joshi và cộng sự đã định nghĩa ba loại phân cấp, vai (phân cấp kế thừa giấy phép, phân cấp kế thừa kích hoạt phân cấp kế thừa tổng , quát [16] ) vàđa ra một số vị từ trạng thái dới đây, đợc chúng tôi dùng trong các định nghĩa phát biểu Mục 2.2 , Mụcở .2 2.2.3 và đợc sử dụng ở Mục 2.3 để phân loại, biểu diễn các ràng buộc số lợng, ràng buộc phân ly trách nhiệm. Joshi và cộng sự cũng đa ra một hệ tiên đề nêu lên những mối quan hệ chủ yếu giữa các vị từ trạng thái này, làm cơ sở để nhận biết chính xác sự có đợc giấy phép và sự kích hoạt vai đang xảy ra hoặc có khả năng xảy ra trong một hệ thống RBAC.

Các kí hiệu , , , U R P S tơng ứng biểu diễn tập ngời dùng, tập các vai, tập

các giấy phép và tập các phiên nh ở mô hình RBAC96, T là tập các thời điểm (0, ∞); xét u∈U r, ∈R p, ∈P s, ∈S t, ∈T.

1. Các vị từ trạng thái tạo khả năng, làm mất khả năng của vai:

r t

enabled(r, t) : có khả năng tại thời điểm

r t

2. Vị từ trạng thái gán ngời dùngvào vai, gán giấy phép cho vai:

r t

u_assigned(u, r, t): uđợc gán vào tại thời điểm

r t

p_assigned(p, r, t): pđợc gán cho tại thời điểm 3. Vị từ trạng thái kích hoạt vai:

active(u, r, t) : r ở trạng thái kích hoạt trong phiên của u tại thời điểm t

r t

s_active(u, r, s, t): ở trạng thái kích hoạt trong phiên scủa u tại 4. Vị từ trạng thái khả năng kích hoạt vai:

r t

can_activate(u, r, t): có khả năng kích u hoạt tại thời điểm

r t

s_can_activate(u, r, s, t): có khả năng kích hoạt u trong phiêns tại 5. Vị từ trạng thái khả năng ngời dùng có đợc giấy phép:

t acquires(u, p, t): ucó đợc p tại thời điểm

t can_acquire(u, p, t): có khả năng u có đợc p tại thời điểm 6. Vị từ trạng tháikhả năng nhận đợc giấy phép thông qua vai:

r, r t

can_be_acquired(p, t): có thể nhận p đợc thông qua tại thời điểm 7. Vị từ trạng thái ngời dùng có đợc giấy phép thông qua vai:

r t r_acquires(u, p, r, t): ucó đợcp thông qua tại thời điểm

, t

s_acquires(u, p s, t): ucó đợcp trong phiêns tại thời điểm

Phát hiện xâm nhập mức máy

Phát hiện xâm nhập mức nhân