Phân phối khóa (Key) trong IP SEC

Phân phối khóa (Key) trong IP SEC

Rate this post

Phần quản lý chính của IPsec liên quan đến việc xác định và phân phối khóa bí mật. Một yêu cầu điển hình là bốn khóa để giao tiếp giữa hai ứng dụng: cặp truyền và nhận cho cả tính toàn vẹn và bảo mật. Tài liệu Kiến trúc IPsec yêu cầu hỗ trợ hai loại quản lý khóa:

  • Manual: Người quản trị hệ thống định cấu hình thủ công từng hệ thống với các khóa riêng của nó và với các khóa của các hệ thống giao tiếp khác. Điều này là thực tế cho các môi trường nhỏ, tương đối tĩnh.
  • Automated: Hệ thống tự động cho phép tạo khóa theo yêu cầu cho SA và tạo điều kiện sử dụng khóa trong một hệ thống phân tán lớn với cấu hình đang phát triển.

Giao thức quản lý khóa tự động mặc định cho IPsec được gọi là ISAKMP / Oakley và bao gồm các phần tử sau:

  • Oakley Key Determination Protocol: Oakley là một giao thức trao đổi khóa dựa trên thuật toán Diffie-Hellman nhưng cung cấp thêm tính bảo mật. Oakley chung chung là nó không quy định các định dạng cụ thể.
  • Internet Security Association and Key Management Protocol (ISAKMP):  ISAKMP cung cấp một khuôn khổ để quản lý khóa Internet và cung cấp hỗ trợ giao thức cụ thể, bao gồm các định dạng, để thương lượng các thuộc tính bảo mật.

ISAKMP tự nó không ra lệnh cho một thuật toán trao đổi khóa cụ thể; đúng hơn, ISAKMP bao gồm một tập hợp các loại thông báo cho phép sử dụng nhiều thuật toán trao đổi khóa. Oakley là thuật toán trao đổi khóa cụ thể được yêu cầu sử dụng với phiên bản ban đầu của ISAKMP.

Các bài viết liên quan:

Trong IKEv2, các thuật ngữ Oakley và ISAKMP không còn được sử dụng nữa, và có sự khác biệt đáng kể so với việc sử dụng Oakley và ISAKMP trong IKEv1. Tuy nhiên, chức năng cơ bản là giống nhau. Trong phần này, chúng tôi mô tả đặc tả IKEv2.

Key Determination Protocol 

Xác định khóa IKE là một cải tiến của thuật toán trao đổi khóa Diffie-Hellman. Nhớ lại rằng Diffie-Hellman liên quan đến sự tương tác sau đây giữa người dùng A và B. Có thỏa thuận trước về hai tham số toàn cục: q, một số nguyên tố lớn; và a, một gốc nguyên thủy của q. A chọn một số nguyên ngẫu nhiên Xa làm khóa riêng của nó và truyền cho B khóa công khai của nó Ya = Xa mod q. Tương tự, B chọn một số nguyên ngẫu nhiên XB làm khóa riêng và truyền cho A khóa công khai YB = Xb mod q. Giờ đây, mỗi bên có thể tính khóa phiên bí mật:

Phân phối khóa (Key) trong IP SEC

Thuật toán Diffie-Hellman có hai tính năng hấp dẫn:

  • Khóa bí mật chỉ được tạo khi cần thiết. Không cần thiết phải lưu trữ các khóa bí mật trong một thời gian dài, làm cho chúng dễ bị tổn thương hơn.
  • Sàn giao dịch không yêu cầu cơ sở hạ tầng tồn tại từ trước ngoài thỏa thuận về các tham số toàn cầu.

