RE: CardRSADecrypt succeeds but CryptDecrypt fails with NTE_BAD_DA

Thanks for your reply Mounir,
but I followed your tips and it's still not working.
I'm going to get a little more specific with the parameters I get as input
and the results I am obtaining to see if you can help me out.

This is the original data that I have to cypher and decypher:
"OpenSSL - Frequently Asked Questions Which is the current version of
OpenSSL? Where is the documentation? How can I contact the OpenSSL
developers? Do I " ...and it goes on, but I wont post the whole buffer.

When the CardRSADecrypt function of my card module gets called these are the
input parameters I receive in the CARD_RSA_DECRYPT_INFO structure:
pInfo->dwVersion: 1,
pInfo->bContainerIndex: 00,
pInfo->dwKeyspec: 1,
pInfo->cbData: 128,
pInfo->pbData: af 36 42 fc 64 01 32 fb c4 da 25 e7 95 04 77 de 92 b3 44 89
29 2f 6e 78 32 63 a8 62 d9 7c 5d 34 f3 45 7b 1f 23 48 2d 09 e0 76 10 d4 d9 58
14 94 ff 42 de 62 26 0c 99 44 53 4f 11 0f d4 c5 0a d4 f5 b1 ae ea e8 e9 bf c9
1d 2c 20 54 84 18 69 c6 20 04 eb b7 f3 89 87 7a eb a3 63 cb cf 4f 79 d5 2b cf
3f 0e 65 f8 77 d7 61 23 5e e9 fc 4d fa 18 e4 b4 21 1b a2 38 a0 a0 3b 0c 99 94
75 e4 f8 7c

Inside the function I decrypt the data with the openssl RSA_private_decrypt
function, using the private key that my smartcard holds (because my card is
not a cryptographic one). After I process the input cypher, the prior
structure looks like this:
dwVersion: 1 ,
pInfo->bContainerIndex: 00 ,
pInfo->dwKeySpec: 1 ,
pInfo->cbData: 128 ,
pInfo->pbData: 4f 70 65 6e 53 53 4c 20 20 2d 20 20 46 72 65 71 75 65 6e 74
6c 79 20 41 73 6b 65 64 20 51 75 65 73 74 69 6f 6e 73 20 57 68 69 63 68 20 69
73 20 74 68 65 20 63 75 72 72 65 6e 74 20 76 65 72 73 69 6f 6e 20 6f 66 20 4f
70 65 6e 53 53 4c 3f 20 57 68 65 72 65 20 69 73 20 74 68 65 20 64 6f 63 75 6d
65 6e 74 61 74 69 6f 6e 3f 20 48 6f 77 20 63 61 6e 20 49 38 a0 a0 3b 0c 99 94
75 e4 f8 7c

If I edit the deciphered data (in pInfo->pbData) using an hexadecimal editor
I get the following:
"OpenSSL - Frequently Asked Questions Which is the current version of
OpenSSL? Where is the documentation? How can I"
....and 11 weird characters which I suppose are the padding bytes: 38 a0 a0
3b 0c 99 94 75 e4 f8 7c

That is exactly what my function returns, and I am still getting the ugly
NTE_BAD_DATA error in the CAPI CryptDecrypt function.
Do yo see anything wrong here? I just don't understand what I'm doing wrong.

"Mounir IDRASSI" wrote:

Hi,

In the implementation of CardRSADecrypt , you should only perform a bare
bone RSA private key exponentiation (classically C^D mod N) without trying to
remove any padding from output data. All the padding verification and
removal is done by the MS Base Smart Card CSP.

Cheers,
--
Mounir IDRASSI
IDRIX
http://www.idrix.fr

to reach : mounir_idrix_fr (replace the underscores with the at and dot
characters respectively)


"glosoria" wrote:

Hello everyone,

I'm new to writing a card module and I have some doubts about the
implementation of the CardRSADecrypt function. I don't know if either the
documentation is not complete or if I'm making a mistake.

I came to the point of implementing the CardRSADecrypt function in my card
module, and when I test it, by calling it through the CAPI function
CryptDecrypt, it fails with a NTE_BAD_DATA error (that is CryptDecrypt fails).

CardRSADecrypt finishes well and returns SCARD_S_SUCCESS. But it seems like
CryptDecrypt (or maybe the BaseCSP in between) doesn't like the data that it
is returning.

I print the data that is being returned by CardRSADecrypt and it is fine.
The data is decrypted (in fact the data is the same as originally I ciphered
by using the certificate that is inside the smart card). Maybe I am not
inicialiting the return parameters right:
- Should the returned decrypted data include padding?
- what should pInfo->cbData return? the documentation of the CryptDecrypt
funcion in the MSDN says: "This value must always be the same as the key
modulus". According to that, If I'm using a 1024 bits key, I should return
128bytes, right?
If so, how should I fill that returned data? Because in my test, the length
of the descripted data is 117 bytes. Then, How should I filled the bytes
between 117 and 128, is there any special format? Should I fill them with
'\0' and an pattern saying the length of the zeros? Or should I return the
data in an special TLV format or blob that indicates the lenght of the data
and the padding?

Thanks in advance for your answers,
Best regards,
Gloria.
.

Relevant Pages

  • CardRSADecrypt succeeds but CryptDecrypt fails with NTE_BAD_DATA
    ... documentation is not complete or if I'm making a mistake. ... I came to the point of implementing the CardRSADecrypt function in my card ... CryptDecrypt, it fails with a NTE_BAD_DATA error. ...
    (microsoft.public.platformsdk.security)
  • strange VPN1401 HiFn issue
    ... Not sure if this is a card, FreeBSD, HiFn driver, or MB ... Using openssl on freebsd, ... then generate some traffic across that ssh session, ...
    (freebsd-stable)
  • HIFN/7955 Soekris 1401 openssl problem
    ... crypto accelerator card to work on FreeBSD 4.10. ... 'openssl speed -engine cryptodev' doesnt use the card for any algorithm. ... As far as I understand the hifn driver fully supports ...
    (freebsd-hackers)
  • Re: Q: SCA1000 is which OEMd product?
    ... Scott Howard wrote: ... The card itself is Sun designed, ... achieve, XMLSec from http://www.aleksey.com/xmlsec/, supports OpenSSL as ... Thus I presume the same goes for Sun's SCA branding ...
    (comp.sys.sun.hardware)
  • Re: Q: SCA1000 is which OEMd product?
    ... Scott Howard wrote: ... The card itself is Sun designed, ... achieve, XMLSec from http://www.aleksey.com/xmlsec/, supports OpenSSL as ... Thus I presume the same goes for Sun's SCA branding ...
    (comp.unix.solaris)