Difference between revisions of "Projects:2014S1-45 Is Secure Communication Possible?"
(Created page with "==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 cryptographi...") |
|||
Line 24: | Line 24: | ||
* 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. | * 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. | ||
+ | |||
+ | ==Team== | ||
+ | '''Team Members''' | ||
+ | * Christopher Lau | ||
+ | * Yuanhao Liu | ||
+ | |||
+ | '''Supervisors''' | ||
+ | *Prof Derek Abbott | ||
+ | *Dr James Chappell | ||
+ | *Lachlan Gunn | ||
+ | |||
+ | ==Resources== | ||
+ | * Workstation | ||
+ | ** Windows/Linux | ||
+ | ** MATLAB | ||
+ | ** Microsoft Visual Studio C++ 2010 | ||
+ | * Cubieboard (single-board computer) | ||
+ | * Network hub |
Latest revision as of 16:49, 3 October 2014
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. Using an 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 embedded boards and make them into VPN-type devices that can use either the timing stuff or a one-time-pad. 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.
Team
Team Members
- Christopher Lau
- Yuanhao Liu
Supervisors
- Prof Derek Abbott
- Dr James Chappell
- Lachlan Gunn
Resources
- Workstation
- Windows/Linux
- MATLAB
- Microsoft Visual Studio C++ 2010
- Cubieboard (single-board computer)
- Network hub