gmane.comp.encryption.opensc.devel

Re: new release?

Douglas E. Engert — 2012-05-25T16:09:54


On 5/25/2012 6:04 AM, Martin Paljak wrote:

Sounds reasonable, but how do we avoid these types of problems in the future?
No two-way syncing, with Gerrit or GitHub as the master?

Re: ACR122U + MyEID dual interface

NdK — 2012-05-25T12:22:41

Il 25/05/2012 11:51, Aventra - Hannu Honkanen ha scritto:

Perfect. I'll *try* not to brick another card, this time. I promise. :)

That's the one I used to "decode" Mifare ATR.

For now I'll edit my local copy, so I can use it.
BTW couldn't it be better to keep ATRs in a config file?

That's what made me think

As usual I like pushing things to their limits... :)

The idea would be to use different slots. But there's a problem
(probably): when you send HaltA to a card, login status gets lost, like
it's been extracted (well, the app is yours and probably you could make
it keep the state between HaltA and wakeup, since it's still receiving
power...).

PS: any way to define a sign pin (so that it have to be re-entered after
each crypto op -- useful with pinpad readers)?

BYtE,
 Diego.

Re: CRYPTOMATE64

NdK — 2012-05-25T12:07:19

Il 25/05/2012 10:59, Martin Paljak ha scritto:
Yup. Sure. A bit OT, but I'll try to keep it terse.

It's just an idea, still have to test it. Might be that it pushes cert
parsing "over its limits". I'm assuming the chain checking is stopped as
soon as a trusted cert is found.

It's based on good old FidoNet routing:
- 3 'root' CAs
- Every CA is root for only one of the other two
- the 'root' CAs are equipotent.
- there's no self-signed certificate
- users choose to trust one, two or three of the 'root' CAs (the more
the better and faster verifications).

Say CAs are A, B, C.
A's cert is signed by B, B's cert is signed by C and C's cert is signed
by A.

Worst case: the user chose to only trust B and connects to an intranet
http server. He's presented a cert signed by C.C1s.C1www (C signed C1s'
cert delegating 's'ervers and C1s signed C1www's cert delegating http
servers certs issuance). Then cert chain is checked: site, C1www, C1s, C
and finally A that, being signed by B validates all the chain.
If the user c

Re: new release?

Martin Paljak — 2012-05-25T11:04:36

Hello,

On Wed, May 2, 2012 at 5:31 PM, Douglas E. Engert <deengert< at >anl.gov> wrote:

Obviously Viktor and others have had way more time in their hands to
work on OpenSC than me :)

Also obvious is that the most active branch is supposed to be merged
as the basis for next release, which was more or less the idea of Git
in the first place.

As the recovery option, the sync problem between Gerrit and github
needs to be cleared. Too much integration is probably not a good idea,
two-way syncing between github pull request and Gerrit has brought no
obvious benefits...

The most straightforward approach would probably be forcing the github
tree into opensc-project.org and clearing Gerrit...

Martin

Re: [opensc-commits] [Git] branch staging updated.ef835cb8a93087b0551c9786be655adaa2242a08

Martin Paljak — 2012-05-25T10:10:09

On Sun, Apr 1, 2012 at 11:09 PM, Git Master
<webmaster< at >opensc-project.org> wrote:


While all the flags in PKCS#15 and PKCS#11 are related and towards
PKCS#11 (which defines its own model for things), I don't think that
this is true, especially for an imported key (the thing has gone
simpler with the extractable-magic gone)

As OpenSC itself, nor most (all ?) cards it supports, don't allow
reading the key out of the card (I hope), sensitive should hold true.
As the key has been imported, alwaysSenstive does not hold, as the key
is in plaintext when imported through pkcs15-init. In PKCS#11 terms,
importing a key is like creating it through C_CreateObject, thus the
same should hold for the flags:

(from PKCS#11):

If C_CreateObject is used to create a key object, the key object will have its
CKA_LOCAL attribute set to CK_FALSE. If that key object is a secret or
private key
then the new key will have the CKA_ALWAYS_SENSITIVE attribute set to
CK_FALSE, and the CKA_NEVER_EXTRACTABLE attribute set to CK_FALSE.


A

Re: ACR122U + MyEID dual interface

Aventra - Hannu Honkanen — 2012-05-25T09:51:51

Hi,

-----Original Message-----
NdK:

should I add support for 'em digging in the code >(for this, help from
Aventra would be really welcome -- big task!).

ACR122U reader gives a different ATR than a contact reader for the same dual
interface card but otherwise the reader works just like a contact reader
with PKI cards. If you force usage of the myeid driver, it should work. 

There is an API specification for the reader available at ACS's website, ATR
generation is explained there: 
http://www.acs.com.hk/drivers/eng/API_ACR122U_v2.01.pdf

Maybe we should add this ATR to card-myeid.c. Could someone with access to
the sources help and modify it like this?

static const char *myeid_atrs[] = {
"3B:F5:18:00:FF:81:31:FE:45:4D:79:45:49:44:65",
"3B:F5:18:00:00:81:31:FE:45:4D:79:45:49:44:9A",
"3B:85:80:01:4D:79:45:49:44:78",
"3B:89:80:01:09:38:33:B1:4D:79:45:49:44:4C",  
NULL
};

The last ATR is from another version of ACR122U. I think it is possible to
affect the way the ATR is generated by altering the "PICC

Re: OpenPGP card / Cryptostick - current status???

Martin Paljak — 2012-05-25T08:48:35

Hello,

On Tue, May 22, 2012 at 10:18 PM, Peter Marschall <peter< at >adpm.de> wrote:

What was basically removing some v1 related hard-coded constants (like
1024 bit keys) and adding some more parsing of on-card structures,
created with gpg --card-edit.

Martin

Re: PKCS15init profile to omit a part of path

Martin Paljak — 2012-05-25T08:40:31

Hello,

On Fri, May 18, 2012 at 12:59 PM, Nguyễn Hồng Quân <quannguyen< at >mbm.vn> wrote:

In the long run, I don't think that it helps to emulate a filesystem
on top of non-filesystem cards (like OpenPGP or Muscle). Or to try to
make it fit into the filesystem-oriented stack of OpenSC.

It is nice to be able to poke around with opensc-explorer, but the
notion of a file and a path should mean that the file is actually
selectable with ISO SELECT command. Which is not true (a plain APDU,
outside of the libopensc emulation layer, would fail).

In case of OpenPGP, where no files or PKCS#15 data structures are
written to the card (the card already has a fixed profile, with fixed
data slots), it makes no sense. The main utility of pkcs15-init is
creating (and storing) PKCS#15 ASN.1 structures to the card, when such
slots for keys or certificates are created as a side-product. If ASN.
shall not be created, pcks15-init should IMHO not be used.

The fact that pkcs15-init is the main interface for generating
keys/sto

Re: CRYPTOMATE64

Martin Paljak — 2012-05-25T07:53:40

If you are definitely into tokens, then you might really look at the
specified instance.
Though hard to get, there are also JavaCards that can do at least 3072
bits key generation. Verification might be possible even with bigger
keys.

For strictly key storage, I would suggest PGP card (which can do 3
keys, but only a single certificate).
Martin
_______________________________________________
opensc-devel mailing list
opensc-devel< at >lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: ACR122U + MyEID dual interface

Jean-Michel Pouré - GOOZE — 2012-05-25T07:23:28

Le jeudi 24 mai 2012 à 19:59 +0200, NdK a écrit :

ACS libccid was boggus when we last tested it. We have dozens of readers
in stock but we are not releasing them to the public. I will soon attach
those readers to the QA farm to test them.

Kind regards,

Re: SIM

Ludovic Rousseau — 2012-05-24T22:05:17

2012/5/24 Hans Witvliet <hwit< at >a-domani.nl>:

Hello,


A SIM is not a PKI card. So I am not surprised if OpenSC tools can't use a SIM.

I wrote 3 articles [1] in my blog about programs to read and interact
with a SIM card.

A SIM card is much more easy to use since the commands are
standardised and the documentation is public. You do not have that, in
general, for a PKI card.

Bye

[1] http://ludovicrousseau.blogspot.fr/search/label/sim

Re: libccid + keyboard

Hans Witvliet — 2012-05-24T21:32:03

<huge sigh of relief>

On a personal note: i wouldn't mind if that part got disabled,
Actually, i always use the top row on the keyboard, instead of the
numeric-pad. For those ultra-secure-solutions people should use a
dedicate reader+pinpad, class-3 preferably (with own window)

Our security department might think otherwise. I'll check with them.
But i think they won't make a big fuss, as for home and travelling
purposes they've bought 50,000 folded readers.

All our workplaces in the office are equipped with those HP-keyboards, i
think that SPE should not be required there ;-)


Hans

SIM

Hans Witvliet — 2012-05-24T21:49:39

Hi all,

EF's on the smartcard.

Although they miss the directory structure normally found on cards, is
there any reason why i should not be able to read thsoe EF's?

I mean, when inserting a SIM into a reader, i get the ATR, but nothing
more. I hoped that opensc-explorer could read them.

Do those cards require special middleware (like those from safesign) or
is there an other reason why i can not read them?


Hans

Re: ACR122U + MyEID dual interface

Frank Morgner — 2012-05-24T19:31:37

It is the ATR of the contact based (SIM?) card included in the reader.
To talk to the NFC-interface of the reader, you can use libnfc [1] or
the cyberflex-shell [2]. I have written a wrapper driver around libnfc
for PCSC-Lite [2]. May be there are also other (proprietary) drivers out
there...

[1] http://www.libnfc.org
[2] https://github.com/henryk/cyberflex-shell
[3] http://sourceforge.net/projects/ifdnfc/

Re: ACR122U + MyEID dual interface

NdK — 2012-05-24T17:59:26

Argh!

Seems so. Might be useful to look at the differences?

BYtE,
 Diego.

Re: ACR122U + MyEID dual interface

NdK — 2012-05-24T17:55:58

Found some docs. Actually the reader's docs from ACS, that seems really
well-written (API_ACR122U_v2.01).
3b: initial header
8f: t0
80: td1
4f: td2
80: t1
4f: Tk: Application identifier presence indicator
0c: Tk: length
a000000306: Tk: registered application provider identifier (RID)
03: Tk: standard (14443-*3*)
0001: Tk: card 'name' *
00000000: RFU
6a: tck (xor from t0 to Tk)

Card name:
0001: Mifare 1K
0002: Mifare 4K
0003: Mifare ultralight
0026: Mifare mini
f004: Topaz and Jewel
f011: FeliCa 212K
f022: FeliCa 424K
ff:   SAK (undefined)

Maybe it's worth updating ATR table.

HIH.

BYtE,
 Diego.

Re: ACR122U + MyEID dual interface

Ludovic Rousseau — 2012-05-24T16:33:16

2012/5/24 NdK <ndk.clanbo< at >gmail.com>:

ACS forked my CCID driver. I got no contract with ACS.

Your "ACS ACR122U PICC Interface" reader should work with my CCID driver.

I have no answer regarding OpenSC support.

Bye

Re: ACR122U + MyEID dual interface

NdK — 2012-05-24T15:56:06

I think this one is well supported: its driver sources have 'rousseau'
in nearly all headers :)
Seems Ludovic got a contract with ACS (I hope for him) in 2009...

If I insert one of the cards in the contact reader, I get the same ATR
as standard MyEID cards:
$ opensc-tool -a -n
Using reader with a card: Gemalto GemPC Twin 00 00
3b:f5:18:00:00:81:31:fe:45:4d:79:45:49:44:9a
MyEID cards with PKCS#15 applet

But (obviously) if I place it on NFC reader I can't use it:
$ pkcs15-init -C --pin 1111 --puk 1111
Using reader with a card: ACS ACR122U PICC Interface 01 00
Couldn't bind to the card: Not supported

Is there any way I could "force" pkcs15-init in recognizing it as myeid
(like "-c myeid" for pkcs11-tool)?

BTW for the other ATR
(3b:8f:80:01:80:4f:0c:a0:00:00:03:06:03:00:01:00:00:00:00:6a)
I already found: it's a Mifare One card (just tested with others I had
around).

BYtE,
 Diego.

Re: libccid + keyboard

Ludovic Rousseau — 2012-05-24T14:50:02

2012/5/24  <J.Witvliet< at >mindef.nl>:

Hello,


SPE is Secure PIN Entry.
In this mode the PIN is entered on the keyboard (numeric pad) and sent
directly to the smart card without going to the host.

See the note at [1].
I do not have such a keyboard myself. So I can't tell you more about
the problems.

Bye

[1] http://pcsclite.alioth.debian.org/ccid/unsupported.html#0x03F00x1024

Re: libccid + keyboard

Martin Paljak — 2012-05-24T14:48:40

Hello,


SPE is Secure PIN entry.

Depending on the exact version of your reader (there are several) the
S in SPE can be bogus:


http://martinpaljak.net/2011/03/19/insecure-hp-usb-smart-card-keyboard/


The reader will still function as a standard reader, but the "PIN
entry through numpad" is disabled.

Martin


On Thu, May 24, 2012 at 5:02 PM,  <J.Witvliet< at >mindef.nl> wrote:

libccid + keyboard

2012-05-24T14:02:03

Hi all,

Just accidentally I came across some lines in Lodovic's blog.

For the latest version of licccid-1.4.6, he writes:
"Disable SPE for HP USB CCID Smartcard Keyboard. The reader is bogus and unsafe."

I am not sure what "SPE for HP..." means, 
but I certainly hope I can still use it for our smartcards as we have a couple of thousands of those keyboards.

I hope that it is just an obscure extra feature.

Hans


______________________________________________________________________
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake