Project

General

Profile

Issue #3421

Using SHA3 with IPsec

Added by Alexander Velkov about 1 year ago. Updated 8 days ago.

Status:
Closed
Priority:
Normal
Category:
configuration
Affected version:
5.8.4
Resolution:
No change required

Description

Hi,

I have a running site-to-site tunnel with IKEv2.

BOX[~]# ipsec statusall
Status of IKE charon daemon (strongSwan 5.8.4, Linux 5.4.23, armv7l):
  uptime: 109 seconds, since Apr 22 10:22:42 2020
  malloc: sbrk 200704, mmap 0, used 185344, free 15360
  worker threads: 27 of 32 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 4
  loaded plugins: charon aes des sha2 sha3 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey pem openssl fips-prf gmp curve25519 xcbc hmac attr kernel-netlink resolve socket-default stroke updown xauth-generic unity
Listening IP addresses:
  192.168.3.3
  fc00:192::3
Connections:
     ipsec$0:  192.168.3.3...192.168.3.28  IKEv2
     ipsec$0:   local:  [C=DE, ST=Bayern, L=Muenchen, O=Garderos, OU=TEST, CN=server, E=server@garderos.com] uses public key authentication
     ipsec$0:    cert:  "C=DE, ST=Bayern, L=Muenchen, O=Garderos, OU=TEST, CN=server, E=server@garderos.com" 
     ipsec$0:   remote: uses public key authentication
    ipsec2$0:   child:  192.168.4.3/32 === 192.168.4.28/32 TUNNEL
Routed Connections:
    ipsec2$0{2}:  ROUTED, TUNNEL, reqid 2
    ipsec2$0{2}:   192.168.4.3/32 === 192.168.4.28/32
Security Associations (1 up, 0 connecting):
     ipsec$0[3]: ESTABLISHED 30 seconds ago, 192.168.3.3[C=DE, ST=Bayern, L=Muenchen, O=Garderos, OU=TEST, CN=server, E=server@garderos.com]...192.168.3.28[C=DE, ST=Bayern, L=Muenchen, O=Garderos, OU=TEST, CN=client, E=client@garderos.com]
     ipsec$0[3]: IKEv2 SPIs: 5a804ad67c12d1c4_i* bf7aa17ef8be69f8_r, rekeying in 60 minutes
     ipsec$0[3]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
    ipsec2$0{4}:  INSTALLED, TUNNEL, reqid 2, ESP SPIs: c61a4fa5_i c4ea5ada_o
    ipsec2$0{4}:  AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 50 minutes
    ipsec2$0{4}:   192.168.4.3/32 === 192.168.4.28/32

BOX[~]# openssl version
OpenSSL 1.1.1e  17 Mar 2020

How should I switch to using SHA3 for IKE, for example? If I change the configuration from "ike=aes256-sha256-ecp256!" to "ike=aes256-sha3_256-ecp256!", I get this in the logs:

..
Apr 22 10:41:34 BOX info  charon  [ 4318]: CFG 05     : algorithm 'sha3' not recognized
Apr 22 10:41:34 BOX info  charon  [ 4318]: CFG 05     : skipped invalid proposal string: aes256-sha3_256-ecp256
..

Thanks for the help!

History

#1 Updated by Tobias Brunner about 1 year ago

  • Description updated (diff)
  • Status changed from New to Feedback

How should I switch to using SHA3 for IKE, for example?

You can't. The use of SHA-3 has not yet been standardized for use with IKE or ESP (not sure if that ever will happen as AEADs are clearly preferred nowadays), it can only be used for signatures.

#2 Updated by Alexander Velkov about 1 year ago

You can't. The use of SHA-3 has not yet been standardized for use with IKE or ESP (not sure if that ever will happen as AEADs are clearly preferred nowadays), it can only be used for signatures.

Hi Tobias,

thanks for the quick reply!

OpenSSL in the new LTS version 1.1.1 states this as a major feature. If SHA2 gets broken in the future, do you think that SHA3 will get standardized? ...

#3 Updated by Tobias Brunner about 1 year ago

OpenSSL in the new LTS version 1.1.1 states this as a major feature.

So?

If SHA2 gets broken in the future, do you think that SHA3 will get standardized?

Just use an AEAD algorithm. As I said, for signatures (in certificates and IKEv2) it can already be used.

#4 Updated by Alexander Velkov about 1 year ago

So?

hehe, ok :)

Just use an AEAD algorithm.

Yes, I've tested that already and it works fine!

Thank you very much, Tobias!

#5 Updated by Tobias Brunner about 1 year ago

  • Category set to configuration
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to No change required

#6 Updated by Alexander Velkov 2 months ago

Hi again,

we have been testing with certificates in IKEv2 using the SHA3 signature algorithm. We created a new RSA PKI using SHA3-512 as a signature algorithm for the CA, server and client certificates, here is a part of the resulting server certificate:

# openssl x509 -in server-sha3.crt -text -noout
Certificate:
    Data:
...
        Signature Algorithm: RSA-SHA3-512
..

We then tried to establish an IPsec tunnel (keyexchange=ikev2) and get errors, here from the server side:

Mar 12 13:37:48 SERVER info  charon  [ 7688]: IKE 26     : IKE_SA (unnamed)[45] state change: CREATED => CONNECTING
Mar 12 13:37:48 SERVER info  charon  [ 7688]: IKE 26     : sending cert request for "C=DE, ST=Bayern, L=Muenchen, O=Vendor, OU=IT,Test, CN=testca-sha3" 
Mar 12 13:37:48 SERVER info  charon  [ 7688]: ENC 26     : generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
Mar 12 13:37:48 SERVER info  charon  [ 7688]: NET 26     : sending packet: from 172.16.0.3[500] to 172.16.0.34[500] (365 bytes)
Mar 12 13:37:48 SERVER info  charon  [ 7688]: NET 16     : received packet: from 172.16.0.34[4500] to 172.16.0.3[4500] (1248 bytes)
Mar 12 13:37:48 SERVER info  charon  [ 7688]: ENC 16     : parsed IKE_AUTH request 1 [ EF(1/2) ]
Mar 12 13:37:48 SERVER info  charon  [ 7688]: ENC 16     : received fragment #1 of 2, waiting for complete IKE message
Mar 12 13:37:48 SERVER info  charon  [ 7688]: NET 29     : received packet: from 172.16.0.34[4500] to 172.16.0.3[4500] (168 bytes)
Mar 12 13:37:48 SERVER info  charon  [ 7688]: ENC 29     : parsed IKE_AUTH request 1 [ EF(2/2) ]
Mar 12 13:37:48 SERVER info  charon  [ 7688]: ENC 29     : received fragment #2 of 2, reassembled fragmented IKE message (1356 bytes)
Mar 12 13:37:48 SERVER info  charon  [ 7688]: ENC 29     : parsed IKE_AUTH request 1 [ IDi CERT CERTREQ AUTH SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
Mar 12 13:37:48 SERVER info  charon  [ 7688]: IKE 29     : received cert request for "C=DE, ST=Bayern, L=Muenchen, O=Vendor, OU=IT,Test, CN=testca-sha3" 
Mar 12 13:37:48 SERVER info  charon  [ 7688]: IKE 29     : received end entity cert "C=DE, ST=Bayern, L=Muenchen, O=Vendor, OU=IT,Test, CN=testdevice" 
Mar 12 13:37:48 SERVER info  charon  [ 7688]: LIB 29     : signature scheme RSA_EMSA_PKCS1_SHA3_512 not supported in RSA
Mar 12 13:37:48 SERVER info  charon  [ 7688]: LIB 29     : signature scheme RSA_EMSA_PKCS1_SHA3_512 not supported in RSA
Mar 12 13:37:48 SERVER info  charon  [ 7688]: IKE 29     : no trusted RSA public key found for
...

SERVER[~]# ipsec statusall
Status of IKE charon daemon (strongSwan 5.9.2, Linux 5.4.94, armv7l):
  uptime: 103 minutes, since Mar 12 13:09:46 2021
  malloc: sbrk 196608, mmap 0, used 164728, free 31880
  worker threads: 27 of 32 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 0
  loaded plugins: charon aes des sha2 sha3 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey pem openssl fips-prf gmp curve25519 xcbc hmac ccm gcm attr kernel-netlink resolve socket-default stroke updown xauth-generic unity
Listening IP addresses:
  172.16.0.3
  10.0.3.1
Connections:
ipsec-cert$0:  172.16.0.3...172.16.0.34  IKEv2, dpddelay=60s
ipsec-cert$0:   local:  [C=DE, ST=Bayern, L=Muenchen, O=Vendor, OU=IT,Test, CN=server] uses public key authentication
ipsec-cert$0:    cert:  "C=DE, ST=Bayern, L=Muenchen, O=Vendor, OU=IT,Test, CN=server" 
ipsec-cert$0:   remote: uses public key authentication
ipsec-cert$0:   child:  10.0.3.1/32 === 10.4.4.0/24 TUNNEL, dpdaction=clear
Security Associations (0 up, 0 connecting):
  none

Thanks for any help.

#7 Updated by Tobias Brunner 10 days ago

The openssl plugin currently doesn't support RSA signatures with SHA-3, only the gmp plugin does (actually, the botan plugin does too), so make sure to load that before the openssl plugin (see PluginLoad).

#8 Updated by Alexander Velkov 9 days ago

Tobias Brunner wrote:

The openssl plugin currently doesn't support RSA signatures with SHA-3, only the gmp plugin does (actually, the botan plugin does too), so make sure to load that before the openssl plugin (see PluginLoad).

Thanks for the update!

Hmm, this is somehow strange I have the GMP plugin loaded according to ipsec statusall, but probably not in the correct order as you mentioned above:

# ipsec statusall
..
  loaded plugins: charon aes des sha2 sha3 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey pem openssl fips-prf *gmp* curve25519 xcbc hmac ccm gcm attr kernel-netlink resolve socket-default farp stroke updown xauth-generic unity
..

# ipsec listalgs

List of registered IKE algorithms:

  encryption: AES_CBC[aes] AES_ECB[aes] 3DES_CBC[des] DES_CBC[des] DES_ECB[des] CAMELLIA_CBC[openssl] CAST_CBC[openssl]
              BLOWFISH_CBC[openssl] IDEA_CBC[openssl] NULL[openssl]
  integrity:  HMAC_MD5_96[openssl] HMAC_MD5_128[openssl] HMAC_SHA1_96[openssl] HMAC_SHA1_128[openssl]
              HMAC_SHA1_160[openssl] HMAC_SHA2_256_128[openssl] HMAC_SHA2_256_256[openssl] HMAC_SHA2_384_192[openssl]
              HMAC_SHA2_384_384[openssl] HMAC_SHA2_512_256[openssl] HMAC_SHA2_512_512[openssl] CAMELLIA_XCBC_96[xcbc]
              AES_XCBC_96[xcbc]
  aead:       AES_GCM_16[openssl] AES_GCM_12[openssl] AES_GCM_8[openssl] CHACHA20_POLY1305[openssl] AES_CCM_8[ccm]
              AES_CCM_12[ccm] AES_CCM_16[ccm] CAMELLIA_CCM_8[ccm] CAMELLIA_CCM_12[ccm] CAMELLIA_CCM_16[ccm]
  hasher:     HASH_SHA1[sha1] HASH_SHA2_224[sha2] HASH_SHA2_256[sha2] HASH_SHA2_384[sha2] HASH_SHA2_512[sha2]
              HASH_SHA3_224[sha3] HASH_SHA3_256[sha3] HASH_SHA3_384[sha3] HASH_SHA3_512[sha3] HASH_MD5[md5]
              HASH_MD4[openssl] HASH_IDENTITY[openssl]
  prf:        PRF_KEYED_SHA1[sha1] PRF_HMAC_MD5[openssl] PRF_HMAC_SHA1[openssl] PRF_HMAC_SHA2_256[openssl]
              PRF_HMAC_SHA2_384[openssl] PRF_HMAC_SHA2_512[openssl] PRF_FIPS_SHA1_160[fips-prf] PRF_AES128_XCBC[xcbc]
              PRF_CAMELLIA128_XCBC[xcbc]
  xof:        XOF_SHAKE128[sha3] XOF_SHAKE256[sha3]
  drbg:      
  dh-group:   ECP_256[openssl] ECP_384[openssl] ECP_521[openssl] ECP_224[openssl] ECP_192[openssl] ECP_256_BP[openssl]
              ECP_384_BP[openssl] ECP_512_BP[openssl] ECP_224_BP[openssl] MODP_3072[openssl] MODP_4096[openssl]
              MODP_6144[openssl] MODP_8192[openssl] MODP_2048[openssl] MODP_2048_224[openssl] MODP_2048_256[openssl]
              MODP_1536[openssl] MODP_1024[openssl] MODP_1024_160[openssl] MODP_768[openssl] MODP_CUSTOM[openssl]
              CURVE_25519[openssl] CURVE_448[openssl]
  random-gen: RNG_WEAK[openssl] RNG_STRONG[random] RNG_TRUE[random]
  nonce-gen:  [nonce]

Maybe there is something wrong with the way I compile StrongSwan. I saw that I don't use an enable-gmp entry while configuring, because I see it as 'enabled' on the Plugins page.

$ ./strongswan-5.9.2/configure --help | grep gmp
  --disable-gmp           disable GNU MP (libgmp) based crypto implementation
                          in software. Requires libgmp.
                          libgmp, if available (default: yes).

# I have 'enable-plugin' entries only for the plugins not stated as 'enabled' by default

./configure
..
                        --enable-openssl \
                        --enable-sha3 \
                        --enable-gcm \
                        --enable-ccm \
                        --enable-unity \
..

Do I need to specify all the plugins with --enabled-X statements?

#9 Updated by Alexander Velkov 9 days ago

# ipsec listplugins

List of loaded Plugins:
..
   gmp:
..
    PUBKEY_VERIFY:RSA_EMSA_PKCS1_SHA3_224
        HASHER:HASH_SHA3_224
    PUBKEY_VERIFY:RSA_EMSA_PKCS1_SHA3_256
        HASHER:HASH_SHA3_256
    PUBKEY_VERIFY:RSA_EMSA_PKCS1_SHA3_384
        HASHER:HASH_SHA3_384
    PUBKEY_VERIFY:RSA_EMSA_PKCS1_SHA3_512
        HASHER:HASH_SHA3_512

#10 Updated by Tobias Brunner 9 days ago

Hmm, this is somehow strange I have the GMP plugin loaded according to ipsec statusall, but probably not in the correct order as you mentioned above:

Yes, you can see the order right there.

Maybe there is something wrong with the way I compile StrongSwan. I saw that I don't use an enable-gmp entry while configuring, because I see it as 'enabled' on the Plugins page.

You can't change the order at compile time, which is why I linked the page that explains how to do that at runtime.

#11 Updated by Alexander Velkov 9 days ago

Yes, you can see the order right there.

OK.

You can't change the order at compile time, which is why I linked the page that explains how to do that at runtime.

Right.
I changed my strongswan.conf to load_modular=yes and additionally I set the gmp Plugin to a higher priority with load=2, all others with default prio 1. That made my tunnel with certificates signed using SHA3 go UP without any further issues. Great, thanks!

Until now, I have used neither the load_modular nor the static load options to activate the Plugins, I even don't have a plugins {} definition in strongswan.conf. The plugins got loaded though, I guess in a more or less random order.
In the Plugins page I find in Compile Time Plugin Configuration 'Proper load order of all plugins (since 5.1.0 this is not so important anymore, the order simply indicates the preference if two plugins provide the same feature)' - but in my case the SHA3 sig. handling feature was provided by the GMP plugin only. So why didn't this feature get loaded? This is why I asked about the configure options.

#12 Updated by Tobias Brunner 8 days ago

Until now, I have used neither the load_modular nor the static load options to activate the Plugins, I even don't have a plugins {} definition in strongswan.conf. The plugins got loaded though, I guess in a more or less random order.

No, the default order (i.e. as predefined in the configure script). And you don't actually have to enable load_modular to change the load order of plugins via load.

but in my case the SHA3 sig. handling feature was provided by the GMP plugin only. So why didn't this feature get loaded? This is why I asked about the configure options.

That's because that feature only becomes relevant after the key was parsed, which both plugins can do. Since OpenSSL supports SHA-3 internally, it parses the key fine (if it wouldn't know the algorithm, it would fail and the gmp plugin would take over). However, because the plugin itself does not support SHA-3 signatures, signing operations will later fail (probably wouldn't be that hard to add this but I haven't looked into it).

