On 9/29/2010 5:04 PM, Andre Zepezauer wrote:
> On Wed, 2010-09-29 at 16:25 -0500, Douglas E. Engert wrote:
>>
>> On 9/29/2010 3:05 PM, Andre Zepezauer wrote:
>>> On Wed, 2010-09-29 at 13:35 -0500, Douglas E. Engert wrote:
>>>>
>>>> On 9/29/2010 9:51 AM, Andre Zepezauer wrote:
>>>>> Hello Douglas,
>>>>>
>>>>> in my opinion the usage of OpenSSL in libopensc.so should be removed
>>>>> altogether. If cryptography is needed by some cards (i.e. for
>>>>> ), then this should be done by dedicated
>>>>> tools. CardOS is a good example. It requires encrypted APDU:s for the
>>>>> delete_MF and create_MF commands. This is done by cardos-tool, which has
>>>>> to be executed only before personalisation. Looking at the code of
>>>>> entersafe, gpk and oberthur I came to the conclusion, that a similar
>>>>> approach could work for these drivers too.
>>>>
>>>> I agree. The PIV card only needs 3DES for initialization/personalization
>>>> today. The piv-tool was designed to allow for initializing test cards, with
>>>> the intent that production cards would be issued by card management
>>>> stations
>>>> run by others as the NIST standards only cover a few of the commands needed
>>>> for initialization, leaving the rest up to the card vendors. (i.e. one can
>>>> generate a key ipair on the card, but you can not load a private key on the
>>>> card.) Thus the ordinary user would not require OpenSSL.
>>>>
>>>>>
>>>>> If parsing of certificates is the reason for using OpenSSL, then the
>>>>> missing functionality of pkcs15-cert.c should be determined and
>>>>> corresponding tickets should be created.
>>>>
>>>> What has happened as some card driver authors have found it easier to
>>>> just use OpenSSL, and have added routines like: sc_pkcs15_pubkey_from_cert
>>>> into pkcs11-pubkey.c Because the parse_x509_cert only works with RSA.
>>>>
>>>> But to get this code replaced, will take the will of the community
>>>> to get this done.
>>>
>>> I don't think so, because the function sc_pkcs15_pubkey_from_cert is
>>> called only at pkcs15init/pkcs15-lib.c#L2030
>>>
>>> The same holds for sc_pkcs15_pubkey_from_prvkey, which is called at
>>> pkcs15init/pkcs15-lib.c#L2036 and nowhere else.
>>>
>>> That shows (at least to me), that these two functions belonging to the
>>> tools section of OpenSC and should be placed there.
>>
>> But parse_x509_cert also get the pubkey from a cert. So why are there two
>> routines? Because parse_x509_cert only works with RSA? Where as
>> sc_pkcs15_pubkey_from_cert could easily work with more the RSA.
>>
>> So we have duplicate code, using different methods. We could do a better
>> and implement sc_pkcs15_pubkey_from_cert without OpenSSL, and use it from
>> parse_x509_cert.
>>
>> I am interested in expanding OpenSC to work with EC keys, with at least
>> named-curves. (The OID of the curve is the parameter.) parse_x509_cert does
>> not obtain the algorithm parameters, which for RSA are null, and the
>> pkcs15-piv.c needs to get the public key from the cert in normal use. This
>> will require a modified parse_x509_cert or sc_pkcs15_pubkey_from_cert.
>>
>> (Since the PIV specs for EC only require the use of prime256v1 or secp384r1
>> so I could take a shortcut, and use the size of the point to get the curve,
>> but in the future, other cards may support EC for other curves or even
>> explicit
>> parameters.) All the code for EC is in OpenSSL, making it very tempting
>> to just use OpenSSL.
>>
>> The gostr3410 [1][2] algorithm is also based on EC, but has its own OID
>> {iso(1) member-body(2) ru(643) rans(2) cryptopro(2)} and requires parameters,
>> and it looks like the way it is used does not require parsing the cert to get
>> a public key so has not been added to parse_x509_cert.
>>
>> Much of gost is in OpenSSL too, as a separate engine
>
> Can you point out the place where OpenSSL is called for GOST
> computation. This is of interest, because host-side decryption/signing
> is definitely subject for removal.
No, can't find decryption/signing. But OpenSSL with or without GOST does
allow for software verifying, and includes support for many hashes.
To see what GOST was adding, I made a mod to the card-piv.c copied from
the card-rtecp.c to call _sc_card_add_algorithm with SC_ALGORITHM_GOSTR3410.
With OpenSSL-1.0.0a pkcs11-tool -M shows:
Supported mechanisms:
SHA-1, digest
SHA256, digest
SHA384, digest
SHA512, digest
MD5, digest
RIPEMD160, digest
GOSTR3411, digest
GOSTR3410, keySize={256,256}, sign, verify, unwrap, decrypt
RSA-X-509, keySize={1024,3072}, sign, verify, unwrap, decrypt
RSA-PKCS, keySize={1024,3072}, sign, verify, unwrap, decrypt
SHA1-RSA-PKCS, keySize={1024,3072}, sign, verify
MD5-RSA-PKCS, keySize={1024,3072}, sign, verify
RIPEMD160-RSA-PKCS, keySize={1024,3072}, sign, verify
RSA-PKCS-KEY-PAIR-GEN, keySize={1024,3072}, keypairgen
Without OPenSSL, pkc11-tool -M
Supported mechanisms:
GOSTR3410, keySize={256,256}, sign, unwrap, decrypt
RSA-X-509, keySize={1024,3072}, sign, unwrap, decrypt
RSA-PKCS, keySize={1024,3072}, sign, unwrap, decrypt
Note that verify is not listed without OpenSSL, as the
pkcs11/openssl.c adds the OpenSSL hash and verify functions.
>
>
--
Douglas E. Engert <deeng...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
