Mã hóa xác thực – Wikipedia

Posted on by lordneo

Mã hóa được chứng thực ( AE ) và mã hóa được xác thực với dữ liệu liên quan ( AEAD ) là các hình thức mã hóa đồng thời đảm bảo tính bảo mật và tính xác thực của dữ liệu. Các thuộc tính này được cung cấp dưới một giao diện lập trình đơn, dễ sử dụng.

Nhu cầu về AE xuất hiện từ quan sát rằng việc kết hợp an toàn riêng biệt và các chế độ hoạt động mã hóa khối có thể dễ bị lỗi và khó khăn. [1][2] Điều này được xác nhận bởi một số về các cuộc tấn công thực tế được đưa vào các giao thức và ứng dụng sản xuất do triển khai không chính xác hoặc thiếu xác thực (bao gồm cả SSL / TLS). [3]

Khoảng năm 2000, một số nỗ lực đã phát triển xung quanh khái niệm này. Đặc biệt, sự quan tâm mạnh mẽ đối với các chế độ này đã được khơi dậy bởi việc xuất bản các chế độ IACBC và IAPM của Charanjit Jutla [4] vào năm 2000. Sáu chế độ mã hóa được xác thực khác nhau (cụ thể là OCB 2.0, Key Wrap, CCM, EAX, Encrypt-then-MAC (EtM ) và GCM) đã được tiêu chuẩn hóa trong ISO / IEC 19772: 2009. [5] Đã được phát triển thêm để đáp ứng với chào mời của NIST. [6] Các chức năng xốp có thể được sử dụng trong chế độ song công để cung cấp mã hóa xác thực. [7]

Một giao diện lập trình điển hình để thực hiện chế độ AE sẽ cung cấp các chức năng sau:

  • Mã hóa
    • Đầu vào: plaintext khóa và tùy chọn một tiêu đề trong bản rõ sẽ không được mã hóa, nhưng sẽ được bảo vệ bởi tính xác thực.
    • Đầu ra: mật mã và thẻ xác thực (mã xác thực tin nhắn).
  • Giải mã
    • Đầu vào: cexttext khóa thẻ xác thực và tùy chọn một tiêu đề . hoặc lỗi nếu thẻ xác thực không khớp với phần mã hóa được cung cấp hoặc .

Phần đầu được dự định để cung cấp bảo vệ tính xác thực và toàn vẹn cho siêu dữ liệu mạng hoặc lưu trữ mà việc bảo mật là không cần thiết, nhưng tính xác thực là mong muốn.

Ngoài việc bảo vệ tính toàn vẹn và bảo mật của thông điệp, mã hóa được xác thực có thể cung cấp bảo mật chống lại cuộc tấn công bản mã được chọn. Trong các cuộc tấn công này, một kẻ thù cố gắng giành lợi thế trước hệ thống mật mã (ví dụ: thông tin về khóa giải mã bí mật) bằng cách gửi mật mã được chọn cẩn thận cho một số "tiên tri giải mã" và phân tích kết quả được giải mã. Các lược đồ mã hóa được xác thực có thể nhận ra các bản mã được xây dựng không đúng và từ chối giải mã chúng. Điều này đến lượt nó ngăn chặn kẻ tấn công yêu cầu giải mã bất kỳ bản mã nào trừ khi anh ta tạo ra nó một cách chính xác bằng thuật toán mã hóa, điều này có nghĩa là anh ta đã biết bản rõ. Được thực hiện một cách chính xác, điều này loại bỏ tính hữu dụng của nhà tiên tri giải mã, bằng cách ngăn chặn kẻ tấn công có được thông tin hữu ích mà anh ta chưa sở hữu.

Nhiều chế độ mã hóa xác thực chuyên dụng đã được phát triển để sử dụng với mật mã khối đối xứng. Tuy nhiên, mã hóa được xác thực có thể được xây dựng một cách khái quát bằng cách kết hợp sơ đồ mã hóa và mã xác thực tin nhắn (MAC), với điều kiện:

Bellare và Namprempre (2000) đã phân tích ba thành phần của các nguyên thủy này và chứng minh rằng mã hóa tin nhắn và sau đó áp dụng MAC vào bản mã (phương pháp Encrypt-then-MAC) ngụ ý bảo mật chống lại cuộc tấn công mã hóa được chọn thích nghi, với điều kiện là cả hai chức năng đáp ứng các thuộc tính cần thiết. Katz và Yung đã điều tra khái niệm dưới cái tên "mã hóa không thể tha thứ" và chứng minh rằng nó ngụ ý bảo mật chống lại các cuộc tấn công mật mã đã chọn. [9]

Mã hóa được xác thực với dữ liệu liên quan (AEAD) [ chỉnh sửa ]

AEAD là một biến thể của AE trong đó dữ liệu được mã hóa cần cả xác thực và toàn vẹn thay vì chỉ toàn vẹn. AEAD liên kết dữ liệu liên quan (AD) với bản mã và bối cảnh nơi nó sẽ xuất hiện, do đó các nỗ lực "cắt và dán" một bản mã hợp lệ vào một ngữ cảnh khác được phát hiện và từ chối.

Ví dụ, nó được yêu cầu bởi các gói mạng. Tiêu đề cần tính toàn vẹn, nhưng phải được nhìn thấy; tải trọng, thay vào đó, cần sự toàn vẹn và cũng bảo mật. Cả hai đều cần tính xác thực.

Phương pháp tiếp cận mã hóa đã được xác thực [ chỉnh sửa ]

Encrypt-then-MAC (EtM) [ chỉnh sửa ] Bản rõ đầu tiên được mã hóa, sau đó MAC được tạo ra dựa trên bản mã kết quả. Bản mã và MAC của nó được gửi cùng nhau. Được sử dụng trong, ví dụ, IPsec. [10] Phương pháp tiêu chuẩn theo ISO / IEC 19772: 2009. [5] Đây là phương pháp duy nhất có thể đạt được định nghĩa bảo mật cao nhất trong AE, nhưng chỉ có thể đạt được khi MAC được sử dụng là "không thể tha thứ". [11] Vào tháng 11 năm 2014, tiện ích mở rộng TLS và DTLS cho EtM đã được xuất bản dưới dạng RFC 7366. Các loại mật mã EtM khác nhau cũng tồn tại cho SSHv2 (ví dụ [email protected] ).

Encrypt-and-MAC (E & M) [ chỉnh sửa ]

MAC được sản xuất dựa trên bản rõ và bản rõ được mã hóa mà không cần MAC. MAC của bản rõ và bản mã được gửi cùng nhau. Được sử dụng trong, ví dụ: SSH. [12] Mặc dù cách tiếp cận E & M chưa được chứng minh là không thể tha thứ cho chính nó, [11] có thể áp dụng một số sửa đổi nhỏ cho SSH để làm cho nó không thể bị tha thứ mặc dù cách tiếp cận. [ cần trích dẫn ]

MAC-then-Encrypt (MtE) [ chỉnh sửa ]

Một MAC được sản xuất dựa trên bản rõ, sau đó bản rõ và MAC được mã hóa cùng nhau để tạo ra bản mã dựa trên cả hai. Bản mã (chứa MAC được mã hóa) được gửi. Được sử dụng trong, ví dụ, SSL / TLS. [13] Mặc dù cách tiếp cận MtE chưa được chứng minh là không thể tha thứ cho chính nó, [11] việc triển khai SSL / TLS đã được chứng minh là không thể tha thứ được bởi Krawc: 05, người đã chứng minh rằng SSL / TLS trên thực tế được bảo mật vì mã hóa được sử dụng cùng với cơ chế MtE. [14] [ đáng ngờ – thảo luận ] Mặc dù bảo mật lý thuyết, phân tích sâu hơn về SSL / TLS được mô hình hóa bảo vệ như MAC-then-pad-then-mã hóa, tức là bản rõ trước tiên được đệm theo kích thước khối của chức năng mã hóa. Lỗi đệm thường dẫn đến các lỗi có thể phát hiện được ở phía người nhận, từ đó dẫn đến các cuộc tấn công sấm sét, chẳng hạn như Lucky Thirteen.

