Project

General

Profile

Issue #3264

feature CUSTOM:kernel-ipsec in plugin 'kernel-netlink' failed to load

Added by James Fahrny 3 months ago. Updated about 17 hours ago.

Status:
Feedback
Priority:
Normal
Category:
configuration
Affected version:
5.8.1
Resolution:

Description

I apologize in advance if this has already been solved. I am using strongSwan 5.8.0 and a working baseline that uses ipsec config files and can create SAs with a series of target devices that are running Debian Linux. I have performed measurements for performance and I am now trying to get to a new baseline with the addition of a Spyrus HSM microSD card.

This seems like a kernel privilege issue but I could really use some expert input on how to solve this.
All of the certificates and keys are loaded in PKCS 12 format on the SD token and are being found correctly.

I am getting an error that is "feature CUSTOM:kernel-ipsec in plugin 'kernel-netlink' failed to load".

I am attaching the charon log so that the path is defined. Can you please provide some insight?
Thanks,
Jim Fahrny

charon.log (6.95 KB) charon.log James Fahrny, 12.11.2019 06:54
ipsec.conf (679 Bytes) ipsec.conf James Fahrny, 12.11.2019 17:17
ipsec.conf (768 Bytes) ipsec.conf James Fahrny, 13.11.2019 06:59
charon.log (9.15 KB) charon.log James Fahrny, 13.11.2019 06:59

History

#1 Updated by Tobias Brunner 3 months ago

  • Category changed from charon to configuration
  • Status changed from New to Feedback
  • Priority changed from High to Normal

I am getting an error that is "feature CUSTOM:kernel-ipsec in plugin 'kernel-netlink' failed to load".

Becasue you already loaded the kernel-libipsec plugin. It's not really an error if you actually want to use the latter (read the linked page).

More of an issue is probably this:

Nov 11 23:21:15 00[CFG] loading secrets from '/usr/local/etc/ipsec.secrets'
Nov 11 23:21:15 00[CFG] line 1: expected PIN

See PinSecret.

#2 Updated by James Fahrny 3 months ago

Thanks Tobias for the quick reply! It sounds like I don't need to load kernel-libipsec and that there is an ipsec component in kernel-netlink? That sounds much better since the reduced performance of kernel-libipsec is not going to match the long term goal.

Both of these lines below are redundant with having the keys/certs on the HSM.

Loading ca certificates from /usr/local/etc/ipsec.d/cacerts
Loading secrets from /usr/local/etc/ipsec.d/ipsec.secrets

With ipsec.secrets, I only have the HSM reference, slot, key ID, PIN in this file and the secret key is on the SD Token.
If I only have the leftcert ID in the ipsec.conf file, the certs and secret key will auto load from token. Why would strongSwan also try to load from certs/secret keys from these directories?

Attaching the ipsec.conf file.
Thanks,
Jim

#3 Updated by James Fahrny 3 months ago

Made some changes including adding the %prompt to the PIN in ipsec.secrets I also removed eliminated the loading of the kernel-libipsec plugin. I am attaching a new copy of the charon.log and the ipsec.conf files. I am now seeing the same issues that you had talked about in issue 3048.
unable to create IPv4 routing table rule
unable to create IPv6 routing table rule

http://wiki.strongswan.org/issues/3048

I looked at the charon_nm kernel privilege that you outlined in this issue 3048. I have added the plugin section for in the strongswan.conf file but did not see any change?

I have a routing table setup at 254:

ip route list table 254
default via 192.168.3.254 dev br0
172.20.0.0/16 dev br0 proto kernel scope link src 172.20.40.32
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.32
192.168.3.0/24 dev br0 proto kernel scope link src 192.168.3.32
192.168.4.0/24 dev rdl1 proto kernel scope link src 192.168.4.32
However, the seems to be some type of routing table issue and it may be permissions?

I also used "ipsec listcerts" and "ipsec listcacerts" and see no output but will this command work on an HSM?
If yes, then I probably have and issue with packaging multiple certs/keys in each PKCS #12 package or a problem with the referencing of the CKA_ID, Subject name or Alt Subject. I see some areas where the strongSwan document says CKA_ID must be used but not sure about this piece?
Thanks,
Jim Fahrny

#4 Updated by Tobias Brunner 3 months ago

I looked at the charon_nm kernel privilege that you outlined in this issue 3048. I have added the plugin section for in the strongswan.conf file but did not see any change?

Why do you think charon-nm is relevant? (You are using the charon daemon, not the NM backend.) Anyway, to use routing rules, the kernel must support them (they are required to install routes in a separate table, however, they could also be installed in the main routing table, or routing installation may be disabled completely if not required).

I looked at the charon_nm kernel privilege that you outlined in this issue 3048. I have added the plugin section for in the strongswan.conf file but did not see any change?

Again, charon-nm is not relevant here.

I have a routing table setup at 254:

That's just the main routing table.

However, the seems to be some type of routing table issue and it may be permissions?

Don't think it's a permission issue as the XFRM socket, which requires CAP_NET_ADMIN, has been opened successfully.

I also used "ipsec listcerts" and "ipsec listcacerts" and see no output but will this command work on an HSM?

If any certificates have been loaded from the device, yes.

If yes, then I probably have and issue with packaging multiple certs/keys in each PKCS #12 package or a problem with the referencing of the CKA_ID, Subject name or Alt Subject. I see some areas where the strongSwan document says CKA_ID must be used but not sure about this piece?

