Re: [Muscle] SmartCard sign number

[Sébastien Lorquet]

Hello

there is no "generic" way to talk to a smart card.

You need to either

-get technical documentation for your card
-reverse the card protocol by looking at the exchanges between the card 
and the application. That may not be sufficient if the card uses a 
dynamic authentication mechanism.


before allowing the use of a private key to sign data, most card 
requires a pin presentation or mutual authentication.


Best regards
Sebastien Lorquet

Le 16/12/2013 22:11, Raul Rosetto Munoz a écrit :

Hello Douglas,

I try many foruns, and all the time I get Unsupported card:

opensc-tool --reader 0 --name
Unsupported card

Do you know how to find the real type of my card?

I try pcsc_scan

But I didnt find some name that I can compare with this list:
https://github.com/OpenSC/OpenSC/wiki/Supported-hardware-%28smart-cards-and-USB-tokens%29

pcsc_scan
PC/SC device scanner
V 1.4.18 (c) 2001-2011, Ludovic Rousseau >

Compiled with PC/SC lite version: 1.7.4
Using reader plug'n play mechanism
Scanning present readers...
0: ACS ACR 38U-CCID 00 00

Mon Dec 16 19:05:21 2013
Reader 0: ACS ACR 38U-CCID 00 00
  Card state: Card inserted,
  ATR: 3B 7F 18 00 00 80 59 49 44 65 61 59 49 44 65 61 6C 5F 31 2E

ATR: 3B 7F 18 00 00 80 59 49 44 65 61 59 49 44 65 61 6C 5F 31 2E
+ TS = 3B --> Direct Convention
+ T0 = 7F, Y(1): 0111, K: 15 (historical bytes)
  TA(1) = 18 --> Fi=372, Di=12, 31 cycles/ETU
129032 bits/s at 4 MHz, fMax for Fi = 5 MHz => 161290 bits/s
  TB(1) = 00 --> VPP is not electrically connected
  TC(1) = 00 --> Extra guard time: 0
+ Historical bytes: 80 59 49 44 65 61 59 49 44 65 61 6C 5F 31 2E
  Category indicator byte: 80 (compact TLV data object)
Tag: 5, len: 9 (card issuer's data)
  Card issuer data: 49 44 65 61 59 49 44 65 61
Tag: 6, len: C (pre-issuing data)
  Data: 5F 31 2E

Possibly identified card (using /home/raul/.smartcard_list.txt):
3B 7F 18 00 00 80 59 49 44 65 61 59 49 44 65 61 6C 5F 31 2E
e-CNPJ issued by Fenacon (eID)
http://www.fenacon.org.br

Thanks For All Help.





On Mon, Dec 16, 2013 at 5:28 PM, Douglas E. Engert > wrote:




On 12/16/2013 11:46 AM, Raul Rosetto Munoz wrote:

Hello,

That's my first time that I really need to understand how the
smart card works.

First of all I have with me a Brazilian Digital Document
called e-CPF, this card is an Version V2 with 2048 bits and is
part of IPC-BRAZIL.

Every thing start because I need to sign my device serial
number with my smart card, in the documentation that I need to
follow just say that I need sign a number like  "290953052"
and after sign I
need to get an data string in base64, followed the PKCS #1
version 1.5.

My First question, there is an chance to outsource the private
key inside the smart card?


No. That is the point of a smart card, the private key can not be
read.
It can only be used for decryption or signing. (The public key in
a certificate
is used for encryption or verifying signatures.)
(The issuer of the card may be able to read it, but not ordinary
users.)



I asked that because if I get the private key I can do that
using openssl.


You might be able  to use OpenSSL, if the card  has an openssl
engine or
the card has a PKCS#11 library. (OpenSC has an openssl_engine for
use with PKCS#11.)
OpenSC also has PKCS#11 for some cards. Not clear if the e-cnpj is
supported or not.
People have asked in the past.

https://github.com/OpenSC/OpenSC/wiki


https://github.com/OpenSC/OpenSC/wiki/Supported-hardware-%28smart-cards-and-USB-tokens%29

Google for: opensc smart card e-cnpj



But if this happen I cant see an reason for smart cards work well.

Im sorry to ask this basics questions but I realy got
difficult to find informations.

Thanks For All Help!

--
*Raul Rosetto Muñoz*


___
Muscle mailing list
Muscle@lists.musclecard.com 
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com


-- 


 Douglas E. Engert  mailto:deeng...@anl.gov>>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439
 (630) 252-5444

___
Muscle mailing list
Muscle@lists.musclecard.com 
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com




--
*Raul Rosetto Muñoz*


___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com


___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.mu

Re: [Muscle] ACR122U response frames contain wrong sequence numbers

[Sébastien Lorquet]

Hello

for your information, no ACR122 reader ever worked OK with any card I 
tested (types A and B).

Both under linux and windows.
At this time I could not investigate deeply, so we changed the readers 
and never got any problems with the same cards :)


So I don't exactly know the cause, but you're not alone having problems 
with this reader :)


Sebastien Lorquet


Le 18/08/2013 12:05, Eugene Crosser a écrit :

A little followup:

On 08/16/2013 03:15 PM, Eugene Crosser wrote:


I've got ACR122U reader and noticed that when a CCID frame sent from the
host to the token is larger than 64 bytes (APDU larger than 54 bytes),

 of the response frame
 -v---

the sequence number (byte at +6 in the CCID frame) is one less than the
sequence number of the sent frame.

  ...


I must note that openpgp functionality works over this reader (maybe
they never use APDUs bigger than 54 bytes?).

I checked and indeed, they do not:

$ grep CmdXfrBlockTPDU /var/tmp/gpg-ccid-log.txt
0013 commands.c:1619:CmdXfrBlockTPDU_T0() T=0: 11 bytes
0006 commands.c:1619:CmdXfrBlockTPDU_T0() T=0: 5 bytes
0005 commands.c:1619:CmdXfrBlockTPDU_T0() T=0: 5 bytes
0005 commands.c:1619:CmdXfrBlockTPDU_T0() T=0: 5 bytes
0006 commands.c:1619:CmdXfrBlockTPDU_T0() T=0: 5 bytes
0006 commands.c:1619:CmdXfrBlockTPDU_T0() T=0: 5 bytes
0007 commands.c:1619:CmdXfrBlockTPDU_T0() T=0: 5 bytes
0006 commands.c:1619:CmdXfrBlockTPDU_T0() T=0: 5 bytes
0006 commands.c:1619:CmdXfrBlockTPDU_T0() T=0: 5 bytes
0002 commands.c:1619:CmdXfrBlockTPDU_T0() T=0: 5 bytes
0007 commands.c:1619:CmdXfrBlockTPDU_T0() T=0: 5 bytes
0006 commands.c:1619:CmdXfrBlockTPDU_T0() T=0: 11 bytes
0006 commands.c:1619:CmdXfrBlockTPDU_T0() T=0: 41 bytes
0005 commands.c:1619:CmdXfrBlockTPDU_T0() T=0: 5 bytes

This is going to be a real problem if/when yubikey's library gets the
functionality of reaching the key over PC/SC. In challenge-response mode, they
are sending frames longer than 54 bytes, and it works over the yubikey's
built-in CCID implementation, but not over the ACR reader.

Anybody?

Regards,

Eugene



___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com


___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com

Re: [Muscle] RES: Parallel Process with readers - pcsc-lite

[Sébastien Lorquet]

Le 03/07/2013 21:45, Ludovic Rousseau a écrit :

2013/7/3 MURILO COSTA :

I thought that maybe can be a Java problem, do you know some software to do 
this kind of test (parallelism) ? I'll check if pcsc-tools can do that...

I guess it is a javax.smartcardio "limitation".

You need to create one context per reader using SCardEstablishContext.
I bet the Java wrapper creates only one context for all the readers.
In pcsc-lite the context is associated to a mutex. So all your
commands will block on the same mutex even if they use different
readers.
I don't know if is it easy or even possible to avoid this Java wrapper
"feature".

Hello

One possible method would be to use JNA to talk directly to 
libpcsclite.so (or winscard.dll on windows)

This would allow you to use the pcsclite C API from java.

Best regards
Sebastien

___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com

Re: [Muscle] Is there a way to know if a reader is contactless?

[Sébastien Lorquet]

do you really need the "contactless" part of the information?

if I had to do that, I would proceed in 2 steps

-find readers that contain a card (already doable)
-send a specific command that is recognized by the card application, 
typically it will be a select with an AID

-same idea is usable to find the reader that contains the sam.

and that's all, you do not have contacts or radio waves in the equation.

what about that?

regards
Sebastien

Le 06/06/2012 22:01, s.ferey a écrit :

Le 18/05/2012 13:12, Ludovic Rousseau a écrit :

2012/5/18 helpcrypto helpcrypto:


Is there a way to know if a reader is contactless?


Why do you need to know if the reader is contactless or not?


(late answser sorry)

knowing if a reader is contactless or not is very important (not to 
say critical) in a lot of cases and especially for application used by 
"normal users" (i mean not PC/SC - and so on - expert).


applications, such as ID (passport, eDL, ...) readers, would have to 
be able to auto-configurate (to choose the right reader) when several 
readers are present (and a lot of "combo-readers" do include several 
contact and/or contactless heads, one (or 2) for its main purpose(s), 
other for SAM).


a standardized function to get this information will save a lot of 
time and avoid tons of bad assumption made on names.


Sylvain.
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle


___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] PC/SC workgroup, November 2011 meeting

[Sébastien Lorquet]

My two cents:

In two years of work with javacards I never saw this status word.  
Invalid cap files tend to produce 6A80s with the cards I have around.  
My guess is that this is a custom SW for this very card emulator  
(jcwde?) rather than a standard one.


Some javacards also reply some strange SWs (like 6601 etc) when they  
encounter runtime exceptions. The only spec I found for this is the  
card datasheet :-)


Regards
Sebastien

Ludovic Rousseau  a écrit :


2011/10/10 Martin Paljak :

Meaningful questions/suggestions (some probably reflect my bad
homework on the subject, as they might not be in the scope of this
workgroup):
 - Work out firewalling and settle on a specific SW for "command
firewalled" status (intersection between CCID/firmware level and
PC/SC)


The Status Word 0x6404 as proposed is already used by JavaCard in [1]:
0x6404 Invalid CAP file major number.

Maybe that is just because 0x64xx is not defined by ISO 7816-4 so many
"standard" use values from this range.
I don't think that will be a problem, unless you try to install CAP
file using a VERIFY command and a pin pad reader.

Bye

[1]  
http://www.cs.ru.nl/~tews/jcdocs/kit-user-2.2.1/cJDKinstaller.html#wp14869


--
 Dr. Ludovic Rousseau

___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle




___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] ERROR: proto-t1.c:479:t1_transceive() CT sent S-block with wtx=1 -MEANING?

[Sébastien Lorquet]

Hi

I don't know the consequences but here are the facts:

T=1 can be seen as a state machine

When a command is sent an APDU in an I block, S(wtx) is a reply from  
the card that requires more time to complete the command.
At startup, the card timeout is negotiated and if the card has not  
completed the required computations within this timeout, it has to  
reply this block.


the reader will reply with the same block, and the SWTX exchanges will  
continue until the card has terminated the processing. When it's done,  
the card will reply with the R-APDU in a final I-block.


Regards
Sebastien

Umberto Rustichelli aka Ubi  a écrit :


Dear all,

I'm not an expert of smart card readers nor of APDU commands but I'm  
developing software that uses a mix of PKCS#11 modules since some  
time.
I gave a look to proto-t1.c but for sure you cannot guess the real  
meaning of the error without sufficient background.


Using a new smart card reader, I'm experiencing some slowdown in  
communication with the smart cards and I see this error in the logs:


proto-t1.c:479:t1_transceive() CT sent S-block with wtx=1

As the operations are completed anyway, so I guess this is rather a  
sort of warning, but what does it mean (in human terms)?
Is there some issue in the communication and the driver must cope  
with it by resending data (hence the slight slowdown)?


I'm currently forced to use old versions of the software involved  
(see later), so the second question is: should I care about the  
error? What could the consequenses be?


DETAILS:

system: Red Hat ES 5.4
SW versions: ccid 1.3.10, pcsc-lite-1.5.3
+ [opensc-0.11.8.tar.gz] + [pkcs11-helper-1.07.tar.bz2] +  
proprietary PKCS#11 module libbit4ipki.so for InCard smart cards  
(version not available)


The smart card readers:

Bus 001 Device 009: ID 072f:90cc Advanced Card Systems, Ltd ACR38  
SmartCard Reader
Bus 001 Device 007: ID 072f:90cc Advanced Card Systems, Ltd ACR38  
SmartCard Reader



___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle




___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [opensc-devel] [Muscle] Failed transactions with a card in some readers with INS in 9X/6X range

[Sébastien Lorquet]

Hi,

That makes sense, since the ACK reply would me mistaken for a status byte.

Moreover, if your card expects incoming data for this bogus command  
(from host to card) then it will timeout since at this moment, the  
reader will also wait, for SW2. If the command has outgoing data (from  
card to host) then it will be lost right after the first byte (read as  
SW2).


Regards
Sebastien

Ludovic Rousseau  a écrit :


2011/8/25 Martin Paljak :

Hello,

On Thu, Aug 25, 2011 at 14:47, Ludovic Rousseau
 wrote:

The realy strange situation is that you can have a working T=0
card+reader with these "invalid" INS bytes.

In your INS exploration program just skip 6X and 9X INS values.


Thanks for the explanation!

For the fun of it I think I'll do the opposite instead:
 - make the protocol dependant probing more explicit (for several
stupid reasons I'm using T=0 only currently, as this is the only
"supported algorithm" for Estonian eID cards)
 - DO probe the forbidden ranges (not by default though)
 - see what happens with different card+reader combos :)

Would it make sense to debug on USB level what is happening at
different situations, to maybe make the CCID driver more robust (==
predictable outcome with different readers)?


You can activate the communication logs in the CCID driver.
But you will not see much more than at the PC/SC level. The error
comes from the reader (I guess), not the CCID driver.

The best would be to log at the card/reader interface. I guess the
CardMan reader do not even try to send the "bogus" APDU to the card
and just reject it.

bye

--
 Dr. Ludovic Rousseau

___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle




___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] How to identify a java card?

[Sébastien Lorquet]

Hi,

Not knowing anything about the card keys, I'd not try an authentication.
A SELECT ISD (00A4 0400 00) can be issued even if the ISD AID is not known.
If the answer is not matchable to anything defined in the GP card spec, then
a GET DATA will be able to read the current keys identifiers: 00CA 00E0 00.
Objects 00C1 (sequence counter) and 00CF (CSN IIRC) are also often present
in javacards.

Regards
Sebastien

On Sat, Aug 13, 2011 at 7:53 AM, Martin Paljak wrote:

> Hello,
>
>
> You could also use GPJ [1] or GPShell to see if you can list applications
>
> [1] http://www.opensc-project.org/opensc/wiki/JavaCard#Loadingtheapplet
>
> On Sat, Aug 13, 2011 at 01:51, Michael StJohns 
> wrote:
> > Parsing the ATR, this might be a YPSID S3 smart card.(The historical
> bytes encode to "YPSID03" with a card status of "0x7f").
> >
> > If its either an S2 or S3 ypsID it is a javacard.
> >
> > Mike
> >
> >
> >
> > At 03:03 PM 8/12/2011, Marcelo Aloisio da Silva wrote:
> >>Hi,
> >>
> >>Please, I need help. I have a card with no description. It is completely
> white.
> >>I have got the ATR
> >>
> >>3B 7D 14 00 02 80 57 59 50 53 49 44 30 33 83 7F 90 00
> >>
> >>I would like to know if it is a java card?
> >>
> >>Thanks in advance.
> >>___
> >>Muscle mailing list
> >>Muscle@lists.musclecard.com
> >>http://lists.drizzle.com/mailman/listinfo/muscle
> >
> >
> > ___
> > Muscle mailing list
> > Muscle@lists.musclecard.com
> > http://lists.drizzle.com/mailman/listinfo/muscle
> >
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] GlobalPlatform Library & GPShell documentation now online

[Sébastien Lorquet]

>
> There are two issues that I find interesting, but I'm not sure
> if you want to put information about these in the wiki:
> a) where can people get javacard cards at reasonable price?
> b) what about the standards of the javacards, e.g. JCOP?
>   as far as I know there is some functionality you can't access
>   once you get the finished card (e.g. change ATR, UID etc.).
>   IIRC the documentation is closed under NDA, but if anyone
>   found a copy available on the net, that would be interesting...
>

You're talking about not initialized cards. First, it's near impossible to
find cards in this state, so the doc would be useless, and second, the
commands available in these modes are generally secret and not even
available with NDAs outside the manufacturer. In these initialization
states, cards are not javacards yet, they are totally proprietary objects,
as you might already know.

Aditionnaly, please avoid talking about "JCOP" when referring to Java Card,
JCOP is a (not so good for all applications) NXP product, and fortunately,
there are bunch of other manufacturers and cards, such as the Oberthur
Cosmo, the Gemalto GXP/GCX and some others at G&D, for example.

All of these cards follow a single standard, namely Java Card.

Sebastien
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] reading sims

[Sébastien Lorquet]

commands are in the SIM ETSI spec, I think it's TS11.11
>From there you can find crossrefs to the STK documentations.

On Tue, Feb 22, 2011 at 3:39 PM, Scott Weisman  wrote:

> Are these commands documented somewhere?
>
> On Tue, Feb 22, 2011 at 4:29 PM, Sébastien Lorquet wrote:
>
>> Hi,
>>
>> yes, but not out of the box.
>>
>> pcsc provides an API that will allow you to do that. However you have to
>> know the exact commands that shall be sent to the card.
>>
>> regards
>>
>> Sebastien
>>
>> On Tue, Feb 22, 2011 at 3:13 PM, Scott Weisman wrote:
>>
>>>  I am interested in reading SIMs in general and finding out about SIM
>>> toolkit apps in particular. Can the PC/SC codebase obtain this kind of info?
>>>
>>> ___
>>> Muscle mailing list
>>> Muscle@lists.musclecard.com
>>> http://lists.drizzle.com/mailman/listinfo/muscle
>>>
>>>
>>
>> ___
>> Muscle mailing list
>> Muscle@lists.musclecard.com
>> http://lists.drizzle.com/mailman/listinfo/muscle
>>
>>
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] reading sims

[Sébastien Lorquet]

Okay you're trying to understand your locked SIM. I replied to someone in
your thread on the osmocombb mailing list.

You won't be able to list the sim toolkit applets easily. That would require
knowing the global platform keys for the SIM Issuer Security Domain, that
are probably in a HSM inside some secure server whiteroom.

But, as suggested by Harald Welte, you could spy the dialogue between the
SIM and the phone, that would provide lots of information, and possibly a
solution.

See here: http://bb.osmocom.org/trac/wiki/SIMtrace

Sebastien


On Tue, Feb 22, 2011 at 3:29 PM, Sébastien Lorquet wrote:

> Hi,
>
> yes, but not out of the box.
>
> pcsc provides an API that will allow you to do that. However you have to
> know the exact commands that shall be sent to the card.
>
> regards
>
> Sebastien
>
>  On Tue, Feb 22, 2011 at 3:13 PM, Scott Weisman wrote:
>
>>  I am interested in reading SIMs in general and finding out about SIM
>> toolkit apps in particular. Can the PC/SC codebase obtain this kind of info?
>>
>> ___
>> Muscle mailing list
>> Muscle@lists.musclecard.com
>> http://lists.drizzle.com/mailman/listinfo/muscle
>>
>>
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] reading sims

[Sébastien Lorquet]

Hi,

yes, but not out of the box.

pcsc provides an API that will allow you to do that. However you have to
know the exact commands that shall be sent to the card.

regards

Sebastien

On Tue, Feb 22, 2011 at 3:13 PM, Scott Weisman  wrote:

> I am interested in reading SIMs in general and finding out about SIM
> toolkit apps in particular. Can the PC/SC codebase obtain this kind of info?
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Access to multiple contactless cards using PCSC-Lite

[Sébastien Lorquet]

