Hi,
--- Axel Heider <[EMAIL PROTECTED]> wrote:
> Hi,
>
> some time ago I got this response from Eric Perlin
> from
> Microsoft about their PC/SC implementation:
>
> > This is no work for the driver. This needs to be
> handled
> > by the app. I recommend a little layer on top of
> > SCardTr
Hello,
Maybe then the ICC Service Proviver should be intelligent enough to send a
Get Response when a 61 XX is returned and carry on with other transactions
when the full data is returned.
Dave
***
Unix Smart Card Developers - M.U.S.C.
On Thu, 02 Aug 2001 09:19:53 +0200 Laurent Boulard
<[EMAIL PROTECTED]> wrote:
> David Corcoran wrote:
>
> >Hello,
> >
> >Points well taken. It seems unanimous that the driver should take care
> of
> >Get Response. I shall update the IFD Handler documentation to
> reflect
> >this. Thank you so
river, but its going to be
true for some time to come.
Regards,
Peter T
Bristol UK
- Original Message -
From: "Laurent Boulard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 01, 2001 8:08 AM
Subject: Re: MUSCLE Is 61xx handled in your driver?
>
Hi,
Check out this link:
http://www.corbina.ru/~versia23/ALLSAT/SatXpress/SmartCard/Iso7816-4.htm
This has some useful info about T=1 and T=0 protocols.
You can check the source code for Infineer Smartcard drivers ( available under Source
drivers in download page in www.linuxnet.com ).
I fol
CLA INS P1 P2 Lc Le in 7816-4 speak (section 5.3.1 Fig 3)
Peter T
Bristol UK
- Original Message -
From: "David Corcoran" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 31, 2001 9:26 PM
Subject: Re: MUSCLE Is 61xx handled in your driver?
>
> In the perfect world yes ! but, sadly, people sometimes doesn't follow
> correctly the ISO7816 or misunderstood it. I have cards (W4SC as an
> example) which send back a GET RESPONSE even for a APDU without data.
> This is really annoying as I have to modify my application to take care
> of this
David Corcoran wrote:
>Hello,
>
>Points well taken. It seems unanimous that the driver should take care of
>Get Response. I shall update the IFD Handler documentation to reflect
>this. Thank you so much for your suggestions.
>
Jim rees said:
I agree that the application should not hav
Purchase ISO 7816 parts 3 and 4 to understand the low level communication
between card and IFD (Terminal, card reader).
Peter T
Bristol UK
- Original Message -
From: "Joe Phillips" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Wolf Geldmacher" <[EMAIL PROTECTED]>
Sent: Thursday, August
Mahlzeit
On Wed, Aug 01, 2001 at 08:34:06AM -0700, David Corcoran wrote:
> Points well taken. It seems unanimous that the driver should take care of
> Get Response. I shall update the IFD Handler documentation to reflect
> this. Thank you so much for your suggestions.
One question: How does
David Corcoran wrote:
>I think you should handle the Get Response if your APDU looks like the
>following:
>
>CLA INS p1 p2 p3 lentx xx xx xx xx xx lenrx
>
>Is this correct ?
>
In the perfect world yes ! but, sadly, people sometimes doesn't follow
correctly the ISO7816 or misunderstood it. I hav
I think you should handle the Get Response if your APDU looks like the
following:
CLA INS p1 p2 p3 lentx xx xx xx xx xx lenrx
Is this correct ?
Dave
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards i
I agree that the application should not have to deal with this. But I don't
think the driver should either. Anything that every driver must do in the
same way really belongs at a higher level, in pc/sc.
***
Linux Smart Card Developers -
Hi,
I completly agree with Andreas. Get Response is
dependant on T=0 transport protocol and must not be
handled at application level. This is at least what
ISO 7816 says.
Towitoko driver 2.0.X handles authomatically the Get
Response when the command is Case 3 or Case 4. Also
the issues athomatic
When a card returns 61.xx, it means that the card has xx byte to
return to host.
Does a smartcard reader driver handle this, usually?
My Todos driver does. It seemed useful at the time. I would like to know
whether this is correct or not. Most other reader drivers I have looked at
do n
ly 31, 2001 5:07 AM
Subject: Re: MUSCLE VerifyKey using OCF
>
> > Hi All,
> >
> > Does anybody here use Cyberflex Access cards with OCF?
> >
> > If so, could you help me with the doubt below?
> >
> > In the Cyberflex Access card we have t
> Most of the drivers pass the 61 XX back to the application to handle. I
> think it is bad practice to handle this in the driver since it is a card
> specific ISO function.
GET RESPONSE is a transport level command. It should therefore be invisible
for the application. The problem arises if you
Hi Naomaru
Our driver for the ORGA ECO 5000 automatically sends GET_RESPONSE; if the
card returns '61 xx' or '9F xx' and the application passed a case 4 command
APDU to the reader. The class byte for GET_RESPONSE is copied from the class
byte used for the original command.
IMHO this is the way i
Hello,
Most of the drivers pass the 61 XX back to the application to handle. I
think it is bad practice to handle this in the driver since it is a card
specific ISO function. This should happen above the reader abstraction
where the card abstraction layer occurs. BTW - has anyone done an OSI
l
Most readers wont handle this response code. Some POS terminals will.
You should send the get response/data command to retrieve the data.
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of Naomaru Itoi
Sent: Monday, July 30, 2001 6:43 PM
To:
> Hi All,
>
> Does anybody here use Cyberflex Access cards with OCF?
>
> If so, could you help me with the doubt below?
>
> In the Cyberflex Access card we have the idea of identity such as AUT0,
> AUT1, etc. In OCF to verify a Card Holder we must use the sendVerifyCommand.
> Now w
Does your OCF have a PassThru API? (Sun's OCF does.) If it does,
PassThru allows you to send an APDU directly to the card, so you could
try that.
--
Concentration .. Naomaru Itoi, coding @ home
***
Linux Smart Card Developers - M.U.S
On Wed, 25 Jul 2001, Priit Randla wrote:
> For some strange reason, my Reflex 72 does not work with this driver.
> pcscd (0.9.3) registers card insertion/removal, reports ATR but does
> not poll
> the card, as other readers do. SEstablishContext, SCardListReaders,
> SCardConnect all succ
David Corcoran wrote:
>
> Hello,
>
> Due to popular demand. I re-released the Reflex 72 driver with the
> IFDHANDLER 2.0 wrapper for CT-API. The driver is available on the website
> now. All the card insertion/removal bugs have been solved.
>
> Regards,
> Dave
>
For some strange reason,
Hello,
I included the wrong ctbcs.h in the package. I uploaded a newer version
with the correct one.
Can you tell me the T=1 card you are using for the Reflex USB on Mac OS X
? Please send me mail directly.
There is an official DDK for PC/SC apps and drivers for Mac OS X at:
http://developer.
Hello,
I get errors when compiling the Reflex 72 driver on linux mandrake 8.0.
CTBCS_* seems to be not defined into the ctbcs.h.
Do I use the wrong ctbcs.h ?
I also tried the Reflex USB and the GemPC430 on osx. The GemPC430 work fine
but the pcscd crash when I send an apdu to the
Reflex USB re
Apparently, at
least with the Cyberflex, the card responds with its maximum speed and
the Gemplus driver interprets this as the requested speed.
If so, that would be a bug in the reader driver. The card remains at
default timings until the reader sends it a PPS.
By the way, the Cyberflex
Hi,
I will run tests on Monday night to determine the status of the new
Gemplus driver.
Dave
On Sat, 21 Jul 2001, Francois ARNAULT wrote:
> Hello,
>
> Did somebody tried the Gemplus serial reader NEW driver ?
> I did not succeed make it work. The pcscd daemons die whenever
> I put a card in
On Fri, 20 Jul 2001, Rich Wareham wrote:
> I think I had a similar problem when trying to make the Cambridge
> University smartcard (an IBM MFC) work with a GemCore reader. Eventually,
> after tracing through long sniffer logs of communication with a Windows
> PC, I managed to hack the existing l
On Fri, Jul 20, 2001 at 01:30:35AM +0200, Francois ARNAULT wrote:
> Hello,
>
> I'm trying to use Schlumberger Cryptoflex 8K and Cyberflex Access
> smart cards in a Gemplus 410 reader driven by pcsc-lite-0.9.3, and I
> have some trouble.
I have the same combination. I ran into some trouble wi
On Fri, 20 Jul 2001, Francois ARNAULT wrote:
> Does anyone encountered the same problem and/or can help me to solve
> it ?
I think I had a similar problem when trying to make the Cambridge
University smartcard (an IBM MFC) work with a GemCore reader. Eventually,
after tracing through long snif
Hi,
I'm assuming from this message that the Cyberflex for Linux Starter's
Kit 2.1 includes a PKCS#11 library/module? Is this correct?
Thanks,
Shelby
Sebastien abdi wrote:
>
> Le Tuesday Jul 17, 2001 at 10:45:27AM +0200, Schalamonek Henrik a écrit :
> > Hi there,
> >
> > I'm looking for a PKCS#1
Mahlzeit
On Tue, Jul 17, 2001 at 10:45:27AM +0200, Schalamonek Henrik wrote:
> I'm looking for a PKCS#11 implementation for linux that works with
> Crpyptoflex smart cards but could not find any. I would really
> appreciate if anyone could help me out. I'm also interested in other
> cards if it
Le Tuesday Jul 17, 2001 at 10:45:27AM +0200, Schalamonek Henrik a écrit :
> Hi there,
>
> I'm looking for a PKCS#11 implementation for linux that works with
> Crpyptoflex smart cards but could not find any. I would really
> appreciate if anyone could help me out. I'm also interested in other
> ca
Hello,
Erwann ABALEA wrote:
> I don't think that the current release of the PC/SC standard
> supports card readers with 'expansions', like PIN pads, screens, etc.
>
> Maybe the next version of the standard?
When OCF was split into "core" and "opt" parts, it has been decided
to move this functio
On 10 Jul 2001, Stephan Heinze wrote:
> I have a question about card readers. How can I check (via
> pcsc-lite-api) if the reader is a simple card reader or if it has a
> pinpad to supply safe pin validation?
I don't think that the current release of the PC/SC standard supports card
readers with
> "Pauley, John" wrote:
>
> All,
>
> First, sorry for the long post.
>
> My problem is that I have to authenticate the terminal with a GemPlus
> MPCOS-EMV smart card using the following algorithm (this is in the G+
> MPCOS-EMV manual):
>
[description deleted]
I'm not sure what your problem is
If you mean the CT-API man pages, you can get them
from the towitoko-2.0.4 source package from
http://www.geocities.com/cprados or from the Debian
mirror nearest to you, f.i:
http://http.us.debian.org/debian/pool/main/t/towitoko
(note that I'm not native english-speaker and there
may be imperfect
I didn't think there was a conflict at all between N and CWT/BWT. N is how
long the reader waits before sending the next byte. CWT is how long it
waits before giving up on receiving the next byte. BWT is how long it waits
before giving up on receiving the next block.
Also, I'm not getting the
: "Jim Rees" <[EMAIL PROTECTED]>
To: "Smart Muscleheads" <[EMAIL PROTECTED]>
Sent: Friday, June 29, 2001 1:47 PM
Subject: Re: MUSCLE Error using an IBM MFC in GemPlus readers.
> The Gemplus reader shouldn't wimp out just because BWT is "reserved."
The MFC docs claim it to be ISO 7816 compliant. Is there anyone who has
has success reading IBM MFC cards with a GemPlus reader?
Rich
On Fri, 29 Jun 2001, Peter Tomlinson wrote:
> >From ISO 7816-3:1997, ATR looks like:
>
> 3B Direct data convention
> EF TB1, TC1, TD1 present, 15 historical byte
Mahlzeit
On Fri, Jun 29, 2001 at 08:47:57AM -0400, Jim Rees wrote:
> The Gemplus reader shouldn't wimp out just because BWT is "reserved." My
> Todos driver does its best to talk to the card and uses defaults when the
> protocol parameters don't make sense. There are an amazing number of cards
The Gemplus reader shouldn't wimp out just because BWT is "reserved." My
Todos driver does its best to talk to the card and uses defaults when the
protocol parameters don't make sense. There are an amazing number of cards
out there that aren't strictly 7816 compliant.
Besides, isn't BWT given b
>From ISO 7816-3:1997, ATR looks like:
3B Direct data convention
EF TB1, TC1, TD1 present, 15 historical bytes
00 TB1 Vpp not used
FF TC1 Min delay between character transmissions is default value (11 etu
for T=1)
81 TD1 T=1 protocol only, TD2 is present
31 TD2 TB3 and TC3 present
FF TB3 BWI for
>From ISO 7816-3:1997, ATR looks like:
3B Direct data convention
EF TB1, TC1, TD1 present, 15 historical bytes
00 TB1 Vpp not used
FF TC1 Min delay between character transmissions is default value (11 etu
for T=1)
81 TD1 T=1 protocol only, TD2 is present
31 TD2 TB3 and TC3 present
FF TB3 BWI for
s security value
> > is
> > dubious to say the least, and this guy didn't seem to understand what
> > a
> > trust path even implied.
> >
> > Alex
> > [EMAIL PROTECTED]
> > [EMAIL PROTECTED]
> > [EMAIL PROTECTED]
> >
> > -
h a system, it's security value
> is
> dubious to say the least, and this guy didn't seem to understand what
> a
> trust path even implied.
>
> Alex
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
> - Original Message -----
> From: &q
Ok, it's offtopic here, but I don't think, it is a good idea
to use such policy. Why to protect such thing ??
A good policy is to setup a box and to have a model earning
money on services not on the boxes or the system (linux).
The user can do what ever he/she wants to do, if the user
disconfigu
When I looked in cyberflex toolkit they were
requiring xcard. The xcard that I have ( provided in the toolkit) didn't
work. I don't know the usefulness of xcard and can I get another tool with
which I can work.
I recommend you use "pay" from our web site:
http://www.citi.umich.edu/projec
Patrick Valsecchi wrote:
>
>
> I don't have to store each signature of each bin into the smartcard. I won't
> have enough RAM for that! I'll store inside each executable and library the
> signed crypto hash. The kernel will check if the crypto hash is still the same
> and the smartcard will just
Quoting [EMAIL PROTECTED]:
> On Fri, 22 Jun 2001, Jim Rees wrote:
>
> > Ok, so you have a bunch of executables and a table of pre-computed
> CRC's.
> >
> > No, you have a bunch of executables, and for each you have a crypto
> hash
> > signed with a private key.
>
> Ok.
>
> > You could sto
eheads <[EMAIL PROTECTED]>
Sent: Friday, June 22, 2001 11:17 PM
Subject: Re: MUSCLE Disk encryption and more
> On Fri, 22 Jun 2001, Jim Rees wrote:
>
> > Ok, so you have a bunch of executables and a table of pre-computed
CRC's.
> >
> > No, you have a bunch of ex
built into their
spec a system to control what programs it can run, they should have.
Peter T
Bristol UK
- Original Message -
From: "Jim Rees" <[EMAIL PROTECTED]>
To: "Smart Muscleheads" <[EMAIL PROTECTED]>
Sent: Friday, June 22, 2001 10:13 PM
Subject: Re: MUS
On Fri, 22 Jun 2001, Jim Rees wrote:
> Ok, so you have a bunch of executables and a table of pre-computed CRC's.
>
> No, you have a bunch of executables, and for each you have a crypto hash
> signed with a private key.
Ok.
> You could store the public key in the secure rom, but this guy wa
Hi,
It's still crude, but we have a paper on smartcard based secure
booting:
http://www.citi.umich.edu/techreports/
Boot up from secure ROM, and use a smartcard to make sure kernels and
application binaries are good.
--
Concentration .. Naomaru Itoi
*
Ok, so you have a bunch of executables and a table of pre-computed CRC's.
No, you have a bunch of executables, and for each you have a crypto hash
signed with a private key.
You could store the public key in the secure rom, but this guy wants to use
a smart card, presumably because he wants t
Thanks you, this is a very good recapitulation. Even better that my first
mail ;-)
Quoting Jeremy Impson <[EMAIL PROTECTED]>:
> On Fri, 22 Jun 2001 [EMAIL PROTECTED] wrote:
>
> > On Fri, 22 Jun 2001, Jim Rees wrote:
> >
> > > But if you really are concerned about "very skilled hackers" you
>
On Fri, 22 Jun 2001, Patrick Valsecchi wrote:
> I can sign the kernel, the executables and the libraries. The loader (lilo) can
> be in the securized memory of the processor. So before it loads the kernel, it
> checks the signature with the smartcard. Then I'm quit sure it's my own kernel
> th
Aren't CRC algorithms easy to reverse?
Sorry for the sloppy terminology. Obviously this has to be a cryptographic
hash, not just a crc. But I still think performance will not be a huge
issue.
dumaguete# ls -l /bsd
-rwxr-xr-x 1 rees wheel 2172784 Jan 25 16:11 /bsd
dumaguete# time md5 /bsd
On Fri, Jun 22, 2001 at 10:00:35PM +0200, Patrick Valsecchi wrote:
> The user will be able to change the code, that's not the matter, but it wont be
> able to run it on my customer's hardware. That's the point. And I don't this it
> goes against any law neither any license.
>
> I'm sure it does
The user will be able to change the code, that's not the matter, but it wont be
able to run it on my customer's hardware. That's the point. And I don't this it
goes against any law neither any license.
I'm sure it doesn't go against any GPL spirit. It's even possible that my
source will be par
On Fri, 22 Jun 2001 [EMAIL PROTECTED] wrote:
> On Fri, 22 Jun 2001, Jim Rees wrote:
>
> > But if you really are concerned about "very skilled hackers" you will need
> > significant hardware protection, like a processor with integrated boot code
> > or an epoxy potted processor and boot rom modul
I know that checking the CRC of the executable can lead to slowlyness (have to
load each page of it), but I don't think I have the choice.
This shouldn't be slow at all. You have to load the pages anyway, right? I
hope you're not thinking about sending the entire kernel to the card, that
w
Hi
Why not, but this solution is not solving my problem. This just provides
encrypted disk. My main concern, is disallowing the user to run its own
executables.
For answering peoples questions, I don't want to protect this hardware against
governements or very high budgeted crackers. My custo
On Fri, 22 Jun 2001, Jim Rees wrote:
> But if you really are concerned about "very skilled hackers" you will need
> significant hardware protection, like a processor with integrated boot code
> or an epoxy potted processor and boot rom module. Even then you won't be
> able to completely protect
I don't know about the rest of it, but a former colleague of mine worked on
a secure booting system using a smartcard. I don't see anything on his web
page about it but you could contact him directly.
http://www.citi.umich.edu/u/itoi/
But if you really are concerned about "very skilled hackers"
um you've got a lot of requirements that Linux may or may not be able to
meet. I think the biggest problem you're going to have is that if the user
has hardware access, the game is over anyway. Really, truly, and completely
over. Trusted hardware tends to combat this inability to be able to
wi
Hi,
--- Christoph Plattner <[EMAIL PROTECTED]>
wrote:
> I have spoken with Towitoko, and it seems to be a
> wrong
> card in the the package. The label on the crad
> package
> says CHIPCARD M2 (I2C EEPROM) card, and Towitoko
> says, that cards
> using PINs are CHIPCARD M2P. The M2 type does not
>
I have spoken with Towitoko, and it seems to be a wrong
card in the the package. The label on the crad package
says CHIPCARD M2 (I2C EEPROM) card, and Towitoko says, that cards
using PINs are CHIPCARD M2P. The M2 type does not use any
PIN.
The information of the "000" as default PIN would be
help
Hi,
> which includes 2 memory cards. Those two cards seems
> to be of a different type:
> - 2Kbit I2C EEPROM Card (256 Byte, R/W)
> seems to be a 2-wire card
> (icc->type = 2)
If it's I2C, then it isn't 2-wire. If the Towitoko
driver assigns '2' to the ICC type then it migth be an
2-wire c
On Mon, 18 Jun 2001, David Corcoran wrote:
> -- Forwarded message --
> Date: Sun, 17 Jun 2001 02:14:01 +0200
> From: Christoph Plattner <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: New to list, problems with PIN code !
>
> Hello SmartCard Linux hackers
Resignation? are you resigning from slb? why? be more specific please. And general
ettiquet is a signature thats shorter than
that the message.
Thanks,
William Tiemann
On Thu, Jun 14, 2001 at 04:39:28AM -0500, Neville Pattinson wrote:
> resignation
> *
From the last sun blade 100 I oppened it was plugged into one of the serial ports I
thought. The smart card reader is some
SCM Microsystems product, I forget witch.
Billy
PGP signature
Hello,
> Very interesting, but the text from Sun is not at all clear. If the smart
> card really is connected [directly] to the I2C interface, this reader will
> only accept I2C interface memory cards.
>
> But because I2C is not 7816 compliant, one would expect that the reader
> module has a 781
Very interesting, but the text from Sun is not at all clear. If the smart
card really is connected [directly] to the I2C interface, this reader will
only accept I2C interface memory cards.
But because I2C is not 7816 compliant, one would expect that the reader
module has a 7816-compliant slot, so
On 7 June 2001 Carlos Prados wrote
> Re: MUSCLE Work Waiting Time question
>
> Hi,
>
> > It seems, therefore, that changing the value of Di
> > in the ATR does not
> > change the value of the wwt, but changing the value
> > of Fi does. Is this what
> >
--
> Von: Erwann ABALEA [mailto:[EMAIL PROTECTED]]
> Gesendet am: Freitag, 8. Juni 2001 12:07
> An: [EMAIL PROTECTED]
> Betreff: Re: MUSCLE Linux Login with RSA SmartCards
>
> >You can design your application so that whenever a signature (or
> >decryption) operation is to be p
On Fri, 8 Jun 2001, Dr S N Henson wrote:
> Carlos Prados wrote:
> >
> >
> > Again, I would pay more athention to local security.
> > Why is the file /tmp/.pcscrx world writtable? isn't
> > this a security hole?
> >
>
> On the subject of security...
>
> As may be apparent I've only just got my set
On Thu, 7 Jun 2001, Carlos Prados wrote:
> Hi,
>
> --- David Corcoran <[EMAIL PROTECTED]> wrote:
> > Definitely. The interface exported must be a subset
> > of the
> > available functionality or else someone could write
> > a worm which does a
> > Verify Key function incorrectly and blocks cards
Carlos Prados wrote:
>
>
> Again, I would pay more athention to local security.
> Why is the file /tmp/.pcscrx world writtable? isn't
> this a security hole?
>
On the subject of security...
As may be apparent I've only just got my setup working and I've not
examined things in any detail. I di
Hi,
Thanks Peter for your great explanation.
> 7816-3:1997 section 8.2 on work waiting time:
>
> wwt = 960 * WI * (Fi / f)
>
This is exactly what I get doning variable
substitution and symplification in the formula that
comes in ISO 7816-3: 1992.
[snip]
> It seems, therefore, that changing
Hi,
--- David Corcoran <[EMAIL PROTECTED]> wrote:
> Definitely. The interface exported must be a subset
> of the
> available functionality or else someone could write
> a worm which does a
> Verify Key function incorrectly and blocks cards
> where services are
> available.
Even worst. If you
Definitely. The interface exported must be a subset of the
available functionality or else someone could write a worm which does a
Verify Key function incorrectly and blocks cards where services are
available. A signature function must be carefully exported and
authenticated to so it does not pe
Hi,
I think the PCSC is good enough if it enables access
to the local smartcard to local proceses, and
verifies that the user has UNIX permission to use the
smartcard reader (for instance if /tmp/.pcsctx anc
/tmp/.pcscrx are accessibe to the user).
For remote authentication, a client/server app
David Corcoran wrote:
>
> Hi,
>
> Sorry for the confusion, when I said RPC like service I meant a service
> that uses GSS-API or something tunnelled under ssh. Keep in mind this is
> a separate service that acts as an application to PC/SC - I would never
> make this part of PC/SC and it would n
For accessing remote computers (which the original query was about)
something like ssh or secure telnet using smart card based keys
for authentication would be more appropriate.
Of course what you really want is for the session to be secure all the way
to the card, not just to the terminal.
Hi,
Sorry for the confusion, when I said RPC like service I meant a service
that uses GSS-API or something tunnelled under ssh. Keep in mind this is
a separate service that acts as an application to PC/SC - I would never
make this part of PC/SC and it would never be Sun RPC.
I do need some sor
Hello,
On Wed, 6 Jun 2001, Dr S N Henson wrote:
> > I don't think using RPC is a good idea.
> > You use a smartcard to provide security in a unsecure environment.
> > I don't want to send my PIN code in clear over RPC. You need to have
> > authentication, integrity and confidentiality of your n
Ludovic Rousseau wrote:
>
>
> I don't think using RPC is a good idea.
> You use a smartcard to provide security in a unsecure environment.
> I don't want to send my PIN code in clear over RPC. You need to have
> authentication, integrity and confidentiality of your networks
> communications.
>
On Wed, 6 Jun 2001, Ludovic Rousseau wrote:
> On Mon, Jun 04, 2001 at 12:57:20PM -0700, David Corcoran wrote:
> > Hello,
> >
> > You can't use pcsc-lite-0.9.1 for remote use of the resource manager. I
> > wanted to create the core package as local only. I'm working on an RPC
> > like service th
On Mon, Jun 04, 2001 at 12:57:20PM -0700, David Corcoran wrote:
> Hello,
>
> You can't use pcsc-lite-0.9.1 for remote use of the resource manager. I
> wanted to create the core package as local only. I'm working on an RPC
> like service that sits atop the local service which will export the PC/
On Tue, Jun 05, 2001 at 08:44:42PM +0100, Dr S N Henson wrote:
> David Corcoran wrote:
> > Hi,
> > Try removing bundleparser.c and doing the ./configure --enable-usb
> > and everything over again.
> That did the trick. I still get a few kernel warning messages when I
> plug the device in but I
Hello all...
Now I have yet ANOTHER twist to all this...
On Tue, Jun 05, 2001 at 08:44:42PM +0100, Dr S N Henson wrote:
> David Corcoran wrote:
> >
> > Hi,
> >
> > Try removing bundleparser.c and doing the ./configure --enable-usb
> > and everything over again.
> >
> That did the tri
David Corcoran wrote:
>
> Hi,
>
> Try removing bundleparser.c and doing the ./configure --enable-usb
> and everything over again.
>
That did the trick. I still get a few kernel warning messages when I
plug the device in but I can now access the reader, thanks.
Steve.
--
Dr Stephen N. Henson.
Jean-Luc GIRAUD wrote:
>
>
> >
> > I'm compiling MUSCLE 0.9.1 and the GemPC430 driver from source. There
> > are a few problems with 'make install' in MUSCLE, at least on my setup:
> > for example it installs reader.conf in /usr/local/etc but expects to
> > find it in /etc and it doesn't seem to
Jean-Luc GIRAUD wrote:
>
> Dr S N Henson wrote:
> >
> > I suspect the answer is 'none of the above' :-)
>
> Yes and no :-) (see below).
>
> >
> > I'm compiling MUSCLE 0.9.1 and the GemPC430 driver from source. There
> > are a few problems with 'make install' in MUSCLE, at least on my setup:
>
Dr S N Henson wrote:
>
> I suspect the answer is 'none of the above' :-)
Yes and no :-) (see below).
>
> I'm compiling MUSCLE 0.9.1 and the GemPC430 driver from source. There
> are a few problems with 'make install' in MUSCLE, at least on my setup:
> for example it installs reader.conf in /usr
Jean-Luc GIRAUD wrote:
>
> Dr S N Henson wrote:
> >
> > I've been testing out MUSCLE and some related software with some gemplus
> > readers, all with RHL 6.1 2.2.12 kernel and RHL7.0 2.2.16 with
> > backported USB and 2.4.5.
> >
> > I haven't got the USB reader GemPC430 to work though. All I get
Dr S N Henson wrote:
>
> I've been testing out MUSCLE and some related software with some gemplus
> readers, all with RHL 6.1 2.2.12 kernel and RHL7.0 2.2.16 with
> backported USB and 2.4.5.
>
> I haven't got the USB reader GemPC430 to work though. All I get when I
> plug the reader in is a mess
Hello,
You can't use pcsc-lite-0.9.1 for remote use of the resource manager. I
wanted to create the core package as local only. I'm working on an RPC
like service that sits atop the local service which will export the PC/SC
interface . To the apps it will be identical to the older versions
1 - 100 of 920 matches
Mail list logo
