I'd already asked to have my commit access revoked, so this change is fine
with me.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
On Thu, 29 Jan 2009, Andrey Jivsov wrote:
> I am attaching the tested patch to the file ifd-ccid.c to add support for the
> reader. The reader's USB IDs that I tested with are 0b97:7762 and 0b97:7772.
> Without this patch the ifd-ccid.c code will not work with these readers.
>
> The patch is b
Chaskiel, please look at the ccid_open_usb(), and try to help me
figure out why I had to add ifd_sysdep_usb_reset() in order to make
the reader respond to the initial status query.
It appears that ccid_card_status always fails if it has to probe the
device and no card is present. That's because
I seem to have not sent this yesteday when I composed it
> Please notice that the reset is before any other command...
Yes, I did see that.
> Debug: ccid_command: sending: 65 00 00 00 00 00 00 00 00 00
> Debug: usb_send: usb send to=x02
> Debug: usb_send: send 65 00 00 00 00 00 00 00 00 00
>
On Fri, 2 Jan 2009, Alon Bar-Lev wrote:
ifd_sysdep_usb_set_interface(dev,
params->usb.interface,
params->usb.altsetting))
A usb device may provide multiple programming interfa
On Fri, 2 Jan 2009, Alon Bar-Lev wrote:
>
> I don't understand if you think that this patch is an improvment to
> current state or not.
The patch should work with your hardware and should not break anything
else (it avoids SETINTERFACE if the default altsetting is the only one
available for the c
I recently happened across some opensc-user discussion of eutron
cryptoidenty itsec-i tokens (as well as the wiki document
https://www.opensc-project.org/opensc/wiki/CryptoIdentityItsec)
I have tracked down the key generation problem (though I don't know why it
doesn't also affect etokens).
Now
On Sat, 31 May 2008, Alon Bar-Lev wrote:
Chaskiel,
Can you please have a look?
It should be standard CCID.
This device seems to have a bug. It does not reset the parameters when a
new IccPoweron command is sent (page 27 of DWG_Smart-Card_CCID_Rev110.pdf)
The 'automatic activation' exception
I have apparently been sitting on a patch that does pts and parameter
setting in the proper order for most of a year. (the problem you have
seems to be that the existing code changes the baud rate before doing pts,
so the card responds at the old baud rate) I do not know why I did not
submit th
> have refrained from initializing the itsec-p I got, due to the somewhayt
> write-only nature of starcos.
I meant "write once", of course. sigh.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/lis
On Wed, 9 Jan 2008, Justin Karneges wrote:
> Is the CryptoIdentity better supported in OpenSC/CT yet?
> I remember a year or so ago you and I were fighting to get to work.
I'm pretty sure the patch that was commited as rev 826 of ifd-eutron.c
made everything work for me. I no longer have useful
cardos_match_card() will identify M4.2b carda as M4.3 instead. As far as I
can tell, this has no detrimental effects right now (the rest of the code
treats all SC_CARD_TYPE_CARDOS_M4_3 and SC_CARD_TYPE_CARDOS_M4_2B the
same), but it would probably be good if the following two tests were done
in
> Have you tried my CCID driver [1] with such a card?
not in a character mode reader (it turns out that the "new" o2micro
devices still have the descriptor bug and are not usable with ccid for
pcsc. I do not know why it worked in openct).
your copy of openct's proto-t1.c does not have the bogus
On 3/12/07, Andreas Jellinghaus <[EMAIL PROTECTED]> wrote:
I also changed the chop size in 3127 to
256 and added a comment. this needs a lot of testing, I fear
some combinations of readers and cards might break. but editing
the opensc.conf should be able to fix it.
When trying to create a us
On Sat, 18 Nov 2006, John T. Guthrie wrote:
On Fri, 2006-11-17 at 16:17 -0500, Chaskiel M Grundman wrote:
pkcs15 does define file formats (for smart cards that use "transparent"
files), but "a file in PKCS #15 format" is nonsensical. At the very
least, there are multiple file formats depending
Any idea what is wrong?
starcos cards are "single use" unless they are test cards. You cannot
erase them. Eutron cannot provide ITSEC-P tokens that have been
"finalized" as test cards (I asked)
There is no 'delete file' operation at all (even on a test card. you must
erase and recreate the mf
One more cardos question:
Is there a way to delete a pin reference, other than deleting the DF that
it's rooted in? if so, I may be able to simulate pkcs15-init -E even with
the blocked pseudo-transport pin
___
opensc-devel mailing list
opensc-devel
My ITSEC-I works fine (more or less)
% pkcs11-tool --list-objects
Certificate Object, type = X.509 cert
label: Certificate
ID: 45
Public Key Object; RSA 1024 bits
label: Certificate
ID: 45
Usage: encrypt, verify
When I added the certificate (using pk
On Mon, 24 Apr 2006, Justin Karneges wrote:
Alright, I decided to pick up an ITSEC-I model so that I'd at least have a
working card. Sadly, and many dollars later, I can't get this one to work
either. :( pkcs11-tool reports a lot of errors when I try to use
--show-info, for example. --list-obj
(C) 2003, Andreas Jellinghaus <[EMAIL PROTECTED]>
* Copyright (C) 2003, Olaf Kirch <[EMAIL PROTECTED]>
+ * Copyright 2006, Chaskiel Grundman <[EMAIL PROTECTED]>
*/
#include "internal.h"
+#include "atr.h"
+#include "usb-descriptors.h"
#include
I am unfortunately encountering frequent usb errors with the itsec-p and
5/2048. ifd_usb_control is failing with EOVERFLOW, which apparently
means that a usb condition known as 'babble' has been detected. I don't
really know what this means or if it's the fault of openct, linux, or
the hardware
On Sun, 16 Apr 2006, Justin Karneges wrote:
But what about drivers? Does the same SafeSign driver installation work for
all 5 devices? This might mean that even though there are varying firmwares,
they probably operate very similarly if one driver can manage all of them.
There are 2 "driver" c
I acquired a starcos card today, and I appear to have blocked its pin
(only 2 pin tries were available)
I have some questions
1) is it possible to adjust the number of pin tries?
2) does this card support unblocking? it responds to unblock requests with
AUTHENTICATION METHOD BLOCKED (0x6983):
I noticed that too. I tried sending 0x65 pts[2] (which happens to be 0x18),
but all that did was put opensc into some weird loop:
recv: 00 82 00 82
send: 00 c0 00 c0
recv: 00 82 00 82
send: 00 c0 00 c0
recv: 00 e0 00 e0
This is sane (but unfortunate) T=1 control stuff. The first is
T1_R_BLOCK |
Getting closer...
It seem like a step backwards to me though...
First, I should mention that with your patch, now the 0x65 control request
happens before the T=1 negotiation. The original ifd-eutron.c and safesign
both do it afterwards. My device doesn't seem to mind though.
However, the 0x65
The attached patch _should_ force the use of T=1 in a clean way. It
includes (and expands upon) the PTS/ccid patch I sent earlier. (I left the
ccid-specific parts out though).
If I decide to pick one of these devices up, I might try to fix the T=0
stuff, but the cost seems a bit high for exper
On Sat, 18 Mar 2006, Justin Karneges wrote:
By the way, how do the fields not initialized by ifd_eutron_register() get
initialized?
global uninitialized data is stored in the bss segment, which is
guaranteed to be zeroed when the executable is loaded. I'm pretty sure the
C standard says somet
The attached patch fixes some broken PTS behavior that resulted from two
misconceptions that I had about PTS:
1) that the PTS response from the card must be an exact reflection of the
request in order to be considered successful. 7816-3 says that the card
may refuse the PTS1 byte by sending a
send: 00 a4 00 0c 02 3f 00
recv: a4
This means that the set_protocol patch is incorrect. the a4 is a proper
T=0 ack byte. (and my assumptions about what usb T=0 devices do don't
apply here)
You didn't say what actually happens when eutron_send only gets/sends 5
bytes. Does the card reply at a
On Fri, 17 Mar 2006, Justin Karneges wrote:
I'd like to make ifd-eutron do the same thing, although I'm not sure of the
best approach. My "guess" is that SafeSign determines that the first
response is wrong, and then rerequests the ATR, but I don't know how this
wrongness would be detected, esp
30 matches
Mail list logo
