signatures using S-Trust smart card

Ullrich Martini mailbox at
Tue Jan 2 20:03:56 CET 2007


I am trying to perform a digital signature with a S-Trust (card issuer
behind some german banks, "Sparkassen") signature card. This is a
qualified signature card according to german signature law. Technically,
it's a SECCOS card from Giesecke & Devrient. The file system complies to
the german ZKA specification which is an evolved version of the "DIN
signature card", which finally should be supported by gpgsm through

I have successfully installed the card reader so that I can issue 
gpgsm --learn-card to read the public certificate from the card.
I also have started gpg-agent as described in the man page.

In order to get the certificate accepted I had to retrieve the S-Trust
certificates from their website and get an intermediate certificate
which is not published on the website from their email support.

So far so good:

ullrich at luna:~$ gpgsm --dump-chain
Serial number: 01D3241394E9BB63609D0A7A934B1E18
       Issuer: CN=S-TRUST Authentication and Encryption Root CA
2005:PN,O=Deutscher Sparkassen Verlag
GmbH,L=Stuttgart,ST=Baden-Wuerttemberg (BW),C=DE
      Subject:,C=DE,,,CN=Dr. Ullrich Martini
          aka: <mailbox at>
      md5_fpr: 5C:AA:EE:84:5B:56:53:A4:ED:AD:86:E6:DC:E9:AE:CE
      keygrip: 864314699D78AB3F134A009BDD3FF4F7F2F86779
    notBefore: 2006-07-08 00:00:00
     notAfter: 2010-12-30 23:59:59
     hashAlgo: 1.2.840.113549.1.1.5 (sha1WithRSAEncryption)
      keyType: 1728 bit RSA
    subjKeyId: 8816E965BDC22D3CF403B9A6ABE096FA538CB2A5
    authKeyId: [none] 0FCA1E5C79E0A2F329B6D285B30B4AB565EC6B52
     keyUsage: digitalSignature keyEncipherment dataEncipherment
  extKeyUsage: clientAuth (suggested)
               emailProtection (suggested)
               ipsecUser (suggested)
  chainLength: not a CA
               issuer: none
     authInfo: (ocsp)
     subjInfo: [none]
         extn: (authorityInfoAccess)  [42 octets]
Certified by
Serial number: 371918E653547C1AB5B8CB595ADB35B7
       Issuer: CN=S-TRUST Authentication and Encryption Root CA
2005:PN,O=Deutscher Sparkassen Verlag
GmbH,L=Stuttgart,ST=Baden-Wuerttemberg (BW),C=DE
      Subject: CN=S-TRUST Authentication and Encryption Root CA
2005:PN,O=Deutscher Sparkassen Verlag
GmbH,L=Stuttgart,ST=Baden-Wuerttemberg (BW),C=DE
      md5_fpr: 04:4B:FD:C9:6C:DA:2A:32:85:7C:59:84:61:46:8A:64
      keygrip: F0608EFE3BF31FA253B87E1B1702BAA8EAE4E654
    notBefore: 2005-06-22 00:00:00
     notAfter: 2030-06-21 23:59:59
     hashAlgo: 1.2.840.113549.1.1.5 (sha1WithRSAEncryption)
      keyType: 2048 bit RSA
    subjKeyId: 0FCA1E5C79E0A2F329B6D285B30B4AB565EC6B52
    authKeyId: [none] 0FCA1E5C79E0A2F329B6D285B30B4AB565EC6B52
     keyUsage: certSign crlSign
  extKeyUsage: [none]
     policies: [none]
  chainLength: 0
        crlDP: [none]
     authInfo: [none]
     subjInfo: [none]

looks good. I configured this key as local-user in gpsm.conf.

However, then:

ullrich at luna:~$ gpgsm -s test.txt > test.sig
gpgsm: can't sign using `3D21BC85EDA74D98F1AC5A71F426771A150F47BD': Kein
geheimer Schlüssel

(the german error message means "no secret key")

Now I'm at loss. Of course, there is no secret key, because it is still
on the card. Looks to ma as if gpgsm is missing the fact that this key
must be used through the card reader.

I checked that that card is still connected. What is wrong here?

many thanks in advance,



my system info:
Debian testing, versions are:
gpgsm          2.0.0-5.2  
gnupg-agent    2.0.0-5.2 
pcscd          1.3.2-3

The card reader is Reiner SCT cyberJack e-com class 3 reader.

I work for the smart card vendor Giesecke & Devrient and would be
willing to contribute with respect to APDUs and smart card file systems.
However, it looks to me as if the problem in question here is not
located on APDU level but somewhere around gnupg-agent itself or my
faulty usage of gpgsm.

Does gpgsm know about class 3 readers? There are two certificates on my
card, one is to be used with PINs from the PC keyboard ("CSA password")
and the other is to be used with PINs entered on the card reader. Only
the latter one is acceptable for qualified signatures. It seems to me
that certificate in question is of the first kind (judged from looking
at the certificate chains).

More information about the Gnupg-users mailing list