You are on page 1of 9

ĐỀ K49

Câu 1: Các ứng dụng xác thực


Xét hội thoại xác thực Kerberos 4.
a. Giải thích tác dụng của Dấu C trong các thông báo client C gửi cho server cấp thẻ TGS và server dịch
vụ ở các bước 3 và 5.
Trả lời:
- Dấu C có tác dụng để chống tấn công lặp lại
- Giải thích tác dụng: + Ở bước 3: Dấu C được sinh ra từ TS3 được mã hoá bằng khoá Kc, tgs nên
nếu gói tin bị gửi lại thì TGS sẽ biết và bỏ qua gói tin này.
+ Ở bước 5: Dấu C được sinh ra từ TS5 được mã hoá bằng khoá KC, V nên
nếu gói tin bị gửi lại thì V sẽ biết và bỏ qua gói tin này.

b. Hãy thiết kế 1 biến thể của Kerberos 4 trong đó máy C sinh ra khoá phiên Kc,tgs chứ không phải AS
như trong phiên bản chuẩn.
Trả lời:
(1) C -> AS : E(KC , [KC,tgs || IDC || IDtgs || TS1])
(2) AS -> C : E(KC , [IDtgs || TS2 || Hạn2 || Thẻ tgs])
Thẻ tgs = E( Ktgs , [KC,tgs || IDC || ADC || IDtgs || TS2 || Hạn2 ])
(3) C -> TGS : IDV || Thẻtgs || Dấu C
Dấu C = E(KC,tgs , [IDC || ADC || TS3])
(4) TGS -> C : E(KC,tgs , [KC,V || IDV || TS4 || ThẻV])
Thẻ V = E(KV, [KC,V || IDC || ADC || IDV || TS4 || Hạn4])
(5) C -> V : Thẻ V || Dấu C
Dấu C = E(KC,V , [IDC || ADC || TS5])
(6) V -> C : E(KC,V , [TS5 + 1])
ĐỀ K50
1. Hệ thống xác thực Kerberos
Một người dùng trên client C thuộc phân hệ Kerberos A muốn truy nhập vào một server
dịch vụ Vrem thuộc phân hệ Kerberos B (rem là viết tắt của từ remote).
a. Hãy mô tả cấu trúc của thẻ cấp thẻ mà server cấp thẻ của phân hệ A gửi cho người
dùng trên client C để truy cập vào server cấp thẻ của phân hệ B. Giải thích rõ các
ký hiệu được sử dụng.
Trả lời:
(4) TGS -> C : E(KC,tgs ,[KC,tgsrem || IDtgsrem || TS4 || Thẻtgsrem])
Thẻtgsrem = E(Ktgsrem, [KC,tgsrem || IDC || ADC || IDtgsrem || TS4 || Hạn4])

Trong đó :
Thẻtgsrem : là thẻ cấp thẻ
Ktgsrem : là khoá bí mật mà các TGS thống nhất với nhau từ trước
KC,tgsrem : là khoá chung giữa C và TGSrem được TGS cấp cho.
IDC : là định danh của C
ADC : là địa chỉ của C
IDtgsrem : là định danh của TGSrem
TS4 : là nhãn thời gian
Hạn4 : là khoảng thời gian còn hiệu lực của Thẻtgsrem

b. Hãy mô tả cấu trúc của dấu xác thực mà người dùng trên client C gửi cho server
cấp thẻ của phân hệ B để xin cấp thẻ truy nhập vào server dịch vụ Vrem. Giải thích
rõ các ký hiệu được sử dụng.
Trả lời:
(5) C -> TGSrem : IDVrem || Thẻtgsrem || Dấu C
Dấu C = E(KC,tgsrem, [IDC || ADC || TS5])

Trong đó :
Dấu C : là dấu xác thực của C
KC,tgsrem : là khoá chung giữa C và TGSrem được TGS cấp cho.
IDC : là định danh của C
ADC : là địa chỉ của C
IDtgsrem : là định danh của server cấp thẻ TGSrem
TS5 : là nhãn thời gian