Tuy vậy, Có một số điểm yếu đối với Diffie-Hellman, như đã chỉ ra trong [HUIT98].

  • Nó không cung cấp bất kỳ thông tin nào về danh tính của các bên.
  • Nó là đối tượng của một cuộc tấn công man-in-the-middle, trong đó bên thứ ba C tấn công B trong khi giao tiếp với A và mạo danh A trong khi giao tiếp với B. Cả A và B đều thương lượng khóa với C, điều này có thể sau đó nghe và vượt qua lưu lượng truy cập. Cuộc tấn công man-in-the-middle tiến hành như:
  1. B gửi khóa công khai YB của mình trong một thông điệp được gửi đến A (xem Hình 10.2).
  2. Kẻ thù (E) chặn tin nhắn này. E lưu khóa công khai của B và gửi tin nhắn đến A có User ID của B nhưng khóa công khai của E là YE. Tin nhắn này là

được gửi theo cách mà nó có vẻ như được gửi từ máy chủ của B hệ thống. A nhận tin nhắn của E và lưu khóa công khai của E với ID người dùng của B. Tương tự, E gửi một tin nhắn đến B bằng khóa công khai của E, với mục đích đến từ A.

  1. B tính toán khóa bí mật K1 dựa trên khóa riêng của B và YE. A tính toán khóa bí mật K2 dựa trên khóa riêng của A và YE. E tính K1 bằng khóa bí mật XE và YB của E và máy tính K2 sử dụng XE và YA.
  2. Kể từ bây giờ, E có thể chuyển tiếp các thông điệp từ A đến B và từ B sang A, thay đổi cách cư trú của họ trên đường đi một cách thích hợp theo cách mà cả A và B đều không biết rằng họ chia sẻ thông tin liên lạc với E.
  • Nó chuyên sâu về mặt tính toán. Kết quả là, nó dễ bị tấn công tắc nghẽn, trong đó đối thủ yêu cầu một số lượng khóa cao. Nạn nhân sử dụng tài nguyên máy tính đáng kể để thực hiện phép tính lũy thừa mô-đun vô ích hơn là công việc thực sự.

Xác định chính của IKE được thiết kế để giữ lại những ưu điểm của Diffie- Hellman, đồng thời chống lại những điểm yếu của nó.

Xem thêm Mã hóa mật mã: các khái niệm cơ bản

FEATURES OF IKE KEY DETERMINATION

Thuật toán xác định khóa IKE được đặc trưng bởi năm tính năng quan trọng:

  1. Nó sử dụng một cơ chế được gọi là cookie để ngăn chặn các cuộc tấn công làm tắc nghẽn.
  2. Nó cho phép hai bên thương lượng một nhóm; về bản chất, điều này chỉ định các tham số toàn cục của trao đổi khóa Diffie-Hellman.
  3. Nó sử dụng các nonces để đảm bảo chống lại các cuộc tấn công phát lại.
  4. Nó cho phép trao đổi Giá trị khóa công khai Diffie-Hellman.
  5. Nó xác thực trao đổi Diffie-Hellman để ngăn chặn các cuộc tấn công của kẻ trung gian.

Chúng ta đã thảo luận về Diffie-Hellman. Hãy để chúng tôi xem xét phần còn lại của lần lượt các yếu tố này. Đầu tiên, hãy xem xét vấn đề tắc nghẽn các cuộc tấn công. Trong cuộc tấn công này, đối thủ giả mạo địa chỉ nguồn của người dùng hợp pháp và gửi khóa Diffie- Hellman công khai cho nạn nhân. Sau đó nạn nhân thực hiện phép tính lũy thừa mô-đun để tính khóa bí mật. Các tin nhắn lặp đi lặp lại kiểu này có thể làm tắc nghẽn hệ thống của nạn nhân với công việc vô ích. Việc trao đổi cookie yêu cầu mỗi bên gửi một số giả, cookie, trong thông điệp ban đầu mà bên kia thừa nhận. Sự xác nhận này phải được lặp lại trong thông điệp đầu tiên của trao đổi khóa Diffie-Hellman. Nếu địa chỉ nguồn bị giả mạo, đối thủ sẽ không có câu trả lời. Do đó, đối thủ chỉ có thể buộc người dùng tạo ra xác nhận chứ không thể thực hiện phép tính Diffie-Hellman.