ds advertising CID support shall work as expected),
>> but also availability on cards, and availability via pcsc/ccid.
>>
>> This is a possible, but low level feature, and far from supported by all
>> cards and readers.
>>
>> Sebastien
>>
>> On Thu, Jan 27, 2011 at 11:41 PM, s.ferey > <mailto:s.fe...@wanadoo.fr>> wrote:
>>
>> Hi,
>>
>> To be honest I hesitated a bit before being so affirmative :)
>>
>> You are right, "if the card supports CID" and reader firmware /
>> middleware let you manage the full frame building, you should be able to
>> talk to different chips (identified by their CID) w/o halting them.
>>
>> But (based on experience) some chips do not support CID (or NAD) and
>> reader SDKs won't always let you manage the CID (ie the targeted chip).
>> So my advice was actually: try to avoid it because of the leak of
>> reliability.
>>
>> Sylvain.
>>
>>
>> Le 27/01/2011 15:31, Sébastien Lorquet a écrit :
>>
>> Hi,
>>
>> are you sure the CID function is not usable to keep a live context in
>> more than one card (in the same field of course)? Only the card with the
>> targeted CID value will reply to a command that contains this CID. At
>> least, IIUC... it means that with CID support, you don't need to halt
>> the cards you're not talking to...
>>
>> Sebastien
>>
>> On Thu, Jan 27, 2011 at 2:57 PM, s.ferey > <mailto:s.fe...@wanadoo.fr>
>>
>> <mailto:s.fe...@wanadoo.fr <mailto:s.fe...@wanadoo.fr>>> wrote:
>>
>> Hi,
>>
>> As Ludovic yet answered you can manage that sequence (ie card
>> requests, tag/chip enumeration, selection of one of them) yourself
>> as long as some API give you access to such functions; but for most
>> of readers the PC/SC driver is opaque to these operations -- in
>> short PC/SC manages APDU exchanges as per ISO 7816/14443-4 but hide
>> details of protocol stack as per ISO 7816/14443-3; or other way to
>> explain the reader firmware implements 14443-3 while the reader
>> driver implements 14443-4 with PC/SC syntax.
>>
>> That said, some readers manufacturer provide proprietary API
>> offering direct access to the protocol - this includes (and is not
>> limited to) Integrated Engineering (SmartID), ID3 semiconductors
>> (CL1356), Pro-Active (SpringCard), certainly also OmniKey or DUALi
>> that offers a valuable SDK.
>>
>> Last point, your sequence: "Select one of them and read it; Select
>> another and read it" is valid but do not expect to read several
>> chips simultaneously (it's certainly not required); indeed some
>> several chips are in the field the reader shall "select" one and
>> "halt" the other ones, from the chip point of view the "halt" is
>> (more or less) a soft reset (it will keep its UID but will lose its
>> context) and thus it is not possible to suspend and then resume the
>> exchange of APDUs.
>>
>> Sylvain.
>>
>>
>> ___
>> Muscle mailing list
>> Muscle@lists.musclecard.com <mailto:Muscle@lists.musclecard.com>
>> http://lists.drizzle.com/mailman/listinfo/muscle
>>
>>
>>
>> ___
>> Muscle mailing list
>> Muscle@lists.musclecard.com
>> http://lists.drizzle.com/mailman/listinfo/muscle
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>

___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Access to multiple contactless cards using PCSC-Lite

[Sébastien Lorquet]

Hi,

I sincerely can't think of a real-world, largely deployable one.

I'm just aware of a specific demo where two cards in the same fields
exchanged value.
I didn't even see the demo, a colleague described it to me.

Given the relatively small reading distance (5 cm) of a normal 13.56 MHz
reader, reading more than one card at once does not really makes sense.

Moreover, I can think of lots of technical problems with such a reader, for
example field strength problems.

Regards

Sebastien

On Fri, Jan 28, 2011 at 1:50 PM, Alexei Soloview <
alexei.solov...@intech.natm.ru> wrote:

>  Hello, Sebastien!
>
>
>
> I’m working in reader’s manufacturer company J
>
> At this time I try to build a list of requirements to upgrading of
> functionality of driver to our RFID-reader.
>
>
>
> At this time we think that simple consecutive reading of all present chips
> in the field are enough.
>
> Do you know use cases where reader should work with more than one card and
> capability of consecutive reading is not enough(for example, use case with
> reading first card, reading second card, processing data on terminal,
> writing something on first card)?
>
>
>
> Sincerelly, Alexei.
>
>
>
> *From:* muscle-boun...@lists.musclecard.com [mailto:
> muscle-boun...@lists.musclecard.com] *On Behalf Of *Sebastien Lorquet
> *Sent:* Friday, January 28, 2011 12:04 PM
> *To:* MUSCLE
>
> *Subject:* Re: [Muscle] Access to multiple contactless cards using
> PCSC-Lite
>
>
>
> I was affirmative because I'm working in a contactless card company ;-)
>
>
> Apart from that, I'm totally OK with your advice: avoid it, because of
> reliability (but cards advertising CID support shall work as expected), but
> also availability on cards, and availability via pcsc/ccid.
>
> This is a possible, but low level feature, and far from supported by all
> cards and readers.
>
> Sebastien
>
> On Thu, Jan 27, 2011 at 11:41 PM, s.ferey  wrote:
>
> Hi,
>
> To be honest I hesitated a bit before being so affirmative :)
>
> You are right, "if the card supports CID" and reader firmware / middleware
> let you manage the full frame building, you should be able to talk to
> different chips (identified by their CID) w/o halting them.
>
> But (based on experience) some chips do not support CID (or NAD) and reader
> SDKs won't always let you manage the CID (ie the targeted chip).
> So my advice was actually: try to avoid it because of the leak of
> reliability.
>
> Sylvain.
>
>
> Le 27/01/2011 15:31, Sébastien Lorquet a écrit :
>
> Hi,
>
> are you sure the CID function is not usable to keep a live context in
> more than one card (in the same field of course)? Only the card with the
> targeted CID value will reply to a command that contains this CID. At
> least, IIUC... it means that with CID support, you don't need to halt
> the cards you're not talking to...
>
> Sebastien
>
> On Thu, Jan 27, 2011 at 2:57 PM, s.ferey 
> <mailto:s.fe...@wanadoo.fr>> wrote:
>
>Hi,
>
>As Ludovic yet answered you can manage that sequence (ie card
>requests, tag/chip enumeration, selection of one of them) yourself
>as long as some API give you access to such functions; but for most
>of readers the PC/SC driver is  opaque to these operations -- in
>short PC/SC manages APDU exchanges as per ISO 7816/14443-4 but hide
>details of protocol stack as per ISO 7816/14443-3; or other way to
>explain the reader firmware implements 14443-3 while the reader
>driver implements 14443-4 with PC/SC syntax.
>
>That said, some readers manufacturer provide proprietary API
>offering direct access to the protocol - this includes (and is not
>limited to) Integrated Engineering (SmartID), ID3 semiconductors
>(CL1356), Pro-Active (SpringCard), certainly also OmniKey or DUALi
>that offers a valuable SDK.
>
>Last point, your sequence: "Select one of them and read it; Select
>another and read it" is valid but do not expect to read several
>chips simultaneously (it's certainly not required); indeed some
>several chips are in the field the reader shall "select" one and
>"halt" the other ones, from the chip point of view the "halt" is
>(more or less) a soft reset (it will keep its UID but will lose its
>context) and thus it is not possible to suspend and then resume the
>exchange of APDUs.
>
>Sylvain.
>
>
>
>
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Access to multiple contactless cards using PCSC-Lite

[Sébastien Lorquet]

I was affirmative because I'm working in a contactless card company ;-)

Apart from that, I'm totally OK with your advice: avoid it, because of
reliability (but cards advertising CID support shall work as expected), but
also availability on cards, and availability via pcsc/ccid.

This is a possible, but low level feature, and far from supported by all
cards and readers.

Sebastien

On Thu, Jan 27, 2011 at 11:41 PM, s.ferey  wrote:

> Hi,
>
> To be honest I hesitated a bit before being so affirmative :)
>
> You are right, "if the card supports CID" and reader firmware / middleware
> let you manage the full frame building, you should be able to talk to
> different chips (identified by their CID) w/o halting them.
>
> But (based on experience) some chips do not support CID (or NAD) and reader
> SDKs won't always let you manage the CID (ie the targeted chip).
> So my advice was actually: try to avoid it because of the leak of
> reliability.
>
> Sylvain.
>
>
> Le 27/01/2011 15:31, Sébastien Lorquet a écrit :
>
>> Hi,
>>
>> are you sure the CID function is not usable to keep a live context in
>> more than one card (in the same field of course)? Only the card with the
>> targeted CID value will reply to a command that contains this CID. At
>> least, IIUC... it means that with CID support, you don't need to halt
>> the cards you're not talking to...
>>
>> Sebastien
>>
>> On Thu, Jan 27, 2011 at 2:57 PM, s.ferey > <mailto:s.fe...@wanadoo.fr>> wrote:
>>
>>Hi,
>>
>>As Ludovic yet answered you can manage that sequence (ie card
>>requests, tag/chip enumeration, selection of one of them) yourself
>>as long as some API give you access to such functions; but for most
>>of readers the PC/SC driver is  opaque to these operations -- in
>>short PC/SC manages APDU exchanges as per ISO 7816/14443-4 but hide
>>details of protocol stack as per ISO 7816/14443-3; or other way to
>>explain the reader firmware implements 14443-3 while the reader
>>driver implements 14443-4 with PC/SC syntax.
>>
>>That said, some readers manufacturer provide proprietary API
>>offering direct access to the protocol - this includes (and is not
>>limited to) Integrated Engineering (SmartID), ID3 semiconductors
>>(CL1356), Pro-Active (SpringCard), certainly also OmniKey or DUALi
>>that offers a valuable SDK.
>>
>>Last point, your sequence: "Select one of them and read it; Select
>>another and read it" is valid but do not expect to read several
>>chips simultaneously (it's certainly not required); indeed some
>>several chips are in the field the reader shall "select" one and
>>"halt" the other ones, from the chip point of view the "halt" is
>>(more or less) a soft reset (it will keep its UID but will lose its
>>context) and thus it is not possible to suspend and then resume the
>>exchange of APDUs.
>>
>>Sylvain.
>>
>
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Access to multiple contactless cards using PCSC-Lite

[Sébastien Lorquet]

Hi,

are you sure the CID function is not usable to keep a live context in more
than one card (in the same field of course)? Only the card with the targeted
CID value will reply to a command that contains this CID. At least, IIUC...
it means that with CID support, you don't need to halt the cards you're not
talking to...

Sebastien

On Thu, Jan 27, 2011 at 2:57 PM, s.ferey  wrote:

> Hi,
>
> As Ludovic yet answered you can manage that sequence (ie card requests,
> tag/chip enumeration, selection of one of them) yourself as long as some API
> give you access to such functions; but for most of readers the PC/SC driver
> is  opaque to these operations -- in short PC/SC manages APDU exchanges as
> per ISO 7816/14443-4 but hide details of protocol stack as per ISO
> 7816/14443-3; or other way to explain the reader firmware implements 14443-3
> while the reader driver implements 14443-4 with PC/SC syntax.
>
> That said, some readers manufacturer provide proprietary API offering
> direct access to the protocol - this includes (and is not limited to)
> Integrated Engineering (SmartID), ID3 semiconductors (CL1356), Pro-Active
> (SpringCard), certainly also OmniKey or DUALi that offers a valuable SDK.
>
> Last point, your sequence: "Select one of them and read it; Select another
> and read it" is valid but do not expect to read several chips simultaneously
> (it's certainly not required); indeed some several chips are in the field
> the reader shall "select" one and "halt" the other ones, from the chip point
> of view the "halt" is (more or less) a soft reset (it will keep its UID but
> will lose its context) and thus it is not possible to suspend and then
> resume the exchange of APDUs.
>
> Sylvain.
>
>
> Le 27/01/2011 10:26, Alexei Soloview a écrit :
>
>> Hello!
>>
>> I have reader compliant to ISO 14443-3 and smartcards with support of
>> anticollision function.
>> The ISO 14443-3 specifies procedures to manage selection of the card for
>> further communication?
>> Can I via PCSC-Lite implement the following functionality:
>> 1. Put on reader two smartcards.
>> 2. Select one of them and read it
>> 3. Select another and read it
>> ?
>>
>> Sincerelly, Alexei.
>>
>>  ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Access to multiple contactless cards using PCSC-Lite

[Sébastien Lorquet]

FYI, the topic of multiple cards in the same field is quite complicated.

it will require the CID feature (or NAD, but this one is not frequently
used)

this way it's possible to establish different channels with different cards
in the same field.

Else, you can only communicate with one card at once. The reader would
report the list of card identifiers, you select one, and the reader will
shut the others. Changing the current card is more complex.

In fact it's so complicated that master card or visa (cant remember which,
may be EMV) forbid it.

Sebastien

On Thu, Jan 27, 2011 at 10:40 AM, Ludovic Rousseau <
ludovic.rouss...@gmail.com> wrote:

> 2011/1/27 Alexei Soloview :
> > Hello!
>
> Hi,
>
> > I have reader compliant to ISO 14443-3 and smartcards with support of
> > anticollision function.
> > The ISO 14443-3 specifies procedures to manage selection of the card for
> > further communication?
> > Can I via PCSC-Lite implement the following functionality:
> > 1. Put on reader two smartcards.
> > 2. Select one of them and read it
> > 3. Select another and read it
> > ?
>
> This will be driver "specific".
> I have not implemented any support of ISO 14443-3 in my CCID driver
> for example. And some CCID readers are using ISO 14443-3.
>
> You can read PCSC v2 part 3 chapter "3.1.3  Contactless Environment
> Specifics" [1]. Maybe you will find something related to your problem.
> Or you can contact the reader manufacturer. They should know what is
> possible to do with their reader/driver.
>
> Bye
>
> [1] http://www.pcscworkgroup.com/specifications/specdownload.php
>
> --
>  Dr. Ludovic Rousseau
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

[Muscle] [off topic but important] someone here has a hacked AOL account

[Sébastien Lorquet]

Hello all,

Today I received a spam that had many of this list's members inside its
"To:" list. It was sent via aol.com

The spam made it directly to my inbox instead of being filtered, which means
it was not sent via a google-known botnet but rather via a hacked personal
account.

If someone wants more information on the list of users this hacked account
sent spam to, send me a private email.

regards
sebastien
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Smartcard installation

[Sébastien Lorquet]

Only cyberflex requires captransf. I'm quite sure the Classic TPC will work
with the standard cap.
sagem orga shall work OK provided you have the correct GP keys, of course.

Sebastien

On Tue, Dec 21, 2010 at 6:28 AM, Martin Paljak  wrote:

>
> On Dec 20, 2010, at 8:35 PM, Brian Thomas wrote:
>
> > Hello,
> >
> > Does anyone know how to install the MUSCLE applet onto any of the
> following smart cards using Gpshell?
>
> http://www.opensc-project.org/opensc/wiki/JavaCard#Loadingtheapplet
>
> >  1.)Oberthur ID-One COSMO V7
> > 2.)Gemalto_Classic_TPC
> > 3.)SagemOrga ypsID
>
> I've had success with Oberthur Cosmo. At least some Gemalto cards require
> post-processing the .cap file with captransf.jar and I've not seen
> SagemOrga. What are the JC and GP versions of the non-Oberthur cards?
>
>
>
> --
> @MartinPaljak.net
> +3725156495
>
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Status of the Muscle applet

[Sébastien Lorquet]

I don't believe *javacard* itself , or any current javacard platform,
provides support for 4096 bits RSA.

But I'd be happy to be wrong.

Sebastien Lorquet

On Tue, Dec 14, 2010 at 9:49 AM,  wrote:

> http://muscleplugins.alioth.debian.org/ has the most recent common source
> code of the v1 applet. It does work on JCOP 41 cards at least and there is a
> build file specific to JCOP.  I don't believe it includes support for 4096
> bit RSA, but it should be fairly easy to add. If you order enough cards from
> a vendor, you can usually arrange for the applet to be placed on-card during
> pre-personalization - the amount and cost differ from each vendor.
>
> Mike
>
> Sent from Comcast mobile
>
> -Original Message-
> From: Jean-Michel Pouré - GOOZE
> To: muscle
> Sent: 2010-12-14 08:14:22 +
> Subject: [Muscle] Status of the Muscle applet
>
> Dear Friends,
>
> Would it be possible to know the status of the Muscle applet. We would
> be interested in testing the muscle applet with a JCOP card.
>
> What is exactly the home page of the Muscle applet project?
> Is it still: http://www.linuxnet.com/musclecard/index.html
>
> Could you redirect http://www.linuxnet.com/musclecard/index.html
> to the actual page.
>
> Some questions:
> 1) Is the Muscle applet compatible with the JCOP specs?
> 2) Do vendors provide a JCOP card with Muscle applet included by
> default.
> 3) Can the muscle applet be used to generate a card with 4096bit key RSA
> crypto?
> 4) Is the Muscle applet actively developed and maintained?
>
> Kind regards,
> Jean-Michel POURE
> --
>  Jean-Michel Pouré - Gooze - http://www.gooze.eu
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] GSM SIM Apps

[Sébastien Lorquet]

Hi,

for me, a GSM SIM is definitely a Smart card. It runs "advanced"
cryptographic algorithms , verify PINs and store files under the control of
this PIN.

a card would not be smart if it contained only wired algorithms and memory.
I think that even the first SIM ever issued were "smart" :)

Regards

Sebastien

On Wed, Oct 27, 2010 at 10:31 AM,  wrote:

> Hello all,
>just starting out on investigating GSM SIM Apps. Normally I'd lurk on a
> mailing list for a while and listen to the traffic but there's not been
> much
> traffic so I'll dip my toes into the water.
>
> Like I say it's early days and I have far to many simple questions like is
> a
> GSM SIM even considered to be a smart card and as a result is this the
> right
> mailing list?
>
> If I'm in the wrong place please let me know.
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] pcsc-lite: Card auto power on and off

[Sébastien Lorquet]

Hi,

in that case, that's 100% OK.
I did not RTFD enough :-)

Regards
Sebastien

On Mon, Oct 25, 2010 at 10:22 AM, Ludovic Rousseau <
ludovic.rouss...@gmail.com> wrote:

> 2010/10/24 Sébastien Lorquet :
> > I also agree with that opinion. In my company we have highly complex SAMs
> > that can handle multiple *long* transactions (up to around one minute)
> and
> > it would be a problem if the card was powered down in the process.
>
> The card will be powerd off only if NO application is using it. So no
> transaction will be ongoing.
>
> If an application is connected to the card the card will NOT be powered
> off.
>
> Bye
>
> --
>  Dr. Ludovic Rousseau
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] pcsc-lite: Card auto power on and off

[Sébastien Lorquet]

Hi

I also agree with that opinion. In my company we have highly complex SAMs
that can handle multiple *long* transactions (up to around one minute) and
it would be a problem if the card was powered down in the process.

Autopoweroff shall be an optional, non default activated feature.

btw I agree it's useful in some cases where power consumption is an issue.

Sebastien

PS: background threads in a *card* ... how awful x_x !

On Sun, Oct 24, 2010 at 3:19 PM, s.ferey  wrote:

> Hello Ludovic, All,
>
> I see at least 3 issues with auto power-off:
>
> - under Windows (may be also on Linux) the smardcard withdrawal can lock
> the station; a power off of the cad will result in unexpected log-out.
>
> - a SSO solution may/should rely on a backgroung process that controls all
> smartcard requests, but still one can design a solution based on an "short
> life time" application to gain card access (user verification, on-card
> context establishment) and then small clients for signature, data storage,
> etc, requests - such clients will expect the card to keep its context.
>
> - JavaCard 3.0 introduces "distributed services", such a card can have
> running background threads w/o applications actually connected - the card
> behaves as a server and thus must keep a context alive.
>
> Regards,
> Sylvain.
>
>
> Le 24/10/2010 11:56, Ludovic Rousseau a écrit :
>
>
>> Hello,
>>
>> I just implemented a new feature in pcsc-lite: card auto power on and off
>> I describe the mechanism in an article [1] on my blog.
>>
>> Play with the new code, break it and report bugs :-)
>>
>> Bye
>>
>> [1]
>> http://ludovicrousseau.blogspot.com/2010/10/card-auto-power-on-and-off.html
>>
>>
>
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] PCSC on ARM

[Sébastien Lorquet]

you never know, since 0x42 = 66 :-)


On Thu, Aug 5, 2010 at 6:33 PM, Roger Brown wrote:

>  I don’t think Douglas Adams was thinking in hex.
>
>
>
> *From:* muscle-boun...@lists.musclecard.com [mailto:
> muscle-boun...@lists.musclecard.com] *On Behalf Of *Fundu
> *Sent:* Friday, 6 August 2010 4:30 a.m.
> *To:* MUSCLE
>
> *Subject:* Re: [Muscle] PCSC on ARM
>
>
>
>
>
>   >here is a pointer: (void*)&documentation;
>
> like the sarcastic sense of humor. but there's hardly much documentation
> around. atleast on the site there isn't an installation section .
>
>
> >>> I should have written (void*)0x42 :-)
> didn't understand this one...
>
>
>
>
> >Yes, pcscd is required; this is the resource manager. libpcsclite is the
> client library that connects your application to this daemon.
>
> Yeah i figured that one out.
>
>
> >Isn't there a
> --with-libusb=/usr/local/arm/4.3.2/arm-none-linux-gnueabi/libc/armv4t/usr/
> option in this configure?
>
> won't the LIBUSB_CFLAGS and LIBUSB_LIBS do that same ?
>
>
> >>>Looking at the latest pcsclite source package, we only have
> --with-libusb=yes, and the env vars you changed seem to override the
> settings >>>detected from pkgconfig. Which leads me to the solution I used
> when I had to: I relied on pkg-config. You just need the .pc file installed
> by >>>your toolchain's libusb package. I would expect it to be in:
>
> >>>/usr/local/arm/4.3.2/arm-none-linux-gnueabi/libc/armv4t/usr/lib/pkgconfig
>
> i'm using the latest pcsclite 1.6.2.  and --with-libusb also doesn't work
> as well as LIBUSB_CFLAGS LIBUSB_LIBS
>
>
>
>
>
> can you explain more about pkg-config and .pc file. i found it in usb what
> do i do with it ?
>
> But someone else may have a better idea.
>
> Regards
> Sebastien
>
>
>
>
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] PCSC on ARM

