An toàn hơn với giao thức xác thực Kerberos

03/11/2015 21:58
Theo dõi ICTVietnam trên

Khi nói về hệ thống các biện pháp tổng hợp nhằm bảo đảm an toàn cho việc trao đổi thông tin trên mạng máy tính, người ta thường nhắc đến AAA (Authentication – xác thực; Authorization – phân quyền và Accounting – tính toán). Trong đó xác thực là công đoạn đầu tiên và quan trong nhất. Một trong các giao thức xác thực được sử dụng rộng rãi nhất hiện nay là Kerberos.

Kerberos là gì?

 Kerberos là một giao thức mật mã dùng để xác thực trong các mạng máy tính hoạt động trên những đường truyền không an toàn. Giao thức Kerberos có khả năng chống lại việc nghe lén hay gửi lại các gói tin cũ và đảm bảo tính toàn vẹn của dữ liệu. Mục tiêu khi thiết kế giao thức này là nhằm vào mô hình client - server và đảm bảo xác thực cho cả hai chiều.

Giao thức được xây dựng dựa trên mã hoá đối xứng và cần đến một bên thứ ba mà cả hai phía tham gia giao dịch tin tưởng.

Lịch sử phát triển

Kerberos được Học viện kỹ thuật Massachusetts (MIT) phát triển để bảo vệ các dịch vụ mạng cung cấp bởi dự án Athena. Tên của giao thức được đặt theo tên của con chó ba đầu Cerberus canh gác cổng địa ngục trong thần thoại của Hy Lạp. Giao thức đã được phát triển dưới nhiều phiên bản, trong đó các phiên bản từ 1 đến 3 chỉ dùng trong nội bộ MIT.

Các tác giả chính của phiên bản 4, Steve Miller và Clifford Neuman, đã xuất bản giao thức ra công chúng vào cuối thập niên 1980, với mục đích chính là chỉ phục vụ cho dự án Athena.

Phiên bản 5, do John Kohl và Clifford Neuman thiết kế, xuất hiện trong tài liệu RFC1510 - http://tools.ietf.org/html/1510 vào năm 1993 và được thay thế bởi RFC 4120 vào năm 2005 - http://tools.ietf.org/html/4120 với mục đích sửa các lỗi của phiên bản 4.

MIT đã cung cấp các phiên bản thực hiện Kerberoslo miễn phí dưới giấy phép tương tự như dùng cho các sản phẩm BSD.

Hình 1: Hoạt động của giao thức Kerberos.

Chính phủ Hoa Kỳ đã cấm xuất khẩu Kerberos vì nó có sử dụng thuật toán DES 56 bit. Tuy nhiên, trước khi chính sách xuất khẩu của Hoa Kỳ thay đổi năm 2000, đã có phiên bản KTH-KRB viết tại Thụy Điển thực hiện Kerberos 4 được phân phối rộng rãi bên ngoài Hoa Kỳ. Phiên bản này được dựa trên một phiên bản khác có tên là eBones. eBones lại dựa trên một phiên bản được xuất khẩu của MIT thực hiện Kerberos 4 (patch-level 9) gọi là Bones (loại bỏ các hàm mật mã và các lệnh gọi chúng). Eric Young, một lập trình viên người Austraulia, đã phục hồi lại các lệnh gọi hàm và sử dụng các hàm mật mã trong thư viện của anh ta.

Một phiên bản khác thực hiện Kerberos 5, Heimdal, cũng được thực hiện bởi nhóm đã xuất bản KTH-KRB.

Các hệ điều hành Windows 2000, Windows XP và Windows Server 2003 sử dụng một phiên bản thực hiện Kerberos làm phương pháp mặc định để xác thực. Những bổ sung của Microsoft vào bộ giao thức Kerberos được đề cập trong tài liệu RFC 3244  - http://tools.ietf.org/html/3244 ("Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols"). Hệ điều hành Mac OS X cũng sử dụng Kerberos trong các phiên bản Clients và Server của mình.

Năm 2005, nhóm làm việc của IETF về Kerberos cập nhật các đặc điểm kỹ thuật tại địa chỉ http://www.ietf.org/html.charters/krb-wg-charter.html. Các cập nhật gần đây bao gồm:

RFC 3961: "Các quy định về mật mã hóa và kiểm tra tổng";

RFC 3962: Mã hoá AES cho Kerberos 5";