Certificates are loaded automatically if found and unless disabled (see pkcs11 plugin). Keys are referenced via CKA_ID in config files (certificates may be associated with configs via them too). Regarding PKCS#12 and how to store certificates/keys, you'd have to check the docs of your HSM. strongSwan uses PKCS#11 to communicate with the HSM, so as long as it implements it properly, it doesn't matter how the data is stored.

#5 Updated by James Fahrny 3 months ago

Yes, I was working late and should have not gone down the charon_nm path. I didn't think it would apply.

Thanks for the link on kernel routing rules. I corrected some missing pieces in that area a few days ago.

You do agree that the two unable messages need to be corrected?
unable to create IPv4 routing table rule
unable to create IPv6 routing table rule

On the HSM, there must be some type of issue if the keys/certs are automatically loaded on startup.
with strongswan running, there is nothing showing up with the "ipsec listcerts"
I do have the private key/cert/CA cert all in the same file and the CN is the same ID. I think that the HSM uses CKA_Label by default and the CKA_ID needs to be added to make this work?

Thanks Again!

#6 Updated by Tobias Brunner 2 months ago

You do agree that the two unable messages need to be corrected?

Depends on whether you need the routes (depends on the scenario and existing routes etc.) and whether it is an advantage to have them in a separate table.

I think that the HSM uses CKA_Label by default and the CKA_ID needs to be added to make this work?

No idea. Ask the manufacturer of your device. The pkcs11 plugin simply enumerates all X.509 certificate objects returned by the device, the CKA_ID is not relevant for that.

#7 Updated by James Fahrny 2 months ago

Several issues are resolved. There appear to not be any routing issues and I have connections along with a tunnel and Child SA with "ipsec statusall". I only have a few more questions since I do not have security associations.
I am still not seeing certificates when I use the "ipsec listcerts". Since the CA certs are still setup in PEM files, I can see those with "ipsec listcacerts". This leads to a few questions:
1) Is there any tool/logging capability in strongSwan to log PKCS 11 messages/transactions between PKCS11 plugin and the HSM?

2) Does it make sense to store the end entity private key in the clear to possibly eliminate any problems with the PIN in ipsec.secrets?

3) There are two choices in ipsec.secrets with * : PIN %smartcard0:<key_id> "Pin Code"* or : PIN %smartcard0:<key_id> %prompt
4) I am using the x509 certificate Common Name for Key_ID. Will this work?
If the prompt is used, should there be a way to enter the PIN?
Are these the only 2 methods for specifying a PIN for the private key?

Thanks for all of your assistance.

#8 Updated by Tobias Brunner 2 months ago

1) Is there any tool/logging capability in strongSwan to log PKCS 11 messages/transactions between PKCS11 plugin and the HSM?

The plugin itself has not much logging except for error cases. Since it's the configured PKCS#11 library that actually communicates with the HSM, check if you can enable logging there.

2) Does it make sense to store the end entity private key in the clear to possibly eliminate any problems with the PIN in ipsec.secrets?

What do you mean? Not store the key on the HSM? Or does it allow storing it unencrypted?

4) I am using the x509 certificate Common Name for Key_ID. Will this work?

<key_id> is the CKA_ID of the key object. Since that's a byte array it could theoretically be the CN, but you'll have to use the hex encoding there.

If the prompt is used, should there be a way to enter the PIN?

You have to call ipsec secrets to get prompted.

Are these the only 2 methods for specifying a PIN for the private key?

Yes. What other method would you expect?

#9 Updated by James Fahrny 2 months ago

Tobias Brunner wrote:

1) Is there any tool/logging capability in strongSwan to log PKCS 11 messages/transactions between PKCS11 plugin and the HSM?

The plugin itself has not much logging except for error cases. Since it's the configured PKCS#11 library that actually communicates with the HSM, check if you can enable logging there.

Thanks! I wanted to make sure and I am building a PKCS 11 open source logging tool.

2) Does it make sense to store the end entity private key in the clear to possibly eliminate any problems with the PIN in ipsec.secrets?

What do you mean? Not store the key on the HSM? Or does it allow storing it unencrypted?

I think that it does but it would require some modification

4) I am using the x509 certificate Common Name for Key_ID. Will this work?

<key_id> is the CKA_ID of the key object. Since that's a byte array it could theoretically be the CN, but you'll have to use the hex encoding there.

OK, thanks! The private keys have a CKA ID and I have entered that no in place of what I had used.

If the prompt is used, should there be a way to enter the PIN?

You have to call ipsec secrets to get prompted.

Are these the only 2 methods for specifying a PIN for the private key?

Yes. What other method would you expect?

Thanks and I was just thinking that there should be a way to secure the PIN but the prompt method does that.

Back at the beginning of this thread you stated:
"More of an important issue is"
Nov 11 23:21:15 00[CFG] loading secrets from '/usr/local/etc/ipsec.secrets'
Nov 11 23:21:15 00[CFG] line 1: expected PIN

I was looking at this log entry that the file was loaded and the PIN was found as expected on Line 1.
Is this interpretation correct or is this an error/warning stating that a PIN was expected but not found?

#10 Updated by Noel Kuntze 2 months ago

Make sure the line is formatted correctly. Check the man page for ipsec.secrets for reference.

#11 Updated by James Fahrny 2 months ago

I have SAs and security tunnels running with a pkcs 12 file for the certificate packages on the initiator and responder. Is the keyid value required to be an integer in ipsec secrets and a string/character array does not work? I am not getting a valid match for the certificate and the keyid in the ipsec.secrets file.

#12 Updated by Tobias Brunner 2 months ago

