Tải bản đầy đủ - 0 (trang)
CHƯƠNG 2. GIAO THỨC XÁC THỰC KERBEROS

CHƯƠNG 2. GIAO THỨC XÁC THỰC KERBEROS

Tải bản đầy đủ - 0trang

của dữ liệu. Kerberos hoạt động theo mơ hình client/server và nó thực hiện q

trình chứng thực 2 chiều cả người dùng và dịch vụ xác thực lẫn nhau.

Kerberos được xây dựng dựa trên mơ hình mã hóa khóa đối xứng và đòi

hỏi một thành phần thứ ba tin cậy (trusted third party) tham gia vào quá trình

chứng thực.

2.1.2. Lịch sử phát triển

Kerberos được phát triển bởi Học viện kỹ thuật Massachusetts (MIT)

nhằm bảo vệ những dịch vụ được cung cấp bởi dự án Athena. Kerberos trải qua

nhiều phiên bản, trong đó, các phiên bản từ 1 – 3 chỉ được sử dụng nội bộ bên

trong MIT.

Giao thức được đặt tên dựa theo một nhân vật trong thần thoại Hy Lạp

Kerberos (hay Cerberus), đó là một con chó săn 3 đầu khổng lồ dưới âm phủ.

Steve Miller và Clifford Neuman, những thiết kế gia chính của Kerberos phiên

bản 4, đã công bố phiên bản này vào cuối thập niên 80, mặc dù mục đích chính

của họ vẫn là dùng để phục vụ cho dự án Athena.

Phiên bản 5, được phát triển bởi John Kohl và Clifford Neuman, xuất hiện

trong RFC 1510 vào 1993, với mục đích khắc phục những giới hạn và các vấn

đề liên quan đến bảo mật trong phiên bản 4.

Windows 2000, XP và 2003 Server sử dụng Kerberos như là một phương

pháp chứng thực mặc định. Hệ điều hành Mac OS cũng sử dụng Kerberos trong

các phiên bản Clients và Server của mình.



2.2.



Một số khái niệm



2.2.1. KDC – Key Distribution Center



Key Distribution Center – trung tâm phân phối khóa của Kerberos (KDC), là

một phần của hệ thống Kerberos. Trên lý thuyết KDC bao gồm ba thành phần:

- Database của tất cả các principal và các khoá đã mã hố của nó để gia

nhập

- Authentication Server

- Ticket Granting Server



22



Người ta thường gom chúng lại trong một chương trình duy nhất và chạy

cùng nhau trong một process duy nhất

Trong một realm của Kerberos phải có ít nhất một KDC. Khi nhu cầu đòi hỏi

chạy KDC trên một máy bình thường, người ta khuyên rằng nên dung một KDC

riêng biệt. Vì nếu hệ thống mạng có nhiều KDC kết nối nhau thì tất cả các dữ

liệu quan trọng bao gồm các key của các principal trong realm của bạn đều có

trên mỗi KDC trong mạng. Điều đó có nghĩa là có nhiều nguy cơ bị tấn ơng hơn.

Ngồi ra, để cho người dung xác thực thành công đến Kerberos kishc hoạt dịch

vụ. ít nhất một KDC phải được hoạt động mọi lúc.

Mỗi KDC chứa một database của tất cả các principal có trong realm này,

cũng như các bí mật liên quan của nó. Phần mềm KDC chứa hầu hết các thông

tin bổ sung của các principal trong database này, chẳng hạn như thời gian sống

của mật khẩu, mật khẩu thay đổi lần cuối cùng là gì và nhiều thứ khác nữa.

Window 2000 và 2003 giữ cơ sở dữ liệu này trong Active Directory (chứa trong

LDAP).

Trong một realm có thể chứa nhiều Kerberos KDC, database trên mỗi KDC

phải được đồng bộ hoá để đảm bảo thống nhất xác thực. Nếu một máy chủ có dữ

liệu để lâu dài thì sẽ rất dễ thất bại khi tìm cách hợp pháp để xác thực với máy

chủ đó, vì nó khơng update bản sao của các cơ sở dữ liệu của Kerberos. Khơng

có phương pháp tiêu chuẩn đồng bộ hoá được xác định bằng giao thức Kerberos,