IKE yêu cầu việc tạo cookie phải đáp ứng ba yêu cầu cơ bản:

  1. Cookie phải phụ thuộc vào các bên cụ thể. Điều này ngăn kẻ tấn công lấy cookie bằng địa chỉ IP thực và cổng UDP, sau đó sử dụng nó để đưa nạn nhân vào các yêu cầu từ các địa chỉ IP hoặc cổng được chọn ngẫu nhiên.
  2. Không được để bất kỳ ai khác ngoài tổ chức phát hành có thể tạo ra các món ăn sẽ được chấp nhận bởi tổ chức đó. Điều này ngụ ý rằng tổ chức phát hành sẽ sử dụng thông tin bí mật địa phương trong quá trình tạo và xác minh sau đó của

bánh quy. Không thể suy ra thông tin bí mật này từ bất kỳ cookie cụ thể nào. Điểm của yêu cầu này là tổ chức phát hành không cần lưu các bản sao cookie của mình, sau đó chúng dễ bị phát hiện hơn, nhưng có thể xác minh xác nhận cookie đến khi cần.

  1. Phương pháp xác minh và tạo cookie phải nhanh chóng để ngăn chặn các cuộc tấn công nhằm phá hoại tài nguyên của bộ xử lý.

Phương pháp được đề xuất để tạo cookie là thực hiện băm nhanh (ví dụ: MD5) trên các địa chỉ Nguồn và Đích IP, các cổng Nguồn và Đích UDP và một giá trị bí mật được tạo cục bộ.

Xác định khóa IKE hỗ trợ việc sử dụng các nhóm khác nhau để trao đổi khóa Diffie-Hellman. Mỗi nhóm bao gồm định nghĩa của hai tham số toàn cục-ters và danh tính của thuật toán. Đặc điểm kỹ thuật hiện tại bao gồm các nhóm sau.

  • Tính lũy thừa mô-đun với mô-đun 768-bit
Phân phối khóa (Key) trong IP SEC
  • Mô-đun lũy thừa với mô đun 1024 bit
Phân phối khóa (Key) trong IP SEC
  • Mô-đun lũy thừa với mô đun 1536 bit
    • Các thông số được xác định
  • Nhóm đường cong elliptic trên 2155
    • Trình tạo (hệ thập lục phân): X = 7B, Y = 1C8
    • Tham số đường cong elip (hệ thập lục phân): A = 0, Y = 7338F
  • Nhóm đường cong elliptic trên 2185
    • Trình tạo (hệ thập lục phân): X = 18, Y = D
    • Tham số đường cong elip (hệ thập lục phân): A = 0, Y = 1EE9

Ba nhóm đầu tiên là thuật toán Diffie-Hellman cổ điển sử dụng lũy ​​thừa mô-đun. Hai nhóm cuối cùng sử dụng tương tự đường cong elliptic cho Diffie-Hellman.

Xác định chính của IKE sử dụng các nonces để đảm bảo chống lại các cuộc tấn công phát lại. Mỗi nonce là một số giả ngẫu nhiên được tạo cục bộ. Nonces xuất hiện trong các câu trả lời và được mã hóa trong một số phần nhất định của sàn giao dịch để đảm bảo việc sử dụng chúng.

Ba phương pháp xác thực khác nhau có thể được sử dụng với xác định khóa IKE:

  • Digital signatures: Việc trao đổi được xác thực bằng cách ký tên lẫn nhau hàm băm có thể lấy được; mỗi bên mã hóa băm bằng khóa riêng của mình. Hàm băm được tạo trên các thông số quan trọng, chẳng hạn như ID người dùng và số khác.
  • Public-key encryption: Trao đổi được xác thực bằng cách mã hóa các tham số như ID và số không bằng khóa riêng của người gửi.
  • Symmetric-key encryption: Một khóa có nguồn gốc từ một số cơ chế ngoài băng tần có thể được sử dụng để xác thực trao đổi bằng cách mã hóa đối xứng các tham số trao đổi.

