Re: [opensc-devel] Status of the server migration
2012/12/27 Ludovic Rousseau ludovic.rouss...@gmail.com: Hello all, 2012/12/26 Viktor Tarasov viktor.tara...@gmail.com: On Wed, Dec 26, 2012 at 3:56 PM, Andreas Jellinghaus andr...@ionisiert.de * mailing lists: no idea what the current status is (i.e. this is a test mail). Do we have new lists? Subscribers migrated or invited? Does this old list still work, or should I shut it down? The mailing lists with the same names are created on SF. The request to import the 'OpenSC' archive (for a while only OpenSC) is pending. https://sourceforge.net/tracker/?func=detailatid=497423aid=3596976group_id=61487 Viktor, this request has been closed the same day you opened it. It looks like it is not the correct procedure. I just sent an email on each of the 3 lists to ask users to resubscribe to the lists at SF. * Trac/Wiki/ - any progress here? I remember so offerings and questions to migrate, but no status update since - maybe I missed it? We are waiting solution from Peter. I don't think we can count on Peter. I had a bad experience on the libusb project and waited after Peter for a new release during 2 years before participating to a forked project (libusbx). If something will no go as he expects, the alternative solution is to use the Wiki on github. Currently all wiki pages of OpenSC are migrated to github. https://github.com/OpenSC/OpenSC/wiki Sure, the github wiki is not the equivalent substitution to the WikiTrac, but an advantage is that there is no dependence on particular person to get it running. I do not like it at all but we may have lose all the bugs reported at opensc-project.org and start a new collection at github. If it is possible to do it automatically we may add a comment to every bug asking the bug reporter to report it again on github if the bug is still valid. * opensc-project.org domain - registered to martin paljak, opensc.org reigstered to same unknown person - opensc.com for sale. any chance to move one of the domains to (whom?) someone? or live without them? I have no much experience, but my guess is if Peter will create a real wikitrac, he could use this domain for this service. If not, I can use this domain for the actual opensc.fr platform. Martin is busy with other project and real life. The best we can do is ask him to redirect opensc-project.org to opensc.org so a web site is still available. Anything else I missed? As said, I'd like to retire the server end of year, as it is a very old and unmaintained installation. Andreas, can you wait until mid-January before retiring the server so I have a chance to backup what I can? I am not at home now. Sure, that is fine. I'd prefer to shutdown those parts that are migrated already - i.e., make the SVN read-only (is this possible), set the mailing lists to moderated etc. Andreas Thanks -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Status of the server migration
Hi, merry xmas / happy holidays everyone! If you don't read this in the coming day: all is fine, enjoy your time off with friends and family or skiing or ... But for those with time on their hands for open source project work: can someone summarize the current status of our server migration? * source code: now all in git on github, right? Does everyone have access who needs? What is the new system, people are asked to push patches to the mailing list and someone collects them? Or should people have their own repo, publish patches there and someone else pulls them? (more work, maybe not such a good idea) Or do we have an rietveld instance somewhere, so people can push changes there (how?) and they get compile-build-tested? * mailing lists: no idea what the current status is (i.e. this is a test mail). Do we have new lists? Subscribers migrated or invited? Does this old list still work, or should I shut it down? * Continuous build: is there a replacement system for the (jenkins?) system we have/had on the old server? * Trac/Wiki/ - any progress here? I remember so offerings and questions to migrate, but no status update since - maybe I missed it? * opensc-project.org domain - registered to martin paljak, opensc.org reigstered to same unknown person - opensc.com for sale. any chance to move one of the domains to (whom?) someone? or live without them? Anything else I missed? As said, I'd like to retire the server end of year, as it is a very old and unmaintained installation. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Which libraries/APIs needed?
opensc has a test suite that does very similar things - create a key,
take some content, hash it, sign the hash, verify it.
or take some content, and encrypt/decrypt it, verify the result is ok.
check that code, most of it will be very similar to
what you have, except for the smart card specific parts.
http://www.opensc-project.org/opensc/browser/OpenSC/src/tests/regression/init0009
Regards, Andreas
2012/12/4 Markus Wernig liste...@wernig.net:
Hi all
I have a rather basic question on which libraries/APIs to use for
implementing the following in eg. a C or Java program.
The basic idea is:
init:
- create 256bit key for AES-256
- create RSA keypair on token (no x.509)
- encrypt aes-key with pubkey of rsa-pair, delete cleartext version
loop:
- when needed, decrypt aes-key with private rsa key, load to memory
- perform symmetric en-/decryption with key in memory
Mainly the question is: Since the cryptographic functions on the token
(which could also be a network HSM) appear to be carried out by the
pkcs#15 driver, do I need the cryptoki API and pkcs#11 at all?
Thanks in advance for any pointer.
Here's the shellcode that should be translated into a compiled program:
echo Generate AES Key
secret=`head -c64 /dev/urandom`
openssl enc -aes-256-cbc -k $secret -P -md sha1 aes.key
echo Generate keypair on pkcs#15 storage
pkcs15-init -G rsa/4096 -i 45 -a 01 -u sign,decrypt --pin XXX:YYY
pkcs15-tool --read-public-key 45 -o rsa.pub
echo Encrypt AES Key
openssl rsautl -pubin -inkey rsa.pub -encrypt -in aes.key -out aes.key.c
echo Remove AES Key
for i in `seq 0 7`
do
size=`stat aes.key | grep Size | awk {'print $2'}`
head -c $size /dev/urandom aes.key
sync
sync
sleep 1
done
rm aes.key
sync
echo Decrypt AES Key to memory (depending on shell)
eval `pkcs15-crypt -c --pkcs1 -i aes.key.c` | tr -d `
echo Encrypt data
openssl enc -K $key -iv $iv -S $salt -in data.file -out data.file.crypt
-aes256
echo Decrypt data
openssl enc -d -K $key -iv $iv -in data.file.crypt -out
data.file.decrypt -aes256
echo Clear memory
unset key iv salt
kind regards thanks
Markus
PS: The above shellcode is based on
http://www.gooze.eu/howto/smartcard-quickstarter-guide/signing-crypting-and-verifying
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New SE (Security Element) Company Formed
2012/11/21 Martin Paljak mar...@martinpaljak.net: On Thu, Nov 15, 2012 at 7:12 PM, Anders Rundgren anders.rundg...@telia.com wrote: Another hurdle is that the GP security model is incompatible with the Internet: GP presumes mutual authentication AFAIK. This is how the Google Wallet currently works (Google holds the master keys to the SE) but that's not really cutting it. I don't believe that the industry players would want to give up their current position easily. Appstores (authority over what can be installed without hurdles), keys to the empire (GP-style approach) or monetary gatekeepers (who can charge a certain % for what is happening in their gardens) make money. Telcos would prefer to kill data based instant messaging providers without hesitation, if they could - SMS makes golden eggs... are you sure that is still the case? SMS flat is down to 5€/month over here. and I use google talk all the time instead of SMS, unless it is someone who doesn't have an android phone. Interenet as an ideal is one thing, business as usual must still live on, unfortunately. thats a bit harsh I think - its not like the mobile carriers e.g. aren't trying to sell payment systems on top of their infrastructure or similar, but at the end it doesn't gain wide acceptance it seems. maybe too expensive? also for them change is very expensive - their equipment is certified and expensive, and any additional feature might require an upgrade to new equipment with expensive addons in the software/hardware. plus they have a huge amount of equipment so any change affects a lot of parts. no wonder the mobile carriers think change is expensive. still they change when necessary, e.g. to adapt to new speeds/tech like LTE, but in that case they know that everyone left behind will likely die soon, and that the quality level on their network will only get worse with the explosion of mobile data usage. I cannot comment on many things discussed here, but as someone living in an SSO world, where I have one place to authenticate, and every app I use gets the authentication from that central place via OAuth: that is real nice. Thus my personal goal would be no longer to be able to get many credentials from many places, but only to handle one credentials with one service on the other side, and handle that very, very well. every other place can use OAuth with that central place. (remember how I opposed using openid in the past? seeing how nice it is to have such infrastructure changed my view on that) Regards, Andreas Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New SE (Security Element) Company Formed
2012/11/21 Martin Paljak mar...@martinpaljak.net: On Wed, Nov 21, 2012 at 8:55 PM, Andreas Jellinghaus andr...@ionisiert.de wrote: 2012/11/21 Martin Paljak mar...@martinpaljak.net: On Thu, Nov 15, 2012 at 7:12 PM, Anders Rundgren anders.rundg...@telia.com wrote: Another hurdle is that the GP security model is incompatible with the Internet: GP presumes mutual authentication AFAIK. This is how the Google Wallet currently works (Google holds the master keys to the SE) but that's not really cutting it. I don't believe that the industry players would want to give up their current position easily. Appstores (authority over what can be installed without hurdles), keys to the empire (GP-style approach) or monetary gatekeepers (who can charge a certain % for what is happening in their gardens) make money. Telcos would prefer to kill data based instant messaging providers without hesitation, if they could - SMS makes golden eggs... are you sure that is still the case? SMS flat is down to 5€/month over here. and I use google talk all the time instead of SMS, unless it is someone who doesn't have an android phone. Even public sources estimate a nice business And text messaging is still a big business, accounting for an estimated $21 billion in U.S. revenue for telecom companies last year and an estimated $23 billion this year, according to the Consumer Federation of America. Source: http://articles.latimes.com/2011/aug/21/business/la-fi-texting-20110822 http://ovum.com/press_releases/ovum-estimates-that-operators-lost-13-9bn-in-2011-due-to-social-messaging/ other source wine about lost revenue due to people using facebook chat and friends instead of sms. (no statement relating to increased revenue for the data tarif so people can use facebook of course...) The ROI on SMS is not comparable to the investments and increasing traffic for data services (where messaging is accounts only for a 1% of traffic, I believe) yes, the stories about price per bit for a sms are quite old. but if 2011 already 9% of chat moved from sms to facebookfriends, that is a strong development and guess that trend increases. Interenet as an ideal is one thing, business as usual must still live on, unfortunately. thats a bit harsh I think - its not like the mobile carriers e.g. aren't trying to sell payment systems on top of their infrastructure or similar, but at the end it doesn't gain wide acceptance it seems. maybe too expensive? Sure, as long as they can get a % of the business happening in their walled garden. Then again, financial services and payments are important parts of the overall who controls the money routes, controls the business play, so I don't expect any of the carriers or handset platform providers to open up a loophole that would allow for some 3rd party to easily take their market, without paying. There's just no commercial interest. So yes, harsh, but I believe realistic. I cannot comment on many things discussed here, but as someone living in an SSO world, where I have one place to authenticate, and every app I use gets the authentication from that central place via OAuth: that is real nice. Thus my personal goal would be no longer to be able to get many credentials from many places, but only to handle one credentials with one service on the other side, and handle that very, very well. every other place can use OAuth with that central place. (remember how I opposed using openid in the past? seeing how nice it is to have such infrastructure changed my view on that) Sure. But that should be an *option* rather than requirement. Eventually you still would want to separate your bank account from your google account, for example. Sure, I want several different authentication options, one for work, one for home, but causal things, and one for very important things like banking. but if I have accounts at several banks, all could use a shared very-secure authentication mechanism, I wouldn't mind. the problem is each bank wants to have their own mechanism I guess. how is the experience with the eID in estonia? I thought that was the one case where people used one central eID card for many things, like authenticating to banks for online banking - and it is not tied to one bank only? Maybe in 10 years this sounds like a stupid idea for the younger generation, but this moment in time I still would prefer the option to choose my credentials and identities (but would love to re-use them as *I* want, not how some vendor wants it (what makes OpenID better than peered implementations like saml or facebook connect or..) I love the idea of having more control. if there is a secure clearing provider for authentication, I might prefer to have him in the loop, rather than the bank. some of them don't seem to do a good job with basic things like a useable web page, or asking me for strangely limited passwords, etc. I'm not advocating the one for everything
Re: [opensc-devel] state of the project?
2012/11/16 Peter Stuge pe...@stuge.se: Ludovic Rousseau wrote: Andreas, the host available at opensc-project.org will disapear at the end of the year 2012 [2]. I think you misunderstood what Andreas wrote in his email. I think that what Andreas was saying is that someone else needs to be root and care for the machine. I don't expect that it will be any problem whatsoever to keep the VM around until whenever it is easy to change DNS, as long as someone is actually taking care of the system. well, noone is maintaining the VM. so if we don't have enough resorces for this now, it is not proper to assume we will magically have them sometimes later. the more I think about it, the more I think using a service is better than running your own server. github, sourceforge, savannah, code.google.com - its not like we don't have options. worst case I can do something, but it seems people already migrated all code to github, so that part is taken care of. the mailing list is archived in many other places, so I guess we don't need to migrate the mailing list archive. as for the list itself, extracting subscribers and asking them to subscribe somewhere (e.g. a new groups.google.com list or some other place) should be easy. as for trac: no idea what to do best. I think the wiki pages are valuable. the bug tracking I see as nice to have, but not essential. Of course if someone wants to invest time into this - then it is also your choice to take the proper direction. Andreas Of course when noone is able to and other offers aren't useful, then all that remains is to rely on free (beer) services like github or SF. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] state of the project?
2012/11/16 Viktor Tarasov viktor.tara...@gmail.com: Hello Peter, Le 16/11/2012 21:42, Peter Stuge a écrit : Viktor Tarasov wrote: I propose to start migration the week 19-25.11 . I'll have more free time: - sources: all sources will migrate to github; - CI: CI server is currently hosted by 'opensc.fr' ; - download: on the same platform can be hosted the file server; - TRAC (wiki?): it seems that Peter Stuge proposed to do something with Trac. Peter, if you are here, can you take this part, or at least explain how it could be done, please? If no suggestions, Trac can also be hosted by 'opensc.fr' . Educating someone on how to do a migration is as I'm sure you know a whole lot more work than performing the migration. If there's desire I'm of course still happy to host a Trac, but please keep in mind that Trac is a lot less useful when source code is somewhere else. It seems that decision to move all sources to github is accepted. Do you mean that with sources on github it would be more useful to use the bug system and wiki on github, as Ludovic proposed, and not the Trac installed on someone's platform ? (I need some time to discover Trac's internals and how it interacts with SCM .) As far as I understood, in any case we have to start from sqlite dump of the current OpenSC Trac. Andreas, can you do it, please ? sure, send a mail. trac is kept in postgresql though, not sqlite. we have nightly backups, if you want the dump files. plus of course the backup directory with templates, attachments and so on. Please add my SSH key on the server and let me know, if you want me to look into moving Trac out. - mailling list: the same, if no other suggestions, I'm ready to install/migrate it to 'opensc.fr' platform. Would be nice if one of the experts explain what is the actions to follow for such migration. I don't like mailman too much. I've set it up, but I don't use it. I'd suggest using SF for the list(s?). Could you expand 'SF' or give the link, please? SF is sourceforge.net I guess? it still has the opensc project (that was used many, many years ago). Owners are juha and olaf - if you can reach them, you can re-activate it. Andreas //Peter Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] state of the project?
Hi, I wonder what we can or should do to improve the state of the project. It seems to me: * the last release was 0.12.2, released on 17.07.2011, not enough progress to create a release since. * that is a maintenance release, the last major version was opensc 0.12.0 in 22-Dec-2010. * discussions about new server / some migration / some improvement etc. are similar old, no significant results yet While there have been some proposals, e.g. in the thread about the future of the server, there hasn't been any real discussion, no back and forth about the merrits of the different proposals, and no convergence on one option or decission by anyone. It seems to me the state of the project is defunct: while there are requests, proposals, options and offerings, we are not getting towards a decission or action it seems, as noone decides anything or gets people to agree or to do things. I haven't touched a smart card in over a year, so don't expect me to do anything - that wouldn't work. But if anyone is still concerned about the project, I think it is time you take action. Don't look for anyone else, it is you or noone. But many people offered help, if you want to drive the project forward. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Donation of a dedicated server to the OpenSC community
opensc needs very few resources I think, so a much smaller system would work as well I guess. but if there is noone specialised on setting up such a server and keeping it running well and secure, maybe using some service like code.google.com, sourceforge, savannah or github or others would be easier? Regards, Andreas 2012/10/3 Jean-Michel Pouré - GOOZE jmpo...@gooze.eu Le mercredi 03 octobre 2012 à 10:13 +0200, Jean-Michel Pouré - GOOZE a écrit : What is your dedicated hosting plan? I am proposing to donate a Kimsufi 2G to the community and pay for it: http://www.kimsufi.com/fr/ It has a dedicated IP, an ATOM processor with 2G RAM and 1T disc space. Although the ATOM is quite slow, I think it could be enough to host the wiki + trac. Wiki + trac = OVH dedicated host Github = Git build farm: Viktor + Jean-Michel I am of the opinion that we should have a dedicated hosting for OpenSC main site, not in link with other hosting plans. For example, we have a 12 core computer at OVH. But I don't propose to host OpenSC there. Independent hosting means that it belongs to the community. We are not tight to a company and this is cheap hosting. Then we can be several webmasters with root access. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new server hoster and adminstrator for opensc-project.org required
So, have you agreed on something? I read different opinions, offers, comments, but nothing that points out coming to some consent. What is your preference? Since I'm not really active, I don't want to decide this. I checked googlegroups and code.google.com, worst case I can figure out how to copy/move things there. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
2012/9/27 Martin Paljak mar...@martinpaljak.net On Sat, Sep 22, 2012 at 1:41 PM, Andreas Jellinghaus andr...@ionisiert.de wrote: In my mind keys could optionally contain application-oriented ACL telling which applications they trust so that even if you install a bad App, it would for example not be able to use your bank or eID-key in the background. I must admit I don't know how many apps are managed and seperated. given the restricted resources a smart card has, I assume there is a master key that creates contain of specific sizes/dimensions/... and the app is loaded into such a container, limiting it and reserving the unallocated space for further applications/containers? Is there a standard on doing this, or is it all JCOP magic under NDA? Are you referring to GlobalPlatform? That's public, with docs and API references (when applicable) available on globalplatform.org. I thought JCOP had more commands than GlobalPlattform, e.g. to manage card specific settings (e.g. change the ATR and communication settings). I bet there are probably vendors who tweak/amend/change/molest the spec, but the general principles should be there and followed by many vendors. There is an interesting thing called Trusted Execution Environment that might come to existence some time in the future, called TEE: http://www.globalplatform.org/documents/GlobalPlatform_TEE_White_Paper_Feb2011.pdf But for a mobile solutions and experiences, I think the time now is as good as pre-CCID for smart card readers: wild-wild-west and with a *much* tougher competition situation. Who needs standards if you have an iPhone :) Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
2012/9/25 Peter Stuge pe...@stuge.se NdK wrote: IIUC that bit is not authenticated, so a MITM attack can force both the reader and the card think the other party doesn't support PIN auth, making the card sign the transaction anyway, regardless the amount involved. So IMVHO it's quite serious... http://www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.pdf Tks. That's the (or one of) article I remembered but couldn't find... http://google.com/search?q=chip+and+pin+broken but the broken security demonstrated so far is related to misconfiguration, and many other banks have correct card profiles and are not affected. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
2012/9/23 Anders Rundgren anders.rundg...@telia.com On 2012-09-23 12:04, Andreas Jellinghaus wrote: 2012/9/22 Anders Rundgren anders.rundg...@telia.com mailto: anders.rundg...@telia.com On 2012-09-22 17:27, NdK wrote: Il 22/09/2012 12:41, Andreas Jellinghaus ha scritto: In my mind keys could optionally contain application-oriented ACL telling which applications they trust so that even if you install a bad App, it would for example not be able to use your bank or eID-key in the background. In my mind, the SE should take over display and touch controller by hardware means, so absolutely no app can snoop user input or fake it. Too bad seems nobody really *needs* that level of security... The problem with that is that is impossible for a user to distinguish between a real PIN dialog and a fake ditto. The SKS' work-around to this particular issue is that there is an OS-based PIN dialog and that keys can specify that they only accepts PINs through the system PIN dialog (trusted path). If the user is presented a spoofed PIN dialog, the attacker may indeed get the PIN. However, the attacker must also take the device as well in order to use it which makes the attack much less useful. If the OS is hacked this doesn't help but it seems that this is not the biggest problem with mobile devices; it is rather determine what an app should be able to do or not. To get the proportions right, consumer security solutions should IMO be compared with the Gold Standard for Internet-payments where authorization is performed by a UserID (Card Number) and Password (CCV) printed in clear on plastic cards, which is all the Financial Industry have manged to roll out during the 15Y+ we have had with the Internet! actually I think the system was doing fine - if you can review transactions later and refute any bogus transaction and the money can be traced to the recipient, and the system provider has a huge interest to keep the money traceable and recall'able, that is a good system design, and protects everyone much better than technical adventures. I guess you refer to the Google Wallet or SKS as technical adventures? I don't see any conflicts between judicious logging and systems that [rightly or wrongly] are claimed to be more secure than passwords printed in clear on plastic cards. no, I was refering to all the magic solutions that make things secure suddenly. Like sms-tan instead of pin+tan, or funny devices reading flickering info on some banks online system, or smart cards with biometrics on board, or $government-identified-super-secure-signing-cards or stupid de-mail (email with a postage cost of half an euro) which they try to sell in germany, and all this stuff. switching from magstripe to EMV transactions (chip+pin) seams to be a good idea though, as magstripe is totaly unsecure. but the real foundation of the credit card business is the middle man that vouches against both user and shop for any loss, and runs a fraud prevention programm to minimize risk and cost. this idea is great, technical solutions are perfectly fine, if they keep this basic system. I complain that they try to do not. EMV is of course totaly bloated and thus far too complex, and the whole idea of visa and mastercard keeping paypass and paywave confidential, even partners under NDA only get to see their bits, that is real stupid and insecure. I wonder how many years we need until people are willing to build an online only system. that won't work offline, but could be soo much easier than the offline system. many banks have already moved e.g. their PINs from the card to the online system, as unblocking a PIN in a card was often not working well, and having a central manged IT is much easier. So banks are already willing to restrict at least certain functions like debit (cash from ATM) to online only. The downside from my perspective is rather that visa and master card are shifting the liability to the end user. if the only one in the system who can enforce security standards is no longer liable to carry the burdon of not having a good enough security, then the system is going bad. verified by VISA and the similar master card initiative require the end user to verify each transaction with an additional password. If it is a password, it can be sniffed by a trojan as easily. if it is a TAN send over a SMS to your mobile phone, then loosing you mobile phone means an empty bank account. 3D Secure IMO combines the worst possible user-interface with questionable security. However, the concept is actually brilliant but it will rather be Google and Apple that will make it useful, not MasterCard and VISA. well, no nfc in iphone5, thus no idea what plans Apple has, and I can't comment
Re: [opensc-devel] Technical Description - Android Embedded SE
2012/9/24 NdK ndk.cla...@gmail.com Il 23/09/2012 11:52, Andreas Jellinghaus ha scritto: In my mind, the SE should take over display and touch controller by hardware means, so absolutely no app can snoop user input or fake it. Too bad seems nobody really *needs* that level of security... like credsticks from scifi novels decades ago? that owuld be a single use appliance, and I think easy to hack, similar how it is trivial to have a chip recording keystrokes placed inside a laptop etc. and I guess a multi app would be extreme complex and unlikely to be secure either. Nope. Speaking of SE in smartphones here :) well, that is lots of software in the smart phone that can be hacked. not a secure entry device from my point of view. You don't have much space inside a phone... Hopefully not enough to add a logger chip. And a phone is really much more tamper evident than a laptop... hmm, not so sure about that. but even if that is true, the software is easier to hack anyway, and requires only installing the wrong app try this game, thus has a much easier attack vector. hmm, a datasheat I found on smartmx for example does not mention a MMU. I guess it is onl a software implementation in the java interpreter, and that could be well faulty. Software-emulated MMU, then. Since it's so simple, it could well be worth the reduction in gates at the expense of a little longer run time -- but you are already running java, not optimized asm... well, in the end your programm is pretty simple I guess, and the complex operations like crypto are in a library in the chip and not java bytecode. also how are things managed - how easy is it to setup things wrong? That should be impossible, if the card only allows fixed-size apps and went under throrought testing. well, we saw so many insecurities in smart cards in the last few years - e.g. the hacks on mifare and legic, or the flaws found by ross anderson and his team on EMV cards - I doubt things are really secure, if they are very complex. Another question: if the applet manager is secure, then why change master keys before giving a card to customers? cards go throug a pipeline of ~4 entities and everyone has his own secret [...] Uhm... Found. If the key was publicly known, a reseller could easily remove an applet and replace it with another using the same app id and the final user wouldn't be able to know. If only the card manager would allow a per-app removal key... well. who is the card manager. if I buy a phone without contract, is it the vendor? if I buy a phone with a contract, is it the mobile network operator? will we have conflicts of interest? we already have locked phones and preventing some functionality (voice over ip, tethering, ...), and I guess phone companies want you to pay with your phone - as long as it ends up on the phone bill and they get a share of each transaction? thus who controls the SE has power, and it can't be you the end user, as the bank won't trust you to do a secure deployment. My new impression is I would only need to use a smart card keycert with one site only - my SSO provider. Thus a plugin for that communication only would work well with me. As long as you can import/export your cert (better if keeping it protected by a password) then you can have quite good security using openid and an identity provider like startssl that authenticates you using that cert. certs don't need protection, only keys do. and being able to export a key is always a bad idea. Unless you either can set up a multi-party RSA system or have another way to recover a damaged key. no one needs to recover keys. simply create a new one and create a new cert. If exporting keys is always such a bad idea, then why root-CAs export theirs? Simply to have a backup and obtain business continuity in case of HSM failure. HSM have all keys stored on the normal windows disk - but encrypted. the encryption is with AES or 3DES, and that is a master key that can be loaded into several HSM. often it is an XOR of N master key parts, and 4*N different persons have a copy of one part (two sites, two person each site). Thus worst case any copy of the key database plus parts 1..N can be used to setup a fresh HSM with the same master key and keep using those keys. standard practice for IBM HSMs at least I believe. it is much better to be able to get a new certkey whenever you want on demand. e.g. enter your credentials (password, pin, tan, fingerprint, retina scan, secret handshake, whatever you think is secure) and then get/generate a new keypair and CSR and get the signed cert. Unless you run a CA. :) no. if you run a CA creating new certificates costs you nothing, so the best thing you can do for security is short lived certificates with fast automated secure refresh cycles. the reason why people have long lived certificates, is because it is such a hassle to create new ones and manage
Re: [opensc-devel] Technical Description - Android Embedded SE
2012/9/25 NdK ndk.cla...@gmail.com Il 24/09/2012 21:37, Andreas Jellinghaus ha scritto: no, I was refering to all the magic solutions that make things secure suddenly. there was a good comic strip I can't find just now... Hackers view: oh, no, this laptop is protected by 4096-bit RSA... no way we can recover it even with $100! Grunt view: this laptop is locked... take this $5 wrench and beat off the pass from the user. Too bad it proves right... Here in Italy we've had many episodes of people kidnapped to make their families let robbers enter well-protected houses... :( Like sms-tan instead of pin+tan, or funny devices reading flickering info on some banks online system, or smart cards with biometrics on board, or $government-identified-super-secure-signing-cards or stupid de-mail (email with a postage cost of half an euro) which they try to sell in germany, and all this stuff. Not to speak of italian posta certificata (certified mail, with provable delivery so that it can have legal value)... :) EMV is of course totaly bloated and thus far too complex, and the whole idea of visa and mastercard keeping paypass and paywave confidential, even partners under NDA only get to see their bits, that is real stupid and insecure. Maybe because they know it's not secure? No, I think it is well intended - try to be compatible with every old thing and have all the features everyone wants in there. Except the result of such a process is not good. EMV for sure: there's an unauthenticated bit that tells the card to authenticate the transaction without asking for the PIN... Thats ok, it is a valid feature. If people buy something for less than a dollar, and the transaction is authenticated with the signature of a rsa key in the smart card, and we haven't reached the consecutive lower boundary amount yet, then simply approving the transaction is perfectly fine - getting a PIN or doing an online transaction isn't worth doing for such a small amount of money. Most vending machines still use modems and dial up for every transaction and hang up again later. Thats why card transactions are so slow. Once the standard is to have a permanent internet connection, the cost of doing an online transaction is lower (less delay) and the profile could be changed to do everything online. But since the card doesn't know where it is, it can only have a world wide setting, and people expect the card to work in the remote places with the worst infrastructure. Maybe some day banks want to give people two credit cards with different settings? Andreas BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
2012/9/22 NdK ndk.cla...@gmail.com Il 22/09/2012 12:41, Andreas Jellinghaus ha scritto: In my mind keys could optionally contain application-oriented ACL telling which applications they trust so that even if you install a bad App, it would for example not be able to use your bank or eID-key in the background. In my mind, the SE should take over display and touch controller by hardware means, so absolutely no app can snoop user input or fake it. Too bad seems nobody really *needs* that level of security... like credsticks from scifi novels decades ago? that owuld be a single use appliance, and I think easy to hack, similar how it is trivial to have a chip recording keystrokes placed inside a laptop etc. and I guess a multi app would be extreme complex and unlikely to be secure either. I must admit I don't know how many apps are managed and seperated. given the restricted resources a smart card has, Think about how an MMU works: it keeps a table of pages assigned to an app, and maps 'em in app's address space. An app have no way to access a page outside its allowed address space. Nothing secret, here, and doesn't require great resources. hmm, a datasheat I found on smartmx for example does not mention a MMU. I guess it is onl a software implementation in the java interpreter, and that could be well faulty. also how are things managed - how easy is it to setup things wrong? I only remember seeing code that would change master keys and put one app into a card, thus never bothered how it works in detail or how to manage resource, secure apps against each other etc. Also I wonder: does the vendor claim to have the security thight enough to prevent a hostile app from accessing data of another app? Or is it the usual all is secure, but we don't tell how it works, how to use it, and make no real guaranties anyway? Another question: if the applet manager is secure, then why change master keys before giving a card to customers? cards go throug a pipeline of ~4 entities and everyone has his own secret key that he doesn't want to give out. first there is the chip key by the cpu vendor. then the mask of the OS vendor has a different master key, so from serial and the mask a new key is set. then the OS manufacturer changes the key again as soon as he gets the hand on the chips, as the cpu manufacturer can see the master key in the mask. then he wants to send the chips to some perso unit, so he has a master key agreed on between the os vendor and the perso provider, and changes the card key to be derviced from this. the perso provider could change the key again when receiving the cards, but he needs to trust the card or provider anyway, and might be too lazy. but once he manufacturers a card, he has a master key agreed on with the customer, e.g. a bank. and now the card key is changed again. in this step the old key is derived from the card serial, as in all previous steps, but the new key is derived from the number of e.g. the visa card, not the chip. again the bank could then change the cards key later, e.g. using an update procedure in an ATM. which noone does, because it never works well, but in theory ... this procedure is not entirely accurate, as e.g. os vendors move towards hosting equipment directly at the CPU manufacturer, so the cards are changed on site, and can be directly send to perso units, which will safe them manual extra work and one security transport - those are quite expensive. so for SE in mobile phones we would have the same more or less - e.g. NXP does the chip and the OS (if the two units trust each other they can skip one change to the key here), then the sell the chip to samsung and change the key to the nxp-samsung-$chip MK derived one first, samsung might want to change the key again, and sell the device. but if banks need to trust the device enough to upload a smart card into it, then the end user can't have the key for his device - otherwise he could decrypt the communication and create several copies of the credit card uploaded, great for fraud, but security of those depends on single unique cards. My new impression is I would only need to use a smart card keycert with one site only - my SSO provider. Thus a plugin for that communication only would work well with me. As long as you can import/export your cert (better if keeping it protected by a password) then you can have quite good security using openid and an identity provider like startssl that authenticates you using that cert. certs don't need protection, only keys do. and being able to export a key is always a bad idea. it is much better to be able to get a new certkey whenever you want on demand. e.g. enter your credentials (password, pin, tan, fingerprint, retina scan, secret handshake, whatever you think is secure) and then get/generate a new keypair and CSR and get the signed cert. as for openid, I thought there was some discussion about
Re: [opensc-devel] Technical Description - Android Embedded SE
2012/9/22 Anders Rundgren anders.rundg...@telia.com On 2012-09-22 17:27, NdK wrote: Il 22/09/2012 12:41, Andreas Jellinghaus ha scritto: In my mind keys could optionally contain application-oriented ACL telling which applications they trust so that even if you install a bad App, it would for example not be able to use your bank or eID-key in the background. In my mind, the SE should take over display and touch controller by hardware means, so absolutely no app can snoop user input or fake it. Too bad seems nobody really *needs* that level of security... The problem with that is that is impossible for a user to distinguish between a real PIN dialog and a fake ditto. The SKS' work-around to this particular issue is that there is an OS-based PIN dialog and that keys can specify that they only accepts PINs through the system PIN dialog (trusted path). If the user is presented a spoofed PIN dialog, the attacker may indeed get the PIN. However, the attacker must also take the device as well in order to use it which makes the attack much less useful. If the OS is hacked this doesn't help but it seems that this is not the biggest problem with mobile devices; it is rather determine what an app should be able to do or not. To get the proportions right, consumer security solutions should IMO be compared with the Gold Standard for Internet-payments where authorization is performed by a UserID (Card Number) and Password (CCV) printed in clear on plastic cards, which is all the Financial Industry have manged to roll out during the 15Y+ we have had with the Internet! actually I think the system was doing fine - if you can review transactions later and refute any bogus transaction and the money can be traced to the recipient, and the system provider has a huge interest to keep the money traceable and recall'able, that is a good system design, and protects everyone much better than technical adventures. The downside from my perspective is rather that visa and master card are shifting the liability to the end user. if the only one in the system who can enforce security standards is no longer liable to carry the burdon of not having a good enough security, then the system is going bad. verified by VISA and the similar master card initiative require the end user to verify each transaction with an additional password. If it is a password, it can be sniffed by a trojan as easily. if it is a TAN send over a SMS to your mobile phone, then loosing you mobile phone means an empty bank account. Lets be honest: you might have your mobile phone and wallet in your hand-bag or backpack or whatever, and if both are stolen the attacker has access to about everything and almost all ways to identify you and authorize transactions are in his hand. even the numbers you might need to know to prevent fraud are no longer with you - e.g. in germany I might remember the central hotline for reporting stolen cards (116 116) and I remember my bank account number. but if they require my visa card number, I wouldn't know that. also I wouldn't have mobile phone with me - it got stolen - and if I don't notice the issue I'm out of luck, as everyone (banks, telco, ...) shift the liability for every transaction until the theft gets reported to the customer. the mobile phones have authentication of the customer (gesture, pin, password or screen unlock), but those are not very good protections. so my expectation is they won't stop attackers. Andreas Anders I must admit I don't know how many apps are managed and seperated. given the restricted resources a smart card has, Think about how an MMU works: it keeps a table of pages assigned to an app, and maps 'em in app's address space. An app have no way to access a page outside its allowed address space. Nothing secret, here, and doesn't require great resources. I only remember seeing code that would change master keys and put one app into a card, thus never bothered how it works in detail or how to manage resource, secure apps against each other etc. Also I wonder: does the vendor claim to have the security thight enough to prevent a hostile app from accessing data of another app? Or is it the usual all is secure, but we don't tell how it works, how to use it, and make no real guaranties anyway? Another question: if the applet manager is secure, then why change master keys before giving a card to customers? My new impression is I would only need to use a smart card keycert with one site only - my SSO provider. Thus a plugin for that communication only would work well with me. As long as you can import/export your cert (better if keeping it protected by a password) then you can have quite good security using openid and an identity provider like startssl that authenticates you using that cert. Not sure what to do about phone theft though - I really fear putting all the access
Re: [opensc-devel] Technical Description - Android Embedded SE
Am 20.09.2012 21:06 schrieb Anders Rundgren anders.rundg...@telia.com: http://nelenkov.blogspot.se/2012/08/accessing-embedded-secure-element-in.html Very interesting IMHO. Agree, thanks for sharing. According to the author SD-slots are becoming exceptions also for Android so this is probably what most people will be dealing with. I think he is also over optimistic with multi applications on a Java card SE, but we will see. The NFC chip should be similar to what can be used with libnfc, so porting all the mifare copy clone and fake tools would be awesome... Andreas Anders ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Request for comment: bringing warnings down to a dull roar
Am 21.09.2012 09:41 schrieb Ludovic Rousseau ludovic.rouss...@gmail.com: Hello, 2012/9/20 B. Scott Michel sco...@aero.org: I'm debating whether to submit a pull request on github with patches to reduce gcc's warnings to a minimum (actually, completely eliminated.) However, the patches violate the coding rules by marking unused parameters in static functions -- the marking is very explicit and very visible. I also took care of other issues, such as replacing int with size_t where needed. I should have made the unused param patch separate from the integer conversion and other warnings. Do not fix unused param warnings. The correct way to fix them is to remove the parameter. Well, with c style object orientation we have interfaces that all card drivers must implement, even if they don't use all function parameters. Not sure if the marking will still allow people to also compile with visual c. Andreas Use -Wno-unused-parameter Question (and request for comments): Should I submit the pull request, even though the patch would potentially violate the coding conventions? It is always a good idea to submit a pull request to be able to review it. Maybe it will be rejected and you will be asked to change it. Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
2012/9/22 Anders Rundgren anders.rundg...@telia.com On 2012-09-22 08:58, Andreas Jellinghaus wrote: Am 20.09.2012 21:06 schrieb Anders Rundgren anders.rundg...@telia.commailto: anders.rundg...@telia.com: http://nelenkov.blogspot.se/2012/08/accessing-embedded-secure-element-in.html Very interesting IMHO. Agree, thanks for sharing. According to the author SD-slots are becoming exceptions also for Android so this is probably what most people will be dealing with. I think he is also over optimistic with multi applications on a Java card SE, but we will see. Indeed. I even wonder if the SE needs to host applications at all. IMO, it would be enough if the SE hosts keys and associated attributes while the applications either rather run at OS-level as trusted processes like PIN input etc. or as standard applications. As far as I understand the Wallet is just an Android App that is trusted by the SE. well, even if the battery of the mobile phone is empty, the secure element can still be powered by any reader and thus still work. Implementations can or cannot make use of this - if the implementation prefers the user to take the phone out of his bag, unlock it, open some app and make the I approve gesture, then disabling it is a good idea to prevent unauthorized usage. In my mind keys could optionally contain application-oriented ACL telling which applications they trust so that even if you install a bad App, it would for example not be able to use your bank or eID-key in the background. I must admit I don't know how many apps are managed and seperated. given the restricted resources a smart card has, I assume there is a master key that creates contain of specific sizes/dimensions/... and the app is loaded into such a container, limiting it and reserving the unallocated space for further applications/containers? Is there a standard on doing this, or is it all JCOP magic under NDA? I only remember seeing code that would change master keys and put one app into a card, thus never bothered how it works in detail or how to manage resource, secure apps against each other etc. Also I wonder: does the vendor claim to have the security thight enough to prevent a hostile app from accessing data of another app? Or is it the usual all is secure, but we don't tell how it works, how to use it, and make no real guaranties anyway? Here is a write-up of a possible ACL-scheme that is intended for the Web and App: http://webpki.org/papers/PKI/pki-webcrypto.pdf hmm, that link is configured as download :( a normal link would be easier so chrome users can browse it without a download to the filesystem (and another file kept around in Dowload/ folder forever). I haven't looked into this into very detailed. My new impression is I would only need to use a smart card keycert with one site only - my SSO provider. Thus a plugin for that communication only would work well with me. I use two browsers, thus could have a differnt plugin each time linked to a different identity. Not sure if I wanted to share a card for that purpose, that agains simplifies my requirements I would have for a smart card a lot. Like many people I noticed that people have their mobile phone with them all the time, and notice if they lost it right away. Thus using a mobile phone for authenticating any other device seems to be the right thing to do and works well for many people in practice. Thus using the SE in such a phone can become interesting. Not sure what to do about phone theft though - I really fear putting all the access credentials into one basket (my phone), plus a lot of personal information, so any thief would be able to impersonate me and access my mail, documents, banks, and much more. In summary: my old expectations how to secure communication and use smart cards in them have gone many months ago, now I see the world very differently. My adventures into smart card business also make me wonder if trusting such an industry is a good thing. Andreas Anders The NFC chip should be similar to what can be used with libnfc, so porting all the mifare copy clone and fake tools would be awesome... Andreas Anders ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org mailto: opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new server hoster and adminstrator for opensc-project.org required
A small follow up: As far as I know the server does: * svn server / code repository * svn server / release tar.gz repository (also containing binaries) * build robot to create nightly builds and or automated builds (jenkins?) * many trac repositories - wiki, browser for svn, bug tracking (the bugs are not very helpful if noone works on them) * mailing lists So I don't know if all svn code repositories have been migrated to githup etc. I have little knowledge what plattform would be best to fill the gaps so that we can shut down the server. What I can do is make all configurations available to whoever wants to setup a new server, or help with migrating to whatever plattform. If I had to pick one, I would try code.google.com (as I work for google now), but not having much clue what plattform has what features I can be persuaded to any plattform I guess. As people mostly focused on opensc, I would be happy if the other small projects do not get lost / don't get a second class treatment. Those should be very easy to migrate as they are tiny (e.g. libp11 and pam_p11, pam_pkcs11, engine_pkcs11) and I know for sure there are many users of those code parts around that need them (e.g. many people using TPM also use engine_pkcs11 and thus libp11 and also use pkcs11-tool from opensc for testing the TPM pkcs11 module). I don't want to be the one deciding where to go, as I find little time for OpenSC these days (maybe none would be more correct). Thus I think you guys should find a compromise on the options people are offering here. Thanks and regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] new server hoster and adminstrator for opensc-project.org required
Hi, opensc-project.org needs a new home: someone with a (real or virtual) server and the interest in setting it up from scratch and keeping it running and maintaining that server, installation and service for the project. someone who is able to win the trust of the community as new server administrator. The current installation is terribly old. It is based on ubuntu hardy and I think that is nearing the end of its supported livetime or even is unsupported now, thus it is urgently required to rebuild the server. Over the years we had several approaches and various people offered to take over running the server, but so far none of those worked out in the end, noone followed up after the initial discussion. To give this new efford more motivation here is some presure: running a server without maintenance and security updates is not a good idea. Thus I will shut down the current installation at the last end of this year. Any motivated linux administrator can setup a simple server with apache and a few copies of trac, plus postfix and a few mailing lists in a few hours or a day, with maybe a bit more time for fine tuning and migration of the content. This shouldn't be a big deal, thus there should be enough time to find someone interested in doing so and migrating opensc and related projects of the outdated installation. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC Server Maintenance
2012/6/11 Jean-Michel Pouré - GOOZE jmpo...@gooze.eu Dear Andreas and all, Nice to hear from you. the software running opensc-project.org is getting very, very old. I didn't upgrade it when Martin had plans to rebuild the server on real hardware somewhere, but that didn't happen for years now, and the installation is getting older and older. We are running servers on real hardware hosted at OVH.com in France. This is the largest and probably cheapest hosting company in Europe. good. the server runs on a shared server I have with friends at hetzner.de, one of the best hoster in germany. the server resource is not the big deal - I have no time to maintain/improve the system and think that is a bad situation. I can probably host OpenSC if needs be. Is anyone interested in working on this - building a new server somewhere? Or what is your suggestion to migrate the project to some hosting plattform? code.google.com, sourceforge, savannah, ...? github looks great. Only the wiki needs hosting on dedicated host. see my other list of all the components we have. not sure if we need all of them, though. or if migration from trac to X is possible without loosing all content. It not urgent, but I wouldn't be supprised if things break, as the server gets little attention. Thus the better someone steps up to maintain it, the better. I would be glad to apply to become part of a webmaster team. great. though there is little of a team - haven't done much in the last years to keep the server alive, and not sure how much time martin has for the server maintainance. so we are mostly lookig for someone to take over the job I guess - that doesn't mean we drop dead, we are still reachable to help, but I can't do much more than help our here or there. I am currently working on the packaging farm project with Viktor. On the other hand I am also creating a full computer room with regression test servers and development servers. Some working on real hardware, some on VMs and others in chroots. All machines runs in vlans with limited connection to Internet. We have VPN connections and a double backup in a NAS and in a cloud. Several developers joined and gave hardware. I am quite confident we can collect all working OpenSC hardware and make it available over Internet. This is quite a tedious job and it takes me 2/3 days every week. Half of my time! I think Viktor and I would be glad to manage Jenkins, Gerrit and the various farms (packaging, test, development). When this is finished, I can be part of the websmaster team. But I don't like working alone and I would like to share the project with other hackers at OpenSC, in a collaboration spirit. good idea. the main task right now is this: the old installation is ubuntu hardy, i.e. the stable release from 4 years ago. in a year even the security updates will end. thus lets find a new installation and migrate everything - or move to some service / hosting / ... (either is fine with me). Regards, Andreas Kind regards, Jean-Michel GOOZE ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC Server Maintenance
2012/6/11 Alon Bar-Lev alon.bar...@gmail.com Hello Andreas, GitHub is a great place... Already there, just need to migrate the wiki. The question is where Gerrit will be (if is used). And if there is a need to migrate the bugs as well... which may be difficult. ok, thanks. In summary we have: * several repository (not sure if all got migrated to git) * several wiki (not sure if you can migrate from trac to something else without major work) * bug tracker (not much used I think, wouldn't be missed very much I guess?) * mailing lists * download section with all the binary / zip / tar.gz files etc. * buildreview system (jenkis/gerrit/...?) not sure if github covers all of that. sourceforge might - not sure, other service: no idea. Regards, Andreas Alon. On Mon, Jun 11, 2012 at 10:31 PM, Andreas Jellinghaus andr...@ionisiert.de wrote: Hi everyone, the software running opensc-project.org is getting very, very old. I didn't upgrade it when Martin had plans to rebuild the server on real hardware somewhere, but that didn't happen for years now, and the installation is getting older and older. Is anyone interested in working on this - building a new server somewhere? Or what is your suggestion to migrate the project to some hosting plattform? code.google.com, sourceforge, savannah, ...? It not urgent, but I wouldn't be supprised if things break, as the server gets little attention. Thus the better someone steps up to maintain it, the better. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] OpenSC Server Maintenance
Hi everyone, the software running opensc-project.org is getting very, very old. I didn't upgrade it when Martin had plans to rebuild the server on real hardware somewhere, but that didn't happen for years now, and the installation is getting older and older. Is anyone interested in working on this - building a new server somewhere? Or what is your suggestion to migrate the project to some hosting plattform? code.google.com, sourceforge, savannah, ...? It not urgent, but I wouldn't be supprised if things break, as the server gets little attention. Thus the better someone steps up to maintain it, the better. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] GlobalPlatform and OpenSC
2012/3/22 Anders Rundgren anders.rundg...@telia.com Somewhat related to the OpenSC organization discussions: http://www.globalplatform.org/documents/Consumer_Centric_Model_White_PaperMar2012.pdf I must confess I don't understand a thing of this, neither the business model, the consumer centric concept, or how it integrates in phones that doesn't permit changes in the internals except through routing or jail-breaking. my view: all you need is authentication. their view: no, that is only the start, they want to have applications deployed on tokens, security policies, and whatnot. at least they realize people buy their own smartphones and use them. now they want people to buy their secure tokens and use them, and have a huge ecosystem build on top of that. well, if that is a sign towards more compatiblitiy: +1 but in general I still think complex on card systems are a failed model. all you need is authentication, and the rest can be build much better, much cheaper, much faster, much more secure as an online system. Andreas Anders On 2012-03-22 10:33, Alon Bar-Lev wrote: On Thu, Mar 22, 2012 at 12:03 AM, Peter Stuge pe...@stuge.se wrote: Alon Bar-Lev wrote: I will try again. Thanks! It really helps! I am glad! Well, let's agree we do not agree... :) At no point in time I argue that the gerrit is not a good tool, I argue the methodology. Anyway, just last note I want to make... OpenSC is by far *NOT* a security project. Yes, that may sound surprising... :) OpenSC deals with security subject, that's true... hardware cryptography. But its origin mission was to provide access (USABILITY) to none Windows (+ none proprietary) users to hardware cryptography, PKCS#15 and partially by reverse engineering. If we want OpenSC to be security project, we should probably rewrite the whole thing from scratch. With different priorities, the code will probably be completely different feature set will be smaller, and the quality of the code will be higher, thus also the cost of implementation and maintenance. Few years back, when I tried to push OpenSC enabled tokens to enterprises, I found that I just cannot do that, mainly because of this reason. I don't see this happening without sponsor and some full time developers. Maybe this is another issue that differentiate our views. I think there is a great value in current state of OpenSC to allow people to [at least] use hardware cryptography, even if this is not the perfect implementation, keeping it flexible enough to enlarge the cycle of devices and users. Apart of the value of people can actually use their hardware, this implementation will allow in future the necessary low level details in order to do the rewrite. Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Problem with CardMan4040 and OpenSC
Am Freitag 25 November 2011, 19:39:43 schrieb Niclas Hoyer: Hi, I'm running a recent ArchLinux on a Thinkpad x60t and installed a CardMan4040 pcmcia card reader. OpenCT works, at least I get an ATR: Buy a real card reader, CardMan 4040 never worked right in all these years, as far as I know. I reported bugs with the unstable kernel driver, and IIRC the developer had moved on to more interesting topics already, so I guess those remain unfixed. Who wants to use old and undocumented hardware, when there are nice alternatives with companies wanting to be supported and giving you support and documentation etc? Please vote with your money. Sorry, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] opensc-project.org in flight
I'm transfering the domain to Martin right now. He already configured everything, so you shouldn't notice anything. If you run into any trouble, please contact a...@dungeon.inka.de and mar...@martinpaljak.net. Thanks, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Fork of Debian's openSC repo at Github with ideas for 0.12.2 DEB
Hi Daniel, Am Sonntag 21 August 2011, 23:23:36 schrieb Daniel Kahn Gillmor: On 08/21/2011 12:36 PM, Peter Marschall wrote: * renable zlib readline support [...] what about a new, official Debian package, with my changes as the starting point as starting point? i don't think these are compatible with the DFSG, alas. GNU readline (at least) is GPL-licensed, and opensc links against OpenSSL. So building a package that links to both of them creates a non-redistributable work :( http://people.gnome.org/~markmc/openssl-and-the-gpl.html I agree with this. Is there any way to have OpenSC build against some crypto libraries other than OpenSSL (preferably licensed in GPL-compatible ways) so we could link it to readline without violating one license or the other? On the other hand: what part of opensc benefits from using readline? I guess the only place it might be used is the opensc-explorer, and it works fine for me without readline - so I say lets remove the readline code to avoid this. It might be nice to have opensc link with libgcrypt instead of openssl too. libgcrypt has a very nice interface and is much easier to use than openssl in my opinion. but if we work on such a change, we will have some fun with the new stacking: will applications (that use openssl or libgnutls) still work if that library or a helper to that lib uses a plugin interface (pkcs#12) to load opensc pkcs#12 plugin which is linked to (libcrypto or libgcrypt). we had problems even with app - openssl - opensc - libcrypto setup in the past, and I would expect problems here - or this should at least require a lot of testing to make sure the resulting setup works correctly. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ikey3000 opensc- woes
Am Donnerstag 04 August 2011, 22:39:23 schrieb sibu xolo: #--- #openct-control status No. Name Info === 0 Rainbow iKey 3000slot0: card present #--- good. but 'opensc-tool -n' returns No smart cards found maybe opensc was compiled without openct support, or it was disabled in the config file. check opensc-tool -r and the opensc.conf, set reader_drivers=openct. or it could be access control. if opensc-tool as root finds the readers, then you need to fix the permissions on /var/run/openct and the sockets in there. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] How to update http://www.opensc-project.org/files/pam_pkcs11/
Am Sonntag 07 August 2011, 11:32:58 schrieb Ludovic Rousseau: 2011/8/7 Andreas Jellinghaus a...@dungeon.inka.de: Am Samstag 06 August 2011, 15:49:24 schrieb Ludovic Rousseau: Hello, I just released a new version of pam-pkcs11. I added the file pam_pkcs11-0.6.7.tar.gz in the SVN repository at https://www.opensc-project.org/svnp/files/trunk/pam_pkcs11 But I can't see the new file on the web site at http://www.opensc-project.org/files/pam_pkcs11/ did you see any error during the commit of that file? I don't remember having an error. the server runs the commit script, which generates the commit emails and - in case of the files repository - updates the /var/www/files/ checkout. I ran the svn up manually and couldn't find any problem, and now the /files/ is up to date. The file at http://www.opensc-project.org/files/pam_pkcs11/ is dated 07-Aug-2011 06:28 But I made the commit at 2011-08-06 15:33:42 +0200 Either the server time is wrong or something happened to delay the web server update. timestamp from this morning, as I ran the svn up this morning. No idea why it didn't work for you yesterday. feel free to try with adding test files and removing them and let me know if it works. Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] unsubscribing from email management lists
Am Donnerstag 07 Juli 2011, 23:13:30 schrieb Martin Paljak: At least one person should be subscribed to the listmaster address, even if only to find out if anything is broken and fix it, or a human sends an email asking for help. Any volunteers? Have been doing this for a few years or so. ok, changed to config to point to you. I used your martinpaljak.net address - some config still hat the pri.ee address in it. Thanks and regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] unsubscribing from email management lists
Hi, I really don't have time to look at all the emails I get daily from the mailing list manager we are using - most of it is spam send to the list (and blocked, as only subscribers can post), but sometimes real people send mail to the list and either they need to subscribe and send it again, or someone needs to approve their requests. At least one person should be subscribed to the listmaster address, even if only to find out if anything is broken and fix it, or a human sends an email asking for help. Any volunteers? Thanks, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Code flow for Git branches / code review
some small questions: what about code review tools/sites like gerrit? Are those usefull for open source projects? maybe those are also easier to use for both submitting patches and merging those than posting patches to mailing lists or attaching them to tickets? also I'd think that anyone doing release management (incl. documentation, testing, communication etc.) is very welcome, and more releases would be a good thing? thus hard rules could be a problem, if they create restrictions or too much extra work or unrealistic goals. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Git build status.
Hi Martin, with the svn to git migration, I'm disabling my snapshot script. Is that ok? How cna jenkins create new tar files and upload those to opensc-project.org? Or can you run the service on the server directly? One thing that needs to be dealt with is opensc-commits, which also includes source code changes as they happen. And Trac changes. 33 people subscribe to opensc-commits. Ideas on how to manage that? What about RSS? Trac sends emails about new tickets, can you convert that into RSS? Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] any issue with the new server?
Hi everyone, I moved the server vm to a different host a few days ago. Is there any issue with the new host? There shouldn't be, and except for a small downtime (some hours) and a change in the ip config and name servers, there shouldn't have been any hickups. If you see any problem with the new hosting, please let me know so I can have a look. Thanks and best regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] moving opensc virtual server
Hi, I have a new server for hosting my virtual domains. So I will soon move all domains - including opensc - to this new server. That will create a downtime of a few minutes, and maybe a bit of a chaos for max. one day, as the ip address will change. I'm trying to get dns and whois info changed properly so there shouldn't be any long outage, but not 100% sure if it will work out correctly. So if you can't reach opensc sometimes this week - don't panic, try again after an hour later and you should be fine. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] moving opensc virtual server
Migration took a bit longer, but now the vm is running on the new server (i.e. this is a test email). More small hickups tomorrow, as we migrate the dns server. Good night and best regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Reading PKCS15 PIN max attempt number
not sure about athena, but many cards return the number of tries left, when you try to VERIFY a PIN. so if the PIN is wrong, the lower byte or nibble of the return code could be the number of tries left, and you can generate a messagebox from that. Good Luck! Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] CA key on card: how?
Am Donnerstag 17 Februar 2011, um 22:24:41 schrieb NdK: I've found a lot of tutorials to use openssl to generate self-signed certs (OK for my root CA), but couldn't find one where the signature is done by the card. Even on http://www.opensc-project.org/engine_pkcs11/wiki/QuickStart no, that wiki page is correct and works for me - done it a hundred times. it uses the key on the card, and the card does the signature (you cannot read the private key, a smart card won't ever give it to you). so maybe 10 is the wrong key id or something like that? good luck! Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] CA key on card: how?
Am Donnerstag 17 Februar 2011, um 23:30:57 schrieb NdK: On 17/02/2011 22:55, Andreas Jellinghaus wrote: no, that wiki page is correct and works for me - done it a hundred times. it uses the key on the card, and the card does the signature (you cannot read the private key, a smart card won't ever give it to you). Yup. That's why keys are generated on card :) so maybe 10 is the wrong key id or something like that? I generated it with $ pkcs15-init -G rsa/2048 -a 3 --id 10 -l Root CA you specified -a 3 so the pin 3 is needed to use the key. I hope you did create such a pin? Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Multiple certs on a MyEID card?
Am Sonntag 13 Februar 2011, um 21:39:17 schrieb NdK: What's the downside of setting it to bigger size? Maybe even 8192 or so? Can I override default profiles on a per-user basis in a simple way? I already tried copying myeid.profile and using -p, but I had to use ../../../../path/to/current/dir/myeid (.. to go to root, then full path of my modified profile, w/o .profile extension). I have no clue about myeid, but some other cards are only 32k for example. reserving 8192 would be 25% and that is only one directory file... and a fine tuning for each different card and driver: I don't think anyone has the time and manpower for that. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Multiple certs on a MyEID card?
I haveno clue about myeid cards. but in general you need to edit the profile to set the size of the *DF files (directory files, i.e. files with the list and attributes of all certs / keys / whatever). If some fileis too small, all you can do is erase the whole card and create a new pkcs#15 structure with larger files. yes, smart cards are quite old technology, files can't grow on demand :( sorry, I know ono way to calculate such file sizes. all you can do is try and error. the debug log file should show you what file is toosmall, so you can find out what file needs to be initialized bigger. Regards and good luck, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Is Aladdin eToken Pro 72k Java supported by opensc / openct?
Am Mittwoch 09 Februar 2011, um 19:51:15 schrieb LIMIN Thomas: Hello I have an Aladdin eToken Pro 72k Java. According to http://www.opensc-project.org/opensc/wiki/AladdinEtokenPro: The eToken PRO is fully supported by OpenSC and is well tested yes. but eToken PRO and eToken PRO 72k are two different and incompatible products :( I guess the eToken PRO 72k is a javacard connected to a ccid reader. so you can use libccid driver with pcsc-lite and opensc - but only if you install a javacard applet such as musclecard first using a tool like gpshell. see the cryptoflex cards, they are javacards too, and the process of loading an applet on them is documented there. but in general musclecard works ok for simple demonstration, but not sure if it has the features you expect from a production type setup. IMO we need a better javacard applet and opensc support for that, but there is none I know, so the situation isn't great. maybe the coolkey project is better suited for your needs? they have an applet which maybe can do more and works better than the musclecard applet (which has some issues - as far as I know). good luck and best regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Feitian PKI speed
Am Dienstag 08 Februar 2011, um 09:08:38 schrieb Ludovic Rousseau: I would not say openssh is slow or fast. That is not the problem here. It is _expected_ to have a _highly_ variable time for prime number generators. maybe some smart cards add extra delays if they find a random number fast, so that timing cannot be used to guess results from the rng? not sure if any card does something like that. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Canonical mailing list address
Am Samstag 15 Januar 2011, um 00:21:45 schrieb Lionel Elie Mamane: Then please change the Reply-To of the opensc-commit mailing list... Commit messages come with Reply-To: opensc-de...@opensc-project.org, opensc-devel@lists.opensc-project.org Messages sent by humans seem to contain Reply-To: opensc-de...@opensc-project.org which is even more wrong. sorry, somehow I didn't see your email. thanks for your report, fixed that. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Canonical mailing list address
Am Sonntag 06 Februar 2011, um 20:29:49 schrieb Ludovic Rousseau: I just got catch by this configuration bug. Mails sent to opensc-de...@opensc-project.org are rejected. So replying to a opensc-commit mail will generate a mail error. The opensc-commit Reply-To: header need to be fixed. Andreas? Martin? thanks, I didn't see the original email. fixed. Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[5185] Revert r5137, because size_t is defined as unsigned integer type ( without further qualification).
Am Sonntag 06 Februar 2011, um 20:23:59 schrieb Ludovic Rousseau: 2011/2/6 webmas...@opensc-project.org: Revision: 5185 Author: andre Date: 2011-02-06 17:28:30 + (Sun, 06 Feb 2011) Log Message: --- Revert r5137, because size_t is defined as unsigned integer type (without further qualification). http://www.opengroup.org/onlinepubs/95399/basedefs/stddef.h.html I will not argue on the fact that integer is not just int. It can also be long and long long. ... In fact the correct answer is %zu [1] But this does not work on Windows. windows has %I[uoxX] http://msdn.microsoft.com/en-us/library/tcxf1dw6(v=VS.90).aspx hmm, can you #ifdef WIN32 #define %size_t %Iu #else #define %size_t %zu #endif ? Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PCSC api questions
Am Montag 31 Januar 2011, um 10:35:47 schrieb Ludovic Rousseau: I don't know if it is possible to specify a PPS. It is not possible to do that using pcsc-lite unless the driver has support for it. ok, thanks for the advice! more reason to return cards with broken atr to the manufacturer :) one more question about return codes on SCard API: is SCardTransmit supposed to return values other than 0 and 0x8000 ? in windows scarderr.h it seems the upper two bits encode ok/info/warn/err and the other bits define the detailed info/warning/status/error code. So today I once saw (on windows) a api call to SCardTransmit return some non 0 but also non error (i.e. not 0x8???) value, and wonder what the right treatment would be. will investigate this issue tomorrow in detail, maybe I can find out what is going on. but maybe you or someone here knows about this already and can give me advice? in pcsclite.h I don't see this notion of different error/warn/... levels, only 0x0 (ok) and a list of 0x8.. errors (the usual stuff from windows). Thanks and best regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] PCSC api questions
Hi everyone, this is a bit off topic, but I hope you can still give me some advice about PCSC api usage (mostly on win). background: I'm changing some commercial code at work from a proprietory interface to standard PCSC interface and wonder how you can do some of these things... Is there a way tell the reader what PPS to use? I need three modes: NONE - only work with standard speed, ATR - try the better speeds adviced in the ATR (I can do the decoding etc.) and SPECIFIC - here are some settings, please use them. Normal cards are much faster if you use ATR, i.e. up to the speed the card announces in the atr. But I happen to known broken / badly initialized cards and the ATR announced by the card doesn't work, at least with some readers, so an option to turn PPS off is very important. And then there are cards with a very cautious ATR setting (9600 / standard speed), and communication can be much faster (at least in the readers I tested them), so having the option to tell the reader please try PPS with these settings is a good way to speedup the communication. well - these are my results from practice in a company doing card personalisation - but so far only with proprietory card reader interfaces. Google found some old emails about this topic, but I'm not exactly sure what the situation these days is. I fear it will depend on the vendor or driver, but maybe there is a standard for this these days? Thanks and regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC on Android
Am Mittwoch 26 Januar 2011, um 12:12:42 schrieb Nikos Mavrogiannopoulos: I don't understand what you mean by a reasonable enrollment system, however having seen the EMV protocol, I believe that the available PKCS #11 compatible smart-cards have a much higher security level than EMV bank cards. It seems the only criteria for banks evaluating protocols and technologies is their complexity. hu? can you go into details? I learned a lot about EMV in the past 10 months, and it doesn't seem hard to me. Of course there is a lot of complexity involved, but it is a partly online partly offline payment system with a very complex decission system (accept transaction offline or online or decline based on many different factors that can be personalized as parameters). a pure pkcs#11 card has something like 10% of the number of features that an EMV card has? so comparing those two and complaining about complexity seems to be quite unfair to me. Still I think we could learn from EMV and friends, for example companies with many employees might want a system to change cards in some remote reader in a secure way. Some banks can do that with scripting on emv cards, and the mechanism involved don't seem so hard. Something like that (e.g. to unblock or change the pin on a card connected to some machine remote) could be nice for opensc users too. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Canonical mailing list address
Am Donnerstag 06 Januar 2011, um 14:57:35 schrieb Peter Stuge: Cool. I'm not sure exactly how to implement that $handling, it also depends a bit on what tools and processes are used on the server. see one of my last emails in the thread. postfix has everything we need build in. I also think the lists. name is important to drop, but having a canonical address is much more important. Implemented. you shouldn't be able to send email to opensc-d...@opensc-project.org any more. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Key renewals in HSMs
maybe use a central ca creating the keys and storing them (and the cert) on the cards? that way the key would be created by the hsm of the ca. of course you would need a card with secured and authenticated connection to it, so you can be sure to store keycert on the card of your choice. opensc unfortunatly wouldn't help you for any part of implementing that - guess we have no code for such requirements. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Canonical mailing list address
Am Mittwoch 05 Januar 2011, um 18:26:10 schrieb Peter Stuge: The motivations are, again: * to have one canonical mailing list address + meaning that mail to other addresses has some handling to help guide posters to the canonical address (ie. something better than current forwarding) fine with me, we can implement it as suggested. * without lists. is more intuitive, shorter, and prettier, to me and that is a good reason to force everyone else to switch to a different address? here is the statistic from okt/nov/dec 2010: r...@opensc-project:/var/log/syslog# grep to=opensc-de...@opensc-project 2010-1* |grep -v NOQUEUE |grep status=sent |wc -l 92 r...@opensc-project:/var/log/syslog# grep to=opensc-de...@lists.opensc- project 2010-1* |grep -v NOQUEUE |grep status=sent |wc -l 521 92 mails to opensc-devel@ and 521 to opensc-de...@lists.. further analysis even shows even less mails to opensc-devel@ : r...@opensc-project:/var/log/syslog# egrep `grep to=opensc-de...@opensc- project 2010-1* |grep -v NOQUEUE |grep status=sent |cut -d -f7 |cut -d: - f1|xargs echo |sed -e s/ /|/g ` 2010-1* |grep from= |cut -d -f8 |sort | uniq -c |sort -r -n - 8 from andre.zepezauer, 6 from martin, 4 from ludovic, 4 from alon, 2 from viktor, 2 from s4ms0n0v, 4 from no-reply and donot-reply, 2 from gmane. so we are talking about 26 emails by 6 people. wouldn't it be easiest to ask those 6 people, all well known contributors to opensc, to use the right email address? At least I completely fail why changing the email address that everyone else uses properly for years is any good. why ask hundreds of users to change their email settings (mail filters, contact lists, address books etc.) only because of you like one form more than the other. and for me the whole argument about the length of the email address is rediculous. these days I click on a mailto: link on the web page and start typing the email. the only time I ever enter an email address, is when I have a new contact on the phone and they tell me their address. at least it is this way for me, and I do think that about everyone works this way these days. so with this statistic, is there any reason not to simply remove the aliases for the old names and send a mail to those 6 people and ask the to update their addressbook? Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Canonical mailing list address
Am Mittwoch 05 Januar 2011, um 13:24:43 schrieb Peter Stuge: Andreas Jellinghaus wrote: the biggest argument of course is: why change a working system? But it isn't working, that's the point. It's ambiguous and unneccessary to have two addresses for the list and every now and then there are duplicate messages because a message ends up being sent to both addresses. Better to not have that. so you want a postfix config change with smtpd_recipient_restrictions gaining an check_recipient_access with the old @opensc-project.org addresses listed with REJECT Some nice information ? shouldn't be much work. If you haven't updated the email address in your contact list for that many years, this could force you do to that. And it's also much prettier to not have the extra lists. after @. you want to annoy all the people that did update to the new email address in favor of a handfull of people that didn't? not a nice move. I don't think it needs to. At a minimum there should be forwards like there is now, just in the other direction. There could even be some rewriting (procmail+formail or such) for the @lists. addresses. wow, that will be such a much better situation. instead of gettign A and a duplicate B you will get B and a duplicate A? I think shakespear wrote Much Ado About Nothing... Misunderstanding. I mean does anyone receive email to an address @opensc-project.org that is not for one of the lists? in the past every developer had an email alias @opensc-project.org, and a few people still use them. also there is bugs@ and webmaster@ etc. One argument was ease of moving the mail handling elsewhere, but if there's only really the lists to consider then changing MX in DNS already allows full freedom to move, no extra name is needed. why annoy everyone with a change that (at least it looks to me) will not improve the situation at all? we could simply drop the old email addresses without lists. with a reject containing the new name (introduced in 2004 or so?). Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Canonical mailing list address
Am Montag 03 Januar 2011, um 23:59:47 schrieb Peter Stuge: opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel I would appreciate if we could change the canonical email address of the list to be *without* the lists. name. Possible? but it is much easier to direkt all emails to @lists.opensc-project.org to mailman. the alternative would be to write a long list of all those list and list-postfix email addresses and manualy direkt those to mailman. been there, done that, much more work on the admin side. we could remove the old aliases @opensc-project.org so they finaly die. no idea why people still use them, guess old contacts in their email apps. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] FOSDEM 2011: february 5th and 6th
Hi everyone, I'm really sorry and it is frustrating, but things went wrong here and I won't be able to make it to fosdem this year. Still I hope many of you can make it and will have a good time. With best regards, Andreas p.s. And a happy new year to all of you! ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Canonical mailing list address
the biggest argument of course is: why change a working system? also, it might affect every single user, if we change the email address of the list, so that alone is a very good reason to not do that. Hm? Is anyone using email addresses @opensc-project.org ? 19 emails to opensc-de...@opensc-project.org, 1 to opensc-u...@opensc- project.org (so far: this year). mostly martin, viktor, you, and a few other people. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Windows 7 support for PKCS#11 = mini-driver
Am Montag 20 Dezember 2010, um 07:39:43 schrieb Nikolay Elenkov: On 2010/12/20 15:23, Andreas Jellinghaus wrote: 2.) a PKCS-CSP such as the ID-Ally CSP, CSP#11 or PKCSCP - all these packages implement a CSP, but they don't talk to the smart card directly. Instead they load a pkcs#11 plugin to do that, such as opensc-pkcs11.so Forgot all about those. Are any of those still supported? Last I checked was maybe a couple of years ago and they were pretty much dead. ID Ally CSP worked ok for me. An open source version is available in redhat or fedora as coolkey CSP as far as I know. I haven't tried anything later than XP however, and did only basic testing back then. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Windows 7 support for PKCS#11 = mini-driver
Hi Jean-Michel, there is no PKCS#11 smartcard, as the format of the data has nothing to do with the API of the software used to access the card. The traditional way for windows software is this: 1.) a baseCSP minidriver to access the card combined with 2.) a PKCS#11 plugin to access the card, either via CSP or directly. The traditional opensc way for windows however is this: 1.) opensc used to access the card from PKCS#11 applications. 2.) a PKCS-CSP such as the ID-Ally CSP, CSP#11 or PKCSCP - all these packages implement a CSP, but they don't talk to the smart card directly. Instead they load a pkcs#11 plugin to do that, such as opensc-pkcs11.so I haven't tested yet if you can use the new opensc minidriver and opensc- pkcs11.so at the same time, or if this will cause any kind of conflict. Also one option would be a kind of daemon or server process, and have all applications talk to that one, so you have a central instance, and you can implement single sign-on that way (enter pin once, use card with all apps). However not everyone likes that idea, and some cards (e.g. eID) require the pin to be entered for every single use. And I'm not aware of any working implementation of this idea. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] heise.de / h-online.com : When a smart card can root your computer
http://www.h-online.com/open/news/item/When-a-smart-card-can-root-your- computer-1154829.html http://www.heise.de/security/meldung/Wenn-die-Smartcard-den-Rechner- rootet-1154599.html Heise reports a security issue found in OpenSC. As far as I can see the code was added in 2004 to the starcos driver with the bug and has found it's way cutpasted into other drivers later. If you only use certain cards, and the code for your card is not vulnerable, then you can edit opensc.conf and set card_drivers to the name of your card driver, thus disabling all other drivers. Warning: I haven't tested this myself. Or you can apply this patch (link by heise, haven't looked at our code myself): https://www.opensc-project.org/opensc/changeset/4913 Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] anyone at cartes?
Hi everyone, is anyone going to cartes? that is the biggest smart card exhibition as far as I know, in paris 7.12. - 9.12., i.e. starting tomorrow. If so, please feel free to send report, I guess everyone is interested about all the new stuff you can tell us about. Personally I'd be interested in: * cheap jcop cards (contact only, dual interface, or as cheap usb stick). and of course resellers that sell them at reasonable price (low quantities, like only one or only five). * nfc phones / adapters etc. * industrial card readers (i.e. either very small or with a seperate chip contact unit). and/or card readers with contact heads (i.e. contacts from above, not the usual sliding contacts that leave small scratches on cards). if you happen to see any of that, maybe you could take a note and post it later? thanks :) Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] anyone at cartes?
Am Montag 06 Dezember 2010, um 19:44:58 schrieb Martin Paljak: Hello, On Dec 6, 2010, at 8:13 PM, Andreas Jellinghaus wrote: Personally I'd be interested in: * cheap jcop cards (contact only, dual interface, or as cheap usb stick). and of course resellers that sell them at reasonable price (low quantities, like only one or only five). Why JCOP? Which version of JCOP, why not some other JavaCard? ok,I should have written javacard. So far I only know jcop - and any other card (preferable with a public documentation, not the JCOP secret+NDA stuff) would be nice. How cheap is cheap? cardomatic sells single pki cards starting at 12€ (10 cost 9€ each). jcop dual interface starting at 19.80€. that is the best offer I know so far (most companies are only interested in volume sale so I'm happy there are few retailers selling single cards at all). so cheap would be 20%+ less than that. after all in volume cards are sold at cents, not euros (with volume ~ 10⁵). Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Upper limit for file size to upload into 'contrib'
Am Sonntag 26 September 2010, um 14:52:58 schrieb Viktor TARASOV: Hi, what is the maximal possible size of the file to commit into the 'svn/files/trunk/contrib/' ? My attempt to upload the MSI of the opensc-sm, that weights a little bit more the 2M, was refused with error '413 Request Entity Too Large'. many files in the files svn are 10mb or larger. so 2mb shouldn't be an issue. also there is pletty of disk space left and we have no hook scripts to enforce any limites. so maybe this is a client issue? do you use a web proxy? http or https connection? Regards,Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] FOSDEM 2011: february 5th and 6th
Am Mittwoch 22 September 2010, um 08:28:41 schrieb Jean-Michel Pouré - GOOZE: Le mardi 21 septembre 2010 à 19:25 +0200, Andreas Jellinghaus a écrit : I haven't found a nice hostel so far. any suggestions? Several years ago, I stayed in Sleep Well Youth Hostel http://www.fosdem.org/2011/practical/accommodation It is more like a hotel with individual rooms and shower. I was pretty amazed by the quality. There is a bar downstairs. And it is very cheap. Call for more information and to confirm. Thanks, it looks real nice. except I can't book - no room availabity for 4th/5th of february. so either they are booked out already, or I can't book this early (more likely, some other hostels can be booked earliest a month before the date). Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] pkcs11.h
Am Donnerstag 23 September 2010, um 02:49:56 schrieb Andre Zepezauer: Therefore my question is: Do you think it could be worthwhile to take some efforts on standardising on *one* single definition of pkcs11.h? And given the case it would be worthwhile, how to start such an effort? talk to rsa labs. they have a plan for a new version of the pkcs#11 standard and they want to change the license of the pkcs#11 header files at that time too. then we can all drop both our old and badly licensed pkcs#11 header files from rsa labs or the new and free, but only partial, reimplementation from scute project. except of course those projects, that don't want to implement the new version of the standard. thats the problem with versioned standards: everyone can pick the version they want to implement and support, and thus subtile incompatibilites are possible. the non-free license on the header files, thus the need to reimplement what we need from those files, made the situation even worse. but I still hope pkcs#11 v2.30 will be released soon with a free license on the header files. and that it won't contain problematic changes, thus everyone can update to the new header files (and simple keep the version number they implement at a lower value, if they don't want to update). Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] FOSDEM 2011: february 5th and 6th
Am Dienstag 21 September 2010, um 07:17:15 schrieb Peter Stuge: FOSDEM loves this. Reading http://fosdem.org/2011/call_for_devrooms they say over and over that they want related projects to cooperate, and they will be prefered at the conference. Should we organize ourselves a foss crypto devroom? Applying for booths (stands) happens later, after the devrooms have been decided on. I believe that if we have a devroom then there won't be a stand. But there could be a demo table in a corner of the room. not sure if we need a full room. I guess large projects like debian do, but opensc is pretty small. and what other projects would there for a crypto room? openssh and openssl are most likely tied to openbsd, if anyone from those projects attends? if there would be a workshop room that you can have for an hour or two or three, that could be nice I think. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] FOSDEM 2011: february 5th and 6th
Hi everyone, I always wanted to go to FOSDEM conference in Brussels, Belgium. Next year the conference will be on 5th and 6th of february. Maybe more people on this list are interested in going there and meeting up, and maybe having a devroom, a talk, or whatever other options we have? Last time we talked about something like this the conference was real close. But this time we have about 5 months till the event, so that might be enough to organize many people, plan ahead of time, get cheap flights/train tickets/travel arrangements etc. What do you think? Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Redirect loop on Trac login
Am Sonntag 05 September 2010, um 17:22:31 schrieb Emanuele Pucciarelli: Hello, I have an issue with Trac. Since I have reset my password I can't seem to login. If I try to login with a wrong password, then the correct error message comes up. trac.log: 2010-09-05 16:18:44,853 Trac[session] WARNING: Attributes for session ep already updated: can't adapt no idea what is wrong, with google I can't find that error message. trac-opensc= delete from session where sid='ep'; DELETE 1 I hope this helps, please try once more. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] new anti spam configuration
Hi everyone, we got some spam on our list, send by people using the list address as from: in smtp. I changed our email config to check the smtp sender address properly (valid host etc.) and also blacklisted our mailing lists as from address. I hope that works - reduces spam send to opensc and delivered to you via opensc, and not blocks any other legal mails. but if it does, please send me an email with the mail header / details of the mails rejected, so I can debug and fix the mail system configuration. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Initialisation of CardOS
Am Montag 30 August 2010, um 22:13:34 schrieb Andre Zepezauer: what do you think of dropping the possibility to initialise CardOS smart cards in 0.11.14? The reason of doing so, is to stop the production of more of these questionable split-key cards. Very bad idea. CardOS is working very well (at least for me). In my tests the old split-key code worked ok, the new code with the new format without split-key, and the new code still worked with old split-key cards (well, not sure if you can modify them a lot, but at least use them). also I have cards initialized by siemens and they work with both versions of opensc. People who want to initialise CardOS are then forced to do this with either 0.11.13 or 0.12.X. Hopefully they chose the newer release, because it comes with an improved initialisation for CardOS. No more split-keys here! Cards initialised with 0.12.0 should work with the 0.11.X releases too. Verification of this fact is required of cause. IIRC new cards work with old opensc too, true. but I'd need to check once more. (- use. modify is a different story...) Another fact is that for example Ubuntu 10.04 and Debian Squeeze will stay with the 0.11.X branches for at least the next three years. they don't even fix bugs. or at least it is a __HUGE__ task to get a bug fix into either distribution. so big, I gave up. all we can do - from my point of view - is to create well working releases, work with the packages, so the new release is packaged well, and that has to happen way before a new ubuntu or debian release is even close to the freeze. for debian that opportunity slipped away in the last months, for ubuntu you need to work hard about 6-4 months before the release. The same holds for other distributions with a long release cycle (RHEL has seven years of support I think). The imagination that someone could easily produce new split-key cards for the next few years isn't very appealing to me. RHEL includes opensc? that would be new to me. I guess RHEL only includes a small, limited set of packages with red hat support? they have coolkey, so why would they include and maintain another solution for smart cards? Too much numbers and bad wording, I know. But what do you think of it? If this could be feasible? if you are aware of bugs or problems, why not spend your time on debugging the issues? the lines of code changed (related to cardos split key) in the last three years was maybe 50? so it is not very much code that needs to be looked at and debugged to find out, if something isn't working as expected. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] planned server downtime 30th of august to 31st of august
the hoster of opensc-project.org is moving the machine to a new data center, thus the machine will be unavailable from august 30th ~22:30 CEST to august 31st ~07:30 CEST Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Spec for specifying PKCS#11 modules to load
Am Sonntag 18 Juli 2010, um 00:16:15 schrieb Stef Walter: Is there a spec around for specifying to applications which PKCS#11 modules to load and how to initialize them? I'm thinking something along the lines of PAM conf files, where you can specify which PAM modules different applications load. We're working hard on PKCS#11 support in GNOME, and rather than coming up with something like this on our own, perhaps someone has already given this some thought? I think it could be great, if a middle layer API for applications was created. Why should all the details of crypto layers (like what algorithms you support in ssl connections, where your root certificates are, what certificates you have etc.) implemented again and again for each new application? microsoft has crypto API that works as such a middle layer, and apple has some middle layer too. so I think a middle layer could be great for gnome, kde, freedesktop, whoever-wants-to-use-it. and it could be build with smart cards in mind, so opensc and other pkcs#11 modules could be integrated somehow. but I know next to nothing about gnome or kde or any gui app and how a middle layer could look like, so not sure if I could be of any help there. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Aladdin eToken Pro w/PKCS15 (was Re: OpenPGP card v2)
Am Mittwoch 14 Juli 2010, um 19:41:09 schrieb David Woodhouse: On Wed, 2010-07-14 at 20:31 +0300, Martin Paljak wrote: http://pcsclite.alioth.debian.org/unsupported.html#0x05290x0620 It is not supported / only works without a reset. Thank you. With 'connect_reset=false' in opensc.conf, I can now run 'opensc-tool -a' more than once. However, I don't seem to be able to do much *else*... [r...@i7 dwmw2]# pkcs15-tool -D Using reader with a card: Aladdin eToken PRO USB 72K Java ... Am I just being *completely* stupid?... eToken 72k are javacard based. thus you need: 1.) make sure you have a special test/developer edition, where you can store your own javacard applet. if not, you have one with the aladdin applet on it - which works only with the aladdin software. (they make more money by proprietory bundeling token and client software...) 2.) if you have a developer token, you can store an applet on it, that opensc supports. once that is done, you can use it with opensc. the only open source applet opensc supports is the muscle applet, and its support is not 100% - you can get it to work, but while opensc supports many different and complex setups with some cards, for muscle card only a few special setups work and are supported. the wiki has more information on the musclecard applet (some if it might be in the cyberlex section - cyberflex was the first javacard widely available, and tools that work with it, should work with all the other javacards and tokens with javacard inside as well). yes, the situation is a bit disappointing. every gread card or token that works great with opensc is no longer sold, outdated, hard to get etc. (cryptoflex from schlumberger was great, no longer sold. aladdin etokens 32k/64k were great except for the cardos problems (secret startkey) - replaced with the java based token. ikey3000 with starcos was great - never was sold in volume as far as I know (and most starcos cards or token are not the eraseable test edition that is inside ikey 3000). we could improve by supporting new cards like acos5 - noone found time for that so far - or writing/improving the javacards applet and the driver for them - noone found time for that either. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] CardOS 4.3
Hi Kerstin, Am Mittwoch 07 Juli 2010, um 14:05:42 schrieb kerstin.ho...@uv.ruhr-uni- bochum.de: Hi Andreas, I checked out 0.12.0-svn-r4413. With this version, our cards work again. In the previous versions (up to release candidate 0.11.14) it seems to be the change of flag SC_PKCS15_CARD_FLAG_SIGN_WITH_DECRYPT that caused our problems. good to hear the svn version works for you. still it would be interesting to find out why that happened. If you like we can send one of our RUB-Cards to you for testing purposes. thanks, but my free time for opensc is currently so small, it would most likely get dusty without being used. maybe someone else here is interested in looking into this issue and could use the card? Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [RFC] removal of more split-key related pieces
If you initialize a card with old opensc and split-key, and then try to use or alter it with the new opensc with that patch, does it still work? I didn't touch some parts of the code, because I feared to break support for old opensc cards initialized with split-key. we should never do that IMO, even if it means keeping legacy code. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PKCS #11 Spy
Am Montag 21 Juni 2010, um 08:47:07 schrieb Jean-Michel Pouré - GOOZE: On Sat, 2010-06-19 at 19:06 +0200, Andreas Jellinghaus wrote: google pkcs11-spy and the first hit is: http://www.opensc-project.org/opensc/wiki/UsingOpensc Thanks I updated the doc with examples. Now, I try to reproduce with ssh-add: PKCS11SPY=/usr/lib/pkcs11/opensc-pkcs11.so \ PKCS11SPY_OUTPUT=/tmp/pkcs-spy.log \ ssh-add -s /usr/lib/pkcs11-spy.so Enter passphrase for PKCS#11: SSH_AGENT_FAILURE Could not add card: /usr/lib/pkcs11-spy.so There is no log in /tmp/pkcs-spy.log ssh is complex, so this won't work. try that instead: PKCS11SPY=/usr/lib/pkcs11/opensc-pkcs11.so \ PKCS11SPY_OUTPUT=/tmp/pkcs-spy.log \ ssh-agent bash and inside that bash ssh-add -s /usr/lib/pkcs11-spy.so because I guess, that ssh-add tells ssh-agent hey, the user requested you open pkcs#11 module with path ... and use it, but the ssh-agent does the actual loading of the module and using it. if you try ssh directly without agent, of course this should work: PKCS11SPY=/usr/lib/pkcs11/opensc-pkcs11.so \ PKCS11SPY_OUTPUT=/tmp/pkcs-spy.log \ ssh u...@machine -o smartcard=/usr/lib/pkcs11-spy.so note: I don't know what the real option you need to give to ssh is. but you get the idea. and always remember: if you start setuid or setgid applications, the kernel (or ld.so?) will remove some environment variables. also some applications clean the environment variables when they are started too, so you can't use malicious environment variables with them. typical example: you can't run PKCS11SPY=/usr/lib/pkcs11/opensc-pkcs11.so \ PKCS11SPY_OUTPUT=/tmp/pkcs-spy.log \ login with pkcs11-spy.so configured as pam module, that won't work. well, it might work if you are root, maybe also login needs not have setuid/setgid. but you get the idea - important apps like su, login, sudo and friends cleanup the environment before they start (or the kernel or ld does that for them). I hope this helps? Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] CardOS 4.3
Am Freitag 18 Juni 2010, um 14:09:33 schrieb Johannes Becker: Am Montag 14 Juni 2010 schrieb Andreas Jellinghaus: 1.) define a test. for example pkcs11-tool --test --login --pin ... --slot I didn't succeed yet in testing all you've proposed. Here an intermediary result. The RUB-Card from Bochum works on windows with http://www.opensc-project.org/files/build/opensc-i686-pc-mingw32-006- base.tar.bz2 , which is opensc 0.11.9 The RUB-Card doesn't work with opensc 0.11.9 on Debian Lenny, while the Uni-Gießen Card (TCOS) is ok with that. I attach the output of the test below. As I've posted earlier, all the opensc builds higher than opensc-i686-pc-mingw32-006 don't work with the Uni-Gießen Card. To be precise, the command line tools work, but opensc-pkcs11.dll doesn't. I didn't find a working configuration for RUB-Card on Linux yet. I wonder if we have major difference between opensc on Linux and Windows. not sure either. but it command line tools work, the problem is strange indeed. (however differnt command line tools test different aspects of the software, so maybe you only tested some parts with some tools?). in any case without an opensc debug log file, there is little we can say about the problem. your output shows only that something didn't work, but not what. note: a debug log file will include certificates, pin number etc. so beware if that content is confidential. (but you can as well easily find your pin and replace it with X characters I guess) Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] libassuan 2
Am Freitag 18 Juni 2010, um 15:44:57 schrieb Alessandro Premoli: Is there a plan to switch from libassuan 1 to libassuan 2, as gnupg just did, for the signer browser plugin? there is not a single known user of the signer plugin, thus we removed it from opensc code, and the next major release (0.12.*) won't include it. Thus there is no need for migrating it. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] CardOS 4.3
Am Donnerstag 17 Juni 2010, um 13:25:42 schrieb kerstin.ho...@uv.ruhr-uni- bochum.de: Hi, thanks for your reply. I will try the code in the trunk next week. good! I already tried the release candidate 0.11.14-rc1. This does not work with our cards, we have the same problem as with version 0.11.12 and 0.11.13. of course. we can't fix the bug unless someone can find out what exactly is not working. btw: I assume you have cards initialized with some other software and try to use them with opensc? otherwise we would need to know which opensc version was used to initialize the cards / which to use them. btw: the code for enabling that sign_with_decrypt hack is in src/libopensc/pkcs15.c, line 749ff /* for cardos cards initialized by Siemens: sign with decrypt */ if (strcmp(p15card-card-driver-short_name,cardos) == 0 scconf_get_bool(conf_block, enable_sign_with_decrypt_workaround, 1) ( strcmp(p15card-manufacturer_id,Siemens AG (C)) == 0 || strcmp(p15card-manufacturer_id,Prime) == 0 )) p15card-flags |= SC_PKCS15_CARD_FLAG_SIGN_WITH_DECRYPT; i.e. make sure: 1.) your manufacturer_id is Siemens AG (C) or Prime 2.) you have enable_sign_with_decrypt_workaround turned on (default as far as I know). 3.) you are debugging a _signing_ opteration. 4.) the key usage is both sign and decrypt not sure if 4.) matters, but maybe the workaround is only used with that situation - if key is signing only, it should be used with sign APDU of course. but if the software used for personalization got that wrong, we would need to add extra code to handle such bugs. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] CardOS 4.3
Am Mittwoch 09 Juni 2010, um 12:41:51 schrieb Johannes Becker: Hello, I got a card for testing purposes from the Ruhr-Universität Bochum. It works with Windows, the newest Firefox and opensc-pkcs11.dll from good old smart card bundle. (opensc 0.11.4). It doesn't work on Debian Linux Testing (opensc 0.11.13-1). My impression is, that the problem is not the operating system but the opensc version. (I will test that later). How to get it working with a newer opensc? 1.) define a test. for example pkcs11-tool --test --login --pin ... --slot 2.) run the test with a known good config, and debugging enabled. (edit opensc.conf, set debug_level to 9 and some debug file) 3.) run the test with the new opensc, same settings. 4.) use diff / some tool to see what is different. we can help with instructions for 1-3 and with 4 (if you provide log files somewhere). note: if you use production cards: your details and the pin can be in the log file. if you have a pure test card, I guess that is ok. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] CardOS 4.3
Am Donnerstag 10 Juni 2010, um 13:58:58 schrieb kerstin.ho...@uv.ruhr-uni- bochum.de: Hi, I am working on the SSO- and Signature-Framework at the Ruhr Universität. We recently tried to upgrade to version 0.11.13 but encountered some problems with the apdus sent for digital signature operations. CardOS 4.3 cards provide two commands for the same functionality, PSO_ CDS and PSO_DEC. Unfortunately in CardOS the usage of the commands depends on the signature object created on the card. The cards of Ruhr-Universität Bochum need PSO_DEC (the Siemens approach for key objects that sign and decipher). Some changes in OpenSC version 0.11.12 resulted in choosing the PSO_ CDS command instead of PSO_DEC for our cards. opensc 0.11.11 to 0.11.12 - I can't see any big change that affects the sign-with-decrypt hack. but you could try these changes: --- src/libopensc/pkcs15.h (.../opensc-0.11.11)(Revision 4413) +++ src/libopensc/pkcs15.h (.../opensc-0.11.12)(Revision 4413) -#define SC_PKCS15_CARD_FLAG_SIGN_WITH_DECRYPT 0x10 +#define SC_PKCS15_CARD_FLAG_SIGN_WITH_DECRYPT 0x1000 that was mostly to make it a flag that is run-time configured only and not written to the card. (i.e. the old code wrote the flag to the card, that shouldn't have happened, and any way the new code should read the card code, and then add any internal flags necessary...) There has already been a posting by Andreas Jellinghaus at 12.March 2010, removing --split-key,using decrypt() for signing keys with usage sign, decrypt on cardos. I think the proposed solution should fix the issue. The last version that works with the cards of Ruhr-Universität Bochum on OS Windows is 0.11.11. maybe you could try opensc trunk too? I hope that trunk has the best code we can offer for the problem, mostly working like siemens does, but still working with old opensc cards too. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Release procedure, why backport trunk to releases/opensc-0.11.14?
you seem to be confused: noone is merging trunk into 0.11.4. for 0.11.* there is maintanence only: some urgent bugs are fixed in a new 0.11.* release, with those important bug fixes only. trunk is incompatible ABI and API wise with 0.11.* so it can't be merged without breaking ABI and API. the plan is to create a new 0.12.0 release sometime soon from trunk, as far as I know. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [patch 0/3] [RFC] Adding an 'in system' SmartCard interface
Am Donnerstag 27 Mai 2010, um 10:57:58 schrieb Juergen Beisert: what is missing are some small issues: * license: LGPL-2.1+? or 3-BSD? or some other license? In my next version I replaced the license information by a link to the 'LGPL-2.1' file. Okay? ok. best use the template in the license text (at the end). Ah, you ask for documentation. ;-) OpenCT uses Doxygen. Does it use it also for user documentation or only for API documentation? I would prefer to keep code and usage documention together by adding it in docygen style into the source code. But I'm also fine with adding it to another place (like the OpenCT homepage for example). no, doxygen use in openct is not really done or maintained. it is bestto edit the openct wiki (although martin is replacing some wikis with the central opensc wiki, I think the openct wiki is not affected - though not sure). or put a txt file into the source with details. * kernel patch: is it published somewhere? Not yet. I started the discussion here to define the kernel API first. Publishing it at the kernel maillist will follow now. ok, fine. There should be no need for any user adding the driver itself to his/her kernel. Our plan is to bring it into the mainline kernel. very good. Card and application is customer specific. I will try to get a more useful card for the regression tests. Hope also OpenSC is cross compile aware... we use standard autoconf/make/libtool with no dirty tricks as far as I know, so it should work, or at least provide a good base. That is the question: Do the readers the negotiation triggered (and controlled) by any kind of userland application, or do they do it internally in their firmware by their own? I think some do it internaly. but pcsc standard dictates the application uses some mechanism to let the driver (ifdhandler) know what speed it wants. the card will refuse. not sure if you have several tries in pps negotiation, or if you need to reset the card (warm or cold) in between. AFIAK some cards are answering with a different ATR when they see a second reset after they send their first ATR after power up. A perfect negotiation seems tricky... yes, with warm reset the card can show different ATRs, while with cold reset it will always start with the first. I don't know the other card readers: In my system I can power down the card, but I can still continue to check to card presence pin. good! Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new versions
Am Donnerstag 27 Mai 2010, um 11:01:53 schrieb Kalev Lember: What API/ABI stability are you talking about? right. since only the tools inside opensc source code use libopensc, there is no need to worry about ABI/API any more. so let me rephrase the question: can we target a new stable release now, or are there current plans for major changes, and should we wait for those before aiming for new releases? Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [patch 3/3] Add i.MX card reader support
Am Dienstag 25 Mai 2010, um 15:54:10 schrieb Ludovic Rousseau: You may want to specify a LGPL license version. 2.1 or 3.0 or (at your option) any later version? I had a quick look at the other OpenCT files and they do not use the standard LGPL license text. And the license version is not indicated on the OpenCT project page [1]. Just that the project uses LGPL. [1] http://www.opensc-project.org/openct OpenCT smart card reader drivers, middleware and library (C) 2003-2006 Copyright by the OpenCT Authors listed above This software is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. is the normal license. Most of the code is still BSD-3 licensed too (and all of libopenct is), but some drivers are already LGPL-2.1+ only, so another new driver with LGPL-2.1+ is ok. If you want to go for LGPL 3 or 3+ (or 2.1) or any other new license, lets have a discussion about that first (so we know why, and how it will affect openct as a whole). About the web page: hmm, there is now a link to fsf web page with lgpl? strange. AFAIK the authorative parts are this: http://www.opensc-project.org/openct/wiki/LicenseText - core is BSD-3 http://www.opensc-project.org/openct/wiki/AuthorsAndCredits - in more details: some parts are LGPL 2.1+, thus if you compile in those parts, the whole is LGPL 2.1+. if you compile OpenCT without those parts, it is BSD-3. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [patch 0/3] [RFC] Adding an 'in system' SmartCard interface
the code looks good to me. very clean, nice! what is missing are some small issues: * license: LGPL-2.1+? or 3-BSD? or some other license? * the whole picture: if someone has a patched kernel and openct with these changes: how does he get it to work? mknod to create a device and a static config in openct.conf? or sysfs, udev and hotplugging? (if so, what changes are needed for udev...?) if the big picture is described somewhere, a url would be fine too. * kernel patch: is it published somewhere? we could carry a copy from my point of view, or a txt file with a url in it or something like that (or simply edit openct wiki and create a new page, and possibly attach it, if you like). The kernel driver is not part of this patch stack. Please bear with me, if the SmartCard handling seems broken at any point. I'm not a SmartCard expert. This is my first attempt to make them work. do you have some card and app for testing? opensc and a cardos card for example, and running the opensc regression test suite. Some notes: - I'm not sure if something like the 'src/ifd/direct.c' is really required. I wrote it to get my userland driver to work and to be able to setup my interface in the same manner like the other reader's drivers. Most functions are dead in this file, because the communication to 'in kernel' drivers is much simpler than talking to a serial or USB device. Suggestions to avoid this file are welcome. hmm, not sure if direct is such a good name, but I don't know a better one myself. in general keeping that abstraction is ok with me. - there was the need to touch 'src/ifd/atr.c' to be able to calculate some timeout values. If there is a generic way to extract the CWI/BWI related to a specific protocol, please give me a hint. I think for the other reader devices, this kind of calculation is done in their firmware, right? not sure, maybe openct lacks proper handling there. At last I never bothered with all that, since usb crypto tokens are often very fast by default. * what is the default 'block waiting time' for the T0 protocol? I thought T=0 is character based, so there should be none...? but no expert here, only used T=1 devices myself. * what is the correct behaviour, if the card wants to use a specific FI/DI pair, the hardware cannot handle? the card lists in atr what it can do. the reader doesn't need to do pps, it can stay at the default speed. or it can use PPS with any fi/di it wants, not only the one listed in the atr. if the card accepts that fi/di in pps communication, both sides are fine with it. also not sure 100% how higher level APIs work, but I thought apps need to trigger PPS? still many readers do pps by themself, so cards are always as fast as possible with them, at least I think. (well, at least drivers for windows might do that...) Falling back to 1/1, or trying to use a FI/DI pair with slower transfer speed? I'm using the latter one, but I'm unsure if its correct. And what to do, if the FI value is supported, but the DI value is to small? (for example: Card wants FI/DI=13/1, but my interface can only handle 13/2, 13/3, ...) the card will refuse. not sure if you have several tries in pps negotiation, or if you need to reset the card (warm or cold) in between. [power management] hmm, good idea. if noone keeps a connection to the reader open, it could be suspended and everything turned off. however is some app keeps a connection open, it must stay active, so that a verified state (pin confirmed) isn't lost due to a power down. * Even running openct-control shutdown seems not to call the driver's 'close' function. Bug or feature? guess a bug. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Built-in SmartCard reader
Am Donnerstag 20 Mai 2010, um 10:11:03 schrieb Juergen Beisert: That's exactly what I have. But to bring such kind of driver into the mainline kernel, the API to the kernel space must be more generic. That's the reason, why I'm asking for more uses cases for these SmartCards than I have with my small (and special) hardware. hmm. I still would try to keep it as simple and small as possible. a larger API with functions noone implements simply rots, and isn't helping anyone. Currently I'm using a simple char device node. sounds good. I'm a kernel hacker. Writing kernel drivers is my daily job. But defining an API for SmartCard interfaces isn't. the problem: in my opinion the interface to smart card readers is defined with serial ports (e.g. how to access a serial port device such as a towitoko smart card reader) or with usb (user space communication towards a usb reader, for example those implementing CCID or ICCD standard). so the implement a smart card reader is mostly user space, and the kernel only provides the generic transport mechanism from user space to the device on the other side of the cable. I would try to keep it that way. don't implement t=0 or t=1 in kernel etc. Yes, that's why I'm asking here. Defining an API for SmartCard interfaces in a way, to make life easy for people using these userland projects (or developing drivers for). I'd rather say: you have a device attached via a reduced version of a serial port.not a generic one (then you could use std. serial port driver and do everything in user space), but a somehow reduced one, and you need to hide that details. but if your hardware has extra features that don't map to a std. serial port, I don't know what to do. how do the driver for serial towotoko readers implement the same feature? maybe some special signaling - i.e. like catching some APDU commands and acting on them? no idea. with a pc you have your cpu and then a firmware in some microchip inside the reader, I guess. so that part would need to be in the kernel? not sure. better not use openct+pcsc-lite combo, it can work, but needs to be tested well. Then I'm a tester. My current test case is a small test program using PCSC to talk to a SmartCard via an ifdhandler from the OpenCT + my OpenCT driver + my kernel driver. At least my test case works. great! that is good news. if you have one of the cards supported by opensc completely, you could later run the regression tests in opensc source src/tests/regression directory. if they work fine, you know that pretty heavy communication works. Currently I should support SmartCard/SIM and its specific type of communication. For other interfaces (like I2C) other frameworks in the kernel do exist. yes. but I have no clue how to implement a generic interface. seems that in real world (e.g. windows), every vendor has a special proprietory library with their own extensions to handle memory cards too. What else must a generic API to the kernel handle, to control all features of SmartCards interfaces? Attached my current approach to define some IOCTLs to control the interface to the SmartCard. too much (please keep t=0 and t=1 in userspace in stead of kernel), and not enough (which frequencies does your hardware use with the card)? I think - read data - write data - warm reset - hard reset - get card status (card / no card / card removed and added again) - reader frequency What does reader frequency mean? The clock, the reader provides to the SmartCard? Or something different? yes. I don't know much about those low level details, but the real communication speed isn't only controlled by fi and di negotiated during PPS, but also by the clock frequency used by the reader. in datasheets I often see up to ..., but as poweruser I would like to know, what frequency the reader uses right now. I saw other readers are also able to lock the card. Also a useful case? lock? like if you have an ATM where some hardware based mechanism cuts the connection to the outside, so you can't insert a card with a cable connecting it to your laptop? sure, I guess some readers have that. but I guess the kernel has generic framework for strange features like that (e.g. input system that can map to arbitrary special keys/buttons on any device, and also work the other way, unless I'm mistaken), so maybe it is easier if you have two interfaces for that - one to control such hardware and one for the chip communication, than to have a complex one for both. not sure about that... Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Built-in SmartCard reader
Am Donnerstag 20 Mai 2010, um 09:47:19 schrieb Juergen Beisert: Hi Andreas, Andreas Jellinghaus wrote: Thinking about it for a few more minutes, I have a much better advice: implement a serial port. That was also an idea of Alax Cox. But this implies to emulate the whole reader in kernel land (the kernel driver must be the 'firmware' of this device). Than an application can work with this device like an externally connected one. But who wants such complex code in the kernel? why complex? with serial attached smart card readers, the complex parts like T=0 and T=1 are in user space. the kernel only receives the byte and puts it into the hw register that maps to the serial port chip. I don't know your hardware, but I guess it has some register to put a byte as serial signal on the wire too? (you see I have no clue about hw, only strange ideas how it might work...) Currently in my prototype I just use the standard IO functions like read() and write() to receive and send data from/to the SmartCard. Setting up communication parameter is done via special (=SmartCard related) IOCTLs (shown in the attached file in my first mail to this list). Should work in a way you suggest. looks like a good driver to me. sure, the kernel folks don't like new device types with more and more and more special ioctl()s, but I think it is the easiest way - little other option is available. and in-band signaling with special byte combinations written would be much much worse. Problem is, how to setup the SmartCard communication parameter via IOCTL? The currently implemented serial drivers changing these kind of parameters by sending special commands through the serial line to the reader's firmware (or its firmware does it by itself). They are only using IOCTLs to setup the serial line parameters between the host and the reader. To re-use it, I would need a command interpreter in the kernel driver to distinguish between commands to the firmware and to the SmartCard. Hmmm, I don't like this idea. I agree, a new custom ioctl() is much better. You should not need an interpreter inside the kernel, but rather expose the hw interface you have as good as possible to the userland. I have a working openct driver for my device (and the home brew API between userland and kernel). Should I send it to this list for discussion? sure, it is welcome! Regards, Andreas p.s. and of course I'm curious, if you are allowed to talk about it: what kind of device is it? where/when can I buy one? :) ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Feitian ePass+SCR301 problem
It would be great if the entersafe driver could be improved to the point, where src/test/regression/ test suite works with the cards. The test suite provides a very good way for us to test many different card features, and make sure new versions of opensc still work as good as old cards. I think entersafe is still missing some features we need to run the test suite. maybe it is possible to improve that? Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Built-in SmartCard reader
Am Mittwoch 19 Mai 2010, um 15:32:22 schrieb Juergen Beisert: I don't know if this is the correct list to ask this question. If not, please give me a pointer. muscle list has even more experts on writing drivers I guess, but opensc-devel should be fine, too. Other SmartCard interfaces are built into an external reader (mostly connected via USB or serial line). My SmartCard interface is built into a SoC processor running a regular Linux based system. I have written a small kernel driver to gain access to the hardware (the interface logic) and also a driver for openct to make userland happy. So, all software components (application, opensc, openct, driver, SmartCard interface, SmartCard) are running on the same system. Are there other people out there who are also using SmartCards in such a way? So, does it makes sense to support this kind of connection in openct and/or the kernel? hmm. I guess there are embedded people with similar projects. For example I read about people writing NFC stacks for Android mobile phones, I guess they will have similar situations. I asked on the kernel maillist and the most important thing is to define an API used between any userland application and the kernel driver to control the interface to the SmartCard (the communication itself is handled with simple read()/write()). write a minimal driver that can setup a char device, so you can read and write, and maybe supports some ioctl (e.g. to set speed / get speed etc.). but: I never did something like that, so this is pure theoretical thinking. and some sysfs stuff, so you can find the device (i.e. udev knows what to create and the minor/major number to use). ask on linux-kernel for some good driver that could be used as template. or there are some lists specialised on giving advice and reviews for writing new kernel driver. I would minimize the kernel driver, to export a simple and easy interface (e.g. read/write/speed/reset or so), and leave the rest to useland. for example T=0 and T=1 and related protocols should be done in userspace I think, as there is no need for kernel space. plus you don't need to implement those your self, as there are open source implementations available (openct, libccid, scez etc.). and for apps, it would be best to hook into pcsc-lite like ccid does (or extend openct with a new driver - not so difficult I think, but openct is quite limited compared to ccid+pcsc-lite). better not use openct+pcsc-lite combo, it can work, but needs to be tested well. (no one is using it, and no one is maintaining it or fixing it, if it is broken. but might be an option of last resort - getting it to work could be faster than writing something from scratch.) But I'm new to SmartCards and don't know yet, what's required in such an API to control all interface features to SmartCards (and my hardware is limited to only switch on/off and reset the card, changing to various communication parameter and running the communication itself). make sure you know exactly what cards you need to support. there are processor cards based on iso 7816-3 and 4 standard, but there are also old memory cards that fit the same physical interface, but have very different protocols (and there are many different protocols for that- two wire, three wire, many proprietory ones, i2c, ...). so first make sure what you need to support. sim cards are all iso 7816-3/4. What else must a generic API to the kernel handle, to control all features of SmartCards interfaces? Attached my current approach to define some IOCTLs to control the interface to the SmartCard. too much (please keep t=0 and t=1 in userspace in stead of kernel), and not enough (which frequencies does your hardware use with the card)? I think - read data - write data - warm reset - hard reset - get card status (card / no card / card removed and added again) - reader frequency - speed / pps should cover most you need. hmm, t=0 has parity bits and stuff maybe too? not sure, don't know t=0 well. maybe I mix that up with config for attaching serial readers. oh, add ejectif you have a physical way to eject a card. or sensors that tell you if a card is properly inserted, detected as fake, has a wire to outside of the atm preventing some gate to close behind the card and whatever. in any case I would start small and for every feature think hard: can it be done in user space? unless you have hard reasons why it can't, userspace is the best place for it. (and much more forgiving if your code has a bug...) hope this helps. btw: in your other mail your signature sais you are in munich? well, I don't drink, but we could mod advice for beer into some other fluid and have a chat someday if you want. good luck with your project! Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4359] pkcs11: by default do not lock login
Am Mittwoch 19 Mai 2010, um 10:38:16 schrieb Alon Bar-Lev: For a security product, I don't think it is wise to have default of none secure behavior, especially such that allows everyone to use the private objects once authenticated. I agree. and I think openssl engine_pkcs11 breaks if you disable lock_login. or was it the other way round? sorry, no time for testing, I forgot the details. but it should be in the email archive somewhere, and of course testing the new behaviour would be best. security products should be also easy to use, and maybe those two goals conflict. so I think it would be best to have some overview of arguments for each setting with hard facts (and how to test/reproduce those). Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Built-in SmartCard reader
Thinking about it for a few more minutes, I have a much better advice: implement a serial port. the reader-smart card interface is not that much different from a serial port I guess, so in kernel land you should be able to look at many existing drivers for serial ports, and implement a simple serial port driver with some special hacks for the smart card specific parts. and in user land: there are full drivers for serial port smart card readers, so you can simply re-use one of them and adapt it to the specifics of your serial port / reader. dumb mouse and towitoko are the most well known serial port readers I guess - the first was something you could build on your own, and the second was a very popular serial smart card reader (but there were also ps2 and later also usb editions of it, so code you find could be more complex that what you are looking for). openct has code for serial towitoko readers for example, but many more projects wrote driver for those, scez for example I think, and maybe there is an ifdhandler for serial towotoko readers too somewhere? good luck! Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Rainbow ikey 3000
Am Mittwoch 28 April 2010 17:31:27 schrieb Jim Rees: The Rainbow ikey seems to have been discontinued in 2007. I thought it was never realy sold - only a few examples made it to the distributors? CyProtect recommends AET IDp 1000 Token, which is JCOP41, as a replacement. Will this work with OpenSC? Can someone update the wiki? well, I guess it works as good or bad as every jcop card - you need to load some applet (e.g. muscle applet) and that applet can work with opensc. see cyberflex cards - they are all jcop, so it is all the same to opensc. but muscle applet and driver are quite restricted compared to the full drivers in opensc (e.g. cardos, cryptoflex). not sure what the details are, but installation is much harder as you need a gp tool first, and you can't run all commands - and of course not the full test suite. also only one pin and only some profiles are supported etc. :( Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [OpenSC] #120: pkcs15-init needs to accept ctrl-c
Am Sonntag 25 April 2010 20:56:44 schrieb Ludovic Rousseau: And on Mac OS X Snow Leopard I do not have getline(). Maybe a correct solution is to test for the presence of getline in configure.ac and use #ifdef HAVE_GETLINE #else /* Windows and Mac OS X */ #endif ah. windows is not an issue, the only code using getline() already is inside a #ifndef _WIN32 block. maybe the code for windows can be used on mac os X too? Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4266] tools: thanks to Ludovic; check for getline() in configure.ac and use 'HAVE_GETLINE' macro in get password procedure.
Am Montag 26 April 2010 14:29:43 schrieb webmas...@opensc-project.org: Revision: 4266 Author: viktor.tarasov Date: 2010-04-26 12:29:42 + (Mon, 26 Apr 2010) ... - buf[i] = _getch(); + /* buf[i] = _getch(); */ + buf[i] = getchar(); _getch() gets a character from stdin *without echo*. in getchar() manpage I don't see any reference to suppressing echo. so for windows it would be best to stick with _getch(). Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4264] Support for CardOS 4.4
Am Mittwoch 21 April 2010 16:38:24 schrieb webmas...@opensc-project.org: Revision: 4264 Author: jps Date: 2010-04-21 14:38:23 + (Wed, 21 Apr 2010) wow, great! chears for jps! does anyone know a source where I can buy a cardos 4.4 card? :) also: once the startkey is changed from 00 (secret manufacturing startkey) to ff (with 16 bytes ff, not that strange new other ff key they seem to have): does the card work perfectly with opensc like older generations do? Thanks for your help! Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] wget and pkcs11?
Am Mittwoch 21 April 2010 21:01:51 schrieb Jim Rees: I'm in need of a command line utility that can do https fetches given a url, like wget, but use pkcs11 for the crypto ops, so I can store the client cert/key on a smart card. Firefox will do this but it's overkill and I need something scriptable. Any suggestions? there was a python discussion a few weeks ago, with example code posted. it was for a https connection, but I guess this is enough to get you started. I'm not aware of any usual tool supporting smart cards / pkcs11 (i.e. wget or curl or GET or similar - no support as far as I know). Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Sub-project for OpenSC with secure messaging and multi-applications
I think it is a great idea to implement these things! forking a project is easy (every cp -r ... is a fork from my point of view), but merging can be hard, depending on the tools you use. thus my advice: a) stay in opensc svn, but simply do svn cp https:///svn/opensc/trunk \ https:///svn/opensc/branches/some-name and then from time to time merge the changes that happend in the mean time in trunk into your branch, until your branch is ready to be merged back into trunk. with old subversion you would need to keep manual notes of the revision where you copy svn trunk to your branch, and then everytime you merge trunk you more or less tell svn to diff from that revision to the current trunk revision, and apply that patch on top of your current branch. then you need to write down the new current revision of trunk used in this merge as reference for the next merge. newer subversion should be much improved over this note-keeping process, but I haven't worked with it so far. b) use git/hg/bazar with svn bridge to import current opensc repository and all future changes to it, and develop in git/hg/bazaar. you can publish your codebase on one of the popular hosts (github, launchpad, the mercurial hub whose name I don't remember right now), or on opensc-projects.org (I guess, pending martins approval) - only a small admin work needed to add some ssh account for you with write access in /var/www/some-name Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Middleware-free USB PKI Tokens?
Am Mittwoch 21 April 2010 08:34:29 schrieb Peter Stuge: Again, what part of the PC system would be authenticated by the token? Basically; what purpose does the authentication serve for the token? for example I would like to put my openssh known_hosts on a smart phone, so it is current with all machines I use. for read access to the desktop: it would be ok for me to publish it to a *well known* desktop without asking me. but to a strange desktop: please don't do that (for privacy reasons). Or for the PC, for that matter? talk whatever protocol you want over that, for example to request some signature from other keys (one that needs the user to enter the pin e.g.), push pdf's for signing or whatever. Is there a point in pushing a PDF if it can't be verified by the user on the token? well, if the token is a smart phone, it can display the pdf and show it to me, before I agree to sign it. thats my whole point: smart cards/ usb crypto tokens, even with pinpad readers, have this problem of not being able to display a pdf before I sign it. a simple nice personal, trusted device with a real screen and input system and security system build in could do that on the other hand. wait! I already have something like that, my mobile phone ... so that is my way to think about this. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
