Using OpenSSL ENGINE to get Certificate from Smartcard

The OpenSSL ENGINE facilities had ENGINE_load_private_key,
and ENGINE_load_public_key, but do not have ENGINE_load_certificate.

When the ENGINE is used by an application, such as the
Heimdal PKINIT code to use a smartcard to get a Kerberos
ticket the application does not have easy access to the
certificate stored on the smartcard.

The Heimdal code needs the certificate, as well as the key.
Currently the certificate must be loaded off the card
in a separate step, then passed in as a file.

Is there any chance that:

  (1) OpenSSL would implement ENGINE_load_certificate

  (2) OpenSC would use it in their sslengine/hw_pkcs11.c

  (3) Heimdal would use it to load the certificate from the
      smartcard?

Even if (1) is not done,  It looks possible to use the
ENGINE_ctrl to do this if OpenSC would add a routine to
access the certificate and the Heimdal code would call it.

I am in the process of getting Heimdal on Linux to use OpenSC
to access a GemSAFE card, which was initialized for use
for Windows login to za domain.

So far its working, but the above is a problem as the

Re: Using OpenSSL ENGINE to get Certificate from Smartcard

In message <424D7361.7060803 <at> anl.gov> on Fri, 01 Apr 2005 10:14:25 -0600, "Douglas E. Engert"
<deengert <at> anl.gov> said:

deengert> The OpenSSL ENGINE facilities had ENGINE_load_private_key,
deengert> and ENGINE_load_public_key, but do not have ENGINE_load_certificate.
deengert> 
deengert> When the ENGINE is used by an application, such as the
deengert> Heimdal PKINIT code to use a smartcard to get a Kerberos
deengert> ticket the application does not have easy access to the
deengert> certificate stored on the smartcard.

