On Thu, 8 Jan 2004, Ludovic Rousseau wrote: > Le jeudi 08 janvier 2004 � 16:57:33, Roberto Gassira' a �crit: > > On Thu, 8 Jan 2004, Jesse I Pollard wrote: > > > > > Not that fast - access to a serial interface will reduce your application > > > startup to a MAXIMUM of one every 2 to 3 seconds. A USB interface should > > > speed that up to about one every 1/2 second. > > > > Correct, but SmartK is modular, you can easily develop a IO module that > > supports the USB port instead of the serial port. > > I may have missed an important point but you only need to access the > smart card to _sign_ a binary. The verification (using the public key) > can be done by the kernel without the smart card. The kernel just has to > get the public key from the smart card (or from somewhere else) at start > up. So the performances of the smart card is not a real problem.
True, the problem is verifying that the public key is valid, though. That usually take two certs. One to sign, one to countersign. But for the simple case, you are right.. I did overstate it. > > On the other hand, the majority of readers communicate through the > > /dev/ttySBx devices, that are handled by means of the "USB-Serial > > converter" feature. > > I have never seen such a reader yet. Do you have a reference or URL just > for my curiosity? There are many USB card readers - http://www.pcscworkgroup.com/ check the compatable card reader entry. The problem is that the card itself is still a serial device. > > 2) The management of public and private keys is a critical issue as > > well as the security of keys repository. Smart cards are suitable to be > > a robust solution for the key storage. > > You can also boot on a CDROM or a read-only partition to be sure your > executables and config files have not been modified. Once you get your > public key and the needed infrastucture you can verify your binary and > mount a read-write partition. You still have to verify that the signature used by the kernel is the correct one for the binary. It doesn't do any good to have a cert in the kernel and not be able to verify it each time. It would be relatively easy to use a substitute certificate to get a root kit running. The other problem is speed - CDs are NOT fast. > > 3) The integration of a kernel-level architecture and a user-level > > smart card interface is unsafe and unpratical. > > That's still to be demonstrated. > I don't know how you can use a Unix system if you don't trust at least > some processes/programs in user space. Problem has been worked on in much detail... Common Criteria, the US Orange Book... The easiest is to use compartments and assigned roles with each controled executable with a label that determine access rights (both execute, read OR write). Or the older access matrix using multi-level security (compartments, and levels; augmented with roles). > That's an interesting discussion I think. ------------------------------------------------------------------------- Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.musclecard.com/mailman/listinfo/muscle