IKEV2 EXCHANGES

Giao thức IKEv2 liên quan đến việc trao đổi thông điệp theo cặp. Hai cặp trao đổi đầu tiên được gọi là trao đổi ban đầu (Hình 19.11a). Trong lần trao đổi đầu tiên, hai đồng nghiệp trao đổi thông tin liên quan đến các thuật toán mật mã và các tham số bảo mật khác mà họ sẵn sàng sử dụng cùng với các giá trị khác nhau và Diffie-Hellman (DH).

Kết quả của việc trao đổi này là thiết lập một SA đặc biệt được gọi là IKE SA (xem Hình 19.2). SA này xác định các tham số cho một kênh an toàn giữa các đồng đẳng mà qua đó các cuộc trao đổi thông điệp tiếp theo diễn ra. Do đó, tất cả các trao đổi tin nhắn IKE tiếp theo đều được bảo vệ bằng mã hóa và xác thực tin nhắn. Trong lần trao đổi thứ hai, hai bên xác thực lẫn nhau và thiết lập một IPsec SA đầu tiên được đặt trong SADB và được sử dụng để bảo vệ thông tin liên lạc thông thường (tức là không phải IKE) giữa các đồng nghiệp.

Phân phối khóa (Key) trong IP SEC

Trao đổi CREATE_CHILD_SA có thể được sử dụng để thiết lập các SA khác nhằm bảo vệ lưu lượng truy cập. Trao đổi thông tin được sử dụng để trao đổi thông tin quản lý, thông báo lỗi IKEv2 và các thông báo khác.

Header and Payload Formats 

IKE định nghĩa các thủ tục và định dạng gói để thiết lập, thương lượng, sửa đổi và xóa các liên kết bảo mật. Là một phần của việc thành lập SA, IKE xác định tải trọng chotrao đổi dữ liệu xác thực và tạo khóa. Các định dạng tải trọng này cung cấp một khuôn khổ nhất quán độc lập với giao thức trao đổi khóa cụ thể, thuật toán mã hóa và cơ chế xác thực.

IKE HEADER FORMAT

Một thông báo IKE bao gồm một tiêu đề IKE được theo sau bởi một hoặc nhiều trọng tải hơn. Tất cả điều này được thực hiện trong một giao thức vận tải. Đặc tả chỉ ra rằng việc triển khai phải hỗ trợ việc sử dụng UDP cho giao thức truyền tải.

Hình 19.12a cho thấy định dạng tiêu đề cho một thông báo IKE. Nó bao gồm các trường sau đây.

  • Initiator SPI (64 bits): Một giá trị được bộ khởi tạo chọn để xác định một hiệp hội bảo mật IKE duy nhất (SA).
  • Responder SPI (64 bits): Một giá trị do trình phản hồi chọn để xác định một IKE SA duy nhất.
  • Next Payload (8 bits): Cho biết loại trọng tải đầu tiên trong thông báo; tải trọng sẽ được thảo luận trong phần phụ tiếp theo.
  • Major Version (4 bits): Cho biết phiên bản chính của IKE đang được sử dụng.
  • Minor Version (4 bits): Cho biết phiên bản nhỏ đang được sử dụng.
Phân phối khóa (Key) trong IP SEC

Hình 19.12 Định dạng IKE

  • Exchange Type (8 bits): Cho biết loại trao đổi; những điều này sẽ được thảo luận sau trong phần này.
  • Flags (8 bits): Cho biết các tùy chọn cụ thể được đặt cho trao đổi IKE này. Ba bit được xác định cho đến nay. Bit khởi tạo cho biết gói này có được gửi bởi bộ điều khiển SA hay không. Bit phiên bản cho biết liệu máy phát có khả năng sử dụng số phiên bản chính cao hơn số phiên bản hiện được chỉ định hay không. Bit phản hồi cho biết liệu đây có phải là phản hồi cho một tin nhắn có chứa cùng một ID tin nhắn hay không.
  • Message ID (32 bits): Được sử dụng để kiểm soát việc truyền lại các gói bị mất và khớp các yêu cầu và phản hồi.
  • Length (32 bits): Độ dài của tổng số tin nhắn (tiêu đề cộng với tất cả các trọng tải) tính bằng octet.

IKE PAYLOAD TYPES

Tất cả các tải trọng IKE bắt đầu với cùng một tiêu đề trọng tải chung được thể hiện trong Hình 19.12b. Trường Trọng tải Tiếp theo có giá trị là 0 nếu đây là tải trọng cuối cùng trong thông báo; nếu không giá trị của nó là loại của trọng tải tiếp theo. Trường Độ dài tải trọng cho biết độ dài tính bằng octet của tải trọng này, bao gồm cả tiêu đề trọng tải chung.

Bit quan trọng là 0 nếu người gửi muốn người nhận bỏ qua tải trọng này nếu người đó không hiểu mã loại tải trọng trong trường Tải trọng tiếp theo của phần trước khối hàng. Nó được đặt thành 1 nếu người gửi muốn người nhận từ chối toàn bộ thư này nếu người đó không hiểu loại trọng tải.

Bảng 19.3 tóm tắt các loại trọng tải được xác định cho IKE và liệt kê các trường hoặc tham số là một phần của mỗi trọng tải. Tải trọng SA được sử dụng để bắt đầu

Bảng 19.3 Các loại tải trọng IKE

Phân phối khóa (Key) trong IP SEC

thành lập của một SA. Tải trọng có cấu trúc phức tạp, phân cấp. Cáctrọng tải có thể chứa nhiều đề xuất. Mỗi đề xuất có thể chứa nhiều ưu đãi. Mỗi giao thức có thể chứa nhiều biến đổi. Và mỗi biến đổi có thể chứa nhiều thuộc tính. Các phần tử này được định dạng dưới dạng cấu trúc con trong tải trọng như sau.

  • Proposal: Cấu trúc con này bao gồm số đề xuất, ID giao thức (AH, ESP hoặc IKE), chỉ báo về số lần chuyển đổi và sau đó là cấu trúc con chuyển đổi. Nếu có nhiều hơn một giao thức được bao gồm trong mộtđề xuất, sau đó có một cấu trúc con đề xuất tiếp theo với cùng một số hiệu quả.
  • Transform: Các giao thức khác nhau hỗ trợ các kiểu biến đổi khác nhau. Các dạng chuyển đổi được sử dụng chủ yếu để xác định các thuật toán mật mã được sử dụng với một giao thức cụ thể.
  • Attribute: Mỗi biến đổi có thể bao gồm các thuộc tính sửa đổi hoặc hoàn thành đặc điểm kỹ thuật của biến đổi. Một ví dụ là độ dài khóa.

Trọng tải Key Exchange có thể được sử dụng cho nhiều công nghệ trao đổi khóa, bao gồm Oakley, Diffie-Hellman và trao đổi khóa dựa trên RSA được PGP sử dụng. Trường dữ liệu Trao đổi khóa chứa dữ liệu cần thiết để tạo khóa phiên và phụ thuộc vào thuật toán trao đổi khóa được sử dụng.

Tải trọng Nhận dạng được sử dụng để xác định danh tính của các đồng nghiệp đang giao tiếp và có thể được sử dụng để xác định tính xác thực của thông tin. Thông thường, trường Dữ liệu ID sẽ chứa địa chỉ IPv4 hoặc IPv6.

Trọng tải Chứng chỉ chuyển một chứng chỉ khóa công khai. Trường Mã hóa chứng chỉ cho biết loại chứng chỉ hoặc thông tin liên quan đến chứng chỉ, có thể bao gồm những thông tin sau:

  • PKCS # 7 đã bọc chứng chỉ X.509
  • Chứng chỉ PGP
  • Khóa đã ký DNS
  • Chứng chỉ X.509 — chữ ký
  • Chứng chỉ X.509 — trao đổi khóa
  • Mã thông báo Kerberos
  • Danh sách thu hồi chứng chỉ (CRL)
  • Danh sách thu hồi quyền hạn (ARL)
  • Chứng chỉ SPKI

