M.I.T. DEPARTMENT OF EECS
6.033 - Computer System Engineering
Design Project #2: FAQ
Last updated: $Date: 1998/04/30 15:46:18 $ by $Author: csapuntz $
My group has been working on the 2nd design project for a while, but we keep coming up against a brick wall: we just are not exactly sure how conduits work. Could one of you perhaps point us to a source that describes conduits in detail, or even email me a short description?
I don't think this is central to the project. You're given a description of what your piece of the system needs to do - we don't ask you to describe how a conduit works.
My understanding of how conduits work is as follows:
The conduits purpose is to reconcile data between an application on the computer and the Pilot. The conduit is a program that runs on the host computer, not the Pilot.
A conduit is activated when a HotSync Operation is initiated. This is accomplished by either pressing the HotSync button on the Pilot's stand or by running the HotSync applet.
Each pilot applications has a database associated with it. The database has, as part of its header, a creator ID, which describes the application that created the database (e.g. datebook, to-do-list, etc.). Conduits on the PC register to handle certain types of creater IDs. So, your Quicken conduit cna register to handle your Pilot expense database, and your Microsoft Outlook conduit can register to handle your datebook and to-do list.
There are two types of HotSync: FastSync and SlowSync. SlowSync involves downloading the entire database of the Pilot application. FastSync involves downloading only the chnaged records.
SlowSync is done the first time you HotSync a pilot on a given computer. Also, if you HotSync the pilot with more than one computer, SlowSync is used.
The Pilot Database Manager keeps track of what records have been modified since last HotSync by maintaing a modified bit for each record in an application's database. This bit is set whenever you add a new record or modify an existing one. The FastSync involves only reconciling those records with a modified bit.
Each Sync clears the modified bits. That is why a SlowSync is needed when HotSync'ing with more than one computer.
In addition, each record in a Pilot databses is tagged with a Unique ID which remains the same for the life of the record (e.g. even if the name of the appointmnet changes). This Unique ID can be used to reconcile data and recognize new data in cases of a SlowSync.
When an application database is being reconciled, the conduit has an opportunity to note the changes made on the pilot by receiving the changed records. Also, it can add records of its own to the Pilot database. I'm not sure whether it can delete records from the database (I'd assume so).
This information is derived from my memory of the Pilot databases/conduits from the COnduit Developer's kit documentation. Some of it might be wrong. However, there is documentation available.
- Costa Sapuntzakis
To what degree should we trust conduits? In one example case, a person uses a public PC to send data to a pilot, using conduits on that public PC. Must our design account for possible compromise of conduits? Or can we assume that conduits are trusted by either the owner of a pilot or a provider of data, and are not subject to compromise?
Conduits are powerful and do help modify your data during a reconciliation. You might want to consider whether or not you wish to trust a particular conduit if one was sent to you. Obviously if your conduit is signed by a someone you trust chances are you would be more apt to install it on your desktop computer. I think you can assume that once installed on your desktop machine, no bad-guys will break in and modify that conduit, but when a new conduit is introduced to your system a certification check might be useful.
- John Rusnak
I was wondering if I could have some clarification about the design project parameters. From the description of most of the specification, it sounds like authentication is needed for sites or info or conduits the pilot is connecting to. This seems like the case except for the one case where it says something about banks needing to approve something. From that statement it sounds as though the design also needs to include user to bank authentication. If I am reading that correctly, it sounds as though the user needs private keys and such to sign outgoing traffic? Am I just misreading?
Yes, you misread. Here is a scenario that describes what we mean:
Suppose I am using my pilot to store my expenses. I log onto Joe's Computer Warehouse web site and purchase a toaster. Joe would like to update my account balance on my PalmPilot, but he does not have the authorization to do so. Only my bank does. One way Joe could do this is contact the bank, get authorization to debit the account on my PalmPilot, and then download that authorization in order to convince the PalmPilot that a debit had taken place.
- Danilo Almeida
The conduit SDK's specific purpose is to allow reconciliation of data between the pilot's databases and the desktop's databases for a specific appilication. This involves communication with the pilot's databases, and therefore must support authentication. However, there's also a desktop protocol that supports remote communication from a desktop application to the pilot's databases. It seems that capabilities like the one described in the project's description (interaction between mit's registrar and the pilot, for example) is achieved using the desktop protocol, not writing conduits. Most probably, the conduit sdk builds on top of the desktop protocol. Do you think it's a good idea to state this in the paper, and extend the desktop protocol to support authentication? or should we just focus on the conduit sdk, and do authentication only at that level.
I have not looked into the details of how the communication works, but what you said sounds about right. However, bear in mind that the conduits will have to use the facilities of the desktop protocol. So they will have to be aware of what is going on.
- Danilo Almeida
On the third printed page of the design project, in the Operation section, the following query is made: * How do you make sure the phone number you're downloading is newer than the old one? What does this mean? There is no reference to telephones prior to this in the document.
That seems to be a reference to one of the applications that comes with the PalmPilot: a personal address and telephone book. I think it was mentioned primarily as an example of a generic problem of reconciliation systems: how do you know if the information you are downloading is newer or older than information that you already had in the PalmPilot? The same question applies, for example, to downloading into your calendar a posted statement about where the next 6.033 quiz will be held. You want to make sure that you not only have information from an authentic source, but also that it is newer than the previous version of that information from that source.
- Jerry Saltzer
Well doesnt the user either have to state that the prof has the permission to give other people permission to the records that he has access to, or require the prof to use a 6.033 key pair that belongs to the 6.033 staff and that all the staff members have a coyp of the private key. (kind of like the registrar example where multiple people at the registrar's office may have scheduling power and may need to change your schedule, however, they will all use the "registrar's key" right?)
Well, you tell me. That's part of your design.
- Danilo Almeida
I have a quick question about the design project. Can the patch for each PalmPilot be different, so that, for example, each PalmPilot gets a unique public/private key pair?
The instructions were pretty clear that there is only one patch and all the pilots get the same one. I think you are worried about a key assignment/distribution problem. I'd suggest you base the distribution off one of the two used standards for public key distribution. These are the ones I talked about in Prof. Ward's review session before the test. Trusted central authority (one machine has all the public keys for everyone), or web of trust (people sign each other's keys and if you recognize someone's signature your pilot accepts the new key). Also remember that there is limited storage on the Pilot so think about requesting keys on demand when they are needed.
- John Rusnak
So in other words, if I trust Prof Kaashoek to do anything to my 6.033 grades and schedule, AND I trust the people that he TRUSTS to change my 6.033 grades. I can trust those people? Is that what you mean? So I suppose in this scenario, the user has to trust the judgment of the prof. (his friends are my friends kind of thing?) in who he gives acces to?
Well, the user does not *have* to do anything. So that the particular scenario I gave works, that is the case. The question is: how does your design handle this general type of situation?
- Danilo Almeida
How extensive is the public key library that is added to the PalmOS as a patch?
My understanding is the Pilot doesn't have any disk. But I think it is fair to say that it does have some type of NVRAM (Non-Volatile RAM). NVRAM is the same stuff that keeps modem initialization strings saved with an AT&W command. You might want to consider keeping a trusted key like Verisign in NVRAM on your pilot. Then when a new key is needed your pilot can "request it on demand" from a trusted server. When the new key arrives the pilot can certify it with the Verisign key in NVRAM. In a future developments section of your report you might want to mention that if a new version of the Pilot has a PCMCIA hard disk you could have more flexibility. These are just ideas though.
- John Rusnak
For the encryption algorithm that is provided to us (the public key system) how big is the output related to the input? i.e. if the input message is 160 bits, how big is the output message?
You can make a reasonable assumption. If you use RSA, the actual plaintext/ciphertext input to the RSA encryption/decryption routine must be smaller than the modulus, which is the product of two primes. That is, if the number n is your RSA modulus, then the input must range between 0 and n-1. This is beyond the scope of 6.033 (try 6.875 or 6.857 for a full taste).
There are ways to constrain the size of the input to an encryption routine when you just care about authentication. Take a look at page 6 in lecture notes 14 for digital signatures.
- Kevin Fu
I was reading through the FAQ and am actually unclear about the discussion about private keys. It appears to me that private keys are in fact necessary because you need to send the registrar information (your class list) and it returns a schedule... In this case it wouldn't be devastating if you were not authenticated to the registrar, but in a scenario where I was accessing my bursar bill etc... I would want authentication. To accomplish that, I would in fact need a private-key on the pilot...
In a situation like that, what I can do it type a command on my workstation that authenticates me to the registrar's server using Kerberos (or whatever authentication mechanism). Then, the registrar allows me to get some info to put into my PalmPilot.
Of course, one could also support direct PalmPilot user authentication, but it is not required (esp. if your PalmPilot is connected to an authenticated user session on a workstation).
- Danilo Almeida
Hi, the design project says: "On the PalmPilot side, your authentication system will have to be implemented as a trusted authentication library and a security management application that users can install on their patched PalmPilots. "
What is this "security management application"? In other words, are we supposed to assume that the "already written" patch to the PalmOS will call the methods in our security library to perform authentication and authorization, or does the patch simply transfer control to the mythical "security management application?"
The application essentially gives the user and interface to the security library. For example, it lets you configure the settings that the library uses.
- Danilo Almeida
Any last minute advice?
The design project finale is rapidly approaching. I thought I'd come up with a checklist of issues that I think a good design project should deal with. This list is probably not complete. Nor are any of the items leading questions meant to modify your design. These are just questions that you may want to deal with.
___ Authenticated protocol. An protocol for authenticated RPC from the kiosk to the Pilot. Note - the responses of the Pilot need not be authenticated (though you can do it for extra credit). Does it deal with replay attacks? Spoofing? What are the possible attacks on the protocol still possible? Are your protocol messages explicit?
___ What extensions are necessary to the RPC protocol? Are read and write sufficient? (maybe append and list records would be useful too)
___ Are you seperating the notions of signing and encryption clearly? Are your crypto algorithms fast enough? Are you assuming a good source of randomness on the Pilot for your protocol?
___ Are you stating your assumptions?
___ Key distribution. How are the public keys in this system distributed? How much of a hassle is it to the user? Do you support certificates? Do you support insecure but convenient methods of download?
Authorization - note:
___ User should be able to keep private data on the pilot.
___ Are you going to use ACLs? If so, how complex? How will they be encoded?
___ Will the ACLs apply to individual records in the database? Will the ACLs apply to columns? (e.g. different ACLs on datebook times than on datebook appointment description)
___ Will your changes require modifying the applications? Can any subset of your changes be made to the system without modifying the applications? What compelling reasons can you give to application writers if they change their application?
___ Scenarios. A good design project should motivate the design decisions made with scenario(s) where a given feature would be useful. An overall scenario that brings together all aspects of your system could be useful.
___ Rationale. Similar to scenarios. Every design decision should have a clear rationale - explaining why it was made.
___ User interface. One of the central oals of the Pilot designers was to have the thing really simple to use. They saw their competition not as Windows, Mac, Newton, or Linux but of a paper and pencil agenda/planner. Is your design that easy to use?
___ Readability. Can a former 6.033 student read your paper and get what's going on?
___ Magic. Are there any big pieces of magic in the system? Magic = some large gap between the components given to you and your design.
___ Does your Pilot have a private key? If so, is it protected in any way (e.g. encryption)? What can you do with this private key?
___ Confidentiality in authenticated protocol.
- Costa Sapuntzakis
|Go to 6.033 Home Page||Questions or Comments: |