[Sébastien Lorquet]

On Thu, Aug 5, 2010 at 5:20 PM, Fundu  wrote:

> >here is a pointer: (void*)&documentation;
>  like the sarcastic sense of humor. but there's hardly much documentation
> around. atleast on the site there isn't an installation section .
>

I should have written (void*)0x42 :-)


>
>
> >Yes, pcscd is required; this is the resource manager. libpcsclite is the
> client library that connects your application to this daemon.
> Yeah i figured that one out.
>
> >Isn't there a
> --with-libusb=/usr/local/arm/4.3.2/arm-none-linux-gnueabi/libc/armv4t/usr/
> option in this configure?
> won't the LIBUSB_CFLAGS and LIBUSB_LIBS do that same ?
>

I'm really far from being a ./configure guru.
Looking at the latest pcsclite source package, we only have
--with-libusb=yes, and the env vars you changed seem to override the
settings detected from pkgconfig. Which leads me to the solution I used when
I had to: I relied on pkg-config. You just need the .pc file installed by
your toolchain's libusb package. I would expect it to be in:
/usr/local/arm/4.3.2/arm-none-linux-gnueabi/libc/armv4t/usr/lib/pkgconfig

But someone else may have a better idea.

Regards
Sebastien
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] PCSC on ARM

[Sébastien Lorquet]

here is a pointer: (void*)&documentation;

Yes, pcscd is required; this is the resource manager. libpcsclite is the
client library that connects your application to this daemon.

Isn't there a
--with-libusb=/usr/local/arm/4.3.2/arm-none-linux-gnueabi/libc/armv4t/usr/
option in this configure?

Regards
Sebastien
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] [PATCH] more idiomatic sysconfdir usage

[Sébastien Lorquet]

hello

what about a smaller tab setting in your editor? :)

sebastien

On Mon, Aug 2, 2010 at 6:13 PM, Luisa  wrote:

> What about this:
>
> std_sysconfdir='${prefix}/etc'
>
> if test x"${sysconfdir}" == x"${std_sysconfdir}"; then
>  sysconfdir=/etc
> fi
>
> or even simplier, since herarchy or prefixes aren't likely to change:
>
> if test x"${sysconfdir}" == x'${prefix}/etc'; then
>  sysconfdir=/etc
> fi
>
> This migth be somewhere between AM_INIT_AUTOMAKE and
> AC_CONFIG_FILES/AC_OUTPUT in configure.ac/.in
>
> Also, as I'm begining to study the library in order to adapt my
> reader, is there any chance to have the code properly idented? I can
> do it with no hassle.
>
> I don't know what sort of editors do you guys use, but on a terminal
> it is pretty much unreadable:
>
> http://openscd.googlecode.com/files/shot-wrong-1.png
> http://openscd.googlecode.com/files/shot-wrong-2.png
> http://openscd.googlecode.com/files/shot-ok-1.png
> http://openscd.googlecode.com/files/shot-ok-2.png
>
> That would make easy to follow up and send patches, at least for me.
>
> Regards,
>
>
>
> On 8/1/10, Ludovic Rousseau  wrote:
> > 2010/8/1 Sébastien Lorquet :
> >> I agree with you with the correct default behaviour of using /etc, but I
> >> really have no idea on how to achieve that without --sysconfdir
> >> Maybe your idea is the best one even if it sounds hackish, at least for
> >> the
> >> moment.
> >
> > Implemented the kackish way in revision 5082.
> >
> > Bye
> >
> > --
> >  Dr. Ludovic Rousseau
> >
> > ___
> > Muscle mailing list
> > Muscle@lists.musclecard.com
> > http://lists.drizzle.com/mailman/listinfo/muscle
> >
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] [PATCH] more idiomatic sysconfdir usage

[Sébastien Lorquet]

I agree with you with the correct default behaviour of using /etc, but I
really have no idea on how to achieve that without --sysconfdir

Maybe your idea is the best one even if it sounds hackish, at least for the
moment.

or a warning in the configure script if it finds that sysconfdir equates to
something different than /etc ?

configure: creating Makefile
WARNING: sysconfdir is not set to the standard value /etc. Maybe you forgot
to use --sysconfdir?
etc

Sebastien

On Sat, Jul 31, 2010 at 10:23 PM, Ludovic Rousseau <
ludovic.rouss...@gmail.com> wrote:

> 2010/7/4 Kalev Lember :
> >> URL: http://svn.debian.org/wsvn/pcsclite/?sc=1&rev=5060
> >> Log: set --sysconfdir=/etc/reader.conf.d so that we parse any file in
> this
> >> directory
> >>
> >> [...]
> >> ---sysconfdir=/etc \
> >> +--sysconfdir=/etc/reader.conf.d \
> >
> > It's more common to set sysconfdir to /etc and have configure script
> > figure out the subdirectory. The configure script should always default
> > to sane values when no arguments are specified. The default value for
> > sysconfdir is /usr/local/etc; so the configure script should just append
> > /reader.conf.d to that. Right now if the user doesn't override
> sysconfdir,
> > pcsc will try to go through every .conf file in /usr/local/etc, and I
> > don't think anything good will come out of that.
>
> I would like to have a default value of sysconfdir to be /etc instead
> of /usr/etc if prefix=/usr
>
> The motivation is that I would like to have everything configured
> "correctly" with just a "./configure --prefix=/usr"
>
> I could hardcode a test in configure and set sysconfdir to /etc if
> prefix=/usr but that looks like a hack more than a correct solution.
>
> Any ideas or comments?
>
> Bye
>
> --
>  Dr. Ludovic Rousseau
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Re: Open readers and iso7816 question

[Sébastien Lorquet]

Hello,

I understand your happiness. Congrats!

The specs at cardwerks are unfortunately out of date for at least 2
versions, but the basics haven't changed, just details such as odd INS
values, etc. the protocols are still OK.

Regards
Sebastien

On Sun, Jul 18, 2010 at 10:24 PM, Luisa  wrote:

> Guys! Success!!
>
> I've just read the full atr out of the card!
>
> How nice!! I haven't got words to say how much appreciate your
> patience, help and support, as any of this wouldn't have been possible
> with your tips.
>
> Well, my findings:
>
> * With my card, I can read from 500 Khz to 4 Mhz, haven't test 5 Mhz yet.
>
> * The higher the frequency applied to the card's clock-line is, the
> most it takes to return an atr after the TS byte. Then I recalled what
> you said Sebastien, that atr is given by software, so it all starts
> making sense.
>
> As soon as I got this working, been trying to connect the chip the
> serial port, but it seems the maxim on my adaptor is not up or it
> today, so I'll see tomorrow what's wrong with it or make a new one.
>
> The crystals haven't arrived so far, so the clock line is output by
> the chip as well, the bits are read one by one till it gets a byte,
> but it works so reliably!.
>
> The good point of going this lowlevel instead of by usart, is that I
> can implement error reporting by means of holding the line low, which
> I coulnd't do if using the hardware usart module, appart from
> supporting synchronous cards, etc.
>
> Anyways, I'm so happy, can't wait to have the maxim circuit working so
> as to go further with this.
> As soon as I have the circuit talking to the pc I'll upload code and
> schematics.
>
> Also, would the specs @ cardwerk I mentioned be up to date regarding
> the command protocol? I guess they would.
>
> hmm, there's soemthing else I was curious about, but can remember now,
> will leave it for latter.
>
> Thanks!
>
> Regards,
>
>
>
> On 7/9/10, Sébastien Lorquet  wrote:
> > I was ascertained by my "personal card expert" that the lower limit is
> > guaranteed to be lower than 1MHz, so that frequency shall be OK.
> >
> > Sebastien
> >
> > On Fri, Jul 9, 2010 at 4:54 PM, Drasko DRASKOVIC <
> drasko.drasko...@gmail.com
> >> wrote:
> >
> >> On Fri, Jul 9, 2010 at 4:04 PM, Sébastien Lorquet 
> >> wrote:
> >> > Beware: the line is *toggled* every 10 clock pulses, so a period is 20
> >> > pulses or 1 MHz :)
> >>
> >> Yes, you're right. In that case, rising up this frequency is worth
> >> trying, as you mentioned, because we might be on a low limit...
> >>
> >> ___
> >> Muscle mailing list
> >> Muscle@lists.musclecard.com
> >> http://lists.drizzle.com/mailman/listinfo/muscle
> >>
> >
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: Apologies: Auto Reply: Auto Reply: [Muscle] Rule of F and D praramter

[Sébastien Lorquet]

Hi,

*I* am very sorry because I was a bit too stressful!

There does not seem to be any bug, we got only an extra copy of your
out-of-office message, there is nothing wrong with that.

The way to avoid such cascade might be a very simple issue, ie don't send
autoreplies to a received autoreply, etc

Sorry again and regards,
Sebastien


On Thu, Jul 15, 2010 at 5:34 PM, Valerie Anne Fenwick <
valerie.fenw...@oracle.com> wrote:

> Sébastien Lorquet wrote:
>
>> I fear a cascade of out-of-office autoreplies :/
>>
>> On Sat, Jul 10, 2010 at 3:26 PM, > valerie.fenw...@oracle.com>> wrote:
>>
>>Hi -
>>
>>I am out of the office from July 10-July 14, 2010. I will not be
>>checking email or voicemail at that time. I do receive a lot of
>>email, so if you're message needs urgent attention
>>when I return, please leave me a voice mail to draw my attention to it.
>>
>
> Hi everyone -
>
> My sincerest apologies about this barrage of out of office
> messages. This was my first time setting an "away" message
> with Oracle's mail system, after having joined the company
> in the Sun acquisition. I had no idea it was this broken
> as I had not seen this type of behaviour with internal aliases
> I own and manage, nor external aliases with Oracle members.
>
> I will not use this vacation mail system again until this
> bug is confirmed fixed.
>
> I am very sorry.
>
> Valerie
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: Auto Reply: Auto Reply: [Muscle] Rule of F and D praramter

[Sébastien Lorquet]

I fear a cascade of out-of-office autoreplies :/

On Sat, Jul 10, 2010 at 3:26 PM,  wrote:

> Hi -
>
> I am out of the office from July 10-July 14, 2010. I will not be checking
> email or voicemail at that time. I do receive a lot of email, so if you're
> message needs urgent attention
> when I return, please leave me a voice mail to draw my attention to it.
>
> Good alternate contacts for me:
> about   contact
> bugster scott.roto...@oracle.com, bt2-fo...@sun.com
> crypto framework ef-inter...@sun.com, crypto-disc...@opensolaris.org
> elfsign elfsign-c...@sun.com
> manager steven.de@oracle.com
> RTIsjohn.ojem...@oracle.com
> CRT on-crt-advoca...@sun.com
>
> thank you for your patience!
>
> Valerie
>
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Re: Open readers and iso7816 question

[Sébastien Lorquet]

I was ascertained by my "personal card expert" that the lower limit is
guaranteed to be lower than 1MHz, so that frequency shall be OK.

Sebastien

On Fri, Jul 9, 2010 at 4:54 PM, Drasko DRASKOVIC  wrote:

> On Fri, Jul 9, 2010 at 4:04 PM, Sébastien Lorquet 
> wrote:
> > Beware: the line is *toggled* every 10 clock pulses, so a period is 20
> > pulses or 1 MHz :)
>
> Yes, you're right. In that case, rising up this frequency is worth
> trying, as you mentioned, because we might be on a low limit...
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Re: Open readers and iso7816 question

[Sébastien Lorquet]

Beware: the line is *toggled* every 10 clock pulses, so a period is 20
pulses or 1 MHz :)


On Fri, Jul 9, 2010 at 3:54 PM, Drasko DRASKOVIC  wrote:

> On Fri, Jul 9, 2010 at 3:42 PM, Luisa  wrote:
> > Hi Sebastien,
> >
> > It seems I have to wait for a week or so till the crystal arrives.
> > Though I'm also sure one can get advantage on the hardware usart to
> > get things done and it's the way to go.
> >
> > However, been testing this "by hand" now that I had some spare time at
> > 1Mhz, with no success so far (I've got the impression I won't have it
> > either when the crystal arrives and I setup the hardware accordingly,
> > because of the problem here being some other that I can't see).
> >
> > What I'm doing now, with a 20Mhz clock on the chip, instead of the
> > original 18Mhz one:
> >
> > * I setup the card's clock line to toggle each 10 cycles, hence giving
> > me a full-swing 1Mhz signal on the output pin, though I don't yet let
> > it toggle.
>
> 20Mhz / 10 = 2Mhz, not 1Mhz. Though the cart should work fine for all
> frequencies between 1Mhz and 5Mhz,
> I suggest you to use 1Mhz for the beginnig.
>
> >
> > * I activate the contacts appropiately, including the card's clock line.
> >
> > * Just after I activate the contacts, no interrupts or whatsoever, I
> > just fall into a loop where I sample 80 bits on the i/o line each +/-
> > 372 uS (have also tried with more and less, though this time the card
> > actually sends bytes as expected, each +/- 372uS).
>
> If you are clocking your card with 2Mhz, you should not sample at 372uS.
> Again, the formule is : initial ETU = 372 / Fcard_clock.
>
> For 1Mhz, initital ETU = 372 uS.
> For 2Mhz, initial ETu = 372 / 2 = 186 uS.
>
> BR,
> Drasko
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Re: Open readers and iso7816 question

[Sébastien Lorquet]

Hi,

No real clues, except that 1MHz may be a bit too close from the lower
accepted limit.

Did you try with another card? Anyone will do at this stage. bank card with
a chip, SIM card, etc.

Regards
Sebastien

On Fri, Jul 9, 2010 at 3:42 PM, Luisa  wrote:

> Hi Sebastien,
>
> It seems I have to wait for a week or so till the crystal arrives.
> Though I'm also sure one can get advantage on the hardware usart to
> get things done and it's the way to go.
>
> However, been testing this "by hand" now that I had some spare time at
> 1Mhz, with no success so far (I've got the impression I won't have it
> either when the crystal arrives and I setup the hardware accordingly,
> because of the problem here being some other that I can't see).
>
> What I'm doing now, with a 20Mhz clock on the chip, instead of the
> original 18Mhz one:
>
> * I setup the card's clock line to toggle each 10 cycles, hence giving
> me a full-swing 1Mhz signal on the output pin, though I don't yet let
> it toggle.
>
> * I activate the contacts appropiately, including the card's clock line.
>
> * Just after I activate the contacts, no interrupts or whatsoever, I
> just fall into a loop where I sample 80 bits on the i/o line each +/-
> 372 uS (have also tried with more and less, though this time the card
> actually sends bytes as expected, each +/- 372uS).
>
> I keep only getting the TS byte.
>
> In order to check that I'm not loosing successive bytes, after the
> first loop and a delay (that I set to different values across
> different tests, up to the maximum o 2688 etus in this case) I fall
> into another loop where I read another 80 bits.
>
> The voltages on the pins when the card is in operation are as follows
> (in respect to card's GND):
>
> * VCC: 4,96
> * RST: 4,70
> * CLK: 2,53 (this is actually my multimeter averaging over the 1Mhz
> signal I guess. The signal is comming directly from the chip, and so
> measured against chip's gnd)
> * IO:  4,93
>
> Any clues?
>
> Regards,
>
>
>
> On 7/8/10, Sébastien Lorquet  wrote:
> >>
> >> Yes, that's exactly what I tried today. One can output a signal on
> >> certain pins by hardware, without it generatig a software interrupt,
> >> but I didn't have any success yet, same results.
> >
> > Only rare CPUs allows that mode, one of them is the PIC 18F2620.
> >
> >>
> >> I think the problem lies on the output signal and the interrupt (the
> >> one which samples the i/o line not being in synch).
> >>
> >> Hence why the need for a clock, one setups usart and recieves just
> >> what the card sends (the transciever does handle start and stop bits,
> >> etc).
> >>
> >> Not sure yet how to synch with the external clock with usart either,
> >
> > No sync is needed. Just a speed relationship. The USART will detect
> > the start bit and sync with that provided the baud rate is OK.
> >
> >> but I'm pretty sure that by going the usart way, the stop bits needed
> >> when one wants the card to repeat las byte are not going to be easily
> >> accessible, but we'll see.
> >
> > I'm definitely sure you can use the usart. It's half duplex, so you
> > just have to short Tx and Rx and disable receiver when transmitting
> > (and that may not be needed).
> >
> > The fundamental part is to set the correct baud rate.
> >
> > The USART bit rate must be 1/372 the frequency present on the card
> > "clock" pin. Forget about PPS until it works at basic speed.
> >
> > If you can use the same clock frequency for the usart and the clock
> > output, you're done. Just set the baud rate timer to 372 and exchange
> > bytes. If you know that the input to the baud rate generator is a
> > fraction of the xtal clock (because of a prescaler, for example), then
> > use the XTALOUT signal from your cpu to clock the card and compute the
> > proper baud rate generator parameters so that the usart bit rate is
> > 1/372 the XTAL clock :)
> >
> > Then remember cards can not use a very high clock: 3-5 MHz will be ok.
> > This will also be you CPU's clock.
> >
> > Also, I don't know your microcontroller, but some of them can use an
> > external clock to generate baud rates.
> >
> > Sebastien
> > ___
> > Muscle mailing list
> > Muscle@lists.musclecard.com
> > http://lists.drizzle.com/mailman/listinfo/muscle
> >
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Re: Open readers and iso7816 question

[Sébastien Lorquet]

>
> Yes, that's exactly what I tried today. One can output a signal on
> certain pins by hardware, without it generatig a software interrupt,
> but I didn't have any success yet, same results.

Only rare CPUs allows that mode, one of them is the PIC 18F2620.

>
> I think the problem lies on the output signal and the interrupt (the
> one which samples the i/o line not being in synch).
>
> Hence why the need for a clock, one setups usart and recieves just
> what the card sends (the transciever does handle start and stop bits,
> etc).
>
> Not sure yet how to synch with the external clock with usart either,

No sync is needed. Just a speed relationship. The USART will detect
the start bit and sync with that provided the baud rate is OK.

> but I'm pretty sure that by going the usart way, the stop bits needed
> when one wants the card to repeat las byte are not going to be easily
> accessible, but we'll see.

I'm definitely sure you can use the usart. It's half duplex, so you
just have to short Tx and Rx and disable receiver when transmitting
(and that may not be needed).

The fundamental part is to set the correct baud rate.

The USART bit rate must be 1/372 the frequency present on the card
"clock" pin. Forget about PPS until it works at basic speed.

If you can use the same clock frequency for the usart and the clock
output, you're done. Just set the baud rate timer to 372 and exchange
bytes. If you know that the input to the baud rate generator is a
fraction of the xtal clock (because of a prescaler, for example), then
use the XTALOUT signal from your cpu to clock the card and compute the
proper baud rate generator parameters so that the usart bit rate is
1/372 the XTAL clock :)

Then remember cards can not use a very high clock: 3-5 MHz will be ok.
This will also be you CPU's clock.

Also, I don't know your microcontroller, but some of them can use an
external clock to generate baud rates.

Sebastien
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] T=0 Case 2 response length

[Sébastien Lorquet]

On Thu, Jul 8, 2010 at 10:56 AM, Drasko DRASKOVIC
 wrote:
> On Thu, Jul 8, 2010 at 10:24 AM, Wayne Wang  wrote:
>> hi Sebastein,
>>
>> here is code section for towitoko
>> http://towitoko.sourcearchive.com/documentation/2.0.7-8/protocol__t0_8c-source.html
>>
>> It handles the APDU directly in the driver.
>> Any comment :)
>
> No, it does not. What you show is not a driver code, but a transport
> layer, which confirms Sebastien's statements, and my initial idea of
> layer decoupling.

Well that's even simpler then. I didn't notice that (excuse: working
on something else right now :) ).

