Tính ngẫu nhiên và xác thực trên đầu ra giá trị ngắn (48 bit)

Tôi muốn triển khai ứng dụng khách tạo giá trị 48 bit ngẫu nhiên và gửi chúng dưới dạng tin nhắn quảng bá. Chúng tôi cũng giả định rằng có một người nhận hợp pháp nhận được các giá trị đó (vì vậy, có một số loại xác thực trước đã xảy ra nhưng nó không quan trọng ở đây. Chúng tôi cũng có thể giả sử máy khách/người nhận chia sẻ một khóa chung $K$). Vì đây là những thông báo quảng bá, điều đó cũng có nghĩa là bất kỳ ai cũng có thể chặn các giá trị đó. Tôi muốn những giá trị đó có hai thuộc tính:

1. Kẻ tấn công khó đoán được giá trị ngẫu nhiên tiếp theo trong chuỗi
2. Người nhận sẽ có thể xác minh rằng các giá trị này thực sự đến từ máy khách cụ thể

Tôi đã nghĩ về một kế hoạch đơn giản như sau:

Khách hàng

1. $t$ = AES-CTR($K$, nonce||bộ đếm, random_plaintext)â

2. $r = t â K$ (giữ 48 bit cuối cùng)

3. Phát tin $t, r$

Tôi sử dụng AES-CTR để tạo chuỗi tìm kiếm ngẫu nhiên tạm thời $t$ và sau đó XOR nó với khóa một lần nữa để tạo giá trị ngẫu nhiên của tôi.Sau đó tôi giữ 48 bit cuối cùng và phát cả hai $t$ và $r$. Sau đó, người nhận có thể chỉ cần:

Người nhận

1. $r' = t â K$ (giữ 48 bit cuối cùng)
2. Thẩm tra $r' == r$

Nếu kiểm tra thành công thì anh ta xác thực ứng dụng khách vì chỉ anh ta biết cùng một khóa $K$. Ngoài ra, giá trị là đầu ra của AES-CTR phải khá ngẫu nhiên, nghĩa là rất khó để ai đó đoán được giá trị tiếp theo.

Chương trình này có đạt được yêu cầu của tôi không? Việc cắt bớt 48 bit cuối có gây rủi ro bảo mật không?

Chương trình này có đạt được yêu cầu của tôi không? Việc cắt bớt 48 bit cuối có gây rủi ro bảo mật không?

Kế hoạch bị phá vỡ bởi một kẻ thù thụ động chỉ nhận được một cặp $(t,r)$. Quan sát rằng 48 bit cuối cùng của khóa có thể được phục hồi dưới dạng $K[:48] = t \oplus r$. Do đó, kẻ tấn công bây giờ có thể gửi tùy ý $(t^*, r^*)$ các giá trị mà người nhận sẽ chấp nhận. Nhắc lại rằng người xác minh làm như sau

$r' = t' \oplus K$ (chỉ giữ 48 bit cuối cùng); thẩm tra $r = r'$

Chúng tôi thấy rằng kiến ​​​​thức về phần còn lại của khóa là không cần thiết.

Ngoài ra, các giá trị 48 bit cung cấp khả năng bảo vệ va chạm thấp, nhưng điều đó có thể tốt cho ứng dụng của bạn...

phát lại: một cuộc tấn công đơn giản hơn là chơi lại cặp $(r, t)$. Mô tả không cho biết cách người nhận kiểm tra điều này.

Giải pháp tiềm năng: Từ mô tả ban đầu, có vẻ như người nhận khá hạn chế về mặt tính toán và họ chỉ có thể tính toán xors là nhất chứ không phải AES-CTR chẳng hạn. Điều gì sẽ là kỳ lạ với những điều sau đây

vì vậy, có một số loại xác thực trước đã xảy ra nhưng nó không quan trọng ở đây

Dù sao, một giải pháp khả thi là sử dụng hai hàm giả ngẫu nhiên nếu người nhận có thể thực hiện nhiều hơn xors. (Tôi nghi ngờ nó an toàn ...). Ban đầu, mở rộng $K$ vào trong $K_1, K_2, K_3$ có độ dài phù hợp.

Người gửi thực hiện như sau

1. $ r = $ AES-CTR$(K_1, bộ đếm)$ (giữ 48 bit cuối cùng)
2. gửi $count, r, \tau = HMAC(K_2, counter,r)$

Người nhận làm như sau

1. Khi nhận được $r, \tau$, thẩm tra $\tau$
2. Bộ đếm séc đã tăng lên
3. làm lại $r$.

Một số nhận xét:

• Phát sóng ở đây thậm chí không cần thiết nếu người gửi và người nhận là người dùng chung đồng hồ.
• Giải pháp thay thế có một số vấn đề về độ bền trong trường hợp khởi động lại, như Paul đã chỉ ra trong một nhận xét.