I have SAs and security tunnels running with a pkcs 12 file for the certificate packages on the initiator and responder. Is the keyid value required to be an integer in ipsec secrets and a string/character array does not work? I am not getting a valid match for the certificate and the keyid in the ipsec.secrets file.

PKCS#12 is a container format, it has nothing to do with PIN secrets and keyids. However, if you are referring to PKCS#11, then these things would be relevant (as I said before, the keyid is the CKA_ID, parsed as a hexadecimal binary string).

#13 Updated by James Fahrny about 2 months ago

I was able to resolve series of issues around p12, keyid, HSM and there is one area that we would like to see if there are any plans to modify the strongswan configure/configure.ac build variables? We are using strongswan in several projects for endpoint/server communication security. We need to be able to easily make openssl to package components like librypto into locations that we want to control for applications but have the linux environment/system be unchanged. We want to have specific versions of openssl, pkcs11 engines and other strongswan components built and packaged into non-system linux locations that are not in the /usr/lib/aarcch64-linux-gnu/ path. We also need to modify plugin dependencies like libstrongswan-openssl paths/locations other than the /usr/lib/aarch-linux-gnu/libcrypto.so.1.0.0 but a path to a library that we control. Is this easily modifiable or are the plans to make this easier to control? Thanks!

#14 Updated by Tobias Brunner about 2 months ago

./configure --help?

#15 Updated by James Fahrny 15 days ago

I am having a problem that the error status is no pkcs11 module found with key id = x in the log status.

I wanted to confirm that the subject key identifier must have the same value of the keyid for the
find_lib_and_keyid_by_skid function to return a valid value. Is this correct?

When I print the elements of the certs/keys that I have generated using "ipsec pki", the keyid is not the same
value as the subject key identifier. I thought that the keyid could be set in the ipsec pki command by setting it
with --keyid (hex value) but this does not seem to work. Are there examples for this or is the --keyid only for displaying
the keyid value?

Thanks!

#16 Updated by Tobias Brunner 14 days ago

With regards to the pkcs11 plugin the "id", "keyid" or "handle" refers to the CKA_ID of the key/certificate object on the token/smartcard. And yes, it's usually easiest if that value matches the keyid (as printed by pki) of the related key/certificate. But it doesn't have to if you explicitly configure it.

#17 Updated by James Fahrny 14 days ago

Let me layout this issue with more details so it makes more sense. I wrote this last message late last night.
In Issue #845 (5 years ago), you stated that the "same ID is not enough, the ID must actually match the SubjectKeyIdentifier of the certificate (or a hash of the subjectPublicKey.)" However, this issue was using charon_nm. I am using charon so does this requirement of matching apply to charon as well?

Loaded plugins
loaded plugins: charon pkcs11 aes rc2 sha2 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf curve25519 xcbc cmac hmac gcm attr kernel-netlink resolve socket-default forecast stroke vici updown xauth-generic dhcp counters

ipsec.conf

config setup
        charondebug="all" 
        uniqueids = yes
        strictcrlpolicy=no

conn %default
        keyingtries=0
        ikelifetime=1h
        lifetime=8h
        dpddelay=30
        dpdtimeout=120
        dpdaction=restart
        keyexchange=ikev2
        type=tunnel
        ike=aes256-sha2_256-modp1024!
        esp=aes256-sha2_256!
        leftsubnet=192.168.50.0/24
        rightsubnet=192.168.50.0/24
        left=%defaultroute
        leftid="C=US, O=strongSwan, CN=860109a4-6e61-42c6-84fa-f3c319ce2feb" 
        auto=start

conn ux32 
        right=192.168.3.32
        rightid="C=US, O=strongSwan, CN=cfa9cb85-3e39-4e6a-a7ee-abba7d9af91f" 

ipsec.secrets

: PIN %smartcard0:33 "$p412usA" 

strongswan.conf

