Alternative Communication

And Control

Senior Design Dec99-16

4-27-99

Abstract:

Due to their changing needs, education and industry are placing higher demands on technology. One area of increasing importance is the security of an audio transmission over a network. We intended to look into the security of audio transmission over a network in addition to other areas. Specific areas of concern for our project are reliability, security, cost, and ease of use.

Problem Statement:

Audio transmission is a rapidly growing area of interest for the market. Many institutions are now looking for ways to administer tests remotely, or to communicate between office sites. Transmission of audio over a network could improve the way it is done. Using this media has its advantages, but there are problems to overcome. A very important area of concern lies with the security of this activity. One does not desire to have their conversation or remote testing to be monitored or ‘snooped’ off the network. Our project aims to provide a secure, reliable, and inexpensive method for clients to transmit and receive audio transmissions with little or no fear. In addition it should also be fairly inexpensive.

Design Objectives:

In considering this project there are many areas of concern for design that must be answered. Below is a list:

Affordability
Ease of implementation for the end user
Quality of transmission
Security

Our average client will be required to have an IBM-compatible machine with Microsoft Windows 95/98. Additionally, the client also needs a sound card and network card installed on the machine. The finally requirement for the client will be a microphone and speakers to use our software product. These limited hardware requirements will greatly reduce the end cost for the client. Most of these features come preinstalled on today’s multimedia PCs.

When the client receives our product they should not have to go though many steps to implement our final design. Ideally the client should only have to install the software. If the product is to be used over a web page for testing, as would be the case for something like the Mallard System at Iowa State, some additional steps will be required for setup of the web page.

Delivery of this communication over a network is greatly dependent upon quality. The voice must be clear and understandable, even background noise and errors in transmission need to be factored into the design. One suggestion proposed to the client to assist in quality assurance will be accomplished be requiring a quality microphone. This may incur a little more expense on their part, but will be an inexpensive solution to assure their satisfaction. Currently we are researching three types of microphones

High quality headset speakers and microphone
Desktop microphone of medium quality, with client default speakers
General computer microphones, with client default speakers

These three distinct types of microphones show our target clients. Many businesses and perhaps schools will go for the headset type. This is a more costly solution, but does provide for the best quality and use. Schools in a lab setting, or a home user could easily use the medium range desktop microphones. Medium quality microphones should provide a good transmission quality, while at the same time keeping costs low. The general desktop microphone would be for the casual user who just wants to try out or experiment with our product. These three distinct product variations should allow us a pricing scale to fit into most of our client’s budget constraints. As of this time we have not formally decided on a particular microphone to use, we have however draw up pseudo-code and almost completed the research process for our project.

If one compares Appendix B to Appendix C the changes from our original modular design become apparent. The major difference is the addition of another computer link, the Server. This will be the machine that other machines connect to as a switchboard that will allow communication. The Server, depending on the setup could very well be one of the machines communicating with the world. In addition to handling negotiation of conversations with other machines the Server, particularly in an office or educational environment, will be the machine responsible for key exchanges. This will require the storage of secret keys on the Server.

For purposes of this project we have decided to go with a DES encryption algorithm. The DES encryption, while not as secure as RSA , is fast and efficient. Both of these play a vital role in our project as we cannot afford many delays in the transmission of the data to the remote system or the sound quality will not be as good as desired. The only problem with DES (and many other encryption methods) is the requirement of a key exchange. An end user will need the public key of a user to send a transmission to them and visa versa. To initiate the program the local machine will generate a key pair. The secret key will remain on the local machine, while the public key is sent to the server. If another machine wishes to communicate with the local machine then a process is taken to set up communication. First, the remote machine must have it’s own public key on the server. Next the local machine will be queried for permission to give out it’s public key. If permission is granted then the server will transmit the public key to the remote system and set up a session.

As can be seen from the above description, this will be a very complex program to write and implement. That is the reason that a good portion of this semester efforts have been put into research and design thought. Our design team has broken the program into several modules from which we are making pseudo-code. The main parts of the program are Key Generation, Encryption, TCP/IP communication, Server Functionality, Remote Playback, Local Recording, and Visual Interface. Our goal is to over the span of this summer to begin programming and testing of these program modules. In the beginning of the fall semester we shall integrate and test these modules for full functionality.

An updated timeline for design and production is included in Appendix A. This timeline includes achieved and new milestones. Appendix B is our original System Diagram and Appendix C is our new updated Diagram.

Budget:

Below is our updated budget for the dec99-16 project team. The proposed human budgets in Phases one and two are based upon an hour of work per team member for 18 weeks during the fall semester. This implies approximately two hours per team member per week. There is more proposed cost in human effort in Phases three and four due to the high cost in manpower of first writing and then debugging any major program. A note on Phase one’s total planned cost and the resulting actual costs. Our initial cost estimate called for $600.00 to be spent on human effort and for $50.00 to be spent on the poster printing. While we were slightly below on the total human effort in this area the total cost of the poster and supplies was in excess of $120.00. Knowing that most other groups had to pay a similar cost we would recommend that future senior design classes be informed about the high cost of printing and be compensated through the class accordingly.