Is secure communications possible? 2014

From Derek
Jump to: navigation, search

Supervisors

Honours students

Project guidelines

Project description

All existing cryptographic schemes involve, one way or another, the sharing or exchange of a cryptographic key. An open question is: can a cryptographic key be shared securely over the Internet without interception?

The essence of key distribution is to provide two endpoints with a shared secret that remains unknown to eavesdroppers. A subtle point is that the endpoints need not generate a secret and share it themselves, but could instead obtain it from elsewhere, provided an eavesdropper cannot do the same without error. In this project the goal is to explore this new idea.

One such source of random data is the transit time between two internet-connected terminals. If Alice and Bob rally information packets back and forth via the internet, the time of each transit is a quantity common to the measurements of both, but measurable only with the addition of noise from the return trip. An eavesdropper will suffer the same problem, however her noise will differ from that of Alice and Bob. This difference prevents the eavesdroper from taking advantage of the error correction performed by Alice and Bob during the information reconciliation phase of processing, which discards bits likely to be incorrect.

The trick is to extract random bits from the round-trip times by finding their median and declaring those times greater than the median to be a one, and those less to be a zero. With only one bit per round-trip, we avoid the problem that errors are more likely to fall into adjacent quantisation bins and so create correlations between bits.

Bob and Alice repeatedly send packets back and forth. There will be random timing variations. But there will be a degree of correlation between Alice and Bob, that is not shared by Eve. The idea is to investigate an error correction protocol that can improve the fidelity of the key received by Bob, but where any scheme adopted by Eve simply increases her error. Bob and Alice have the advantage of multiple resends until the key is finally distilled. Although this process is slow, we are not concerned by speed for key distribution. The important thing is to establish proof-of-concept at any speed. We shall call this the RTKS-cipher, or the random time Kish-Sethuraman cipher.

Approach and methodology

For the RTKS-cipher, perform experiments by communicating between two different internet nodes and record the resulting bit stream. Then record the bit streams that Eve receives depending on the location of her node. Probably just try to two worst-case nodes, which would be (i) in the same room as Bob, and (ii) in the same room as Alice. You can then compute the cross-correlation between Bob's bit stream and Eve's bit stream, to demonstrate if Eve has been able to distill any information or not.

Once you have a working link set up between two laptops, the idea is to try to attack and find weaknesses that an eavesdropper might exploit. You could build one of these network taps: https://greatscottgadgets.com/throwingstar/

It’s an open-source project with only a couple of parts, so you wouldn’t need to order one in from overseas but could have it made up in-house. For the endpoints, a little embedded PC would probably be safest in case something goes wrong with the tap---you can get BeagleBone boards or similar for $50ish each. They just run Linux, so one should be able to use the existing encryption software if they so desired. One can use another of these boxes for the eavesdropper as well. They have HDMI output if it is desired for the demonstration, but one can talk to them over USB too. This provides a bit of isolation between the custom hardware and any computers of substantial value.

Using the embedded board for the eavesdropper is a good idea in its own right, though, since then you have an example of a little box that can be surreptitiously inserted into a network.

Another idea might be to forget the tapping part and just take two of the BeagleBone (or similar) boards and make them into VPN-type devices that can use either the timing stuff or a one-time-pad. They have GPIOs which you could use to connect to a true-random-number-generator. There are other ways to do key agreement which use physical phenomena, and if the system were designed in such a way that they might be integrated in the future then that would be useful.

Summary of suggestions:

  • 1. Attack existing software (and maybe rewrite some of it too). This will give you a bit of hardware experience plus some embedded and PC software development.
  • 2. Develop tools for practical key agreement, be it via timing or other methods. This would involve mainly embedded software development, but there is the potential for some hardware too if you are keen.

Expectations

Luckily your job is made easier as we already have software that runs this protocol. The expectation is to explore this new technique and see where it can be improved. We want you to set up two laptops and send a secret key from one to the other, whilst deliberately trying to eavesdrop with a third machine. We want you to plot various graphs to demonstrate the performance of the system and to test its limits. Can you break it?

  • We don't really expect you, in this project, to solve the entire problem of performing secure communication. No practical scenario is perfectly secure. The question is, can we be secure enough? What is secure enough?
  • What we are more interested in is you exploring the problem, doing some tests, and showing some critical thinking. We'd like you to record and compare bit streams received by Bob and Eve.
  • To get good marks we expect you to show a logical approach.
  • We expect all the written work to be place on this wiki. No paper reports are to be handed up. Just hand up a CD or USB with your complete project directory at the end. The entire project directories of each group member can go in separate folders on the same CD or memory stick. You won't be getting the CD or stick back.
  • It is expected that you fill out a short progress report on the the wiki each week, every Friday evening, to briefly state what you did that week and what the goals are for the following week.
  • The onus is on you to drive the meetings, make the appointments and set them up. We have agreed on weekly meetings.
  • You are expected to make a YouTube presentation of your whole project. You should also consider making 3-4 short instructional YouTube videos to walk a future user through any software and tools you develop.

Deliverables

Semester A

  • Proposal seminar (20-21 March)
  • Progress report - only one report needed in wiki format (6 May)

Semester B

  • Final seminar (16 October)
  • Final report - only one report needed in wiki format (24 October)
  • Poster - one poster only needed (30 October)
  • Project exhibition 'expo' (30 October)
  • Labelled CD or USB stick containing your whole project directories. Only one is needed but it should contain two project directories, ie. one for each group member (30 October)
  • YouTube video summarizing project in exciting way - add the URL to this wiki - only one needed (30 October)
  • Optional: any number of instructional how-to YouTube videos on running your software etc.

Weekly progress and questions

This is where you record your progress and ask questions. Make sure you update this every Friday.

Relationship to possible career path

This project will familiarize you with techniques in encryption, decryption and data security. It will also improve your software skills. The types of jobs out there where these skills are useful are in computer security, comms, or in digital forensics. The types of industries that will need you are: the software industry, e-finance industry, IT industry, telecoms industry, ASIO, defence industry, etc.

See also

Delivered items

References and useful resources

If you find any useful external links, list them here:

Back

Retrieved from "https://www1.eleceng.adelaide.edu.au/personal/dabbott/wiki/index.php?title=Is_secure_communications_possible%3F_2014&oldid=14851"