>
> Driver does not get APDU at all, but TPDU formed by this transport
> layer. Driver code (here not shown) implements functions like:
> ICC_Async_Transmit() and ICC_Async_Receive() and does not have much
> idea of protocol itself (I guess, though I did not look at fnc
> implementation).
>
> Also, I am still wondering on the driver implementing functions like this :
> ICC_Async_Receive (t0->icc, 1, buffer + recv)  <-- receiving byte by byte ???

the towitoko code is ten years old :)

>
> That means that you will have yourself interrupt after each byte that
> comes... Unsupportable from the performance point of view in a larger
> RT system (like mobile phone).

Yes, I saw you on the osmocombb mailing list ;)

Sebastien

>
> BR,
> Drasko
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>

___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] T=0 Case 2 response length

[Sébastien Lorquet]

in computer science everything is possible. But what is best for your
users, ie easy to use still universal enough?

I don't like this towitoko code because it does things behind your
back. When I send an APDU, I expect to know what goes to the card.

if a driver does that, and another driver does not do that, then your
card/software behaviour can depend on the reader!

especially during software development I think it is useful to have a
stable low level layer.

In this thread, I described the standard pcsc behaviour, because I
think this is the best way to implement the software given the
non-layered nature of T=0.

And I'm convinced that proper Le handling is important and must be
managed by the application. From my experience in my company, this is
the only way I know to stay compatible with all cards on the market,
including old cards and new cards, contact cards and contactless
cards.

At least that's my opinion, and I agree with myself :-)

Regards,
Sebastien

On Thu, Jul 8, 2010 at 10:24 AM, Wayne Wang  wrote:
> hi Sebastein,
>
> here is code section for towitoko
> http://towitoko.sourcearchive.com/documentation/2.0.7-8/protocol__t0_8c-source.html
>
> It handles the APDU directly in the driver.
> Any comment :)
>
> B.R.
> Wayne
>
> -Original Message-
> From: muscle-boun...@lists.musclecard.com 
> [mailto:muscle-boun...@lists.musclecard.com] On Behalf Of Sébastien Lorquet
> Sent: Thursday, July 08, 2010 14:34
> To: MUSCLE
> Subject: Re: [Muscle] T=0 Case 2 response length
>
> One more thing:
>
>>
>> It is so weird to let the dependency exist from bottom to top.
>
> In fact, I do not think that's not a dependency. That just means that T=0 is 
> unable to transfer a case 4 command at once.
> The fact that the direction of the transfer MUST be known prior to the 
> transfer also implies that you must know the response length.
>
> If the response length is not what the card expected, there is no way to make 
> the host and the card agree on the action to be taken. So instead of relying 
> on timeouts, the designers preferred to be sure of the transfer length. So if 
> the transfer length is not OK for BOTH the host and the card, the latter one 
> sends 61 or 6C as SW2, so that the host can agree with the card, or abort the 
> transfer.
>
> Sebastien
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>

___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] T=0 Case 2 response length

[Sébastien Lorquet]

One more thing:

>
> It is so weird to let the dependency exist from bottom to top.

In fact, I do not think that's not a dependency. That just means that
T=0 is unable to transfer a case 4 command at once.
The fact that the direction of the transfer MUST be known prior to the
transfer also implies that you must know the response length.

If the response length is not what the card expected, there is no way
to make the host and the card agree on the action to be taken. So
instead of relying on timeouts, the designers preferred to be sure of
the transfer length. So if the transfer length is not OK for BOTH the
host and the card, the latter one sends 61 or 6C as SW2, so that the
host can agree with the card, or abort the transfer.

Sebastien
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] T=0 Case 2 response length

[Sébastien Lorquet]

On Thu, Jul 8, 2010 at 3:09 AM, Wayne  wrote:
>
> Hi Sebastein,
>
> As to the PB in T=0 protocol, I think I'm clear days before. But after the 
> discusstion between Drasko, I'm confused again.
>
> On Thu, Jul 8, 2010 at 12:05 AM, Sébastien Lorquet  wrote:
>>
>> The last one. a call to the driver is a single sequence of data sending / 
>> data return.
>> Return only 61XX if necessary.
>>  Same as above :-) Return only the SW, and set return_len to 2.
>>
>> The only "intelligent" thing to do in your driver is a loop to wait for the 
>> card when it replies NULL procedure bytes (0x60) to request more time for 
>> its processing. If you get something else, the exchange step completes.
>
>
> In your opinion, the driver should not issue any "GET REPONSE" command by it 
> self? Even for case4, where a "GET RESPONSE" is required to get all response, 
> the driver also wait for upper layer to issue the "GET RESPONSE" command?
> And the re-issuing of original command is also done by upper layer?

Yes, the simplest example is javax.smartcardio. The library source is available.

>
> I wonder is it the implementation in most drivers. And did you see any 
> implementation like this way?

pcsclite. and windows winscard.

And CCID does not autosend get response either.
See the function named

CmdXfrBlockCHAR_T0

in the file: 
http://svn.debian.org/viewsvn/pcsclite/trunk/Drivers/ccid/src/commands.c?revision=5013&view=markup

>
> And the application( or support library) should be aware of the protocol used 
> in the driver, and to handle differently for T=0 and T=1?

This can be very simple. If you get 61XX, send a get response, and
return the get response reply to the user. If you get something else,
and you have data, the card was contactless or T=1, so no get response
is needed.


>
> It is so weird to let the dependency exist from bottom to top.

totally agree with you. That's why T1 was invented, and ISO14443 is
based on T=1 :-)

>
>
> Hi Drasko,
> Driver should always prepare to go back and forth for T=0 protocol. Assume 
> case3, you send a command, and the card alway feed you with a PB as "~INS", 
> then you must send a BYTE, get a PB, and again send BYTE, get a PB, over and 
> over till all command sent to card and then get SW1, SW2.

In my mental model, this situation must be handled in the driver,
because ~INS is a procedure byte, not a SW for the user. You quit the
driver when the procedure byte turns out to be SW1 (return SW2) or INS
(return data bytes)

Also have a look at CmdXfrBlockCHAR_T0  in the previously mentionned file.

Regars
Sebastien

___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Re: Open readers and iso7816 question

[Sébastien Lorquet]

> Looks very good.

> > If I were you, I would use a GPIO to detect card insertion. This event
> can
> > be used to trigger card activation, reset sequence, ATR reading and
> optional
> > PPS exchange. Do you plan to connect your reader to a PC via a serial
> port?
> > TxD and RxD are still free on PD0 and PD1.
> >
>
> Thanks, am, there is another hardware usart bellow it, and yes, my
> intention is to connect the reader to the computer.
>
> However, given your and drasko's clarifying comments, I'm feeling a
> bit like this is not the chip I want to use anymore? I mean, I'm gonna
> study the whole thing at hardware level, and study whether this chip
> will leave me room for getting anywhere I ever wanted to in terms of
> the iso implementation/smartcard development.
>
> If it doesn't, I have some ST7XX samples arround (arm7 chips from
> st-microelectronics), an (iirc) believe one of them has builtin
> smartcard support, including clock frecuency switching at runtime.
>
> My main concern is really to have a processor powerfull enough so as
> let me do it by software. It's more fun to me achieve a software
> implementation that I made, than reading the ds and setting a few
> registers with a given recommended hardware-setup beneath, though
> having that on-chip is an advantage also, I could use it when I wanted
> to.
>
> Totally agree. Looks like your atmel is OK provided you just add a 3.57
crystal clock. You can still make a bitbanged uart if you wish, and use an
irq as a timer.

an ARM SoC looks a bit overkill for this task, a 8 bit micro is enough for
this task. it will be funnier, easier to understand and easier to reproduce.

As a side note, to sample the IO line, ISO7816 requires to read the line at
the middle of the bit. You're not required to average more than one read.
Just have your irq run a twice the bitrate so that you can read the bit in
the middle, and toggle the IO line at the right moment for sending.



> Well, thanks, I'l keep you informed guys!
>
> Hope so! This project is interesting!

Regards
seb
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] T=0 Case 2 response length

[Sébastien Lorquet]

You're welcome.
I'm happy if my comments helped you.

Regards
Sebastien

On Wed, Jul 7, 2010 at 6:18 PM, Drasko DRASKOVIC  wrote:

> On Wed, Jul 7, 2010 at 6:05 PM, Sébastien Lorquet 
> wrote:
> >
> >
> > On Wed, Jul 7, 2010 at 4:27 PM, Drasko DRASKOVIC
> >  wrote:
> >>
> >> > To make things as perfect as possible, my opinion is to change your
> >> > driver
> >> > abstraction model to an upper level, and manage T=0 in a single
> "blob",
> >> > which can be seen as a layer by itself, but does not follow the OSI
> >> > concepts.
> >>
> >> What would that say in practice ? To do TX, and after RX processing
> >> and possible TX-resend (upon reception of 61 XX) in the driver code ?
> >> Or rather do give back 61 XX to transport layer function to process it
> >> and re-send command ?
> >
> > The last one. a call to the driver is a single sequence of data sending /
> > data return.
> > Return only 61XX if necessary.
> >
> >>
> >> > typical drivers provide an API like this one:
> >> > error_code_t exchange(unsigned char *command, int command_len
> /*known*/,
> >> > unsigned char *response, int *response_len /*discovered*/ );
> >>
> >> Same as the question above, would we find here after the function data
> >> of length 2 (61 XX) or data of length Luicc ? I.e. does exchange()
> >> function returns upon reception of 61 XX and put response_len to 2, or
> >> continues conversation until reception of Luicc bytes of data and puts
> >>  response_len to Luicc ?
> >
> > Same as above :-) Return only the SW, and set return_len to 2.
> >
> > All the terminals (PCSC or not) that I know work this way.
>
> Great, I will do it this way.
>
> Sebastien,
> thank you very much for your help.
>
> BR,
> Drasko
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] T=0 Case 2 response length

[Sébastien Lorquet]

On Wed, Jul 7, 2010 at 4:27 PM, Drasko DRASKOVIC  wrote:

> > To make things as perfect as possible, my opinion is to change your
> driver
> > abstraction model to an upper level, and manage T=0 in a single "blob",
> > which can be seen as a layer by itself, but does not follow the OSI
> > concepts.
>
> What would that say in practice ? To do TX, and after RX processing
> and possible TX-resend (upon reception of 61 XX) in the driver code ?
> Or rather do give back 61 XX to transport layer function to process it
> and re-send command ?
>

The last one. a call to the driver is a single sequence of data sending /
data return.
Return only 61XX if necessary.


>
> > typical drivers provide an API like this one:
> > error_code_t exchange(unsigned char *command, int command_len /*known*/,
> > unsigned char *response, int *response_len /*discovered*/ );
>
> Same as the question above, would we find here after the function data
> of length 2 (61 XX) or data of length Luicc ? I.e. does exchange()
> function returns upon reception of 61 XX and put response_len to 2, or
> continues conversation until reception of Luicc bytes of data and puts
>  response_len to Luicc ?
>

Same as above :-) Return only the SW, and set return_len to 2.

All the terminals (PCSC or not) that I know work this way.

The only "intelligent" thing to do in your driver is a loop to wait for the
card when it replies NULL procedure bytes (0x60) to request more time for
its processing. If you get something else, the exchange step completes.

Regards
Sebastien


> BR,
> Drasko
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] T=0 Case 2 response length

[Sébastien Lorquet]

Hi,

Now I understand.

I think that the problem arises from your clever layered design. T=0 was not
designed as an OSI layered protocol but as a state machine. This is why you
have to go back and forth between the layers.

-

if (rx_char & 0xf0 == 0x60)
> {
>  rx_len = 2;  /* This will overwrite rx_len = Le demanded by transport
> layer */
> }
> Like this driver will exit back to transport layer after 2 chars, as
> rx_len is now 2 and not Le.
>
> Is this what you suggesting, or I did not understand correctly ?
>

Exactly.

ISO7816 explicitly says about the procedure byte:

If the value is '6X' or '9X', except for '60', it is a SW1 byte. It requests
no action on data transfer. The
interface device shall wait for a character conveying a SW2 byte. There is
no restriction on SW2 value.

So as soon as you get this value, no data is transferred except SW2.

To make things as perfect as possible, my opinion is to change your driver
abstraction model to an upper level, and manage T=0 in a single "blob",
which can be seen as a layer by itself, but does not follow the OSI
concepts.

All experts around me agree that T=0 is not a "clean" protocol, but rather
something weird because of someone who did not notice the possible problems
before sending the document to ISO :-)

In ISO7816-3:2006, we can read about T=1:
The transmission protocol applies the principle of the OSI reference model.
Three layers are defined.

This may be a tip to all the people who complained about T=0 :-)

typical drivers provide an API like this one:
error_code_t exchange(unsigned char *command, int command_len /*known*/,
unsigned char *response, int *response_len /*discovered*/ );


Regards and sorry to partly destroy your vision :)
Sebastien
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] T=0 Case 2 response length

[Sébastien Lorquet]

Hi,

Then you may have a design problem in your driver. I know, T=0 is
frustrating and does not follow a layered scheme.

You cannot tell your driver to receive Le bytes, because only the card knows
how much it has to send. If you ask a different number, the card will say "I
cannot answer because you don't ask me the right question, and I have no
other way to tell it. Here is the correct length you have to ask me."
So it sends 61 or 6C. If you get that, you have to be happy with that and
return these bytes to the user even if he asked for more.

See how it's done at
http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/2b1a7d4b9ac6/src/share/classes/sun/security/smartcardio/ChannelImpl.java
check doTransmit() at line 155. Note that the ScardTransmit method is called
more than once, in a loop. pcsclite and winscard do not manage the get
response command. so do the card drivers.

A timeout is not acceptable because it would be too long and would not solve
your problem. FYI, I don't know any reader that have to rely on timeouts.

If I understand correctly, in the case the card does not give you Le bytes,
you want to send the get response in the driver, just after the actual
command? And what if the card DOES NOT have Le bytes at all? will you wait?
it will never come :-)

I would not do that. If the first byte you get is 61 or 6C, just get SW2 and
return. The application will take care of the get response and send the
proper command.

Regards
Sebastien

On Wed, Jul 7, 2010 at 12:53 PM, Drasko DRASKOVIC <
drasko.drasko...@gmail.com> wrote:

> On Wed, Jul 7, 2010 at 12:09 PM, Sébastien Lorquet 
> wrote:
> > Hi,
> >
> > APDU cases are deeply linked to T=0. In T=1, you don't need anything like
> > this, because the block length is sent in the block header, before the
> block
> > data, so the peers know the data length.
> >
> > So I think the exchange transparency should be done at a higher level.
> >
> > In case 2, just send the 5-bytes apdu you get, do not change Le (P3)
> > In this case, P3=Le=00 accounts for 256 bytes to be responded.
> >
> > Then, switch to receive mode.
> >
> > If the length is correct and accepted by the card, the card will answer
> INS
> > then the proper number of data bytes and SW. you do not need a timeout.
> if
> > the procedure byte is INS, the length you requested is valid and you will
> > get that many bytes - plus final SW.
> >
> > If the length is not correct, the card will ALWAYS reply an error or
> > warning, be it 61XX, 6CXX, or anything else. you also know that you just
> > have 2 bytes to read, and the correct length. just go ahead with get
> > response or command re-emission, now you know the correct length that
> will
> > be accepted by the card.
>
> Well this is exactly where the trouble comes : I told my driver to
> receive Le bytes,
> but card send him only 2. The driver keeps on waiting, because it does
> know that these are errors/warnings.
>
> I can not go out of driver RX routine to process bytes, because I did
> not know that it will receive only 2 bytes in the first place,
> and going out after 2 bytes to my transport layer can result in RX
> FIFO overflow (as driver is concerned he thinks that data is still
> coming from the card).
>
> So - in this case how to know to stop drives RX after only two bytes ?
> By looking at timeout (Work Waiting time exceeded) ?
>
> BR,
> Drasko
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] T=0 Case 2 response length

[Sébastien Lorquet]

Hi,

APDU cases are deeply linked to T=0. In T=1, you don't need anything like
this, because the block length is sent in the block header, before the block
data, so the peers know the data length.

So I think the exchange transparency should be done at a higher level.

In case 2, just send the 5-bytes apdu you get, do not change Le (P3)
In this case, P3=Le=00 accounts for 256 bytes to be responded.

Then, switch to receive mode.

If the length is correct and accepted by the card, the card will answer INS
then the proper number of data bytes and SW. you do not need a timeout. if
the procedure byte is INS, the length you requested is valid and you will
get that many bytes - plus final SW.

If the length is not correct, the card will ALWAYS reply an error or
warning, be it 61XX, 6CXX, or anything else. you also know that you just
have 2 bytes to read, and the correct length. just go ahead with get
response or command re-emission, now you know the correct length that will
be accepted by the card.

Normal cards indicate the correct length, so you can receive the exact
number of bytes.

If the card is dumb and replies a foolish 61XX length, this is not your
driver's fault :-)
This will timeout and the card is bad.

Other cases are undefined and do not need to be taken into account, because
this is a card problem (like the french navigo cards who replies 9000
instead of 61XX - pardon them, they are old cards).

There are some differences among cards when you send a GET RESPONSE with a
length that is shorter that what the card did
-some cards complains with an error
-some cards insists with a 61XX/6CXX and the correct length
-some cards send what you requested, and terminates with a 61YY where YY is
the remaining length. This can be used to read a very long apdu in blocks -
but not all cards supports this.

Final word, your driver should not care about emitting the get responses.
This is the responsibility of the application.

The only available software I know that does that is javax.smartcardio, but
this is not a driver. It's an application. Winscard and PCSC do not
automatically send the GET RESPONSE commands.

Regards
Sebastien


On Wed, Jul 7, 2010 at 11:32 AM, Drasko DRASKOVIC <
drasko.drasko...@gmail.com> wrote:

> Hi all,
> I am currently implementing one SC driver and I have run into a
> problem with T=0 Case 2 command response length.
>
> Standard says that this response can be :
> 1) 6C Luicc (i.e. 2 bytes); or
> 2) INS [Data(Luicc)] 90 00 (i.e. Luicc + 3 bytes)
>
> There are other variations with "61" and "6C" PBs, but in any case it
> turns out that for the same command [CLA INS P1 P2 P3=00],
> response can vary in length and is not known in advance.
>
> I can not read byte by byte and analyse it because :
> 1) It should be done in a transport layer, so I have to exit my driver
> RX function
> 2) When I do this, there is a danger of RX FIFO overflow while I am in
> transport layer processing,
> because now driver is not popping bytes from RX FIFO (which is only 8
> bytes). And if a card is sending long answer and
> I exited my driver code to analyse first byte, havoc might happen.
>
> As a result, before calling my drivers RX function I have to know in
> advance how much bytes I have to receive,
> and stay in my driver's RX function until I received this number of
> bytes, while popping RX FIFO to some location in memory.
>
> What is the best way to implement Case 2 response END detection :
> 1) To demand always 256 (maximum) length from UICC and have timeout
> which will say : no more characters arriving, so it must be the end of
> message.
> 2) To insert some kind of T=0 dependence in the driver itself
> (datalink layer) which will take a look at every byte arriving (which
> I did not want to do. I wanted to keep byte sending/receiving
> transparent for the driver, and do analysis in the transport layer. I
> do not want to pollute my driver with T=0 dependencies).
> 3) Something other that I am missing right now ?
>
>
> BTW.
> Luicc is defined like :
>
> Luicc: exact length of data available in the UICC to be returned in
> response to the case 2 or 4 Command received by
> the UICC
>
> Is it always not known by the terminal before issuing first Case 2
> command, or there is a way to know this value in advance (I guess no,
> and I guess it changes dynamically depending on the command and the
> card state.)
>
> BR,
> Drasko
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Re: Open readers and iso7816 question

[Sébastien Lorquet]

On Tue, Jul 6, 2010 at 7:03 PM, Luisa  wrote:

> Hi Drasko and Sebastien,
>
> Drasko, my fault. I meant 9600 Hz on my last email, rather than 96Khz.
>
>
OK, I thought you sent something like 20MHz to your card :)


> And, Sebastien, that comment was unvaluable! I couldn't get to a point
> where that would had shown up from trial and error. So thanks both!.
>
> Don't mention it :)


> Well, I'm not still getting it. I'd say my card is definetely not
> answering me each 372uS. Though I've got yet some tests to be done.
> Will keep on trying, but the situation is being the same, whatever I
> do, the card asnwers me with just the TS at a fixed speed, above the
> 372uS between bits.
>
> Also, just to know I'm not wrong with this as well, I'm supossed to
> toggle the clock line each etu, don't I? or does the card expects a
> high and just next to it, a low on the clock line? I'm using the
> former, though have also tried with the latter with no success.
>
>
As noted by Drasko, ISO7816 is not I2C or SPI (data bits synchronous to a
clock signal). The bus is really asynchronous, ie the clock line is really
the CPU clock signal used to drive all the internal logics, and the IO
signal is driven by an UART, like a PIC or a 8051, with a baud rate
generator. This is why it's called asynchronous. The etu is of course
related to the clock speed, for example the atr is sent at 372 clocks cycles
per ETU.

