Re: [opensc-devel] ACR122U + MyEID dual interface
Le jeudi 24 mai 2012 à 19:59 +0200, NdK a écrit : Your ACS ACR122U PICC Interface reader should work with my CCID driver. Seems so. Might be useful to look at the differences? 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, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PKCS15init profile to omit a part of path
Hello, On Fri, May 18, 2012 at 12:59 PM, Nguyễn Hồng Quân quanngu...@mbm.vn wrote: Hello all, I need a help to create pkcs15init profile structure so that I can change/rewrite the canonical path. In general, the path to a file AABB in PKCS15 is as: 3F005015AABB, in which 3F00 is the MF, 5015 is the PKCS15-AppDF's file-id. Now, because the virtual file system of my OpenPGP card (which is non-pkcs15) is constructed as: MF (3F00) | +-- File_1 (AABB) | +-- File_2 (AACC) | +--- Directory (DDCC) | +-- File_3 (CCEE) the real path to the file is 3F00AABB. How would I define the profile file to omit the PKCS15-AppDF, i.e. the 5015, in the path? 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/storing certificates, is thus somewhat misleading. You can't create more keys than 3 on OpenPGP, nor can you write more certificates. You can't create additional arbitrary slots on the card. Maybe it would be better to have a single sticky pkcs15-ish mapping for a fixed profile card in a single location (like the pkcs15 emulation drivers) and allow pkcs15-tool (which does not try to create any PKCS#15 structures) to re-generate exposed key slots and replace exposed certificate slots. And extend that API as needed. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenPGP card / Cryptostick - current status???
Hello, On Tue, May 22, 2012 at 10:18 PM, Peter Marschall pe...@adpm.de wrote: Martin started the extension of pkcs15-openpgp.c to support OpenPGP v2 cards which I continued. (but again: without write support) 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 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ACR122U + MyEID dual interface
Hi,
-Original Message-
NdK:
Too bad the cards aren't recognized by default:
$ opensc-tool -a -n
Using reader with a card: ACS ACR122U PICC Interface 00 00
3b:85:80:01:4d:79:45:49:44:78
Unsupported card
Is it only matter of unknown ATR and I can safely use force myeid? Or
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 Operating
Parameter of the reader. BTW, bytes 4D:79:45:49:44 which are present in all
of the ATR's are the text MyEID.
Is it possible to make that reader handle multiple cards in parallel
(both placed on the reader)?
I don't think it is possible and haven't tried it, but ACS lists Built-in
anti-collision feature (only 1 tag is accessed at any time). as a feature
of the reader. It probably means that the reader selects one card and
ignores others in its range. Even if that would be possible by hardware, I
don't know how you could access multiple cards in the same reader through
PCSC.
Regards,
Hannu
--
Hannu Honkanen
AVENTRA
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] [Git] branch staging updated. ef835cb8a93087b0551c9786be655adaa2242a08
On Sun, Apr 1, 2012 at 11:09 PM, Git Master webmas...@opensc-project.org wrote: commit ef835cb8a93087b0551c9786be655adaa2242a08 Author: Robbert Müller spam...@grols.ch Date: Sun Jan 8 15:48:12 2012 +0100 Adding default accessflags to the do_store_private_key function in the same way do_generate_key has those accessflags This seems the right thing to do, when you look at the initial commit which added the flags in do_generate_key and the ticket http://www.opensc-project.org/opensc/ticket/198 Currently when storing a key, the accessflags are not set diff --git a/src/tools/pkcs15-init.c b/src/tools/pkcs15-init.c index 2bf3cd1..978fd66 100644 --- a/src/tools/pkcs15-init.c +++ b/src/tools/pkcs15-init.c @@ -886,6 +886,11 @@ do_store_private_key(struct sc_profile *profile) args.x509_usage = opt_x509_usage? opt_x509_usage : usage; } + args.access_flags |= + SC_PKCS15_PRKEY_ACCESS_SENSITIVE + | SC_PKCS15_PRKEY_ACCESS_ALWAYSSENSITIVE + | SC_PKCS15_PRKEY_ACCESS_NEVEREXTRACTABLE; + 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. Also rememember, that the flags are mostly cosmetic. In the end the card enforces things, no matter what kind of flags you set in descriptors: (from PKCS#15): The semantics of the accessFlags field’s sensitive, extractable, alwaysSensitive, neverExtractable and local identifiers is the same as in PKCS #11. This field is not required to be present in cases where its value can be deduced by other means. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new release?
Hello, On Wed, May 2, 2012 at 5:31 PM, Douglas E. Engert deeng...@anl.gov wrote: The SM branch has pulled in many other changes (including my C_Derive changes) that I would like to see in the next release. If the SM branch is not going to be the bases for the next release, then we need to look at what change in the SM branch can be pulled in to the release. Martin, I would like to hear your comments. 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 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] CRYPTOMATE64
Il 25/05/2012 10:59, Martin Paljak ha scritto: Hello, On Wed, May 23, 2012 at 2:57 PM, NdK ndk.cla...@gmail.com wrote: I'm thinking to use one to store our internal root CA's key (4096bit RSA). [actually I'm thinking more about a ring of roots, but that's another story] Care to share the story? 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 chose to trust A and C too, then last two steps could be avoided, omitting costly verifications with large keys. This makes the system quite scalable, with a tradeoff between number of root certs to store and (computational and network) resources used to verify received certs. This schema 'requires' (unless you want to change all root-CAs certs quite often) quite a static root set, so it's not for general use (say between different CAs). But I think it could well accomodate our needs. Any evident pitfalls? BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ACR122U + MyEID dual interface
Il 25/05/2012 11:51, Aventra - Hannu Honkanen ha scritto:
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.
Perfect. I'll *try* not to brick another card, this time. I promise. :)
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
That's the one I used to decode Mifare ATR.
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
};
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?
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 Operating
Parameter of the reader. BTW, bytes 4D:79:45:49:44 which are present in all
of the ATR's are the text MyEID.
That's what made me think
Is it possible to make that reader handle multiple cards in parallel
(both placed on the reader)?
I don't think it is possible and haven't tried it, but ACS lists Built-in
As usual I like pushing things to their limits... :)
anti-collision feature (only 1 tag is accessed at any time). as a feature
of the reader. It probably means that the reader selects one card and
ignores others in its range. Even if that would be possible by hardware, I
don't know how you could access multiple cards in the same reader through
PCSC.
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.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new release?
On 5/25/2012 6:04 AM, Martin Paljak wrote: Hello, On Wed, May 2, 2012 at 5:31 PM, Douglas E. Engertdeeng...@anl.gov wrote: The SM branch has pulled in many other changes (including my C_Derive changes) that I would like to see in the next release. If the SM branch is not going to be the bases for the next release, then we need to look at what change in the SM branch can be pulled in to the release. Martin, I would like to hear your comments. 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 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? -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PKCS15init profile to omit a part of path
Hello Martin, On Fri 25 May 2012 03:40:31 PM ICT, Martin Paljak wrote: Hello, 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. Has OpenSC project defines another approach to deal with these cards (non-filesystem)? I'm starting from the current codebase, which uses a emulation layer, so I don't know other choice than continue with this approach. 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. I want to store certificate via PKCS#11 interface, and this interface invokes pkcs15-init to do that. If you know there is other way to redirect PKCS#11 to use directly the card driver, instead of going through pkcs15-init, please tell me. Maybe it would be better to have a single sticky pkcs15-ish mapping for a fixed profile card in a single location (like the pkcs15 emulation drivers) and allow pkcs15-tool (which does not try to create any PKCS#15 structures) to re-generate exposed key slots and replace exposed certificate slots. And extend that API as needed. I don't really understand this idea. - Now, to solve the problem of the path I mentioned at the beginning of this mail thread, I change a bit in gpg_select_file, to automatically ignore the part of DF PKCS15-AppDF (5015). Does it resemble the idea sticky pkcs15-ish mapping for a fixed profile card? - What re-generate exposed key slots and replace exposed certificate slots is for? Thank you. -- Regards, Quân ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