2. Dịch vụ xác thực X.509


Xét thủ tục xác thực ba chiều sau đây:
A -> B : A{rA, IDB}
B -> A : B{rB, IDA, rA}
A -> B : A{rB}
Trong đó,
IDA là định danh của A
IDB là định danh của B
rA là một giá trị ngẫu nhiên do A sinh ra, được đảm bảo là duy nhất trong khoảng
thời gian từ t1 là thời điểm rA được sinh ra đến t2 là thời điểm rA hết hạn, A lưu lại
các thời điểm t1 và t2 cùng với giá trị rA trong bộ nhớ cho đến thời điểm hết hạn t2
thì xóa đi tất cả những thông tin đó
rB là một giá trị ngẫu nhiên do B sinh ra, được đảm bảo là duy nhất trong khoảng
thời gian từ t3 là thời điểm rB được sinh ra đến t4 là thời điểm rB hết hạn, B lưu lại
các thời điểm t3 và t4 cùng với giá trị rB trong bộ nhớ cho đến thời điểm hết hạn t4
thì xóa đi tất cả những thông tin đó
Giải thích bằng cách nào thủ tục trên phát hiện được hình thức tấn công lặp lại.
Trả lời:
// To do soon
ĐỀ K53
1. Phân phối khoá và xác thực người dùng
a. Mô tả hai tình huống theo đó một địch thủ không có mật khẩu hay khóa KC của
người dùng IDC vẫn giả mạo thành công người dùng này để được server cấp thẻ
cấp cho ThẻV
b. Trong mỗi tình huống nêu trên, sau khi đã lấy được ThẻV , địch thủ làm thế nào để
được server dịch vụ coi là người dùng hợp lệ và được phép truy nhập vào server
dịch vụ?
c. Giải thích hình thức tấn công mật khẩu đối với hệ thống đã cho.
Trả lời:
// To do soon
2. An toàn mức giao vận
Trong một ứng dụng Web, hai bên client và server sử dụng giao thức bắt tay trong chuỗi
giao thức SSL để xác thực lẫn nhau và thỏa thuận các tham số an ninh (giải thuật và
khóa). Giả sử phương pháp trao đổi khóa được client và server thống nhất sử dụng là
Diffie-Hellman trong đó server có cặp khóa riêng và khóa công khai Diffie-Hellman cố
định (khóa công khai được chứng thực), còn client sinh ra cặp khóa riêng và khóa công
khai Diffie-Hellman một cách tức thời (khóa công khai không được chứng thực) nhưng
có một cặp khóa riêng và khóa công khai RSA từ trước với khóa công khai đã được
chứng thực.
a. Vẽ sơ đồ trao đổi thông báo 4 giai đoạn giữa client và server trong giao thức bắt
tay SSL nêu trên theo cách an toàn nhất có thể.
b. Với mỗi thông báo tùy chọn (tức những thông báo không phải đối với bất kỳ
phương pháp trao đổi khóa nào cũng được gửi) và thông báo client_key_exchange,
hãy chỉ ra nó có những tham số cụ thể gì.
Trả lời:
PHASE 1 VÀ 4 MẶC ĐỊNH
| certificate |
|<------------------------------------------|
| PUSDH |
| certificate request |
|<------------------------------------------| Phase 2
| type, auth |
----------------------------------------------------------------------
| certificate |
|------------------------------------------>|
| PUCRSA |
| client-key-exchange |
|------------------------------------------>| Phase 3
DH RSA
| PUC kí bởi PRC |
| certificate-verify |
|------------------------------------------>|
| (*) | *giá trị băm các thông báo trước đó và master-secret được mã
hoá với PRCRSA

