Re: [OpenWrt-Devel] [PATCH 0/4] add μrngd: true RNG based on timing jitter
On 28.05.2019 12:37, Petr Štetiar wrote: Rosen Penev [2019-05-27 19:19:53]: Hi, Tested this on both mt7621 and Turris Omnia. Works pretty well. Init gets done fast. thanks a lot for testing, can you please reply with your Tested-by next time so the patchwork could add this tag automatically to this patch? The Turris people might want something like this or they need to fix haveged to run earlier. I've been recommended haveged many times (by someone from nic.cz as well), so my initial idea was to simply give it a go and create uhaveged, but I quickly came to the conclusion, that it won't work for OpenWrt for many reasons, which I've already forget, but I think it wasn't truly multiplatform solution due to some compiler/assembly magic. Then I've simply found out, that haveged is no longer considered good enough[1] by the security community: Also the use of `haveged` is recommended, which is a bad idea as this daemon can create blocking situations during key generation effectively creating a deadlock and thus security problems. haveged's design is from 2002, it has never been audited, there're only papers by the original authors available. Even Andre Seznec, one of the main HAVEGE authors stated following[2]: He also pointed out a security warning: with some VMs, the hardware cycles counter is emulated and deterministic, and thus predictible[3]. He therefore does not recommend using HAVEGE on those systems. so I started looking at other options and luckily enough, I've found out about this KISS jitter RNG. 1. https://lists.cert.at/pipermail/ach/2017-May/002251.html 2. https://github.com/BetterCrypto/Applied-Crypto-Hardening/commit/cf7cef7a870c1b77089b1bd6209ded6525b5a4e0#commitcomment-23006392 3. https://tls.mbed.org/tech-updates/security-advisories/polarssl-security-advisory-2011-02 -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel works good on Atom 330 first boot dmesg | grep random before [ 29.043097] random: fast init done [ 76.467115] random: crng init done after [ 0.00] random: get_random_bytes called from start_kernel+0x6d/0x3df with crng_init=0 [ 5.899674] random: jshn: uninitialized urandom read (4 bytes read) [ 5.933012] random: jshn: uninitialized urandom read (4 bytes read) [ 5.957578] random: jshn: uninitialized urandom read (4 bytes read) [ 6.969902] urandom_read: 4 callbacks suppressed [ 6.969907] random: jshn: uninitialized urandom read (4 bytes read) [ 10.043998] random: jshn: uninitialized urandom read (4 bytes read) [ 10.550301] random: mkfs.f2fs: uninitialized urandom read (16 bytes read) [ 11.420925] urandom-seed: Seed file not found (/etc/urandom.seed) [ 13.321222] random: crng init done Regards Tested-by Lucian Cristian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] add μrngd: true RNG based on timing jitter
Rosen Penev [2019-05-27 19:19:53]: Hi, > Tested this on both mt7621 and Turris Omnia. Works pretty well. Init > gets done fast. thanks a lot for testing, can you please reply with your Tested-by next time so the patchwork could add this tag automatically to this patch? > The Turris people might want something like this or they need to fix haveged > to run earlier. I've been recommended haveged many times (by someone from nic.cz as well), so my initial idea was to simply give it a go and create uhaveged, but I quickly came to the conclusion, that it won't work for OpenWrt for many reasons, which I've already forget, but I think it wasn't truly multiplatform solution due to some compiler/assembly magic. Then I've simply found out, that haveged is no longer considered good enough[1] by the security community: Also the use of `haveged` is recommended, which is a bad idea as this daemon can create blocking situations during key generation effectively creating a deadlock and thus security problems. haveged's design is from 2002, it has never been audited, there're only papers by the original authors available. Even Andre Seznec, one of the main HAVEGE authors stated following[2]: He also pointed out a security warning: with some VMs, the hardware cycles counter is emulated and deterministic, and thus predictible[3]. He therefore does not recommend using HAVEGE on those systems. so I started looking at other options and luckily enough, I've found out about this KISS jitter RNG. 1. https://lists.cert.at/pipermail/ach/2017-May/002251.html 2. https://github.com/BetterCrypto/Applied-Crypto-Hardening/commit/cf7cef7a870c1b77089b1bd6209ded6525b5a4e0#commitcomment-23006392 3. https://tls.mbed.org/tech-updates/security-advisories/polarssl-security-advisory-2011-02 -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] add μrngd: true RNG based on timing jitter
On Mon, May 27, 2019 at 2:30 PM Petr Štetiar wrote: > > Hi, > > this patch series fixes some of the current urandom-seed flaws and improves > situation with low entropy in the kernel during the boot. > > First, simply writing to /dev/urandom does not increase the kernel's entropy > count, this casuses processes obtaining randomness to block. Particularly > processes using OpenSSL's RAND_bytes() will block until the kernel emits > 'random: crng init done'. This can take upwards of twenty minutes. > > According to random(4) the entropy count is only increased when using the > RNDADDENTROPY ioctl, which urandom-seed currently doesn't use when feeding the > kernel RNG. > > Second, urandom-seed is using /etc/urandom.seed file to seed the kernel's RNG > machinery upon every boot. The problem is, that this file is created only once > during first-boot and then reused on every consecutive boot, so pretty much > static. > > So this patch series adds μrngd, which is a new micro non-physical true random > number generator (system service) based on timing jitter. On devices which > provide a reliable and precise enough timer, μrngd can provide sufficient > entropy. > > μrngd is using the Jitter RNG core under the hood, which provides an entropy > source that μrngd feeds into the Linux /dev/random device if its entropy runs > low. It updates the /dev/random entropy estimator such that the newly > provided entropy unblocks /dev/random. > > The seeding of /dev/random also ensures that /dev/urandom benefits from > entropy. Especially during boot time, when the entropy of Linux is low, the > Jitter RNG based μrngd provides a source of sufficient entropy. > > Some RNG init time numbers from qca9563 (TP-Link Archer C7 v5): > > [ 12.045693] random: crng init done(μrngd) > [ 120.043132] random: crng init done(urandom-seed) > > μrngd binary has 4579 bytes on ath79. > > I'm creating separate packages for getrandom and urandom-seed, so they can be > removed easily on platforms where either μrngd or any other hardware based RNG > provides good entropy. I'm not removing urandom-seed package from the > defaults, because during the testing of μrngd I've found out, that for example > MediaTek MT7620A ver:2 eco:6 (MIPS 24KEc V5.0) doesn't provide high precision > timer which is needed for Jitter RNG so the initialization of Jitter RNG > inside μrngd ends with following error: > > jent-rng init failed, err: 2 (ECOARSETIME) > > so on such platforms it might still be probably better to stick to > urandom-seed as a fallback. The Jitter RNG implements a startup test that is > intended to detect non-appropriate timers. If it identifies such > non-appropriate timers, the Jitter RNG will deactivate. Thus, the Jitter RNG > always tries to reach a secure state. > > I believe, that μrngd is going to improve entropy situation on most of current > platforms OpenWrt supports, so I would like to enable it as default. Having > another source of reliable noise in the system doesn't hurt, it only helps. > > I would like to note, that most of this stuff is based on the amazing work > done[1] by Stephan Müller, I've just bend it over and packaged it for OpenWrt. > > 1. http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html Tested this on both mt7621 and Turris Omnia. Works pretty well. Init gets done fast. The Turris people might want something like this or they need to fix haveged to run earlier. > > Petr Štetiar (4): > urng: add micro non-physical true RNG based on timing jitter > ubox: move getrandom into separate getrandom package > base-files: move urandom seed bits into separate package > build: add urandom-seed and urngd to default packages set > > include/target.mk | 2 +- > package/base-files/Makefile| 11 - > package/base-files/files/etc/init.d/urandom_seed | 12 -- > .../base-files/files/lib/preinit/81_urandom_seed | 24 --- > package/base-files/files/sbin/urandom_seed | 20 - > package/system/ubox/Makefile | 17 ++-- > package/system/urandom-seed/Makefile | 32 +++ > .../urandom-seed/files/etc/init.d/urandom_seed | 12 ++ > .../urandom-seed/files/lib/preinit/81_urandom_seed | 24 +++ > .../system/urandom-seed/files/sbin/urandom_seed| 20 + > package/system/urngd/Makefile | 48 > ++ > package/system/urngd/files/urngd.init | 21 ++ > 12 files changed, 182 insertions(+), 61 deletions(-) > delete mode 100755 package/base-files/files/etc/init.d/urandom_seed > delete mode 100644 package/base-files/files/lib/preinit/81_urandom_seed > delete mode 100755 package/base-files/files/sbin/urandom_seed > create mode 100644 package/system/urandom-seed/Makefile > create mode 100755 package/system/urandom-seed/files/etc/init.d/urandom_seed > create mode 100644 >
