-2

I am trying to create a special military RADIO transmitter. Basically, the flow is:

  1. A solider will receive a message to transmit (about 10 times a day). Each message is of length 1024 bits exactly.

  2. He will insert this message into the radio and validate it is inserted correctly.

  3. The RADIO will repetitively transmit this message.

This is very important that the transmitter will not be hacked, because its very important in times of emergencies.

So, the assistance I ask from you is, how to preform stage 2 without risking getting infected. If I will transfer the data using a DOK, it may be hacked. If I will make the user type in 1024 bits, it will be safe but exhausting.

Any Ideas? (unlimited budget)

(It’s important to say that the data being transmitted is not a secret)

Thanks for any help you can supply!

Danny

Edit: Basically, I want to create the most secure way to transfer a fixed number of bits (in this case 1024), from one (may be infected computer) to the other (air gaped computer). without having any risk of a virus being transferred as well.

I don't mind if an hacker will change the data that is transferred from the infected computer, I just want that the length of the data will be exactly 1024, and avoiding virus to be inserted to the other computer.

Punch card (https://en.wikipedia.org/wiki/Punched_card) sounds like a good option, but an old one.

Any alternatives?

Danny Haas
  • 1
  • 2
  • If you can't use puch cards then use VHS tapes. VHS tapes have greater data density than punch cards. In fact, a truck loaded with VHS tapes driving at 60 mph moves information faster than a fiber optic line because the bit density is so great. – jww Jun 12 '18 at 03:10

1 Answers1

1

The transmitter is in the field, and is one dead soldier away from falling into enemy hands at any time. The enemy will take it apart, dissect it, learn how it works and use the protocol to send fraudulent messages that may contain exploit code to you, with or without the original equipment. You simply cannot prevent a trasmitter or otherwise mocked up "enemy" version of a transmitter from potentially transmitting bad stuff, because those are outside of your control. This is the old security adage "Never trust the client" taken to its most extreme level. Even punch cards could be tampered with.

Focus on what you can control: The receiving (or host) computer (which, contrary to your description, is not airgapped as it is receiving outside communication in your model) will need to validate the messages that come in from the client source; this validation will need to check for malicious messages and handle them safely (don't do anything functional with them, just log it, alert somebody and move on with life).

Your protocol should only be treating inbound messages like text or identifiers for message types. Under no circumstances should you be trying to interpret them as machine language instructions, and any SQL queries or strings that this message is appended to should be properly sanitized. This will prevent the host from executing any nasties that do come in.

Brandon McKenzie
  • 1,555
  • 12
  • 25