Điểm:0

Sử dụng bí mật được chia sẻ làm dữ liệu xác thực Ngoài băng trong ghép nối Bluetooth

lá cờ br

Theo Thông số kỹ thuật Bluetooth, quá trình ghép nối bắt đầu bằng việc Slave gửi gói quảng cáo có thể kết nối và sau đó Master bắt đầu kết nối. Trong xác thực LE Legacy OOB, Khóa tạm thời 128 bit bí mật (TK) được cho là được chia sẻ qua một số kênh bảo mật khác, ví dụ: NFC, được sử dụng trong xác thực phản hồi thử thách, như sau:

  1. Master chọn Mrand ngẫu nhiên và tính toán Mconfirm = AES(TK, AES(TK, Mrand XOR p1) XOR p2)
  2. Slave chọn Srand ngẫu nhiên và tính toán Sconfirm = AES(TK, AES(TK, Srand XOR p1) XOR p2)
  3. Master gửi Mconfirm
  4. Slave gửi xác nhận
  5. Master gửi Mrand và Slave xác nhận
  6. Slave gửi Srand và Master xác nhận
  7. Khóa ngắn hạn được tính là STK = AES(TK, Srand[65:128] || Mrand[65:128])
  8. Thông tin liên lạc hơn nữa được mã hóa bằng STK.

trong đó p1 và p2 chứa địa chỉ của Master và Slave cùng với một số thông tin về lệnh ghép nối, v.v.

Bây giờ, giả sử Master và Slave chia sẻ khóa bí mật (SK) được ghi vào chúng khi xuất xưởng. Tôi định gửi một dữ liệu ngẫu nhiên 128 bit (RD) trong gói quảng cáo để cả hai bên có thể sử dụng nó để tính toán TK là TK = AES(SK, RD). Tôi chưa thấy cách tiếp cận này ở bất kỳ nơi nào khác và có rất ít tài liệu về phân tích xác thực LE Legacy OOB theo như tôi có thể thấy.

Vì vậy, đây có phải là một cách tiếp cận hợp lệ? những vấn đề với nó là gì?

Các thông tin và giả định liên quan khác:

  1. Tải trọng của gói quảng cáo có thể kết nối đã được mã hóa và xác thực qua CCM bằng cách sử dụng một khóa khác cùng với bảo vệ phát lại thông qua bộ đếm và/hoặc dấu thời gian.
  2. Có nhiều chủ và nô lệ trong đó chủ ở các vị trí cố định và nô lệ thì di động. Mỗi nô lệ có một SK duy nhất và các bậc thầy có thể tra cứu nó từ cơ sở dữ liệu an toàn.
  3. Không thể sử dụng liên kết vì sẽ không có tương tác của người dùng để xác thực và các khóa liên kết không thể được chia sẻ giữa các chủ.
  4. LE Secure Connections được cho là an toàn hơn nhưng yêu cầu sự tương tác của người dùng để xác thực, điều mà chúng tôi không thể cung cấp.
  5. Kết nối sẽ được thực hiện cứ sau 1-10 phút cho mỗi nô lệ.
Điểm:2
lá cờ us

Điều này không gây ấn tượng với tôi như một giao thức xác thực rất tốt. Bạn có thể xem $(Mrand, \textsf{AES}_{TK}(\textsf{AES}_{TK}(Mrand \oplus p_1) \oplus p_2))$ như một nỗ lực của một CBC-MAC ngẫu nhiên của $p_1\|p_2$, với $Ông$ là vectơ khởi tạo.

Thật không may, CBC-MAC ngẫu nhiên bị hỏng hoàn toàn dưới dạng MAC. Giả sử đối thủ nhìn thấy MAC hợp lệ $(R,T) = \bigl(R, \textsf{AES}_K(\textsf{AES}_K(R \oplus p_1) \oplus p_2)\bigr)$ của một tin nhắn $p_1 \| p_2$. Sau đó, nó có thể sản xuất $(R \oplus \delta, T)$ đó là MAC hợp lệ của tin nhắn $(p_1 \oplus \delta) \| p_2$.

Ngoài nỗ lực kém tại MAC, giao thức này còn bị các cuộc tấn công lặp lại tầm thường. Mỗi bên chọn một giá trị ngẫu nhiên ảnh hưởng đến chỉ tin nhắn của riêng họ. Để ngăn phát lại, mỗi bên nên liên kết các thông báo giao thức của họ với một giá trị ngẫu nhiên được chọn bởi khác bữa tiệc.

Thậm chí còn có một cuộc tấn công phản ánh. Trong giao thức này nếu chủ gửi $Mrand, Mconfirm$ sau đó khách hàng có thể phản hồi lại $Srand=Ông$$Sconfirm=Mconfirm$, điều này sẽ xác minh chính xác trừ khi có nhiều giao thức hơn bạn đề cập.

Kết quả của các cuộc tấn công này là một điểm cuối tin rằng nó đã được ghép nối thành công, mặc dù điểm cuối kia không biết khóa ngoài băng tần $TK$. Tuy nhiên, kẻ tấn công không thể lấy được khóa phiên.

lá cờ br
Cảm ơn vì câu trả lời. Tôi đã kiểm tra lại p1 và p2 bao gồm những gì. Hóa ra p1 chỉ chứa các tham số kết nối, các tham số này phải không đổi giữa tất cả các kết nối. Vì vậy, chúng ta có thể bỏ qua bất kỳ nỗ lực kết nối nào nếu p1 khác với dự kiến. p2 bao gồm cả địa chỉ chính và phụ. Điều này có đủ để ngăn chặn sự cố CBC-MAC ngẫu nhiên không?
lá cờ br
TK thay đổi cho mỗi phiên theo giá trị ngẫu nhiên do nô lệ cung cấp trong gói quảng cáo và khóa bí mật dùng chung được cung cấp tại thời điểm sản xuất. Tôi đoán nó ngăn chặn các cuộc tấn công phát lại?
lá cờ br
Tôi đoán cuộc tấn công phản chiếu có thể được ngăn chặn bằng cách kiểm tra $Sconfirm \neq Mconfirm$ hoặc $Srand \neq Mrand$? Tôi hy vọng điều này được thực hiện bởi nhà cung cấp ngăn xếp. Tôi có thể yêu cầu một bản vá nếu nó không được thực hiệ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.