ĐỀ K55
1. Chứng thực X.509
Trả lời:
- Chuỗi các chứng thực lẫn nhau:
Y<<W>> W<<P>> P<<Q>> Q<<B>>
- Cách thức cho phép:
Vì A được chứng thực bởi Y nên A có khoá công khai hợp lệ của Y
A kiểm tra Y<<W>> nếu hợp lệ thì A có khoá công khai hợp lệ của W
A kiểm tra W<<P>> nếu hợp lệ thì A có khoá công khai hợp lệ của P
A kiểm tra P<<Q>> nếu hợp lệ thì A có khoá công khai hợp lệ của Q
A kiểm tra Q<<B>> nếu hợp lệ thì A có khoá công khai hợp lệ của B
- Nếu chứng thực của A và chứng thực của B có cùng khóa công khai thì có vấn đề gì về
an ninh không? Giải thích.
** Chứng thực A và B có cùng khoá công khai thì yếu tố an ninh sẽ không còn. Vì khi đó, các khoá
công khai không còn yếu tố độc nhất và các chứng thực sẽ không đáng tin cậy.

2. An toàn mức giao vận


Trong một ứng dụng Web, hai bên client và server sử dụng giao thức Handshake trong
chuỗi giao thức SSL để xác thực lẫn nhau và thỏa thuận các tham số an ninh (các giải
thuật và khóa mật mã). Giả sử phương pháp trao đổi khóa được client và server thống
nhất sử dụng sau khi trao đổi các thông báo client_hello và server_hello ở giai đoạn 1 là
RSA. Tuy nhiên, khóa công khai RSA mà server có sẵn và được chứng thực chỉ có tính
năng ký (không thể sử dụng để mã hóa)
Trả lời:
PHASE 1 VÀ 4 MẶC ĐỊNH
| certificate |
|<------------------------------------------|
| PUSRSA(kí) |
| server-key-exchange |
|<------------------------------------------| Phase 2
| PUSRSA(mã hoá) kí bởi PUSRSA(kí) |
| certificate request |
|<------------------------------------------|
| type, auth |
| certificate |
|------------------------------------------>|
| PUCRSA (kí) |
| client-key-exchange |
|------------------------------------------>| Phase 3
RSA
| E(PUS , [KS]) |
| certificate-verify |
|------------------------------------------>|
| (*) | *giá trị băm các thông báo trước đó và master-secret được mã
hoá với PRCRSA