#13 Updated by Alexander Velkov 8 days ago

No, the default order (i.e. as predefined in the configure script). And you don't actually have to enable load_modular to change the load order of plugins via load.

Yes, I saw that the OpenSSL plugin is before the GMP plugin while assembling the plugins in the configure script.
I tried to retain the order of plugins (as listed in ipsec statusall) but set gmp before openssl in a charon.load line (without load_modular) in strongswan.conf. That worked for me.

That's because that feature only becomes relevant after the key was parsed, which both plugins can do. Since OpenSSL supports SHA-3 internally, it parses the key fine (if it wouldn't know the algorithm, it would fail and the gmp plugin would take over). However, because the plugin itself does not support SHA-3 signatures, signing operations will later fail (probably wouldn't be that hard to add this but I haven't looked into it).

Ah OK, that explains it! .. If the plugin could handle SHA-3 signatures then I wouldn't need the workaround from above. But anyway, I can confirm that the feature works fine, so thank you very much for your support!

#14 Updated by Tobias Brunner 8 days ago

I tried to retain the order of plugins (as listed in ipsec statusall) but set gmp before openssl in a charon.load line (without load_modular) in strongswan.conf. That worked for me.

That's not actually what I meant. You can use charon.plugins.<plugin>.load to change the order for a specific plugin even without load_modular, no need to use charon.load to specify the complete list (check the docs again it's explained in the last paragraph of this section).

#15 Updated by Alexander Velkov 8 days ago

You can use charon.plugins.<plugin>.load to change the order for a specific plugin even without load_modular, no need to use charon.load to specify the complete list (check the docs again it's explained in the last paragraph of this section).

Ah OK, that is even better. I just tried setting ONLY the prio for the gmp plugin to '2' without load or load_modular and that worked also fine, the tunnel with SHA-3 signatures went UP! Thanks again :) !!!

#16 Updated by Alexander Velkov 8 days ago

Forgot to mention, setting the prio for GMP to '2' boosts the position of the plugin in the loaded plugins list to the front. I guess, I could also set the prio for OpenSSL to '0/-1' for my test to be successful. I am not sure what is better, I need to test if that brings unwanted implications in case similar loading/feature issues exist with GMP and the other plugins...

Also available in: Atom PDF