Cardos sign modifes

Some time ago I tests Cardos SC_CARD_TYPE_CARDOS_M4_3, with
atr:
3b:f2:18:00:02:c1:0a:31:fe:58:c8:08:74

Sign fails on final transmit of sign adpu. I analyzed adpu
winscard.dll log of 
SmartTrustPersonal, which CSP sign correctly. 
And found that it use other way of sign throw adpu: 00 2A 80
86 ...

So I modify OpenSc, and now it sign well.

1. Add new type: SC_CARD_TYPE_CARDOS_M4_3B

2. In static struct sc_atr_table cardos_atrs[] init as:
//Old:
        {
"3b:f2:18:00:02:c1:0a:31:fe:58:c8:08:74", NULL,
NULL,            
SC_CARD_TYPE_CARDOS_M4_3, 0, NULL },
//Modified:
	{ "3b:f2:18:00:02:c1:0a:31:fe:58:c8:08:74", NULL,
NULL, 
SC_CARD_TYPE_CARDOS_M4_3B, 0, NULL },
/////////

3. In do_compute_signature modifies: 
//Old:
       sc_format_apdu(card, &apdu, SC_APDU_CASE_4, 0x2A,
0x9E, 0x9A);
//Modified:
	if(card->type == SC_CARD_TYPE_CARDOS_M4_3B)
		sc_format_apdu(card, &apdu, SC_APDU_CASE_4B, 0x2A,
0x80, 0x86);
	else 
		sc_format_apdu(card, &apdu, SC_APDU_CASE_4, 0x2A,
0x9E, 0x9A);
////////


4. Add constants:

//Modified:
#define SC_APDU_CASE_4B			0x34
#define SC_APDU_B			0x20
#define SC_APDU_CASE_4B_EXT		SC_APDU_CASE_4_SHORT |
SC_APDU_EXT | 
SC_APDU_B
/////////

5.  In static size_t sc_apdu_get_length(const sc_apdu_t
*apdu, unsigned int 
proto) add:

//Modified: 
	case SC_APDU_CASE_4B_EXT:	
		ret += apdu->lc + (proto == SC_PROTO_T0 ? 1 : 6);
		break;
/////////

6. In static int sc_apdu2bytes(sc_context_t *ctx, const
sc_apdu_t *apdu,
	unsigned int proto, u8 *out, size_t outlen) add:

//Modified:
	case SC_APDU_CASE_4B_EXT:
		if (proto == SC_PROTO_T0) {
			/* again a T0 extended case 4 APDU looks just
			* like a short APDU, the additional data is
			* transferred using ENVELOPE and GET RESPONSE */
			*p++ = (u8)apdu->lc;
			memcpy(p, apdu->data, apdu->lc);
			p += apdu->lc & 0xff;
		} else {
			*p++ = (u8)0x00;
			*p++ = (u8)0x01;
			*p++ = (u8)(apdu->lc >> 8);
			*p++ = (u8)apdu->lc;
			memcpy(p, apdu->data, apdu->lc);
			p += apdu->lc;
			/* only 2 bytes are use to specify the length of the
			* expected data */
			*p++ = (u8)(apdu->le >> 8);
			*p++ = (u8)apdu->le;
		}
		break;
//////
 

7. In static void sc_detect_apdu_cse(const sc_card_t *card,
sc_apdu_t *apdu):

	if ((apdu->le > 256 || (apdu->lc > 255
&& (apdu->flags & 
SC_APDU_FLAGS_CHAINING) == 0)) &&
			(card->caps & SC_CARD_CAP_APDU_EXT) != 0){
			btype |= SC_APDU_EXT;
//Modified:
			if(apdu->cse == SC_APDU_CASE_4B) btype |= SC_APDU_B;
/////////
		}


This example of my winscard.dll adpu log: 

...

 transmitted:
 00 A4 08 00 02 50 15
 received:
 90 00

 transmitted:
 00 A4 08 00 06 50 15 50 72 4B 01
 received:
 90 00

 transmitted:
 00 22 01 B6 03 83 01 01
 received:
 90 00

 transmitted:
 00 2A 80 86 00 01 01 00 00 01 FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF
  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF
  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF
  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF
  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF
  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF
  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF
  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF
  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF 00 30 20 30 0C
  06 08 2A 86 48 86 F7 0D 02 05 05 00 04 10 F4 89 AD 25 62
