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
> # pkcs11-tool --module /usr/local/lib/opensc-pkcs11.so --list-objects
> card-cardos.c:225:cardos_check_sw: file not found
> iso7816.c:458:iso7816_select_file: returning with: File not found
> card-cardos.c:401:cardos_select_file: returning with: File not found
> card.c:563:sc_select_file: returni
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
On Sunday 16 April 2006 10:15, Chaskiel Grundman wrote:
> On Sun, 16 Apr 2006, Justin Karneges wrote:
> > Ok. So, at this time, the ITSEC-I is the only model of the five that is
> > known to work in OpenSC.
>
> We could have told you that weeks ago.
Alright, I decided to pick up an ITSEC-I model
Am Montag, 17. April 2006 13:22 schrieb Justin Karneges:
> On Monday 17 April 2006 03:20, Andreas Jellinghaus wrote:
> > so I guess your problem is the hotplugging. are you using hotplug, udev
> > or hald for that?
>
> I have /etc/hotplug, so I'm guessing hotplug. Is there some trick to
> making i
On Monday 17 April 2006 03:20, Andreas Jellinghaus wrote:
> so I guess your problem is the hotplugging. are you using hotplug, udev
> or hald for that?
I have /etc/hotplug, so I'm guessing hotplug. Is there some trick to making
it work with OpenCT?
-Justin
__
Am Montag, 17. April 2006 12:20 schrieb Andreas Jellinghaus:
> - if you plugin some ifdhandler, either hotplug, udev or hald will get a
^^ usb crypto token I meant of course...
> notification from kernel and start "openct-control attach ..." which in
> turn runs
Am Montag, 17. April 2006 10:52 schrieb Justin Karneges:
> Nit: OpenCT still reports the card as "CryptoIdendity", which is not proper
> spelling.
>
> Side note: OpenCT is very picky about running for me. openct-control's
> 'init' seems to have no effect unless I have a card plugged in, and if I
>
On Sunday 16 April 2006 23:53, Chaskiel Grundman wrote:
> The attached patch implements the eutron changes from my last message,
> including the T=1 fix. It also adds an ifsd negotiation function to
> proto-t1.c (taken from the copy of proto-t1.c in the pcsc-lite ccid
> driver), and makes use of it
The attached patch implements the eutron changes from my last message,
including the T=1 fix. It also adds an ifsd negotiation function to
proto-t1.c (taken from the copy of proto-t1.c in the pcsc-lite ccid
driver), and makes use of it in the eutron driver.
The patch also attempts to flush the
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 Sunday 16 April 2006 10:15, Chaskiel Grundman wrote:
> On Sun, 16 Apr 2006, Justin Karneges wrote:
> > Well, this is silly and stupid, yet unsurprising. I guess what we really
> > want is OpenSC support for the devices and then we can wipe our cards and
> > throw SafeSign out the window.
>
> ex
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
On Saturday 15 April 2006 11:34, Chaskiel M Grundman wrote:
> ITSEC-P and FIPS use the same card operating system (STARCOS). They're not
> identical though. The ITSEC-P is STARCOS SPK 2.3, and FIPS is 2.4. The
> other models do not use STARCOS (ITSEC-I is cardOS and 5 & 2048 are based
> on ARX Priv
On Sat, Apr 15, 2006 at 04:58:56PM -0400, Chaskiel M Grundman wrote:
> >If so, do you have another OHCI HC (preferably USB 1.1-only)
> >available for testing just to exclude everything EHCI-related?
> I do not. The OHCI devices I have were acquired to be add-on EHCI
> controllers
>
> >Also interes
On Sat, Apr 15, 2006 at 04:43:10PM -0400, Chaskiel M Grundman wrote:
> Forgot this part
> --On Saturday, April 15, 2006 10:36:33 PM +0200 Peter Stuge
> <[EMAIL PROTECTED]> wrote:
>
> >Did you get any other errors
> >on the OHCI controller that could provide more clues?
>
> Nothing else. just:
>
--On Saturday, April 15, 2006 10:56:30 PM +0200 Peter Stuge
<[EMAIL PROTECTED]> wrote:
Right. Is the NEC controller EHCI with one simulated OHCI HC per
port?
Well, per 2 ports, but yes.
If so, do you have another OHCI HC (preferably USB 1.1-only)
available for testing just to exclude ever
On Sat, Apr 15, 2006 at 04:42:03PM -0400, Chaskiel M Grundman wrote:
> >If you have a hub
> >between the host (PC) and the device (token) when you see the error
> >perhaps you could try connecting the device directly to the host?
> No hub.
Ok.
> >Also, which HC(s) did you see this with?
>
> The
Forgot this part
--On Saturday, April 15, 2006 10:36:33 PM +0200 Peter Stuge
<[EMAIL PROTECTED]> wrote:
Did you get any other errors
on the OHCI controller that could provide more clues?
Nothing else. just:
usb 7-1: new low speed USB device using ohci_hcd and address 2
usb 7-1: usbfs: USBDEV
--On Saturday, April 15, 2006 10:36:33 PM +0200 Peter Stuge
<[EMAIL PROTECTED]> wrote:
If you have a hub
between the host (PC) and the device (token) when you see the error
perhaps you could try connecting the device directly to the host?
No hub.
Also, which HC(s) did you see this with?
On Sat, Apr 15, 2006 at 02:28:59AM -0400, Chaskiel M Grundman wrote:
> 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 kn
--On Saturday, April 15, 2006 01:10:45 AM -0800 Justin Karneges
<[EMAIL PROTECTED]> wrote:
Interestingly, both
ITSEC-P and FIPS use the same software driver (is this also true for the
other models?).
ITSEC-P and FIPS use the same card operating system (STARCOS). They're not
identical though
On Friday 14 April 2006 23:28, Chaskiel M Grundman wrote:
> Two patches are attached. One is what I've been running for most of today.
> it successfully resets and can do some communication with ITSEC-P/2048/5
> devices.
>
> The second implements Justin's suggestion that we just ignore TA(0) in the
Hi Chaskiel,
On Friday 14 April 2006 23:28, Chaskiel M Grundman wrote:
> I ended up purchasing a 'demo kit' from eutron that includes one of each of
> their 5 cryptoidentity tokens.
Glad to see you're still looking into this. Here's the update on my side:
Apparently the FIPS model does not work
--On Saturday, March 18, 2006 09:06:56 PM -0500 Chaskiel Grundman
<[EMAIL PROTECTED]> wrote:
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 experimentation.
I ended up purchasing a 'demo kit' from eutron that includes one of ea
On Sunday 19 March 2006 20:32, Chaskiel Grundman wrote:
> > 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
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 |
On Sunday 19 March 2006 15:39, Chaskiel Grundman wrote:
> > 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.
> >
> > Howev
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
On Saturday 18 March 2006 18:06, Chaskiel Grundman wrote:
> 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 tr
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
On Saturday 18 March 2006 08:40, Chaskiel Grundman wrote:
> Try the attached patch. It introduces eutron_set_protocol.
By the way, how do the fields not initialized by ifd_eutron_register() get
initialized?
What tipped me off is that you added this line:
eutron_driver.set_protocol = eutron_set
On Saturday 18 March 2006 16:52, Chaskiel Grundman wrote:
> > 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 ha
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 Saturday 18 March 2006 08:40, Chaskiel Grundman wrote:
> On Fri, 17 Mar 2006, Justin Karneges wrote:
> > send: 00 c1 01 fe 3e
> > recv: 00 e1 01 fe 1e
> > The 0x40 bit is set in here, but of course there are others too. I'd
> > also like to find out what the meaning of the content is as well (0
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
Justin Karneges wrote:
...
5) The device claims to support PKCS#15. I thought this was a hardware
protocol standard, and would mean instant OpenSC compatibility, but I
guess I was wrong? (I read now that it's more of a filesystem layout, how
uninteresting...)
yep, pkcs15 describes what is where
On Friday 17 March 2006 15:20, Justin Karneges wrote:
> On Friday 17 March 2006 08:19, Chaskiel M Grundman wrote:
> > Since it doesn't seem to break this device, I would put back the other
> > card_reset code you pulled out, since it might be needed with other
> > hardware (and it might deal with t
On Friday 17 March 2006 15:20, Justin Karneges wrote:
> On Friday 17 March 2006 08:19, Chaskiel M Grundman wrote:
> > it is openct's job to do the T=1 framing. The problem is that the
> > device's ATR reports that it supports both T=0 and T=1.
> > ifd_protocol_select picks T=0 (because it is report
On Friday 17 March 2006 08:19, Chaskiel M Grundman wrote:
> it is openct's job to do the T=1 framing. The problem is that the device's
> ATR reports that it supports both T=0 and T=1. ifd_protocol_select picks
> T=0 (because it is reported earlier in the ATR) and tries to use it.
> Unfortunately, e
On Fri, Mar 17, 2006 at 11:19:18AM -0500, Chaskiel M Grundman wrote:
> >Another question: Does it matter that all the windows USB writes
> >beginn with 42? In the openct driver, the init writes begin with
> >41, and the "normal" writes begin with 42. I tried changing the
> >opensc driver to use
However, eutron_send gets this:
00 a4 00 0c 02
This is not "t=1" format. Is opensc forgetting to frame the content
before
passing to openct?
it is openct's job to do the T=1 framing. The problem is that the device's
ATR reports that it supports both T=0 and T=1. ifd_protocol_select pic
On Friday 17 March 2006 02:36, Justin Karneges wrote:
> I've not yet put this in the code because surely this is much more than
> just the initialization. The openct eutron init is 2 exchanges, and this
> log shows 10 already. I hope you can make sense of this data and tell me
> where the boundar
On Friday 17 March 2006 00:40, you wrote:
> > Could you briefly explain what each phase of this function is? There
> > seems to be a lot of calls to ifd_usb_control() in chunks or in loops.
>
> card_reset does exactly the same commands I saw in a lot. they
> worked. no changes at all. then there i
On Thursday 16 March 2006 18:25, Justin Karneges wrote:
> # opensc-tool --atr
[snip]
> Failed to connect to card: Card is invalid or cannot be handled
>
> Seems definitely broken still.
Follow-up:
With some more debug, I can see that opensc is trying to write 5 bytes:
00 c0 00 00 00
It then a
Hi Chaskiel,
First, I want to mention that I was able to obtain some ATR value by adding
additional debug information. This is the content of 'atr' right after the
memcpy() in eutron_card_reset(). It is 17 bytes.
3b b7 18 00 c0 3e 31 fe 65 53 50 4b 32 34 90 00 25
The reset failure occurs l
--On Thursday, March 16, 2006 16:02:31 -0800 Justin Karneges
<[EMAIL PROTECTED]> wrote:
Yes, ifd-eutron.c looks quite simple. Syslog reports "eutron: failed to
activate token", which is in eutron_card_reset(), so I should probably
first look for problems there.
I would first attempt to re
Hi Andreas,
On Thursday 16 March 2006 11:56, Andreas Jellinghaus wrote:
> to write a new driver you could help with:
> a) cat/proc/bus/usb/devices - only the part for those devices,
>so we can see how they look like / how to identify the hardware.
>(usualy this is done with vendor and prod
(resending this, didn't seem to go through)
Hi Nils,
On Thursday 16 March 2006 00:45, Nils Larsch wrote:
> Starcos SPK 2.4 shouldn't be a problem for opensc (of course it would
> be interesting to know whether the token is empty)
Well, it is not empty anymore, I've initialized it using SafeSign
Hi Justin,
the smart card inside should be fine.
the problem is the usb part. I guess the current openct
driver won't work.
to write a new driver you could help with:
a) cat/proc/bus/usb/devices - only the part for those devices,
so we can see how they look like / how to identify the hardware.
Hi Nils,
On Thursday 16 March 2006 00:45, Nils Larsch wrote:
> Starcos SPK 2.4 shouldn't be a problem for opensc (of course it would
> be interesting to know whether the token is empty)
Well, it is not empty anymore, I've initialized it using SafeSign on Windows.
However, I've tried the card un
Justin Karneges wrote:
Hi folks,
I have a CryptoCombo FIPS device, which I believe contains the same hardware
as a CryptoIdentity FIPS. Eutron's website claims that both devices use a
Philips P8WE5032 chip, with "mask" G&D StarCOS SPK 2.4.
Eutron offers a closed source driver for some old L
54 matches
Mail list logo
