On Thu, 2010-10-07 at 16:25 -0500, Douglas E. Engert wrote:
>
> On 10/7/2010 2:30 PM, Andre Zepezauer wrote:
> > On Thu, 2010-10-07 at 09:06 -0500, Douglas E. Engert wrote:
> >>
> >> On 10/6/2010 9:15 PM, Andre Zepezauer wrote:
> >>> On Wed, 2010-10-06 at 23:12 +0300, Martin Paljak wrote:
> >>>> Hello,
> >>>>
> >>>> On Oct 6, 2010, at 7:10 PM, Douglas E. Engert wrote:
> >>>>> PROPOSAL:
> >>>>>
> >>>>> I would like to do the following to cleanup some of the duplication:
> >>>>>
> >>>>> Replace sc_pkcs15_pubkey_from_cert with non OpenSSL code, that would
> >>>>> use the sc_asn1_decode_algorithm_id, and other code from parse_x509_cert
> >>>>> to get the algorithm, its parameter, and the pubkey.
> >>>> OK. This helps with reducing OpenSSL dependancies and reduce duplicated
> >>>> functionality.
> >>>
> >>> Attached is some prototyping stuff related to x509 parsing. Maybe it
> >>> could be helpful. Execute the following command to get the required
> >>> attributes from a certificate:
> >>>
> >>> cat cert.der | tools/cert-tool
> >>
> >> Yes that looks good, but is has to be in the libopensc to support PKCS#11,
> >> and need to replace sc_pkcs15_pubkey_from_cert, and be used by
> >> parse_x509_cert.
> >>
> >> The parse_x509_cert actually get the algorithm and its parameters,
> >> but does not save the parameters, as there is a lot of missing code to
> >> copy the parameters as retrieved in pkcs15-algo.c and reformated into
> >> the union in sc_pkcs15_pubkey.
> >
> > Hello Douglas,
> >
> > you have to deal with sc_pkcs15_pubkey / sc_pkcs15_prkey only when you
> > want to perform cryptographic operations within OpenSC. This shouldn't
> > be required, since private-key operations are done by the card and
> > public ones by the calling application. The calling application can
> > always extract the public key from the certificate and then perform the
> > public key cryptographic operation by itself. The only structure
> > required is sc_pkcs15_cert_info.
> >
> > For private key operations a sc_pkcs15_prkey_info structure with proper
> > values for 'id' and 'subject' should be sufficient. This way, the
> > calling application is able to find the private key corresponding to a
> > certificate. Procedure described in PKCS#11 2.30 section "10.6.3 X.509
> > public key certificate objects".
>
> Well behaved applications may do this, but there may also be some
> that try and get the attributes from a public key, like an ssh
> client that want to use the key pair for example for use with SSH,
> and could care less about the certificate. (I am not defending
> the use of ssh keys, just pointing this out.)
>
> So the more general approach is to have OpenSC get the public key
> from the cert for use with PKCS#11 and that is what is in the code today.
Most ssh clients are able to read public and private keys from two
different locations. Thus reading public keys from disk (as normal) and
offload private key operations to cryptographic devices wouldn't be that
strange.
> OpenSC was targeting PKCS#11 2.20 as far as I know, so would this
> procedure still work with 2.20?
Exactly the same in both versions.
> > The remaining task is to map a private key object (sc_pkcs15_prkey_info)
> > to the APDU parameters P1 (algorithm identifier) and P2 (key reference)
> > when performing GENERAL_AUTHENTICATE. There is a generic solution, which
> > until now is not implemented by OpenSC.
>
> That does sound interesting, if it was implemented.
Data structures are almost complete. Only the attribute
sc_pkcs15_prkey_info.reference is missing. But some additional logic in
pkcs15-sec would be required. It is generic and looks like this:
1 if (prkey.reference != -1) {
2 sc_pkcs15_algorithm_info_t *ai;
3 ai = get_algorithm_info(ti->algorithm_infos, prkey.reference);
4 senv.alg_ref = ai->alg_ref;
5 senv.flags |= SC_SEC_ENV_ALG_REF_PRESENT;
6 }
line 2: that type has also an attribute 'reference' with unique values
line 3: searches though the vector algorithm_infos[] and returns one
with a matching reference
line 4: alg_ref is to be used by the card-driver, when performing
operations with the current prkey but its up to the driver how to use it
It's the task of the emulator to assign meaningful values to
tokeninfo.algorithm_infos. And to reference such an algorithm from
private keys (done on every p15card binding).
Everything else is generic and would even work for native p15cards with
file system. See attachment for output of 'pkcs15-tool -D'.
SupportedAlgorithms is the vector of sc_pkcs15_algorithm_info_t. For a
detailed description of attributes see PKCS#15 "6.9 The cryptographic
token information file, EF(TokenInfo)".
> > This solution would evaluate the
> > TokenInfo.supportedAlgorithms structure. The algRef attributes of this
> > structure would map to P1 (algorithm identifier) and
> > sc_pkcs15_prkey_info.key_reference to P2 (key reference). From
> > pkcs15-sec the set_security_env function of the driver would be called
> > with this two attributes set.
> >
>
> Other cards may have some of the same issues.
>
> > This mapping is possible, when extending sc_pkcs15_prkey_info with the
> > attribute 'reference'. This attribute would reference a record in
> > TokenInfo.supportedAlgorithms where the additional information is
> > stored. Everything is described in PKCS#15 especially "6.1.13 KeyInfo".
> >
>
> For the PIV this sounds circular, as it is not a PKCS#15 card, and
> so all referenced have to be derived from the cert, either internally
> bu OpenSC, or by testing carefully what the calling application is
> asking be done.
The PIV emulator has to initialise the opensc internal vector
algorithm_infos (ti->algorithm_infos) on p15card binding. After binding,
generic logic takes over. Card-piv is still required.
> > The only thing you have to do is, assign proper values to
> > TokenInfo.supportedAlgorithms, assign a matching reference to
> > sc_pkcs15_prkey_info.reference and modify pkcs15-sec in a way, that it
> > passes algRef (P1) from supportedAlgorithms to set_security_env of the
> > driver.
> >
> > Should I explain this workings in more detail? Should I provide an
> > example of the way, the data structures would look for PIV?
> >
> > Kind Regards
> > Andre Zepezauer
> >
> >> The pkcs15-algo.c already knows how to parse parameters for
> >> algorithms, it just did not know how to do EC. The pkcs15-cert.c
> >> parse_x509_cert
> >> would get the parameters but not save then in the sc_pkcs15_pubkey.
> >>
> >> The sc_pkcs15_pubkey_from_cert could call parse_x590_cert, and retried only
> >> the sc_pkcs15_pubkey.
> >>
> >> I have this mostly working, and the proposal I had was to cleanup some
> >> of the code which would also mean changes in other routines where the
> >> sc_pkcs15_cert now has a pointer to an sc_algorithm_id and a pointer to a
> >> sc_pkcs15_pubkey.
> >
> >
> >
>
TokenInfo [PKCS#15]
Version : 0
Serial number : 167bff5671900a1b13
Manufacturer ID : Siemens AG (C)
Label : Andre Zepezauer
Supported algorithms : [reference: algorithm parameters operations oid alg_ref]
1: 0x01 [05 00] -s---d-g 1.2.840.113549.1.1.1 0x0c
2: 0x01 [05 00] -s-----g 1.2.840.113549.1.1.1 0x88
3: 0x01 [05 00] -----d-g 1.2.840.113549.1.1.1 0x08
4: 0x06 [05 00] -s------ 1.2.840.113549.1.1.5 0x88
17: 0x01 [05 00] -s---d-g 1.2.840.113549.1.1.1 0x0a
18: 0x01 [05 00] -s-----g 1.2.840.113549.1.1.1 0x86
19: 0x01 [05 00] -----d-g 1.2.840.113549.1.1.1 0x06
20: 0x06 [05 00] -s------ 1.2.840.113549.1.1.5 0x86
Private RSA Key [Andre Zepezauer]
Object Flags : [0x1], private
Usage : [0x6], decrypt, sign
Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local
ModLength : 2048
Key ref : 1
Native : yes
Path : 3f00501550724b015501
Auth ID : 01
ID : 9e9784812fd09b430445c52cdfca7d6cbe2ce52c
Reference : 17
Private RSA Key [Andre Zepezauer]
Object Flags : [0x1], private
Usage : [0x4], sign
Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local
ModLength : 2048
Key ref : 2
Native : yes
Path : 3f00501550724b025502
Auth ID : 01
ID : 174cbd4f43b47771b0f3762832ecdf666a07a1b9
Reference : 18
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