36 F3 79 0D B9 AC C6
  C4 11 75 13 01 00
 received:
 12 F3 25 DB 23 4F BE B5 D7 9E 44 85 9E C6 40 56 DD DE E6 85
FD 44 F1 2C 80 DD
  EE 37 EE 62 22 23 3B 4D 53 03 79 9B F7 7F B8 CD C2 21 94
20 12 F0 B9 F2 82 10
  58 47 82 5A 45 0D 36 0C 49 EC E5 E7 8C 1C CB 83 9C 14 33
41 6D 6D 19 89 79 A3
  72 89 6F 50 A4 79 A6 7D DE F9 C8 32 C5 74 FF F4 C3 E4 D3
EB 28 84 D7 5C A2 54
  EF 22 3B 18 9D 43 01 AB D7 AE 85 AD C6 87 BC 0D FD 88 8F
F6 A1 99 F9 3C 3A 7A
  94 FB F1 3B FC 64 67 7E BE D1 3D C6 AE 03 F6 F7 2B 6E 0B
8D 8E ED 12 BF 51 65
  73 B7 BF A0 55 5E EE 23 B7 8F FE EE 70 EC 40 8D B8 51 A2
78 1A C6 96 72 20 B6
  19 8F 0E 85 A2 BC 42 CA A1 2C 31 93 19 92 F1 3D B8 7B ED
2E 0A C4 C0 05 42 A7
  8F 54 9F DE 18 63 E4 99 D1 F0 45 AE C9 72 BA 41 CD 5D 7A
52 39 94 D6 3D F1 21
  4A 4D 8A 4D DB FF B3 09 9F 76 FF 69 FE A0 77 AC 79 C5 19
F3 98 4C 90 00

_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

hi dmitry,

any chance you can send a unified diff ("svn diff"
or "diff -u" format) with 
these changes? that would be great.

if not I will try to apply them manually later.

thanks, Andreas
_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

