Hi,
I am interested in the day when USB crypto tokens will be usable with any
computer and not needing special drivers, similar to the success of USB Mass
Storage. I wonder where we are at with that progress? Almost four years ago
I asked about smartcard standards:
http://www.opensc-project.o
On Saturday 02 May 2009 02:08:38 Anders Rundgren wrote:
> The need for an externally visible
> file-system in a smart card does not appear logical; none of the current
> crypto APIs need that.
Certainly apps don't need it. At most, a regular app would target PKCS#11,
which does not expose a fil
On Thursday 14 August 2008 18:52:26 Weitao Sun wrote:
> I have finished the code supporting usb tokens from
> Feitian(www.ftsafe.com) named "ePass3000" , and tested it. It is used in
> China,Japan and Brazil.I want to know by which means I can submit the
> changes to OpenSC. I guess there may be a
On Wednesday 09 January 2008 12:46 pm, Chaskiel M Grundman wrote:
> Depending on what you consider a reasonable price, you can actually get
> them directly from eutron. You'd want the "CRYPTOIDENTITY DEMO KIT BASIC"
> (which is 35 euro + 20% vat + 5-10 euro for shipping. a bit more than a
> cryptof
On Friday 25 May 2007 12:46 pm, Andreas Jellinghaus wrote:
> On Friday 25 May 2007 18:34:51 Ludovic Rousseau wrote:
> > Why is "Generic CCID Reader" used instead of the real reader name?
>
> a mix of a) historic - for some reason we had that already, don't know why.
> and b) I was too lazy today to
On Wednesday 02 May 2007 5:36 am, Martin Paljak wrote:
> On 02.05.2007, at 15:21, Alaric Dailey wrote:
> > StartCom has free certs, and is now accepted by most browsers.
>
> Nice service.
>
> But real life statistics say: 80% users use IE (in Estonia)
>
> So unless IE accepts the certificate ( I'l
On Thursday 15 February 2007 11:00 am, Andreas Jellinghaus wrote:
> Justin Karneges wrote:
> > There would appear to be a standard for #1. I don't remember what it is
> > called, but it involves the ATR and then T=0 or 1 and friends. However,
> > my experience with ha
On Thursday 15 February 2007 7:14 am, Douglas E. Engert wrote:
> Yes propriety vendor solutions are a major problem. Have a look at the
> PIV card comments at:
> http://www.opensc-project.org/opensc/wiki/UnitedStatesPIV
>
> The intent is to standardize on multiple vendors for cards,
> multiple ve
On Thursday 15 February 2007 3:26 am, Henryk Plötz wrote:
> There you also get the definition of APDUs (Application Protocol Data
> Unit) for commands and responses. The second part of your #1, 7816-4
> then defines common ("interindustry") commands for most of the basic
> operations: selecting fil
On Thursday 15 February 2007 12:02 am, Ludovic Rousseau wrote:
> On 14/02/07, Justin Karneges <[EMAIL PROTECTED]> wrote:
> > There would appear to be a standard for #1. I don't remember what it is
> > called, but it involves the ATR and then T=0 or 1 and friends.
>
&g
Hi folks,
I'm just trying to wrap my head around all of the various protocols involved
in smart card use, and today I was reading the OpenSC website and it got my
mind going again. I'm glad that the website finally discusses these
important details.
Now, PKCS#11, as mentioned on the website,
On Tuesday 13 June 2006 14:37, Eric Norman wrote:
> On Jun 13, 2006, at 4:08 PM, Andreas Jellinghaus wrote:
> > I think we need an FAQ page. if you know questions that
> > you think are typical for new people looking at using smart
> > cards, please send them. I will try to gather all of them
> > a
On Tuesday 25 April 2006 13:42, Chaskiel M Grundman wrote:
> you can't pkcs15-init -C more than once.
> if pkcs15-init -E worked on this card, you could do that first, but if your
> card is anything like mine, there's a pin protecting DELETE on objects in
> the MF (this card supports list files, an
On Monday 24 April 2006 23:29, Chaskiel Grundman wrote:
> 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 ei
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 pic
Hi Sergio,
On Tuesday 18 April 2006 13:28, Sergio C wrote:
> As I can see, the usb subsystem sends additional data to the eToken PRO
> attached as follow: there are some bytes before the APDU's Header (00 40
> 05) and after the body (C9)... Has anyone idea about what this bytes
> represent and how
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
__
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
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 Sa
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 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 Wednesday 22 March 2006 17:41, Chaskiel M Grundman wrote:
> --On Wednesday, March 22, 2006 05:19:06 PM -0800 Justin Karneges
>
> <[EMAIL PROTECTED]> wrote:
> > Could these problems be related to the openct driver, or are we done with
> > that? It would be nice to c
On Wednesday 22 March 2006 16:45, Chaskiel M Grundman wrote:
> --On Wednesday, March 22, 2006 03:52:20 PM -0800 Justin Karneges
>
> <[EMAIL PROTECTED]> wrote:
> > On Wednesday 22 March 2006 15:05, you wrote:
> >
> > But --list-files does not:
> >
> >#
On Wednesday 22 March 2006 15:05, you wrote:
> starcos 2.4 should already work (perhaps except for a missing ATR
> but adding a new ATR is trivial and harmless change) as afaik the
> differences between starcos spk 2.3 and starcos spk 2.4 are
> negligible as far as opensc is concerned.
I've added
On Wednesday 22 March 2006 13:57, Nils Larsch wrote:
> unless someone has something extremly important that needs
> to be included in the upcoming 0.11 release I would like
> to announce a feature freeze for 0.11.
I'd really like to get my eutron card working in the next version. What's the
sche
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
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
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
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
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 m
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
> > hardwa
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_
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 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
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
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
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 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
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 Linux distributions. They
43 matches
Mail list logo
