Date: Fri, 26 Oct 2018 19:54:00 +0000 (UTC) From: Conrad Meyer <cem@FreeBSD.org> To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r339784 - head/sbin/dumpon Message-ID: <201810261954.w9QJs05X054833@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: cem Date: Fri Oct 26 19:53:59 2018 New Revision: 339784 URL: https://svnweb.freebsd.org/changeset/base/339784 Log: dumpon(8): Provide seatbelt against weak RSA keys The premise of dumpon -k foo.pem is that dump contents will be confidential except to anyone holding the corresponding RSA private key. This guarantee breaks down when weak RSA keys are used. Small RSA keys (e.g. 512 bits) can be broken on a single personal computer in tractible time. Marginal RSA keys (768 bits) can be broken by EC2 and a few dollars. Even 1024 bit keys can probably be broken by sophisticated and wealthy attackers. NIST SP800-57 (2016) recommends a minimum of 2048 bit RSA keys, and estimates this provides 112 bits of security. It would also be good to protect users from weak values of 'e' (i.e., 3) and perhaps sanity check that their public key .pem does not accidentally contain their private key as well. These considerations are left as future work. Reviewed by: markj, darius AT dons.net.au (previous version) Discussed with: bjk Differential Revision: https://reviews.freebsd.org/D17678 Modified: head/sbin/dumpon/dumpon.8 head/sbin/dumpon/dumpon.c Modified: head/sbin/dumpon/dumpon.8 ============================================================================== --- head/sbin/dumpon/dumpon.8 Fri Oct 26 19:16:17 2018 (r339783) +++ head/sbin/dumpon/dumpon.8 Fri Oct 26 19:53:59 2018 (r339784) @@ -28,7 +28,7 @@ .\" From: @(#)swapon.8 8.1 (Berkeley) 6/5/93 .\" $FreeBSD$ .\" -.Dd June 13, 2018 +.Dd October 26, 2018 .Dt DUMPON 8 .Os .Sh NAME @@ -348,3 +348,15 @@ is taken, it is not possible to send crash dumps direc It is currently not possible to configure both compression and encryption. The encrypted dump format assumes that the kernel dump size is a multiple of the cipher block size, which may not be true when the dump is compressed. +.Sh SECURITY CONSIDERATIONS +RSA keys smaller than 1024 bits are practical to factor and therefore weak. +Even 1024 bit keys may not be large enough to ensure privacy for many +years, so NIST recommends a minimum of 2048 bit RSA keys. +As a seatbelt, +.Nm +prevents users from configuring encrypted kernel dumps with weak RSA keys. +If you do not care for cryptographic privacy guarantees, just use +.Nm +without specifying a +.Fl k Ar pubkey +option. Modified: head/sbin/dumpon/dumpon.c ============================================================================== --- head/sbin/dumpon/dumpon.c Fri Oct 26 19:16:17 2018 (r339783) +++ head/sbin/dumpon/dumpon.c Fri Oct 26 19:53:59 2018 (r339784) @@ -243,6 +243,30 @@ genkey(const char *pubkeyfile, struct diocskerneldump_ if (pubkey == NULL) errx(1, "Unable to read data from %s.", pubkeyfile); + /* + * RSA keys under ~1024 bits are trivially factorable (2018). OpenSSL + * provides an API for RSA keys to estimate the symmetric-cipher + * "equivalent" bits of security (defined in NIST SP800-57), which as + * of this writing equates a 2048-bit RSA key to 112 symmetric cipher + * bits. + * + * Use this API as a seatbelt to avoid suggesting to users that their + * privacy is protected by encryption when the key size is insufficient + * to prevent compromise via factoring. + * + * Future work: Sanity check for weak 'e', and sanity check for absence + * of 'd' (i.e., the supplied key is a public key rather than a full + * keypair). + */ +#if OPENSSL_VERSION_NUMBER >= 0x10100000L + if (RSA_security_bits(pubkey) < 112) +#else + if (RSA_size(pubkey) * 8 < 2048) +#endif + errx(1, "Small RSA keys (you provided: %db) can be " + "factored cheaply. Please generate a larger key.", + RSA_size(pubkey) * 8); + kdap->kda_encryptedkeysize = RSA_size(pubkey); if (kdap->kda_encryptedkeysize > KERNELDUMP_ENCKEY_MAX_SIZE) { errx(1, "Public key has to be at most %db long.",
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201810261954.w9QJs05X054833>