do đó các nhà cung cấp đã tạo ra các giao thức bản sao riêng của họ.

2.2.2. SS, AS, TGS

SS - Service Server:

 Máy chủ dịch vụ - Mail Server, File Server, Application Server.

 Bất kì một Server cung cấp dịch vụ nào đều có thể là Service Server

AS - Authentication Server: Máy chủ xác thực

 Khi một user muốn tham gia vào 1 realm của Kerberos thì thay vì

user phải xác thực với KDC thì phải xác thực với AS

 Khi nhận yêu cầu tham gia hệ thông Kerberos của một client, AS

kiểm tra nhân dạng của người yêu cầu có nằm trong cơ sở dữ liệu



23



của mình hay khơng. Nếu có thì AS gửi 2 gói tin sau tới người

dung.

 Gói tin A: “Khố phiên TGS/máy khách” được mật mã hố với

khố bí mật của người dung

 Gói tin B: ” Vé chấp thuận” (bao gồm chỉ danh người dùng (ID),

địa chỉ mạng của người sử dụng, thời hạn của vé và “Khoá phiên

TGS/máy khác”) được mật mã hố với khố bí mật của TGS.

TGS - Máy chủ cấp phát vé:

 TGS là bộ phận nhận vé chấp thuật TGT (Ticket Granting Ticket) từ

user. TGS có nhiệm vụ kiểm tra các vé TGT có giá trị khơng bằng

cách kiểm tra xem nó có được mã hố bởi key với key của TGT

server Kerberos không. Nếu đúng thì gửi cho user vé dịch vụ mà user

muốn sử dụng. TGS xác nhận việc sử dụng vé cho một mục đích cụ

thể chẳng hạn như truy cập dịch vụ mạng

2.2.3. Ticket và Session key

Ticket:

Ticket (vé) được cung cấp bởi TGS và máy chủ ứng dụng, cung cấp sự

chứng thực cho máy chủ ứng dụng và tài nguyên.

Một vé Kerberos là một cấu trúc dữ liệu được mã hoá do KDC tạo ra để

share 1 key đã mã hoá của một phiên duy nhất. Vé tạo ra có 2 mục đích: xác

nhận danh tính của người tham gia và khởi tạo một khố ngắn hạn để hai bên có

thể giao tiếp an tồn (gọi là khố phiên).

Các trường chính mà mọi vé của Kerberos đều có là:

 Yêu cầu tên của principal

 Dịch vụ của principal có tên này là gì

 Khi nào thì vé có hiệu lực, khi nào thì vé hết hiệu lực (Timestamp,

Lifetime)

 Danh sách IP mà vé có thẻ được dung từ đó

 Chia sẻ khố bí mật (session key) của user/ ứng dụng truyển thơng



24



Một vé được tạo bởi KDC được mã hoá để đảm bảo rằng những người khơng

có khố khơng mở được nó để chính sửa, như là tăng lifetime của nó lên hoặc

tên định danh của client principal.

Bởi vì Kerberos chỉ xác thực một lần khi đăng nhập nên sau khi đăng nhập

thì bất kỳ ai ngồi trên máy đó có thể tham gia vào hệ thơng Kerberos. Vì vậy, vé

trong Kerberos có lifetime ngắn, khoảng từ 10-24h. Điều này thuận tiện cho việc

đăng nhập một lần trong ngày làm việc của user, hạn chế việc tấn công lấy mất

dữ liệu quan trọng

Session key: Được sử dụng cho một phiên làm việc giữa client và server

2.2.4. Ticket cache

Tất cả các vé của Kerberos đều được lưu trong một file nằm trong bộ nhớ

cache gọi là Credential cache. Microsoft và Apple đã lựa chọn phương án này.

Khi đăng nhập vào hệ thống Kerberos thì các vé được lưu trong bộ nhớ cache và

khi đăng xuất thì mọi thứ được xố hết. Các thơng tin chứa tỏng cache gồm: user

principal, các vé mà user có trong suốt phiên đăng nhập của họ.

Ví dụ:

$klist

Ticket cache: FILE:/tmp/krb5cc_502_auJKaJ

Default principal: jgarman@WEDGIE.ORG

Valid starting: Expires

Service principal

