Điểm:1

Làm cách nào để soạn nhiều giá trị để xác thực MAC?

lá cờ sr

Nếu dữ liệu tôi muốn xác thực bao gồm nhiều giá trị và tôi tính toán MAC chỉ bằng cách ghép nối các giá trị, kẻ thù có thể "chuyển" các ký tự trong các giá trị đó mà không làm mất hiệu lực MAC. Làm thế nào là vấn đề này phổ biến và giải quyết tốt nhất?

tôi đã tìm được câu hỏi hiện có này về MACing nhiều tin nhắn, nhưng tôi cảm thấy các giải pháp được đề xuất không khái quát tốt cho nhiều hơn hai thông báo.

Hãy xem xét ví dụ giả tạo sau:

Giả sử tôi có một máy chủ lưu trữ các mục nhật ký xác thực cho khách hàng. Máy khách viết một mục nhật ký, xác thực nó bằng MAC và gửi nó đến máy chủ. Sau đó, khi máy khách truy xuất các mục nhật ký từ máy chủ, nó sẽ có thể xác minh tính xác thực của chúng.

Giả sử các mục nhật ký có cấu trúc sau:

{
  được tạoTại: "1621012345",
  thông báo: "mục nhập đầu tiên"
}

Một cách ngây thơ, tôi có thể tạo MAC cho một mục nhật ký tôi như $$ mac = \text{HMAC}(K, l.createdAt \| l.message) $$ ở đâu $\|$ biểu thị nối và $K$ là chìa khóa bí mật.

Nếu tôi tiếp tục lưu trữ mục nhập nhật ký này và MAC trên máy chủ và truy xuất nó sau, máy chủ có thể quay lại

{
  được tạoAt: "1621012",
  thông báo: "345mục nhập đầu tiên",
  mac: "<MAC được tính ở trên>"
}

Từ 1621012 || 345mục nhập đầu tiên giống như 1621012345 || mục đầu tiên Tôi sẽ không nhận thấy thao tác khi kiểm tra MAC.

Lưu ý rằng trong trường hợp này, tôi thực sự nên phát hiện thao tác bằng cách xác thực độ dài của đã tạoAt. Nhưng điều đó chỉ hoạt động nếu độ dài là cố định chứ không phải nếu tôi có, chẳng hạn, tên tác giả thay vì dấu thời gian.

Tôi có thể nghĩ ra những cách sau đây để giải quyết vấn đề này:

1. Xen kẽ một dấu phân cách

Nếu tôi tính MAC của mình là $mac = \text{HMAC}(K, l.createdAt \| \text{':'} \| l.message)$ Tôi tin rằng cuộc tấn công này sẽ không thể thực hiện được nữa. Thoạt nhìn có vẻ như có vấn đề khi ký tự phân cách có thể xuất hiện trong tin nhắn. Nhưng điều đó chỉ làm cho không thể tái cấu trúc rõ ràng các giá trị từ chuỗi được nối, điều này không liên quan trong trường hợp này. Tôi không thể nghĩ ra bất kỳ cách nào để làm cho việc tính toán MAC trở nên mơ hồ ở đây. Giải pháp đơn giản này có an toàn không?

2. Giá trị băm trước khi nối

Tôi có thể tính toán MAC, ví dụ, như $mac = \text{HMAC}(K, \text{SHA256}(l.createdAt) \| \text{SHA256}(l.message))$ (hoặc bất kỳ hàm băm mật mã nào khác). Điều này đảm bảo rằng kẻ thù không thể thao túng các giá trị mà tôi nối một cách có ý nghĩa. Nó cũng đảm bảo rằng các giá trị được nối luôn có độ dài cố định. Băm có thêm bất kỳ giá trị nào so với ý tưởng đầu tiên không?

3. Xác thực toàn bộ dữ liệu có cấu trúc

Tôi cũng có thể tính toán MAC trên toàn bộ đối tượng JSON của mục nhật ký. Thực tế, điều này có nghĩa là tôi có các dấu phân cách phức tạp hơn, có ý nghĩa hơn (các phím và cú pháp). Về cơ bản, giống như một JWT. Lưu ý rằng cách tiếp cận này cũng có một số nhược điểm, chủ yếu là do mất tính linh hoạt của API và nhu cầu chuẩn hóa JSON. Có một bài viết blog tuyệt vời về điều này tại https://latacora.micro.blog/2019/07/24/how-not-to.html.


