Opened 4 years ago

Last modified 3 years ago

#3634 accepted enhancement

design of asym crypto support

Reported by: fdupont Owned by: fdupont
Priority: low Milestone: Outstanding Tasks
Component: securedhcp Version: git
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DHCP Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description (last modified by fdupont)

The proposal for secure DHCPv6 (https://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6) is currently going through the IETF. If we are to implement this in Kea, an update to the cryptographic capabilities is required. This ticket covers the design of an enhanced cryptographic API to support the draft.

There are some choices to perform, we can follow the current style, so in cryptolink.h:

  • class RSA; (or a more generic name to cover any Asymmetric Algorithm with public/private key pair, public key certificate (in fact encapsulated public key) and final sign/verify operations)
  • RSA* createRSA(xxx) with 3 overloads:
  • RSA* createRSA(const void* cert, size_t cert_len); (note the cert includes the algo) (note IMHO there is no need for a CERT class here as it should be enough to deal with them as bunches of bytes).
  • RSA* createRSA(const void* pubkey, size_t pubkey_len); (same than for certificates when the public key is in the format proposed by secure DHCPv6 (or DNSKEY RDATA))
  • RSA* createRSA(const void* privkey, size_t privkey_len); (we can do the same using PKCS8 which optionally encrypts the value. Note if we want to use this kind of feature it should be easier to use two char* arguments for the file path and the PIN) (PKCS8 can be a bit hard to handle but I have the code: it is used in SoftHSMv2 both as the external format and for key wrapping)

For the crypto_rsa.h (or better crypto_asym???.h):

  • contructor and friend createRSA
  • destructor
  • update()
  • sign()
  • verify()

utils:

  • getOutputLength()
  • perhaps something about keys

Please look at this:

  • does seem the best to do?
  • what name to use (RSA will match only RSA, Asym is perhaps better? another proposal?)?

same than for HMAC...

Subtickets

Change History (18)

comment:1 Changed 4 years ago by fdupont

  • Description modified (diff)
  • Owner set to UnAssigned
  • Status changed from new to assigned

comment:2 Changed 4 years ago by fdupont

Second take...
Same kind of API with for createXXX():

  • a format enum saying what is the next argument (PKCS8 private key, subjectPublicKeyInfo, DNSKEY rdata, etc)
  • data+data_len, buffer?, file path, etc (in fact anything we can consider as useful)
  • optional (default NULL) PIN

For extra tools I believe we need functions to export key parameters (e.g., algo ids) and value. There are at least 2 places where this is required: build a DS RR from a DNSKEY RR, fill a SEDHCP signature option.

comment:3 Changed 4 years ago by fdupont

Implemented almost the whole thing but I have no strong idea about what to do for certificates:

  • a simple way is to use self-signed certificates (so a certificate brought a public key, the proof of the private key ownership and some attributes about the owner). In this case it will be enough to compare a certificate with its trusted local version (BTW both crypto backends provide a certificate compare but none really compare them bit to bit: OpenSSL compares cached hashes, Botan compares a small set of critical fields. Note for our purpose it is better to compare public case (i.e., n and e in RSA)).
  • a complex way with certificate chains up to a trust anchor, CRLs, etc.

Both are supported so it is more a question of server configuration: opaque per client attribute or a full PKI?

comment:4 Changed 4 years ago by fdupont

Implemented the self-signed idea. Note to go further #3606 must be reviewed ASAP.

comment:5 Changed 4 years ago by fdupont

I am gaining on holidays so I give this for pre-review... Note it is stacked on #3606.

comment:6 Changed 4 years ago by fdupont

  • Status changed from assigned to reviewing

comment:7 Changed 4 years ago by tomek

  • Milestone changed from Kea-proposed to DHCP Outstanding Tasks

Moving to DHCP outstanding as discussed on 2014-12-03 call (and repeated on 2014-12-10).

comment:8 Changed 4 years ago by stephen

  • Description modified (diff)

comment:9 Changed 4 years ago by fdupont

  • Description modified (diff)

comment:10 Changed 3 years ago by fdupont

  • Owner changed from UnAssigned to fdupont
  • Status changed from reviewing to accepted

comment:11 Changed 3 years ago by fdupont

Took the ticket which is reactivated for the secure DHCPv6 experiment.
Rebased over current master + #3513 + #3859 + #3882 (BTW the first has a direct impact on src/lib/cryptolink) into trac3634a branch.

Last edited 3 years ago by fdupont (previous) (diff)

comment:12 Changed 3 years ago by fdupont

Rebranching over #3908 using sedhcpv6 branch.

comment:13 Changed 3 years ago by fdupont

The code is available for review even there is nothing for the current release (and perhaps the next one).

comment:14 Changed 3 years ago by fdupont

  • Owner changed from fdupont to UnAssigned
  • Status changed from accepted to reviewing

comment:15 Changed 3 years ago by fdupont

  • Owner changed from UnAssigned to fdupont
  • Status changed from reviewing to accepted

I remove this from review and propose to split it into:

  • RSA (required for secure DHCPv6)
  • ECDSA (with detection in configure.ac as some OpenSSL's are built without ECC support)
  • tools/examples (for secure DHCPv6 users)

comment:16 Changed 3 years ago by fdupont

A dependency (#3908) and 3 children (#4021, #4022, #4023).

comment:17 Changed 3 years ago by fdupont

  • Component changed from crypto to securedhcp

comment:18 Changed 3 years ago by tomek

  • Milestone changed from DHCP Outstanding Tasks to Outstanding Tasks

Milestone renamed

Note: See TracTickets for help on using tickets.