Tại bất kỳ thời điểm nào trong trao đổi IKE, người gửi có thể bao gồm một trọng tải Yêu cầu chứng chỉ để yêu cầu chứng chỉ của thực thể giao tiếp khác. Tải trọng có thể liệt kê nhiều loại chứng chỉ được chấp nhận và nhiều tổ chức phát hành chứng chỉ được chấp nhận.

Tải trọng Xác thực chứa dữ liệu được sử dụng cho mục đích xác thực tin nhắn. Các loại phương pháp xác thực được xác định cho đến nay là chữ ký số RSA, mã toàn vẹn thông điệp khóa chia sẻ và chữ ký số DSS.

Trọng tải Nonce chứa dữ liệu ngẫu nhiên được sử dụng để đảm bảo tính trực tiếp trong quá trình trao đổi và để bảo vệ khỏi các cuộc tấn công phát lại.

Tải trọng Thông báo chứa thông tin lỗi hoặc trạng thái được liên kết với SA này hoặc thương lượng SA này. Bảng sau liệt kê các thông báo IKE thông báo.

Phân phối khóa (Key) trong IP SEC

Tải trọng Xóa cho biết một hoặc nhiều SA mà người gửi đã xóa khỏi cơ sở dữ liệu của mình và do đó không còn hợp lệ.

Trọng tải ID nhà cung cấp chứa một hằng số do nhà cung cấp xác định. Hằng số được sử dụng bởi các nhà cung cấp để xác định và nhận ra các trường hợp từ xa của các triển khai của họ. Cơ chế này cho phép nhà cung cấp thử nghiệm các tính năng mới trong khi vẫn duy trì khả năng tương thích ngược.

Trọng tải của Bộ chọn lưu lượng cho phép các đồng nghiệp xác định các luồng gói để xử lý bởi các dịch vụ IPsec.

Trọng tải được mã hóa chứa các trọng tải khác ở dạng được mã hóa. Định dạng tải trọng được mã hóa tương tự như định dạng của ESP. Nó có thể bao gồm IV nếu thuật toán mã hóa yêu cầu nó và ICV nếu xác thực được chọn.

Tải trọng cấu hình được sử dụng để trao đổi thông tin cấu hình giữa các đồng nghiệp IKE.

Trọng tải của Giao thức xác thực mở rộng (EAP) cho phép các IKE SA được xác thực bằng EAP.

Các thuật toán mật mã trong IPSEC và IKEv

Các giao thức IPsecv3 và IKEv3 dựa trên nhiều loại thuật toán mật mã khác nhau. Như chúng ta đã thấy trong cuốn sách này, có rất nhiều thuật toán mật mã của mỗi loại, mỗi loại có nhiều thông số khác nhau, chẳng hạn như kích thước khóa. Để thúc đẩy khả năng tương tác, hai RFC xác định các bộ thuật toán và thông số mật mã được khuyến nghị cho các ứng dụng khác nhau.

RFC 4308 định nghĩa hai bộ mật mã để thiết lập mạng riêng ảo. Suite VPN-A phù hợp với bảo mật VPN công ty thường được sử dụng trong các triển khai IKEv1 cũ hơn tại thời điểm phát hành IKEv2 vào năm 2005. Suite VPN-B cung cấp bảo mật mạnh hơn và được khuyến nghị cho các VPN mới áp dụng IPsecv3 và IKEv2.

Bảng liệt kê các thuật toán và tham số cho hai bộ. Có một số điểm cần lưu ý về hai dãy phòng này. Lưu ý rằng đối xứng

Bảng 19.4 Bộ ứng dụng mật mã cho IPsec