charon {
    load_modular = yes
    multiple_authentication=no
    plugins {
            include strongswan.d/charon/*.conf
    }

    libstrongswan {
       plugins {
         modules {
          HSM_SD {
            # Full path to the shared object file of this PKCS#11 module.
            path = /usr/local/lib/lib3pkcs11x64sd.so.1.18
          }
        }
    }
 }

pkcs11.conf

pkcs11 {

    # Whether to load the plugin. Can also be an integer to increase the
    # priority of this plugin.
    load = yes

    # Reload certificates from all tokens if charon receives a SIGHUP.
     reload_certs = no

    # Whether the PKCS#11 modules should be used for DH and ECDH (see use_ecc
    # option).
     use_dh = no

    # Whether the PKCS#11 modules should be used for ECDH and ECDSA public key
    # operations. ECDSA private keys can be used regardless of this option.
     use_ecc = no

    # Whether the PKCS#11 modules should be used to hash data.
     use_hasher = no

    # Whether the PKCS#11 modules should be used for public key operations, even
    # for keys not stored on tokens.
     use_pubkey = no

    # Whether the PKCS#11 modules should be used as RNG.
     use_rng = no

    # List of available PKCS#11 modules.
    modules {

        MICRO_SD {

            # Whether to automatically load certificates from tokens.
            load_certs = yes

            # Whether OS locking should be enabled for this module.
            os_locking = no

            # Full path to the shared object file of this PKCS#11 module.
            path = /usr/local/lib/lib3pkcs11x64sd.so.1.18

        }

    }

}

Log file with details
Getting this error with extra debug added into pkcs11_private_key.c

Jan 12 21:57:05 oc03 charon-custom: 00[CFG] loading aa certificates from '/usr/local/etc/ipsec.d/aacerts'
Jan 12 21:57:05 oc03 charon-custom: 00[CFG] loading ocsp signer certificates from '/usr/local/etc/ipsec.d/ocspcerts'
Jan 12 21:57:05 oc03 charon-custom: 00[CFG] loading attribute certificates from '/usr/local/etc/ipsec.d/acerts'
Jan 12 21:57:05 oc03 charon-custom: 00[CFG] loading crls from '/usr/local/etc/ipsec.d/crls'
Jan 12 21:57:05 oc03 charon-custom: 00[CFG] loading secrets from '/usr/local/etc/ipsec.secrets'
Jan 12 21:57:05 oc03 charon-custom: 00[CFG] BUILD PKCS#11 slot# 0
Jan 12 21:57:05 oc03 charon-custom: 00[CFG] BUILD PKCS#11 Key ID 33
Jan 12 21:57:05 oc03 charon-custom: 00[CFG] CKO Public - PKCS#11 module NOT found having CKO Pub keyid 33
Jan 12 21:57:05 oc03 charon-custom: 00[CFG] CKO Certificate - PKCS#11 module NOT found having CKO Cert keyid 33
Jan 12 21:57:05 oc03 charon-custom: 00[CFG] PKCS#11 module '(null)' found
Jan 12 21:57:05 oc03 charon-custom: 00[CFG] no PKCS#11 module found having a keyid 33
Jan 12 21:57:05 oc03 charon-custom: 00[LIB] failed to load private key with ID '0:33' from engine 'pkcs11'
Jan 12 21:57:05 oc03 charon-custom: 00[LIB] building CRED_PRIVATE_KEY - ANY failed, tried 7 builders

Key Print

ipsec pki --print --in 860109a4-6e61-42c6-84fa-f3c319ce2feb-Cert.pem

  subject:  "C=US, O=strongSwan, CN=860109a4-6e61-42c6-84fa-f3c319ce2feb" 
  issuer:   "C=US, O=strongSwan, CN=Root CA" 
  validity:  not before Jan 13 01:58:39 2020, ok
             not after  Jan 12 01:58:39 2022, ok (expires in 729 days)
  serial:    44:73:3e:a4:1f:75:06:f2
  altNames:  oc31
  flags:     serverAuth ikeIntermediate 
  authkeyId: 1e:e2:11:cc:19:ce:42:d1:de:80:32:09:2d:08:cf:75:d6:d7:94:df
  subjkeyId: e3:e4:68:88:d9:b1:76:06:8c:ba:82:1f:41:a4:1d:d7:34:ef:dc:53
  pubkey:    RSA 2048 bits
  keyid:     38:a2:41:c6:81:03:cb:39:fe:fe:3c:0c:a8:9c:bf:ba:42:7b:23:10
  subjkey:   e3:e4:68:88:d9:b1:76:06:8c:ba:82:1f:41:a4:1d:d7:34:ef:dc:53

Questions
Should the PKCS#11 module value be null or match the name MICRO_SD?

I have loaded the private key, the public key and the certificate onto the SD token with a CKA_ID value of 33.
Does the "module" = NULL create any problem with the the function "find_lib_and_keyid_by_skid"?

Do you see any other problems that could create this error?
Thanks Much!

#18 Updated by Tobias Brunner 13 days ago

I am using charon so does this requirement of matching apply to charon as well?

No, because you can explicitly configure the CKA_ID.

The modules section in your strongswan.conf file is useless (there is no plugin called modules). Is the module configured in the pkcs11.conf file actually loaded (check the log)?

Should the PKCS#11 module value be null or match the name MICRO_SD?

Doesn't really matter if you only have one module configured.

I have loaded the private key, the public key and the certificate onto the SD token with a CKA_ID value of 33.

33 hex or decimal? The handles in strongSwan are always hex. Are you sure about the slot ID (otherwise just omit it)?

Does the "module" = NULL create any problem with the the function "find_lib_and_keyid_by_skid"?

No, that function is actually only called if the module is not set. Otherwise find_lib is called directly.

#19 Updated by James Fahrny 13 days ago

Tobias Brunner wrote:

I am using charon so does this requirement of matching apply to charon as well?

No, because you can explicitly configure the CKA_ID.

OK, great. That is what I am doing with the tool that loads the objects onto the SD token.

The modules section in your strongswan.conf file is useless (there is no plugin called modules). Is the module configured in the pkcs11.conf file actually loaded (check the log)?

The log shows that the plugin was loaded successfully.

Yes, this was a typo and I corrected it. It is now setup as:

libstrongswan {
plugins {
pkcs11 {
modules {
TOKEN_SD { # Full path to the shared object file of this PKCS#11 module.
path = /usr/local/lib/lib3pkcs11x64sd.so.1.18
}
}
}
}
}

Actually, I realized that I don't need this explicit callout
of the plugin for PKCS 11 modules since the section at the top of the strongswan.conf file has:

plugins {
include strongswan.d/charon/*.conf
}

Should the PKCS#11 module value be null or match the name MICRO_SD?

Doesn't really matter if you only have one module configured.

Both are called the same name (TOKEN_SD) and yes I only have one token configured on each target.

Is it required to have the module defined in both the strongswan.conf and in the pkcs11.conf file?

I have loaded the private key, the public key and the certificate onto the SD token with a CKA_ID value of 33.

33 hex or decimal? The handles in strongSwan are always hex. Are you sure about the slot ID (otherwise just omit it)?

I will need look at this but I am 99% sure that the value is 33 hex. Does this need to be specified in ipsec.secrets as 0x33?
Yes, the slot is 0 so I will just omit it.

Does the "module" = NULL create any problem with the the function "find_lib_and_keyid_by_skid"?

No, that function is actually only called if the module is not set. Otherwise find_lib is called directly.

The function "find_lib_and_keyid_by_skid" is definitely being called given the debug statements in the log.

For this function below, I added the DBG1 logging and I am not getting to the "case BUILD_PKCS11_MODULE:" in the switch statement.

pkcs11_private_key_t *pkcs11_private_key_connect(key_type_t type,
va_list args) {
private_pkcs11_private_key_t *this;
char *module = NULL;
chunk_t keyid = chunk_empty, ckaid = chunk_empty;
int slot = -1;
CK_RV rv;

while (TRUE)
{
switch (va_arg(args, builder_part_t)) {
case BUILD_PKCS11_KEYID:
keyid = va_arg(args, chunk_t);
DBG1(DBG_CFG, "BUILD PKCS#11 Key ID%#B", &keyid);
continue;
case BUILD_PKCS11_SLOT:
slot = va_arg(args, int);
DBG1(DBG_CFG, "BUILD PKCS#11 slot# %d",slot);
continue;
case BUILD_PKCS11_MODULE:
module = va_arg(args, char*);
DBG1(DBG_CFG, "BUILD PKCS#11 Module %s",module);
continue;
case BUILD_END:
break;
default:
return NULL;
}
break;

Why would I need get to this case in the switch?
Thanks!

#20 Updated by James Fahrny 13 days ago

Actually, forget the first question since I figured this out by examining the strongswan.conf file later in my responses.

#21 Updated by James Fahrny 13 days ago

The last question should say...
What would cauae the code execution to not get to the "case BUILD_PKCS11_MODULE:" in the switch statement?
The public key and certificate appear to be found on the token but the private key is not found. Is it possible that the login has not happened to permit access to the private key?
The 33 is definitely 0x33 hex value for keyid.
THANKS

#22 Updated by Tobias Brunner 13 days ago

What would cauae the code execution to not get to the "case BUILD_PKCS11_MODULE:" in the switch statement?

Obviously, this block is only executed if a module was passed (e.g. if you configure one in the %smartcard statement).

The public key and certificate appear to be found on the token but the private key is not found.

The certificate is loaded automatically (unless disabled in the config) simply by enumerating all certificate objects on the token. You can try loading it explicitly via leftcert=%smartcard... to see if it can loaded that way.

Is it possible that the login has not happened to permit access to the private key?

No that happens later, after the module and object with matching CKA_ID has been found.

The 33 is definitely 0x33 hex value for keyid.

Can you post a list of object on the token (e.g. via pkcs11-tool --list-objects if you have OpenSC installed).

#23 Updated by James Fahrny 12 days ago

Here are the objects on the token:

Token Information:
                         label: SPYRUS ROSETTA SD 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
                manufacturerID: SPYRUS INC.                     
                         model: Rosetta SD      
                  serialNumber: 02000000900022EE
                         flags: CKF_RNG,CKF_LOGIN_REQUIRED,CKF_USER_PIN_INITIALIZED,CKF_TOKEN_INITIALIZED
             ulMaxSessionCount: 4096
             ulMaxSessionCount: 4096
                   ulMaxPinLen: 20
                   ulMinPinLen: 1
           ulTotalPublicMemory: 8000
            ulFreePublicMemory: 8000
          ulTotalPrivateMemory: 8000
           ulFreePrivateMemory: 8000
               hardwareVersion: 003.000
               firmwareVersion: 000.014
           utcTime: \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
Object 0
                   Object size: 1587
                     CKA_CLASS: CKO_CERTIFICATE
                     CKA_TOKEN: TRUE
                   CKA_PRIVATE: FALSE
                     CKA_LABEL: 860109a4-6e61-42c6-84fa-f3c319ce2feb
                     CKA_VALUE: 
30 82 04 5a 30 82 02 42 a0 03 02 01 02 02 08 57 
9c ad 22 f6 f8 fc cc 30 0d 06 09 2a 86 48 86 f7 
0d 01 01 0c 05 00 30 34 31 0b 30 09 06 03 55 04 
06 13 02 55 53 31 13 30 11 06 03 55 04 0a 13 0a 
73 74 72 6f 6e 67 53 77 61 6e 31 10 30 0e 06 03 
55 04 03 13 07 52 6f 6f 74 20 43 41 30 1e 17 0d 
31 39 30 39 31 30 30 34 34 36 30 37 5a 17 0d 32 
31 30 39 30 39 30 34 34 36 30 37 5a 30 51 31 0b 
30 09 06 03 55 04 06 13 02 55 53 31 13 30 11 06 
03 55 04 0a 13 0a 73 74 72 6f 6e 67 53 77 61 6e 
31 2d 30 2b 06 03 55 04 03 13 24 38 36 30 31 30 
39 61 34 2d 36 65 36 31 2d 34 32 63 36 2d 38 34 
66 61 2d 66 33 63 33 31 39 63 65 32 66 65 62 30 
82 01 22 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 
05 00 03 82 01 0f 00 30 82 01 0a 02 82 01 01 00 
d4 fd 7d 31 c4 20 c9 33 0d 35 90 ca 4f 59 b4 a4 
79 69 44 a8 62 42 d1 f2 c2 3f 9b ad dc 43 d7 af 
a8 e6 d0 d0 71 dd 75 49 b6 f2 f8 4d 3f 83 6a d9 
02 c5 20 62 61 82 dc 66 64 db e5 c5 82 73 5e 64 
75 0e 0c 08 7f 73 f4 8a 94 b9 39 aa c4 9a c3 28 
21 57 cc f4 aa f4 bd 70 c5 4c f8 83 15 79 70 6b 
1f c9 96 4a cc 94 12 f5 06 87 6f a7 13 40 eb 29 
2a d8 34 59 85 42 a7 80 58 56 cf 86 63 41 54 e5 
85 13 6c 7b c2 80 60 a2 68 56 07 62 0d a3 dd f2 
51 b3 46 cd 3b 49 c2 4d 7b 09 b8 36 86 a5 78 bb 
3f f7 76 cc e0 57 2d 26 3c ee a4 57 67 02 a8 0c 
fb c0 e5 37 d6 01 2d 1d 6e 0f fe 02 6e 1f a2 f3 
3f 25 2e b0 5f 87 d3 7e 3e e0 23 ef f0 8e 6d ba 
7f 70 0b 9a 2f 7f 4d f2 53 de 31 6a 58 c0 9c 79 
2f 88 d0 78 53 15 ce 7a d4 74 bc 1a 3f 9a 13 d6 
8d f8 85 94 5b 7b 46 84 20 c2 65 62 32 a6 04 1d 
02 03 01 00 01 a3 53 30 51 30 1f 06 03 55 1d 23 
04 18 30 16 80 14 1e e2 11 cc 19 ce 42 d1 de 80 
32 09 2d 08 cf 75 d6 d7 94 df 30 0f 06 03 55 1d 
11 04 08 30 06 82 04 6f 63 33 31 30 1d 06 03 55 
1d 25 04 16 30 14 06 08 2b 06 01 05 05 07 03 01 
06 08 2b 06 01 05 05 08 02 02 30 0d 06 09 2a 86 
48 86 f7 0d 01 01 0c 05 00 03 82 02 01 00 61 92 
26 2a c0 4f d3 8e 1c 2e b5 9f fb e0 e4 d3 53 e3 
ef 3d e0 70 4f e5 68 18 30 56 f9 79 42 92 f1 eb 
0d d8 64 d5 02 00 94 8b 06 86 d6 f7 b8 75 b0 1e 
9e 5d eb 6c 5f 61 c4 66 b4 08 17 71 3e 8f b1 9a 
10 45 07 f2 e8 33 2d 92 8a 07 99 5f 57 95 b8 3a 
ee 70 6f 8d 7b fb 57 27 78 9d 5b 50 87 f9 8d 63 
b7 34 b6 80 5d 9e 02 b3 53 8b 26 71 a5 c0 6e 2f 
99 eb 95 ca 8d b3 64 25 10 5b 6e 59 b5 9e be 30 
2c 8a e4 86 10 35 32 bb 37 4d 38 fb 49 3f 91 14 
11 49 13 ea 75 ad ba 47 b0 23 6c 7c 3c 7a a5 a9 
e9 43 61 d4 d8 49 dd 41 05 0f de 56 2a 48 6c ed 
22 57 b7 12 b6 dd 86 84 c0 40 12 ea cd 3c 9a b1 
ac 2f ed 51 78 22 08 ba e7 82 33 77 d6 42 60 62 
1f d0 13 b1 27 4b f3 29 48 1e e3 74 1c d5 a0 bc 
69 7c 85 ef 5c 10 18 b1 39 1e 5c 9b 69 7e 1c 31 
5f dd 73 4c 7e ee 20 7c f4 81 27 33 5b 80 71 2e 
d3 c5 2b de e9 b0 1c 9f bb 71 26 aa d4 6e e1 f7 
dc 73 dd ea 4d 00 5c 9a f9 ca ec a1 fb 28 dd e6 
c5 e5 02 4b 5e 87 88 92 a6 ec 03 93 d5 58 45 8a 
e5 b6 8f f0 f9 66 1b 10 2f 32 df 88 56 ef 47 67 
1f 13 56 04 d0 cd 69 57 d2 e1 44 86 f5 69 3b a5 
df 2f 56 c1 65 51 96 ca e7 b9 7d b5 9f d1 13 2b 
eb e4 fa 5b 38 80 0f b6 95 17 cf bf b9 a2 69 1d 
34 13 e5 72 67 ca bd 95 45 4f ff 7f 7e 08 63 c1 
b2 e2 58 0c 6a 74 f2 41 9d 90 91 96 08 ba f4 cc 
51 b7 43 1b 8d 9d 3e 35 96 94 11 73 87 d9 e1 79 
7c 3b ba a5 87 cb e6 d2 1c 69 21 40 61 9c 55 7c 
b2 47 0a 26 01 45 8c b2 4c 45 3d 70 db c6 90 9e 
6d 89 fe d8 f4 55 e9 f4 83 98 30 34 da 95 08 89 
94 b0 32 9b 44 26 ea a6 fb 91 1f d1 21 34 93 96 
39 4e 73 ae 37 95 9c 46 82 3d a0 65 cb fc 3e 00 
42 d5 4c 6d f8 50 7c a3 36 29 ab da b6 1f 

          CKA_CERTIFICATE_TYPE: CKC_X_509
                    CKA_ISSUER: /C=US/O=strongSwan/CN=Root CA

             CKA_SERIAL_NUMBER: 
02 08 57 9c ad 22 f6 f8 fc cc 

                   CKA_SUBJECT: /C=US/O=strongSwan/CN=860109a4-6e61-42c6-84fa-f3c319ce2feb

                        CKA_ID: 
33 

                CKA_MODIFIABLE: TRUE
Object 1
                   Object size: 797
                     CKA_CLASS: CKO_PUBLIC_KEY
                     CKA_TOKEN: TRUE
                   CKA_PRIVATE: FALSE
                     CKA_LABEL: 860109a4-6e61-42c6-84fa-f3c319ce2feb
                  CKA_KEY_TYPE: CKK_RSA
                   CKA_SUBJECT: /C=US/O=strongSwan/CN=860109a4-6e61-42c6-84fa-f3c319ce2feb

                        CKA_ID: 
33 

                   CKA_ENCRYPT: TRUE
                      CKA_WRAP: TRUE
                    CKA_VERIFY: TRUE
            CKA_VERIFY_RECOVER: TRUE
                    CKA_DERIVE: TRUE
                   CKA_MODULUS: 
d4 fd 7d 31 c4 20 c9 33 0d 35 90 ca 4f 59 b4 a4 
79 69 44 a8 62 42 d1 f2 c2 3f 9b ad dc 43 d7 af 
a8 e6 d0 d0 71 dd 75 49 b6 f2 f8 4d 3f 83 6a d9 
02 c5 20 62 61 82 dc 66 64 db e5 c5 82 73 5e 64 
75 0e 0c 08 7f 73 f4 8a 94 b9 39 aa c4 9a c3 28 
21 57 cc f4 aa f4 bd 70 c5 4c f8 83 15 79 70 6b 
1f c9 96 4a cc 94 12 f5 06 87 6f a7 13 40 eb 29 
2a d8 34 59 85 42 a7 80 58 56 cf 86 63 41 54 e5 
85 13 6c 7b c2 80 60 a2 68 56 07 62 0d a3 dd f2 
51 b3 46 cd 3b 49 c2 4d 7b 09 b8 36 86 a5 78 bb 
3f f7 76 cc e0 57 2d 26 3c ee a4 57 67 02 a8 0c 
fb c0 e5 37 d6 01 2d 1d 6e 0f fe 02 6e 1f a2 f3 
3f 25 2e b0 5f 87 d3 7e 3e e0 23 ef f0 8e 6d ba 
7f 70 0b 9a 2f 7f 4d f2 53 de 31 6a 58 c0 9c 79 
2f 88 d0 78 53 15 ce 7a d4 74 bc 1a 3f 9a 13 d6 
8d f8 85 94 5b 7b 46 84 20 c2 65 62 32 a6 04 1d 

              CKA_MODULUS_BITS: 2048
           CKA_PUBLIC_EXPONENT: 
01 00 01 

                CKA_MODIFIABLE: TRUE
Object 2
                   Object size: 815
                     CKA_CLASS: CKO_PRIVATE_KEY
                     CKA_TOKEN: TRUE
                   CKA_PRIVATE: TRUE
                     CKA_LABEL: 860109a4-6e61-42c6-84fa-f3c319ce2feb
                  CKA_KEY_TYPE: CKK_RSA
                   CKA_SUBJECT: /C=US/O=strongSwan/CN=860109a4-6e61-42c6-84fa-f3c319ce2feb

                        CKA_ID: 
33 

                 CKA_SENSITIVE: TRUE
                   CKA_DECRYPT: TRUE
                    CKA_UNWRAP: TRUE
                      CKA_SIGN: TRUE
              CKA_SIGN_RECOVER: TRUE
                    CKA_DERIVE: FALSE
                   CKA_MODULUS: 
d4 fd 7d 31 c4 20 c9 33 0d 35 90 ca 4f 59 b4 a4 
79 69 44 a8 62 42 d1 f2 c2 3f 9b ad dc 43 d7 af 
a8 e6 d0 d0 71 dd 75 49 b6 f2 f8 4d 3f 83 6a d9 
02 c5 20 62 61 82 dc 66 64 db e5 c5 82 73 5e 64 
75 0e 0c 08 7f 73 f4 8a 94 b9 39 aa c4 9a c3 28 
21 57 cc f4 aa f4 bd 70 c5 4c f8 83 15 79 70 6b 
1f c9 96 4a cc 94 12 f5 06 87 6f a7 13 40 eb 29 
2a d8 34 59 85 42 a7 80 58 56 cf 86 63 41 54 e5 
85 13 6c 7b c2 80 60 a2 68 56 07 62 0d a3 dd f2 
51 b3 46 cd 3b 49 c2 4d 7b 09 b8 36 86 a5 78 bb 
3f f7 76 cc e0 57 2d 26 3c ee a4 57 67 02 a8 0c 
fb c0 e5 37 d6 01 2d 1d 6e 0f fe 02 6e 1f a2 f3 
3f 25 2e b0 5f 87 d3 7e 3e e0 23 ef f0 8e 6d ba 
7f 70 0b 9a 2f 7f 4d f2 53 de 31 6a 58 c0 9c 79 
2f 88 d0 78 53 15 ce 7a d4 74 bc 1a 3f 9a 13 d6 
8d f8 85 94 5b 7b 46 84 20 c2 65 62 32 a6 04 1d 

           CKA_PUBLIC_EXPONENT: 
01 00 01 

               CKA_EXTRACTABLE: FALSE
                CKA_MODIFIABLE: FALSE

#24 Updated by James Fahrny 12 days ago

I tried to use the leftcert=%module and it did not seem to work. I am assuming that this requires that you still have the PIN: %module "xxxxxx" in ipsec.secrets?

I also was able to use a debugger and will look at more details in the morning. However, I was able to see that the file credential_factory.c is failing in the METHOD "CRED_PRIVATE_KEY". I need to look at this in more detail to see why it is failing.
THANKS!

#25 Updated by Tobias Brunner 12 days ago

Here are the objects on the token:

Thanks. That at least seems to confirm the CKA_ID of 33 hex.

I tried to use the leftcert=%module and it did not seem to work.

Why would you think that's valid syntax? It's exactly the same as in ipsec.secrets (i.e. it starts with %smartcard).

I am assuming that this requires that you still have the PIN: %module "xxxxxx" in ipsec.secrets?

Yes, but wrong syntax again.

However, I was able to see that the file credential_factory.c is failing in the METHOD "CRED_PRIVATE_KEY".

You should focus on the code in the pkcs11 plugin as that's where the failure occurs eventually.

#26 Updated by James Fahrny 11 days ago

My mistake on the syntax and was not what I had. I actually have PIN: %smartcard:33 "XXXXXXXX" in ipsec.secrets and leftcert=%smartcard in the ipsec.conf

I wrote this late last night. Thanks for the pointer on the pkcs11 plugin.

#27 Updated by Tobias Brunner 11 days ago

My mistake on the syntax and was not what I had. I actually have PIN: %smartcard:33 "XXXXXXXX" in ipsec.secrets and leftcert=%smartcard in the ipsec.conf

I see, please note that the keyid/CKA_ID is mandatory (i.e. the leftcert value is still not correct), and that the : actually has to be before PIN (see PinSecret).

#28 Updated by James Fahrny 10 days ago

Thanks for the update on this. I do have the : before PIN.
Does the pin need to be included in the leftcert syntax?
Are single quotation marks or double quotation marks for pin value both allowed?

:PIN %smartcard:33 '1234' or "1234" or just 1234

leftcert=%smartcard:33 '1234' ?

if I add the module to the PIN statement, I assume that it would be the string TOKEN_SD as defined above. Is this correct?

THANKS!

#29 Updated by Tobias Brunner 8 days ago

Does the pin need to be included in the leftcert syntax?

No.

Are single quotation marks or double quotation marks for pin value both allowed?

Both are fine (or none).

if I add the module to the PIN statement, I assume that it would be the string TOKEN_SD as defined above. Is this correct?

Yes, it's the name of the sub-section you configure in the *.plugins.pkcs11.modules section.

#30 Updated by James Fahrny 7 days ago

Thanks for the inputs! I seem to be having a problem with the Pin/passphrase when the SD Toke is accessing the private key in stroke_creds.c. I have created the p12 package on the SD Token with a passphrase. There is also a password to login into the SD Token. In this case, would the ipsec.secrets need to specify both the PIN for the Smartcard based on the CKA ID and also the P12 passphrase to open the package that was loaded onto the SD Token. If yes, does the order of these in ipsec.secrets file matter?

#31 Updated by Tobias Brunner 7 days ago

In this case, would the ipsec.secrets need to specify both the PIN for the Smartcard based on the CKA ID and also the P12 passphrase to open the package that was loaded onto the SD Token.

That there is a PKCS#12 container on the card is irrelevant to strongSwan, it only accesses it via PKCS#11. So make sure your middleware handles this correctly (e.g. decrypts the PKCS#12 container on the fly when the key/certificate is accesses via PKCS#11).

#32 Updated by James Fahrny 4 days ago

Yes, the import tool unwraps the PKCS 12 and stores the objects as pkcs11 objects.
In Openssl_plugin.c. we have two places that are a little unclear:

There is a function called login(ENGINE *engine, chunk_t key_id)
and the code execution ends up at line 359:
DBG1;

The PIN and the engine values are correct but the keyid appears to be NULL.

We then end up in execution at Line 450/451:

key = ENGINE_load_private_key(engine, keyname, NULL, NULL);
ENGINE_finish(engine);
if (!key) {
Line 450: DBG1(DBG_LIB, "failed to load private key with ID '%s' from "
"engine '%s'", keyname, engine_id);
Line 451: return NULL;

}

The strange part to me is that the keyname is correct as an ascii string of the keyid.
The engine ID is 'pkcs11'.
The key is 0.

Do you have any suggestions on what to look for here or in the PKCS 11 plugin for this
failure. I would think that this is a not finding the private key due to the login but want top see what your thoughts are?
THANKS!

#33 Updated by Tobias Brunner 4 days ago

In Openssl_plugin.c. we have two places that are a little unclear:

So you now use the openssl plugin? Not the pkcs11 plugin? For the former you have to configure OpenSSL correctly (i.e. set up an ENGINE in openssl.cnf that can be used via strongSwan), but why switch? I'd recommend you debug this in the pkcs11 plugin.

#34 Updated by James Fahrny about 17 hours ago

I removed the openssl plugin to possibly eliminate any conflicts that could occur. I added the module name to the ipsec.secrets file:
: PIN %smartcard0@SPYRUS_ROSETTA_SD:38363031303961342d366536312d343263362d383466612d663363333139636532666562 "123456"

I added the CA certificate onto the SD Token.
ca strongswan
cacert=%smartcard:526f6f74204341

I added the leftcert for the smartcard:
leftcert=%smartcard:38363031303961342d366536312d343263362d383466612d663363333139636532666562

The private key is being found now but...

now I am failing with the login to the SD Token:
[CFG] login to 'SPYRUS_ROSETTA_SD':0 failed: FUNCTION_FAILED
[CFG] Login on slot ID 0 failed

The PIN is correct but I am still digging into the login failure.
Any thoughts or things that appear to be wrong?
THANKS

Also available in: Atom PDF