ĐỀ K56
1. Phân phối khoá và xác thực người dùng
Xét hội thoại xác thực Kerberos 4. Như đã biết, trong trường hợp người dùng thuộc về
một phân hệ A muốn truy nhập vào server dịch vụ thuộc về một phân hệ B khác với A thì
các bên liên quan bao gồm client C, server xác thực AS của phân hệ A, server cấp thẻ
TGS của phân hệ A, server cấp thẻ TGS của phân hệ B và server dịch vụ V của phân hệ
B phải trao đổi với nhau tổng cộng 8 thông báo (kể cả thông báo V gửi cho C để C xác
thực V).
a. Hãy thêm các thông tin HệC, Hệtgs và Hệv chỉ phân hệ của người dùng, phân hệ của
server cấp thẻ TGS và phân hệ của server dịch vụ V một cách tương ứng vào
những chỗ thích hợp trong hội thoại xác thực Kerberos 4 để tổng số thông báo trao
đổi trong trường hợp truy nhập liên phân hệ giảm xuống còn 6. Yêu cầu đặt ra là
giữ nguyên các thông tin khác của hội thoại Kerberos 4 và cũng không được thêm
bất kỳ thông tin nào khác vào hội thoại ngoài các thông tin chỉ phân hệ đã nêu.
Trả lời:
(1) C -> AS : IDC || HệC || IDtgs || TS1])
(2) AS -> C : E(KC , [KC,tgs ||Hệtgs || IDtgs || TS2 || Hạn2 || Thẻ tgs])
Thẻ tgs = E( Ktgs , [KC,tgs || HệC || IDC || ADC || IDtgs || TS2 || Hạn2 ])
(3) C -> TGS : IDV || Thẻtgs || Dấu C
Dấu C = E(KC,tgs , [IDC || HệC || ADC || TS3])
(4) TGS -> C : E(KC,tgs , [KC,V || HệV || IDV || TS4 || ThẻV])
Thẻ V = E(KV, [KC,V || IDC || HệC || ADC || IDV || TS4 || Hạn4])
(5) C -> V : Thẻ V || Dấu C
Dấu C = E(KC,V , [IDC || HệC || ADC || TS5])
(6) V -> C : E(KC,V , [TS5 + 1])
b. Viết hội thoại trao đổi liên phân hệ cho phép người dùng thuộc một phân hệ này
truy nhập vào server dịch vụ thuộc một phân hệ khác (ở xa)?
Trả lời:
(1) C -> AS : IDC || HệC || IDtgsrem || TS1])
(2) AS -> C : E(KC , [KC,tgsrem || Hệtgsrem || IDtgs || TS2 || Hạn2 || Thẻ tgsrem])
Thẻ tgsrem = E( Ktgsrem , [KC,tgsrem || HệC || IDC || ADC || IDtgsrem || TS2 || Hạn2 ])
(3) C -> TGSrem : IDVrem || Thẻtgsrem || Dấu C
Dấu C = E(KC,tgsrem , [IDC || HệC || ADC || TS3])
(4) TGSrem -> C : E(KC,tgsrem , [KC,Vrem || HệVrem || IDVrem || TS4 || ThẻVrem])
Thẻ Vrem = E(KVrem, [KC,Vrem || IDC || HệC || ADC || IDVrem || TS4 || Hạn4])
(5) C -> Vrem : Thẻ Vrem || Dấu C
Dấu C = E(KC,Vrem , [IDC || HệC || ADC || TS5])
(6) Vrem -> C : E(KC,Vrem , [TS5 + 1])
2. An toàn mức giao vận
Trong một ứng dụng Web, hai bên client và server sử dụng giao thức Handshake trong
chuỗi giao thức SSL để xác thực lẫn nhau và thỏa thuận các tham số an ninh (các giải
thuật và khóa mật mã). Giả sử phương pháp trao đổi khóa được client và server thống
nhất sử dụng sau khi trao đổi các thông báo client_hello và server_hello ở giai đoạn 1 là
RSA. Client có sẵn một cặp khóa riêng và khóa công khai DSS trong đó khóa công khai
DSS đã được chứng thực từ trước. Server cũng có sẵn một cặp khóa riêng và khóa công
khai DSS trong đó khóa công khai DSS cũng đã được chứng thực từ trước.
Trả lời:
DSS không học nhưng nhớ là giống DH tức thời, DSS chỉ để kí :V

ĐỀ K57

Câu 1: Chứng thực X.509


Trả lời:
- Chuỗi các chứng thực lẫn nhau:
S<<Q>> Q<<P>> P<<W>> W<<X>> X<<Y>> Y<<B>>
- Cách thức cho phép:
Vì A được chứng thực bởi S nên A có khoá công khai hợp lệ của S và tin cậy vào S
A kiểm tra S<<Q>> nếu hợp lệ thì A có khoá công khai hợp lệ của Q và tin cậy vào Q
A kiểm tra Q<<P>> nếu hợp lệ thì A có khoá công khai hợp lệ của P và tin cậy vào P
A kiểm tra P<<W>> nếu hợp lệ thì A có khoá công khai hợp lệ của W và tin cậy vào W
A kiểm tra W<<X>> nếu hợp lệ thì A có khoá công khai hợp lệ của X và tin cậy vào X
A kiểm tra X<<Y>> nếu hợp lệ thì A có khoá công khai hợp lệ của Y và tin cậy vào Y
A kiểm tra Y<<B>> nếu hợp lệ thì A có khoá công khai hợp lệ của B và tin cậy vào
- Về mặt an ninh trước khi người này sử dụng khoá công khai của người kia thì người này phải kiểm tra
tính hợp lệ thông qua chứng thực lẫn nhau giữa các cơ quan chứng thực.

