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

(1 ) C → : S ({auth(C)}KC,S , {ticket(C, S)}KS , { , Mn 1}KC,S) (2 ) S → : ({C n}KC,S , M2)

Trong đó: auth(C)= (C, addr, t , ) ticket(C, S)= (C, addr, role(C), S, t1 , t2 , tf , tn , KC,S) Sau khi đã lấy đợc vé {ticket(C, S)}KS và khoá phiên KC,S , để truy nhập một máy chủ dịch vụ , một S thành phần máy khách C trớc tiên sản sinh một bộ xác thực chứa định danh, địa chỉ IP, vai role(C) của thành phần máy khách, thời gian hiện tại và tổng kiểm tra của yêu cầu. Sau đó nó mã hoá bộ xác thực khi dùng khoá phiên giao tiếp với máy chủ d ch vụị S và gửi bộ xác thực đã đợc mã hoá cùng với vé dịch vụ cho máy chủ này.

Khi máy chủ dịch vụ S nhận đợc một yêu cầu dịch vụ, nó giải mã vé {ticket(C, S)}KSnhận đợc bằng khoá riêng KS của mình và trích ra khoá phiên dịch vụ KC,S để giải mã bộ xác thực{auth(C)}KC,S . Máy chủ dịch vụ sẽ tính tổng kiểm tra của yêu cầu và so sánh với tổng kiểm tra trong bộ xác thực. Nếu kết quả khác nhau, nó không đáp ứng yêu cầu dịch vụ và báo lỗi. Nếu kết quả giống nhau (chứng tỏ tính toàn vẹn của thông báo) thìmáy chủ dịch vụ sẽ so sánh nội dung trong vé với nội dung trong bộ xác thực để chắc chắn rằng thành phần máy khách C này là đối tác mà nó đang giao tiếp và yêu cầu là đến từ chính thành phần máy khách C. Máy chủ dịch vụ cũng cần biết chắc chắn địa chỉ thành phần máy khách này đợc chứa

trong định danh. Cuối cùng, nếu mọi kết quả đều hợp lệ, dịch vụ sẽ trích ra vai role(C) của thành phần máy khách C để tiến hành kiểm soát truy nhập dựa trên vai. Căn cứ vào kết quả kiểm soát truy nhập này, dịch vụ sẽ cho phép hay cấm chỉ thành phần máy khách C truy nhập.

Hình 2.5 – Minh hoạ giao thức con yêu cầu dịch vụ

1 2 Máy chủ dịch vụ S Máy chủ cấp phát vé KDC Máy uỷ nhiệm PKDC Máy khách C

2.1.2.4. Giao thức cập nhật định danh (1 ) C → PKDC : (C, {C, C', p}KC , n) (thực hiện trên SSL) (2 ) PKDC → KDC : ({auth(PKDC)}KPKDC,KDC , {ticket(PKDC, KDC)}KKDC , {C, {C, C', p}KC , role(C’), n}KPKDC, KDC) (3 ) KDC →PKDC : {{ }Kn C’}KPKDC (4 ) PKDC → C : {n}KC’

Hình 2.6 – Minh hoạ giao thức con cập nhật định danh

Máy khách có định danh cũ là C, định danh mới là C’ và mật khẩu mới là p (hoặc mật khẩu cũ nếu mật khẩu không cần thay đổi . )

Để cập nhật định danh và mật khẩu, một thành phần máy khách trớc tiên sinh ra một bản thông báo gồm định danh cũ C của nó, định danh mới C’ và mật khẩu mới p hoặc mật khẩu cũ nếu mật khẩu không cần thay đổi rồi mã hoá bằng , khoá riêng của nó.

Sau đó nó gửi định danh của mình và bản thông báo đã mã hoá cho dịch vụ PKDC và dịch vụ PKDC sẽ chuyển chúng cho KDC. Nếu có sự thay đổi vai của C ứng với định danh mới C’ thì AdminRole sẽ cung cấp vai mới role(C’) của C’cho KDC để thêm vào thông báo này. Bởi vì định danh mới và mật khẩu mới đợc mã hoá, nên cả KDC lẫn dịch vụ PKDC đều không đọc đợc chúng.

Khi KDC có đợc thông báo cập nhật định danh, nó lấy ra khoá riêng của

thành phần máy khách trong cơ sở dữ liệu xác thực dựa trên định danh rõ trong 1 4 2 3 Máy uỷ nhiệm PKDC Máy khách C Máy chủ cấp phát vé KDC Máy chủ dịch vụ S

thông báo. Rồi nó giải mã dữ liệu mã hoá trong thông báo. Nếu định danh thành phần máy khách trong dữ liệu mã hoá cũng chính là định danh rõ, thì việc sửa chữa của bản giải mã đợc công nhận. Tiếp theo KDC sẽ cập nhật định danh của thành phần máy khách và khoá riêng bằng cách sinh ra một khoá mới KC’ dựa trên định danh mới C’ và mật khẩumới. KDC cũng làm mới vé của C’ giao tiếp với các dịch vụ S bằng vai mới role(C’) của C’.

2.1.2.5. 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é :

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

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