PAD

Project Proposal:
The US Robotics Pilot (now PalmPilot) has taken the PDA world by storm. In a market that sold a combined 500,000 units in 1995, USR has shipped nearly twice that number of Pilots since their introduction in May of 1996. The success of the Pilot can be at least partially attributed to the following four factors: 1) it is very small, 2) it is comparatively cheap, 3) it communicates well and easily with desktop PC's, either by direct serial connection or modem (and now via TCP/IP with ppp or slip), and 4) it is programmable and can be loaded with custom software. The Pilot is a natural choice for an authentication device, because it is easily available and cheap (unlike conventional smartcard systems); it is something that will be carried along anyway to remote locations, when a full computer may not be desirable or practical, and the communication system is already in place. In short, it's a good use for an already fairly popular device. This project is partly about examining potential security-related uses for the Pilot, and it is partly about programming a specific application for demonstration purposes - The Pilot Authenticaion Device (PAD). The Pilot Authentication Device will be a system in two parts, designed to enable use of the US Robotics PalmPilot or Pilot 1000/5000 as a "smart" device for authentication purposes across insecure communications lines. The system will consist of two programs: 1) the Pilot executable, and 2) a desktop component that will run on Win32 machines, and will allow remote authentication without revealing a repeatable password on an open network. The project will evolve in stages:

1. More research: I will first do more research on possible applications for the pilot, and ways to implement PAD.
2. The Encryption Engine: Step 2 will be to program a pilot-based encryption engine. I believe the protocol will be as follows, but it will be confirmed at the end of step 1: 1) PC generates random + timestamp challenge and sends to pilot. 2) Pilot asks user for pass phrase. 3) Pass phrase is used as key to decrypt key for main encryption algorithm. 4) Pilot uses decrypted key for main encryption algorithm, decrypts challenge, and returns result to PC. 5) PC checks encrypted challenge against own version and accepts/denies.
   During this stage, all i/o will be user/screen. Serial communications will be added in step 4.
3. Desktop Component: Step 3 will be to construct the desktop counterpart to the Pilot program. The desktop component will generate the challenge, encrypt it, and check the response. All i/o will be user/screen.
4. Automation: Step 4 will involve using the serial port tcp/ip connection to communicate between the desktop program and the pilot to perform the correlation step automatically without user intervention after entering the passphrase. If time permits, this step will be expanded to allow modem and straight "hotsync-style" serial communications to take place as well.
5. Summation: Step 5 will consist of a report incorporating Steps 1-4. It will contain documentation for PAD as well as a risk assessment and suggestions for possible improvement.