RFC 4120: Phiên bản mới về tiêu chuẩn Kerberos V5: "The Kerberos Network Authentication Service (V5)". Phiên bản này thay thế RFC 1510, làm rõ các vấn đề của giao thức và cách sử dụng;

RFC 4121: Phiên bản mới của tiêu chuẩn GSS-API: "Cơ cấu GSS-API của Kerberos Version 5: Version 2."

Cơ chế hoạt động của hệ thống Kerberos

Kerberos không xây dựng các giao thức chứng thực phức tạp cho mỗi máy chủ mà hoạt động dựa trên một trung tâm phân phối khóa (Key Distribution Centre – KDC), bao gồm ba thành phần:

- Máy chủ xác thực (Authentication Server – AS): sử dụng các thông tin có trong database để xác thực người dùng.

- Máy chủ cấp vé ((Ticket Granting Server TGS): cung cấp vé dịch vụ cho phép người dùng truy nhập vào các máy chủ trên mạng.

- Cơ sở dữ liệu (Database): chứa dữ liệu của KDC và của người dùng (Client).

Client muốn truy cập các dịch vụ trên máy chủ ứng dụng (Applycation Server – AP) thì trước hết phải tiến hành xác thực mình với AS, sau đó chứng minh với TGS rằng mình đã được xác thực để nhận vé, cuối cùng chứng minh với AP rằng mình đã được chấp thuận để sử dụng dịch vụ.

Quá trình xác thực gồm 3 pha (Hình 1), cụ thể:

Pha 1: Client xác thực với AS để lấy về vé xin truy nhập TGS (Hình 2):

1. Client gửi yêu cầu xác thực (AS_REQ) tới AS yêu cầu xác thực:

- Người dùng nhập định danh (Client ID) và mật khẩu tại máy tính của mình (máy khách).

Hình 2: Client xác thực với AS.

- Phần mềm máy khách thực hiện hàm băm một chiều trên mật khẩu nhận được. Kết quả sẽ được dùng làm khóa bí mật của Client.


- Client gửi một gói tin (không mật mã hóa) tới AS để yêu cầu dịch vụ. Trong gói tin chỉ chứa Client ID, không chứa khoá bí mật lẫn mật khẩu của Client.

2. AS nhận được yêu cầu của Client, kiểm tra xem Client ID có nằm trong database của mình không. Nếu có thì gửi tới Client AS_REP gồm 2 gói tin sau:

- Gói tin A: "khóa phiên Client/TGS" được mã hóa với khóa bí mật của Client.

- Gói tin B: "Vé chấp thuận" (Ticket Granting Ticket – TGT), bao gồm Client ID, IP của người dùng, thời hạn của vé và "khóa phiên Client/TGS". TGT được mã hóa bằng khóa bí mật của TGS.

Khi nhận được 2 gói tin trên, Client nhập mật khẩu để giải mã gói tin A và thu được khóa phiên Client/TGS. Gói tin B được mã hóa với khóa bí mật của TGS nên không thể giải mã. Tại thời điểm này, Client đã có thể xác thực mình với TGS.

Pha 2: Client xác thực với TGS (Hình 3):

3. Client gửi TGS_REQ, gồm 2 gói tin C và D, tới TGS để yêu cầu dịch vụ:

- Gói tin C: TGT từ gói tin B và định danh của dịch vụ yêu cầu (Service ID).

Hình 3: Trao đổi giữa Client và TGS.

- Gói tin D: Phần xác thực, chứa Client ID và thời điểm yêu cầu (timestamp), được mã hóa bằng "khóa phiên Client/TGS".

4. TGS giải mã C bằng khóa bí mật của mình và thu được khóa phiên Client/TGS. Khóa này sau đó được dùng để giải mã D sẽ thu được phần xác thực. Tiếp theo TGS gửi TGS_REP trở lại cho Client chứa 2 gói tin sau:

- Gói tin E: "Vé Client/AP" (bao gồm Client ID, IP của Client, thời hạn sử dụng và "khóa phiên Client/AP") được mã hóa bằng khóa bí mật của AP.

- Gói tin F: "Khóa phiên Client/AP" mã hóa bằng "khóa phiên Client/TGS".

Sau khi nhận được 2 gói tin E và F, Client giải mã F để lấy khóa phiên Client/AP. Lúc này người dùng  đã có đủ thông tin để xác thực với AP.

Pha 3: Khách hàng truy cập và yêu cầu cấp phép sử dung dịch vụ (Hình 4):

5. Client kết nối với AP và gửi AP_REQ chứa 2 gói tin sau:

- Gói tin E: Vé thu được từ bước 4.

- Gói tin G: Phần xác thực mới, bao gồm Client ID và timestamp, được mã hóa với "khóa phiên Client/AP" thu được từ việc giải mã F.

Hình 4: Chứng thực với máy chủ dịch vụ.

6. AP giải mã E bằng khóa bí mật của mình để lấy khóa phiên Client/AP. Khóa này sau đó được dùng để giải mã G. Nhờ đọc được phần xác thực mới, AP gửi AP_REP chứa gói tin H tới người dùng để xác nhận định danh của mình cũng như khẳng định sự đồng ý sử dụng dịch vụ:

Gói tin H: Chứa giá trị timestamp trong G cộng thêm 1, mã hóa với "khóa phiên Client/AP".

7. Client giải mã gói tin H, xác nhận và kiểm tra thời gian có được cập nhật chính xác hay không. Nếu đúng thì người dùng có thể tin tưởng AP và bắt đầu tiến hành gửi yêu cầu sử dụng dịch vụ. AP cung cấp các dịch vụ mà Client yêu cầu.

Ưu điểm bảo mật khi sử dụng Kerberos

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à luôn được mã hóa.

- Kerberos không yê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).

