Telemetry: Add an HMAC style authentication scheme to the telemetry system

Đang mở
  • Có gì không ổn?
#136 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
30/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Ít trao đổi
Công nghệ
c
Lĩnh vực
embedded-iot, networking, security

Hướng nghiên cứu

Bắt đầu bằng cách truy vết quá trình tạo thông điệp đo từ xa trên máy tính bay, truyền qua LoRa, và tiếp nhận cũng như xác thực trong đường dẫn trạm mặt đất/SDEC. Xem xét phương án thay thế trong Flight-Computer-Firmware issue 191 và xác định thiết kế xác thực, cách xử lý khóa, ảnh hưởng đến kích thước thông điệp và hành vi đối với thông điệp không hợp lệ trước khi triển khai. Công việc được xem là hoàn tất khi biện pháp bảo mật đã thống nhất được tích hợp ở cả hai đầu và dữ liệu sai định dạng hoặc chưa được xác thực không bị truyền tiếp.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

enhancement

Requester: @ETSells

Describe the solution you'd like
The ground station currently provides no validation for the data it receives over LoRa. This is a security vulnerability. For the flight ecosystem, there is no impact on safety margins, so we have not prioritized it.

However, the new liquid feed system requires onboard flight data in order to function properly, so the criticality of this function will increase for that project. We need some security measure to provide an assurance that the received data is not maliciously malformed.

The flight computer has the highest design assurance and security assurance standards of any of SDR's projects, so we can safely consider it a trusted device. If the flight computer asserts that data is good, we can trust it. So, we need some method of determining that the device sending the data is the flight computer.

We can do this via some form of hashing scheme. Consider the following:

  1. A private key is generated in SDEC. This can be up to (256 bytes - lora_msg_size).
  2. That private key is uploaded to the flight computer and lives in the preset struct.
  3. When a telemetry message is generated, we take a buffer with the private key and the message, and then we hash over it using SHA-256.
  4. We can then append this hash to the generated message (either half of it (16 bytes) or the whole thing (32 bytes)). This brings our message length up to 64 bytes or 80 bytes, depending on how much of it we use.
  5. Continue the transmission process as normal
  6. The ground station receives the message, and if the CRC matches, it passes the whole thing including the hash to SDEC.
  7. On the other side, SDEC has a copy of the private key. It performs the same hash operation and compares its output to the signature.
    a. If the signature matches, then we have an assurance that both the message content didn't get mutated in transit and that the sender is within the trust boundary.
    b. If the signature matches, then either the message was corrupted in transit or sent outside the trust boundary. Either way, we discard the message and don't propogate the data through to displays.

Notably, since the message is fixed size, we shouldn't suffer from length extension attacks, which is the only known weakness of SHA-2. This does increase message size, which will reduce transmission speed.

Describe alternatives you've considered
See https://github.com/SunDevilRocketry/Flight-Computer-Firmware/issues/191.

Additional context
This is not an urgent feature that has to be worked in the upcoming release. The flight computer cannot be exploited as a result of the base vulnerability.

However, the New Liquids Feed System upgrades the criticality of the ground station and the data flow from it. As such, mitigation FC.NLFS.GS.3 requires the presence of some security measure on LoRa. Priority should increase as we get closer to NLFS completion.

Points of Contact
FC Rev 3 Project Lead / Telemetry & Security SME / NLFS PM & SQA: @ETSells

Ngôn ngữ chính
C
Star
4
Fork
2
Merge trung bình
5 ngày 12 giờ
Pull request đã merge (30 ngày)
5

Chuẩn bị môi trường

  • Không có Dockerfile hay tệp Docker Compose
  • Có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của SunDevilRocketry/mod

Tất cả issue của SunDevilRocketry/mod

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.