FYI: the latest native card I worked with had an internal oscillator, and
only uses the input clock signal to detect whether someone is trying to
cheat. So the IO bit rate has really nothing to do with the input clock :-)

FYI2: once unpon a time, when Roland was still young, the clock line was
driven by a bare quartz oscillator made from an inverter gate, and the IO
line was connected to both TxD and RxD of a RS-232 port (after level
conversion). If the quartz runs a 3.57 MHz, then 357 / 372 = 9600 bauds
and you can use a basic PC UART with the proper data bits and parity. Now
everything is USB, CCID, and we have SoC and microcontrollers, so we don't
need these tricks anymore! But I still have such a reader on my desk when I
need to be "sure" :)

The behaviour of you card is extremeley clear and normal. You basically send
a 9600 Hz clock. The card detects this low frequency condition just after
sending TS, which is sent in hardware, but not the other bytes. This
behaviour seems to show that your card is recent and have a free running
clock, not dependent on the input clock frequency. You're lucky to see TS
and not a mute card.

So basically the card is extremely underclocked, and not overclocked as I
thought. and it thinks you're trying to hack it: observing the internal
states by slowing down the CPU, which is an antique attack vector detected
by all modern card hardwares.

Cards typically work correctly when Fclk is between 1 and 5 MHz. Out of
these bounds, the security detectors are activated and the card is muted as
soon as possible.


In fact, I noticed the card is giving me that TS byte alone even when
> I don't toggle the clock at all during the reset sequence.
>
> One more argument for the free running internal clock.

For the record, I'm expecting data from the card after I toggle the clock
> line.
>
> And about the hardware, is within the allowed tollerances. My guess is
> that the problem is either in my firmware, or in my spanish id card
> not allowing a cold reset at 5 volts (perhaps the majority of chips
> have already gone down to 3.3 or so, I don't know).
>
>
Per ISO7816-3, all cards are *required* to work at 5 volts, and some of them
accepts a lower voltage.


> That's all by now. I did setup a google code account, though I've only
> uploaded the schematics:
>
> http://openscr.googlecode.com/files/breakout.pdf
>

Looks very good.
If I were you, I would use a GPIO to detect card insertion. This event can
be used to trigger card activation, reset sequence, ATR reading and optional
PPS exchange. Do you plan to connect your reader to a PC via a serial port?
TxD and RxD are still free on PD0 and PD1.

Regards
Sebastien


> Regards,
>
>
>
>
Regards
Sebastien




> On 7/5/10, Sébastien Lorquet  wrote:
> > You're overclocking your card and the hardware overclock detector inside
> the
> > card stops the card. Only TS is sent because this is automatic and
> hardware
> > driven, but as soon as software starts, HW detectors are enabled, the
> faulty
> > condition is detected and the card is muted in a while(1); loop.
> >
> > At reset, a card MUST be clocked a 372 etu (default params) and the clock
> > must be kept within limits, ie at a max of ~4 MHz
> >
> > Are you sure the voltages are in the mandated range? 5V 

Re: [Muscle] Re: Open readers and iso7816 question

[Sébastien Lorquet]

You're overclocking your card and the hardware overclock detector inside the
card stops the card. Only TS is sent because this is automatic and hardware
driven, but as soon as software starts, HW detectors are enabled, the faulty
condition is detected and the card is muted in a while(1); loop.

At reset, a card MUST be clocked a 372 etu (default params) and the clock
must be kept within limits, ie at a max of ~4 MHz

Are you sure the voltages are in the mandated range? 5V +- 5%, or 10% don't
remember which tolerance must be met. Card also have over / under voltage
detectors.

Sebastien

On Sun, Jul 4, 2010 at 11:26 PM, Drasko DRASKOVIC <
drasko.drasko...@gmail.com> wrote:

> On Sun, Jul 4, 2010 at 10:48 PM, Luisa  wrote:
> > Hi,
> >
> > Thanks for your answers.
> >
> > I've got a bit further with this, though not much more either.
> >
> > I found out the card, albeit being initalized as the iso says, and
> > having the clock line toggling @ 96000 Hz, is answering me with a bit
> > each +/- 20 microseconds.
>
> Why are you clocking your card with 96kHz ? Should not it be clocked 1-5Mhz
> ?
>
> What is "bit" in your case ? Is it value during one ETU, as it should
> be, or you are looking your clock (which is wrong) ?
>
> Clock your card with 1Mhz, and have in mind ETU value while decoding
> characters, because it defines your baud rate. Inital ETU for ATR will
> be 372/1Mhz = 372uS. "Bit" is a value taken during this period.
> Character duration will accordingly be 1(start bit) + 8 + 1(parity
> bit)  + 2(guard bits) = 12 ETUs, i.e. 12*372uS.
>
> BR,
> Drasko
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Re: Open readers and iso7816 question

[Sébastien Lorquet]

well that's the ETSI battery powered phone point of view :-)

By ISO7816-3, all cards are required to support 5V, so this voltage and only
this one can be used in an experimental, non battery powered device. Low
voltage is a desirable option but not an absolute requirement. So playing
with TTL is enough for a ATR acquisition test.

Sebastien
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Re: null procedure byte for T=0, vs normal presponse data

[Sébastien Lorquet]

Not sure, but I'd say no. Just compare INS and the procedure byte, nothing
else. What does "$" stands for?

On Fri, Jul 2, 2010 at 2:55 PM, Wayne  wrote:

> Hi sebastien,
> I found a linux driver with source for a cowitoco reader device. What
> it did is the same to your way.
> And I found another problem, it judge the ACK PB in this way:
> if ( (Response[0] $ 0x0E ) == ( INS $ 0x0E ))...
> Is it corect?
>
> BR
> Wayne
>
> On 7/2/10, Sébastien Lorquet  wrote:
> > Hi,
> >
> > For an outgoing command, when data is to be sent from the card to the
> host,
> > the card answers a ACK byte (equals to INS), then the actual data bytes.
> >
> > So after sending the 5 bytes header CLA INS P1 P2 P3, you just have to
> read
> > one byte from the card: if it is 0x60, then wait. If it the INS you sent,
> > then read the GET RESPONSE data. Else, that's a SW1 (6X,9X) or an error.
> >
> > A consequence is that INS=$6x and INS=$9x are forbidden.
> >
> > At least that's my understanding. Anyone, please correct me if I'm wrong.
> >
> > Regards
> > Sebastien
> >
> > PS: quoting ISO7816-3:
> >
> > After transmitting the header as a string of five characters, the
> interface
> > device shall wait for a character
> > conveying a procedure byte. There are three types of procedure bytes, see
> > Table 11.
> >
> > 􀁿 If the value is '60', it is a NULL byte. It requests no action on data
> > transfer. The interface device shall wait
> > for a character conveying a procedure byte.
> >
> > 􀁿 If the value is '6X' or '9X', except for '60', it is a SW1 byte. It
> > requests no action on data transfer. The
> > interface device shall wait for a character conveying a SW2 byte. There
> is
> > no restriction on SW2 value.
> > NOTE ISO/IEC 7816-4 enforces '60' as invalid value of SW1, as well as any
> > value different from '9X' and '6X'.
> >
> > 􀁿 If the value is the value of INS, apart from the values '6X' and '9X',
> it
> > is an ACK byte. All remaining data
> > bytes if any bytes remain, denoted Di to Dn, shall be transferred
> > subsequently. Then the interface device
> > shall wait for a character conveying a procedure byte.
> >
> > NOTA: this is the case you're requesting. It implies that you MUST know
> the
> > direction of the transfer, incoming or outgoing.
> >
> > 􀁿 If the value is the exclusive-or of 'FF' with the value of INS, apart
> > from the values '6X' and '9X', it is an
> > ACK byte. Only the next data byte if it exists, denoted Di, shall be
> > transferred. Then the interface device
> > shall wait for a character conveying a procedure byte.
> >
> > NOTA: AFAIK this is not used / supported in modern cards.
> >
> > 􀁿 Any other value is invalid.
> >
> >
> > On Fri, Jul 2, 2010 at 4:31 AM, Wayne  wrote:
> >
> >> Hi there,
> >> Sorry to disturb you.
> >>
> >> I'm comfused to a problem in the ISO7816-3, as regard to T=0 protocol.
> >> It said, a card can response a "60" as NULL procedure byte to extend
> >> waiting time.
> >> And when the should have valid data to send back, such as response to
> "GET
> >> RESPONSE" command,
> >> how the interface distinguished the NULL PB form narmal data in the
> >> response, which is followed by SW1,SW2.
> >>
> >> Any comment is appreciated.
> >> Thanks.
> >>
> >> B.R.
> >> Wayne
> >>
> >> ___
> >> Muscle mailing list
> >> Muscle@lists.musclecard.com
> >> http://lists.drizzle.com/mailman/listinfo/muscle
> >>
> >>
> >
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Re: Open readers and iso7816 question

[Sébastien Lorquet]

Hi,

from your problem I would say: double and triple check the card activation
sequence. If your software has a slight problem with that, you won't get
anything. Sequencing as well as delays are important.

The DS8007 chip may help you, at least for understanding, see
http://datasheets.maxim-ic.com/en/ds/DS8007.pdf page 28.

Regards
Sebastien

On Fri, Jul 2, 2010 at 2:04 PM, Luisa  wrote:

> Thanks, I see more or less what's going on.
>
> Besides of nobody's answers...how stupid is to have free software for
> which no free hardware can be found?
>
> On 6/30/10, Luisa  wrote:
> > Hello,
> >
> > In my spare time, I'm trying to make a smart card reader, for which
> > I'm using an 8 bits microcontroller.
> >
> > I've written a state machine within a timer interrupt which strictly
> > implements the iso7816 as I could read of it here:
> >
> > http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816.aspx
> >
> > However, I'm not even getting an ATR out of the card.
> >
> > Although I don't have oscilliscope or logic analizer, I've revised my
> > code and my hardware setup as many times as I can remember. Also,
> > since I begun with hardware testing, use to check the card I'm using
> > for it frequently at a friend's home, where her reader says my card is
> > ok.
> >
> > I'm begining to suspect that I'm either missing something completely
> > obvious for the score, or that nowaday's cards don't make use of the
> > standard above mentioned (at least not how it's explained on the link
> > above).
> >
> > So I was just wondering if anyone could provide some hints or
> > insigths? Also, is there any known open reader with firmware available
> > somewhere? (doesn't matter processor, protocol or whatsoever, just
> > tryng to catch what I'm doing wrong here)
> >
> > I've seen some on the net, but all of them offering support for memory
> > cards (of the sort of Siemens SLE chips), rather than proper iso7816
> > ones, and so the reset sequence is not the same as described in the
> > above standard.
> >
> > Thanks,
> >
> > Luisa
> >
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] null procedure byte for T=0, vs normal presponse data

[Sébastien Lorquet]

Hi,

For an outgoing command, when data is to be sent from the card to the host,
the card answers a ACK byte (equals to INS), then the actual data bytes.

So after sending the 5 bytes header CLA INS P1 P2 P3, you just have to read
one byte from the card: if it is 0x60, then wait. If it the INS you sent,
then read the GET RESPONSE data. Else, that's a SW1 (6X,9X) or an error.

A consequence is that INS=$6x and INS=$9x are forbidden.

At least that's my understanding. Anyone, please correct me if I'm wrong.

Regards
Sebastien

PS: quoting ISO7816-3:

After transmitting the header as a string of five characters, the interface
device shall wait for a character
conveying a procedure byte. There are three types of procedure bytes, see
Table 11.

􀁿 If the value is '60', it is a NULL byte. It requests no action on data
transfer. The interface device shall wait
for a character conveying a procedure byte.

􀁿 If the value is '6X' or '9X', except for '60', it is a SW1 byte. It
requests no action on data transfer. The
interface device shall wait for a character conveying a SW2 byte. There is
no restriction on SW2 value.
NOTE ISO/IEC 7816-4 enforces '60' as invalid value of SW1, as well as any
value different from '9X' and '6X'.

􀁿 If the value is the value of INS, apart from the values '6X' and '9X', it
is an ACK byte. All remaining data
bytes if any bytes remain, denoted Di to Dn, shall be transferred
subsequently. Then the interface device
shall wait for a character conveying a procedure byte.

NOTA: this is the case you're requesting. It implies that you MUST know the
direction of the transfer, incoming or outgoing.

􀁿 If the value is the exclusive-or of 'FF' with the value of INS, apart
from the values '6X' and '9X', it is an
ACK byte. Only the next data byte if it exists, denoted Di, shall be
transferred. Then the interface device
shall wait for a character conveying a procedure byte.

NOTA: AFAIK this is not used / supported in modern cards.

􀁿 Any other value is invalid.


On Fri, Jul 2, 2010 at 4:31 AM, Wayne  wrote:

> Hi there,
> Sorry to disturb you.
>
> I'm comfused to a problem in the ISO7816-3, as regard to T=0 protocol.
> It said, a card can response a "60" as NULL procedure byte to extend
> waiting time.
> And when the should have valid data to send back, such as response to "GET
> RESPONSE" command,
> how the interface distinguished the NULL PB form narmal data in the
> response, which is followed by SW1,SW2.
>
> Any comment is appreciated.
> Thanks.
>
> B.R.
> Wayne
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] I now have a blog to talk about smart cards

[Sébastien Lorquet]

Yes, I think Ludovic's blog will be interesting for the developer point of
view :)


PS:
Burak, you wrote a nice blog entry about Calypso :)


On Fri, Apr 9, 2010 at 4:30 PM, Burak Ilgicioglu wrote:

> I have blog on smart cards, but on the contactless and dual interface ones
> :)
>
> www.contactless-world.com
>
> Mainly focused on the application and functionality level, rather than
> coding like Ludovic's one.
>
> Regards,
>
>
> On Fri, Apr 9, 2010 at 5:24 PM, Jonas Gulle  wrote:
>
>> This is great, finally a blog about smart cards :)
>>
>> Best regards,
>> Jonas Gulle
>>
>>
>> On Thu, Apr 8, 2010 at 1:37 PM, Ludovic Rousseau <
>> ludovic.rouss...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I created  a blog to talk about smart card in general and pcsc-lite,
>>> libccid and other projects I work on in particular. I am not a
>>> blogger, this is my first blog.
>>>
>>> http://ludovicrousseau.blogspot.com/
>>>
>>> I have two posts for now:
>>> - Parsing an ATR
>>> - PC/SC sample in different languages
>>>
>>> I don't know if I should also post my blog messages on this mailing
>>> list. Do you have any opinion on this?
>>>
>>> Envoy
>>>
>>> --
>>>  Dr. Ludovic Rousseau
>>> ___
>>> Muscle mailing list
>>> Muscle@lists.musclecard.com
>>> http://lists.drizzle.com/mailman/listinfo/muscle
>>>
>>
>>
>> ___
>> Muscle mailing list
>> Muscle@lists.musclecard.com
>> http://lists.drizzle.com/mailman/listinfo/muscle
>>
>>
>
>
> --
> Burak ILGICIOGLU
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] SCR001

[Sébastien Lorquet]

Hi,


> The CCID device declares only one slot. Using the SIM-size slot looks
> like a hack.
>
>
Probably not a hack but a non-standard commands. SAM slots are not main
slots, security modules are not meant to be removed too often. For example,
the GemProx chipset uses low level commands to talk to the SAM slots, not
"basic" apdu exchange commands. I guess this is the same here.

These special model-specific commands won't have anything to do with a
generic CCID driver I guess.

IIRC, the only reader I know where the SAM is considered as a standard PCSC
visible reader (at least for the windows pcsc driver) is the ACS ACR128U.

just my 2 cents

sebastien
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] SCARD_E_SHARING_VIOLATION information

[Sébastien Lorquet]

Hi,

I know there are problems with the coolkey package on RHEL 5

On linux, also verify that you have no java process trying to use
javax.smartcardio connections running. This conflicts whith native
applications also using pcsclite.

Regards
Sebastien


On Tue, Mar 23, 2010 at 11:54 AM,  wrote:

> I use SCARD_SHARE_EXCLUSIVE mode.
> On the desktops, there are more and more apps trying to use SmartCards...
> Did you try to insert a Card with windows seven for example ... it really
> tries to install a driver for the card the same way of a new peripheral !
>
> I'm sure there will be more and more SHARE card problems in a future (that
> I however hope to be soon) ...
>
> regards,
>
> Gui
>
> - Mail Original -
> De: "Ludovic Rousseau" 
> À: "MUSCLE" 
> Envoyé: Mardi 23 Mars 2010 11h19:24 GMT +01:00 Amsterdam / Berlin / Berne /
> Rome / Stockholm / Vienne
> Objet: Re: [Muscle] SCARD_E_SHARING_VIOLATION information
>
> 2010/3/23  :
> > I'm working with SAM, connected to a critical server with critical
> application.
> > It may happen, someday (or even night), that the application cannot
> connect to a SAM because of SHARING_VIOLATION ...
> > I hope that this will never happen, but in such a situation, we must
> record a maximum of log information that will allow to determine the reason
> of the SHARING_VIOLATION, and find the guilty process to definitively solve
> the issue.
> > On a desktop for example, I encountered this problem. After investigation
> it was a RedHat Gnome applet's fault that try to identify the inserted
> cards.
>
> If your application is the only one using PC/SC you should not have
> any problems (except your owns).
>
> Do you use SCardConnect in SCARD_SHARE_SHARED or SCARD_SHARE_EXCLUSIVE
> mode?
>
> > If there is no official way, would it mean that such a thing could
> however be developed inside PCSC, or at the kernel level ?
>
> pcsc-lite does not store the id of the processes using the readers. So
> anything is possible but development is needed.
> Have you looked at the pcscd logs?
>
> > By the way : "http://www.linuxnet.com/musclecard/index.html"; indicates a
> broken link to "The following article describes the MuscleCard architecture
> and it's components"
> > Can any one fix it ?
>
> I forwarded your request to David Corcoran, maintainer of the web site.
>
> Bye
>
> --
>  Dr. Ludovic Rousseau
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Accessing Smart Card Unique ID (newbee)

[Sébastien Lorquet]

Yes, I feel it's the right way too.
good luck!

Sebastien

On Thu, Mar 11, 2010 at 1:08 PM, Ray Caruso GMAIl wrote:

> Thank you all for your answers. You have pointed me in the right direction.
> I found a resource for each card I need to support that provides the
> specific PDUs I need to send to get the data I am need.
>
> Beat regards,
>
> On Mar 10, 2010, at 11:53 PM, Sébastien Lorquet  wrote:
>
> Hi,
>
> Does this data have a link with what is returned by INIT UPDATE? In this
> case this identifier may not be unique.
>
> Sebastien
>
> On Thu, Mar 11, 2010 at 2:52 AM, Michael StJohns < 
> mstjo...@comcast.net> wrote:
>
>>  If your card is a global platform card -
>>
>> 1) Select the default security domain
>> 2) do a get data on  00 42 and 00 45  (80 CA 00 42 , 80 CA 00 45).  The
>> first is the issuer identification number, the second is the card image
>> number.
>>
>> Either or both of these may be set depending on the issuer of the card.
>> Pre-issue cards probably don't have these set.
>>
>> Also (both for GP and non GP cards), if the ATR historical bytes begin
>> with 80, those bytes may include an issuer and card number or may point to a
>> file on the card which contains them - get a copy of ISO 7816-4 for details.
>>
>>
>> Later, Mike
>>
>>
>>
>>
>> At 01:30 PM 3/10/2010, Ray Caruso wrote:
>>
>> Thank you for the reply. I am sorry about mis-forming the get data PDU- I
>> truely doubt it required that type of response- it did seem a little rude. I
>> should have written XX CA 00 00 00 where XX being the class and I am not
>> sure which instruction class to use. I used FF as a bitmask way of indicated
>> wild carding because all 1's can always be OR'd in.
>>
>> I am reading a manual that states the following:
>>
>>  "The appliance will query the smart card for a unique ID, which is a
>> portion of a reply from a “get data†application protocol data unit
>> (APDU) command. The ID contains unique information such as the smart card
>> manufacturer, smart card chip manufacturer, chip type, batch number, etc
>> that identifies a particular card from other cards."
>>
>> I need to emulate the behavior of the appliance. I am able to verify the
>> card token during development.
>>
>> Thanks Again.
>>
>> On 3/10/2010 11:13 AM, Sébastien Lorquet wrote:
>>
>> Hi,
>> Â
>>  As I understand, every smart card has a unique IDÂ
>>
>>
>> Unfortunately, that single statement is not true.
>> Well, it's not even true at the chip level (I guess every manufacturer has
>> its own system) but there is no standard way to get this "unique number" in
>> the same manner for all cards in the world.
>>
>> Each card model *may* support an unique id, but it is specific to the card
>> model, as well as the method to retrieve it.
>>
>>  that is accessible without security.
>>
>>
>> Â
>>  I need to read this ID from any card within a reader. I have spent some,
>> but not enough, quality time with the ISO 7816-4 spec and understand the
>> formation of smart card request and response APDUs (at least I think I do).
>> I have read that I need to use the get data command as follows:
>>
>> FF CA 00 00 00
>>
>>
>> Nice. You need to spend more time on ISO7816 as the FF class is invalid,
>> it's not a card command but (maybe) a reader command or something else.
>>
>> Moreover if such a magic command existed, someone would have mentioned it
>> somewhere in google.
>> Â
>>
>> However, this fails to provide the correct ID.
>>
>>
>> Sure. Do you at least know what *is* the correct ID you're expecting? :-)
>>
>> Â
>>  Any help on this would be greatly appreciated.
>>
>>
>> First detect the card model in some way, then pray for the card to provide
>> a mean to identify itself, then issue the appropriate valid commands to get
>> it.
>>
>> Regards
>> Sebastien
>>
>> ___
>> Muscle mailing list Muscle@lists.musclecard.com 
>> <http://lists.drizzle.com/mailman/listinfo/muscle>http://lists.drizzle.com/mailman/listinfo/muscle
>>
>>
>>
>> ___
>> Muscle mailing list
>>  Muscle@lists.musclecard.com
>>  <http://lists.drizzle.com/mailman/listinfo/muscle>
>> http://lists.drizzle.com/mailman/listinfo/muscle
>>
>>
>>
>> ___
>> Muscle mailing list
>>  Muscle@lists.musclecard.com
>>  <http://lists.drizzle.com/mailman/listinfo/muscle>
>> http://lists.drizzle.com/mailman/listinfo/muscle
>>
>>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Accessing Smart Card Unique ID (newbee)