Xem thêm [ chỉnh sửa ]

Tài liệu tham khảo [ chỉnh sửa ]

  1. ^ "mọi người đã làm khá kém khi họ cố gắng để kết hợp một sơ đồ mã hóa truyền thống (chỉ bảo mật) và mã xác thực tin nhắn (MAC) "trong: M. Bellare; P. Rogaway; D. Wagner. "Chế độ mã hóa được chứng thực thông thường" (PDF) . NIST . Truy xuất ngày 12 tháng 3, 2013 .
  2. ^ "rất dễ dàng vô tình kết hợp các sơ đồ mã hóa an toàn với MAC an toàn và vẫn nhận được các sơ đồ mã hóa được chứng thực không an toàn" trong: T. Kohno; J. Viega & D. Whites. "Chế độ mã hóa xác thực CWC (dữ liệu liên kết)" (PDF) . NIST . Truy xuất ngày 12 tháng 3, 2013 .
  3. ^ "Thất bại của mật mã khóa bí mật" (PDF) . Daniel J. Bernstein . Truy cập ngày 12 tháng 3, 2013 .
  4. ^ Jutl, Charanjit S. (2000-08-01). "Các chế độ mã hóa với tính toàn vẹn tin nhắn gần như miễn phí". Lưu trữ ePrint mật mã: Báo cáo 2000/039 . IACR . Truy xuất 2013-03-16 .
  5. ^ a b "Công nghệ thông tin – Kỹ thuật bảo mật – Mã hóa xác thực". 19772: 2009 . ISO / IEC . Truy xuất ngày 12 tháng 3, 2013 .
  6. ^ "Phát triển chế độ mã hóa". NIST . Truy cập 17 tháng 4, 2013 .
  7. ^ Đội Keccak. "Nhân đôi miếng bọt biển" (PDF) .
  8. ^ Katz, J.; Yung, M. B. Schneier, chủ biên. "Mã hóa và các chế độ hoạt động an toàn không thể mã hóa được chọn lọc". Mã hóa phần mềm nhanh (FSE): Kỷ yếu 2000; . Bài giảng trong khoa học máy tính. Springer-Verlag. 1978 : 284 Từ299.
  9. ^ "CAESAR: Cạnh tranh cho mã hóa xác thực: Bảo mật, khả năng áp dụng và mạnh mẽ" . Truy xuất ngày 12 tháng 3, 2013 .
  10. ^ "Thuật toán bảo mật và toàn vẹn riêng biệt". RFC 4303 . Lực lượng đặc nhiệm kỹ thuật Internet (IETF) . Đã truy xuất 2018-09-12 .
  11. ^ a b "Mã hóa xác thực: Mối quan hệ giữa các khái niệm và phân tích mô hình thành phần chung". M. Bellare và C. Namprempre . Truy xuất ngày 13 tháng 4, 2013 .
  12. ^ "Tính toàn vẹn dữ liệu". RFC 4253 . Lực lượng đặc nhiệm kỹ thuật Internet (IETF) . Truy xuất 2018-09-12 .
  13. ^ "Bảo vệ tải trọng hồ sơ". RFC 5246 . Lực lượng đặc nhiệm kỹ thuật Internet (IETF) . Truy xuất 2018-09-12 .
  14. ^ "Thứ tự mã hóa và xác thực để bảo vệ thông tin liên lạc (Hoặc: SSL bảo mật như thế nào?)" (PDF) H. Krawchot . Truy cập ngày 13 tháng 4, 2013 .
General
  • Bellare, M.; Namprempre, C. trong Khoa học máy tính, Springer-Verlag, 1976 : 531, doi: 10.1007 / 3-540-44448-3_41, ISBN 978-3-540-41404-9

Liên kết ngoài [ chỉnh sửa ]