Re: [opensc-devel] Changed certificate on opensc-project.org
2012/3/23 Jean-Michel Pouré - GOOZE : > In the past, main OpenSC developers used to have write access to the > main trunk or at least to their development. Even minor ones, such as myself. > This is no longer the case. The new collaboration tools like GIT are > used to limit the power of the main developers. I do not think so. Anybody is free to write code and share it. > * Only one or two members control commits. > > * As a result, they are overwhelmed with work and cannot keep on > reviewing patches. Some patches have been around for 6 months. Please understand that nobody needs to be a committer in order to be a reviewer. Anyone can be a reviewer, and Gerrit is meant to make that easier. I think that my own position is fairly close to Peter's on this matter. If I had seen code reviews on this list, and their iterations had output reviewed code that did not make it into trunk, I'd agree with you that limited commit rights are a bottleneck. Since I haven't, I can't really say that committers are the bottleneck. I am sure that there are many good examples of this notion. I'll share the first example that comes to my mind, which is the Illumos development process. You can see this going on at https://www.listbox.com/member/archive/182179/=now (even without advanced tools like Gerrit). I will not comment on pcsc-lite, as I don't know enough about it, but I agree with everything that Martin has written today on this list. > * For me the next step is a company like Apple or Gemalto taking over > OpenSC. Some reviewers are already Gemalto contractors, this is not a > secret. This is more of a conspiracy theory than anything else, IMVHO. I might even comment, tongue-in-cheek, that if nobody except Gemalto contractors is interested in reviewing code, then maybe that would be a reasonable course of action. ;) > when reading your statement Emmanuele, we understand that you are > serving the community. Thanks. I actually scratched my own itch. It happened to be the same itch of a larger community, and after that I did agree to doing some work to benefit other community members but not myself. That is all. > Now we are asking Ludovic and Martin to make a statement where the they > confirm a) and b): > 1) The OpenSC project is owned by the community at large, not one or two > individuals. I think that your notion of ownership, as you explained by way of the car example, is misleading at best. A FLOSS project such as this is more concerned with stewardship than ownership, as far as I can see. Best regards, -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Changed certificate on opensc-project.org
Hello, > We all agree here that OpenSC is not a semi-closed project and we ask > you and Marin to confirm that: > > 1) The OpenSC project is owned by the community at large, not one or two > individuals. > 2) That Martin and You are system administrators and developers. As > such, you admit to serve the community. You are not the owners. I believe that I have very little say in this, as my own contributions to OpenSC are tinyish. However, let me say that I believe: - that I do not "own" anything; I have written some code and I have offered it to whoever is pleased to use it under a specific license; - that the same applies to all contributors. I trust Martin and Ludovic to have carried out good work as stewards (not owners) of the project as a whole – and I believe they will probably do so in the future – but I also know that they are volunteers and they are under no obligation whatsoever to serve anybody. Also, the code is out there under a suitable license; nobody is keeping it from me or trying to violate the license under which my own contributions – or anyone else's, for that matter – were provided. I am a member of the community, but the thought that Martin and Ludovic are trying to "take over" (take over what?!) hasn't even begun to speculate about the merest possibility of crossing my mind. What exactly are you trying to achieve? -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] How to make proper use of sc_card_cache
Hi Frank, >> This might have some small variations in the implementations. For >> instance, the Italian CNS (national almost-eID card) seems to follow >> 7816-4 where, when using SM authentication, the first block contains >> CLA, INS, P1, P2 + padding. But the padding is not 80 followed by as >> many 00's are needed to complete the block; rather, it is only 00's. I >> think that these quirks could be best handled by flags, if they are >> reasonably few. > > Could you check if thats consistent with 7816-4 6.2.3.1? I think the > sequential stage also defines the behavior which you are describing. Almost. 7816-4 6.2.3.1 mandates 80h as the first padding byte, followed by zero or more 00h bytes until the end of the block is reached. The CNS specification, on the contrary, skips the 80h byte and only uses zero bytes until the end of the block. Why this behavior was chosen is beyond me; my best guess is that either someone misread the specs, or that one of the card manufacturers who participated in the sessions / round tables that led to the CNS specification already had such an implementation, and it was proposed for adoption. Best regards, -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] How to make proper use of sc_card_cache
Hi, just a couple of comments: > Are your key sets relevant to the encoding of the APDU? If not, then you > could see key sets as part of the crypto layer. The block size of the cipher is relevant for padding. So it actually depends on the notion of key set you decide to implement. If you keep the specific block size out of the key set, it is not relevant. (On a related note: if I understand correctly 7816-4 allows, but does not mandate, to use block chaining across different APDUs in a session, so that you have to keep some state across different commands in order to recover the initialization vector.) > I agree. But you have to keep in mind that ISO-7816 subsumes multiple > cards, which only differ in crypto. This might have some small variations in the implementations. For instance, the Italian CNS (national almost-eID card) seems to follow 7816-4 where, when using SM authentication, the first block contains CLA, INS, P1, P2 + padding. But the padding is not 80 followed by as many 00's are needed to complete the block; rather, it is only 00's. I think that these quirks could be best handled by flags, if they are reasonably few. Best regards, -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] How to make proper use of sc_card_cache
Hello there! >> 3. if we need to, transform this APDU into a sequence of chained >> APDUs, or something else; for instance, if I understand correctly, the >> Spanish DNIe doesn't support command chaining, but rather wants this a >> sequence of ENVELOPE APDUs; > > Enveloped APDUs and Chained APDUs are not strictly the same: Enveloped > APDUs can send effectively only one APDU (such as an APDU with a lot of > data), where chained APDUs can perform a certain operation consisting of > one or more APDUs (such as a get challenge chained with a PSO). Sure. In the DNIe example that I brought, they share the same purpose (breaking up long APDUs), but they are different beasts and can be tamed for usage in different situations. > So your transformation concept is not strictly bound to SM but rather to > smart card operations in general. An other approach would be to hard > code the single steps of transmission rather than to use a more flexible > chain. This is right. > Note that hardcoding is already done in sc_transmit_apdu: An > APDU, that is too long (e.g. extended length) is broken into multiple > pieces and sent. The same is done for the response via get response > commands. So what is the advantage of coding all this with your > approach? Code reuse and streamlining of the architecture. I've seen that different cards do this differently. As en example, let me show how OpenDNIe solved this problem: by 1. adding the "wrap_apdu" operation hook in the card driver 2. adding a global variable of type dnie_private_data_t to store all information needed for SM processing 3. calling wrap_apdu() early in sc_transmit_apdu() 4. wrap_apdu() looks at the private data to check if SM is active; if it is, it calls cw_encode_apdu() to process it 5. wrap_apdu() calls dnie_transmit_apdu(), the custom replacement for sc_transmit_apdu(), which knows how to handle long APDUs for the DNIe card 6. finally, if SM is active, wrap_apdu() calls cw_decode_apdu(), so that it can return an authenticated and/or unencrypted response to the upper layer. This works (for one card), but hard-coding this approach means that each driver has to reinvent the wheel: code duplication, tight coupling, difficult maintenance. With a transformation chain, a driver could pick the bits it needs and at least some of them could be "black boxes" that carry out useful work without forcing the card driver to know about their innards. > Don't fix what is not broken. Your approach is useful and could be > integrated, but if you don't have something in mind that can be done > only or better by your approach, it's hard to justify the work it needs. Yes, I am afraid that I'm over-engineering it. On the other hand, I think that the code for this is rather short and that the other approaches that come to my mind seem to lead to cut-and-paste drivers. > The German identity card uses a very good replacement for basic access > control. It is basically an anonymous key agreement consisting of > something like 6 APDUs. If some other APDU slips into this sequence, > then it breaks the command chaining (this is what I mean with > interfering). The key agreement could be one single operation queued up > with multiple APDUs in one chain. But it could also be superseded by > sending a sequence of subsequent APDUs (one at a time). This would not > require the overhead of a transmit chain. Take for example > sc_set_security_env or sc_pin_cmd. They are interpreted by the card > driver and the driver can also send multiple (hard coded) APDUs instead > of just one (no matter if they are standardized or not). I see what you mean. On one hand, I think that the usefulness of transforming a whole APDU sequence (or an APDU into an APDU sequence) only arises when you recycle the code you may need to break up long APDUs for a given card. In the case that you show, there is certainly no need for this; you can just lock the card and perform the key agreement. The ability to handle an APDU sequence, in my "concept" of a transformation chain, is only useful in the last steps, not in the early ones. As for where this stuff belongs and for whether a transform chain is needed, your example is a perfect fit. Let us imagine that other cards use the same key agreement scheme or a similar one, but must perform different checks to know what algorithms must be used for a given objects (early steps before SM), and have a different way of dealing with long APDUs (last steps after SM and before APDU transmission). In the transform chain, a single function is responsible for *both* ways of the transformation. If there is anything clever in the approach (which I'm not sure of :) ), this is it. A simpler approach would be to just provide a wrap_apdu() hook and deal there with the whole sequence, just like in DNIe. This way we would still achieve code reuse, by simply breaking up the steps in a logical way to get the desired loose coupling, and provide them as functions available to all drivers.
Re: [opensc-devel] How to make proper use of sc_card_cache
On Fri, Mar 25, 2011 at 22:34, Frank Morgner wrote: > SM is a term from ISO-7816, which AFAIK only has something like a > security environment to group operations. So why do you propose to wrap > chained APDUs with SM? Thanks for the comment. To tell the truth, I didn't explain this. I propose to apply the general "transformation" concept both to single APDUs and chained APDUs. In this way, we would be able to: 1. build a non-SM APDU 2. if we need to, transform it into a SM APDU; 3. if we need to, transform this APDU into a sequence of chained APDUs, or something else; for instance, if I understand correctly, the Spanish DNIe doesn't support command chaining, but rather wants this a sequence of ENVELOPE APDUs; 4. finally, apply the last transform – the "send to the smart card" transform – to the whole sequence. > I understand that it can be useful to separate > potentially interfering operations, but this should be done on top of > SM. To be more concrete, such a separation should be done on top of > libopensc, since this could also be needed for non-SM-APDUs. I'm not sure I understand what you mean by "potentially interfering operations", but the way I'm seeing it now, I think I agree fully with your viewpoint. I was not thinking of merging two different APDUs that both require SM into a single sequence. Rather, I was thinking of being able to take what the upper layers see as a single APDU and turn it into a sequence of APDUs to suit the card's needs (lack of extended APDUs and the like). The only case that comes to my mind right now where two different operations intermingle during the processing of a transformation chain is this: it may happen that one of the stages needs to issue a particular command to the smart card (like GET CHALLENGE, or GIVE RANDOM). In this case, the upper layer (libopensc, or above libopensc) does not know that there is a need for such a command to be issued, since it is only needed to carry out the crypto operations; this is why I see a need for the lower layer to be able to issue it independently. (More precisely: one of the stages of the transform chain would pause processing the SM APDU before having sent anything to the card, issue the command, get the result, and use this result it to carry on processing the SM APDU.) Concrete example: let's say we have to ask the card to perform a digital signature. If the security environment and/or the private key's BSO do not call for SM, we must only issue one APDU, and it will probably be a standard ISO 7816-8 command (INS=0x2A, "Perform security operation"). If, on the contrary, they do call for SM, then we *may* have to issue different APDUs before that, but they aren't defined by ISO 7816 and they depend on the card, on the crypto algorithms, on the BSOs, etc. Therefore, I think it might be an advantage to keep the upper layer clean and delegate these matters to the SM transformation layer and to the card drivers (who, anyway, control fully how the transform chain is composed). Sorry for being rather verbose; there's still some handwaving in this architecture and I try to explain it as clearly as I can. Your comments are obviously most welcome! :) (And please, let me know if I got your point or if I missed it! :) ) Best regards, -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] How to make proper use of sc_card_cache
On Mon, Mar 21, 2011 at 15:50, Martin Paljak wrote: >> Has there been any progress or even some results on the discussion about >> SM in OpenSC? > > > Here's just a skeleton, add links and thoughts if you can: > > http://www.opensc-project.org/opensc/wiki/SecureMessaging I've updated the page with my proposed architecture. I believe that it's a bit too abstract to see immediately whether it makes sense, but I've thrown it away and redone a few times, because I'm trying to code it in the meantime and I've already expunged the bits that made the least sense. ;) If everything goes all right, I should have working code in 2-3 weeks. ANY and ALL suggestions, objections, sharp criticism, rotten eggs are more than welcome from everyone, of course! :) Thanks, -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] How to make proper use of sc_card_cache
Hi!
> It's on my conscious .
> I have a strong intention to start this work as soon as possible .
I would like to collaborate on this. My hidden agenda [ ;) ] is to
make this happen in such a way that this work can be used by the
"itacns" driver as well, and possibly by other present and future
drivers.
The requirements for "itacns" are very simple; there is one RSA keyset
that mandates the usage of a fixed-key 3DES SM enc+mac scheme for PIN
verification/changing and for using the key. That is all.
> There are few specification items, that imho should be present in this future
> implementation :
> - common crypto library for dnie and ias/ecc (ias/ecc specification has been
> partly inspired by prEN-14890 standard. Afais, it's the same as cwa14890) ;
It would be great to layer this upon "basic" ISO 7816-4 SM support, so
that it can be used by simpler cards too.
> - two SM modes:
> -- 'apdu' (or pcsc) mode (roughly the same as you implement in your driver)
> -- 'acl' mode where particular ACL initiates the using of SM ;
I shall now try to rephrase what you are saying. Please correct me if
I got it wrong, as I am quite sure I got it wrong. :) This should
relate to how the upper layers (PKCS #15 emulators and card drivers)
trigger the usage of SM and set its parameters. Some card drivers
would handle this without exposing the functionality to PKCS #15,
hence "apdu" mode. Some other drivers could trigger SM usage, and
possibly the setting of specific parameters too, by way of specific
ACLs as seen by the PKCS #15 layers.
> - driver specific callback to filter the APDUs that cannot be used in SM mode
> (for example, for some cards the 'SELECT' command cannot be done in SM);
So, the card driver would have a "filter" callback that would be
called when the APDU is ready to be transmitted. The driver would then
be able to return a value communicating its own "yes, go ahead and use
SM for this", or "no, skip the SM transformation".
> - multiple keysets, they can be defined on the global and on the local level
> (inside of one of the on-card PKCS#15 application);
Sure thing. IIUC, "global" means "provided by the driver itself",
while "local" means "provided by the upper layer" (almost surely PKCS
#15).
> - dynamically loadable SM modules, configured with the OpenSC config files .
As Martin mentioned some time ago, in addition to loadable SM modules,
it would be great to also maintain the capability to embed them in the
main binary itself, statically linked – at least for those that are
distributed with OpenSC itself.
I am wondering whether it can be useful to implement this with a
"transformation stack" concept. I'll try to clarify this.
Let us think of a function type:
int (sc_apdu_transform_cb_t*) (sc_card_t *card, sc_apdu_t *apdu, bool response)
A card driver could define two static functions, sm_transform() and
envelope_transform(), and declare an array:
const sc_apdu_transform_cb_t transforms[] = { sm_transform,
envelope_transform, NULL};
The apdu.c code would be able to call sm_transform() and
envelope_transform() in this order, with the "response" parameter set
to false, before transmitting the APDU, and in the reverse order, with
the "response" parameter set to true, after receiving the response.
(It would be probably advisable to prepare data structures to keep
multiple APDUs and specify what response is expected after
transmitting each.)
These two functions would be able to act as a filter and to invoke the
proper SM transformations, after checking both the APDUs and the
internal state in the sc_card_t structure. Of course, ACL
considerations should take place when checking the internal state.
Also, it would be possible to provide "general-purpose" transform
functions to be invoked by these filter functions (something like
encode_apdu(apdu_pointer, ALG_3DES_ENC_SIG, key_pointer) ).
Of course, these functions should in turn be able to issue commands to
the card and get responses before the transformed APDU is processed
(I'm thinking of GET CHALLENGE and friends).
I am, of course, willing to help with coding or start coding
altogether when I get a clearer picture but I would really like to
exchange a few thoughts on a sensible architecture with all of you. I
am afraid this is over-engineering it a bit, but on the other hand I
would like to make it easy to let all drivers use this SM framework.
Possibly there is some simpler way to do it that would provide the
same level of code reuse.
Thanks!
--
Emanuele
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Compile from source
On Mon, Jan 3, 2011 at 18:26, Brian Thomas wrote: > I need to compile OpenSC version 12 myself. I am working on a custom > implementation using a minidriver in Windows XP. Can somebody please list > the required steps or point me in the direction of the required tools? Any > help is much appreciated. You can find a "Microsoft Windows" section at the end of http://www.opensc-project.org/opensc/wiki/CompilingInstalling I haven't tried it myself recently, but it should be much closer to a working solution than to a starting point, if I remember correctly! Best regards, -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Fix for trivial bug in pkcs15-itacns.c
On Sat, Dec 18, 2010 at 15:09, Matteo Nastasi wrote: > I attach the patch (but the mantainer of the file, Emanuele Pucciarelli, > is also informed so tomorrow he will commit a more consistent version > of the fix, with my fix also). This has been fixed in r4978. Thanks! By the way, the list of manufacturer IDs comes from http://www.cnipa.gov.it/html/docs/CNS%20Functional%20Specification%201.1.5_11012010.pdf . I have been unable to find a later release of that docuement and I wonder how they got to add almost 10 new manufacturers in such a short time. Could you share the ATR of your card, so that we make sure that the driver is not parsing the historical bytes incorrectly? > I'm interested to work on this project, there is a TODO list > of missing pieces ? You may want to get started by looking at the wiki (the developer pages and the open tickets are good places to start) and come back here for any clarifications. More expert guidance than mine will surely be available too :) Bye, -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] itacns driver in WIndows
Will take care of that today or tomorrow, thanks for pointing this out! Best regards, Emanuele On Mon, Sep 6, 2010 at 09:18, Viktor TARASOV wrote: > Hi, > > current trunk cannot be compiled with Visual Studio > that do not supports the declaration of the variables > inside the block after the first instruction. > > Actually it's the case in 'card-itacns' and 'pkcs15-itacns'. > > Kind wishes, > Viktor. > > -- > Viktor Tarasov > > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Redirect loop on Trac login
Hello, I have an issue with Trac. Since I have reset my password I can't seem to login. If I try to login with a wrong password, then the correct error message comes up. If I use the correct one: - using Chrome, whether in Windows or in OS X, I fall into a loop where http://www.opensc-project.org/opensc/prefs/account always redirects to itself; - using Internet Explorer I'm apparently stuck, waiting for a reply after submitting the login form. Can anyone help me with this? I'd be definitely grateful :) Best regards, -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Personal Review Of The Upcoming 0.12.0 Release
Hello, thanks for going through the drivers! > The handful of drivers with insecure operations I was talking about, I > got with the following command: grep -n OPENSSL libopensc/card-*.c > > But looking closer to each drivers source, I must confess that there are > only two of them affected: > > http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/card-westcos.c#L1244 > http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/card-rutoken.c#L1376 Looking at card-westcos.c:1117, I'd say that the "insecure mode" is only used with cards that do not have on-board RSA capabilities, but do have a private exportable key. In other words, it should only be a fallback. On the other hand, it really seems that RSA is only done in software with card-rutoken.c. Perhaps that device does not support RSA in hardware at all? -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Serbian national eID smart card
On Mon, Aug 23, 2010 at 16:02, Goran Rakic wrote:
> Hi all,
Zdravo Gorane! :)
Thanks for the interesting info. I went through the process of reverse
engineering Italian eID two years ago, albeit with much more official
information than you have (we already had a full official
specification of the smart card commands). I'm not a long-time expert,
so I'll put my 2 cents, but I'll be very happy to be corrected by the
list.
> The smart card contains full name, place and date of birth, current
> address, unique citizens number, eID number, photo (fingerprint data and
> electronic signature should also be there). Certificates for legally
> binding digital signatures are included on the card.
Great. I am not 100% sure, but if I've read correctly, this is done
following EU directives about digital signature; IIRC, they forbid the
usage of the same key pair for both legally binding ("qualified")
digital signatures and for web authentication (key wrapping). So, you
probably have two sets of "X.509 certificate + public key + private
key".
> From what I saw, the smart card is in ISO 7816 format (I do not know how
> compatible, it is just what I used to get public data of the card). I do
> not know what would be required to implement the support for this card
> in OpenSC or is it already supported using some of the standard modules.
Most commands are probably already implemented in OpenSC. You can try
running opensc-explorer and using "cd" and "cat" to look at the files
you already know. It is entirely possible that "ls" does not work.
> I can run the middleware inside the VM and trace calls to my reader
> using usbmon, analyzing them with logdecode from carddecoders. My plan
> is to do the tracing during the digital signing and I hope this will
> give me some interesting findings about the card.
It should. Another option you have is to use "apduview":
http://www.fernandes.org/apduview/index.html, in either a virtual or a
physical machine. It works by making the software load a PC/SC library
(winscard.dll) that acts as a shim, logging all exchanged APDUs and
relaying the function calls to the original library, which will
perform the actual communication with the card. It should be a tad
easier, because you can trace APDUs to any card and reader supported
by Windows' own PC/SC API without having to decode the reader's
protocol. I've used it on Windows XP a lot of times without any
hiccups.
> Is this how the things are supposed to work? Should I try something
> different first? Is there some documentation available on how one can
> add support for a new card? I read somewhere that card driver and the
> PKCS#15 emulation are required for every smart card, is that true?
Yes. The card driver will issue the correct APDUs to your smart card,
recognize it, handle any quirks, and so on. The PKCS #15 emulation
behaves like a higher-level driver, if I may say it that way. It knows
where the data files and the certificates are, it knows how to decode
them, and it knows the correct sequence of commands to perform certain
operations (decryption, signature computation…). It presents all of
this to OpenSC's upper layers, so that they can get data files and
invoke crypto operations.
You're welcome to ask for clarifications, help with decoding or anything else!
Regards,
--
Emanuele
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
Hello! > What's the response to the select commands. Please can you post one. > Contains it something like that: A5:07:9F:65:04:02:02:01:01 > Important are the tags A5 and 9F65. If they are present, then it is most > likely that your card is a GlobalPlatform one. Redacted for brevity/clarity: ATR: 3b:6e:00:00:00:31:c0:71:c6:65:01:b0:01:03:37:83:90:00 $ ~/local/bin/opensc-explorer -m aid:a0:00:00:00:03:20:10 -vvv --> 00 A4 04 00 07 A0 00 00 00 03 20 10 .. . <-- 61 22 a" --> 00 C0 00 00 22 " <-- 6F 20 84 07 A0 00 00 00 03 20 10 A5 15 50 05 56 o ... ...P.V 20 50 41 59 87 01 02 5F 2D 08 69 74 65 6E 66 72 PAY..._-.itenfr 64 65 90 00 de.. --> 00 B2 01 0C 00 . (read record 1 from SFI 01) <-- 6C 29 l) --> 00 B2 01 0C 29 ) <-- 70 27 57 […] Bye, -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
On Tue, Aug 17, 2010 at 17:52, Andre Zepezauer wrote: [about improving SELECT FILE in iso7816.c] > It would be nice, if the driver could be configured in a way to support > such a scenario. The bits responsible for card detection should be > placed in a function not part of the driver. FWIW, just to get one more data point, I have experimented this with the two payments card I have. Both are EMV cards and have 31:c0 in their historical bytes, meaning (according to the humble summaries of 7816-4 that Google finds for me) they will only support application selection by full or partial name. In fact, P1==04h is the only value that works for me with them; with the current trunk you can use "info aid:xx:yy:zz..." to get some information. The info isn't exceedingly useful yet; the next steps are interpreting the file type correctly and adding the capability to issue file commands to that file by SFI. (It's in place in the API, e.g. through the "flags" argument of sc_read_record(), but not in opensc-explorer.) Bye, -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Oops, wrong commit (my fault)
Hello everyone,
> Second, if the functioning of opensc-explorer will not change without extra
> options, it is a nice addition.
> Adding a long option ("--mf"?) together with documentation would be nice. I'd
> use -m short option instead of -f (which many other utilities use for
> filesystem based parameters and could be associated by some people as "read
> commands from file" by default)
It's now there in r4637.
The change in r4638 is there because, when starting opensc-explorer
with --mf "", no current_path is set, and there will be none until the
user cd's to a valid DF.
Given that EMV cards are a valid use case where we can issue such
commands as "info" and exchange raw APDU's without ever cd'ing to a
valid path, I have introduced this change to let the system keep the
currently selected file when there is no valid DF to go back to.
Neither r4637 nor r4638 should change the behavior in any way when
opensc-explorer is started without -m/--mf.
Greetings!
--
Emanuele
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4633] Prevent card-incrypto34. c from catching the Italian CNS card's ATR
On Wed, Aug 18, 2010 at 16:36, Martin Paljak wrote: > As there is not much information about incrypto34 available besides the > original commit [1], can you describe the difference or similarities of the > two cards/drivers? Is incrypto34 driver superseded/obsoleted by the itacns > driver? Can they function in parallel? Do you know anything else about the > incrypto card/driver? The CNS specification only contains a small number of commands – those needed to ensure interoperability (to a certain degree), so that any vendor can (in theory) manufacture compliant cards based on the platform of their choice. The specs leave a certain degree of freedom in the ATR issued by the CNS card; only some items, and some historical bytes, are fixed. The "itacns" driver tries to recognize any CNS card and to support any quirk required by specific models. By contrast, the "incrypto34" driver lists a specific, old CNS card and seems to support a wider range of commands, including those required card initialization/personalization (erasing the filesystem and creating the ATR), but I have no way of testing whether they work. Also, current CNS cards manufactured by STMicroelectronics have different ATR's, and it is possible that their command set is different too. The pkcs15-itacns.c emulator uses specific card data that is stored by card-itacns.c, so it wouldn't currently work with the incrypto34 driver. I removed the ATR from the list so that owners of that specific CNS card can use the emulator (the most common use case) without forcing the driver in the configuration file. Those who want to try and play with the card can still use the incrypto34 driver, so I wouldn't say it is superseded; only, it's useful for the rare use case (and, perhaps, with specific cards that were issued long ago). -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Oops, wrong commit (my fault)
Hi, in r4634 I accidentally committed an experimental change to opensc-explorer. That's the -f option. It overrides the MF selection at start-up. If you use it with "cd"'s own syntax, i.e.: opensc-explorer -f 3f001100 or opensc-explorer -f aid:31:32:33:34:35:... then it will select that file at start-up. If you use it with an empty argument, i.e.: opensc-explorer -f "" it won't select any file and let you use any command (I've used it to work with raw APDUs). I can either back it out, or document it properly and re-commit. Any opinions? Thanks! -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
On Tue, Aug 17, 2010 at 03:07, Andre Zepezauer wrote: > Cards which comply with chapter "9 Application-independent card > services" of 7816-4 must implement 1,2,4. The preferred values used by > the iso driver are 0,8,9. Now I think I see what you are after. :) So, you'd like the iso7816 driver to: - try to read the historical bytes and the 2F00/2F01 files - establish the supported ways of using SELECT FILE - remember them and pick the right one every time iso7186_select_file() is invoked, to improve interoperability. Is that correct? Bye! -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
On Tue, Aug 17, 2010 at 00:59, Andre Zepezauer This particular card isn't important at all. But it shows, that the > select_file function doesn't work for an iso card. I had to write code, > to read the contents of this one. But I really would like to use > opensc-explorer for such a task. For example: > cat 2F00 > cat 2F01 I still think it wouldn't be bad if you could give an example of what does not work and what does, because then, perhaps, someone would be willing to help implement the missing (or wrong) functionality – especially as you've already written your own code. As far as debit cards are concerned (EMV), my experience is that opensc-explorer does not work because it tries to select the Master File upon startup. A small patch to let the user choose a different file, or not file at all, at startup, would overcome that. (Surely there would be other problems later.) I'm unsure about your example of "cat 2F00, cat 2F01", because I'm under the impression that EMV cards use file selction by name (and not by file ID), but I may very well be wrong here. > There is still the question, if this is the right place for a command > not defined by iso. My answer is clearly not, because: > 1. Iso defines CLA 0x80 as proprietary which means, that every vendor > can code it's own proprietary commands in this class. Which in turn > leaves the possibility, that two different vendors define the same apdu > command in two completely different ways. Yes, this is possible in principle, although many sensible COS manufacturers (or even developers writing BasicCard/JavaCard applets) would question the opportunity of defining a proprietary command overriding an international standard (EN 726) that's been in place for so long. But the point is moot, because… > 2. Not even a single card driver overrides iso_ops->give_random. So > every driver would send this command down to the card. Which is not a > good idea (see point one). …as far as I am able to tell, this means that no driver at all will ever send this command to the card, until someone decides to use it somewhere in the code. That said, I'll reiterate: if give_random is significantly controversial, I won't object to removing it, as it isn't being used. Bye! -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
Hi Andre! Thanks for the remarks! > It works very well, right now. I have a modified cardos driver, which > uses both functions (signing and decipherment from iso7816.c) with keys > of 2048 bit. Seems to me, that there is nothing to be done here. Good to hear. Are you using reader-pcsc? > @martin: When you are interested in improving iso7816.c, then rewrite > the select_file function. It is not very generic. For example it won't > work for my german debit card, which is of course iso-compliant. Also > get_data/put_data could be implemented. Speaking for myself here – examples and/or log traces would be helpful, I think. What doesn't work with your card, and you'd like to see improved? > @ep: APDUs with Class Byte 0x80 are very misplaced in an iso-driver. I > guess that this was an accident. It isn't, to tell the truth; as the comment states, that APDU is not from ISO 7816, but rather from EN 726-3 (or ETSI TS 101 206-3, if you wish). The driver isn't using it any longer (as I'm looking at SM separately, following Viktor's work), so I don't "need" it. It may make sense to leave it there, though, as it is clearly marked not to be from ISO 7816 but from a different standard. Greetings, -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [PATCH] fix buffer overflow in pkcs15-itacns.c
Hi Kalev, > gcc warns about a potential buffer overflow: […] Thanks! I'll fix that in both places (lines 540 and 552). To be honest, no overflow should ever happen, as the label is always a static string; nevertheless, those lines are ugly, and I think gcc is right in complaining about that. :) Best regards, -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Fwd: New Italian CNS/eID patch
[Sent to Martin only by mistake. Apologies.]
On Sun, Aug 15, 2010 at 16:11, Martin Paljak wrote:
>> I think that the checks already in place are all right. I guess that
>> implementation quirks may arise if and when 2048-bit keys are
>> supported, but currently I know of no CNS card with keys longer than
>> 1024 bit, so it's safe for the time being.
>
> That's a good example: iso7816.c should be eventually updated to work with
> extended APDU-s and 2048b keys as well.
I guess that it should also include the proper workarounds for
configurations (card readers, or specific reader+card combinations)
that do not support extended APDUs properly. I should have a CardOS
4.2/4.3 card that could be initialized with 2048-bit keys. Will write
that down as a worthwile project. :)
> Some things to consider
> * javacard driver really should be the last but one driver before default.
> It is as dummy by nature as the default driver.
> * card->name vs driver->name. Currently the card driver name is long and in
> Italian ("Carta Nazionale dei Servizi") while the card name is short and in
> English. Keep in mind that the driver name is hidden from most users and the
> card name pops up with opensc-tool -n and in your case in PKCS#11 token
> labels. You might want to balance between them, as long as OpenSC does not
> have localization support.
> * Also, you use the card name as the PKCS#15 card label. From personal
> experience I'd suggest to use something personal instead of that, so that
> Firefox or thunderbird could differentiate between two cards of the same
> type. For the Estonian ID-card it used to be "ID-kaart" as well, but "MARTIN
> PALJAK (PIN1)" prompt beats "ID-kaart (PIN1)" prompt.
I've taken care of them in
http://www.opensc-project.org/opensc/attachment/ticket/177/itacns-patch5.diff
The only noteworthy new part is at pkcs15-itacns.c:319 and following,
where the cardholder's personal data is read and parsed. I think the
code is defensive enough not to break even with invalid data in the
file.
Bye!
--
Emanuele
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
On Sun, Aug 15, 2010 at 13:45, Martin Paljak wrote: > Great! IMO that's good to go, I have only one small comment: > * Do I miss something or does the itacns_compute_signature -> > do_compute_signature chain translate almost 1:1 to iso7816_compute_signature > with an additional check in itacns_compute_signature ? > * The same seems to apply for itacns_decipher -> do_decipher and > iso7816_decipher That's entirely correct. :) I have double-checked, and I have removed the "custom" functions from card-itacns.c altogether. > iso7816.c should not be taken as a final, static code, if there are checks > missing from there, it is OK to improve iso7816.c as well :) I think that the checks already in place are all right. I guess that implementation quirks may arise if and when 2048-bit keys are supported, but currently I know of no CNS card with keys longer than 1024 bit, so it's safe for the time being. > I guess #237 would solve the problem almost cleanly for you. > > I remember a similar problem with Estonian ID card but after some digging in > the specs and card manual it turned out to be somewhat sensible (Maybe > something like 0x00 Le indicating "give me as much as you have", like in > deciphering comments) but I can't locate the details nor changesets about it > now. This was the right hint – I hadn't thought of that. :) Even though certainly no data is expected from the card when issuing a MSE command, I switched to a Case 2 APDU with Le = 0. The transmitted APDU is exactly the same (P3 set to 0), and I think that leaving room for a small buffer on the stack is a less ugly workaround than disabling the check logic in apdu.c. So the driver can live without #237 :) > javax.smartcardio also does APDU mangling and it is not possible to send such > APDU-s, as it eats away the final zero... Thanks for the heads up. It might be that I'm going to play with it in the future (Roberto Resoli graciously pointed me to the Mocca project[1]). I hope that the CommandAPDU(ByteBuffer apdu) form does not try to mangle the APDU, but I've never tried. The revised patch is now at http://www.opensc-project.org/opensc/attachment/ticket/177/itacns-patch4.diff , and I feel it addresses all points that have been brought up. Thanks! [1] http://mocca.egovlabs.gv.at/ -- Emanuele > > >> Thank you in advance for any comment/feedback. I'm looking forward to >> getting this into shape for integration in trunk. > > > [1] http://www.opensc-project.org/opensc/ticket/237 > -- > Martin Paljak > @martinpaljak.net > +3725156495 > > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] New Italian CNS/eID patch
Greetings, I have uploaded a new, updated patch for Italian CNS support against the current trunk: http://www.opensc-project.org/opensc/attachment/ticket/177/itacns-patch3.diff Now all Secure Messaging bits are completely out (I'm working on that separately) and there is only a tiny bit of dead code in apdu.c – I'm unsure how to deal with that. The check *should* be there for short Case 3 APDU's, but I can see no way to disable that only for Italian CNS cards without fundamental changes to apdu.c (i.e. something like a sc_trasnmit_apdu_without_check() function, or a "purposefully broken APDU" flag in the sc_apdu_t structure). Thank you in advance for any comment/feedback. I'm looking forward to getting this into shape for integration in trunk. Bye! -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Patch to display correct EF ACLs in opensc-explorer
Hello,
it seems to me that ACL handling in opensc-explorer is wrong. It
assumes SC_AC_OP_* flags are numbered in the same order as in
opensc-explorer.c:436 (used to display DF ACLs), which is correct. But
then, a few lines later, it employs a different label list for EF
ACLs, which IMHO is wrong. I made this tiny patch – do you think it's
all right?
Greetings,
Emanuele
diff --git a/src/tools/opensc-explorer.c b/src/tools/opensc-explorer.c
index 6c74094..9bc5260 100644
--- a/src/tools/opensc-explorer.c
+++ b/src/tools/opensc-explorer.c
@@ -453,16 +453,25 @@ static int do_info(int argc, char **argv)
"Linear fixed, SIMPLE-TLV", "Linear variable",
"Linear variable TLV", "Cyclic, SIMPLE-TLV",
};
- const char *ops[] = {
- "READ", "UPDATE", "DELETE", "WRITE", "REHABILITATE",
- "INVALIDATE", "LIST_FILES", "CRYPTO",
+ const struct {
+ const char * label;
+ int op;
+ } ops[] = {
+ { "READ", SC_AC_OP_READ },
+ { "UPDATE", SC_AC_OP_UPDATE },
+ { "DELETE", SC_AC_OP_DELETE },
+ { "WRITE", SC_AC_OP_WRITE },
+ { "REHABILITATE", SC_AC_OP_REHABILITATE },
+ { "INVALIDATE", SC_AC_OP_INVALIDATE },
+ { "LIST_FILES", SC_AC_OP_LIST_FILES },
+ { "CRYPTO", SC_AC_OP_CRYPTO },
};
printf("%-15s%s\n", "EF structure:",
structs[file->ef_structure]);
for (i = 0; i < sizeof(ops)/sizeof(ops[0]); i++) {
char buf[80];
- sprintf(buf, "ACL for %s:", ops[i]);
- printf("%-25s%s\n", buf,
util_acl_to_str(sc_file_get_acl_entry(file, i)));
+ sprintf(buf, "ACL for %s:", ops[i].label);
+ printf("%-25s%s\n", buf,
util_acl_to_str(sc_file_get_acl_entry(file, ops[i].op)));
}
}
if (file->prop_attr_len) {
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Sub-project for OpenSC with secure messaging and multi-applications
On Fri, Jul 23, 2010 at 17:14, Roberto Resoli wrote: >> As for me, there is no sense in SM keys embedded in the middleware. > > I am with you ... There would be no need for "me too" here, but I'll write it just for the record. > This interpretation seems even more valid looking at "Figure 8 - […] Thanks for this. I knew I could count on someone who'd looked at those documents much deeper and better than I did :) Those excerpts are quite telling. In general, I would venture to say that they promote and support the view that (1) one's typical desktop computer is a "trusted environment"; (2) cryptography is not a magic wand and has to be implemented and evaluated in the actual operating context. (With a tiny bit of sarcasm, I might add that this is true for any solution and crypto algorithm, especially when the design calls for a 0-bit keyspace, i.e. a single possible key. ;) ) > Nice to hear, I hope someone out there is hearing as well ... It would be great to standardise on something sensible like this. In the meantime, I hope that we can integrate CNS support with Viktor's work (I'm still looking at it but I'm very positive about it). Bye, -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Sub-project for OpenSC with secure messaging and multi-applications
On Fri, Jul 23, 2010 at 14:00, Anders Rundgren wrote: >> I'm not sure I understand entirely; so the system uses a digital >> signature, but would you know if it uses secure messaging too? > > They do not use SM. If they did somebody would reverse engineer > the software and claim "victory" or something like that :-) Er, right, been there… 0:-) > SM was probably designed for usage in certified terminals so that the card > wouldn't do anything interesting except in such a device. Which is the idea in CWA 14890-1, as far as I can tell, paragraph 8.2: the card holder decides whether the environment is trusted or not, and if it is, the path is already trusted, without a need for secure messaging. The examples of untrusted environments are limited to signing application and SSCD being in different physical locations, or biometrics. >> Do I infer correctly that the system uses secure messaging, but >> client-side software is limited to relaying encoded APDUs that are >> generated/decoded by the server-side application? > > You mean SKS/KeyGen2? > > Yes, the client software is a semi-trusted proxy that does the heavy > lifting including XML encoding/decoding, networking, and GUI but it is > still a fully E2ES (End To End Secured) solution with user PIN setting > as the only exception. If the proxy does not relay properly the > system will abort in one of the ends (SKS or issuer). > It is like Global Platform's SCP80 on steroid's. I was thinking of the Swedish system, but you answered me by telling me it doesn't use SM. Besides, I started looking at KeyGen2 yesterday, so the clarification is welcome :) Thanks! -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Sub-project for OpenSC with secure messaging and multi-applications
Hi Anders, I'm very interested in these matters too. (Thanks, Roberto, for starting the discussion here!) >> Moreover, I'm rather curious about SM for digital signature outside >> Italy; is it used at all? > > It is a used by for example Swedish governments for citizens' on-line > tax-declaration. > I believe 500 000 people used it this year. I'm not sure I understand entirely; so the system uses a digital signature, but would you know if it uses secure messaging too? >> If yes, is it implemented in a similar fashion? (SM keys embedded in sw >> libraries?) > > No, I don't think SM has reached out to citizen/consumer PCs for several > reason including a IMHO rather questionable security model. Why would > the libraries be any more trustworthy than the rest of the computer? Do I infer correctly that the system uses secure messaging, but client-side software is limited to relaying encoded APDUs that are generated/decoded by the server-side application? As for your question: I agree entirely with your observation, as there is nothing making client-side libraries more trustworthy or able to shroud the SM keys, yet this is the model by which Italian qualified signatures are deemed compliant with CWA 14169. Thanks! -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Italian CNS integration (without SM)
Dear Andre, > it would be nice, if you could provide some more information about the > card you are working on. What I'm interested in is: If there are keys on > the card which are usable for signing but not for decrypting or vice > versa (in context of pkcs11/15)? And if so, is the pkcs1 padding for > this keys is added/removed by the card or is it done in the library? Yes. The main key can be used by policy for both signing and encryption/decryption, but the card won't accept the CDS command, so that at the driver level, the key can only be used for encryption/decryption. IIRC the padding is performed by the library; the card blindly encrypts the given block (but, alawys IIRC, does require that the block is PKCS #1 compliant). > The point is, that I'm having a local patch for the cardos driver that > works without the try-and-fail hack and doesn't even need the NEED_USAGE > mechanism. It works perfectly for me but isn't a general solution yet. > Depending on the keys on your card it could be helpful for you too. It could be definitely helpful. Thank you very much! -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Italian CNS integration (without SM)
On Wed, Jul 21, 2010 at 13:44, Martin Paljak wrote: > Reading the code it all feels hairy, the patchwork that sets the flags in > pkcs15.c and the try-and-fail approach in card-cardos.c > Stricter mapping of actual card and its capabilities to something like card > flags and proper failing with a debug message would be much better. Currently > it seems to me that mysterious failures can happen. Agreed. I hope the somebody else can chime in on this; I'm under the impression that CardOS has too many versions and installable packages to determine this with some degree of certainty. (Unfortunately the same applies, to a smaller extent, to the CNS card… 12 mask manufacturers, an ever-varying number of authorized issuers, and I'm still trying to hunt down who is responsible for what.) > Exact knowledge of what is supported as input (hash, raw data, padded data > etc), what gets fed to the card and what is expected as the return should be > very explicit. As should be the hacks that are supported. > I don't have any cardos cards to try it out. If I understand correctly, the problem with those cards (and possibly not only those) is twofold. I'll write my findings here so that I can stand corrected, and that the resulting discussion can be later googled: 1. a single private key will not support both signing and encryption: if a key is supposed to do both, then the software is supposed to perform a signature by calling the encryption command. This is already implemented at the PKCS #15 emu layer (I've noticed pkcs15-cardos.c:522 and following for initialization, and pkcs15-sec.c:194 and following for usage); 2. with CardOS, the padding to be used for signature is determined at BSO creation time. So, beside trial-and-error, the solution (IMHO) would be having an upper layer set it explicitly. My interpretation is that the code in pkcs15-sec.c already does this based on the "flags" argument of sc_pkcs15_compute_signature(), so there should be no need for the trial-and-error logic in card-cardos.c, but… perhaps I'm missing something here? [Give random] > No real preference, I think a comment about ETSI origin in both the header > file as well as source file would do just fine. Will do so. > I attached a modified patch to the original ticket (#177). Comments: > > * No dead code (#if 0 and #if 1) in the patch > * The card should be read-only (correct?) and pkcs15-emulated, so it does not > support key generation -> no flags should be set about it. In fact, I'm not > sure SC_ALGORITHM_ONBOARD_KEY_GEN is useful at all. It should be checked if a > pkcs15init driver exists that does currently not support key generation. We could support it, in principle, but probably nobody would ever use it (unless a certified issuer decides to adopt OpenSC). > * Same applies to SC_ALGORITHM_NEED_USAGE. Are you sure about it? I think I am; if I'm not mistaken, without that flag, the code at pkcs15-sec.c:197 and following will try to invoke PSO_CDS on keys that require DECipher. > * I don't understand "itacns_ops = *(sc_get_incrypto34_driver()->ops);" when > initializing the card driver, why so? Why not use the ISO function > overloading as other drivers do? At some point I wanted to use those functions by default, because they happened to be correct for the CNS card, but you're right – it's much cleaner if I invoke them directly, or copy them into the itacns driver. > * MAX_LE and ITACNS_MAX_PAYLOAD, would it make sense to resort on one single > value that gets fed to card max_recv_size? Yes. I copied that from the incrypto34 driver, where apparently it isn't even used any more. So I'll get rid of one or both of them. I'll work on this stuff and remove any remaining dead code, then resubmit. Thanks! -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Italian CNS integration (without SM)
Hello, here's a patch for Italian CNS support against the current trunk, this time without secure messaging. The plan is to reach a consensus on this version, then add Secure Messaging, building on Viktor's work. There shouldn't be any thorny issues to deal with. The two outstanding discussion points, IMHO, are: - in card-cardos.c, I changed the logic around line 820, because I think that the previous handling of outlen was downright wrong – am I missing something fundamental? - I kept the "Give random" function in iso7816.c. It doesn't really belong to ISO 7816, but it does belong to ETSI TS 101 206-3, and it is shared by many cards. What do you think about this? Should I confine it to card-itacns.c, or is it OK to keep it there, os other (and future) drivers could benefit from it? Any feedback is extremely welcome! Thanks, -- Emanuele itacns-r4518-20100719.patch.gz Description: GNU Zip compressed data ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC support for HID token
On Thu, Jun 10, 2010 at 14:20, Ludovic Rousseau wrote: > The advantage of using a HID interface instead of CCID is that, on > Windows, any user application can talk to a HID device without > installing a driver. > With a CCID interface and an old Windows (before Vista I think) you > have to install a CCID driver and then you need to have the > administrative access rights for that. I can confirm that the same should apply to OS X. > Vendors are dreaming of a world of zero-install (no admin rights > needed) and zero-footprint (no files copied on the hard disk). You > just plug your device and you can use it (using autorun). Of course my considerations about security depend strongly on the threat model – a lot of compromised machines are compromised enough that malware can work with admin rights, so I admit it doesn't make a lot of difference in that (common) case. > On GNU/Linux it is different. The kernel HID driver will use the > device and you need to be root to disconnect the device from the HID > driver and use it the way you want. My tests show that these HID devices are caught by the hidraw driver, so they are ready to be accessed from the userland. Still, one has to reconfigure udev to assign privileges to the right user (or to the console group, etc.) for things to be automatically ready every time that the token is inserted; either that becomes the default in mainstream distros, or users should be happy with an "almost-zero install" experience. > Doing AES in hardware is not expensive and is fast. Good! (I'm not up-to-date with any of that – it shows, doesn't it? :D) I wouldn't be able to suggest whether the best approach would be a new driver for pcsc-lite, OpenCT, or an OpenSC reader module; probably one of the first two would be more flexible/recyclable, since they could be used in other environments, and on the other hand a "key-portable" version of OpenSC could open and use their libraries as well. Bye, -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC support for HID token
Hello Jean-Michel, > Do you have any information on the work involved to add some HID > protocol to OpenSC. Is HID protocol standard or would any solution be > proprietary? Just trying to add my 2 cents: I am aware of tokens that expose a USB hub with more than one device connected to it. Specifically, one or more mass storage units and one or more HID devices. The mass storage units are seen by the system as standard units, while the HID device gives access to a card reader through a proprietary protocol. The advantage of this solution should be that, on many operating systems, you can access the card reader without elevated privileges and without having to install any drivers – just use the userland software provided on the storage unit. Of course, security-wise I tend to see that more as a disadvantage; the first thing that comes to my mind is a drive-by download that can sniff your card transactions and use your token without the need for any special privilege. What seems unlikely to me is mass storage encryption directly on the device: I would guess that you need expensive hardware (at least, expensive compared to ordinary smart cards) to perform decent encryption at reasonable bitrates for a mass storage device, but I'm not knowledgeable on this front and I certainly stand ready to be corrected! It would still be possible to add a HID reader module to OpenSC, but you would need an OS-specific lower layer and a reader-specific upper layer, and either get precise specs from the vendor or go through quite a bit of reverse engineering. Bye, -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Five tickets with patches
Hello, > Unless somebody has comments or corrections, they'll be merged. The only > problematic ticket is #177 which is actually a set of patches (that need > manual merging for now) and that adds a major feature, secure messaging. My bad. Been meaning to tackle that for more than a year (and I didn't follow up privately with you on that – writing it here just to acknowledge that I *did* promise to work on it, but didn't do it :) ) > Basically there's a mini-fork on http://itacns.corp.it/browser (requires > registration) that should be eliminated better now than never. Agreed. > Viktor, you had plans with secure messaging as well, I know that this > specific implementation (it reads keys from a config file or environment, > IIRC) is not what you have in mind, as it should also support remote tunnels. > Can you have a look and see if: > a) parts of it can be integrated anyway > b) some of the code could be re-used for a better SM implementation > c) some parts of the design can be upgraded on the way I'm more than willing to collaborate on this. Thanks :) -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [Csp11-devel] [CSP11] MinGW build and lots of fixups
Il giorno 25/ago/08, alle ore 14:01, Andreas Jellinghaus ha scritto: >> The big advantage is that it is short (less than 2000 lines before >> clean-up) and it does not need signing by Microsoft. > > nice. do you use opensc code directly, or do you use the PKCS#11 > interface > to opensc-pkcs11.dll? I use the PKCS#11 interface. That's almost a must – myself, I wouldn't know any interface really well, so PKCS#11 has the advantage of being thoroughly documented… >> The disadvantages are that (1) it only runs on Windows XP+ (Vista >> included) and > > I don't think users of Win2K and older are likely to start using > smart cards. > so I wouldn't worry about this one. Agreed. Especially as things are even better: I'm checking it now, and KB909520 provides a version of Base CSP that runs on Windows 2000 SP4. Only Windows 9x/ME are left out, then. >> hmm, if the hack is config file enabled, people would need to switch > edit it, when switching from outlook/ie/login/... to cmd line tools/ > putty/... > and back? maybe some other solution could be used (like environment > variables - easy way to store some text value that the library code > can > reach). Actually, I'm doing both. The configuration file has the names of the environment variables to check for; if they are missing, or if the conversion of the pointer fails, then it behaves as though there were no hack. > sure it remains a hack, but I think it is most important to find one > well > working solution (as there are generic but not always well working > alternatives already - csp11 and pkcscsp). Now that you made think of it, there is a cleaner hack: a replacement winscard.dll, in the spirit of APDUVIEW. The interface is thankfully standard, so we can write a new winscard.dll that opens the original one upon loading. If there are no environment variables, or they are not valid, then it calls the corresponding function of the original DLL without performing any operation. If there are, then (1) it only enumerates one reader and one smart card, the one that has been already opened; (2) it reports successful connections/disconnections without actually doing anything, and returns the pre-opened handles to the calling application; (3) when it is called with those same handles by the application, it forwards the parameters to the original DLL and performs the APDU transfers, transparently returining buffers and results to the calling application. It shouldn't be difficult, and it should work with all PKCS#11 libraries, provided that it is installed by dropping the "fake" winscard.dll in the same directory as the PKCS#11 DLL. >> one question: I think both CSP#11 and pkcs-csp had some tool to >> "register" > certificates or similar, but I don't know the details about what the > tools > did and why. It's fairy awful; CSP11 comes with a 1000-line C program to do just that. These tools add the certificate to Windows' certificate store, so that it knows that the user owns the certificate and has a private key for it, and it knows what is the responsible CSP for it. > do you need any special tool with your approach? Luckily everything is provided by the Base CSP, so the user still has to register the certificates, but it is done via Microsoft's standard interface, and possibly some applications handle it on their own. (At least for testing, "certutil.exe -scinfo" is enough to do everything, it tests the smart card and pops up a certificate listing where you can just click OK to install the certificate; and it's likely that there are some other completely mouse-friendly shortcuts.) > also I wonder: if the smart card mini driver opens pcsc with locking > the > driver - how can several applications use the smart card? for example > internet explorer, outlook and the GINA (login screen / screen lock)? Correct; to be precise, the Base CSP opens the card in exclusive mode and passes the handle to the minidriver. I think that this only happens when the user has to log in, though. After the "sensitive" operation is done, the Base CSP asks the driver to deauthenticate (or to reset the card, if there is no "logout"/"deauthenticate" function) and releases the lock. It also keeps a cached copy of the PINs, so that when the same application wants to log in, Windows can perform the verification behind the scenes, without bothering the user; performs the actual operation; and then deauthenticates and releases the lock again. > did microsoft a central service that the applications talk to, or > does the > driver need to read all public info and then close the pcsc driver, > so other > apps can open it? or some other solution? Both are correct; all the applications that use the CSP API talk to Windows, which talks to the Base CSP provider, which chooses the right minidriver and talks to it. But if an applications wants to use PC/SC directly, or by linking to a PKCS#11
Re: [opensc-devel] [Csp11-devel] [CSP11] MinGW build and lots of fixups
Il giorno 25/ago/08, alle ore 08:49, Alon Bar-Lev ha scritto: > Can you please explain some more? > Actually, I would like to see a generic minidriver that use PKCS#11, > so it able to use any provider out there. > Maybe you can fake a handle and delay the connection? I would like that too, but I can't see how to do it, unfortunately. The Base CSP opens the card connection in exclusive mode, at least at login, and I think (I haven't tried it out!) it is kept that way until the operations that require the login have finished. So I'm expected to return valid results, e.g. a signature, before Windows releases the exclusive connection… -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [Csp11-devel] [CSP11] MinGW build and lots of fixups
Hi all, > noone is maintaining CSP#11 I think. > > the alternative would be PKCS-CSP, which we also host on opensc- > project.org, > but which is also unmaintained. I think it handles some stuff > better, and a > few people reported success with this or that modification. but I > never got > around to build it myself and test it - no windows here any more. I have one more alternative – I have written a smart card minidriver for the Base CSP architecture. It's beta-ish, but it correctly handles IE connections; I haven't tested Outlook et al. yet, but they should be fine. The big advantage is that it is short (less than 2000 lines before clean-up) and it does not need signing by Microsoft. The disadvantages are that (1) it only runs on Windows XP+ (Vista included) and (2) it requires a hack in reader-pcsc.c. In detail, Windows connects to the card first, and then passes a PC/SC context and handle to the minidriver. Therefore, I had to modify reader-pcsc.c to read pointers to them from the environment. It is not beautiful, but there should not be any security implications since this behaviour can be turned on or off from the main OpenSC configuration file. If it sounds "good enough" an idea, I'm going to push myself to clean it up and release it a little earlier :) Regards, -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] A graphical PIN dialog for PKCS#11?
Il giorno 10/ago/08, alle ore 00:13, Ludovic Rousseau ha scritto: > Is it that simple than returning an error code (or something similar) > to Firefox so that Firefox asks the PIN to the user and issue a new > C_Login() with the PIN to the provider? > > Does OpenSC support that feature? > Does Firefox support that feature? In theory, if the private key has the CKA_ALWAYS_AUTHENTICATE attribute set (PKCS#11 §10.9, towards the end), then one C_Login() call will suffice for just one use of the private keys, and subsequent uses will return CKR_USER_NOT_LOGGED_IN. I would guess that OpenSC does not support that right now, but it should be fairly easy to implement, and I would expect Firefox to support it. (Even if the developers did not support it explicitly, getting CKR_USER_NOT_LOGGED_IN as a result from a signature should be enough to make one want to login again!) Bye, -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ACOS5
Hi Andreas, > maybe it is possible to create an MF and a PIN (similar to the > transport > key of the cryptoflex), and go to user stage. then at user stage > use that pin to create all other structures. I haven't checked the details, but I believe that this is possible. In this way you could use this "admin PIN" to delete any files on the card, except the MF, provided that you do that in the correct order, and start from scratch anytime. Of course, when creating any files one should take care to always give full rights to the admin, or there will be no going back… Bye, -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ACOS5
Hi Johannes! I was thinking about writing an ACOS5 driver but I don't have too much time on my hands these days – maybe I could help you, though… > I suspect the documentation to be incomplete regarding initialization. > I have "ACOS5 Reference Manual v1.4, 06-2007". Anything else > available? I have 1.5, 7/2007. It does not say much about initialization, though. I agree that it would be probably easier to initialize the card in a standard PKCS#15 fashion, rather than emulating the supplied proprietary middleware. It's bothersome not to know what the initial blob does, though. > Don't know if this is possible. Documentation talks about "Pre-Perso > Stage", "Perso Stage" and "User Stage". This would require that the > card > is functional in the 'Perso Stage' or there is a way back from 'User > Stage'. My understanding is the same as yours: before you activate the files the card is not really functional, as security attributes are not enforced, and once you activate the MF or any other file on the card, you enter the "User Stage" and it's impossible to go back to the "Perso Stage"… Bye, -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed [3535] Make PC/SC work on Windows again
Il giorno 03/lug/08, alle ore 09:22, Ludovic Rousseau ha scritto: > Hello Alon, > > I do not understand your patch. In which cases SCardListReaders() is > returning ERROR_INVALID_HANDLE? > This error code is not a PC/SC error code. I checked with pcsc-lite > and SCardListReaders(-1, ...) correctly returns SCARD_E_INVALID_HANDLE I've had the same problem with SCardEstablishContext (and prepared a similar patch, checking for either SCARD_E_INVALID_HANDLE or ERROR_INVALID_HANDLE). In Windows XP, you get the standard (correct?) behaviour; in Windows Vista you get ERROR_INVALID_HANDLE. Microsoft forums show lots of unsuccessful attempts at digesting this issue: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1850074&SiteID=1 http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=1880083&SiteID=1 Bye, -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Implementation of Secure Messaging
Hi everyone,
ticket http://www.opensc-project.org/opensc/ticket/177 hosts a set of
patches to add support for the Italian CNS/CIE (eID) card. It's
Republic Day in Italy, and it looks like a most appropriate occasion
to release a new version.
The last round includes support for Secure Messaging. I figure this
could turn out to be important for other drivers or part of OpenSC as
well, so I'd like to post here what I did and how. I'm not sure I did
it the "right way", so I'm writing some clarifications here for
everybody who may be interested to comment on and for the core
developers who may want to merge the patches into trunk.
The tarball contains a set of 7 patches and a small Python tool.
Patches:
* 010-apdu: Currently, libopensc detects Case 3 APDUs with a zero data
length and rejects them. Nevertheless, one of the Italian CNS cards
that I have tested seems to require a 0 byte at the end of the MSE
command ("restore" option), as though it were a length+value structure
with a zero length. I have changed apdu.c so that it allows to send a
Case 3 APDU with zero-length data.
* 020-give-random: It is my understanding that the GET CHALLENGE APDU
is part of the ISO specification, while the GIVE RANDOM one is not.
Nevertheless, it also seems to me that the CLA=0x86, INS=0x00 command
is kind of standard across different cards. For this reason I have
chosen to implement it as part of the "base" ISO driver, and add the
give_random operation to the sc_card_operations structure; it seemed
to me that it would be cleaner to do it this way.
* 030-sm-main. This is the bulk of the SM implementation. It includes
the sm.c module and the sm.h header file. The module relies on OpenSSL
and exposes three functions:
int sm_generic_send_transform(sc_card_t *card, sc_apdu_t *o_apdu,
sc_apdu_t *t_apdu, const u8 *key, int enc_method, int sig_method,
void **store);
int sm_generic_receive_transform(sc_card_t *card, sc_apdu_t *o_apdu,
sc_apdu_t *t_apdu, const u8 *key, int enc_method, int sig_method,
void **store);
int sm_generic_free_storage(void **store);
They are not used directly; rather, card drivers that want to make use
of them can do so in their own card_operations.
Currently they only implement 3DES encryption and MAC3 signing; they
can be extended so that more mechanisms are available to all card
drivers.
sm_generic_send_transform takes the original, ready APDU (o_apdu) and
a fresh APDU structure for the transformed APDU (t_apdu). Based on the
key, enc_method, sig_method parameters, prepares the transformed APDU;
the caller may then send it. sm_generic_receive_transfom does the
opposite, and is meant to be called upon reception of the answer from
the card.
Since we have to maintain some sort of state between the two calls,
both functions take as an argument the address of a pointer. The
pointer itself is allocated and set to NULL by their caller.
sm_generic_send_transform uses it to allocate a local data structure
with the needed buffers.
The caller is responsible for calling at least once, at the end of the
transaction, the "free_storage" function, which takes care of cleaning
everything up. It is possible that, because of an error, the receive
function is never called; the cleanup function must be called anyway.
The module also exports two small macros, SET_SM_STATUS and
RESTORE_SM_STATUS, for the modules who want to temporarily enable
Secure Messaging and disable it when they have finished.
* 040-sm-hooks: here the SM support is linked to the rest of OpenSC.
We define a sc_sm_context structure, used in the card driver's data
record and currently featuring only one record, the integer use_sm. We
also add three operations to the sc_card_operations structure:
sm_send_transform, sm_receive_transform and sm_free_data, with the
meaning explained before. They do not take the encryption/signature
methods and the key as arguments, since that should be taken care of
directly by the card driver.
Then, do_single_transmit (in apdu.c) is modified. If the card-
>sm_ctx.use_sm flag is active, and the card has the needed operation,
then the SM transformation is invoked, and the transformed APDU is
transmitted to the reader driver in lieu of the original one. The
reverse is done at the end. Throughout the function, error returns
have been replaced with "goto out", so that the sm_free_data cleanup
can be performed in any case.
Lastly, SC_ERROR_SM_AUTHENTICATION and SC_ERROR_SM_DECRYPTION have
been added to the errors list.
* 050-pkcs15-smflag-and-signdecrypt: We cannot choose to always use
SM. In particular, the Italian CNS/CIE cards may desire SM only for
some objects, and not for others; only PINs and private keys seem
protected.
This patch adds the NEEDS_SM flag for the PINs and for private keys
access; when an operation is to be performed on the objects that have
the NEEDS_
