Re: [opensc-devel] Resources for getting started with ACOS5
Am Freitag 05 März 2010 18:34:18 schrieb Greg Mefford: > Anyone using this card successfully in any capacity that could help me > get started? Once I understand how this thing works, I'm interested in > making it work with OpenSC, but if it currently only works on Windows, > that's fine for now. hmm, not sure about acos5. you could use some usb sniffer to debug what some windows software does, extract the APDU commands, look them up in the manual, and that way get a general sense of what is going on. or maybe first use opensc with some well known cards, create debug log files for well known actions, and see what that apdu commands are and how they work? then you could translate that into commands for acos5 using their manual. I haven't gotten to the point to work/try things with acos5 so far, even I have some cards here. smart cards aren't very friendly for experiements, if you e.g. lock up a transport key (cryptoflex), system key (cardos), or do something wrong with initializiation (acos5), the card is useless. so I guess first step would be a small init of some acos5 card, only create a main folder and a pin to protect it (similar to the startkey/transport key you have with cardos/cryptoflex), and put it into real mode - where security is enforced. other work can then be done on top of that (create directories, more pins etc.) - but you can always get back to that first step by deleting everything. cardos/cryptoflex have that out of the box with startkey/transport key, but with acos5 you would need to setup something like that first, I guess. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Resources for getting started with ACOS5
On 5 Mar 2010, at 17:34, Greg Mefford wrote: > It seems like the card software includes some > Windows tools (which is fine with me if that's what it takes to get > started) and a bunch of technical documentation, but not much > practical help in how to actually use the thing. Right. As far as I know, that's all there is. > The tools are available on Windows to initialize the card > (whatever that actually means...) and administrate it, but the admin > tools seem pretty useless without some idea of what buttons to press > in what order. The Windows administration utility places a file system on the card, essentially, and then lets you load keys and certificates into it. Once you've done that, you can plug the PKCS#11 library they provide into, say, Thunderbird and use it for e-mail. That all works pretty well. The file system is *almost* standards compliant, except where it just isn't. For example, the thing that finally killed my attempts with this card is that they lay down an illegal ASN.1 encoding of something or other (sorry, my notes are elsewhere) which means that processing what the Windows utility lays down with anything other than their software is problematic. Note that the administration utility does *NOT* put a development card into production mode. This means that with an appropriate tool (which they no longer supply in the current SDK, as if that helps) you can *always* set the card to its initial state (or, I suspect, read its contents) unless you've set it to production mode with *another* tool (which they *also* don't give you unless you know to ask about it). So unless you're just playing around, don't make assumptions about for example the secrecy of information on the card. > I have been working for a few days on trying to figure > out how to create an encryption key in the card using the Card Tool > without success. The card tool, so-called, is much much lower level. In theory, you can do anything at all with it, but you need to know what you're doing and as Andreas says you can lock the card doing so. If you actually want to create a key on the card, you need to have a file to put it in first, and that would be non-trivial to do with the card tool. It's easy with the administration utility, but then your problem is the weirdness in the rest of what's laid down by that tool. > Anyone using this card successfully in any capacity that could help me > get started? Once I understand how this thing works, I'm interested in > making it work with OpenSC, but if it currently only works on Windows, > that's fine for now. I'm using these cards in production, but not with OpenSC. I spent about a solid week on it, and got a bit further than you did (I think I got a very dirtily modified OpenSC to do 1024-bit private key operations, and I probably still have that code somewhere) but in the end it was simpler for my purposes just to deploy on Windows and use their library. Don't underestimate the amount of work required to get something like this going, is all I'm saying. -- Ian 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
[opensc-devel] CKA_ID of CA certificates
Hi, in the OpenSC pkcs#11 module the CKA_ID of the CA certificates is reported as '0'. There is Olaf's comment: "Not sure why CA certs should be reported with an ID of 00 --okir 20030413 " What for it was done? Is it still valid? Kind wishes, Viktor. -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Resources for getting started with ACOS5
Thanks for your thoughts. I have since spent some time debugging with Windows as suggested and made some headway. I believe I ran into some of the same non-standard problems you mentioned about the file structure the Initialization Tool installs. I go to do a simple thing like dump all the files on the card and the PCSC driver barfs and crashes. I've started to make some progress with the ACOS5 driver, though, and will try to at least get it to some basic operational state as I have some more time to work on it. Since I initialized the card on Windows with the clear option enabled, I believe I should be able to always re-clear the card... but if it does brick the card at some point, I have a stack of them, so it's alright. ;) ~Greg Mefford On Mon, Mar 8, 2010 at 11:50 AM, Ian Young wrote: > > On 5 Mar 2010, at 17:34, Greg Mefford wrote: > >> It seems like the card software includes some >> Windows tools (which is fine with me if that's what it takes to get >> started) and a bunch of technical documentation, but not much >> practical help in how to actually use the thing. > > Right. As far as I know, that's all there is. > >> The tools are available on Windows to initialize the card >> (whatever that actually means...) and administrate it, but the admin >> tools seem pretty useless without some idea of what buttons to press >> in what order. > > The Windows administration utility places a file system on the card, > essentially, and then lets you load keys and certificates into it. Once > you've done that, you can plug the PKCS#11 library they provide into, say, > Thunderbird and use it for e-mail. That all works pretty well. > > The file system is *almost* standards compliant, except where it just isn't. > For example, the thing that finally killed my attempts with this card is that > they lay down an illegal ASN.1 encoding of something or other (sorry, my > notes are elsewhere) which means that processing what the Windows utility > lays down with anything other than their software is problematic. > > Note that the administration utility does *NOT* put a development card into > production mode. This means that with an appropriate tool (which they no > longer supply in the current SDK, as if that helps) you can *always* set the > card to its initial state (or, I suspect, read its contents) unless you've > set it to production mode with *another* tool (which they *also* don't give > you unless you know to ask about it). So unless you're just playing around, > don't make assumptions about for example the secrecy of information on the > card. > >> I have been working for a few days on trying to figure >> out how to create an encryption key in the card using the Card Tool >> without success. > > The card tool, so-called, is much much lower level. In theory, you can do > anything at all with it, but you need to know what you're doing and as > Andreas says you can lock the card doing so. If you actually want to create > a key on the card, you need to have a file to put it in first, and that would > be non-trivial to do with the card tool. It's easy with the administration > utility, but then your problem is the weirdness in the rest of what's laid > down by that tool. > >> Anyone using this card successfully in any capacity that could help me >> get started? Once I understand how this thing works, I'm interested in >> making it work with OpenSC, but if it currently only works on Windows, >> that's fine for now. > > I'm using these cards in production, but not with OpenSC. I spent about a > solid week on it, and got a bit further than you did (I think I got a very > dirtily modified OpenSC to do 1024-bit private key operations, and I probably > still have that code somewhere) but in the end it was simpler for my purposes > just to deploy on Windows and use their library. Don't underestimate the > amount of work required to get something like this going, is all I'm saying. > > -- Ian > > > > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Resources for getting started with ACOS5
On Mar 9, 2010, at 03:34 , Greg Mefford wrote: > Thanks for your thoughts. I have since spent some time debugging with > Windows as suggested and made some headway. > I believe I ran into some of the same non-standard problems you > mentioned about the file structure the Initialization Tool installs. I > go to do a simple thing like dump all the files on the card and the > PCSC driver barfs and crashes. What crashes, the PCSC subsystem? Or your application? Are the acos5 windows tools available from somewhere? (I have the card but no Windows software...) > I've started to make some progress with the ACOS5 driver, though, and > will try to at least get it to some basic operational state as I have > some more time to work on it. Since I initialized the card on Windows > with the clear option enabled, I believe I should be able to always > re-clear the card... but if it does brick the card at some point, I > have a stack of them, so it's alright. ;) Care to keep some notes on http://www.opensc-project.org/opensc/wiki/ACOS5 that could help others (like me :)) jump into it? -- Martin Paljak http://martin.paljak.pri.ee +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] unify #includes of opensc headers?
On Mar 3, 2010, at 12:08 , Andreas Jellinghaus wrote: > Am Mittwoch 03 März 2010 08:46:27 schrieb Martin Paljak: >> Tokend still requires access to libopensc headers, having it in a standard >> place (/Library/OpenSC/include) would ease the building of it, as it would >> not require any changes in xcode buildfiles before it can be built. Not >> sure if/how it could be automated and changed to pick up headers from a >> custom location. > > what happened to the idea of merging it into opensc? > the cm is also part of opensc source, and at least I don't mind > keeping these components in opensc source code, would even favor > it, as they are closely tied to opensc. Tokend source code comes with a burden of extra pieces required to build it (like the libtoken itself, which is very macosx tokend specific). There's the option of adding the source to the same svn repository but there's no point in distributing it with the tarball. Building it requires extra preparations that is not available via ./configure/make/make install. Also, the licensing of the whole tokend thing is unclear as everything else that relates to apple. -- Martin Paljak http://martin.paljak.pri.ee +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Cosmetic change to sc_pkcs15_verify_pin()
Hi, I propose to change the sc_pkcs15_verify_pin() prototype from int sc_pkcs15_verify_pin(struct sc_pkcs15_card *, struct sc_pkcs15_pin_info *, const u8 *, size_t); to int sc_pkcs15_verify_pin(struct sc_pkcs15_card *, struct sc_pkcs15_object *, const u8 *, size_t); The reason is that every time this procedure is called, the 'pin_info' is extracted from 'object' either directly in the call line, or a few lines earlier. In every actual call of this procedure the pin object is available. This change will slightly simplify the existing code. The same concerns sc_pkcs15_change_pin() and sc_pkcs15_unblock_pin(). Any objections? Kind wishes, Viktor. -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Cosmetic change to sc_pkcs15_verify_pin()
>I propose to change the sc_pkcs15_verify_pin() prototype from > int sc_pkcs15_verify_pin(struct sc_pkcs15_card *, struct sc_pkcs15_pin_info *, const u8 *, size_t); >to > int sc_pkcs15_verify_pin(struct sc_pkcs15_card *, struct sc_pkcs15_object *, const u8 *, size_t);< > > >The reason is that every time this procedure is called, >the 'pin_info' is extracted from 'object' either directly in the call line, or a few lines earlier. >In every actual call of this procedure the pin object is available. > >This change will slightly simplify the existing code. > >The same concerns sc_pkcs15_change_pin() and sc_pkcs15_unblock_pin(). >Any objections? No objections for me, François. 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
