Extend RFC-7427 Signature Authentication support to IKEv2 with EDDSA: Difference between revisions

From Libreswan
Jump to navigation Jump to search
No edit summary
No edit summary
Line 24: Line 24:


https://github.com/Rishabh-Kumar-07/nss/commit/629e90bb7e4b9c5ce269fb30b401e6bba53207a8
https://github.com/Rishabh-Kumar-07/nss/commit/629e90bb7e4b9c5ce269fb30b401e6bba53207a8
https://github.com/Rishabh-Kumar-07/libreswan/tree/ed25519-gsoc


This project work was sponsored by Google as part of the Google Summer of Code 2021 Program.
This project work was sponsored by Google as part of the Google Summer of Code 2021 Program.
The implementation for this project is done by Rishabh Kumar (cs19mtech11026@iith.ac.in) under the mentorship of Paul Wouters and Andrew Cagney.
The implementation for this project is done by Rishabh Kumar (cs19mtech11026@iith.ac.in) under the mentorship of Paul Wouters and Andrew Cagney.

Revision as of 16:08, 19 August 2021

Introduction

This project aimed to extend the RFC-7427 Digital signature authentication scheme to support EdDSA as per RFC 8420. Since Libreswan relies on the NSS library for cryptographic operations, modifications in the NSS code were made to add the implementation of EdDSA.The mechanisms for generating Ed25519 keys, generating and verifying Ed25519 signatures were added to the NSS. As per RFC 8420, a new value “Identity” must be sent in the SIGNATURE_HASH_ALGORITHMS notification. Inserting this new value into the notification indicates that the receiver supports at least one signature algorithm that accepts messages of an arbitrary size such as Ed25519 and Ed448. Support for this new value and other code to support EdDSA was added in libreswan.

Implementation

1. NSS Implementation: The freebl is the base cryptographic layer where the primitives are implemented. The formally verified implementation (HACL* Library) of Ed25519 was integrated and EDDSA_SignDigest, EDDSA_VerifyDigest, and ED_NewKey were defined in the freebl layer. The Softoken is the PKCS #11 plumbing layer. The current PKCS #11 spec defines CKM_EDDSA mechanism to add support for EdDSA. This mechanism was implemented and the functions EDDSA_SignDigest and EDDSA_VerifyDigest were hooked into NSC_SignInit and NSC_VerifyInit using the stub functions nsc_EDDSASignStub and nsc_EDDSAVerifyStub. The test suite of the gtests (freebl_gtest and pk11_gtest) was extended and test vectors from RFC 8032 were included. Files Hacl_Ed25519.c, Hacl_Ed25519.h, ed25519_unittest.cc, pk11_eddsa_unittest.cc, pk11_eddsa_vectors.h were added. Also, modifications were made to pk11_signature_test.h as EdDSA do not require to prehash the messages to generate and verify signatures. Other modifications were made in blapi.h, pk11table.c, ec.c, loader.c, loader.h, pk11mech.c, pkcs11c.c.

2. Libreswan implementation: To use EdDSA, the user must set the “authby” value in ipsec.conf to EdDSA (authby=eddsa). Changes were made in confread.c to do so. Policy, ASN.1 Object, and structures for the public and private keys were added. The Libreswan already supported ECDSA, so functions were renamed and code was generalized to EC. Major modifications were made in secrets.c to generalize the code. RFC-8420 specifies that EdDSA versions that do not require prehashing of the message SHOULD be used. To signal that no hashing needs to be done, a new value “Identity” is to be added in the SIGNATURE HASH ALGORITHMS notification payload. A new hash algorithm IKEv2_HASH_ALGORITHM_IDENTITY was added and structure was defined in crypt_hash.c. To generate and verify signatures, ikev2_eddsa.c was added and changes were made in v2_calculate_sighash, authsig_and_log_using_pubkey, and code for AUTHBY_EDDSA was added. Also, changes were made in dest_certs.py and strongswan-ec-gen.sh were made to generate Ed25519 certificates. The Test Suite was extended by adding test cases to verify feature functionality and perform interoperability tests with strong swan.

Issues encountered and Future Work

Currently, the NSS supports curve25519 and uses it for key exchange but the public keys generated can not be used for the Ed25519 signature scheme even though both of them generate keys using the same curve. The reason being, currently the public keys generated by the NSS are encoding of the “x” coordinate of a point on Curve25519. Whereas an Ed25519 public key is the encoding of the “x” and “y” coordinates of a point on curve25519.

A separate SECOID needs to be added to support Ed25519 x509 certificates. Changes need to be made to secsign.c and secvfy.c to recognize and pass around the new OID value added for Ed25519. Also, the new OID has to be added nss/lib/util/secoid*. The oid table will make the oid to CKM_EDDSA. From there the NSS will trigger based on the new OID and Libreswan should be able to use the EDDSA as per RFC 8420.


Source code

https://github.com/Rishabh-Kumar-07/nss/commit/629e90bb7e4b9c5ce269fb30b401e6bba53207a8 https://github.com/Rishabh-Kumar-07/libreswan/tree/ed25519-gsoc

This project work was sponsored by Google as part of the Google Summer of Code 2021 Program. The implementation for this project is done by Rishabh Kumar (cs19mtech11026@iith.ac.in) under the mentorship of Paul Wouters and Andrew Cagney.