Câu 2: An toàn mức giao vận.


Trong một ứng dụng Web, hai bên client và server sử dụng giao thức Handshake trong
chuỗi giao thức SSL để xác thực lẫn nhau và thỏa thuận các tham số an ninh (các giải
thuật và khóa mật mã). Giả sử client chỉ có một khóa công khai RSA được chứng thực từ
trước. Khóa công khai này vừa có thể sử dụng để mã hóa, vừa có thể dùng để xác minh
chữ ký. Server cũng chỉ có một khóa công khai được chứng thực từ trước, nhưng khóa
công khai này được tạo ra bằng giải thuật Diffie-Hellman.
Trả lời:
PHASE 1 VÀ 4 MẶC ĐỊNH
| certificate |
|<------------------------------------------|
| PUSDH |
| certificate request |
|<------------------------------------------| Phase 2
| type, auth |
----------------------------------------------------------------------
| certificate |
|------------------------------------------>|
| PUCRSA |
| client-key-exchange |
|------------------------------------------>| Phase 3
DH RSA
| PUC kí bởi PRC |
| certificate-verify |
|------------------------------------------>|
| (*) | *giá trị băm các thông báo trước đó và master-secret được mã
hoá với PRCRSA

ĐỂ K58
Câu 1. Phân phối khoá
Xét một giao thức phân phối khóa và xác thực lẫn nhau giữa hai chủ thể A và B thông
qua một trung tâm phân phối khóa KDC (Key Distribution Center). Mỗi khi A muốn thiết
lập một kết nối logic với B và cần một khóa phiên sử dụng một lần Ks (cho đúng kết nối
logic đó chứ không được sử dụng lại cho các kết nối logic khác giữa hai bên), các bước
sau đây sẽ được thực hiện.
1. A -> KDC: IDA || IDB || N1
2. KDC -> A: E(Ka, [Ks || IDB || N1 || E(Kb, [Ks || IDA])])
3. A -> B: E(Kb, [Ks || IDA])
4. B -> A: E(Ks, N2)
5. A -> B: E(Ks, f(N2))
A có một khóa chủ Ka chỉ A và KDC biết được. Tương tự, B dùng chung một khóa chủ
Kb với KDC. Truy vấn A gửi cho KDC bao gồm định danh của A, định danh của B, và
một số ngẫu nhiên N1 chỉ sử dụng một lần (mỗi thông báo ở bước 1 sẽ có một giá trị N1
khác nhau). N2 cũng là một giá trị ngẫu nhiên chỉ sử dụng một lần, nhưng do B sinh ra, f
là một hàm thực hiện một biến đổi nào đó trên N2 (chẳng hạn cộng N2 với 1).
a. Bên nào (A, B, hay KDC) sinh ra khóa phiên KS? Nó được phân phối tới A và B
một cách an toàn (đảm bảo tính bảo mật của khóa) như thế nào?
Trả lời:
- KDC sinh ra khoá phiên KS (ở bước thứ 2)
- Phân phối tới A: KDC gửi trực tiếp KS cho A ở bước thứ 2, được mã hoá bằng KA
- Phân phối tới B: KDC gửi gián tiếp KS (được mã hoá bằng KB) cho A ở bước thứ 2, được mã hoá
bằng KA , sau đó A gửi KS (được mã hoá bằng KB) cho B ở bước thứ 3.
b. Giải thích tác dụng của N1 (dùng để chống lại hình thức tấn công gì, nếu không có
N1 thì hình thức tấn công đó diễn ra như thế nào, còn khi có N1 thì tấn công bị
chống lại như thế nào)?
Trả lời:
- N1 có tác dụng chống tấn công lặp lại
- Nếu không có N1 thì hình thức tấn công lặp lại có thể xảy ra ở bước thứ 2 nhằm làm cho A và B sử
dụng lại khoá từ bước 1 của lần kết nối trước đó.
- Nếu có N1 thì khi tấn công lặp lại A sẽ nhận ra và không sử dụng gói tin đó nữa.
c. Giải thích tác dụng của N2 (dùng để chống lại hình thức tấn công gì, nếu không có
N2 thì hình thức tấn công đó diễn ra như thế nào, còn khi có N2 thì tấn công bị
chống lại như thế nào, tại sao trong thông báo ở bước 5 lại dùng f(N2) thay vì N2)?
Trả lời:
- N2 có tác dụng chống tấn công lặp lại
- Nếu không có N2 (không có bước 4 và 5) thì hình thức tấn công lặp lại có thể xảy ra ở bước thứ 3
nhằm làm cho KS mà A nhận được khác với B nhận được.
- Nếu có N2 (có bước 4 và 5) thì A và B sẽ biết được 2 bên có dùng chung khoá hay chưa, nếu khác tức
là đã bị tấn công lặp lại ở bước 3.
- Nếu không dùng f(N2) thì có thể bị tấn công lặp lại ở bước 4.