Một số hạn chế của Kerberos

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ì toà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ạngthì toàn bộ dữ liệu người dùng sẽ bị đánh cắp và gây nguy cơ cho toàn bộ hệ thống.

Các phiên bản mới của Kerberos

Cho đến nay, Kerberos mới chỉ phát triển đến version 5. Một số phiên bản Kerberos mới được công bố gần đây bao gồm:

- krb5-1.8.6 công bố ngày 06/02/2012

- krb5-1.9.5 công bố ngày 26/4/2013

- krb5-1.10.6 công bố ngày 05/6/2013

- krb5-1.11.3 công bố ngày 03/6/2013

So với các phiên bản trước thì phiên bản mới nhất krb5-1.11.3 có một số thay đổi sau:

- Sửa lỗi UDP ping-pong dễ bị tổn thương trong dịch vụ kpasswd (thay đổi mật khẩu).

- Cải thiện khả năng tương tác với một số máy khách chạy Windows PKINIT.

- Khôi phục khả năng trao đổi multi-hop SAM-2 preauth mà phiên bản krb5-1.11 đã vô tình loại bỏ.

- Sửa lỗi tự trỏ lại của con trỏ null trong KDC PKINIT [CVE-2013-1415].

- Cải thiện mã hỗ trợ ASN.1, tạo bảng điểu khiển để giải mã cũng như lập mã.

- Cải thiện hiệu suất bộ nhớ cache lookaside của KDC.

- Bổ sung mục hỗ trợ khách hàng cho FAST OTP (RFC 6560)

- Xây dựng hỗ trợ mã hóa Camellia theo mặc định…

Bảng 1: Danh mục các lỗi đã được sửa trong  krb5-1.11.3.

ID

Subject

7596

PKINIT should allow missing DH param Q

7602

allow dh_min_bits >= 1024

7605

Set msg_type when decoding FAST requests

7626

Rename internal Camellia symbols

7637

Fix kpasswd UDP ping-pong [CVE-2002-2443]

7639

Transited realm checks sometimes fail for GSSAPI

7640

Clarify that kdc.conf and krb5.conf are merged

7641

Clarify krb5_rd_req documentation

7644

Sphinx doc build leaves python bytecode (.pyc) in release tarball

7653

Document preauth flags for service principals

7654

Clarify retiring-des based on user feedback

7655

Clean up dangling antecedent in allow_weak_crypto

Tài liệu tham khảo

[1] JASON GARMAN, “Kerberos: The Definitive Guide”, 2003.

[2] O'REILLY, “Protect Yourself Against Kerberos Attacks”, 2009

[3] J.T.KOHLvà B.C.NEUMAN, “The Kerberos network authentication service”, 2010

[4] URL: http://en.wikipedia.org/wiki/Kerberos_protocol.


Nổi bật Tạp chí Thông tin & Truyền thông
Đừng bỏ lỡ
An toàn hơn với giao thức xác thực Kerberos
POWERED BY ONECMS - A PRODUCT OF NEKO