VPN-AVPN-B
Mã hóa ESP3DES-CBCAES-CBC (khóa 128 bit)
Tính toàn vẹn của ESPHMAC-SHA1-96AES-XCBC-MAC-96
Mã hóa IKE3DES-CBCAES-CBC (khóa 128 bit)
IKE PRFHMAC-SHA1AES-XCBC-PRF-128
IKE IntegrityHMAC-SHA1-96AES-XCBC-MAC-96
Nhóm DH IKEMODP 1024-bitMODP 2048-bit
  1. Mạng riêng ảo (RFC 4308)
Phân phối khóa (Key) trong IP SEC
  1. NSA Suite B (RFC 4869)

mật mã, VPN-A dựa trên 3DES và HMAC, trong khi VPN-B hoàn toàn dựa vào AES. Ba loại thuật toán khóa bí mật được sử dụng:

  • Encryption: Để mã hóa, chế độ chuỗi khối mật mã (CBC) được sử dụng.
  • Message authentication: Để xác thực tin nhắn, VPN-A dựa vào HMAC với SHA-1 với đầu ra được cắt ngắn còn 96 bit. VPN-B dựa trên một biến thể của CMAC với đầu ra được cắt ngắn còn 96 bit.
  • Pseudorandom function: IKEv2 tạo ra các bit giả ngẫu nhiên bằng cách sử dụng lặp đi lặp lại MAC được sử dụng để xác thực thông báo.

RFC 4869 xác định bốn bộ mật mã tùy chọn tương thích với thông số kỹ thuật Bộ B của Cơ quan An ninh Quốc gia Hoa Kỳ. Năm 2005, NSA đã ban hành Suite B, trong đó xác định các thuật toán và sức mạnh cần thiết để bảo vệ cả thông tin nhạy cảm nhưng chưa được phân loại (SBU) và thông tin đã phân loại để sử dụng trong chương trình Hiện đại hóa mật mã [LATT09]. Bốn bộ được định nghĩa trong RFC 4869 cung cấp các lựa chọn cho ESP và IKE. Bốn bộ này được phân biệt bởi sự lựa chọn các điểm mạnh của thuật toán mật mã và sự lựa chọn liệu ESP có cung cấp cả tính bảo mật và tính toàn vẹn hoặc chỉ toàn vẹn hay không. Tất cả các bộ đều cung cấp khả năng bảo vệ tốt hơn so với hai bộ VPN được định nghĩa trong RFC 4308.

Bảng 19.4b liệt kê các thuật toán và tham số cho hai bộ. Như với RFC 4308, ba loại thuật toán khóa bí mật được liệt kê:

  • Encryption: Đối với ESP, mã hóa đã xác thực được cung cấp bằng chế độ GCM với khóa AES 128 bit hoặc 256 bit. Đối với mã hóa IKE, CBC được sử dụng, giống như đối với các bộ VPN.
  • Message authentication: Đối với ESP, nếu chỉ cần xác thực thì GMAC sẽ được sử dụng. Như đã thảo luận trong Chương 12, GMAC chỉ đơn giản là phần xác thực của GMC. Đối với IKE, xác thực tin nhắn được cung cấp bằng HMAC với một trong các hàm băm SHA-3.
  • Pseudorandom function: Cũng như các bộ VPN, IKEv2 trong các bộ này tạo ra các bit giả ngẫu nhiên bằng cách sử dụng lặp đi lặp lại MAC được sử dụng để xác thực tin nhắn.

Đối với thuật toán Diffie-Hellman, việc sử dụng các nhóm đường cong elliptic modulo a số nguyên tố được chỉ định. Để xác thực, các chữ ký số theo đường cong elliptic được liệt kê. Các tài liệu IKEv2 ban đầu sử dụng chữ ký điện tử dựa trên RSA. Có thể đạt được sức mạnh tương đương hoặc lớn hơn bằng cách sử dụng ECC với ít bit khóa hơn.

Leave a Reply