On Fri, 9 Jan 2004, Krister Walfridsson wrote: > > On Thu, 8 Jan 2004, Jesse I Pollard wrote: > > On Thu, 8 Jan 2004, Ludovic Rousseau wrote: > > > > > > 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. > > A certificate compiled into the kernel must surly be considered valid > (modulo revocation), since if you cannot trust it, how can you trust > e.g. the code in the kernel that do the permission checks?
Nope - it may have been revoked. Which means that the system is NOT to perform any processing. That calls for a remote connection + sign/countersign activity. > > > > 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. > > Right, but communication with the card is done though a packet based > interface. I would guess that the USB readers using the the USB-Serial > converter are the first generation USB readers, that was made by > just repackaging the existing serial readers, and let the vendors use > their existing PC/SC drivers for Windows. Most new USB readers should > use the CCID. That is true. This applies to the current round of cards which are ALL serial. (backward compatability will be a real booger of a job to do). Counting pads, I don't think they are 8 bit parallel (though they might be - depends on how many grounds/power pads there are). > > > 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. > > But if you can change the certificate within the kernel, then you > can also disable the signature check in the exec code... Quite likely... Though disabling it may (should?) do nasty things to a program loader (since quite likely the root kit would want access to local applications to complete itself... It would also suddenly announce itself.. Less obtrusive to just replace the cert for a specific load, then restore the original). I think that is why the TCPA wants the certificate internal to the hardware... ------------------------------------------------------------------------- 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
