Crispin Cowan wrote: > Makan Pourzandi wrote: > >> Release of digsig.0.1 >> >> We implemented a kernel module using LSM hooks for 2.5.66 >> which checks signatures before running a binary. The main goal is to >> insert digital signatures inside the ELF binary >> and verify this signature before loading the binary. > > > This sounds *very* similar to CryptoMark 1, which we released in 2001 > http://immunix.org/CryptoMark/cryptomark-1.0.tar.gz It also used GPG > to apply public key signatures to executables > http://citeseer.nj.nec.com/beattie00cryptomark.html Hi Crispin. Thank you for your feedback. Actually, digsig is a complete re-imlpementation. We began from the scratch. We had a look on the CryptoMark source code and we decided not to use your code for several reasons. At the time we began the development (several months ago), it was not clear to us if this code is maintained or not (I believe that code has not been changed since 2001, we wanted to use the latest crypto modifications in linux kernel, our code uses the cryptoAPI in the kernel 2.5.X series). We also decided to use Bsign to sign binaries. IMO, Bsign does a good job for signing the banries, reusing their code helps to avoid developing user space tools by our own. And the last but not the least, we think that using your experience with CryptoMark, we could avoid some problems you may have encountered and do a better job in designing and writing our own code. Time and community feedback will show us if we managed to do so or not. > >> However, in order to reduce the overhead in the kernel, we took only the >> minimum code necessary from GPG. We took only the MPI (Multi Precision >> Integer) source code and the RSA crypto source code. This helped much >> to reduce the amount of code imported to the kernel in sourc code of >> the original (only 1/10 of the original gnupg 1.2.2 sourc code has >> been imported to the kernel module). > > > We did that, too. Is digsig a compelte re-implementation? Or is it > based on the CryptoMark release? Either is plausible, as we did not > widely publicize this result (we regarded it as a failed attempt due > to high overhead) but we do know that some people tried to build on it. > >> Performances >> =============== >> >> This is release 0.1. We have done some benchmarks. >> >> We ran lmbench on a Pentium IV, 2.4 GHz, 500 mega bytes of memory, >> running Linux 2.5.66. Our benchmarks show that the execution time >> (exec function call) multiplies by a factor of 4 when the module is >> loaded (no changes for fork call, as the binary is not loaded into >> memory). > > > We found the performance penalties to be *substantial*, typically in > the 500% slowdown range. The problem is that the cost of digital > signatures is more or less linear in the size of the program, mostly > to compute the MD5 of the program. Small programs tend to be > short-lived, while larger programs tend to be longer-lived, and the > net result was 200% to 500% slowdown across the board. I suggest you > try doing a kernel build with and without digsig and see what it does > to your performance overhead. If you don't see the same overhead that > we did, then I'd be very curious about the details. We'll do, for time being we have been trying to use rather lmbench for tests, but I believe you have a good idea, we're currently running the tests as soon as we come up with some synthesis of the results I'll post it to the mailing list. > > We then went and did an OpneSSL implementation. Unfortunately, that is > not releasable, because OpenSSL uses the 4-clause license, which is > asserted to be incompatible with the kernel's GPL by some significant > linux kernel authors. > > Thanks, > Crispin > That's the main reason we avoided the use of OpenSSL, I hoped that somehow I would be wrong and during the discussions someone will come with a brilliant idea to make possible the use openssl. It seems that it was just wishful thinking. Regards, Makan
This archive was generated by hypermail 2b30 : Thu Sep 18 2003 - 07:13:06 PDT