09/10/02 01:48:12 09/10/02 11:48:12 Krbtgt/WEDGIE.ORG@WEDGIE.ORG

09/10/02 01:48:14 09/10/02 11:48:12 host/cfs.wedgie.org@WEDGIE.ORG

09/10/02 04:20:42 09/10/02 11:48:12 host/cfs.wedgie.org@WEDGIE.ORG



Trong ví dụ này, bộ nhớ cache cho user principal của

jgarman@WEDGIE.ORG được lưu trong tập tin /tmp/krb5cc_502_auJKaJ.

Credential cache chỉ có thể được kết hợp với một user principal tại một thời

gian, nếu ta muốn truy cập các dịch vụ với một principal của

jgraman/admin@WEDGIE.ORG , ta đã có thể phá huỷ vé hiện tại của mình và

tái đăng nhập để Kerberos theo jgarman/admin@WEDGIE.ORG

2.3.



Nguyên lý hoạt động



2.3.1. Mơ hình tiêu biểu

Dưới đây là mơ hình hệ thống Kerberos tiêu biểu mà chúng ta thường thấy hiện

nay, bao gồm:



25



- Client hay user

- Thiết bị truyền thông: router, switch, hub, ....

- Kerberos System: AS, TGS, database

- Server cung cấp dịch vụ: Mail server, máy in, ......



Hình 2. 1. Mơ hình kerberos tiêu biểu



2.3.2. Mơ tả giao thức

Theo hệ thống ký hiệu giao thức mật mã, Kerberos được mơ tả như sau (trong

đó Alice(A) sử dụng máy chủ (S) để nhận thực với Bob (B)):

An ninh của giao thức phụ thuộc rất nhiều vào các trường T (đánh dấu thời

điểm) và L (thời hạn) của các gói tin. Đây chính là các chỉ thị về tính chất mới

của các gói tin và chống lại các tấn cơng gửi lại các gói tin cũ.

Trong các bản tin ở trên, máy chủ S bao gồm cả dịch vụ nhận thực và cung

cấp vé. Trong gói tin , chính là khóa phiên giữa A và B; là vé gửi từ máy khách

tới máy chủ; là phần để nhận thực A với B; và để khẳng định lại nhân dạng của



26



B và thơng qua đó chấp nhận A. Điều này cần thiết để hai bên nhận dạng lẫn

nhau.

2.3.3. Nguyên lý hoạt động



Hình 2. 2. Nguyên lý hoạt động của Kerberos

Kerberos sử dụng một đối tác tin cậy thứ ba để thực hiện quá trình chứng

thực, được gọi là Trung tâm phân phối khóa (Key Distribution Center – KDC),

bao gồm 2 phần riêng biệt: một server chứng thực (Authentication Server – AS)

và một server cấp ticket (Ticket Granting Server – TGS). Kerberos làm việc dựa

trên các ticket để thực hiện quá trình chứng thực người dùng.

Kerberos duy trì một cơ sở dữ liệu chứa các secret key; mỗi thực thể trên

mạng – client hoặc server – đều chia sẽ một secret key chỉ giữa bản thân nó với

Kerberos. Để thực hiện q trình giao tiếp giữa 2 thực thể, Kerberos tạo ra một

session key. Khóa này dùng để bảo mật q trình tương tác giữa các thực thể với

nhau.Mỗi người sử dụng (cả máy chủ và máy khách) trong hệ thống chia sẻ một

khóa chung với máy chủ Kerberos.

Việc sở hữu thơng tin về khóa chính là bằng chứng để chứng minh tính

hợp lệ của một người sử dụng. Trong mỗi giao dịch giữa hai người sử dụng

trong hệ thống, máy chủ Kerberos sẽ tạo ra một khóa phiên dùng cho phiên giao

dịch đó.



27



Một cách vắn tắt: người sử dụng chứng thực mình với máy chủ chứng

thực AS, sau đó chứng minh với máy chủ cấp vé TGS rằng mình đã được chứng

thực để nhận vé, cuối cùng chứng minh với máy chủ dịch vụ SS rằng mình đã

được chấp thuận để sử dụng dịch vụ.

Dưới đây là một mô tả về quá trình hoạt động của giao thức (AS =

Authentication Server, TGS = Ticket Granting Server, C = Client, S = Service):