[Sébastien Lorquet]

Hi,

Does this data have a link with what is returned by INIT UPDATE? In this
case this identifier may not be unique.

Sebastien

On Thu, Mar 11, 2010 at 2:52 AM, Michael StJohns wrote:

>  If your card is a global platform card -
>
> 1) Select the default security domain
> 2) do a get data on  00 42 and 00 45  (80 CA 00 42 , 80 CA 00 45).  The
> first is the issuer identification number, the second is the card image
> number.
>
> Either or both of these may be set depending on the issuer of the card.
> Pre-issue cards probably don't have these set.
>
> Also (both for GP and non GP cards), if the ATR historical bytes begin with
> 80, those bytes may include an issuer and card number or may point to a file
> on the card which contains them - get a copy of ISO 7816-4 for details.
>
> Later, Mike
>
>
>
>
> At 01:30 PM 3/10/2010, Ray Caruso wrote:
>
> Thank you for the reply. I am sorry about mis-forming the get data PDU- I
> truely doubt it required that type of response- it did seem a little rude. I
> should have written XX CA 00 00 00 where XX being the class and I am not
> sure which instruction class to use. I used FF as a bitmask way of indicated
> wild carding because all 1's can always be OR'd in.
>
> I am reading a manual that states the following:
>
>  "The appliance will query the smart card for a unique ID, which is a
> portion of a reply from a “get data†application protocol data unit
> (APDU) command. The ID contains unique information such as the smart card
> manufacturer, smart card chip manufacturer, chip type, batch number, etc
> that identifies a particular card from other cards."
>
> I need to emulate the behavior of the appliance. I am able to verify the
> card token during development.
>
> Thanks Again.
>
> On 3/10/2010 11:13 AM, Sébastien Lorquet wrote:
>
> Hi,
> Â
>  As I understand, every smart card has a unique IDÂ
>
>
> Unfortunately, that single statement is not true.
> Well, it's not even true at the chip level (I guess every manufacturer has
> its own system) but there is no standard way to get this "unique number" in
> the same manner for all cards in the world.
>
> Each card model *may* support an unique id, but it is specific to the card
> model, as well as the method to retrieve it.
>
>  that is accessible without security.
>
>
> Â
>  I need to read this ID from any card within a reader. I have spent some,
> but not enough, quality time with the ISO 7816-4 spec and understand the
> formation of smart card request and response APDUs (at least I think I do).
> I have read that I need to use the get data command as follows:
>
> FF CA 00 00 00
>
>
> Nice. You need to spend more time on ISO7816 as the FF class is invalid,
> it's not a card command but (maybe) a reader command or something else.
>
> Moreover if such a magic command existed, someone would have mentioned it
> somewhere in google.
> Â
>
> However, this fails to provide the correct ID.
>
>
> Sure. Do you at least know what *is* the correct ID you're expecting? :-)
>
> Â
>  Any help on this would be greatly appreciated.
>
>
> First detect the card model in some way, then pray for the card to provide
> a mean to identify itself, then issue the appropriate valid commands to get
> it.
>
> Regards
> Sebastien
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
>
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
>  http://lists.drizzle.com/mailman/listinfo/muscle
>
>
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Accessing Smart Card Unique ID (newbee)

[Sébastien Lorquet]

Hi,


> As I understand, every smart card has a unique ID
>

Unfortunately, that single statement is not true.
Well, it's not even true at the chip level (I guess every manufacturer has
its own system) but there is no standard way to get this "unique number" in
the same manner for all cards in the world.

Each card model *may* support an unique id, but it is specific to the card
model, as well as the method to retrieve it.

that is accessible without security.
>



> I need to read this ID from any card within a reader. I have spent some,
> but not enough, quality time with the ISO 7816-4 spec and understand the
> formation of smart card request and response APDUs (at least I think I do).
> I have read that I need to use the get data command as follows:
>
> FF CA 00 00 00
>

Nice. You need to spend more time on ISO7816 as the FF class is invalid,
it's not a card command but (maybe) a reader command or something else.
Moreover if such a magic command existed, someone would have mentioned it
somewhere in google.


>
> However, this fails to provide the correct ID.
>

Sure. Do you at least know what *is* the correct ID you're expecting? :-)



> Any help on this would be greatly appreciated.
>
>
First detect the card model in some way, then pray for the card to provide a
mean to identify itself, then issue the appropriate valid commands to get
it.

Regards
Sebastien
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Fwd: [Muscle] new BETA versions of pcsc-lite and libccid

[Sébastien Lorquet]

>
> > I get a problem to start pcscd , and looking at
>
 > /usr/sbin/update-reader.conf, I find two unsubstituted @conf...@variables.
> substituting with @sysconfdir@ in $tarball/etc/update-reader.conf.in and
> reconfiguring solved the problem. Install is ok, readers are detected.

Fixed in revision 4751. Thanks.

Great


> I get lots of ccid_usb.c:633: ReadUSB() usb_bulk_read(%03d/%03d): No error
> > in /var/log/messages
>
> I am surprised to see "%03d/%03d" in the log. Unless "%03d" is the
real filename on your system, but I would be surprised.


No. I really get numeric values here. I think they are device/bus IDs. I
used a printf format because the values were different on each line :-)

as said after, these lines only appear once per reader, they're not so
important.


> Trying a stress test with our SAM farm now: seems to work as before.
> > So that will be a work for me once the small fix is applied.
>
> Thanks for testing.


You're welcome.

Sebastien
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] new BETA versions of pcsc-lite and libccid

[Sébastien Lorquet]

>
>
> I get lots of ccid_usb.c:633: ReadUSB() usb_bulk_read(%03d/%03d): No error
> in /var/log/messages
>
>
sorry this one is only seen once per inserted reader, not "a lot" as said
before. Forgot to edit my previous message.

Sebastien
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] new BETA versions of pcsc-lite and libccid

[Sébastien Lorquet]

Hi,

after configuring pcsc-lite like this:

./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
--disable-libhal

I get a problem to start pcscd , and looking at
/usr/sbin/update-reader.conf, I find two unsubstituted @confdir@ variables.

substituting with @sysconfdir@ in $tarball/etc/update-reader.conf.in and
reconfiguring solved the problem. Install is ok, readers are detected.

I get lots of ccid_usb.c:633: ReadUSB() usb_bulk_read(%03d/%03d): No error
in /var/log/messages

Trying a stress test with our SAM farm now: seems to work as before.

So that will be a work for me once the small fix is applied.

Regards
Sebastien

On Wed, Feb 10, 2010 at 2:07 PM, Ludovic Rousseau <
ludovic.rouss...@gmail.com> wrote:

> Hello,
>
> I uploaded to [1] new versions of pcsc-lite and libccid. They have
> many and important changes (in particular for pcsc-lite). I would like
> to test these versions before I release them as stable. They work for
> me and should work for you too.
>
> I will not detail any specific change here but do not hesitate to ask
> more for information.
>
> Regards
>
> Changes for libccid:
> 1.3.12 BETA - 10 Feb 2010, Ludovic Rousseau
>- add support of Todos AGM2 CCID, Cherry SmartTerminal XX7X, Smart
>  SBV280, Ask CPL108, German Privacy Foundation Crypto Stick v1.2
>- better support of Dell keyboard
>- better support of multislot readers (like the GemCore SIM Pro)
>- better support of SCM SCR3310
>- The Covadis Véga-Alpha reader is a GemPC pinpad inside. So we use
>  the same code to:
>  . load the strings for the display
>  . avoid limitation of the reader
>- IFDHControl(): the (proprietary) get firmware version escape
>  command is allowed with a Gemalto reader
>  . the (proprietary) switch interface escape command is allowed on
>  the Gemalto GemProx DU
>  . return IFD_ERROR_NOT_SUPPORTED instead of
>  IFD_COMMUNICATION_ERROR if the dwControlCode value is not
>  supported
>  . return IFD_ERROR_INSUFFICIENT_BUFFER when appropriate
>- IFDHGetCapabilities(): add support of SCARD_ATTR_ICC_PRESENCE and
>  SCARD_ATTR_ICC_INTERFACE_STATUS
>- support extended APDU of up to 64kB with APDU readers.
>- get the language selected during Mac OS X installation as language
>  to use for Covadis Véga-Alpha and Gemalto GemPC PinPad pinpad
>  readers
>- some minor bugs removed
>
>
> Changes for pcsc-lite:
> pcsc-lite-2.0.0 BETA: Ludovic Rousseau
> 10 Feb 2010
> - redesign the client/server communication:
>  * no more shared memory used (allow pcscd and libpcsclite1.so to be on
>  different computer and talk over a network)
>  * no more difference between short and extended APDU
>  * no more use of a /var/run/pcscd/pcscd.events/ directory. events are
>  sent through the socket
>  * simpler command format between client and server
>  The side effect is that you are not able to mix an old pcscd with a
>  new libpcsclite1.so or the reverse. SCardEstablishContext() will fail
>  unless you update both sides of the communication.
> - Use lists instead of fixed size arrays to store handles.
>  It is now possible to have:
>  - 200 simultaneous PC/SC clients instead of 16
>  - 200 SCardConnect per client instead of 16
>  - 200 clients per reader instead of 16
>  The default value of 200 can be changed by giving an argument to pcscd
>  --max-thread --max-card-handle-per-thread --max-card-handle-per-reader
>  Thanks to Jean-Luc Giraud for the big patch
> - Make SCardReconnect(), SCardStatus() and SCardTransmit() block instead
>  of returning SCARD_E_SHARING_VIOLATION immediately. These functions
>  will then behave like on Windows.
>  This can happen if these functions are called when the reader is
>  locked by a PCSC transaction
>  (SCardBeginTransaction/SCardEndTransaction).
>  You can define the environment variable PCSCLITE_NO_BLOCKING to use
>  the old behavior.
>  Thanks to Jean-Luc Giraud for the patch.
>  http://archives.neohapsis.com/archives/dev/muscle/2010-q1/0041.html
> - SCardEstablishContext(): try to start the pcscd daemon if not already
>  running.
>  . pcscd will suicide itself after 60 seconds of inactivity if it is
>  started using --auto-exit. This is the default behavior when pcscd is
>  started by libpcsclite
>  . Set PCSCLITE_PCSCD_ARGS with the argument you want to pass to pcscd in
>  autostart Only one argument is passed. The space character is not a
>  separator. example: export PCSCLITE_PCSCD_ARGS=-dfa
> - SCardListReaders(): can use SCARD_AUTOALLOCATE
> - SCardGetAttrib(): return SCARD_E_INSUFFICIENT_BUFFER if the driver
>  returns IFD_ERROR_INSUFFICIENT_BUFFER
>  . add support of SCARD_ATTR_DEVICE_FRIENDLY_NAME as it is better
>  implemented in pcscd (it knows the friendly name)
> - SCardGetStatusChange(): Calling with cReaders == 0 will now just
>  return SCARD_S_SUCCESS
>  . Use the special reader name "\\?PnP?\Notification" to wait for a
>  reader event notification
> - SCardTransmit()

[Muscle] Smart card reader archaeology

[Sébastien Lorquet]

Hi all,

I found an old Philips PE122 reader. Is there any chance to revive this
grandfather? google is not very talkative... :)

pointers to the RJ-45 pinout and/or driver would be appreciated.

Regards
Sebastien
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] [PATCH] Quirk for BCM5880/5881 GetSlotStatus

[Sébastien Lorquet]

and in my opinion a quirks list should have a mask feature to include more
than one model.

Regards
Sebastien

On Mon, Feb 1, 2010 at 2:06 PM, Ludovic Rousseau  wrote:

> 2010/2/1 Max Vozeler :
> > This patch adds a workaround for unusual behaviour of Broadcom
> > BCM5880/5881 readers. They misreport an absent card as "Hardware
> > Error" in GetSlotStatus.
> >
> > To work around it, we turn the HW_ERROR answer to GetSlotStatus
> > into "No error, no card inserted".
> >
> > Since we need some way to look up the required quirk based on
> > USB vendor/product ID, this patch adds some simple quirk lookup
> > functions which can also be used for future quirks.
>
> I don't like the quirks lookup functions idea.
> In the code I detect bogus readers using:
> if (SPR532 == ccid_descriptor->readerID)
>
> Bye
>
> --
>  Dr. Ludovic Rousseau
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Problems with CardTerminal Block methods in Linux using Threads and Smartcardio (Java)

[Sébastien Lorquet]

This is not the first bug we discover in this api.

there's also a problem in T=0 when a case 1 (4 bytes) command produces a
6Cxx: P2 gets overwritten :)

Is it possible to define variables per-thread? this is related to Thread
Local Storage (TLS) isn't it?

Regards
Sebastien
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Problems with CardTerminal Block methods in Linux using Threads and Smartcardio (Java)

[Sébastien Lorquet]

$(JDK_SRC_ROOT)/j2se/src/share/classes/sun/security/smartcardio/PcscTerminals.java
tells:

final class PCSCTerminals extends CardTerminals {

// SCARDCONTEXT, currently shared between all threads/terminals
private static long contextId;

// terminal state used by waitForCard()
private Map stateMap;

PCSCTerminals() {
// empty
}

static synchronized void initContext() throws PCSCException {
if (contextId == 0) {
contextId = SCardEstablishContext(SCARD_SCOPE_USER);
}
}

...

so the context is shared. so a single poller thread is required.

Regards,
Sebastien
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Problems with CardTerminal Block methods in Linux using Threads and Smartcardio (Java)

[Sébastien Lorquet]

Hi,

I think a single polling thread is what OCF is/was using to generate sc
events.

The correct way of doing multithread pcsclite is having one SCARDCONTEXT per
thread, think of contexts as networks connections using sockets. this may
not be possible (IIUC) with javax.smartcardio.

Regards
Sebastien

On Wed, Jan 6, 2010 at 1:14 PM, Caden.smith Smith
wrote:

> Yes,
>
> thank you, I read that since one thread blocks with infinite time the other
> commands in the daemon but will be cued and not execute.
>
> I guess I will have to go with something less tidy/clean like sleeping each
> thread for 1 or 2 secs and verify if "isCardInserted" in all terminal
> threads...
>
> I remembered this approach, but do you have by any chance a different
> solution in order to have generic code for the two platforms?
>
> Cad.
>
>
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] interface between IFD handler and smart card driver

[Sébastien Lorquet]

Hi,

I'm not a smart card driver expert, but if you do require communication
between the kernel and the user space, then a device node plus file
operations is a reasonable requirement :-) . The user space library will be
a wrapper for the kernel module.

ccid commonly uses libusb, this is why it does not need any specific kernel
module. the kernel interface is in this lib.

Regards
Sebastien

On Wed, Dec 23, 2009 at 8:23 PM, Feng Ye  wrote:

>  Hello there,
>
> We are developing smart card driver for our SoC, which has cpu and smart
> card interface.
> The drivers on the muscle website are either for serial or usb external
> readers, while ours are directly connected.
> We would like to put the IFD handler on user space and smart card driver on
> kernel space. We couldn't find a sample driver architected like this.
> Looks like we need to define our own device (like /dev/smartcarad) and our
> own IOCTL (for communicating between IFD handler and the smart cacrd
> driver)?
>
> Thanks,
> Feng
>
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] pkcs11?

[Sébastien Lorquet]

Just my 2 cents, muscleTool on debian does not like my muscle applet cards
too. they have the a0 00 0101 aid.

My solution to on card cryptography was to buy some cryptoflex which are
realy pkcs15 cards :( too bad.

Seb

On Thu, Dec 3, 2009 at 11:13 PM, João Poupino wrote:

> Hi,
>
>
> Ralf Schlatterbeck wrote:
>
>> I now have successfully built and loaded the muscle applet onto my
>> Gemalto TOP IM FIPS CY2 (Cyberflex  Access 64k v2)
>>
>
> Good to hear :)
>
>
>
>> I can -- using opensc tools -- build a pkcs15 structure on the card,
>> erase, initalize, set an ID and generate a key. But when I try to
>> use the card with pkcs11 and openssl I'm getting errors (see below).
>> I'm using the opensc-pkcs11 library.
>>
>> Should I use another pkcs11 lib that is more specific to muscle?
>>
>> Or any hints on what might be wrong with my configuration/card/etc?
>>
>> Working:
>> pkcs15-init -E --create-pkcs15 --no-so-pin
>> pkcs15-init --store-pin --auth-id 01 --label "User Name"
>> pkcs15-tool --list-pins
>> pkcs15-init --generate-key rsa/1024 --auth-id 01
>> #(or alternatively a 2048 bit key)
>> pkcs15-tool --list-keys
>> pkcs15-tool --list-public-keys
>>
>> Errors:
>> % openssl req -days 3650 -new -out $CLIENT.csr -config openssl.cnf -engine
>> pkcs11 -keyform engine -key 0:45 -sha1
>> engine "pkcs11" set.
>> [opensc-pkcs11] iso7816.c:102:iso7816_check_sw: Unknown SWs; SW1=9C,
>> SW2=02
>> [opensc-pkcs11] sec.c:201:sc_pin_cmd: returning with: Card command failed
>> Login failed
>>
>
> 0x9C02 is "Auth Failed". Are you sure you have entered the correct PIN?
>
> Try this, just to be sure: set all PINs (including the ones in pkcs15-init)
> to . Then try the same operation. If it works, I think I know the
> solution.
>
> 
>
> João
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] applet download for Gemalto TOP IM FIPS CY2

[Sébastien Lorquet]

Hi,

nvdatalimit is not the applet size. It's a mean to say to the card, "my
applet won't exceed nvcodelimit bytes, so reject the load operation if I'm
lying"

The same applies for nvdatalimit: "hello card, me, nice applet, I promise
that I will not use more than nvdatalimit bytes of eeprom for my persistent
objects, please check I'm not lying".

My experience is that for all normal "experimentation" situations the
-nv*limit option are 100% useless.
In your own testing card, who cares if your applet uses 1.2 k of ram instead
of 1.1 k? or 18574 bytes of eeprom instead of 18543?

This is only putting additional complexity to a somewhat complex situation.
It's sufficiently complicated to deal with SCP version, option, keys, auth
level, card manager AID (a sort of "myth", the card manager is very often
default selected so you don't need to select it if you don't know what
"privilege 04" means and your card is not a SIM+javacard that could have a
default selected SIM applet), ...

I guess these options were invented when company A owns a card, accept to
load the applet of company B provided it does not consume all the space A
could use in the future (and pays for the space it intends to use).

Just don't use these 'limit' args, they are not needed for a successful
loading.

But don't forget the Trusted Labs captransf.jar if you want to load anything
on a cyberflex like card.

Regards,
Sebastien.

On Thu, Dec 3, 2009 at 7:03 PM, emanuele gringeri wrote:

> Ralf Schlatterbeck ha scritto:
> > Answering my own mail:
> >
> > On Thu, Dec 03, 2009 at 02:06:15PM +0100, Ralf Schlatterbeck wrote:
> >
> >> Just got my Gemalto TOP IM FIPS CY2 (Cyberflex  Access 64k v2)
> >>
> >> But downloading the MCardApplet -- both my homegrown one and one
> >> downloaded from
> >>
> http://www.opensc-project.org/opensc/attachment/wiki/Cyberflex/CardEdgeII.ijc
> >> leads the following error after issuing the install_for_install command:
> >>
> > [...]
> >
> > I've done a little investigation into the magic numbers used by
> > gpshell. Looks like I can find out the argument to the first select
> command:
> >
> > select -AID a300
> >
> > by doing:
> > enable_trace
> > establish_context
> > card_connect
> > open_sc -security 1 -keyind 0 -keyver 0 -mac_key
> 404142434445464748494a4b4c4d4e4f -enc_key 404142434445464748494a4b4c4d4e4f
> > get_status -element 80
> >
> > this gives me the following output (in addition to some debug output):
> > List of applets (AID state privileges)
> > a3007   0
> >
> > The other two AIDs seem to be dependent on the applet used (the applet
> codes
> > the applet ID internally). I came to this conclusion by changing the IDs
> > in the hello world downloader and seeing it fail.
> >
> > Then I looked into the download script for the hello world applet.
> > When unpacking the HelloWorld.cap.transf or HelloWorld.cap file with
> unzip
> > I'm getting several .cap files. The Applet.cap contains the following
> > (in hex):
> >
> > 00 03 00 0e 01 0a a0 00 00 00 62 03 01 0c 01 01 00
> >   ^
> > 10 14
> > 11
> >
> > Now compare this with the Applet IDs used for downloading, citing
> > from helloInstallCyberflexAccess64k.txt from the gpshell distribution:
> >
> > install_for_install -instParam 00 -priv 02 -AID a0006203010c0101
> -pkgAID a0006203010c01 -instAID a0006203010c0101 -nvDataLimit 500
> > 
> 
> >
> > with that info I was able to find out the correct downloading script for
> > my homegrown applet, note the commented-out commands which use the wrong
> > applet ID (see below). My applet seems to use the AID a101
> >
> > Now my question:
> > - Is there some documentation on these magic numbers?
> > - Seems in all docs the MCardApplet uses the other ID I tried first
> >   so something in my build-process probably doesn't correctly set
> >   the applet ID. How should I change that?
> >
> > # gpshell script for loading applet into card:
> > enable_trace
> > establish_context
> > card_connect
> > select -AID a300
> > open_sc -security 1 -keyind 0 -keyver 0 -mac_key
> 404142434445464748494a4b4c4d4e4f -enc_key 404142434445464748494a4b4c4d4e4f
> > delete -AID a101
> > delete -AID a1
> > delete -AID a003230101
> > delete -AID a0032301
> > #install_for_load -pkgAID a0032301 -nvCodeLimit 16000  -sdAID
> a300
> > install_for_load -pkgAID a1 -nvCodeLimit 16000 -sdAID
> a300
> > load -file CardEdgeCflex.ijc
> > #install_for_install -instParam 00 -priv 02 -AID a003230101 -pkgAID
> a0032301 -instAID a003230101 -nvDataLimit 16000
> > install_for_install -instParam 00 -priv 02 -AID a101 -pkgAID
> a1 -instAID a101 -nvDataLimit 32000
> > get_status -element 20
> > card_disconnect
> > release_context

Re: [Muscle] MCardApplet for Gemalto TOP IM FIPS CY2 (Cyberflex Access 64k v2): how?

[Sébastien Lorquet]

Hi,

Did you try this?

http://www.linuxnet.com/musclecard/index.html

Regards
Seb
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] is there an up to date list of supported smartcards and small-volume vendors?

[Sébastien Lorquet]

Hi,

We'll see what the PCSClite maintainer has to say, but if I were him, I
would say that

- pcsc supports READERS, not cards. So if a driver sees your token, then the
job of pcsclite is done. Actual smart functionnality of portable objects (be
them tokens or cards) is the responsibility of other projects, possibly
openSC or others.

- a CARD vendor list is not the "business" of pcsclite. Cards that support
ISO7816 will work in ISO7816 readers supported by pcsclite. But you need
other projects to really use the cards.

A nice smart card vendor for small quantities is SmartCardFocus
http://www.smartcardfocus.com/
But I don't known which card you want.

For both points, you should check OpenSC, as mentioned by the cross post
from Martin.

Regards,
Seb

On Tue, Dec 1, 2009 at 1:14 PM, Luke S Crawford  wrote:

>
> so the thing is, whenever I see a HOWTO or other document it seems it's
> for a smartcard that is no longer available (or never was available
> in quantities I can afford.)  I ask in the usual sysadmin places and
> I get hand-wavy responses.  Apparently some people have it working,
> but with cards I can't buy.   Most people use the time based OTP tokens
> that require you to type in some randomly generated password.
>
> Are smartcards that work (for me, 'work' means it allows me to
> authenticate via ssh without exposing my private key)
> available, and if so, from whom?
>
>
>
> --
> Luke S. Crawford
> http://prgmr.com/xen/ -   Hosting for the technically adept
> http://nostarch.com/xen.htm   -   We don't assume you are stupid.
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Multiple threads and SCardGetStatusChange

[Sébastien Lorquet]

Sorry for the spamming:

I may have said something not true: Is the connection opened by
ScardEstablishContext, or by SCardConnect? I would say the first. This means
we really need both a SCARDHANDLE and a SCARDCONTEXT in each thread.

Seb
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Multiple threads and SCardGetStatusChange

[Sébastien Lorquet]

>In theory is it important to call SCardEstablishContext for every thread
and every API call or in real life it only affects cases like
>SCardGetStatusChange with infinite timeout?

Also in practice.

If I understand correctly, SCardEstablishContext() creates a socket
connection using UNIX domain sockets to pcscd. The PCSC API is blocking (you
do not receive card responses in a callback) so imagine the socket is also
blocking, this explains why you need a SCARDCONTEXT for each thread.

Seb
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Multiple threads and SCardGetStatusChange

[Sébastien Lorquet]

I'm working on other software atm.
But I 'll have a set of unit tests to run with this application in the
coming days.
I'll tell you the syslog messages I find.

I don't remember if the pcsc daemon was crashing or stopped working, or our
application crashed.
Readers are all ccid Teo by Xiring and/or SDI SCR3310 (and occasionnaly
gemplus gray square ones).

Seb

On Tue, Dec 1, 2009 at 9:51 AM, Ludovic Rousseau  wrote:

> 2009/12/1 Sébastien Lorquet :
> > hi
> >
> > here we have a multi card application that uses one thread and one
> > SCardEstablishContext per card, and the load is prettily balanced among
> the
> > multiple cards. We can also add and remove cards at runtime. We tested
> the
> > system with up to 20 cards, it worked without a glitch. The overall
> > transaction time is really reduced with more cards. (we have a command
> > queuing daemon).
>
> Thanks for your return.
>
> > The only problem is when we remove usb readers when the application is
> > running (using polled libusb, not hal)
> > But that's ok.
>
> How could you describe the problem?
>
> Bye
>
> --
>  Dr. Ludovic Rousseau
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Multiple threads and SCardGetStatusChange

[Sébastien Lorquet]

hi

here we have a multi card application that uses one thread and one
SCardEstablishContext per card, and the load is prettily balanced among the
multiple cards. We can also add and remove cards at runtime. We tested the
system with up to 20 cards, it worked without a glitch. The overall
transaction time is really reduced with more cards. (we have a command
queuing daemon).

The only problem is when we remove usb readers when the application is
running (using polled libusb, not hal)
But that's ok.

(this post is not a bug report but a success report :-) )

Regards,
Sebastien.

On Tue, Dec 1, 2009 at 8:57 AM, Ludovic Rousseau  wrote:

> 2009/11/30 Martin Paljak :
> > Hi.
>
> Hello,
>
> > What is the status of multithreaded access to pcsc-lite? Is it supposed
> to work?
>
> Yes. But each thread needs to have its own context. You shall call
> SCardEstablishContext() in the newly created thread and you program
> should work (not yet tested with your sample).
>
> I already tried to detect the problem and return
> SCARD_E_INVALID_HANDLE but that is not easy.
>
> I note to add this "limitation" to the "Known differences with
> Microsoft Windows WinSCard implementation:"
>
> Bye
>
> --
>  Dr. Ludovic Rousseau
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] support for iso 7816-3/4

[Sébastien Lorquet]

Hi,

7816-3 has nothing to do with encryption and only specifies T=0 and T=1, ie
low level comm with the card.

ISO7816-4 deals with file reading and writing and has nothing to do with
encryption, too.

pcsclite will allow you to exchange arbitrary APDUs with readers, regardless
of the higher protocols or commands.

Regards
Sebastien
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Protecting a PIN with keyed hashing?

[Sébastien Lorquet]

I know it, but you can easily write a class implementing the
org.globalplatform.SecureChannel interface to mimick the card manager's
secure channel, and reuse host-side tools that "talk" this protocol :)

On Fri, Jul 17, 2009 at 3:07 PM, Miller, Timothy J. wrote:

> As I understand it, the symmetric key secured channel is for card
> management (e.g., PIN unblock, applet load, key injection, etc.), not for
> normal access.
>
> -- Tim
>
>
> >-Original Message-
> >From: muscle-boun...@lists.musclecard.com [mailto:muscle-
> >boun...@lists.musclecard.com] On Behalf Of Sébastien Lorquet
> >Sent: Friday, July 17, 2009 7:56 AM
> >To: MUSCLE
> >Subject: Re: [Muscle] Protecting a PIN with keyed hashing?
> >
> >the muscle applet is for global platform javacards right?
> >
> >Then about the GP secure channel already implemented
> >(org.globalplatform.SecureChannel
> >org.globalplatform.GPSystem.getSecureChannel() ) in these cards for
> >secure messaging? it provides a mac+tdes encryption. also, writing a
> >software implementation is not difficult, if needed (to use other keys
> >than SD's ones)
> >
> >sebastien
> >
> >ps: the muscle applet also support strong authentication with a
> >challenge/response exchange. A 128 bits TDES key can be seen as a 16-
> >character PIN, that can be right padded with zeroes or other if needed.
> >what do you think of this?
>
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Protecting a PIN with keyed hashing?

[Sébastien Lorquet]

the muscle applet is for global platform javacards right?

Then about the GP secure channel already implemented
(org.globalplatform.SecureChannel
org.globalplatform.GPSystem.getSecureChannel() ) in these cards for secure
messaging? it provides a mac+tdes encryption. also, writing a software
implementation is not difficult, if needed (to use other keys than SD's
ones)

sebastien

ps: the muscle applet also support strong authentication with a
challenge/response exchange. A 128 bits TDES key can be seen as a
16-character PIN, that can be right padded with zeroes or other if needed.
what do you think of this?
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Favorite contactless reader?

[Sébastien Lorquet]

My favorite is the SDI 010.

or the Omnikey one

:)

On Fri, Jul 10, 2009 at 10:00 PM, Sean  wrote:

> Hi,
>
> I am trying to find a good contactless reader for pcscd. I'm taking a poll.
> Do you have a favorite contactless rfid reader? Hopefully it works with the
> open source ccid driver. Thanks for your input.
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] read smart card with C++

[Sébastien Lorquet]

I tried this and found that classic TPC cards do not seem to be supported by
opensc.To my knowledge the specs are not even public (I asked gemalto and
was thrown away, they said to me that the specs are only available to
registered gemalto partners )

If you succeed in this tasks, i'm interested.

On Fri, Jun 19, 2009 at 3:34 PM, Ludovic Rousseau <
ludovic.rouss...@gmail.com> wrote:

> 2009/6/19 Aro RANAIVONDRAMBOLA :
> > I work on a project using red hat linux.
> > I have to make program in C++ which can read / write certificate onto
> smart
> > card : GemSafe classic TPC.
> > I have got pcsc-lite. I can get ATR, no problem.
> > But now I want to read certificate. What kind of tool or/and library can
> > make that.
>
> You should use a PKCS#11 library. Ask your smart card provider for one
> or try to use OpenSC [3] with your card.
>
> Then study the PKCS#11 API or use a higher level API like libp11 [1]
> or pkcs11-helper [2].
>
> Bye
>
> [1] http://www.opensc-project.org/libp11/
> [2] http://www.opensc-project.org/pkcs11-helper/
> [3] http://www.opensc-project.org/opensc/
>
> --
>  Dr. Ludovic Rousseau
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] GlobalPlatform keys

[Sébastien Lorquet]

Do you mean the card does counts the number of times it gets an init update
that's not followed quickly by an ext authenticate??
Is it a general behaviour or is it only implemented on some cards?
On Wed, Jun 17, 2009 at 4:32 PM, sferey  wrote:

> Sébastien Lorquet a écrit :
>
>> from my experience you can check your keys are bad even before you finish
>> channel opening so that you never lock the card :)
>>
> the processing of the Initialise Update comand response by the terminal let
> it knows if it does have the right keys.
> BUT the velocity checking applied on GP keys during that Initialise Update
> (not during the External Auth. that will failed).
>
> Sylvain.
>
>
>
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] GlobalPlatform keys

[Sébastien Lorquet]

from my experience you can check your keys are bad even before you finish
channel opening so that you never lock the card :)

On Wed, Jun 17, 2009 at 3:58 PM, Daniel Benoy  wrote:

>  Out of curiosity, it's my understanding that if I attempt to open a secure
> channel and fail enough times, then it locks the card.  Does it just lock
> the globalplatform access, or does it prevent existing installed
> applications from functioning?
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] GlobalPlatform keys

[Sébastien Lorquet]

That's not cruel, that's a business and security practice: imagine that card
free space is sorta "rented" by card owners to application providers :-)
And allowing to install evil applications on already issued cards is always
a bad thing, even if it cannot harm other on-card applications : There's an
applet firewall that enforces strict data sharing rules, who usually prevent
any bit to cross application boundaries!

Sebastien

On Wed, Jun 17, 2009 at 1:30 AM, Daniel Benoy  wrote:

> Great, thanks for the reply :)  I've been googling all over, but I
> couldn't really find an explanation for this basic question.  For some
> reason that baffles me, smart cards aren't popular even among the nerdy
> community :p
>
> So, would I be correct in saying that you get no security benefit from
> changing the issuer domain key, except that whoever gets your card would
> be unable to use it for their own stuff?  That actually sounds like a
> cruel 'feature', to poison the cards against competitors.  (Prevent me
> from wiping out my visa card and installing MuscleCard on it, for
> example :p)
>
> I suppose perhaps there's some hypothetical scenario, though, where
> someone could secretly take your card, and install some malicious
> program on it, which stores their pin or otherwise does something
> tricky...  Hm.
>
> On Tue, 2009-06-16 at 23:11 +0200, Sébastien Lorquet wrote:
> > Hi,
> >
> > GP keys are used to manage the card contents, ie add/remove applets
> > and packages.
> >
> > The worst an attacker can do is remove the applet instance along with
> > its data and reinstanciate it. But data allocated in the applet is
> > never readable from the outside, otherwise banks would not use chip
> > credit cards :-)
> >
> > You current keys are probably 404142434445464748494A4B4C4D4E4F, like
> > all development cyberflex cards :)
> > So they're not really secret until you change them using the PUT KEY
> > command.
> > but don't forget to write them down somwewhere in a secure place :-)
> >
> > In general if the card is for you only, you don't need to change the
> > security domain keys.
> >
> > Regards,
> > Sebastien
> >
> > ___
> > Muscle mailing list
> > Muscle@lists.musclecard.com
> > http://lists.drizzle.com/mailman/listinfo/muscle
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] GlobalPlatform keys

[Sébastien Lorquet]

Hi,

GP keys are used to manage the card contents, ie add/remove applets and
packages.

The worst an attacker can do is remove the applet instance along with its
data and reinstanciate it. But data allocated in the applet is never
readable from the outside, otherwise banks would not use chip credit cards
:-)

You current keys are probably 404142434445464748494A4B4C4D4E4F, like all
development cyberflex cards :)
So they're not really secret until you change them using the PUT KEY
command.
but don't forget to write them down somwewhere in a secure place :-)

In general if the card is for you only, you don't need to change the
security domain keys.

Regards,
Sebastien
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Cyberflex e-gate 32k install error 6A80

[Sébastien Lorquet]

>
>
>
>  -cards that support both T=0 and T=1 are generally used in T=0 mode since
>> the readers try this one before ;)
>>
>
> depends on the reader, Omnikey drivers - because they are german -
> always use T=1 if both are available.
>

Okay, I was not sure  =]


>
>
>  -command apdu is sent as a whole even if only the 5 first bytes are
>> available before setIncomingAndReceive, this is what the oscilloscope said
>> to me yesterday.
>>
>
>  -new Truc() creates an eeprom object. To get a RAM object, create it as a
>> local variable and give this local variable as a parameter to other methods
>> that will use it.
>>
>
> you are not very precise, if "create it" means allocate a new Truc(),
> it always occurs in EEPROM, the only local variables that are allocated
> from the RAM stack are the integer types (so byte, short) and
> references.


Sure, memory allocation has to be clearly explained and I was a bit fast.


Seb
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Cyberflex e-gate 32k install error 6A80

[Sébastien Lorquet]

That's the right way to do it, yes :)
If it was me, I would even fail with an out of mem SW instead of falling
back to an eeprom buffer. this is really bad for the NV mem.

On Fri, May 29, 2009 at 11:24 AM, Joao Pedro  wrote:

> Thanks for the suggestions Sylvain. I've created a small patch that tries
> to allocate the extended buffer on RAM, but fallbacks to EEPROM memory if
> something should fail.
>
> The extended APDU buffer size is 268 bytes to accommodate for the entire
> received APDU. Ideally this could be only 256 bytes for a 2048 bit key, but
> that implies more changes to the existing code and, at this time, I'm trying
> to make this code the least intrusive as possible.
>
> I've compiled the applet, loaded it and can confirm that is working
> correctly with OpenSC on an Aladdin eToken 72K (engineering version).
>
> According to (very non scientific tests), the running time of "pkcs11-tool
> --login --test" appears to be ~ 1.2 seconds faster using RAM vs EEPROM.
>
> If you anyone can comment, I'll be grateful :)
>
> Best regards,
> Joao
>
> "s.ferey"  wrote:
>
>  Joao Pedro a écrit :
>>
>>>
>>> This is a very good point.
>>> I understand what you mean, and this was a major concern of mine. If I'm
>>> mistaken please correct me but, after looking at the rest of the code, this
>>> kind of "memory usage pattern" is used many times, at least in the
>>> ComputeCrypt() method.
>>>
>>
>> my previous point ! there a lot of EEPROM uses in the applet that
>> shall be avoided!
>>
>> based on a quick review, the ObjectManager & MemoryManager classes
>> are a very bad idea, now there are may be some reasons to use them
>> for instance to store some "session objects" that stay alive across
>> several APDU, so my last question regarding a specification that
>> explains how, why and when such 'semi-persistent' objects may exist
>> (or not).
>>
>>  Regarding the extended APDU buffer, maybe declaring it as transient would
>>> be a good alternative? This card, at least, has 8KB of RAM... I guess all
>>> new cards, that support extended APDU, should have plenty of RAM too... Your
>>> feedback here would be really great! :)
>>>
>>
>> it could be a solution, it depends on use of the transient memory
>> by other applets, if one allocate a big transient reset buffer,
>> that memory won't be available for other applets.
>>
>> it also depends on the actual need of memory, only some very specific
>> cryptographic functions may require to have "huge" data all available
>> at one time in a buffer, for instance if your card / applet supports
>> 4096-bit signature in RAW mode, you need to store the 512-byte to be
>> signed, but I don't know a lot of card that supports 4096-bit keys.
>>
>> the easier context to manage extended length functions is the checksum
>> or digest functions, you need to input a lot of data but you will return
>> a short amount of data. for instance for a digest process, you will use:
>> (one can write the loop according different rules).
>>
>> short part = apdu.setIncomingAndReceive();
>> short length = apdu.getIncomingLength();
>> if (length == part)
>>   length = digest.doFinal(buffer, apdu.getOffsetCdata(),
>> length, buffer, (short) 5);
>> else {
>>   digest.update(buffer, apdu.getOffsetCdata(), part);
>>   length -= part;
>>   for (;;){
>>  part = apdu.receiveBytes((short) 5);
>>  if (part == length){
>> length = digest.doFinal(
>>buffer, (short) 5, part, buffer, (short) 5);
>> break;
>>  }
>>  else {
>> digest.update(buffer, (short) 5, part);
>> length -= part;
>>  }
>>   }
>> }
>> apdu.setOutgoingAndSend((short) 5, length);
>>
>>
>> regarding a "stream function" like encrypt or decrypt, you can not
>> start to return the ciphertext while you will continue to receive
>> the next plain text; something likes
>>
>> for (;;){
>>  apdu.receiveBytes()
>>  cipher.update();
>>  apdu.sendBytes();
>> }
>> is of course invalid.
>>
>> so you have no choice and must limit the amount of transmitted data
>> to fit the maximal length of APDU buffer or to use - as suggested -
>> a transient buffer; both options would require a "get card/applet
>> capabilities" function (a dedicated APDU) to let the terminal aware
>> of how many bytes it can send per APDU (and thus it obvioulsy means
>> a tailored middleware).
>>
>> as an exemple, the Cosmo v.7 card I was dealing with has a transient
>> deselect buffer of 1536 bytes - and most of cards issued in 2007-2008
>> certainly offer at least 1024 bytes, so at least, you can encrypt /
>> decrypt by block of 1024 bytes (instead of 256) w/o any EEPROM writing.
>>
>>
>>  More generic question, is there a specification that
 describes the requierments for the CardEdge applet ?
 (reverse understanding is still possible but paintful).

  I did not understand your question. Could you please clarify?
