Insecure Key Exchange

Learning Goals

• Insecurity of any key when the message sending the key to robots is vulnerable to an attacker
• How to use binary
• Implementing a new hardware based approach that could still be brute-forced given enough time, but is secure initially unlike other methods

Description

So far, we've learned that our communications are not secure without encryption - and the initial key exchange between the student and the robot is no exception. Therefore, it should not happen in the open. We’ll show one way how the key can be securely transmitted. It will be sent from the robot to the student instead of the other way around.

Glossary

• key exchange

Required/Authorized Commands

• No new commands are required, just the same ones that have been used previously.

Activities

• The Issue: Network Key Exchange
  • The initial unencrypted key exchange between the robot and the student that is needed to setup the encryption is happening on the same communication channel as all the other robots. This means that anyone overhearing at the time can hear what the key is being set to and steal it. This is a big issue that can be demonstrated easily. In short, the attacker would start listening to the target robot and filter the commands it overhears for one starting with set key. As soon as such a command is found, the hacker knows the key and can use this key to decrypt the future communication of the student with the target robot.
• Binary Review
  • Binary Number
  • Binary Conversions
• Solution: Hardware Key Exchange (that cannot be overheard)
  • In the real world, to avoid the problems with an insecure key exchange, there are exchange protocols (such as SSL) that ensure keys are sent properly and cannot be overheard or used by unauthorized users. To somewhat replicate this within the features of the robots, we use a feature that facilitates transfer of the initial keys directly from the robot to the students.
  • There is a button on the robots that, when pressed, will instruct the robot to generate a 16 bit random number. Then by default (when using Caesar cipher) this sequence is assigned as the encryption key in the form of four 4-bit numbers. These 16 bits are immediately "transferred" to the user through a pair of blinking LEDs on the robot, one for zero and the other for 1.
  • At this point the students will have to write down the sequence, convert it to decimal, and use it as their encryption key. They can also write a simple set of blocks that does this conversion for them! The robot will only accept commands encrypted with this key afterwards.

Common Pitfalls

Due to network conditions, LED blinking commands might not reach the robot and the robot could skip a bit as a result. If this happens, just restart and try again with a new key.