2. Mục lục
● Tại sao nên sử dụng Kerberos ?
● Hình thức mã hóa, đặc điểm và lưu ý
● Mã hóa trong Kerberos
● Cơ sở dữ liệu của Kerberos
● Cách hoạt động
● Nhược điểm
● Các nguy cơ tấn công
3. Tại sao nên sử dụng Kerberos
● Mật khẩu không được truyền qua mạng
● Mật khẩu không được lưu trữ ở máy khách, sẽ bị xóa bỏ
ngay khi sử dụng
● Mật khẩu phải được mã hóa ngay cả trong CSDL máy
chủ
● Đăng nhập một lần
● Xác thực lẫn nhau giữa người dùng và máy chủ
● Quản lý thông tin dễ dàng :
● Admin vô hiệu hóa user tại một địa điểm duy nhất mà
không cần thao tác trên cụm máy chủ khác nhau.
● User thay đổi mật khẩu sẽ được cập nhập ở tất cả dịch
vụ cùng lúc
● Chuẩn hóa thông tin xác thực ở nhiều nơi khác nhau
4. Hình thức mã hóa
Mã khóa đối xứng là cùng một khóa được
sử dụng để mã hóa và giải mã
● ciphertext = E_key (plaintext)
● plaintext = D_key (ciphertext )
Mã khóa bất đối xứng (khóa công khai) là mã hóa
và giải mã khác nhau
● ciphertext = E_Public_key (plaintext)
● plaintext = D_Secret_key (ciphertext )
E là mã hóa, D là giải mã
5. Đặc điểm & lưu ý
● Khóa bất đối xứng có tốc độ xử lý chậm hơn khóa đối xứng
● Mã xác thực tin nhắn (MAC) với các khóa đối xứng có thể cung cấp thông tin toàn vẹn
● Các cuộc tấn công vào mã đối xứng :
○ known-plaintext attacks
○ chosen plaintext attacks
○ differential cryptanalysis (Thám mã vi phân)
○ linear cryptanalysis (Thám mã tuyến tính)
6. Mã hóa trong Kerberos
● Kerberos sử dụng mã hóa đối xứng
● Sử dụng hàm băm string2key(password, principals)
● Thuật toán băm : MD5, CRC32, SHA1
● Hoạt động :
def string2key(passwd, principals):
return algorithm.hash(“passwd” + “principals”)
key = string2key(password, principals)
7. Lợi thế mã hóa Kerberos
● Các service khác nhau cùng một người dùng sẽ cùng sử dụng chung 1 password để
đồng bộ
● 2 principals có cùng @example.com và password nhưng khác lĩnh vực làm việc sẽ mã
hóa 2 key khác nhau, dễ dàng trong việc quản lý các công việc khác nhau.
○ Ex :
■ quangdm/whitehat@ghtk.vn
■ quangdm/blackhat@ghtk.vn
■ 2 principle cùng user, realm và password : quangdm sẽ sinh ra 2 key khác nhau khi qua
hàm hash
8. Cơ sở dữ liệu Kerberos
● Principal
● encryption key & related kvno
● Thời hạn tối đa của ticket liên quan đến principal
● Thời hạn tối đa của ticket liên quan đến principal có thể gia hạn ( chỉ kerberos 5)
● Attributes hoặc flag đặc trưng của vé tickets
● Hạn sử dụng của password
● Hạn sử dụng của principal và dựng hoạt động cấp vé ticket
9. Hoạt động
Ticket
2 loại request ticket từ client(KDC - REQ)
● AS_REQs: Lấy TGT
● TGS_REQs: Lấy Service ticket
Authenticator
client id và timestamp
10. User client-base login
1. Client: enter user name, password
2. Client: Hash để transforms password -> key mã hóa đối xứng
11. Client Authentication
1. Client: gửi UserId tới AS
2. AS: Kiểm tra nếu client tồn tại trong Database. Gửi message cho client :
a. A: Client/TGS session key encrypted by secret client/user
b. B: TGT (client Id, client address, lifetime, TGS session key) encrypted by key TGS
3. Client: Giải mã gói tin A bằng cách hass password và sẽ có TGS session key
12. Client Service Authentication
1. Client: gửi message tới TGS:
a. C: TGT và id request service
b. D: Authenticator encrypted by TGS session key
2. TGS:
a. Lấy TGT bằng TGS secret key
b. Có TGS session key
c. Sử dụng ss key decrypts D
d. So sánh client ID trong vé (C) và authenticator (D). Nếu match gửi gói tin:
i. E: Client to server ticket (client Id, client address, lifetime, TGS session key)
encrypted by service’s secret key
ii. F: Client/Server session key encrypted Client/TGS session key
13. Client Service Request
1. Client: connect tới server gửi 2 message:
a. E: (Client to Server ticket)
b. G: new authenticator (client Id, timestamp) encrypted by Client/Server session key
2. Server:
a. Giải mã E bằng secret key, lấy ra client/Server session key
b. Dùng Session key giải mã G
c. So sánh ClientId E và G
d. Nếu match, gửi gói tin confirm H(timestamp trong authenticator encrypted by
client/server session key)
3. Client decrypts H, check timestamp đúng và tin server bắt đầu start request
4. Server provide request service của Client
14. Nhược điểm
● Cần thiết việc cài server kerberos dự phòng
● Yêu cầu đồng bộ clocks
● Giao thức quản trị chưa được chuẩn hóa và khác nhau giữa các máy chủ
● Mỗi dịch vụ mạng yêu cầu một tên host name riêng sẽ cần bộ khóa riêng. Phức tạp trong lưu
trữ
● Kerberos yêu cầu acc user, user client và service server phải có quan hệ đáng tin cậy với nhau
● Vì sử dụng mã hóa đối xứng hoặc bất đối xứng, việc xác thực tập trung ở KDC nên có nguy cơ
tấn công mạo danh
15. Các nguy cơ tấn công
● Dictionary attack online, offline
● Attacker với passive network access
● Attacker với active network access
16. Online dictionary attack
● Thử các password request tới KDC
● Visible với KDC
Có thể sử dụng account lockout
Nhưng, attacker deny access với những client hợp lệ
17. Offline dictionary attack
● Attacker lấy bản mã được tạo từ password server trả về và cố gắng thử các password để giải mã nó
● Invisible với KDC và có thể thực hiện nhanh hơn online attack
● Để ngăn chặn những kẻ tấn công không có quyền truy cập file giữa client và server, đặt flag:
kadmin: add_principal +requires_preauth -allow_svr princname
18. Attacker with passive network access
Attacker:
● Monitor packet gửi giữa user và KDC
● Nhưng không thể change hoặc insert các gói tin
● Quan sát form xác thực, mã hóa timestamp
Ngăn chặn:
● Sử dụng SPAKE preauthentication trên KDC và client
● Sử dụng HTTPs proxy nếu Attacker không có quyền kiểm soát proxy
● Sử dụng FAST hoặc anonymous PKINIT
19. Attacker with active network access
Attacker:
● Inject hoặc modify packet gửi giữa user và KDC
● Đánh lừa phần mềm client bằng cách gửi ciphertext
Ngăn chặn:
● Sử dụng SPAKE preauthentication và setting disable_encrypted_timestamp config client
● Sử dụng HTTPs proxy, configure client krb5.conf realm
● Sử dụng FAST