1. Người dùng nhập vào username và password ở phía client.

2. Client thực hiện thuật toán băm một chiều trên password được nhập vào,

và nó trở thành secret key của client.

3. Client gởi một message dưới dạng clear-text đến AS để u cầu dịch vụ.

Chú ý: khơng có secret key cũng như password nào được gởi đến AS.

4. AS kiểm tra xem có tồn tại người dùng C trong cở sở dữ liệu của nó hay

khơng. Nếu có, nó gởi ngược lại cho client 2 message:

Message A: chứa Client/TGS session key được mã hóa bởi secret key của

người dùng (client).

Message B: chứa Ticket Granting Ticket (bao gồm Client ID, Client

Network Address, Ticket Validity Period, và một Client/TGS session key) được

mã hóa sử dụng secret key của TGS.

5. Khi client nhận được Message A và B, nó giải mã Message A để lấy

Client/TGS session key. Session key này được sử dụng cho quá trình giao đổi

tiếp theo với TGS. Chú ý: client khơng thể giải mã Message B, bởi vì nó được

mã hóa bởi secret key của TGS.

6. Khi yêu cầu dịch vụ (S), client gởi 2 message sau đến TGS:

Message C: bao gồm Message B và ID của dịch vụ được yêu cầu.

Message D: chứa Authenticator (gồm client ID và timestamp), được mã

hóa bởi Client/TGS session key.

7. Khi nhận được Message C và D, TGS giải mã Message D sử dụng

Client/TGS session key và gởi 2 message ngược lại cho client:

Message E: chứa Client-to-Server Ticket (bao gồm Client ID, Client

Network Address, Ticket Validity Period, và một Client/Service session key)

được mã hóa bởi secret key của Service.

Message F: chứa Client/Server session key được mã hóa bởi Client/TGS

session key.



28



8. Khi nhận được Message E và F, Client sau đó gởi một Authenticator mới

và một Client-to-Server ticket đến Server chứa dịch vụ được yêu cầu.

Message G: chứa Client-to-Server ticket được mã hóa sử dụng secret key

của Server.

Message H: một Authenticator mới, chứa Client ID, Timestamp và được

mã hóa sử dụng Client/Server session key.

9. Sau đó, Server giải mã Ticket sử dụng secret key của chính nó, và gởi

một message cho client để xác nhận tính hợp lệ thực sự của client và sự sẵn sàng

cung cấp dịch vụ cho client.

Message I: chứa giá trị Timestamp trong Authenticator được gởi bởi client

sẽ được cộng thêm 1, được mã hóa bởi Client/Server session key.

10. Client sẽ giải mã sự xác nhận này sử dụng khóa chia sẽ giữa nó với

server, và kiểm tra xem giá trị timestamp có được cập nhật đúng hay khơng. Nếu

đúng, Client có thể tin tưởng Server và bắt đầu đưa ra các yêu cầu dịch vụ gởi

đến Server.

11. Server cung cấp dịch vụ được yêu cầu đến client.

2.3.4. Phân tích ưu nhược điểm

a. Ưu điểm

Cho đến nay, Kerberos vẫn được phân phối miễn phí từ MIT và một số

nguồn khác. Nó được tích hợp sẵn trong các hệ điều hành như Windows, Mac

OS, Unix… và một số sản phẩm khác. Kerbeross được đánh giá là giao thức xác

thực an toàn nhờ các đặc điểm sau:

 Khi sử dụng Kerberos, mật khẩu không bao giờ truyền đi trong mạng dưới

dạng rõ mà ln được mã hóa.

 Kerberos khơng u cầu người dùng lặp đi lặp lại thao tác nhập mật khẩu

trước khi truy cập vào các dịch vụ, hạn chế nguy cơ tấn công ăn cắp dữ liệu.

 Giao thức được mã hóa theo các chuẩn mã hóa cao cấp như Triple DES,

RC4, AES nên rất an toàn.

 Tất cả các trao đổi giữa các máy đều chứa timestamp nên vé bị đánh cắp

không thể tái sử dụng, chống được tấn công dùng lại (replay attack).

b. Nhược điểm



29



Bên cạnh các ưu điểm kể trên, hệ thống Kerberos cũng tồn tại một số hạn