Câu 2. An toàn mức giao vận


Trong một ứng dụng Web, hai bên client và server sử dụng giao thức Handshake trong
chuỗi giao thức SSL để xác thực lẫn nhau và thỏa thuận các tham số an ninh (các giải
thuật và khóa mật mã). Giả sử server chỉ có một khóa công khai RSA được chứng thực từ
trước. Khóa công khai này vừa có thể sử dụng để mã hóa, vừa có thể dùng để xác minh
chữ ký. Client cũng chỉ có một khóa công khai được chứng thực từ trước, nhưng khóa
công khai này được tạo ra bằng giải thuật Diffie-Hellman.
Trả lời:
PHASE 1 VÀ 4 MẶC ĐỊNH
| certificate |
|<------------------------------------------|
| PUSRSA |
| server-key-exchange |
|<------------------------------------------|
| PUSDH kí bởi PRSRSA |
| certificate request |
|<------------------------------------------| Phase 2
| type, auth |
----------------------------------------------------------------------
| certificate |
|------------------------------------------>|
| PUCDH |
| client-key-exchange |
|------------------------------------------>| Phase 3
| rỗng |

ĐỀ K59
1. Phân phối khóa và xác thực người dùng
Trả lời: Tương tự mấy bài trước OK
2. An toàn mức giao vận
Trong một ứng dụng Web, hai bên client và server sử dụng giao thức Handshake trong
chuỗi giao thức SSL để xác thực lẫn nhau và thỏa thuận các tham số an ninh (các giải
thuật và khóa mật mã). Giả sử client chỉ có một khóa công khai RSA được chứng thực từ
trước. Khóa công khai này chỉ có thể sử dụng cho chức năng chữ ký số, không thể sử
dụng cho mã hóa. Server cũng chỉ có một khóa công khai RSA được chứng thực từ trước
và khóa công khai này cũng chỉ có thể sử dụng cho chức năng chữ ký số, không thể sử
dụng cho mã hóa.
Trả lời:
PHASE 1 VÀ 4 MẶC ĐỊNH
| certificate |
|<------------------------------------------|
| PUSRSA |
| server-key-exchange |
|<------------------------------------------|
| PUSDH kí bởi PRSRSA |
| certificate request |
|<------------------------------------------| Phase 2
| type, auth |
----------------------------------------------------------------------
| certificate |
|------------------------------------------>|
| PUCRSA |
| client-key-exchange |
|------------------------------------------>| Phase 3
DH RSA
| PUC kí bởi PRC |
| certificate-verify |
|------------------------------------------>|
| (*) | *giá trị băm các thông báo trước đó và master-secret được mã
hoá với PRCRSA