>>>
>>
>> well, as explained at the beginning some points are not that obvious
>> and easy to un

Re: [Muscle] Cyberflex e-gate 32k install error 6A80

[Sébastien Lorquet]

just some remarks

-APDU are stored in a dedicated apdu buffer, separated from the main ram
-cards that support both T=0 and T=1 are generally used in T=0 mode since
the readers try this one before ;)
-command apdu is sent as a whole even if only the 5 first bytes are
available before setIncomingAndReceive, this is what the oscilloscope said
to me yesterday.
-new Truc() creates an eeprom object. To get a RAM object, create it as a
local variable and give this local variable as a parameter to other methods
that will use it.

-muscle card spec: the best I know is
http://www.linuxnet.com/musclecard/files/mcardprot-1.2.1.pdf

sebastien
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Cyberflex e-gate 32k install error 6A80

[Sébastien Lorquet]

>
> Is CosmopolIC a 2.1.x card?


2.1 is the minimum, and newer cards are backwards compatible.


>
>
> Does CosmopolIC have the on-card byte code verifier?
>

I think the cyberflex is the only one with a verifier.
In my job, no card need it, including oberthur ones.


> > I have no clue for Cyberflex, expect not using a Cyberflex.
>
> Well Cyberflex 32K is the easiest card to buy (amazingly, the
> Gemalto webstore is still not offering the 64K card, making it
> unavailable to end users like me!), and most other card makers are
> not offering blank cards as ready-to-buy for end users (for
> instance the highly certified Oberthur card has a dead US website
> and a main website which just has a blank area for the "enterprise
> solutions" usage class.


Did you try this site? http://www.smartcardsource.com/

Here are my thoughts: cyberflex is a paranoid card, the on card verifier
confirms this.
But your apdu trace shows 0x80 CLA bytes, which signifies that you
communicate with the card without security.
I would bet that the 6985 (security status not satisfied) comes from here.
Try forcing gpshell to append MACs to the commands.
I see that you have asked it with open_sc -security 1 -keyind 0 -keyver 0
 but it does not seem to have worked, i don't know why.

Also note that my successfull cardedge loading was made using SCShell, which
comes with lots of scripts including one to load cardedge.cap.transf on
cyberflex cards:
http://www.openscdp.org/scsh3/index.html
http://www.openscdp.org/scripts/musclecard/index.html
this may be worth a try.

Sebastien
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Cyberflex e-gate 32k install error 6A80

[Sébastien Lorquet]

Hi,

what commands did you use? load and install in a single command, or separate
loading, then instanciation?

6a80 may come from the instanciation step (install for install) if you don't
give a correct instance initialization data array.

according to GP 2.1.1, the load command does not throw 6A80, but the install
command can.

also, be sure not to use any -nvdatalimit et al options in gpshell, they are
totally useless, but if by chance, the applet is bigger than the limits, the
load will fail.

I hope this gives you some hints, waiting for your feedback.

Sebastien

PS: just to be sure: what is the ijc format? IIRC this is the concatenation
of all CAP components. Why don't you use the generated CAP from the trusted
logic captransf tool directly? this is what I did and it was successful.

On Wed, May 27, 2009 at 9:39 AM, Jakob Bohm wrote:

> Hi,
>
> I am having severe problems installing the CardEdge applet on a Cyberflex
> e-gate 32k (aka Gemalto TOP US), the first card listed as compatible in
> the applet README file.
>
> 1. When I try to install the applet using gpshell, the card refuses the
> "load" command with error 6A80 ("invalid data").  I have tried both gpshell
> 1.4.0 and 1.5.0 and both the downloadable
> http://www.identity-alliance.com/CardEdgeCflex.ijc, a self-compiled
> applet from the latest svn sources (using the ant scripts) and a
> self-compiled applet compiled using a short shell script that I tested to
> otherwise create working applets for that card (tested with HelloWorld.java
> and a small test applet of my own).
>
> And yes, this implies that I do have and use captransf.jar version 1.5 from
> www.trusted-logic.fr .
>
> So far, nothing helps, what am I missing?
>
>
> 2. The current svn sources don't compile as-is, due to at least 4 bugs:
>
> 2.1 common.xml uses Windows-only path separators (backslashes), not the
> portable slashes.
>
> 2.2 common.xml does not set the javac option to produce .class files
> compatible with the JavaCard tools (target="1.1" source="1.2").
>
> 2.3 The build instructions are not sufficiently clear about which kits to
> unpack, what kit files and additional tools to move/copy/patch etc.  It
> took
> a lot of work to figure this out.
>
> 2.4 CardEdge.src does not compile with the JavaCard 2.1.1 kit due to a
> small
> bug in the addition of Extended APDU support.  Here is my patch:
>
>
> Index: CardEdge.src
> ===
> --- CardEdge.src(revision 286)
> +++ CardEdge.src(working copy)
> @@ -910,8 +910,8 @@
> private void ComputeCrypt(APDU apdu, byte[] apduBuffer) {
>/* Buffer pointer */
>byte[] buffer = apduBuffer;
> +#ifdef WITH_EXT_APDU
>short dataOffset = apdu.getOffsetCdata();
> -#ifdef WITH_EXT_APDU
>short LC = apdu.getIncomingLength();
>short bytesLeft = apdu.setIncomingAndReceive();
>
> @@ -925,6 +925,7 @@
>bytesLeft = LC;
>}
>  #else
> +   short dataOffset = ISO7816.OFFSET_CDATA;
>short bytesLeft = Util.makeShort((byte) 0x00,
>buffer[ISO7816.OFFSET_LC]);
>if (bytesLeft != apdu.setIncomingAndReceive())
>
>
>
> --
> This message is hastily written, please ignore any unpleasant wordings,
> do not consider it a binding commitment, even if its phrasing may
> indicate so. Its contents may be deliberately or accidentally untrue.
> Trademarks and other things belong to their owners, if any.
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] Memory card support

[Sébastien Lorquet]

In the general case, to access memory cards, you use reader APDUs with class
0xFF.
But it depends on the reader, these APDUs are proprietary (even if
documented)
In all case, these apdus are transported using ccid and pcsc.

Seb

On Tue, May 19, 2009 at 5:52 PM, Glen Gray  wrote:

> Just to follow up on previous email. I want to be clear on the issue. The
> alcor reader, being controlled via the generic ccid driver stack, does not
> have the ability to power up or access memory cards such as the gpm2k
> sle4442 card. Is that correct ?
>
> In order for this device to be able to access a memory card it would either
> have to emulate the ISO commands mentioned in response to my previous email
> OR it needs some extra layer at the driver level to know how to talk to
> memory cards.
>
> According to the datasheet for the reader, these cards are supported. And
> advantech confirmed that the windows stack they ship can access them.
>
> Thanks in advance.___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] testpcsc not working when not root

[Sébastien Lorquet]

Hi,

For my part I worked this around by creating the folder manually before
starting pcscd for the first time.

Thank you for your reactivity.

Sebastien

On Tue, May 19, 2009 at 4:45 PM, Ludovic Rousseau <
ludovic.rouss...@gmail.com> wrote:

> 2009/5/19 Sébastien Lorquet :
> > well that's the case. I have a /var/run/pcscd directory with files
> inside. I
> > was mistaken by running ls -l /var/run/p*
> >
> > When stracing the program as root, I can see the program locked on
> select()
> > for card insertion.
> >
> > When stracing the program as a user, I can see that a stat64 fails with
> > EACCESS on /var/run/pcscd/pcscd.pub
> >
> > in fact /var/run/pcscd was created with rights 700.
> >
> > it's ok by chmoding it with u+x
> >
> > I did not create this directory, who did it? pcscd itself?
>
> yes, by pcscd.
> The access rights could be wrong if you use a restrictive umask.
>
> I just corrected the problem in revision 4213
>
> http://lists.alioth.debian.org/pipermail/pcsclite-cvs-commit/2009-May/003715.html
>
> Thanks
>
> --
>  Dr. Ludovic Rousseau
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] testpcsc not working when not root

[Sébastien Lorquet]

well that's the case. I have a /var/run/pcscd directory with files inside. I
was mistaken by running ls -l /var/run/p*

When stracing the program as root, I can see the program locked on select()
for card insertion.

When stracing the program as a user, I can see that a stat64 fails with
EACCESS on /var/run/pcscd/pcscd.pub

in fact /var/run/pcscd was created with rights 700.

it's ok by chmoding it with u+x

I did not create this directory, who did it? pcscd itself?

Sébastien
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

[Muscle] testpcsc not working when not root

[Sébastien Lorquet]

Hi,

I'm using pcscd-1.5.3 with ccid-1.3.10 and libusb-0.1.12 on a redhat 3 box
with a 2.4.21 kernel (no, I have no choice)

pcscd is working fine with libusb.

I'm now trying to use it :)

testpcsc works fine when I run it as root.

But it says: "service not available" when I run it as a normal user.
Note that it does NOT display "PCSCD not running".

Any clue here? I just installed the pcscd script to /etc/init.d and used
chkconfig to install links.

The reader is not the cause, it's a teo by xiring and it works like a charm
when I run testpcsc as root.

Also, note that /var/run/pcscd.comm is srwxrwxrwx, I did not touch it.

I installed pcsc-lite by running as root:
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
--disable-libhal && make && make install


Regards and thanks,

Sebastien Lorquet
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] How to use the crypto api with a card gemalto cyberflex 32k ?

[Sébastien Lorquet]

Ah, where did you find this information?

I've got the GP 2.1.1 specification under my nose (pages 115-116) and the
GET STATUS (CLA=80/84, INS=F2) command only retrieves the AID, privileges
and app life cycle state.

Ah, OK, this is defined in GP 2.2. Do old cards also report package version
in their TLV GP Registry data?


On Mon, Mar 23, 2009 at 10:16 AM, s.ferey  wrote:

> Sébastien Lorquet a écrit :
>
>> OK, So I really have no idea of what caused your problem!
>> IIRC, IJC files are only a concatenation of all .cap file contents. or are
>> there modifications?
>>
>
> none.
> the only reason for a successful loading is the use of
> a different set of .exp files - compliant with the card.
>
> note that GP Get Status command allows to list of JCRE
> packages and their version, it's a good way to be sure
> that not too recent export are used.
>
> Sylvain.
>
>
>
> ___
> Muscle mailing list
> Muscle@lists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] How to use the crypto api with a card gemalto cyberflex 32k ?

[Sébastien Lorquet]

OK, So I really have no idea of what caused your problem!
IIRC, IJC files are only a concatenation of all .cap file contents. or are
there modifications?
However, nice if it helps, i'll remember this if I have problems :-)
de rien,
cheers,
Sebastien.

On Sun, Mar 22, 2009 at 7:13 AM, jose85  wrote:

>
> Hello
>  Thanks Sebastien Lorquet,
> finally i've followed the tips of Sonnyyu at the end of this thread:
> http://forums.sun.com/thread.jspa?threadID=5369761&tstart=0
> by converting my .cap into .ijc, i've been able to load my cardlet with
> crypto api in the card
> and it looks to work very well,
> i'll have to decrypt the apdu on the pc side now
> merci
> kind regards,
> Franck
>
>
>
> Sébastien Lorquet wrote:
> >
> > Hi,
> >
> > If you cant load the applet when you use the crypto api, this may be a on
> > card linking problem.
> > Maybe your card only support one version of the crypto package (say
> v1.0),
> > and when you compile with a more recent JCDK, this JCDK wants to link
> with
> > a
> > more recent version of the crypto package (say 1.1). Check the .cap
> > manifest
> > file for more info about this. (cap are JARs)
> >
> > your GPShell commands looks all right, even if you can use a security
> > value
> > of 1 (C-MAC) instead of 3 (C-MAC&C-ENC) with cyberflex.
> >
> > NVDataLimit is useless, remove it, this is only a "ask card to fail if I
> > load more than 500 bytes of eeprom for code". And you never know exactly
> > how
> > much you use :-)
> >
> > I notice that your gpshell script refers to "$PKGAPPLET.cap.transf ",
> > that's
> > right because gemalto cyberflex cards have an on card verifier and need
> > the
> > Trusted Logic "captransf.jar". Don't forget to regerenate the .transf
> file
> > if you change the cap file :-) (you didn't mention the call to captransf
> > in
> > your build process description :-) )
> >
> > An APDU trace log (with security =1 if possible) should be more useful to
> > say you what's wrong.
> >
> > Regards,
> > Sebastien.
> >
> > On Fri, Mar 20, 2009 at 7:23 PM, jose85 
> wrote:
> >
> >>
> >> Hello ,
> >>
> >> I've done many javacard programs using this method :
> >> _compilation with javacard kit 2.2.1
> >> _convertion into ".cap" with the javacard kit 2.1.2
> >> All this programs work fine with this method : helloworld, read, write
> in
> >> the card, 
> >>
> >> But when i want to use the crypto api, i can't charge the program in the
> >> card (just by adding 2 lines for generating keys):
> >> --> returns 0x80206A80 (6A80: Wrong data / Incorrect values i
> >> data.)
> >>
> >> I think it's because i use the 2.1.2 version , but if i use the 2.2.1 to
> >> convert , it's another error and no program work with this
> >> method.even
> >> helloworld doesn't work...
> >> ---> returns 0x80206985 (6985: Command not allowed - Conditions
> >> of
> >> use not satisfied.)
> >>
> >> I thing i must change my gpshel command , but i have read many forums
> but
> >> can't find the configuration for my card cyberflex 32k, some people had
> >> similar problems so they used the kit 2.1.2 combined with 2.2.1 like me,
> >> but
> >> i think they can't use the crypto api with this.
> >>
> >> here are the scripts for compiling , converting and installing the
> >> cardlet
> >> in the card :
> >>
> >>
> 
> >> echo Compilation...
> >> echo $JC22_API
> >> $JAVA_HOME/bin/javac -source 1.2 -target 1.2 -g -classpath $JC22_API -d
> >> $OUT/$PROJECT/ $SRC/$PROJECT/$PKGAPPLET/$APPLET.java
> >> echo $APPLET.class compiled: OK
> >> echo .
> >>
> >> echo Converting...
> >> $JAVA_HOME/bin/java -classpath
> >> $JC22_HOME/lib/converter.jar:$JC22_HOME/lib/offcardverifier.jar
> >> com.sun.javacard.converter.Converter -nobanner -classdir $OUT/$PROJECT/
> >> -exportpath $JC_EXP -d $OUT/$PROJECT/ -out EXP JCA CAP -applet
> $AIDAPPLET
> >> $PKGAPPLET.$APPLET $PKGAPPLET $AIDPACKAGE $PKGVERSION
> >> echo $APPLET.cap converted: OK
> >> echo .
> >> cp $OUT/$PROJECT/$PKGAPPLET/javacard/$PKGAPPLET.cap $OUT/$PROJ

Re: [Muscle] How to use the crypto api with a card gemalto cyberflex 32k ?

[Sébastien Lorquet]

Hi,

If you cant load the applet when you use the crypto api, this may be a on
card linking problem.
Maybe your card only support one version of the crypto package (say v1.0),
and when you compile with a more recent JCDK, this JCDK wants to link with a
more recent version of the crypto package (say 1.1). Check the .cap manifest
file for more info about this. (cap are JARs)

your GPShell commands looks all right, even if you can use a security value
of 1 (C-MAC) instead of 3 (C-MAC&C-ENC) with cyberflex.

NVDataLimit is useless, remove it, this is only a "ask card to fail if I
load more than 500 bytes of eeprom for code". And you never know exactly how
much you use :-)

I notice that your gpshell script refers to "$PKGAPPLET.cap.transf ", that's
right because gemalto cyberflex cards have an on card verifier and need the
Trusted Logic "captransf.jar". Don't forget to regerenate the .transf file
if you change the cap file :-) (you didn't mention the call to captransf in
your build process description :-) )

An APDU trace log (with security =1 if possible) should be more useful to
say you what's wrong.

Regards,
Sebastien.

On Fri, Mar 20, 2009 at 7:23 PM, jose85  wrote:

>
> Hello ,
>
> I've done many javacard programs using this method :
> _compilation with javacard kit 2.2.1
> _convertion into ".cap" with the javacard kit 2.1.2
> All this programs work fine with this method : helloworld, read, write in
> the card, 
>
> But when i want to use the crypto api, i can't charge the program in the
> card (just by adding 2 lines for generating keys):
> --> returns 0x80206A80 (6A80: Wrong data / Incorrect values i
> data.)
>
> I think it's because i use the 2.1.2 version , but if i use the 2.2.1 to
> convert , it's another error and no program work with this method.even
> helloworld doesn't work...
> ---> returns 0x80206985 (6985: Command not allowed - Conditions of
> use not satisfied.)
>
> I thing i must change my gpshel command , but i have read many forums but
> can't find the configuration for my card cyberflex 32k, some people had
> similar problems so they used the kit 2.1.2 combined with 2.2.1 like me,
> but
> i think they can't use the crypto api with this.
>
> here are the scripts for compiling , converting and installing the cardlet
> in the card :
>
> 
> echo Compilation...
> echo $JC22_API
> $JAVA_HOME/bin/javac -source 1.2 -target 1.2 -g -classpath $JC22_API -d
> $OUT/$PROJECT/ $SRC/$PROJECT/$PKGAPPLET/$APPLET.java
> echo $APPLET.class compiled: OK
> echo .
>
> echo Converting...
> $JAVA_HOME/bin/java -classpath
> $JC22_HOME/lib/converter.jar:$JC22_HOME/lib/offcardverifier.jar
> com.sun.javacard.converter.Converter -nobanner -classdir $OUT/$PROJECT/
> -exportpath $JC_EXP -d $OUT/$PROJECT/ -out EXP JCA CAP -applet $AIDAPPLET
> $PKGAPPLET.$APPLET $PKGAPPLET $AIDPACKAGE $PKGVERSION
> echo $APPLET.cap converted: OK
> echo .
> cp $OUT/$PROJECT/$PKGAPPLET/javacard/$PKGAPPLET.cap $OUT/$PROJECT/
>
> echo Scripting...
> $JAVA_HOME/bin/java -classpath $JC22_HOME/lib/scriptgen.jar
> com.sun.javacard.scriptgen.Main -nobanner -o $OUT/$PROJECT/$APPLET.scr
> $OUT/$PROJECT/$PKGAPPLET/javacard/$PKGAPPLET.cap
> echo $APPLET.scr created: OK
> echo .
>
> echo Completing script...
> cat $MISC/Header.scr $OUT/$PROJECT/$APPLET.scr $MISC/Install.scr
> $MISC/Footer.scr > $OUT/$PROJECT/$SIMUSCRIPT.scr
> rm -f $OUT/$PROJECT/$APPLET.scr
> echo $SIMUSCRIPT.scr created: OK
>
>
> ---
>
> 
>
> echo establish_context >> $OUT/config.txt
> echo card_connect >> $OUT/config.txt
> echo select -AID $CARDSECURITYDOMAIN2 >> $OUT/config.txt
> echo open_sc -security 3 -keyind 0 -keyver 0 -mac_key $CARDKEY -enc_key
> $CARDKEY  >> $OUT/config.txt
> echo install_for_load -pkgAID $PACKAGEAID -nvCodeLimit 500 >>
> $OUT/config.txt
> echo load -file $OUT/$PROJECT/$PKGAPPLET/javacard/$PKGAPPLET.cap.transf >>
> $OUT/config.txt
> echo install_for_install -instParam 00 -priv 02 -AID $APPLETAID -pkgAID
> $PACKAGEAID -instAID $APPLETAID -nvDataLimit 500 >> $OUT/config.txt
> echo card_disconnect >> $OUT/config.txt
> echo release_context >> $OUT/config.txt
>
> -
>
> the variable  $JC_EXP is the directory
> "java_card_kit-2_1_2/api21_export_files" or
> "java_card_kit-2_2_/api_export_files" with the the first directory it works
> well but the second doesn't work , while charging the applet in the card :
> ---> returns 0x80206985 (6985: Command not allowed -
> Conditions of use not sat