Re: [opensc-devel] Personal Review Of The Upcoming 0.12.0 Release
Hello,
Martin Paljak wrote:
> On Sep 1, 2010, at 9:41 AM, Aleksey Samsonov wrote:
>> "Rutoken S" [1] doesn't support on-board RSA (as opposed to "Rutoken ECP").
>> "Rutoken ECP" [2] have on-board RSA (with RSA keys up to 2048 bits), GOST R
>> 34.10-2001 (public-key cryptography), GOST 34.11-94 (hash) and GOST 28147-89
>> (symmetric-key algorithm).
>> The file card-rutoken.c provides support "Rutoken S". And this code worked
>> on "old scheme OpenSC". Already now ("new scheme") all old functionality
>> aren't working at "Rutoken S". Example: software key generation was removed
>> [3].
> Right. Software RSA support for Rutoken S should then be removed.
I'm going to cleanup code.
> OpenSC should be a gateway to key operations in hardware.
>
> Maybe, just maybe, it would make sense to support "data objects over PKCS#11"
> for using smart cards like small secure flash drives (like TrueCrypt wants to
> use PKCS#11) but key material should never be automagically extracted into
> host memory and the user of OpenSC (PKCS#11) left the impression that key
> operations are taking place inside the token, when in fact they are not.
I think, support data objects make sense. I will make cleanup Rutoken S
code.
Thanks
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] MyEID microSD
On Thu, 2010-09-02 at 15:44 +0200, Andre Zepezauer wrote: > it's hard to imagine that the demand of these devices is still so > limited, because they fit nicely into every laptop/netbook with SD > card > slot. A lot better than every usb key or smart card. The format of crypto devices, whether it be smartcard, USB token or SD card is secondary. IMHO, the relatively low demand for hardware encryption devices is the result of history: When smartcards were invented, patents did a lot of harm to the technology, driving cost up and technology down. During years, the market was only banks and large companies. In the past years, the ability to store keys pairs in so-called secure software stores, like Iceweasel or Internet Explorer, is offering a low-cost solution to the end-users. In marketing, the bad product kills the good one. The solution for selling encryption devices is not hardware, we already have very good hardware around. The solution is software and integration in the key management systems of OSes: Seahorse, Gnome-Keyring, Network Managers, Apple Keychain. We should make GUIs to manage smartcards and have better integration. -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Opensc and SetCOS.
Patrik Martinsson wrote: > We actually need to buy pcmcia/expresscard-readers for all our > Linux users to get their laptops working. Make sure to go for ExpressCard. PCMCIA chips are on par with PCI chips, there are no docs and also no good API. Buy a few different ExpressCard readers and test. ExpressCard is bog standard PCI-Express x1 and USB 2.0. PCIe bandwidth isn't needed for a smart card reader, so ExpressCard readers should be CCID USB devices. As was mentioned, those are good/the best readers for open source systems. http://www.dustin.se/pd_5010134353.aspx http://www.dustin.se/pd_5010373434.aspx Sadly not in stock at Dustin. You could also try ordering from Gemalto: http://boutique.gemalto.com/boutique/GEMALTO-B2CCORP-Site/-/Pc-Express-Reader/pdu-WFS-en_US-EUR-wrAKAwOEefEizsko8Cyo-PqMKAwOE0S8AAAElGeseUAux;pgid=mvVSSnc0o4FSR0IaStIrwgc4sVsxXoue;sid=7n-X4f3aWmd08LFa5zLM4_7QFv5sbsBbN2yqYCTJ0_5O8g==?JumpTo=OfferList&ParcoursTracking=.Cat.2CATALOGBIS Gemalto mentions says this is "USB Microsoft CCID" (sheesh, as if Microsoft would be significant there) and the Omnikey one is supposed to support Linux, according to Dustin. I bet they're both standard CCID readers. > Even though that may be a relative small cost, it's a stupid an > unnecessary cost in my opinion. Completely agreed. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Smart Cards vs "Really Dumb Tokens"
Hi, I don't know how many of you who are aware of Information Cards but they have been pushed for 5 years by Microsoft with virtually no results. IMO it is because Microsoft have (like most other US companies) essentially no experience with tokens for consumers since US on-line banks /primarily/ use passwords. -- Since there seems to be misunderstandings in the Information Card community about the state of smart cards, I take the liberty describing what I believe are facts. Feel free providing other information :-) In order to use a card it must be initialized. If you take a card and insert it in a leading platform such as Windows 7, you will soon be aware that there is no initialization or "format" command to find. If you are the nerdy type you will also note that cryptographic APIs like featured in Windows, Java, and as well as PKCS #11 do not have support for card initialization. This is because this part is largely proprietary/non-standard. Due to this we will never be able to put Information Cards on smart cards except maybe for a single model that is likely to be both pricey and hard to get. What's even more funny is that after performing this highly proprietary initialization process, cards when used for logging in to AD or to an Internet site, only execute mundane cryptographic operations like RSA sign. I.e. all this advanced technology like Java, or .NET seems virtually useless; at least the diversity is completely unmotivated. So what's the solution? IMHO, it is defining a container that is a "Dumb Keystore" rather than the "Server" the card industry is peddling to keep them from becoming commodity suppliers. Unlike a server, a dumb keystore is just a simple peripheral responding to /a small set of predefined commands/, quite similar to a disk drive. Although you (most certainly) do not agree, I'm pretty sure that Information Cards, U-Prove, and a gazillion of other niceties won't go anywhere until a better token becomes */readily available/*. The better tokens are enhanced USB memory sticks and mobile phones. Traditional smart cards are simply unsuited for large scale use in consumer PCs (where is the reader to begin with...) except for those who can afford the luxury of having a "smart card expert" hanging around. There are other markets and uses like passports that need customizable cards with file-systems and such but this has rather little to do with "logging in" on the Internet. Regards, Anders Designer of "Really Dumb Tokens" that unlike the state-of-the-cards, can be provisioned directly over the Internet with full end-2-end security, using enhanced Internet browsers. http://webpki.org/auth-token-4-the-cloud.html ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Logical Channels
On Thu, 2010-09-02 at 21:31 +0300, Martin Paljak wrote: > Hello, > > On Sep 2, 2010, at 9:16 PM, Andre Zepezauer wrote: > > But as an inspiration for the future, this problem can be solved throughout > > exploiting logical channels. > Which problem? How? 1. If only one application authenticates successfully, then the token becomes unlocked and will be accessible without authentication for all the other applications _and_ users too. 2. Application A authenticates successfully. Later application B fails to authenticate. Now application A is unauthenticated too. Not sure if mozilla will ask for a pin again. My assumption is, it won't. 3. Left as an exercise for the interested reader. > However, logical channels may share application-dependent security status and > therefore may have security-related command interdependencies across logical > channels (e.g. password verification). Source iso7816-4 Draft: After a successful open function performed from 1) the basic logical channel (bits 6, 2 and 1 all set to zero in CLA, coding number zero), the MF shall be implicitly selected as the current DF and the security status for the new logical channel should be the same as for the basic logical channel after the answer to reset. The security status of the new logical channel should be separate from that of any other logical channel. 2) a non-basic logical channel (bits 6, 2 and 1 not all set to zero in CLA, coding a number from one to seven), the current DF of the logical channel from which the command was issued shall be selected as the current DF and the security status for the new logical channel should be the same as for the logical channel from which the open function was performed. > Do you have a specific card in mind? Every modern Java card and in particular GlobalPlatform is capable of doing so, if the applet implements javacard.framework.MultiSelectable. > Do you have a patch No. > or a plan on how to apply the concept to OpenSC? Not in detail. But if someone will begin a serious discussion on it, then I will participate. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Logical Channels
Hello, On Sep 2, 2010, at 9:16 PM, Andre Zepezauer wrote: > But as an inspiration for the future, this problem can be solved throughout > exploiting logical channels. Which problem? How? """ However, logical channels may share application-dependent security status and therefore may have security-related command interdependencies across logical channels (e.g. password verification). """ (source [1]) Do you have a specific card in mind? Do you have a patch or a plan on how to apply the concept to OpenSC? Bye, [1] http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_5_basic_organizations.aspx#chap5_5 -- Martin Paljak @martinpaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Logical Channels
Hello, first of all, I'm not interested in starting the discussion on insecure default setting over again. The decision seems to be clear. But as an inspiration for the future, this problem can be solved throughout exploiting logical channels. Regards Andre ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Personal Review Of The Upcoming 0.12.0 Release
On Wed, 2010-09-01 at 04:55 +0400, Aleksey Samsonov wrote:
> Hello,
>
> Martin Paljak wrote:
> >> 2. The announcement of the GOST public key algorithm seems to me very
> >> optimistic. Because the current implementation isn't functional at all
> >> [1][2].
> > Good catch.
>
> The GOST public key algorithm is working (the current implementation),
> but in [1] [2] by a lucky chance. We need to fix logic in this case.
Sorry when causing trouble. But Aleksey is right. The implementation of
pkcs15-sec doesn't hinder the GOST algorithm to work. That's strange.
@Aleksey: Have you personalised a lot of tokens yet? There's a problem
with the chosen tag for the GOSTPrivateKey. Tag A3 is still allocated by
pkcs15 and is used for KEA.
> See
> http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/card-rtecp.c#L60
>
> >> [1]http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/pkcs15-sec.c#L86
> >> [2]http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/card.c#L725
>
> Trace example:
>
> Breakpoint 1, _sc_card_find_rsa_alg (card=0x8e2530, key_length=256) at
> card.c:730
> 730 for (i = 0; i < card->algorithm_count; i++) {
>
> (gdb) bt
>
> #0 _sc_card_find_rsa_alg (card=0x8e2530, key_length=256) at card.c:730
>
> #1 0x7fce3a329369 in sc_pkcs15_compute_signature (p15card=0x8e2b00,
> obj=0x8eaff0,
> flags=, in=, inlen=32,
> out=, outlen=64)
> at pkcs15-sec.c:175
>
> #2 0x0041118d in pkcs15_prkey_sign (ses=0x8ee2c0, obj= optimized out>,
> pMechanism=, pData=,
> ulDataLen=32,
> pSignature=, pulDataLen=0x7128e8) at
> framework-pkcs15.c:2401
> #3 0x0040ca98 in sc_pkcs11_signature_final (operation=0x8ee230,
> pSignature=0x712860 "",
> pulSignatureLen=0x7128e8) at mechanism.c:425
>
> #4 0x0040d546 in sc_pkcs11_sign_final (session=0x8ee2c0,
> pSignature=0x712860 "",
> pulSignatureLen=0x7128e8) at mechanism.c:307
>
> #5 0x0040a82c in C_Sign (hSession=9364160, pData=0x708de0
> "1234567890123456789012345678901",
> ulDataLen=32, pSignature=0x712860 "", pulSignatureLen=0x7128e8) at
> pkcs11-object.c:591
> #6 0x004079b5 in main ()
>
> (gdb) finish
>
> Run till exit from #0 _sc_card_find_rsa_alg (card=0x8e2530,
> key_length=256) at card.c:730
> sc_pkcs15_compute_signature (p15card=0x8e2b00, obj=0x8eaff0,
> flags=,
> in=, inlen=32, out=,
> outlen=64) at pkcs15-sec.c:176
> 176 if (alg_info == NULL) {
>
> Value returned is $1 = (sc_algorithm_info_t *) 0x8e27c0
>
> (gdb) p/x *$1
>
> $3 = {algorithm = 0x0, key_length = 0x100, flags = 0x8011, u = {_rsa
> = {exponent = 0x0}}}
> (gdb) n
>
> 175 alg_info = _sc_card_find_rsa_alg(p15card->card,
> prkey->modulus_length);
> (gdb)
>
> 176 if (alg_info == NULL) {
>
> (gdb)
>
> 160 size_t modlen = prkey->modulus_length / 8;
>
> (gdb)
>
> 183 if (inlen > sizeof(buf) || outlen < modlen)
>
> (gdb)
>
> 185 memcpy(buf, in, inlen);
>
> (gdb)
>
> 180 senv.algorithm = SC_ALGORITHM_RSA;
>
> (gdb)
>
> 185 memcpy(buf, in, inlen);
>
> (gdb)
>
> 195 if ((alg_info->flags & SC_ALGORITHM_NEED_USAGE) &&
>
> (gdb)
>
> 223 if ((flags == (SC_ALGORITHM_RSA_PAD_PKCS1 |
> SC_ALGORITHM_RSA_HASH_NONE)) &&
> (gdb)
>
> 237 r = sc_get_encoding_flags(ctx, flags, alg_info->flags,
> &pad_flags, &sec_flags);
> (gdb)
>
> 238 if (r != SC_SUCCESS) {
>
> (gdb)
>
> 245 if (pad_flags != 0) {
>
> (gdb)
>
> 242 senv.algorithm_flags = sec_flags;
>
> (gdb)
>
> 245 if (pad_flags != 0) {
>
> (gdb)
>
> 242 senv.algorithm_flags = sec_flags;
>
> (gdb)
>
> 245 if (pad_flags != 0) {
>
> (gdb)
>
> 250 } else if ((flags & SC_ALGORITHM_RSA_PADS) ==
> SC_ALGORITHM_RSA_PAD_NONE) {
> (gdb)
>
> 252 if (inlen < modlen) {
>
> (gdb)
>
> 260 senv.operation = SC_SEC_OPERATION_SIGN;
>
> (gdb)
>
> 261 senv.flags = 0;
>
> (gdb)
>
> 263 if (prkey->key_reference >= 0) {
>
> (gdb)
>
> 264 senv.key_ref_len = 1;
>
> (gdb)
>
> 265 senv.key_ref[0] = prkey->key_reference & 0xFF;
>
> (gdb)
>
> 266 senv.flags |= SC_SEC_ENV_KEY_REF_PRESENT;
>
> (gdb)
>
> 268 senv.flags |= SC_SEC_ENV_ALG_PRESENT;
>
> (gdb)
>
> 270 r = sc_lock(p15card->card);
>
> (gdb)
>
> 271 SC_TEST_RET(ctx, SC_LOG_DEBUG_NORMAL, r, "sc_lock()
> failed");
> (gdb)
>
> 270 r = sc_lock(p15card->card);
>
> (gdb)
>
> 271 SC_TEST_RET(ctx, SC_LOG_DEBUG_NORMAL, r, "sc_lock()
> failed");
> (gdb)
>
> 273 if (prkey->path.len != 0) {
>
> (gdb)
>
> 274 r = select_key_file(p15card, prkey, &senv);
>
> (gdb)
>
Re: [opensc-devel] Personal Review Of The Upcoming 0.12.0 Release
On Wed, 2010-09-01 at 10:41 +0400, Aleksey Samsonov wrote:
> Hello,
>
> Martin Paljak wrote:
> > On Aug 30, 2010, at 2:52 PM, Emanuele Pucciarelli wrote:
> >>> The handful of drivers with insecure operations I was talking about, I
> >>> got with the following command: grep -n OPENSSL libopensc/card-*.c
> >>>
> >>> But looking closer to each drivers source, I must confess that there are
> >>> only two of them affected:
> >>>
> >>> http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/card-westcos.c#L1244
> >>> http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/card-rutoken.c#L1376
> >> Looking at card-westcos.c:1117, I'd say that the "insecure mode" is
> >> only used with cards that do not have on-board RSA capabilities, but
> >> do have a private exportable key. In other words, it should only be a
> >> fallback.
> > There used to be built in signaling for such scenarios, together with
> > SC_ERROR_EXTRACTABLE_KEY return key that was not handled/implemented by the
> > generic libopensc. That was not used and is removed since r4645 [1]
> >
> > Cards that don't support native RSA keys (meaning keys that can not be used
> > for on-board operations) should be unsupported by default by OpenSC.
> > Support for native but extractable keys is a whole different story. I doubt
> > there are any modern smart cards that don't support native RSA these days.
> > At least there is no reason to fake the support in OpenSC.
>
>
> "Rutoken S" is a very old devices (see [1]). They don't support on-board
> RSA, They have only on-board GOST 28147-89 cryptographic functions (GOST
> 28147-89 is a symmetric-key algorithm).
>
>
> >> On the other hand, it really seems that RSA is only done in software
> >> with card-rutoken.c. Perhaps that device does not support RSA in
> >> hardware at all?
> >
> > I suggest to remove the offending code and pay closer attention in the
> > future to avoid such code. Will write it to the wiki as well. Apparently we
> > need to clarify the capabilities of Rutoken (and different versions of it)
> > regarding their RSA support *and* GOST support.
>
> "Rutoken S" [1] doesn't support on-board RSA (as opposed to "Rutoken
> ECP"). "Rutoken ECP" [2] have on-board RSA (with RSA keys up to 2048
> bits), GOST R 34.10-2001 (public-key cryptography), GOST 34.11-94 (hash)
> and GOST 28147-89 (symmetric-key algorithm).
> The file card-rutoken.c provides support "Rutoken S". And this code
> worked on "old scheme OpenSC". Already now ("new scheme") all old
> functionality aren't working at "Rutoken S". Example: software key
> generation was removed [3].
>
> Thanks
Hello Aleksey,
I really hope that it isn't a huge disaster for your personal life, when
support for "Rutoken S" will be dropped in the near future. The rational
behind this decision may be the fact, that such a kind of device is
technology from the past. If we were in the 80's then this would be
state of the art. But today, everyone concerned in security should use
more capable devices.
Kind Regards
Andre
> [1] http://www.opensc-project.org/opensc/wiki/AktivRutokenS
> [2] http://www.opensc-project.org/opensc/wiki/AktivRutokenECP
> [3] http://www.opensc-project.org/opensc/changeset/4646
>
> ___
> 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] OT: desktop crypto implementation
Hello, On Sep 2, 2010, at 7:47 PM, Andre Zepezauer wrote: > On Thu, 2010-09-02 at 19:00 +0300, Martin Paljak wrote: >> Business continuity, including proper key management and PKI, is hard :) > > How can the best "plan for key management" help, if for example a laptop > breaks on an international business trip _and_ the keys were stored on a > TPM? The same way if you lose/break your smartcard/sd card/whatever. If there are established (and tested) procedures for working around such situations. Key management [1] is more a procedure issue than technology issue. It is very little about smartcard vs usb token vs sd card vs tpm vs XXX. > With keys on a removable device (SD card for example) "business > continuity" would be guarantied as long the affected person is able to > get a replacement device. Yeah, without a mini SIM envelope, micro-SIM phone owner would also be OK. as long as he would have another micro-SIM phone to take from somewhere... Most (more than 9/10) GSM phones have mini SIM cards slots. > Martin have you realised, that we haven't discovered any single > disadvantage of SD smart cards so far? You already did find one yourself: On Sep 2, 2010, at 4:44 PM, Andre Zepezauer wrote: > it's hard to imagine that the demand of these devices is still so > limited, because they fit nicely into every laptop/netbook with SD card > slot. A lot better than every usb key or smart card. With the > availability of an ifd-handler and support form opensc it would be an > easy to use plug and play solution. The whole host side software is > already in place with the exception of the idf-handler. That's sad. Bye, [1] http://en.wikipedia.org/wiki/Key_management -- Martin Paljak @martinpaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OT: desktop crypto implementation
On Thu, 2010-09-02 at 19:00 +0300, Martin Paljak wrote: > On Sep 2, 2010, at 6:37 PM, Andre Zepezauer wrote: > > And when this portable brakes, can I use the TPM (with keys on it) in a > > replacement part? > > The situation is no different if your SD card breaks. > Or the TPM chip on the motherboard breaks - you do not get your keys, nor is > it easily replaceable. > > From good key management perspective, the MTBF of your portable might be > longer than a paranoid re-keying period. > > (People use crypto are usually a bit paranoid so you should care about > re-keying. Companies use crypto if they have assets to protect and money to > lose. Unlike people at home, companies usually have procedures and plans for > key management, something that home users usually ignore) > > Business continuity, including proper key management and PKI, is hard :) How can the best "plan for key management" help, if for example a laptop breaks on an international business trip _and_ the keys were stored on a TPM? With keys on a removable device (SD card for example) "business continuity" would be guarantied as long the affected person is able to get a replacement device. Martin have you realised, that we haven't discovered any single disadvantage of SD smart cards so far? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] OT: desktop crypto implementation
On Sep 2, 2010, at 6:37 PM, Andre Zepezauer wrote: > And when this portable brakes, can I use the TPM (with keys on it) in a > replacement part? The situation is no different if your SD card breaks. Or the TPM chip on the motherboard breaks - you do not get your keys, nor is it easily replaceable. >From good key management perspective, the MTBF of your portable might be >longer than a paranoid re-keying period. (People use crypto are usually a bit paranoid so you should care about re-keying. Companies use crypto if they have assets to protect and money to lose. Unlike people at home, companies usually have procedures and plans for key management, something that home users usually ignore) Business continuity, including proper key management and PKI, is hard :) -- Martin Paljak @martinpaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] MyEID microSD
On Thu, 2010-09-02 at 18:20 +0300, Martin Paljak wrote: > Helo, > On Sep 2, 2010, at 6:01 PM, Andre Zepezauer wrote: > > On Thu, 2010-09-02 at 17:05 +0300, Martin Paljak wrote: > >> I believe the reason why smart cards exist is their common, agreed upon > >> form factor and the existence of related infrastructure pieces. Like > >> pinpad smart card readers. > > > > Pinpad readers (like all external readers) are good for desktop and > > office PCs. In the netbook market they will never become the equipment > > of choice. Furthermore there are so many people don't having a desktop > > PC but something portable. Even if there portables never leave there > > desk. For those people (including me) smarter solutions would be more > > appealing than the "[age old] infrastructure pieces". > Some of those people (like me) have a pinpad reader on office dest and a > pinpad reader at home for doing some operations with some cards (like > changing the PIN when I feel like i have to). And a portable reader for the > time on the road. > > But as you say below, we probably need (and talk about) totally different > things. > > Yes, there are other "smarter" solutions, both technology and business-wise. > One of them was Mr. Jobs with the micro SIM move, who created a whole new > niche market of micro SIM cutters and mini SIM micro SIM envelopes. > > Of course there remains the argument, that how often do you need to take a > SIM out from the phone and put it somewhere else... But I could understand > the grief of someone who broke his phone and would like to take some other > phone as a replacement and use the same SIM card.. darn! > > > > >> For permanent built-in crypto operations, the TPM chip should be the most > >> hip thing currently (at least it was for a while, I don't know the exact > >> status of TPM deployment on desktop machines). > > > > That's exactly what I want: "permanent built-in crypto". If not soldered > > on the board, then with good integration at least. > Then buy your next portable with a TPM and check out > http://trousers.sourceforge.net/ And when this portable brakes, can I use the TPM (with keys on it) in a replacement part? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] multiple threads?
2010/9/2 Pierre Ossman : > I noticed this documentation added in r4583: > > * Each thread of an application shall use its own SCARDCONTEXT. On > * Windows the same SCARDCONTEXT can be shared by different threads > * of same application. > > This seems overly harsh. For instance, this would mean that > SCardCancel() is a no-op as it is impossible to call it from the > same thread that's currently calling another (blocking) operation. SCardCancel() is the only exception to the rule. I fixed the Doxygen documentation in revision 5227 of pcsc-lite. I will update the online documentation [1] soon. Thanks for the request. [1] http://pcsclite.alioth.debian.org/api/group__API.html -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] MyEID microSD
Helo, On Sep 2, 2010, at 6:01 PM, Andre Zepezauer wrote: > On Thu, 2010-09-02 at 17:05 +0300, Martin Paljak wrote: >> I believe the reason why smart cards exist is their common, agreed upon form >> factor and the existence of related infrastructure pieces. Like pinpad smart >> card readers. > > Pinpad readers (like all external readers) are good for desktop and > office PCs. In the netbook market they will never become the equipment > of choice. Furthermore there are so many people don't having a desktop > PC but something portable. Even if there portables never leave there > desk. For those people (including me) smarter solutions would be more > appealing than the "[age old] infrastructure pieces". Some of those people (like me) have a pinpad reader on office dest and a pinpad reader at home for doing some operations with some cards (like changing the PIN when I feel like i have to). And a portable reader for the time on the road. But as you say below, we probably need (and talk about) totally different things. Yes, there are other "smarter" solutions, both technology and business-wise. One of them was Mr. Jobs with the micro SIM move, who created a whole new niche market of micro SIM cutters and mini SIM micro SIM envelopes. Of course there remains the argument, that how often do you need to take a SIM out from the phone and put it somewhere else... But I could understand the grief of someone who broke his phone and would like to take some other phone as a replacement and use the same SIM card.. darn! >> For permanent built-in crypto operations, the TPM chip should be the most >> hip thing currently (at least it was for a while, I don't know the exact >> status of TPM deployment on desktop machines). > > That's exactly what I want: "permanent built-in crypto". If not soldered > on the board, then with good integration at least. Then buy your next portable with a TPM and check out http://trousers.sourceforge.net/ -- Martin Paljak @martinpaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] MyEID microSD
On Thu, 2010-09-02 at 17:05 +0300, Martin Paljak wrote: > Hello, > > On Sep 2, 2010, at 4:44 PM, Andre Zepezauer wrote: > > it's hard to imagine that the demand of these devices is still so > > limited, because they fit nicely into every laptop/netbook with SD card > > slot. A lot better than every usb key or smart card. With the > > availability of an ifd-handler and support form opensc it would be an > > easy to use plug and play solution. The whole host side software is > > already in place with the exception of the idf-handler. That's sad. > > I believe the reason why smart cards exist is their common, agreed upon form > factor and the existence of related infrastructure pieces. Like pinpad smart > card readers. Pinpad readers (like all external readers) are good for desktop and office PCs. In the netbook market they will never become the equipment of choice. Furthermore there are so many people don't having a desktop PC but something portable. Even if there portables never leave there desk. For those people (including me) smarter solutions would be more appealing than the "[age old] infrastructure pieces". > For permanent built-in crypto operations, the TPM chip should be the most hip > thing currently (at least it was for a while, I don't know the exact status > of TPM deployment on desktop machines). That's exactly what I want: "permanent built-in crypto". If not soldered on the board, then with good integration at least. > For pluggable devices, USB is still more relevant than SD. My laptop does not > have a SD card slot but I don't know a laptop without USB. > > I think one of the main driving forces of (micro)SD based crypto tokens is > the smartphone market [1]. Even though smartphones already contain a smart > card (SIM) it is very hard/almost impossible to deploy SIM cards with crypto > capabilities on larger scale because of the greedy ignorant bastard named > "mobile operator". > > [1] http://code.google.com/p/seek-for-android/ ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] OpenSC C_FindObjectsInit has artificial limit of 32 objects
While testing some new modifications to the PIV driver,
I ran across a problem with pkcs11-tool -O listing only 32
objects. This appears to be an artificial limit
imposed by: #define SC_PKCS11_FIND_MAX_HANDLES 32
The simple fix (see attached patch) is to change the
limit to 256
A better solution would be to realloc the
sc_pkcs11_find_operation structure if its at its limit.
(I could look at doing this...)
The NIST 800-73-3 allows for up to 20 additional certificate
objects and matching private keys on a card above the 4 pairs
already present, and 9 additional objects as well.
To present these via PKCS#11, each certificate object is
presented as a data object, an extracted/unziped certificate,
a public key, and a matching private key. Thus pkcs11-tool -O
could list up to 24*4 + 9 = 105 objects.
(Current cards have 4 certificate objects and matching keys
and 6 other objects: 4*4 + 6 = 21 objects max.)
--
Douglas E. Engert
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
--- ,sc-pkcs11.h Mon Aug 23 19:13:21 2010
+++ sc-pkcs11.h Thu Sep 2 09:05:59 2010
@@ -280,7 +280,7 @@
};
/* Find Operation */
-#define SC_PKCS11_FIND_MAX_HANDLES 32
+#define SC_PKCS11_FIND_MAX_HANDLES 256
struct sc_pkcs11_find_operation {
struct sc_pkcs11_operation operation;
int num_handles, current_handle;
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] MyEID microSD
Hello, On Sep 2, 2010, at 4:44 PM, Andre Zepezauer wrote: > it's hard to imagine that the demand of these devices is still so > limited, because they fit nicely into every laptop/netbook with SD card > slot. A lot better than every usb key or smart card. With the > availability of an ifd-handler and support form opensc it would be an > easy to use plug and play solution. The whole host side software is > already in place with the exception of the idf-handler. That's sad. I believe the reason why smart cards exist is their common, agreed upon form factor and the existence of related infrastructure pieces. Like pinpad smart card readers. For permanent built-in crypto operations, the TPM chip should be the most hip thing currently (at least it was for a while, I don't know the exact status of TPM deployment on desktop machines). For pluggable devices, USB is still more relevant than SD. My laptop does not have a SD card slot but I don't know a laptop without USB. I think one of the main driving forces of (micro)SD based crypto tokens is the smartphone market [1]. Even though smartphones already contain a smart card (SIM) it is very hard/almost impossible to deploy SIM cards with crypto capabilities on larger scale because of the greedy ignorant bastard named "mobile operator". [1] http://code.google.com/p/seek-for-android/ -- Martin Paljak @martinpaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] MyEID microSD
On Thu, 2010-09-02 at 13:34 +0300, Aventra development wrote: > Hello Andre, > > Yes we can provide you with microSD cards that have our MyEID applet on > them. Currently you also need a SDK to be able to integrate the card to your > application. > > Currently there is no linux ifd-handler available. To be able to communicate > with the card, you need a library that is only available in the card > manufacturers SDK. The card supports common PKI standards, just like the > standard MyEID card. > > While the demand for these kind of microSD cards is very limited, the > purchase of a SDK and implementing the software you want is currently > the > only approach we can offer you. The SDK's library is supported on Windows, > Windows Mobile, Android, Symbian and Linux. Hello Toni, it's hard to imagine that the demand of these devices is still so limited, because they fit nicely into every laptop/netbook with SD card slot. A lot better than every usb key or smart card. With the availability of an ifd-handler and support form opensc it would be an easy to use plug and play solution. The whole host side software is already in place with the exception of the idf-handler. That's sad. I would really like to replace my usb key with a SD card. I keep waiting, until someone provides an easy to deploy solution. Development of custom applications (when got this right) isn't an option to me. Kind Regards Andre > > Best Regards, > Toni > > > > -Original Message- > > From: Andre Zepezauer [mailto:andre.zepeza...@student.uni-halle.de] > > Sent: 1. syyskuuta 2010 21:51 > > To: Aventra development > > Cc: opensc-devel > > Subject: MyEID microSD > > > > Hello Toni, > > > > by visiting the webshop of Aventra I have noticed, that there is a smart > > card in microSD format in there portfolio. I have been looking for such > > a device for a while, but haven't found a supplier so far. Are you able > > to provide some more information on it. Most important to me is the > > existence of an ifd-handler for Linux. > > > > Kind Regards > > Andre > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Call for testing of the upcoming 0.12.0 release
On Thu, 2010-09-02 at 12:21 +0200, Johannes Becker wrote: > Hello, > > unfortunately I have to repeat my message about the TCOS2 card: > > > When using opensc-0.12.0-svn-r4647 with our Uni Giessen Card (TCOS 2), > firefox presents the certificate to use without asking the PIN. I'm not absolutely sure but I think, that mozilla (firefox included) asks for a pin, only when the following expression evaluates to true: (pkcs11_token_info.flags & CKF_LOGIN_REQUIRED) == CKF_LOGIN_REQUIRED Check the presents of this flag with pkcs11-tool: $pkcs11-tool -L token flags: rng, login required, PIN initialized, token initialized ^^ > Subsequently the web page called can't be displayed. > > On the other hand CardOS 4.3 works with that release. > There were no problems with opensc 0.11 and TCOS 2. > > I tested on Debian squeeze. > > > Johannes > > > ___ > 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] multiple threads?
I noticed this documentation added in r4583: *Each thread of an application shall use its own SCARDCONTEXT. On *Windows the same SCARDCONTEXT can be shared by different threads * of same application. This seems overly harsh. For instance, this would mean that SCardCancel() is a no-op as it is impossible to call it from the same thread that's currently calling another (blocking) operation. Hopefully someone can clarify the concurrency requirements better than just stating that you cannot share a context between threads (which is more or less a requirement given the very blocking nature of this API). Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] MyEID microSD
Hello Andre, Yes we can provide you with microSD cards that have our MyEID applet on them. Currently you also need a SDK to be able to integrate the card to your application. Currently there is no linux ifd-handler available. To be able to communicate with the card, you need a library that is only available in the card manufacturers SDK. The card supports common PKI standards, just like the standard MyEID card. While the demand for these kind of microSD cards is very limited, the purchase of a SDK and implementing the software you want is currently the only approach we can offer you. The SDK's library is supported on Windows, Windows Mobile, Android, Symbian and Linux. Best Regards, Toni > -Original Message- > From: Andre Zepezauer [mailto:andre.zepeza...@student.uni-halle.de] > Sent: 1. syyskuuta 2010 21:51 > To: Aventra development > Cc: opensc-devel > Subject: MyEID microSD > > Hello Toni, > > by visiting the webshop of Aventra I have noticed, that there is a smart > card in microSD format in there portfolio. I have been looking for such > a device for a while, but haven't found a supplier so far. Are you able > to provide some more information on it. Most important to me is the > existence of an ifd-handler for Linux. > > Kind Regards > Andre ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Call for testing of the upcoming 0.12.0 release
Hello, On Sep 2, 2010, at 1:21 PM, Johannes Becker wrote: > When using opensc-0.12.0-svn-r4647 with our Uni Giessen Card (TCOS 2), > firefox presents the certificate to use without asking the PIN. > Subsequently the web page called can't be displayed. > > On the other hand CardOS 4.3 works with that release. > There were no problems with opensc 0.11 and TCOS 2. Please provide opensc-debug.log for TCOS2 for the failing transaction with 0.12.0. If possible, also the successful log with 0.11.X might help. [1] http://www.opensc-project.org/opensc/wiki/ReportingBugs -- Martin Paljak @martinpaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Problem with 2K keys and MyEID
Hello, On Sep 2, 2010, at 12:37 PM, Aventra development wrote: >> On Sep 1, 2010, at 7:23 PM, Aventra development wrote: >>> - Card initialization and finalization (activation) >>> From the patch: >> >> +static int card_state; >> + >> >> card_state is now a card driver property, not a card property. I suspect > this >> is not what you want. >> > [TSj] What we want is to maintain the cards state (activated or creation) > and use it internally. > Can the driver itself set this value or is it maintained elsewhere? A static file variable is shared among all instances of the driver, it is not a card property. If you want to associate it with a card, you need to use struct sc_card->drv_data (a void pointer) [1] [2]. >>> - Key generation (thanks to Viktor, however now I have some problem with >> pcsc transmit failing after some time while the card is generating the > key) >> Which reader do you use? Can you try with some other reader? > [TSj] I have used ACS ACR38 CCID and Omnikey Cardman 3121, neither works. > I've attached a log (opensc-debug gen-key.log). Key generation succeeds (in 7 seconds), but another command (select file) is failing: 0xb7b086c0 09:54:00.138 [pkcs15-init] card-myeid.c:1004:myeid_generate_store_key: returning with: 0 0xb7b086c0 09:54:00.138 [pkcs15-init] card-myeid.c:1096:myeid_card_ctl: returning with: 0 0xb7b086c0 09:54:00.138 [pkcs15-init] card.c:688:sc_card_ctl: returning with: 0 0xb7b086c0 09:54:00.139 [pkcs15-init] card.c:543:sc_select_file: called; type=2, path=3f0050154b05 0xb7b086c0 09:54:00.139 [pkcs15-init] card-myeid.c:192:myeid_select_file: called 0xb7b086c0 09:54:00.139 [pkcs15-init] apdu.c:521:sc_transmit_apdu: called 0xb7b086c0 09:54:00.139 [pkcs15-init] card.c:290:sc_lock: called 0xb7b086c0 09:54:00.139 [pkcs15-init] reader-pcsc.c:235:pcsc_transmit: reader 'OmniKey CardMan 3121 00 00' 0xb7b086c0 09:54:00.139 [pkcs15-init] apdu.c:187:sc_apdu_log: Outgoing APDU data [9 bytes] = 00 A4 08 00 04 50 15 4B 05 .P.K. == 0xb7b086c0 09:54:00.139 [pkcs15-init] reader-pcsc.c:168:pcsc_internal_transmit: called 0xb7b086c0 09:54:02.250 [pkcs15-init] reader-pcsc.c:194:pcsc_internal_transmit: OmniKey CardMan 3121 00 00:SCardTransmit/Control failed: 0x80100016 0xb7b086c0 09:54:02.250 [pkcs15-init] reader-pcsc.c:346:pcsc_detect_card_presence: called >>> Anyway it's a step forward. If somebody is able to help with the Firefox >> problem or knows why the pkcs15-tool does not work, feel free to edit the > code >> or send some information to me so we will get also these working. >> Please provide a debug log. > [TSj] The Firefox certificate enrolment does not work. How do I enable debug > logging for this? The same way as for key generation. I created a wiki page with information on how to report bugs[3]. It should cover the basics (to hopefully avoid "My card does not work, help!" messages) but should also give more advanced tips for a good bug report, including simple debugging/troubleshooting tips. Feel free to improve or ask for more if needed. [1] http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/card-piv.c#L1880 [2] http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/card-piv.c#L1821 [3] http://www.opensc-project.org/opensc/wiki/ReportingBugs -- Martin Paljak @martinpaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Call for testing of the upcoming 0.12.0 release
Hello, unfortunately I have to repeat my message about the TCOS2 card: When using opensc-0.12.0-svn-r4647 with our Uni Giessen Card (TCOS 2), firefox presents the certificate to use without asking the PIN. Subsequently the web page called can't be displayed. On the other hand CardOS 4.3 works with that release. There were no problems with opensc 0.11 and TCOS 2. I tested on Debian squeeze. Johannes ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] How to use just one card of two in Firefox?
Helo, On Sep 2, 2010, at 12:45 PM, Johannes Becker wrote: > I'm setting up a process for printing the personal information for a chipcard > to be handed out. > The service person's card is used by firefox for authentication. > The card to be handed out is analysed by opensc command line tools. > Everything works, but I think, the process that analyses the second card is a > bit slow, because firefox with opensc-pkcs11.so also wants to grab > the second card. > > How can I tell opensc-pkcs11.so to ignore the second card completely? Try the latest OpenSC SVN snapshot [1] and use "ignored_readers" PKCS#11 option in opensc.conf [2]. [1] http://www.opensc-project.org/files/opensc/snapshots/ [2] http://www.opensc-project.org/opensc/browser/trunk/etc/opensc.conf.in#L407 -- Martin Paljak @martinpaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] How to use just one card of two in Firefox?
Hello, I'm setting up a process for printing the personal information for a chipcard to be handed out. The service person's card is used by firefox for authentication. The card to be handed out is analysed by opensc command line tools. Everything works, but I think, the process that analyses the second card is a bit slow, because firefox with opensc-pkcs11.so also wants to grab the second card. How can I tell opensc-pkcs11.so to ignore the second card completely? Johannes ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Opensc and SetCOS.
Hello, On Sep 2, 2010, at 11:32 AM, Patrik Martinsson wrote: > Hello again, > >>> That can be improved in gdm/screensaver. OpenSC returns CKF_USER_PIN_LOCKED >>> after a PIN entrr try if the method got blocked. Even NSS/Firefox used to >>> ignore this return code for a long time and as a result asked for a PIN 3 >>> times (hardcoded apparently) even if the PIN was already locked. That got >>> fixed lately, don't know when it will arrive in Firefox though. Also see >>> ticket #250, for further flags to check for usability (e.g. "This will be >>> your final PIN try, failing this will block your PIN" message). > > Ok, sounds good. I don't know if i got this right, but is this the "workflow" > of how a authentication basically works with pkcs11 with nss enabled. > > login(gdm/scrennsaver/whatever) => pam_pkcs11 => nss => opensc => > pcscdriver => pcscd Yes, it should look like this. Bugzilla bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=506939 https://bugzilla.mozilla.org/show_bug.cgi?id=506965 Unfortunately, bugzilla has removed the "my votes" feature which I used to keep track of interesting issues and the user interface is soo sloow and complicated that I'm not able to find the more detailed reports. Feel free to surf bugzilla yourself for the exact status of the issues. > >>> No, it is a bug in OpenSC pcsc driver. Just wanted to draw the attention to >>> the fact that it has nothing to do with Open*CT*. > Ok cool. Is there anything i can debug to help us out here ? I would really > like to get this working and I'm willing to spend alot of time on it to get > there, just need some info on how to go further. Not much, except for trying the patch when it's ready. I'm fixing it after the initial changes to #216, with the exception of adding "disappearing slots" to hotplugging PKCS#11 module, if it works with NSS. It might get ready soon (this week) -- Martin Paljak @martinpaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Opensc and SetCOS.
Hello again, >> That can be improved in gdm/screensaver. OpenSC returns CKF_USER_PIN_LOCKED >> after a PIN entrr try if the method got blocked. Even NSS/Firefox used to >> ignore this return code for a long time and as a result asked for a PIN 3 >> times (hardcoded apparently) even if the PIN was already locked. That got >> fixed lately, don't know when it will arrive in Firefox though. Also see >> ticket #250, for further flags to check for usability (e.g. "This will be >> your final PIN try, failing this will block your PIN" message). Ok, sounds good. I don't know if i got this right, but is this the "workflow" of how a authentication basically works with pkcs11 with nss enabled. login(gdm/scrennsaver/whatever) => pam_pkcs11 => nss => opensc => pcscdriver => pcscd So opensc returns "whatever" to nss and nss returns "whatever" to whats calling it ? Is this the return codes from nss we are talking about, http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html#1039257, cant really see anything about blocket pin or similar. (maybe they haven't updated it yet) And as long as nss doesn't return "whatever" opensc returns, it's impossible for pam_pkcs11 to tell the calling application the "correct" return code ? I'm asking all this out of curiosity so i can get the basic understanding of what I'm talking about >> No, it is a bug in OpenSC pcsc driver. Just wanted to draw the attention to >> the fact that it has nothing to do with Open*CT*. Ok cool. Is there anything i can debug to help us out here ? I would really like to get this working and I'm willing to spend alot of time on it to get there, just need some info on how to go further. /Patrik Martinsson, Sweden. On 09/01/2010 01:17 PM, Martin Paljak wrote: > Hello, > > On Sep 1, 2010, at 1:58 PM, Patrik Martinsson wrote: > >> As a Linux user today at our company you need to find a Windows computer or >> go to our helpdesk to get your card unlocked, you also need to call the >> helpdesk to get your puk. >> I guess what I'm asking for is a simple way for the user to understand that >> their card is locked, eg. telling the user that the 'card is locked' instead >> of 'logon failure' as it is today. But again, maybe this is not possible, or >> maybe this is applications specific rather then opensc. >> > That can be improved in gdm/screensaver. OpenSC returns CKF_USER_PIN_LOCKED > after a PIN entrr try if the method got blocked. Even NSS/Firefox used to > ignore this return code for a long time and as a result asked for a PIN 3 > times (hardcoded apparently) even if the PIN was already locked. That got > fixed lately, don't know when it will arrive in Firefox though. Also see > ticket #250, for further flags to check for usability (e.g. "This will be > your final PIN try, failing this will block your PIN" message). > > > > Only if they integrate standard CCID readers directly to the USB bus. Unfortunately they use integrated chips that do "secure digital" and "smart card". Some Linux tutorials in the wild, that talk about OpenSC,>> direct people to memory card reader listings (where, indeed, some chips support smart cards but AFAIK only on Windows) instead of libccid's extensive list... >> Yep, i was actually talking about one of those chips,R5C822 >> (http://www.ricoh.com/LSI/product_pcif/pcc/5c821/index.html). According to >> the homepage the chip is discontinued however HP still delivers them in >> their brand new models, 8440p for example, god knows why. Is there any >> chance that we would see some support on these chipsets under Linux ? >> > This has been discussed before [2] on MUSCLE mailing list. I doubt it will > happen [3]. > > > >> Check the logs. OpenCT has nothing to do with it. The culprit, failing C_WaitForSlotEvent amd pcsc_wait_for_event has been identified a few e-mails back. reader-pcsc.c needs fixing for a) card re-insertion detecion b) event waiting. >> Hmm yes, I've checked the logs, and as i understand it you correctly, it's a >> pcsc-lite issue ? So i should take it on their mailinglist instead ? >> > No, it is a bug in OpenSC pcsc driver. Just wanted to draw the attention to > the fact that it has nothing to do with Open*CT*. > > > [1] http://www.opensc-project.org/opensc/ticket/250 > [2] http://lists.drizzle.com/pipermail/muscle/2009-December/008009.html > [3] http://lists.drizzle.com/pipermail/muscle/2009-December/008013.html > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Opensc and SetCOS.
Thanks for the info Peter, well explained ! I laughed to myself when I read this part, >> There's maybe a handful of people at HP worldwide who really know the details of components in the systems they sell. I can only confirm this, I've called HP several times about the smartcard-reader in our laptops (6930/6910/8440) and they have no idea what I'm talking about. All this is a shame though. We actually need to buy pcmcia/expresscard-readers for all our Linux users to get their laptops working. Even though that may be a relative small cost, it's a stupid an unnecessary cost in my opinion. /Patrik Martinsson, Sweden. On 09/01/2010 07:03 PM, Peter Stuge wrote: > Martin Paljak wrote: > >>> R5C822 (http://www.ricoh.com/LSI/product_pcif/pcc/5c821/index.html). >>> According to the homepage the chip is discontinued however HP >>> still delivers them in their brand new models, 8440p for example, >>> god knows why. Is there any chance that we would see some support >>> on these chipsets under Linux ? >>> >> This has been discussed before [2] on MUSCLE mailing list. I doubt >> it will happen [3]. >> > Unfortunately I'd say you are quite right, Martin. > > HP do not make the computers they sell. There's a small group of > companies called ODMs, Original Design Manufacturer, typically in > Taiwan, which design and manufacture pretty much all consumer > electronics today. > > The ODMs have the documentation for the chips, but they have > typically signed absurdly strict NDAs with the chip makers. Some chip > makers welcome the open source community and try to help them out, > others run away screaming. (Or decline politely.) > > Unless the chip vendor wants to help, be it officially, or > unofficially, through some side channel, then reverse engineering is > the only way to get a device supported, but that requires tremendous > amounts of work, it can't really be justified economically by 500 > users, or even 5000. :\ > > The (not-so-)quick fix would be in procurement. An open source aware > organization must factor software support into purchasing decisions, > maybe together with the group(s) which create technical requirements > in the organization, so the relevant pieces of hardware can be > ignored. > > The purchasing task is hard, specifically because of the gap between > OEMs (HP, Lenovo, Dell, etc) and ODMs. There's maybe a handful of > people at HP worldwide who really know the details of components in > the systems they sell. There is no channel from consumers with a clue > to peers within the very long production chain for the products we > hold in our hands. > > > //Peter > ___ > 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