chế nhất định.

 Độ bảo mật của hệ thống phụ thuộc vào sự an toàn của hệ thống KDC. Nếu

KDC bị tấn cơng thì tồn bộ các thành phần trong hệ thống cũng bị tê liệt.

 Do tất cả các trao đổi đều gắn timestamp nên đòi hỏi các máy tính trong hệ

thống phải đồng bộ về thời gian (không chênh lệch nhau quá 5 phút). Nếu

không đảm bảo điều này, cơ chế xác thực dựa trên thời hạn sử dụng sẽ không

hoạt động.

 Với cơ chế đăng nhập một lần trên một máy tính, nếu máy tính đó rơi vào

tay những kẻ tấn cơng mạng thì tồn bộ dữ liệu người dùng sẽ bị đánh cắp

và gây nguy cơ cho tồn bộ hệ thống.



CHƯƠNG 3. XÂY DỰNG MƠ PHỎNG Q TRÌNH XÁC THỰC

KERBEROS KHI NGƯỜI DÙNG THUỘC NHIỀU NHĨM

3.1. Xác thực người dùng thuộc nhiều nhóm

3.1.1. Sự cố về Kerberos Access Token

Windows tạo Access Token cho mỗi lần đăng nhập của người dùng. Các

Access Token chỉ định ID tài khoản người dùng và số nhận dạng bảo mật (SID)



30



của tất cả nhóm bảo mật mà người dùng thuộc về. Kích thước của token tăng lên

khi người dùng được thêm vào các nhóm bảo mật bổ sung, được đại diện bởi

một SID bổ sung trong mã thông báo.

Nếu người dùng là thành viên của nhóm trực tiếp hoặc theo tư cách thành

viên trong nhóm khác, thì SID cho nhóm đó được thêm vào token của người

dùng. Có một giới hạn tích hợp trong đó Microsoft nói rằng số lượng SID có thể

được chứa trong token access bị hạn chế đến 1024

Cách Windows phân bổ bộ nhớ cho Access Token có thể gặp thêm vấn đề

quyền truy cập token. Kích thước mặc định của Access Token của người dùng là

4K. Số lượng chính xác của bộ nhớ thành viên nhóm bổ sung (và do đó SID bổ

sung) góp phần vào dung lượng bộ nhớ trong Access Token mặc định 4K ban

đầu này thay đổi một chút tùy thuộc trên loại nhóm - Global, Domain Local,

Built-in, Local hoặc Universal. Tuy nhiên, trung bình khoảng 80 nhóm sẽ hồn

tồn lấp đầy access token có kích thước 4K bộ nhớ này. Khi người dùng vượt

quá con số này, Windows sẽ khơng tăng kích thước của token theo số lượng cần

thiết cho mỗi SID bổ sung được thêm vào. Thay vào đó, Windows phân bổ 4K

bộ nhớ khác, do đó nhân đơi kích thước của Access Token. Tương tự, với xấp xỉ

160 tổng số thành viên nhóm, Access Token của người dùng sẽ tăng thêm một

lần nữa 4K từ 8K đến 12K. Dung lượng bộ nhớ nhỏ này có vẻ khơng phải là vấn

đề, nhưng cách các ứng dụng khác nhau lưu trữ các access token này và các giới

hạn được xác định xung quanh bộ nhớ của chúng, nó có thể trở thành một vấn đề

quan trọng. Điều này đặc biệt đúng trong các tổ chức lớn với hàng ngàn người

dùng với tiềm năng nằm trong hàng trăm nhóm.

Kerberos Token size

Giá trị MaxTokenSize nên được set về mức cao nhất 64K (0x0000FFFF).

Với windows server 2012 và cao hơn, Microsoft đã thay đổi giá trị mặc định

của MaxTokenSize là 48K do HTTP header. Kerberos ticket trong một http

requests được mã hóa ở dạng Base64.

Nếu set MaxTokenSize với giá trị cao hơn 48K có thể gây ra một số vấn

đề với HTTP request cùng Kerberos authentication.

Access token (Group Membership)



31



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

CHƯƠNG 2. GIAO THỨC XÁC THỰC KERBEROS

Tải bản đầy đủ ngay(0 tr)

×