Tôi có thiếu bất kỳ giải pháp tốt nào cho vấn đề này không? Có một cách đề nghị để đối phó với điều này?

poncho avatar
lá cờ my
Một giải pháp thay thế sẽ là thêm vào trước mỗi mục với độ dài của nó; ví dụ. $HMAC_k( len(đã tạoAT) | đã tạoAT | len(tin nhắn) | tin nhắn )$. Tất nhiên, bạn cần một số cách chính tắc để chuyển đổi độ dài thành chuỗi byte; ví dụ. luôn chuyển đổi nó thành giá trị cuối nhỏ 4 byte ...
leftfold avatar
lá cờ sr
Điểm tốt! Tôi quên mất cái này. Tôi đã đọc [rằng ethereum đã từng làm điều đó](https://medium.com/mycrypto/the-magic-of-digital-signatures-on-ethereum-98fe184dc9c7) và sau đó đổi thành `32 || Keccak256(message)` (vì hàm băm luôn là 32 byte). Thật không may, động lực của sự thay đổi này không rõ ràng đối với tôi từ bài báo.
poncho avatar
lá cờ my
Một thứ khác mà bạn cần đưa vào MAC của mình là các nhãn trường; nếu kẻ tấn công có thể chuyển đổi "createdAT: time" thành "deleteBY : time", thì đó là điều chúng tôi muốn phát hiện...
leftfold avatar
lá cờ sr
Đúng, mặc dù tùy thuộc vào trường hợp sử dụng và cách khách hàng thực hiện xác thực. Tôi tưởng tượng khi máy khách tính toán MAC để xác thực, nó sẽ tìm `l.createdAt` và sử dụng giá trị đó cho MAC. Nếu không có trường `createdAt` thì đối tượng mà nó nhận được từ máy chủ đã không hợp lệ. (`deleteBy` sau đó có khả năng bị bỏ qua.) Điều đó nói rằng, nếu chúng ta muốn coi toàn bộ JSON là một "tài liệu", thì chúng ta nên bao gồm các nhãn. Tôi tin rằng điều này rất gần với việc chuẩn hóa và xác thực toàn bộ JSON như được nêu trong ý tưởng thứ 3.
Maarten Bodewes avatar
lá cờ in
Đối với các mục nhật ký, tôi sẽ MAC riêng các thông báo được chuẩn hóa, nhưng tôi sẽ bao gồm một bộ đếm. Dù sao thì bạn cũng sẽ muốn ghi nhật ký tập trung và tôi không muốn bao gồm bộ đếm dưới nano giây hoặc thực hiện các thủ thuật như đợi ít nhất một nano giây trước khi tiếp tục. Nếu đồng bộ hóa là sự cố, bạn có thể bao gồm ID dịch vụ hoặc thứ gì đó tương tự. Cơ sở dữ liệu rất giỏi về loại công cụ này.
Điểm:0
lá cờ sr

Để trả lời một phần câu hỏi của riêng tôi ở đây: ý tưởng 1 trên thực tế không an toàn.

Rốt cuộc, nó sẽ trở thành vấn đề nếu dấu phân cách xuất hiện trong giá trị. Xem xét sử dụng , như một dấu phân cách cho các giá trị Xin chào,Thế giới. Xen kẽ với , điều này mang lại Chào thế giới, trong đó dấu phẩy đầu tiên là một phần của tin nhắn và dấu phẩy thứ hai là dấu phân cách. Thật không may, các giá trị Xin chào,Thế giới đưa ra cùng một thông điệp. Vì vậy, suy cho cùng thì trực giác rằng thông điệp được soạn nên có thể phân tích cú pháp dường như vẫn đúng.

Như @poncho đã chỉ ra trong các nhận xét, điều này có thể được khắc phục bằng cách thêm trước độ dài của trường cho từng trường, thay vì sử dụng dấu phân cách.

Cá nhân tôi có thể sẽ sử dụng phiên bản thứ hai (băm các giá trị trước khi ghép nối). Nhưng tôi vẫn quan tâm nếu có ai khác gặp phải vấn đề này và cách bạn giải quyết nó.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.