ĐỀ K60
1. Phân phối khóa và xác thực người dùng
Trả lời: Tương tự mấy bài trước OK
2. An toàn mức giao vận
Trong một ứng dụng Web, hai bên client và server sử dụng giao thức Handshake trong
chuỗi giao thức SSL để xác thực lẫn nhau và thỏa thuận các tham số an ninh (các giải
thuật và khóa mật mã). Giả sử server chỉ có một khóa công khai RSA được chứng thực từ
trước. Khóa công khai này chỉ có thể sử dụng cho chức năng chữ ký số, không thể sử
dụng cho mã hóa. Trong khi đó, client không có một khóa công khai nào được chứng
thực từ trước.
Trả lời:
Giống đề K55 OK
ĐỀ K61
1. Phân phối khóa và xác thực người dùng
Viết một hội thoại xác thực người dùng phân tán với cùng các mục tiêu và theo đúng
trình tự 6 bước như Kerberos 4, nhưng thỏa mãn các điều kiện sau:
- Server xác thực AS, server cấp thẻ TGS, mỗi người dùng IDc và mỗi server
dịch vụ V đều có một khóa công khai được chứng thực từ trước bởi một cơ
quan chứng thực chung CA
- Ngay từ đầu AS đã có chứng thực khóa công khai CA<<IDC>> của mỗi người
dùng IDc, AS đã có chứng thực khóa công khai CA<<TGS>> của TGS, TGS
đã có các chứng thực khóa công khai CA<<AS>> của AS và CA<<V>> của
mỗi server dịch vụ V, mỗi server dịch vụ V đều có chứng thực khóa công khai
CA<<TGS>> của TGS
- Người dùng IDC không có mật khẩu PC được lưu giữ dưới dạng giá trị băm Kc
trên server xác thực AS như trong Kerberos 4
- Server xác thực AS không có khóa bí mật chung Ktgs với server cấp thẻ TGS
như trong Kerberos 4
- Server cấp thẻ TGS không có khóa bí mật chung Kv với mỗi server dịch vụ V
như trong Kerberos 4
- Các Dấuc ở các bước (3) và (5) không thay đổi
Trả lời:
(1) C -> AS : IDC || IDtgs || TS1
(2) AS -> C : E(PUC , [KC,tgs || IDtgs || TS2 || Hạn2 || Thẻ tgs])
Thẻ tgs = E( PRAS , [E(PUtgs, [KC,tgs]) || IDC || ADC || IDtgs || TS2 || Hạn2 ])
(3) C -> TGS : IDV || Thẻtgs || Dấu C
Dấu C = E(KC,tgs , [IDC || ADC || TS3])
(4) TGS -> C : E(KC,tgs , [KC,V || IDV || TS4 || ThẻV])
Thẻ V = E(PRtgs, [E(PUV, [KC,V]) || IDC || ADC || IDV || TS4 || Hạn4])
(5) C -> V : Thẻ V || Dấu C
Dấu C = E(KC,V , [IDC || ADC || TS5])
(6) V -> C : E(KC,V , [TS5 + 1])
2. An toàn mức giao vận
Trong một ứng dụng Web, hai bên client và server sử dụng giao thức Handshake trong
chuỗi giao thức SSL để xác thực lẫn nhau và thỏa thuận các tham số an ninh (các giải
thuật và khóa mật mã). Giả sử phương pháp trao đổi khóa được client và server thống
nhất sử dụng sau khi trao đổi các thông báo client_hello và server_hello ở giai đoạn 1 là
RSA. Client có sẵn một cặp khóa riêng và khóa công khai Diffie-Hellman trong đó khóa
công khai Diffie-Hellman đã được chứng thực từ trước. Server có sẵn một cặp khóa riêng
và khóa công khai RSA vừa có chức năng chữ ký số vừa có chức năng mã hóa, trong đó
khóa công khai RSA cũng đã được chứng thực từ trước
Trả lời:
PHASE 1 VÀ 4 MẶC ĐỊNH
| certificate |
|<------------------------------------------| Phase 2
| PUSRSA |
----------------------------------------------------------------------
| client-key-exchange |
|------------------------------------------>| Phase 3
RSA
| E(PUS , [KS]) |

You might also like