Hello Murilo, Murilo Camões Perrone wrote: > Karsten, > > First, congrats for the on-goin work. > > We from CertiSign have the same goal as you. Though, maybe we are thinking > further. > > We want to provide a layer above libmusclecard that implements a CSP > interface (windows CSP archtecture). With such “Muscle CSP” layer, any > existing windows applications that use the CSP interface could use > libmusclecard too. Also, windows based applications could migrate to linux > withought having to change for an pkcs11 interface.
Sounds great. > Luiz Reuter is working > on this. The current version are under: http://www.inf.tu-dresden.de/~ko189283/MuscleCard/ I hope it is working. [ The garbage collection for the Card Edge applet is buggy in the initialization. It consumes too much memory, although is should less, so some algorithms must switched off. The version without garbage collection should work with everything enabled. ] My goal is to support all features from this: http://www.inf.tu-dresden.de/~ko189283/MuscleCard/MCardAppletChanges.html Elliptic curve support is still missing there, and I did not mention the possibility of hybrid cipher operations [ 1. Generate secret AES or DES key on card. 2. Send data and encrypt 3. Send the public key of recipient 4. Encrypt with this key secret key from 1. 5. get encrypted secret key 6. Destroy secret key from 1. ] I do not know if this is necessary (Because an attacker can read the data sent to the card, before he could also read the key ...), but at the moment I search for a good way to support this by not breaking the interface. At the moment my testing card is broken and I need to get a new one. To get a single card is more difficult than you could think.) My main targets are the extension of the applet and the whole chain behind the Applet. I did a lot for the applet so it is very versatile, the MCardPlugin, the MuscleTools and for JMuscleCard to allow the access also from Java. The libmusclecard Changes where only minor changes. (OK, a lot of new definitions, some cleaning of the autoconf/automake/libtool chain for Unix and a convenient Windows support). Further targets would have been a CSP provider for Windows to allow Windows applications like Outlook, MS Office, Adobe, ... to access it. There is ID Ally from http://www.identityalliance.com/ from David Corcoran but I don't know if it depends on the PKCS#11 module. Ask him. But now this is your turn. > > I compiled your win32 version of libmusclecard sucessfully following your > instructions. I have a few questions. > An yes/no answer would be sufficient. This would be too short spoken. > - Your project uses Resource Manager below it (by Resource Manager API), > right ? Yes. There is no alternative for Windows. But only the compatible stuff with PC/SC Lite. The whole ideology of COM, concepts of service providers is not realized. (Is it necessary?) > - Above it, the original libmuscle interface has been slightly changed, > right ? Only in two cases: The process for formating the token (structure MSCTokenInit (There are more parameters ... but I appended this changes at the end of the structure, so it should be compatible with old versions (?) Is this true. Then everything would be compatible.) MSCKeyPolicy (The cipher modes are supported for signing and encryption. This was necessary, see doc below.) The current state is this: http://www.inf.tu-dresden.de/~ko189283/MuscleCard/libmusclecardChanges.html > - Is it an not totally independent brench, as the new linux libmuscle > features are being brought into Windows too (parallel development), right ? Don't know. You must talk to David Corcoran [EMAIL PROTECTED] or Ludovic Rousseau [EMAIL PROTECTED] I do not hope that this is a new branch, because a lot of versions are terrible to survey. But I wanted to wait with this discussion until I have the feeling, that I'm ready and it can be published. > - Do you plan reaching single libmusclecard that compiles in Windows and > Linux ? Is there any barrier ? Maybe the incomplete separation of > PCSC/libmuscle ? Yes, the last point. I still have this two things separated. There is some code shared between both. But at least for Windows this does not matter. So, I would take the inconvenient way and if something is changed in PC/SC Lite it must be included in libmusclecard. Although this is not actually necessary, if it is not a bug. So, maybe the solution will be the combination of PC/SC and libmusclecard like Ludovic Rousseau promoted with a special Makefile for Windows only building the libmusclecard. Karsten > > ---------------- > Murilo Perrone > CertiSign > > _______________________________________________ > Muscle mailing list > [email protected] > http://lists.drizzle.com/mailman/listinfo/muscle _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
