IKEv1 so với IKEv2 khi dùng khóa chia sẻ trước: khác nhau ở đâu trong xác thực

Hai cổng được cấu hình cùng một khóa chia sẻ trước hoàn tất một lần bắt tay, và bản ghi gói tin không cho thấy bí mật nào đi qua đường truyền. Đó là phần người ta nhớ. Phần thú vị là điều mỗi phiên bản thực sự tính toán để chứng minh bí mật đã được biết, vì IKEv1 và IKEv2 dựng bằng chứng đó từ những đầu vào khác nhau và để lộ những thông tin khác nhau trong khi làm vậy. Đọc hai dấu vết cạnh nhau và khác biệt không còn là bề ngoài.

Bằng chứng phải đạt được điều gì

Diffie-Hellman cho cả hai bên một giá trị chung mà bất kỳ ai quan sát cũng có thể tính được nửa công khai của nó. Tự nó không chứng minh gì về danh tính: kẻ tấn công hoàn tất trao đổi khóa có cùng giá trị chung với cổng của bạn. Bước xác thực tồn tại để gắn trao đổi đó với một bí mật chỉ các bên dự định nắm giữ, và với danh tính cùng các tham số mà họ đã đồng ý.

Chính sự gắn kết đó là lý do hàm băm bao phủ nhiều hơn khóa. Nếu chỉ bao phủ bí mật, kẻ tấn công có thể phát lại nó vào một trao đổi khác với danh tính hoặc đề xuất khác.

IKEv1 Main Mode: dẫn xuất SKEYID rồi chứng minh

Main Mode chạy sáu bản tin. Cặp đầu tiên thương lượng hiệp hội bảo mật, cặp thứ hai trao đổi giá trị công khai Diffie-Hellman và nonce, cặp thứ ba mang danh tính cùng hàm băm xác thực dưới lớp mã hóa vừa được thiết lập. RFC 2409 định nghĩa cấu trúc: với xác thực bằng khóa chia sẻ trước, SKEYID được dẫn xuất từ bí mật và cả hai nonce, còn vật liệu khóa về sau dẫn xuất từ SKEYID, giá trị chung Diffie-Hellman, các cookie và hằng số.

Hàm băm trong bản tin thứ năm và thứ sáu được tính trên giá trị Diffie-Hellman, hai cookie, đề xuất và danh tính người gửi, lấy SKEYID làm khóa. Bên nhận tính lại bằng bí mật đã cấu hình của mình. Sự không khớp kết thúc trao đổi, và bí mật không bao giờ là tải trọng.

Aggressive Mode nén cùng công việc vào ba bản tin, nghĩa là danh tính và hàm băm xác thực đi trước khi có kênh mã hóa. Đó là rủi ro thực sự với một bí mật dễ đoán, và nó tách biệt khỏi câu hỏi bí mật có được truyền hay không. IKEv1 đã bị RFC 9395 ngừng khuyến nghị, nên một dấu vết cũ là bài tập chẩn đoán chứ không phải mục tiêu triển khai.

IKEv2: cách dẫn xuất khác và tải trọng AUTH khác

IKEv2 không dùng lại lịch khóa của IKEv1. Các khóa IKE ban đầu đến từ một hạt giống dựng từ nonce và giá trị chung Diffie-Hellman, và các hiệp hội bảo mật con dẫn xuất từ đó. Khóa chia sẻ trước hoàn toàn không đưa vào hạt giống.

Xác thực sau đó xuất hiện dưới dạng tải trọng AUTH. Với xác thực bằng khóa chia sẻ, RFC 7296 quy định một dạng đệm của bí mật, tạo ra bằng cách băm bí mật với chuỗi cố định Key Pad for IKEv2, rồi băm dữ liệu trao đổi đã ký và danh tính bằng khóa đã đệm đó. Bên xác minh có thể dựng lại cùng giá trị; người quan sát thì không, nếu không có bí mật.

Hãy để ý điều đã thay đổi. Trong IKEv1 bí mật được nướng vào lịch khóa trước khi hàm băm xác thực tồn tại; trong IKEv2 lịch khóa độc lập với bí mật và bằng chứng là một tải trọng riêng gắn với các octet đã ký. Cùng một bảo đảm về khái niệm, khác bộ máy, và đó là lý do tên tham số cùng bản ghi không ánh xạ một-một.

Người quan sát thực sự biết được gì

Giá trị công khai Diffie-Hellman, đề xuất, nonce và cookie đều hiện ra trong cả hai phiên bản. Danh tính hiện ra ở IKEv1 Aggressive Mode và được bảo vệ trong các trường hợp khác. Bí mật không bao giờ hiện ra.

Câu cuối đó có một giới hạn đáng nói. Một bí mật yếu do con người chọn có thể bị tấn công bằng cách đoán: kẻ tấn công tính giá trị xác thực sẽ là gì với một bí mật ứng viên rồi so sánh. IKEv1 Aggressive Mode khiến việc này rẻ nhất vì bằng chứng nằm rõ, và các tiêu chuẩn nói chung cảnh báo về bí mật có entropy thấp. Không bao giờ truyền bí mật không đồng nghĩa với làm cho một bí mật tồi trở nên an toàn.

Cần làm gì với so sánh này

Dùng một bí mật duy nhất cho mỗi cặp đối tác, sinh nó từ nguồn ngẫu nhiên, và luân chuyển nó qua chính kênh cung cấp đã phân phối nó. Nếu bí mật nằm trong mẫu cấu hình được gửi tới mọi chi nhánh, thì một chỗ bị xâm phạm là tất cả đều bị xâm phạm.

Ưu tiên xác thực dựa trên chứng chỉ ở nơi chi phí vận hành chấp nhận được, vì nó loại bỏ vấn đề đoán bí mật chung và cho mỗi bên một danh tính riêng. Nơi nào vẫn giữ khóa chia sẻ trước, hãy để nó dài, thu hẹp phạm vi, và coi phiên bản IKE là quyết định bảo mật chứ không phải chi tiết tương tác.