In 0.9.8-dev, there's a potentially better mechanism that I started a
while ago (more than a year), called a STORE, which also comes with
ENGINE support.  However, because of lack of funding, I haven't found
the time to finish up (it's no small project).  I hope to get the
opportunity to feel financially safe enough to be able to finish that
module.  It would make it possible to retrieve (or retreive a handle
to) quite a number of different types of data from any store, smart
cards, SQLite databasees, LDAP repositories and whatnot.

I could add ENGINE_load_certificate(), but that would (hopefully) just
be a temporary solution before the grander solution (yes, I'm boasting
it ) is firmly in place.

deengert> The Heimdal code needs the certificate, as well as the key.
deengert> Currently the certificate must be loaded off the card
deengert> in a separate step, then passed in as a file.

Hmm, I imagine that ENGINE_load_certificate() would still be a
separate step.  I hope that's not a problem...

Re: Using OpenSSL ENGINE to get Certificate from Smartcard

Richard Levitte - VMS Whacker wrote:

> In message <424D7361.7060803 <at> anl.gov> on Fri, 01 Apr 2005 10:14:25 -0600, "Douglas E. Engert"
<deengert <at> anl.gov> said:
> 
> deengert> The OpenSSL ENGINE facilities had ENGINE_load_private_key,
> deengert> and ENGINE_load_public_key, but do not have ENGINE_load_certificate.
> deengert> 
> deengert> When the ENGINE is used by an application, such as the
> deengert> Heimdal PKINIT code to use a smartcard to get a Kerberos
> deengert> ticket the application does not have easy access to the
> deengert> certificate stored on the smartcard.
> 
> In 0.9.8-dev, there's a potentially better mechanism that I started a
> while ago (more than a year), called a STORE, which also comes with
> ENGINE support.  However, because of lack of funding, I haven't found
> the time to finish up (it's no small project).  I hope to get the
> opportunity to feel financially safe enough to be able to finish that
> module.  It would make it possible to retrieve (or retreive a handle
> to) quite a number of different types of data from any store, smart
> cards, SQLite databasees, LDAP repositories and whatnot.
> 
> I could add ENGINE_load_certificate(), but that would (hopefully) just
> be a temporary solution before the grander solution (yes, I'm boasting
> it ) is firmly in place.

STORE sound interesting.

> 

[openssl.org #1031]

gcc-4 miscompiles inline assembly bn/asm/x86_64-gcc.c so that the
functions bn_add_words and bn_sub_words are broken and segfault.

This applies only to the stable branch as in the devel branch there is
added initialization of the ret and i variables. However the
initialization is unnecessary instead the code should be modified this way:

 <at>  <at>  -164,7 +186,7  <at>  <at> 
        "       leaq    1(%2),%2        \n"
        "       loop    1b              \n"
        "       sbbq    %0,%0           \n"
-               : "+a"(ret),"+c"(n),"+r"(i)
+               : "=&a"(ret),"+c"(n),"=&r"(i)
                : "r"(rp),"r"(ap),"r"(bp)
                : "cc"
        );
 <at>  <at>  -187,7 +209,7  <at>  <at> 
        "       leaq    1(%2),%2        \n"
        "       loop    1b              \n"
        "       sbbq    %0,%0           \n"
-               : "+a"(ret),"+c"(n),"+r"(i)
+               : "=&a"(ret),"+c"(n),"=&r"(i)
                : "r"(rp),"r"(ap),"r"(bp)
                : "cc"
        );
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Re: Re: Using OpenSSL ENGINE to get Certificate from Smartcard

On Fri, 2005-04-01 at 11:05 -0600, Douglas E. Engert wrote:
> The overhead I am seeing is having to basicly "open" the card twice
> with two seperate programs, pkcs15-tool and kinit. In my case the
> pkcs15 emulation code has to test the card, and read the certificate
> twice. This extra overhead may be 5 to 20 seconds, which adds a lot to login.
> Other cards may have different overhead.

IIRC loading a cert from a card plus doing a rsa 2048 bit signature
including all overhead for pkcs#15 structure: on a cryptoflex 32k
in an egate usb token: total time 1 second or less.

so some cards are fast, and the usb token helps a lot, too.
but many people seem to use last generation cards (i.e. rsa 1024 bit
only, no integratet usb support, ...)

Andreas

--

-- 
---------------------[ Ciphire Signature ]----------------------
From: aj <at> dungeon.inka.de signed email body (612 characters)
Date: on 02 April 2005 at 00:39:17 UTC
To:   deengert <at> anl.gov, openssl-dev <at> openssl.org, opensc-devel <at> opensc.org, heimdal-discuss <at> sics.se
----------------------------------------------------------------
: Ciphire has secured this email against identity theft.
: Free download at www.ciphire.com. The garbled lines
: below are the sender's verifiable digital signature.
----------------------------------------------------------------
00fAAAAAEAAAC16U1CZAIAABADAAIAAgACACBQ2JmUgw78JvBqhaOBPOsMFbVDS6
UaQIxcChG5IhzQhgEA0eMp7V0xI9MrMhC47uaTDnnuTnqi6z9oLEuev70rCXvO2b
rbyyUHpsi9/nYDXjVtB+WmL1ea3UeYChbZGOZqSg==

[openssl.org #1032] Unreachable codes in OpenSSL 0.9.7f

I have attached the list unreachable codes present in OpenSSL 0.9.7f.

Thanks,
Prakash
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

[openssl.org #1033] BUG REPORT : Unreachable code in OpenSSL 0.9.7f

Hello All,

                   I  find some unreachable codes in OpenSSL 0.9.7f .  Their details are as follows

Operating System : HPUX
OpenSSL Version : 0.9.7f

1. File : pk7_lib.c
    Line: 187
    break;
    p7->d.signed_and_enveloped->enc_data->content_type   =OBJ_nid2obj(NID_pkcs7_data);
    break;

2. File : evp_enc.c
    Line : 250
    default:
    return 0;
    break;

3. File  : evp_pkey.c
    Line : 209
    EVP_PKEY_free(pkey);
    return NULL;
    break;

4. File: evp_pkey.c
    Line: 291
    p8->broken = PKCS8_OK;
    return p8;

[openssl.org #1031]

Good catch. I think +r was favored over =&r for a reason [like bug in
initial gcc port, note that the code was written prior Opteron was
released], but I've tested now =&r with gcc 3.2 and it's treated
correctly. So I throw it in and syncronize HEAD and 0.9.7-stable. Case
is dismissed. A.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Re: Compilation problem with OpenSSL-0.9.7f on Win32/NASM

> NASM gives me some errors on compiling crypto\rc4\asm\r4_win32.asm:
> 
> .\crypto\rc4\asm\r4_win32.asm:30: operation size not specified
> .\crypto\rc4\asm\r4_win32.asm:265: operation size not specified
> .\crypto\rc4\asm\r4_win32.asm:267: operation size not specified
> .\crypto\rc4\asm\r4_win32.asm:271: operation size not specified
> NMAKE : fatal error U1077: 'nasmw' : Rueckgabe-Code '0x1'
> Stop.
> 
> The build runs fine if I use r4_win32.asm from OpenSSL-0.9.7e. I'm using 
> NASM version 0.98
> Is this my problem, NASM's problem or OpenSSL's problem?

Was fixed another day, grab recent 0.9.7-stable snapshot at 
ftp://ftp.openssl.org/snapshot. A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

How good a random source is Crypto API?