Re: [opensc-devel] card driver wrapper
> On Mar 20, 2010, at 21:11 , Alejandro Vargas wrote: > > Hello. I an trying to get working a binary card driver for a different > > version. > > > > The driver is for the spanish DNI and it is distributed as a binary > > file, then I cannot re-compile it. Then I think I could build a dummy > > card driver that only loads the binary shared object and wraps the > > functions. My problem is I don't know enough about the working of > > opensc. Is there something like a sample skeleton of a card driver or > > a document on how-to create one? I need to know what are the names of > > the functions that must be imported from the shared object, etc. > It has come to our attention that the Spanish DNI card software for Mac OS X > is using OpenSC not via a loadable card driver module > but with direct merging/linking. Which means there must be published source > somewhere. > Maybe you can help us find the source instead (or help communicating with the > agency distributing the software if the source is not published) There is an interesting document about reverse engineer of proprietary libopensc-dnie.so library at: http://espana.barrapunto.com/es/10/03/20/2251222.shtml The full pdf is at: http://blog.48bits.com/wp-content/uploads/2010/03/articulo.pdf (in spanish, sorry) There is also several people working in create a full source free driver for spanish eDNI card. In the meanwhile, I've developed a wrapper to create a fake function sc_driver_version() to tell opensc that proprietary library module version is ok. It's a dirty trick, but works. I've sent it to Alejandro in a separate mail The free opensc spanish eDNI driver is still a political battle... but we are near to bypass politics :-b BTW: I'm not feel comfortable with patching ctx.c to allow bypass of checking module version: The intend is force developers to release free drivers, or duplicate efforts to compile and recompile again on every OpenSC version for every Linux distribution, not to make proprietary driver developers life easy ;-) Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Published sources for Spanish DNIe opensc module
Finally, here it is: http://www.dnie.es/descargas/codigo_fuente.html According to: http://www.kriptopolis.org/disponibles-fuentes-pkcs11 Seems that code doesn't include component private key to establish secure channel, but I thing that it can be found in other software (java/windows) provided by Spanish DGP A real and long awaited good news Start studying... Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Preliminar analisys of published DNIe code
In Spanish, sorry :-( http://www.kriptopolis.org/disponibles-fuentes-pkcs11#comment-56793 In this article I've done a preliminar analisys of provided source code for Spanish DNIe OpenSC driver http://www.dnie.es/descargas/codigo_fuente.html In a nutshell: won't run without additional work - Need to provide some glue bits to allow use "autotools" - Some data have been "stripped": Certificates an keys to hanldle secure channel. Fortunately I show an alternate way to retrieve it and complete the source code - Uses an obsolete API for pinentry, libassuan and glib that makes it non-compilable Anyway, I've got to re-create a compiling environment and try to get a .so library. Somethings still fails (need to patch code to conform modern OpenSC and external libraries), but I think that we can get it running without extra DNI'e people help. About Licenses... see the code and make your own opinion. DNIe was a case of clear LGPL Violation. In strict sense still does, but now we have enought information to get a full free driver Perhaps you could find interesitng data compression and secure channel codebits Still working :-) Juan Antonio___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Good news from Spanish DNIe code
As you can see at Kriptopolis web site http://www.kriptopolis.org/disponibles-fuentes-pkcs11 A lot of job has been done !in just 2 days! At this moment we have two independent working developments from DGP provided code. So we can confirm that code is valid and works fine Next comes: - Getting rpm and deb packages - Get permission from Spanish Mint staff to include reverse-engineered discovered keys into published code ( by reading of kriptópolis article, you can find the way we discovered and extracted them, but due to current laws we cannot make public without permission ) Oficial files: http://www.dnie.es/descargas/codigo_fuente.html My (little) contribution http://www.megaupload.com/?d=M7PQTLC0 Includes glue bits, and a fake "keys.inc" file ( only CVC certificates are valid, ifd_keys are just fakes ) We've asked DGP for permission. In the meanwhile, you can study code and decide about how to integrate with OpenSC (or leave it as a dynload module) Still working. Cheers Juan Antonio___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Changes on Spanish DNIe licensing
Spanish Direccion General de la Policía has released a new version of their DNIe opensc module... under GPLv3+ license http://www.dnie.es/descargas/codigo_fuente.html That makes several interesting (and problematic) issues: As LGPL states, LGPL code can be promoted to GPL, but the reverse is not true. This means that OpenSC group cannot integrate spanish bits in their code as LGPL. The only way to work is keeping it as a separate loadable module The key codes used to open secure channel still remains unpublished. Some people here at Spain has developed a script to extract keys from older proprietary module and inject it into source code at compile time. So we can create source packages that automagically create binaries with "on-the-fly" generated keys... and publish this source code as GPL. But unsure of legal status of resulting binaries Not sure about legal implications of this sort of "compile-time extracting of unpublished private keys". ( I thing ndiswrapper and linux-dvb people "suffers" from similar problems ) BTW, in the process of evaluating code we have detected some issues about Firefox interaction: Authentication works fine, but signing fails in several Linux distributions As you can see at [1] seems that an undesired old friend reapeared: problems with pinentry, libassuan and pthreads [1] http://www.kriptopolis.org/disponibles-fuentes-pkcs11#comment-56829 So what comes next? - Trying to convince DGP to re-release their code as LGPL - Decide how to handle with private and non-published keys in source code. Alternatively try to get permission from DGP to publis our reverse-engineered keys - Integrate or not in opensc project keeping it as separate dynloadable module - Study problems with signing with firefox-3.x We are unsure about the best way to walk Juan Antonio___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Changes on Spanish DNIe licensing
Mensaje original De: mar...@paljak.pri.ee Fecha: 24/06/2010 10:27 Para: "Juan Antonio Martinez" CC: "Alejandro Vargas", "opensc-devel@lists.opensc-project.org devel", "Malcolm Bain" Asunto: Re: [opensc-devel] Changes on Spanish DNIe licensing [] > > As Direccion General de la Policia has released the code as > > GPL, we never can integrate it (static compile) into OpenSC. > > (LGPL can be promoted to GPL. The reverse isn't true). So > > DNI'e must be built as dynloaded module regardless keys handling > > > > It's a license nightmare: my feeling is that DGP has chosen > > GPL to ensure that all derived code will be easily auditable > What about asking them if this is their intent? We've sent several emails asking for: - Permission for publishing private keys - Policy for code approval - Legal issues on several ways to extract&insert keys into compiled binaries - Change license from GPL to LGPL or allow dual licensing - Centralized source code repository (at OpenSC , DGP, or wherever ) - How to handle linux distribution packages No response (yet) > There is one thing how they want to release the code As no response from DGP, we only can elucubrate: on several forums people talks about a sort of DGP's Source Code Approval Office: developers send their code to DGP, and if is approved, key bits are added and source code signed But, it's just an elucubration... > there's another aspect how it looks from prior infringement aspect (which is > pretty obvious now). Yes: - First one: two years of binary code infringing LGPL - Then two weeks of source code without any license - Legal status of private keys. As not published under GPL, local law applies: we cannot publish them, nor publishing scripts to extract. We only can describe the way to obtain... Stupid an incongruent laws... Im unsure about what OpenSC should do. My feeling is not to include any dnie bits neither in OpenSC tree nor a separate GPL module subtree until legal issues get clear But in the meanwhile, several repositories have started to work with published code. I really dislike this situation. Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] OpenSC-0.12 and Spanish DNIe
hi folks! We have tried to compile, install and get running OpenSC 0.12 with Spanish DNIe code. Status: compile,installs, but fails to run trying to stablish secure channel. Too many changes in debug code, sc_xxx structs, API changes... and not sure about correctness of some patches I've done You can see the discussion (and Martin's suggestions) at Kriptopolis site: http://www.kriptopolis.org/opensc-dnie-linux I've sent patches to Martin. Not sure about the best way to continue integration+debugging until Legal issues get clarified Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC-0.12 and Spanish DNIe
> CIE does not use "Secure Channel" implementation by means of secure > messaging, at least not for normal use of the card (which carries only > Authentication Certificates and not Non-Repudiation, so it is not used > to create legally binding Electronic Signatures). > The version in trunk is covering only that use of the card (https client > auth for instance), and in fact Emanuele took away SM implementation >that Viktor Tarasov is implementing in a general way. > I'm very curious about SM in DNIe , is it used in normal operations by > the card holder (passing PIN, PKCS1 encryption) ? Yes. > In that case, SM uses symmetric cryptograpy? > And how SM static key > distribution problem was solved? Well, there are two ways: - For normal operations , a public/private key pair is stored in the library file. It's stupid, I agree. Moreover, the Spanish DGP (DNIe issuer) wants to keep keys secret... but everyone knows them and there are several programs to extract keys from binary files - Some special operations (i.e. change pin) requires a SSL connection to DGP to get encrypted apdu comands to open special channel with the card. these operations are not supported by dnie opensc code. AFAIK these methods are standard and defined in several documents (no links now, sorry) So yes, as the italian case SM keys "are embedded in the middleware" Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] OpenSC-0.12.0 and DNIe: more logs
Martin: here comes another (more verbose) 0.12.0-svn log from other system and reader ( towitoko-openct serial reader +plus openct-pcsc bridge ) In this case SM channel is created fine, but seems that reader gets into an unstable state and card_transmit_apdu() returns continuous fails I'll check several readers / reader_driver combination to see how logs differs Juan Antonio opensc_0.12.0-svn_dnie.log Description: Binary data ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] OpenSC-0.12.0 and Spanish DNIe
Sorry for this horrible translation but no time for goodness... http://www.kriptopolis.org/opensc-dnie-linux#comment-58005 --- The good news: Using github Martin's repository, whit recent changes, and providing correct SM keys: git clone git://github.com/martinpaljak/OpenSC.git -b dnie cd OpenSC ./bootstrap; configure; make; sudo make install After compiling as usual, we can get this output in Fedora 13: [janto...@router ~]$ opensc-tool -i opensc 0.12.0-svn [gcc 4.4.4 20100630 (Red Hat 4.4.4-10)] Enabled features: zlib readline iconv openssl pcsc(libpcsclite.so.1) [janto...@router ~]$ pkcs15-tool -c Using reader with a card: C3PO LTC31 (1000) 00 00 X.509 Certificate [CertAutenticacion] Flags : 3 Authority: no Path : 3f0060817004 ID : 4138363639413238303730354638453230303930353235313033353232 X.509 Certificate [CertFirmaDigital] Flags : 3 Authority: no Path : 3f0060817005 ID : 4638363639413238303730354638453230303930353235313033353232 X.509 Certificate [CertCAIntermediaDGP] Flags : 2 Authority: no Path : 3f0060617006 ID : 5338363639413238303730354638453230303930353235313033353232 Encoded serial: 02 10 38346ABA656B04B944057F34347BE9AE This version does not use dynload capabilities. dnie is compiled into libopensc, so no need to change opensc.conf. Just compile and install The bad news: When enabling opensc-pkcs11 in firefox. the program needs too many time to start. when going to DGP web page for DNI verification, ask for pin but hangs till message: "sec_error_pkcs11_general_error" appears. Hung is so big that i need to unplug-plug card reader and restart pcscd The regular news: Apparently opensc-pkcs11 seems to work fine. The culprit is (as usual) Firefox: [janto...@router ~]$ pkcs11-tool -L Available slots: Slot 4294967295 Virtual hotplug slot (empty) Slot 1 C3PO LTC31 (1000) 00 00 token label: DNI electrónico (PIN1) token manuf: DGP-FNMT token model: PKCS#15 token flags: rng, login required, PIN initialized, token initialized serial num : 8669A280705F8E Slot 2 C3PO LTC31 (1000) 00 00 (empty) Slot 3 C3PO LTC31 (1000) 00 00 (empty) Slot 4 C3PO LTC31 (1000) 00 00 (empty) [janto...@router ~]$ pkcs11-tool --slot 1 -p MyPasswd -O Certificate Object, type = X.509 cert label: CertCAIntermediaDGP ID: 5338363639413238303730354638453230303930353235313033353232 Public Key Object; RSA 2048 bits label: CertCAIntermediaDGP ID: 5338363639413238303730354638453230303930353235313033353232 Usage: encrypt, verify So thanks to Martin we have got a great progress, but there are still a lot of work... ---___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Rv: OpenSC-0.12.0 and Spanish DNIe
> The bad news: > When enabling opensc-pkcs11 in firefox. the program needs too many time > to start. when going to DGP web page for DNI verification, ask for pin > but hangs till message: "sec_error_pkcs11_general_error" appears. > Hung is so big that i need to unplug-plug card reader and restart pcscd I've checked this behaviour in the same computer and three different card readers: ( Dell Studio 17, Fedora 13 fully updated, opensc-dnie from Martin's github ) - Towitoko (serial) card reader + openct. No work at all (neither firefox nor opensc commandline tools) - Omnikey cardman 4321 (ExpressCard): Authentication works, Signature fails (same as old OpenSC-0.11.x dnie version) - LTC31v2: (USB) shows the behaviour described in last post It's strange: Last two readers are standard CCID ones, and should show same behaviour. In fact Omnikey uses USB connections from ExpressCard slot.. OpenSC comand line apps seems to work DGP DNI test page: http://www.dnielectronico.es/como_utilizar_el_dnie/verificar.html ¿Any idea? I'll try to send logs asap. Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Rv: OpenSC-0.12.0 and Spanish DNIe
Mensaje original > De: alejandro@gmail.com > Fecha: 12/09/2010 12:09 > Para: > Asunto: Re: [opensc-devel] Rv: OpenSC-0.12.0 and Spanish DNIe > 2010/9/10 jons...@terra.es : > > I've checked this behaviour in the same computer and three different card > > readers: > > ( Dell Studio 17, Fedora 13 fully updated, opensc-dnie from Martin's github > > ) > > > > - Towitoko (serial) card reader + openct. No work at all (neither firefox > > nor opensc commandline tools) > > - Omnikey cardman 4321 (ExpressCard): Authentication works, Signature fails > > (same as old OpenSC-0.11.x dnie version) > > - LTC31v2: (USB) shows the behaviour described in last post > > > > It's strange: Last two readers are standard CCID ones, and should show same > > behaviour. In fact Omnikey uses USB connections > > from ExpressCard slot.. Dammit! I've tried to update my LTC31 card reader, by mean of instructions at http://www.c3po.es/pv_ltc31.html#version_firmware_ltc31 And at the end I've finished with the reader's firmware updated... but with my DNIe card broken (ATR ending with 65 81 - Card Memory faillure ) So my DNIe no longer works. Sorry Martin, I need to go to a police office to get my DNIe working back again. So cannot send logs :-( > > > > OpenSC comand line apps seems to work > > DGP DNI test page: > > http://www.dnielectronico.es/como_utilizar_el_dnie/verificar.html > You could check openoffice documment signing. With opensc-0.11.13 I > compiled the free drivers and signing with openoffice worked OK but > firefox returned an ssl error. ¿Are you sure? ... OpenOffice uses same mechanism and routines than FF to handle certificates. Anyway, I cannot continue testing until I go to a police office to re-initialize my DNIe card ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] How to notify an invalidated card?
Perhaps anyone can help me: Now that my DNIe has died [1] I'm trying to get dni code to be aware of this situation. ¿What's the standard way to tell libopensc that a card has been invalidated?, that is: the card is recognized, but cannot operate with it because manipulation detected, too many pin entry errors, or so Not sure on other cards, but DNIe mark this situation by mean of change on ATR status code from 03 90 00 to 0F 65 81 (Memory error). Not sure what to do if detected this situation: - The actual code: do not recognize the card as to be handled by the module - Recognize the card, but return error (¿What is the proper error code?) on any requested operation A good task to code until going to police office to re-enable my card :-) [1]http://www.opensc-project.org/pipermail/opensc-devel/2010-September/014866.html Juan Antonio___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] How to notify an invalidated card?
[...]
> > Not sure on other cards, but DNIe mark this situation by mean of
> > change on ATR status code from 03 90 00 to
> > 0F 65 81 (Memory error). Not sure what to do if detected this
> > situation:
> 1. When data structures of your card are still readable, then match on
> both ATRs. And fail gracefully on pin verification and privileged
> operations.
> 2. When your card doesn't provide any data, then not recognising it
> should be fine. Or handle it like a card in manufacturing state.
Adding invalidated DNIe's ATR to ATR List, some commands still are available:
card_select_file() seems to work... but card fails on stablishing SM. at
card_get_serialnr()
Attached comes ATR patch and resulting log to "pkcs15-tool -c" command
So In your opinion when should invalidated DNIe report error, and which error
code?
Actually card code returns SC_ERROR_INTERNAL.
(NOTE: Remember that this is not an official nor officially supported work:
Still waiting for Spanish autorities
to get support and permission to integrate DNIe into mainstream and resolve
LGPL/GPL conflict on published code )
Juan Antonio
src/libopensc/dnie/base_card.c
index 5e84cd3..c2430bb 100644
@@ -48,7 +48,16 @@ static struct sc_atr_table card_atrs[] = {
SC_CARD_TYPE_DNIE,
0,
NULL
- }
+ },
+ { // card invalidated
+"3B:7F:00:00:00:00:6A:44:4E:49:65:00:00:00:00:00:00:0F:65:81",
+"FF:FF:00:FF:FF:FF:FF:FF:FF:FF:FF:00:00:00:00:00:00:FF:FF:FF",
+CARD_CHIP_NAME,
+SC_CARD_TYPE_DNIE,
+0,
+NULL
+ },
+ { NULL, NULL, NULL, 0, 0, NULL }
};
static struct sc_card_operations card_ops;
damaged_dnie.log
Description: Binary data
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] How to notify an invalidated card?
[...]. > Supposed that the attached log file is complete, then the card fails on > receiving the first APDU. In this case the card provides only it's ATR > and nothing more. This makes it less useful and thus I would prefer to > ignore such a card. You're right. after some test I conclude that card allways answer 6D 00 (unsupported command) to every valid apdu sent So I'll send a patch to match DNIe, but fail on card_init() Thanks for your help Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Spanish DNIe: published Develpers Tech Reference
A very good news: At Spanish DNIe Site [1] guys from TechOffice [2] have published the Developers reference guide for the DNIe. Contains Documentation !And SM keys! enought to create an independent development of DNIe pkcs#11 module Documentation is distributed by mean a sort of Apple/Android Individual Developer license. No License (yet) for Groups nor Companies. But terms of license allows -almost free- redistribution of documentation and code. [3] Actual DNIe [4] published code is under GPL Terms and cannot be used freely in OpenSC. Moreover: recent changes on OpenSC-0.12 libopensc makes it near unusability. The document is already in the web [5] accessible to anyone without signing DGP contract So IMO is time to get the Document and start working in an independent development of DNIe OpenSC module. We have de docs, we have the code, we have the SM keys, we are longing to write code. Need a previous legal study about using published docs in a distributed group -non personal- development, but there is allways the chance to "extract" conflictive info from other sources A real good news Juan Antonio [1] http://www.dnielectronico.es/ [2] http://www.dnielectronico.es/seccion_integradores/index.html [3] http://www.dnielectronico.es/seccion_integradores/cdc.pdf [4] http://www.dnielectronico.es/descargas/codigo_fuente_pkcs11/src.zip [5] https://www.tractis.com/ManualComandosDNIe ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] About "user consent"
Working with Spanish DNIe code, I've received some feedback [1] from Dirección
General
de la Policía about removal of "user consent" code on signature process
Afaik this theme has been discussed at OpenSC [2]. As a result, user consent
code
was removed from OpenSC. Same was for opensc-signer module
But here comes a problem: Spanish authorities certification rules requires that
every
signing procedure must be notified to the user by mean the middleware,
regardless
the behaviour of main application. Removal of User Consent (as Martin did in
github [3])
lies into an un-certificable code
[1] http://www.kriptopolis.org/opensc-cenatic#comment-58751
[2] http://www.opensc-project.org/opensc/ticket/232
[3] http://github.com/martinpaljak/OpenSC/tree/dnie
So, as a Solomon's solution, based on OpenSC-0.11.14's "dialog.c", I've written
a new
code (attached) that makes user consent configurable (at this moment for DNIe
code)
What's your feelings on this?
Thanks in advance
Juan Antonio/*
* User consent function
* Based on dialog.c from opensc-0.11.14
* And original code from DGP's DNIe module
*/
/*
* IMPORTANT NOTICE:
* This code may don't work on:
* - Headless systems
* - Sites without pinentry / libassuan properly installed
* So to handle this, we provide several flags at /etc/opensc.conf:
*
* module dnie {
* # Enable/Disable user consent on signing (default: enable)
* user_consent_enabled = true;
* # Program to be used for ask confirmation (default: pinentry)
* user_consent_app = /usr/bin/pinentry;
* }
* .
* NOTICE that disable User Consent may result on unnoticed signing if
* used on unsecure environments and/or with bad designed/uncertified apps
*
*/
#include
#include
#include
#include "../opensc.h"
#include "../errors.h"
#include "../log.h"
#ifndef PIN_ENTRY
#define PIN_ENTRY "/usr/bin/pinentry"
#endif
static char *user_consent_app=PIN_ENTRY;
static int user_consent_enabled=1; /* default true */
/**
* Parse configuration file to extract user consent flags
*/
static int get_user_consent_env(sc_context_t *ctx) {
int i;
scconf_block **blocks, *blk;
for (i = 0; ctx->conf_blocks[i]; i++) {
blocks = scconf_find_blocks(ctx->conf, ctx->conf_blocks[i],"card_driver","dnie");
if (!blocks) continue;
blk=blocks[0];
free(blocks);
if (blk==NULL) continue;
user_consent_app = scconf_get_str(blk,"user_consent_app",PIN_ENTRY);
user_consent_enabled = scconf_get_bool(blk,"user_consent_enabled",1);
}
return SC_SUCCESS;
}
int ask_user_consent(sc_card_t *card) {
int res;
const char *argv[3];
ASSUAN_CONTEXT ctx;
if ( (card!=NULL) && (card->ctx!=NULL)) return SC_ERROR_INVALID_ARGUMENTS;
get_user_consent_env(card->ctx);
argv[0]=user_consent_app;
argv[1]=NULL;
argv[2]=NULL;
res = assuan_pipe_connect(&ctx,user_consent_app,argv,0);
if (res!=0) {
sc_debug(card->ctx,SC_LOG_DEBUG_NORMAL,"Can't connect to the User Consent module: %s\n",assuan_strerror((AssuanError) res));
res=SC_ERROR_INVALID_ARGUMENTS; /* invalid or not available pinentry */
goto exit;
}
res = assuan_transact(
ctx,
"SETDESC Está a punto de realizar una firma electrónica\n con su clave de FIRMA del DNI electrónico.\n\n¿Desea permitir esta operación?",
NULL, NULL, NULL, NULL, NULL, NULL);
if (res!=0) {
sc_debug(card->ctx,SC_LOG_DEBUG_NORMAL,"SETDESC: %s\n", assuan_strerror((AssuanError) res));
res=SC_ERROR_CARD_CMD_FAILED; /* perhaps should use a better errcode */
goto exit;
}
res = assuan_transact(ctx,"CONFIRM",NULL,NULL,NULL,NULL,NULL,NULL);
if (res == ASSUAN_Canceled) {
sc_debug(card->ctx,SC_LOG_DEBUG_VERBOSE,"Sign cancelled by user");
res= SC_ERROR_NOT_ALLOWED;
goto exit;
}
if (res) {
sc_debug(card->ctx,SC_LOG_DEBUG_NORMAL,"SETERROR: %s\n", assuan_strerror((AssuanError) res));
res=SC_ERROR_SECURITY_STATUS_NOT_SATISFIED;
} else {
res=SC_SUCCESS;
}
exit:
assuan_disconnect(ctx);
return res;
}
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Rv: About "user consent"
Oops!! there are some obvious errors in attached code ( "module" instead of "card_driver", card context null checkings and so ) But It's just an idea :-) Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] using a secret key
> > Hello Nikos, > > AFAIK only RSA is supported by OpenSC. > Is this a design decision or a limitation of the supported cards? Just natural evolution of OpenSC: first cards only supported RSA See thread at opensc-devel list: http://www.opensc-project.org/pipermail/opensc-devel/2010-October/015099.html Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Secure Messaging and Pinpad support . Is it possible?
Working in OpenDNIe [1] code I've found a problem. How to send a verify() cmd throught Secure Channel when pin is to be keyed by mean of a reader with pinpad. My feeling is that this is not possible: OpenSC handles pinpad at reader level. The only way to insert pin from pinpad into SM is that reader firmware create and handle secure messaging and don't know how to instruct reader -and think that is not possible to get an "universal solution"- to do this task So as a poor solution, Im returning error when SC_PIN_CMD_USE_PINPAD is requested in card_pin_cmd() ¿Any thoughts on this? Thanks in advance BTW: I expect to get LGPL'd driver for Spanish DNIe card complete and ready for integration into OpenSC as my personal Christmas gift :-) Juan Antonio [1] http://opendnie.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] r4904 and OpenSSL-1.0.0b in Fedora 14
In Fedora 14 (that ships OpenSSL-1.0.0b) seems that EC support is not built in OpenSSL package - Making all in tools make[3]: se ingresa al directorio `/home/jantonio/work/dnie/cenatic/opendnie/opensc-dnie/trunk/src/tools' gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src -pthread -fno-strict-aliasing -g -O2 -MT pkcs11-tool.o -MD -MP -MF .deps/pkcs11-tool.Tpo -c -o pkcs11-tool.o pkcs11-tool.c pkcs11-tool.c:27:24: error fatal: openssl/ec.h: No existe el fichero o el directorio compilación terminada --- ¿Any easy way to bypass this issue? Juan Antonio___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Rv: r4904 and OpenSSL-1.0.0b in Fedora 14
More info: Seems that Fedora removes all ECC related issues due to patents problems: https://bugzilla.redhat.com/show_bug.cgi?id=615372 ¿How these problems could affect OpenSC? Perhaps we could do some kind of conditional compilation to take care on this Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r4904 and OpenSSL-1.0.0b in Fedora 14
Mensaje original
De: mar...@paljak.pri.ee
Fecha: 03/12/2010 9:48
Para:
CC:
Asunto: Re: [opensc-devel] r4904 and OpenSSL-1.0.0b in Fedora 14
> OPENSSL_VERSION_NUMBER >= 0x1000L && !defined(OPENSSL_NO_EC) is
> the key,
> Douglas hopefully plans that into the next patch unless you do it before
> (I don't have a Fedora VM available at the moment)
OK :-) attached patch works for me
Juan Antonio
diff -rbuN --exclude=.svn opensc/src/tools/piv-tool.c cenatic/opendnie/opensc-dnie/trunk/src/tools/piv-tool.c
--- opensc/src/tools/piv-tool.c 2010-12-03 10:04:30.0 +0100
+++ cenatic/opendnie/opensc-dnie/trunk/src/tools/piv-tool.c 2010-12-03 10:01:57.0 +0100
@@ -31,7 +31,9 @@
#include
#include
#include
+#ifndef OPENSSL_NO_EC
#include
+#endif
#include
#include
#include
@@ -321,7 +323,9 @@
EVP_PKEY_assign_RSA(evpkey, newkey);
- } else { /* EC key */
+ }
+#ifndef OPENSSL_NO_EC
+else { /* EC key */
int i;
BIGNUM *x;
BIGNUM *y;
@@ -348,6 +352,7 @@
EVP_PKEY_assign_EC_KEY(evpkey, eckey);
}
+#endif
if (bp)
r = i2d_PUBKEY_bio(bp, evpkey);
diff -rbuN --exclude=.svn opensc/src/tools/pkcs11-tool.c cenatic/opendnie/opensc-dnie/trunk/src/tools/pkcs11-tool.c
--- opensc/src/tools/pkcs11-tool.c 2010-12-03 10:04:30.0 +0100
+++ cenatic/opendnie/opensc-dnie/trunk/src/tools/pkcs11-tool.c 2010-12-03 11:23:26.0 +0100
@@ -24,7 +24,9 @@
#include
#include
#include
+#ifndef OPENSSL_NO_EC
#include
+#endif
#include
#include
#endif
@@ -1247,6 +1249,9 @@
* so we will write it for OpenSSL if built with OpenSSL
*/
if (opt_mechanism == CKM_ECDSA) {
+#ifdef OPENSSL_NO_EC
+ util_fatal("OpenSSL ECDSA_SIG: not supported");
+#else
int nLen;
ECDSA_SIG * ecsig = NULL;
unsigned char *p = NULL;
@@ -1264,6 +1269,7 @@
free(p);
ECDSA_SIG_free(ecsig);
+#endif
} else
#endif
r = write(fd, buffer, sig_len);
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r4904 and OpenSSL-1.0.0b in Fedora 14
Mensaje original De: deeng...@anl.gov Fecha: 03/12/2010 16:18 Para: Asunto: Re: [opensc-devel] r4904 and OpenSSL-1.0.0b in Fedora 14 Commited r4906 to test for OPENSSL_NO_EC, and opensslconf.h is included. Please verify id Fedora now compiles. Just a simple patch to get it right: -- Index: src/tools/piv-tool.c === --- src/tools/piv-tool.c(revisión: 4906) +++ src/tools/piv-tool.c(copia de trabajo) @@ -34,7 +34,9 @@ /* Module only built if OPENSSL is enabled */ #include #include +#ifndef OPENSSL_NO_EC #include +#endif #include #include #include @@ -351,7 +353,7 @@ EVP_PKEY_assign_EC_KEY(evpkey, eckey); #else -fprintf(stderr, "This build of OpenSSL does not support EC keys"\n); +fprintf(stderr, "This build of OpenSSL does not support EC keys\n"); r = 1; #endif /* OPENSSL_NO_EC */ -- Thanks for the work Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Fwd: IAS sucks
Mensaje original
De: mar...@martinpaljak.net
Fecha: 24/01/2011 12:46
Para: "OpenSC-devel (opensc-devel)"
Asunto: Re: [opensc-devel] [opensc-commits] Fwd: IAS sucks
[...]
> One of the longstanding problems of OpenSC is lack of documentation, both
> developer
> (source comments, internal architecture, tutorials on how to add new card
> drivers other
> way than copypaste etc) and end-user docs. This is unfortunately quite usual
> for open source projects, especially for niche project that does not attract
> a huge
> crowd of volunteers and where some companies could even sometimes take lack
> of documentation as a competitive edge.
> This is not a trivial thing to fix, especially for source code, which is not
> as "sexy"
> as end-user documentation.
> Not that I would want to suggest a "8 meters requirement" [1], something
> should be done about it.
[...]
I agree:
In the writting of Spanish DNIe LGPL driver I've found so many times that lack
of information.
A simple tutorial for writting card drivers, An overview of what iso7816.c
does, differences
between sc_xxx functions an their counterpart iso_xxx functions,
how sc_transmit_apdu handle 61xx status response,
how an when issue apdu->{resp,resplen,le} and what should be expected
At this moment, I'have cwa14890 Secure Messaging working for DNIe,
but I'm next to !wrap and rewrite! sc_transmit apdu()... because I _really_
doesn't
know the exact way of handling a correct get_response() (required on every SM
apdu message)
cmd when expected data length is not known in advance or when a previous
function is already
waiting for a response in their apdu
So I really (really!) need a documented API and description on what is expected
for each routine
Perhaps not indeed to make a public API ( opensc-devel ), just a short of
"Developer's guide"
[...]
> Overall, the goal would be to increase the effort needed to figure out "how?"
> to code right now (not just write code but do some research and refactoring
> if necessary) and reduce the time needed later to figure out "why?"
> certain source code exists.
[...]
My DNIe code [1] already follows Doxigen conventions. Comments/total line ratio
is greater
than 20%. I'm also writting a development diary[2]... Well, my SVN commit
comments
perhaps should be improved :-)
About rewrittng and commenting... well, revise every files on Opensc may lead
unpractical,
and would be better for us to (re)write wiki documentation.Not sure
Anyway, regardless of mainstream comments in source code, I expect get DNIe
ready
for public test at the end of this month. Frank, Victor, perhaps you can find
usefull to
take a look to cwa14890 SM code
Juan Antonio
[1]
https://forja.cenatic.es/plugins/scmsvn/viewcvs.php/opensc-opendnie/?root=opendnie
[2] https://forja.cenatic.es/developer/diary.php?diary_user=5382
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] DNIe driver: Needs Information on writing pkcs15-xxxx files
Hi All: I've concluded that DNIe card is not so pkcs15 compliant as promissed... I think I need rewriting of several file permissions and paths, as information provided in card pkcs15 structure seems to be wrong or incomplete I've studying the source code of provided drivers, but still unsure on how to process. Is there any kind of information about how to write pkcs15-xxx files? specifically, to specify visibility flags of public keys and rewriting paths in CDF file Thanks in advance Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] DNIe driver: Needs Information on writing pkcs15-xxxx files
> Mensaje original > De: andre.zepeza...@student.uni-halle.de > Fecha: 03/02/2011 13:06 > Para: >CC: > Asunto: Re: [opensc-devel] DNIe driver: Needs Information on writing > pkcs15- files >On Thu, 2011-02-03 at 12:03 +0100, jons...@terra.es wrote: >> Hi All: >> >> I've concluded that DNIe card is not so pkcs15 compliant as >> promissed... >> I think I need rewriting of several file permissions and paths, as >> information >> provided in card pkcs15 structure seems to be wrong or incomplete >> >> I've studying the source code of provided drivers, but still unsure on >> how to process. >> >> Is there any kind of information about how to write pkcs15-xxx files? >> specifically, >> to specify visibility flags of public keys and rewriting paths in CDF >> file >Please send the following dumps: >pkcs15-tool -D >opensc-tool -f >Explain what should be fixed. If there are only minor issues (i.e. some >wrong flags or paths) then you can go with a very lightweight emulator. >I will explain later. Here it comes: Notice that there is an "official DNIe driver" released under GPL license (thus cannot be integrated into OpenSC mainstream), by spanish authorities that (partially) works DNIe contains 5 Certificates: At DF 3F006081 - User certificate for Authentication - User certificate for Signing - CA Certificate for User certificate validation At EF 3F00601F - ICC Certificate to stablish cwa14890 Secure Messaging channel At EF 3F006020 -Intermediate CA Cert for ICC cert validation --- [jantonio@drake libopensc]$ pkcs11-tool --login -O Official DGP's published GPL driver does not require "--login". Using slot 1 with a present token (0x1) Logging in to "DNI electrónico (PIN1)". Please enter User PIN: Private Key Object; RSA label: KprivAutenticacion ID: 4130364236323435383832383133323230313031313131313634303236 Usage: sign warning: PKCS11 function C_GetAttributeValue(MODULUS_BITS) failed: rv = CKR_ATTRIBUTE_TYPE_INVALID (0x12) Public Key Object; RSA 0 bits ^^^ an error: RSA key object should show 2048 bits not zero label: KpuAutenticacion ID: 4130364236323435383832383133323230313031313131313634303236 Usage: verify Certificate Object, type = X.509 cert label: CertAutenticacion ID: 4130364236323435383832383133323230313031313131313634303236 Private Key Object; RSA label: KprivFirmaDigital ID: 4630364236323435383832383133323230313031313131313634303236 Usage: sign warning: PKCS11 function C_GetAttributeValue(MODULUS_BITS) failed: rv = CKR_ATTRIBUTE_TYPE_INVALID (0x12) Public Key Object; RSA 0 bits ^^^ Same error: RSA key object should show 2048 bits not zero label: KpuFirmaDigital ID: 4630364236323435383832383133323230313031313131313634303236 Usage: verify Certificate Object, type = X.509 cert label: CertFirmaDigital ID: 4630364236323435383832383133323230313031313131313634303236 Data object 136525816 label: 'ADMIN_DatosFiliacion' application:'' app_id: -1 flags: modifiable private Data object 136525864 label: 'ADMIN_ImagenFacial' application:'' app_id: -1 flags: modifiable private Data object 136522528 label: 'ADMIN_ImagenFirma' application:'' app_id: -1 flags: modifiable private ^ Notice that ICC Certificate and ICC CA Cert are not shown (it does in Official driver) - [jantonio@drake libopensc]$ pkcs15-tool -D Using reader with a card: OmniKey CardMan 4321 00 00 PKCS#15 Card [DNI electrónico]: Version: 0 Serial number : 06B62458828132 Manufacturer ID: DGP-FNMT Flags : Login required, PRN generation PIN [PIN1] Object Flags : [0x3], private, modifiable ID : 01 Flags : [0x211], case-sensitive, initialized, integrity-protected Length : min_len:4, max_len:16, stored_len:8 Pad char : 0x00 Reference : 1 Type : ascii-numeric Private RSA Key [KprivAutenticacion] Object Flags : [0x3], private, modifiable Usage : [0xC], sign, signRecover Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local ModLength : 2048 Key ref: 1 Native : yes Path : 3f0050153f110101 ^ All the paths shown are wrong: real path is (in this case) 3f003f110101 My feeling is that DNIe doesn't store absolute paths, just re
[opensc-devel] Secure Messaging and concurrent access to card
In the testing process of OpenDNIe I've found a problem related with concurrent access to opensc-pkcs11 library. In short: as DNIe can only handle one SM at a time (no virtual channel support), there is no (known) way to get concurrent pkcs11 access This "feature" makes unusable most of signing applets commonly used in many official sites Afaik opensc-pkcs11 is thread/process aware, and non-sm based cards can successfully handle "n" processes without any problem noticed. but for DNIe, I need some way to "centralize" all SM task in a single process/thread I'm thinking on a sort of "SM daemon" to take care on apdu encoding/decoding What do you feel on this approach? btw, most of cryptoapplet jarfiles I know can handle access to card by mean of CSP, PKCS#11 and NSS interfaces. Can you confirm me that selecting NSS as interface instead pkcs#11 would solve this problem ? Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] How to make proper use of sc_card_cache
Hi all. Trying to optimize DNIe card driver, I'd like to cache current df to avoid extra select_file()'s DNIe card cannot handle select_file(SC_PATH_TYPE_PATH) directly: it has to be splitted into recursive calls to select_file(SC_PATH_TYPE_FILE_ID). Studying other card drivers i figure that the way to do is by mean of sc_card_cache structure, but I've not seen a common way to handle it. Some drivers doesn't make any use, other ones doesn't handle nor current_df neither current_ef, but works with current_path. Also, I've noticed that sc_(un)lock() clears sc_card_cache. Is this correct?. I cannot see the reason on this behaviour Any ideas?. Actually I'm working wiht cache code from card-flex.c, but unsure if there is a better approach for "my" card https://forja.cenatic.es/plugins/scmsvn/viewcvs.php/?root=opendnie BTW: Martin: We are working in a "DNIe hackfest meeting" next month, and would like to invite some people from OpenSC team to come to Spain to get a roadmap for DNIe integration into OpenSC mainstream Juan Antonio___ 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 Sunday, March 27 at 01:42PM, Viktor TARASOV wrote: >> > http://www.opensc-project.org/opensc/wiki/SecureMessaging >> >> I've added my vision onto the SM implementation . >> Still to be finalized the proposal for the SM data types. >> I'll try to look over the prior works to see how their needs can be reflected >> in the common data types. I've tried to write my comments into wiki but seems that my user "jonsito" is not recognized or has an incorrect email address. Please help.. >I think you should call the SM routines in sc_transmit_apdu instead of >in do_single_transmit. The SM APDU is usually longer than the >non-SM APDU. So the secured APDU could extend the readers/cards maximum >APDU length and is subject to splitting via chaining (which is done in >sc_transmit_apdu before do_single_transmit). Sure: in DNIe SM this is the way to work, as DNIe does not use APDU chaining but envelope cmd, as states in iso7816-4 sect 7.6.2 for SM handling >I think I implemented a simpler version of your approach for nPA without >file specific SM and without key sets (all this is entirely handled by >the card driver). What I am missing is a separation of ISO 7816 and the >specific cryptographic layer as stated before [1]. This is what Emanuele >calls a "building block" for reuse with different card drivers [2]. Some comments on Victor's suggestions regarding on DNIe: DNIe doesn't need to stablish SM channel at init, but in the first "secure" operation (usually "verify pin" prior to any pso). But once the SM is stablished cwa-14890 states that SM must be used for every further transaction. A Solomon's solution is to get init() to prepare al SM related data, but relay SM stablishment until really required. Notice that for cwa-14890, external data (Certificates, keys,card serialnr and so) are just required in sm_init(); kenc, kmac and SSC u8 arrays are the only required data for SM session handling once stablished, cwa states that SM channel is to be off on deinit(), reset(), or SM transaction fail (66 88 apdu response). Some glue logic is required to detect SM tx fail and (if needed) reconnect. No specific APDU is provided to disable SM, but reset is suggested 'APDU' Mode is just what I do, so is ok for me :-)... But notice that -at least in cwa-14890- standard every SM transmit _requires_ a get_response() command About 'ACL' mode. Not sure, but perhaps a simple flag "SC_APDU_FLAGS_SM_REQUIRED" would avoid replication on every sc__ function Finally: DNIe doesn't support Logical channel in APDU commands. This means that concurrent access to pkcs11 (ie: an https firefox connection to a page that runs a signing applet) doesn't work I'm writting a "SM apdu server" for DNIe. This splits opensc in a sort of client (libopensc) - server (reader driver at sc_transmit_apdu() call level) system. Not sure on collateral implications, or if there is a better approach to this problem. Perhaps a solution could be create an intermediate "SM reader driver" that catches every sc_transmit_apdu(), handles SM and calls in turn to the "real" reader driver ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eSign/cwa14890-01-2004-Mar.pdf Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Comments on r5273 and r5274
1- An stupid bug in piv-tool.xml: [jantonio@jonsy trunk]$ diff ../../../opensc/doc/tools/piv-tool.xml doc/tools/piv-tool.xml 22c22 < --- > - ( a missing start tag ) 2- Not sure about the usage of card reader "black list" on broken readers: What these black list is intended for? - To enumerate readers that send pin back to host in cleartext - To enumerate readers that incorrectly states that has pinpad support - To ... In my case Spanish C3PO's LTC31 (reported name 'C3PO LTC31 00 00' ) claims for having pinpad support but I'cannot see any pinpad :-) Also notice issues regarding SecureMessaging: http://www.mail-archive.com/opensc-devel@lists.opensc-project.org/msg07069.html Juan Antonio___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Comments on r5273 and r5274
2011/3/30 jons...@terra.es : > > In my case Spanish C3PO's LTC31 (reported name 'C3PO LTC31 00 00' ) claims > > for > > having pinpad support but I'cannot see any pinpad :-) > > Can you send me the output.txt file for this reader as documented at [1]? > I have two LTC31 [2, 3] in my list but none of them claim to be a pinpad. Mmmmh... perhaps you're right: Some time ago I had some problems with pinpad flag when testing DNIe and had to disable it card-dnie.c::dnie_init(). So time to revise. Anyway, I send you an attachment with my report.txt The reader is a LTC31v2 with updated firmware Juan Antonio idVendor: 0x0783 iManufacturer: C3PO idProduct: 0x0006 iProduct: USB SMART CARD READER bcdDevice: 0.50 (firmware release?) bLength: 9 bDescriptorType: 4 bInterfaceNumber: 0 bAlternateSetting: 0 bNumEndpoints: 3 bulk-IN, bulk-OUT and Interrupt-IN bInterfaceClass: 0x0B [Chip Card Interface Device Class (CCID)] bInterfaceSubClass: 0 bInterfaceProtocol: 0 bulk transfer, optional interrupt-IN (CCID) iInterface: ? CCID Class Descriptor bLength: 0x36 bDescriptorType: 0x21 bcdCCID: 1.00 bMaxSlotIndex: 0x00 bVoltageSupport: 0x01 5.0V dwProtocols: 0x 0x0003 T=0 T=1 dwDefaultClock: 4.000 MHz dwMaximumClock: 8.000 MHz bNumClockSupported: 0 (will use whatever is returned) IFD does not support GET CLOCK FREQUENCIES request: Success dwDataRate: 9600 bps dwMaxDataRate: 230400 bps bNumDataRatesSupported: 0 (will use whatever is returned) IFD does not support GET_DATA_RATES request: Success dwMaxIFSD: 254 dwSynchProtocols: 0x0007 2-wire protocol 3-wire protocol I2C protocol dwMechanical: 0x No special characteristics dwFeatures: 0x000100BA 02 Automatic parameter configuration based on ATR data 08 Automatic ICC voltage selection 10 Automatic ICC clock frequency change according to parameters 20 Automatic baud rate change according to frequency and Fi, Di params 80 Automatic PPS made by the CCID 01 TPDU level exchange dwMaxCCIDMessageLength: 271 bytes bClassGetResponse: 0x00 bClassEnveloppe: 0x00 wLcdLayout: 0x bPINSupport: 0x00 bMaxCCIDBusySlots: 1 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Compiling for windows in Fedora 14
Some notices on compile for windows under Fedora 14
Using r5283 and install instructions from wiki:
http://www.opensc-project.org/opensc/wiki/WindowsInstaller
1- In file win32/installer_from_build.sh
Fedora mingw compiler uses a different name:
-
# Ubuntu 10.10 (as wiki states)
# (cd ${build_dir}; CHOST=i586-mingw32msvc CBUILD=i686-pc-linux-gnu ./build)
# Fedora 14
(cd ${build_dir}; CHOST=i686-pc-mingw32 CBUILD=i686-pc-linux-gnu ./build)
¿Is there any standard way to take care on mingw naming issues?
2- In building process an strip error found:
-
i686-pc-mingw32-strip: unable to copy file
'/home/jantonio/work/dnie/opendnie/opensc-opendnie/trunk/win32/build/image/opensc/lib/engines/gosteay32.dll';
reason: Permission denied
Seems that openssl lib files are created with 0555 permissions, so cannot be
stripped. ¿is this normal?
Continue testing
Juan Antonio
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Rv: Compiling for windows in Fedora 14
> Mensaje original
>De: jons...@terra.es
> Fecha: 31/03/2011 13:15
>Para:
>Asunto: [opensc-devel] Compiling for windows in Fedora 14
>
>Some notices on compile for windows under Fedora 14
Sorry: I forgot last notice:
My Fedora installation has default language set to "ES", so wine looks
for iscc.exe at
${HOME}/.wine/drive_c/Archivos de programa/Inno Setup 5/ISCC.exe
instead of
${HOME}/.wine/drive_c/Program Files/Inno Setup 5/ISCC.exe
So need some way to take care on i18n issues for wine
Juan Antonio
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Re Rv: Compiling for windows in Fedora 14
>
>Hello,
>On Mar 31, 2011, at 14:22 , jons...@terra.es wrote:
>> Sorry: I forgot last notice:
>> My Fedora installation has default language set to "ES", so wine looks
>> for iscc.exe at
>>
>> ${HOME}/.wine/drive_c/Archivos de programa/Inno Setup 5/ISCC.exe
>> instead of
>> ${HOME}/.wine/drive_c/Program Files/Inno Setup 5/ISCC.exe
>>
>> So need some way to take care on i18n issues for wine
>If you find a very simple method (maybe "wine --print-programs-dir" or
>something) then it could be changed.
>But the de facto language for international open source is English.
Something like this could help:
# Build installer
programFiles=`grep ProgramFilesDir ${HOME}/.wine/system.reg | sed -e
's/^.*="\(.*\)"/\1/g'`
wine "$programFiles\Inno Setup 5\ISCC.exe" win32/OpenSc.iss
..
Juan Antonio
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] CSP-Pkcs11 howto?
(Apologizes if this is not the proper list to ask for ) What's the current status of CSP - support for OpenSC? OpenSC-pkcs11 works fine for me in windows, but I'd like to use not only pkcs11based tools but csp based apps too I've tried some binaries from OpenSC links [1] without success Any (working / updated ) link or information on pkcs11 based CSP's? Seems that scb is outdated. is it correct? Thanks in advance [1] http://www.opensc-project.org/opensc/wiki/WindowsCSP [2] http://www.opensc-project.org/opensc/wiki/OperatingSystems ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] RV: CSP-Pkcs11 howto?
BTW: what's the current state of cardmod? Is it usable? Any instructions? Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] windows installer: handle Fedora/Ubuntu proper mingw
A little patch to "installer_from_build.sh" script to use correct mingw prefix
on win32 builds
Requires "lsb-core" package Ubuntu- or "redhat_lsb" -redhat/fedora-
-
# use mingw to generate binaries
+DistID=`lsb_release -is`
+case $DistID in
+Fedora ) prefix=i686-pc-mingw32 ;;
+* ) prefix=i586-mingw32msv ;;
+esac
+(cd ${build_dir}; CHOST=${prefix} CBUILD=i686-pc-linux-gnu ./build)
-(cd ${build_dir}; CHOST=i586-mingw32msvc CBUILD=i686-pc-linux-gnu ./build)
# Copy files
---
Cheers
Juan Antonio___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] make maintainer-clean patch
Seems that "make maintainer-clean" forgets to delete "trunk/MacOSX/Makefile.in" file This patch does the work: --- ../trunk/MacOSX/Makefile.am2011-04-21 11:33:09.0 +0200 +++ mine/MacOSX/Makefile.am2011-04-25 11:26:32.0 +0200 @@ -1,3 +1,4 @@ +MAINTAINERCLEANFILES = $(srcdir)/Makefile.in EXTRA_DIST = build build-package.in libtool-bundle opensc-uninstall \ 10.5/resources \ 10.5/resources/background.jpg \ Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenDNIe project is now ready for public test
(oops: forgot to CC to list :-) Mensaje original De: jons...@terra.es Fecha: 25/04/2011 14:30 Para: Asunto: Re: [opensc-devel] OpenDNIe project is now ready for public test > About "User Consent" AKA "popping up notice windows about what the > user is about to do" as well as ticket #232 [1]. > I still believe that it is mostly politics to delegate responsibility > :) What it tries to "protect" from or inform the user of, the chosen > technical mechanism is IMHO far from being enough. From purity vs > practicality point of view, in the context of PKCS#11 applications for > example, it would be the responsibility of the application to display > application specific notices if the signature to be given is in fact > given with an application that is meant for giving digital binding > signatures. For example, NSS thinks that non-repudiation keys are OK > for web authentication, giving a popup about legally binding > signatures if the end result is a SSL session is not appropriate. You're right, but in the Real World very few apps take care on these items as they should For instance: OpenOffice doesn't ask user approval for signing documents; ever worse: doesn't check "key usage" flag on the selected certificate. In the testing process of DNIe I've found too many apps that silently sign documents... All these "funny" apps made me change my opinion about "user consent" (Notice that OpenDNIe does not ask user pin: only uses popup windows to ask confirmation for the signature procedure, just before sending proper APDU) > Nevertheless, the feature has usage scenarios (like fulfilling > questionable policies). Some things to consider: > * Where to implement it. Current implementation in a card driver is > not the right place maybe, if the driver is used from a Tokend, a > PKCS#11 or minidriver, GUI availability can vary. Thus it should be > possible to control it based on an "interface driver" (PKCS#11 vs > minidriver for eample) rather than card driver. So your proposal is create a separate file to store all user consent operations, and call them when required. I agree: that's the way to work > * What to show to the user (and how). This includes i18n. i18n is not only related to user consent: any xxx-tool are also candidates. Afaik Belpic card has also same i18n issues (btw no i18n ticket found) > * Integration with the rest of the platform. I really like the > concept of "trusted windows" or "stuff that is controlled by the > system and harder to fake for malware" like the Windows UAC. OS X and > Windows have mechanisms for this, although I'm not sure if/how > difficult it is to jack into them. On Linux, maybe GnomeKeyring can > provide some help (for Gnome desktops)? If the feature is to be > enabled, it would probably be used in a desktop environment, so tuning > for a smooth and integrated experience would be of great value. A problem arises in Linux: dependancy with external libraries at compile time. I've solved it in linux by using pinentry as an external tool, without libassuan, and declare in config file how to process and wich program to use > I can figure out at least these different popups: > 1 - "Legal warning" + plaintext PIN entry > 2 - "Legal warning" + "Please enter PIN on pinpad" > 3 - "Please enter PIN on pinpad" message > 4 - Faked secure PIN entry in PKCS#11 driver and "Please enter PIN" > window for plaintext PIN > 5 - "Please re-enter PIN" window, as described in #232 > 6 - "Plaintext PIN entry forbidden by policy" 7 - "You'are about to emit a digital signature. Please confirm operation" Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] pkcs15-tool --read-public-keys
> Mensaje original > De: mar...@martinpaljak.net > Fecha: 27/04/2011 7:21 > Para: "Juan Antonio Martinez" > CC: > Asunto: Re: [opensc-devel] pkcs15-tool --read-public-keys [] > > Ok, I finally did it. pkcs15-tool -D no longer shows "public keys" > > on my DNIe card > > > > pkcs15-tool trace says that no public key found, so looks for > > keys in cert, find it, tries to read certificate... > > ... And dies with "security status not satisfied": > > > > Remember that DNIe requires pin to read certificates, > > but sc_pkcs15_read_certificate() seems that does not take > > care on it and dies on -1211 error... > pkcs15-tool recently got --verify-pin option to verify a PIN before anything > else. That might work for pkcs15-tool, if documented. Yeap!. you're right: with "--verify-pin" now works fine. Attached comes a patch for pkcs15-tool.xml documentation :-) > You could re-use PIN cache inside sc_pkcs15_read_certificate, much like > everything else in libopensc/pkcs15-sec.c does as well > (the actual usefulness of it might be questionable for *certificates* though, > they are usually read only once) > I'm not sure if there is a silver bullet solution, eventually calling > application must consider the requirement > a PIN code before being able to read certificates. And ideally provide a > tunable for this (like what NSS does > but applications don't support very well) > But as I understand, *listing* certificates (not reading them, but becoming > aware of their existence) works without PIN codes? Yes, sure. Any pkcs15 structure parsing does not require pin; just read_binary() on certificares (and of course any sec operation) BTW: collateral effect is that pin_cmd starts secure message channel. Once SM is established every apdu must be securized > This should probably help a little (compared to a situation where even > becoming aware of the existence of certificates requires a PIN code) [...] > When binding to the card, looping all certificates and creating public key > objects, then filtering for duplicates in the pubkey > file and having fake pubkey objects after binding to the card already (so > that other pieces like pkcs15-tool or PKCS#11 > module would not have to do that separately) Glubs, I could try, but seems too heavy for me :-) > But yes, that would probably not solve the PIN issue. Sure not... but with your suggestions and my last patches for me is enought :-) BTW: I'm not sure of OpenSSH pkcs11 way to retrieve keys: afaik extract it from certificates, but not sure if also handles keys found in pukdf ¿anyone knows? Thanks for the support. Cheers Juan Antonio Index: doc/tools/pkcs15-tool.xml === --- doc/tools/pkcs15-tool.xml (revisión: 5399) +++ doc/tools/pkcs15-tool.xml (copia de trabajo) @@ -99,6 +99,11 @@ + --verify-pin + Verify PIN after card binding and before issuing any command (without 'auth-id' the first non-SO, non-Unblock PIN will be verified) + + + --list-keys, -k Lists all private keys stored on the token. General information about each private key is listed (eg. key name, id and ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] RV: SM and remote data svn commits
Hi, Viktor: > [...] > > > Provide functions for start/stop/testAndSet SM > > New card member 'SM context' will be added to sc_card structure. > > There will be the placeholder for the SM related card/exrternal-module > > handlers, session data, etc. > > Every one will find the possibility to implement what he looks for > > -- integrated or external SM handlers, 'transmit' or/and 'acl' modes, CWA > > or GP protocols, ... > OK. I missunderstood meaning of SM context :-( I've been studing opensc-sm branch to port sm_context_t and related structures to OpenDNIe... Fortunately for me changes in dnie code are minimal, but... - As SM branch had no changes in several months, I'm unsure about if I can use the code (at least data structures) as "definitive", or should I wait for new commits into opensc > > > BTW: there are some SM related APDU responses that aren't included > > > in iso7816.c file. I can provide you proper patch to add them. > > Yes, some code are missing, your proper patch are heartily welcome . > Attached comes my proposed patch. > - Add sw12 response 6688 "Cryptographic checksum invalid" > - Defines some SC_ERROR_SM_xx error codes > - Changes sw12 6987 and 6988 error codes to SM related ones Any news?. According to roadmap [1] SM is next step... :-). In the meanwhile, I've been working a lot in commenting, cleanup & test OpenDNIe. You'll like it :-) Regards. Juan Antonio [1] http://www.opensc-project.org/opensc/roadmap ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] RV: SM and remote data svn commits
> Mensaje original > De: viktor.tara...@gmail.com > Fecha: 31/05/2011 14:45 > Para: > CC: > Asunto: Re: [opensc-devel] RV: SM and remote data svn commits > > Hello Juan Antonio, [...] > Le 31/05/2011 13:02, jons...@terra.es a écrit : > > Hi, Viktor: > > Any news?. According to roadmap [1] SM is next step... :-). > > Sorry, OpenSC is essential, but not my principal activity . > Will try to do my best . OK. I'll be patient :-). Anyway there is a lot of doc & testing work pending [1]. In the meanwhile, I'll remove wrap/unwrap code and rewrite it in something similar your sm_context approach Kind Regards Juan Antonio [1] http://opendnie.cenatic.es/wiki/index.php/Documentacion ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] About ticket #232 (portable gui)
(Happy Holidays, Martin :-) I'm working around ticket #232[1], (GUI related functions), but need a consensus about what is exactly needed [2] - At least two functions are required * Enter pin * Confirm Operation * ¿Any other? - Should I take care on i18n?. Notice that other parts on OpenSC (eg eidenv-tool) need to be i18n-aware - What about external dependencies? * On windows seems not to be any problem, Just call native GUI functions * On MacOSX needs extra "-framework Carbon" compilation CFLAGS [3], to select proper framework to access graphics * On Linux, needs further study if finally we choose gnome-keyring as GUI interface. (At this moment I'm used a fork+pipe connection to pinentry, but needs to be revisited ) In my git branch [3] you can see a preliminary implementation for "Confirm operation". But prior to start writting more general code I'll agree some feedbacks on how to proceed [1] http://www.opensc-project.org/opensc/ticket/232 [2] http://www.opensc-project.org/pipermail/opensc-devel/2011-April/016465.html [3] https://github.com/jonsito/OpenSC/commit/00fb0a849c44d540ee36812c1ca9ec39caa1de59 Juan Antonio___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] About ticket #232 (portable gui)
> Mensaje original > De: ludovic.rouss...@gmail.com > Fecha: 24/06/2011 14:13 > Para: >Asunto: Re: [opensc-devel] About ticket #232 (portable gui) > >Hello, > >2011/6/24 jons...@terra.es : >> I'm working around ticket #232[1], (GUI related functions), but need a >> consensus about >> what is exactly needed [2] >> >> - At least two functions are required >> * Enter pin >> * Confirm Operation >> * ¿Any other? >Please do not code GUI inside OpenSC. I propose to use pinentry [1] instead. >A GUI application is already available for GTK+, KDE and Mac OS X. I >don't know about Windows. The idea - according to roadmap[1], #232 and my talks with Martin is to provide a separate library for GUI related functions. This library should be OS independent (by showing an unified interface for every OS) and use the less external libraries as possible >We already discussed about using pinentry. Is there a problem with >this solution? Well, in theory Windows (at least Vista and W7) and MacOS native functions provide a securized channel between GUI and opensc, and do not rely on external libraries There is no such functionality for Linux. Certainly there is support for Pinentry in Win and Mac, but these implementations requires extra work for getting and installing external libraries. IMO, it's better to use native calls when possible So the problem comes in Linux. - OpenDNIe uses pinentry in a fork+pipe scheme. This avoid need to link OpenSC against libassuan and libgpg-error - There are several pinentry variants. So need to create an extra configuration menu in /etc/opensc.conf to get proper path to desired pinentry app, and extra logic to detect presence and validity of configuration data Martin proposed me to study the use of gnome-keyring to handle UI in Linux That's is the current state. I'm next to start a branch to create separate GUI routines and need to get a clear idea on what is needed and how to implement. Juan Antonio [1] http://www.opensc-project.org/opensc/roadmap BTW: Martin: I'have my (new) MacMini ready to be used on Autobuilds for Mac... waiting instructions :-) ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