> any chance you can send a unified diff ("svn
diff" or "diff -u" format) with 
> these changes? that would be great.

I did't send, next time will use diff. 


_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

Dmitry wrote:
> Some time ago I tests Cardos SC_CARD_TYPE_CARDOS_M4_3,
with atr:
> 3b:f2:18:00:02:c1:0a:31:fe:58:c8:08:74
> 
> Sign fails on final transmit of sign adpu. I analyzed
adpu winscard.dll log of 
> SmartTrustPersonal, which CSP sign correctly. 
> And found that it use other way of sign throw adpu: 00
2A 80 86 ...
> 
> So I modify OpenSc, and now it sign well.
> 
> 1. Add new type: SC_CARD_TYPE_CARDOS_M4_3B
> 
> 2. In static struct sc_atr_table cardos_atrs[] init
as:
> //Old:
>         {
"3b:f2:18:00:02:c1:0a:31:fe:58:c8:08:74", NULL,
NULL,            
> SC_CARD_TYPE_CARDOS_M4_3, 0, NULL },
> //Modified:
> 	{ "3b:f2:18:00:02:c1:0a:31:fe:58:c8:08:74",
NULL, NULL, 
> SC_CARD_TYPE_CARDOS_M4_3B, 0, NULL },
> /////////
> 
> 3. In do_compute_signature modifies: 
> //Old:
>        sc_format_apdu(card, &apdu, SC_APDU_CASE_4,
0x2A, 0x9E, 0x9A);
> //Modified:
> 	if(card->type == SC_CARD_TYPE_CARDOS_M4_3B)
> 		sc_format_apdu(card, &apdu, SC_APDU_CASE_4B,
0x2A, 0x80, 0x86);
> 	else 
> 		sc_format_apdu(card, &apdu, SC_APDU_CASE_4, 0x2A,
0x9E, 0x9A);

no, that's wrong and would have the "small"
side-effect that
cardos v4.3b cards with the opensc profile won't work
anymore.
The problem you have is not a cardos v4.3b problem but a
problem of the profile used (hipath most likely in your
case)
and a "limitation" of cardos. A feature of cardos
is that you
can't sign and decrypt with the same key so in case you
need
a multiple purpose key, for example a authentication key,
you
need to choose either a decryption or signing key and for
example sign with the decipher operation.

The APDU used for the signature generation in your case is
the PSO Decipher APDU as the hipath profile uses the
decryption
operation for signing (well at least in some cases). As
opensc uses
signing key for signature generation (IMHO not totally
unreasonable)
your patch would make these keys unusable.

IMHO the right way to fix this would be to tell the profile
layer to use the decryption operation for signing and not
to
modify the card driver.

> ////////
> 
> 
> 4. Add constants:
> 
> //Modified:
> #define SC_APDU_CASE_4B			0x34
> #define SC_APDU_B			0x20
> #define SC_APDU_CASE_4B_EXT		SC_APDU_CASE_4_SHORT |
SC_APDU_EXT | 
> SC_APDU_B

sorry but I fail to see why this change should be necessary

Cheers,
Nils
_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

Nils Larsch <nlarsch <at> gmx.net> writes:

> IMHO the right way to fix this would be to tell the
profile
> layer to use the decryption operation for signing and
not to
> modify the card driver.
> 
Thanks,

So, I need just test if card is cardos, certificate support
encryption and use 
C_DecryptInit/C_Decrypt instead of C_SignInit/C_Sign ?




_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

On Wednesday 18 July 2007 22:27:06 Nils Larsch wrote:
> IMHO the right way to fix this would be to tell the
profile
> layer to use the decryption operation for signing and
not to
> modify the card driver.

I don't know about the profile layer, so I implemented a
crude
hack, which is not too bad I hope and fixes the problem -
both pkcs15-crypt 
and pkcs11-tool now work for me. The change is commited to
trunk already,

http://www.opensc-project.or
g/opensc/changeset?new=trunk%403223&old=trunk%403222


I added a pkcs15_card flag "sign_with_decrypt"
which looks the right thing to 
me. if that flag is set sc_pkcs15_compute_signature either
calls 
sc_pkcs15_decrypt directly, or adds padding first and then
does so.

the crude hack is in pkcs15.c / sc_pkcs15_bind_internal: at
the end I simply
check for strings ("cardos" and
"Siemens") and if so set the flag. if you know
of a nicer way, please let me know. but for now it works.

Dmitry: can you try this? you would need to checkout svn
trunk and compile
it yourself. it works for me (pkcs15-crypt and pkcs11-tool
on a siemens 
initialized card).

Regards, Andreas
_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

Andreas Jellinghaus <aj <at> dungeon.inka.de>
writes:

> 
> Dmitry: can you try this? you would need to checkout
svn trunk and compile
> it yourself. it works for me (pkcs15-crypt and
pkcs11-tool on a siemens 
> initialized card).
> 

All right, Sign and Verify is working correctly. 

Only little problem with definition of local variable for C
- style code 
(compiler error), "tmplen" must be defined before
any function callings.



_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

On Friday 20 July 2007 16:29:44 Dmitry Zhigulin wrote:
> Andreas Jellinghaus <aj <at>
dungeon.inka.de> writes:
> > Dmitry: can you try this? you would need to
checkout svn trunk and
> > compile it yourself. it works for me (pkcs15-crypt
and pkcs11-tool on a
> > siemens initialized card).
>
> All right, Sign and Verify is working correctly.
>
> Only little problem with definition of local variable
for C - style code
> (compiler error), "tmplen" must be defined
before any function callings.

d'oh. thanks, fixed.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

Andreas Jellinghaus wrote:
> On Wednesday 18 July 2007 22:27:06 Nils Larsch wrote:
>> IMHO the right way to fix this would be to tell the
profile
>> layer to use the decryption operation for signing
and not to
>> modify the card driver.
> 
> I don't know about the profile layer, so I implemented
a crude
> hack, which is not too bad I hope and fixes the problem
- both pkcs15-crypt 
> and pkcs11-tool now work for me. The change is commited
to trunk already,
> 
> http://www.opensc-project.or
g/opensc/changeset?new=trunk%403223&old=trunk%403222

> 
> I added a pkcs15_card flag
"sign_with_decrypt" which looks the right thing to

> me. if that flag is set sc_pkcs15_compute_signature
either calls 
> sc_pkcs15_decrypt directly, or adds padding first and
then does so.
> 
> the crude hack is in pkcs15.c /
sc_pkcs15_bind_internal: at the end I simply
> check for strings ("cardos" and
"Siemens") and if so set the flag. if you know
> of a nicer way, please let me know. but for now it
works.

well, this could cause problems with the non-rep. key on
a signature card as in this case PSO compute signature is
afaik really used for the signature computation. The
"right"
way afaik is to correctly parse the tokenInfo file as this
file contains the information which mechanism a key
supports.

Nils
_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel