Tôi đã thực hiện IPsec VPN trên ASA 8.0 và tôi hiểu một chút về điều đó. Người khởi tạo bắt đầu bằng cách gửi chính sách ISAKMP của mình cho người phản hồi và người phản hồi sẽ gửi lại chính sách phù hợp. Sau đó, khóa Diffie-Hellman được trao đổi, và sau đó cả hai gửi khóa chia sẻ trước cho người kia để xác thực.
Bây giờ chúng tôi có hai chìa khóa:
Khóa nào được sử dụng để mã hóa khóa chia sẻ trước?
Câu trả lời:
Bạn đã hỏi một câu hỏi tuyệt vời. Câu hỏi có vẻ rất đơn giản, nhưng thực tế câu trả lời có phần phức tạp hơn. Tôi sẽ làm hết sức mình để trả lời nó một cách cô đọng. Ngoài ra, vì bạn đã đề cập đến ISAKMP, tôi sẽ giả định rằng bạn quan tâm đến IKEv1. Mọi thứ thay đổi một chút đối với IKEv2 (tốt, rất nhiều), nhưng tôi đã muốn đề cập đến câu trả lời dưới đây chỉ tương quan với IKEv1.
Giai đoạn 1 có thể được thực hiện trong hai mod khác nhau: Chế độ chính và Chế độ xâm lược. Trong bất kỳ chế độ nào, tin nhắn đầu tiên được gửi bởi Người khởi tạo và tin nhắn thứ hai được gửi bởi Người trả lời. Cả hai thông điệp này bao gồm những gì được biết đến trong thế giới mật mã là Nonce . Một Nonce chỉ đơn giản là một số được tạo ngẫu nhiên để sử dụng trong việc tạo khóa. (thuật ngữ Nonce xuất phát từ _N_umber được sử dụng _Once_) . Vì vậy, sau tin nhắn 1 và tin nhắn 2, cả hai bên đều biết Nonces của nhau.
Nonce được kết hợp với Khóa chia sẻ trước để tạo giá trị Seed để tạo khóa bí mật. Phần tương đối của IKE RFC có ở đây:
For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b)
SKEYID là giá trị Seed mà sau này sẽ được sử dụng để tạo các khóa bí mật bổ sung. Khóa được chia sẻ trước và cả hai giá trị Nonce (Ni_b là Nonce của Initiator và Nr_B là Nonce của Người phản hồi) được kết hợp bằng cách sử dụng PRF hoặc Hàm ngẫu nhiên Psuedo. Một PRF giống như một thuật toán băm, ngoại trừ kết quả có thể có nhiều bit như bạn cần.
Bây giờ, nếu ban đầu bạn đang thực hiện Chế độ chính, các tin nhắn 3 và 4 sẽ chia sẻ các khóa công khai của Người khởi xướng và Người phản hồi (tương ứng). Cả hai đều sử dụng các giá trị này để tạo ra bí mật chung của Diffie-Hellman . Nếu bạn đang thực hiện chế độ Hung hăng, các giá trị DH Public này cũng được bao gồm trong Thông báo 1 và Thông báo 2 (cùng với Nonces).
Giá trị Seed sau đó được kết hợp với Bí mật chung của DH (và một vài giá trị khác) để tạo ba Khóa phiên : Khóa phái sinh, Khóa xác thực và Khóa mã hóa. RFC tuyên bố như vậy:
Kết quả của Chế độ chính hoặc Chế độ xâm lược là ba nhóm tài liệu khóa được xác thực:
SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
SKEYID_d, _a và _e là ba khóa Phiên được đề cập ở trên. SKEYIDlà giá trị Seed. g^xylà bí mật được chia sẻ của DH. CKY-Ivà CKI-Rlà Cookie khởi xướng và phản hồi, đây chỉ là các giá trị được tạo ngẫu nhiên bổ sung được sử dụng sau này để xác định hiệp hội bảo mật và trao đổi ISAKMP cụ thể này. 0 1 2là các số nguyên chữ 0, 1 và 2. Biểu tượng ống |đại diện cho phép nối.
Trong mọi trường hợp, tất cả các giá trị này được kết hợp với nhau bằng PRF tạo ra ba khóa Phiên:
Khóa xác thực và Khóa mã hóa được sử dụng để bảo mật / mã hóa cuộc đàm phán Giai đoạn 2 sau đó. Trong Chế độ chính, các thông báo 5 và 6 của Giai đoạn 1 cũng được bảo vệ bởi các phím này. Hơn nữa, mọi trao đổi thông tin ISAKMP trong tương lai (DPD, sự kiện Rekey, Xóa tin nhắn, v.v.) cũng được bảo vệ bởi hai khóa này.
Khóa phái sinh được trao cho IPsec và IPsec tạo tài liệu Khóa riêng từ Khóa này. Nếu bạn nhớ lại, IPsec không bao gồm một cơ chế trao đổi khóa, vì vậy cách duy nhất để nó có được các khóa bí mật là đặt chúng theo cách thủ công (vốn là cổ xưa và không bao giờ thực sự được thực hiện nữa), HOẶC phụ thuộc vào một dịch vụ bên ngoài cung cấp tài liệu khóa, như ISAKMP.
RFC nói như vậy:
SKEYID_e là tài liệu khóa được ISAKMP SA sử dụng để bảo vệ tính bảo mật của tin nhắn.
SKEYID_a là tài liệu khóa được ISAKMP SA sử dụng để xác thực các thông điệp của nó.
SKEYID_d là vật liệu khóa được sử dụng để lấy các khóa cho các hiệp hội bảo mật không phải ISAKMP.
Với tất cả những gì đã nói, chúng tôi có thể tham khảo lại câu hỏi của bạn: Khóa nào được sử dụng để bảo mật Khóa chia sẻ trước?
Trong Chế độ chính, Khóa chia sẻ trước (PSK) được xác minh trong Tin nhắn 5 và 6. Tin nhắn 5 và 6 được bảo vệ bởi các khóa phiên ISAKMP tạo ra, được mô tả ở trên.
Trong Chế độ xâm lược, không có tin nhắn nào trong cuộc đàm phán được mã hóa. Và PSK được xác minh trong Tin nhắn 2 và 3. Lưu ý, tôi đã nói trong cả hai trường hợp PSK được xác minh và tôi không bao giờ nói PSK được trao đổi . Rõ ràng, nếu không có gì trong chế độ Tích cực được mã hóa và bạn chỉ cần gửi Khóa chia sẻ trước qua dây không được mã hóa, sẽ có một lỗ hổng bảo mật rất lớn.
May mắn cho chúng tôi, các nhà văn của ISAKMP đã nghĩ về điều đó. Và kết quả là, họ đã tạo ra một phương pháp đặc biệt để xác minh rằng mỗi bên có PSK chính xác, mà không thực sự chia sẻ nó qua dây. Có hai mục được sử dụng để xác thực cho mỗi Peer mà cả hai đều có cùng PSK: Phương thức nhận dạng và Hash nhận dạng .
Các đồng nghiệp VPN có thể chọn nhận dạng chính mình bằng nhiều phương pháp khác nhau; thông thường nhất, các đồng nghiệp sẽ chỉ sử dụng địa chỉ IP nguồn của họ. Nhưng họ có tùy chọn sử dụng FQDN hoặc Tên máy chủ. Mỗi trong số đó, cùng với giá trị tương quan cho phương thức đã chọn, là những gì tạo nên Phương thức Nhận dạng. Vì vậy, ví dụ, nếu tôi có IP 5.5.5.5 và tôi muốn sử dụng địa chỉ IP của mình để nhận dạng chính mình, Phương thức ID của tôi sẽ thực sự là [Địa chỉ IP, 5.5.5.5] . (Lưu ý: Cả hai giá trị tạo nên toàn bộ Phương thức ID)
Phương thức ID sau đó được kết hợp (sử dụng PRF) với giá trị Seed mà chúng ta đã thảo luận trước đó (SKEYID) và một vài giá trị khác, để tạo Hash nhận dạng . Hãy nhớ lại rằng, thứ đã tạo ra SKEYID ở vị trí đầu tiên là Khóa được chia sẻ trước.
Phương thức ID và ID Hash sau đó được gửi qua dây và bên kia cố gắng tạo lại ID Hash bằng cùng một công thức. Nếu người nhận có thể tạo lại ID Hash tương tự, điều đó chứng tỏ với người nhận rằng người gửi phải có khóa chia sẻ chính xác.
Điều này được mô tả trong RFC ở đây:
Để xác thực trao đổi, bộ khởi tạo giao thức tạo HASH_I và bộ phản hồi tạo HASH_R trong đó:
HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )
IDii và IDir là Phương thức ID. Và HASH_I và HASH_R là hàm băm của Initiator và responder. Cả hai đều được chia sẻ trong Giai đoạn 1. Từ RFC:
Khi thực hiện xác thực khóa chia sẻ trước, Chế độ chính được xác định như sau:
Initiator Responder ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, HASH_I --> <-- HDR*, IDir, HASH_RChế độ hung hăng với khóa chia sẻ trước được mô tả như sau:
Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDii --> <-- HDR, SA, KE, Nr, IDir, HASH_R HDR, HASH_I -->
Và bây giờ, cuối cùng chúng tôi có thể trả lời câu hỏi của bạn đầy đủ:
Khóa được chia sẻ trước được kết hợp bằng PRF với Nonces và một loạt các giá trị khác mà bất kỳ ai khác biết trong cuộc đàm phán. Kết quả là một giá trị chỉ có thể đạt được bởi hai bên nếu cả hai bên bắt đầu với cùng một giá trị - còn gọi là cùng khóa chia sẻ trước. Giá trị kết quả là những gì được chia sẻ trên dây, cho phép hai bên xác minh rằng họ đã khớp với Khóa chia sẻ trước mà không thực sự tiết lộ bất kỳ thông tin nào về chính Khóa trước chia sẻ.
Chế độ chính an toàn hơn một bước bằng cách mã hóa việc trao đổi "giá trị kết quả" được mô tả ở trên, khiến cho việc trích xuất bất kỳ thông tin hữu ích nào về khóa Pre-Shared-Key trở nên khó khăn hơn.
(có vẻ như tôi đã thất bại thảm hại khi trả lời ngắn gọn này)
Câu trả lời của bạn nằm trong câu hỏi của bạn: Trao đổi Diffie-Hellman được sử dụng để tạo một khóa chung để trao đổi một cách an toàn một khóa chung (tức là chia sẻ trước).
Xem điều này: /security/67953/under Hiểu-diffie-hellman-key -exchange