On Thu, 8 Jan 2004, Roberto Gassira' wrote: > Ludovic Rousseau wrote: > > >Le mercredi 07 janvier 2004 � 20:37:07, Roberto Gassira' a �crit: > > > > > >>I think that there are a lot of reason to implement a communication > >>channel with smart card in kernel mode. > >>An example is: > >>have you ever tried to write any kernel service that uses smart card to > >>store cryptographics keys with a userland lib or framework? > >> > >> > > > >What's the problem with the manipulation of keys in userland? > > > >As far as I know the kernel part of IPSec get its keys from user land > >programs for example. > > > >Your motivation for doing like this is for security or because of an > >implementation constraint? > > > >Regards, > > > The motivations are : > - Security, because a secure kernel service, that uses smart card as key > storage, shouldn't exchange data > with an untrusted environment as the userland one. > An example is the WLF project (http://libeccio.dia.unisa.it/wlf/) for > the run-time integrity check of executables > that uses as repository a smart card for the keys. > - Implementation constraint, because using other frameworks from kernel > space is difficult. There are > a lot of solutions, but Smartk provides the easiest one. > > Moreover, Smartk is fast, lite and small.
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. I assume you are verifying the binary signature on every activation by passing the signature to the card to use the private key. It eliminates parallel image activation, pretty much eliminates the use of multiprocessors (though if it is a batch type system where only one image is activated every 5 or 10 minutes it might be reasonable). It does eliminate any real time activation... It does become a real bottleneck in operational use. And it introduces a trivial DoS accident.. (who sat on the card? :-) Or a more severe DoS via a vulnerable daemon (yes it was checked before activation... but the kernel was attacked by the daemon... and the card disabled... which would require multiple vulnerabilities - in the daemon, and in the kernel). Personally, I think a better way would be to use the card in the BIOS to verify a "known" kernel at boot time. The booted kernel would contains it's own separate, internal certificate (perhaps generated by the card - no private key in the kernel - the private key is only used during external configuration of the system). Configuration could be done at install time where the kernel certificate would be generated (and placed in the kernel binary, and the kernel signed), then all binaries being installed could be signed by that generated certificate + private key. Once installed, the private key could be saved (different card...) or discarded. A system level backup should then be made to a CD-R as a safty device (easy to reload, all signatures would be valid, and no private key). Now the kernel can check the signatures of binaries without referencing an external serializing (and slow) device, but not be capable of generating signatures. ------------------------------------------------------------------------- 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
